دو توزیع محبوب Rancher/SUSE برای Kubernetes اغلب کنار هم مطرح می‌شوند: K3s برای edge و منابع کم، و RKE2 برای دیتاسنتر، انطباق امنیتی و محیط‌های تنظیم‌شده.

RKE2 is Rancher’s enterprise-ready next-generation Kubernetes distribution — also known as RKE Government.

هدف رسمی طبق docs.rke2.io: توزیع fully conformant با تمرکز روی امنیت و compliance (از جمله بخش دولتی آمریکا) — نه «Kubernetes سبک برای Raspberry Pi».

سایت: docs.rke2.io · اکوسیستم: SUSE Rancher · نصب: https://get.rke2.io

RKE2 چیست؟

RKE2 (Rancher Kubernetes Engine 2) نسل بعدی موتور Kubernetes رانچر برای use caseهای دیتاسنتر است. به‌صورت standalone یا یکپارچه با Rancher اجرا می‌شود؛ از Rancher v2.6+ provisioning خودکار کلاستر RKE2 در دسترس است.

برای رسیدن به اهداف امنیتی، RKE2:

نام دوم RKE Government همان تمرکز امنیتی/دولتی را نشان می‌دهد؛ نام محصول رایج امروز RKE2 است.

از کجا آمده؟ RKE1، K3s، RKE2

RKE1          → Docker برای control plane + runtime
K3s           → تک‌باینری سبک، بهینه‌شده برای edge (گاهی فاصله از upstream)
RKE2          → usability شبیه K3s + نزدیکی به upstream شبیه RKE1
              → control plane به‌صورت static pods + containerd (بدون Docker)

طبق مقدمهٔ رسمی:

• از K3s: سادگی عملیات و مدل استقرار (تک‌باینری / script نصب)
• از RKE1: هم‌ترازی نزدیک با upstream Kubernetes
• برخلاف RKE1: دیگر به Docker وابسته نیست؛ اجزای control plane static pod زیر مدیریت kubelet؛ runtime تعبیه‌شده containerd

جزئیات بیشتر معماری: Architecture.

مشکل: کدام توزیع را انتخاب کنیم؟

SUSE Communities — When to Use K3s and RKE2 همین تفکیک را تأیید می‌کند: هر دو CNCF-certified و پشتیبانی‌شده توسط Rancher؛ هدف متفاوت.

مقایسهٔ جامع RKE2 و K3s

یک جملهٔ تصمیم

• اگر کسی غیر از تیم شما (ممیزی، امنیت، دولت) باید کلاستر را تأیید کند → RKE2
• اگر کلاستر باید در جایی «ناراحت» با منابع کم زنده بماند → K3s

مقالهٔ عمیق K3s: K3s: Lightweight Kubernetes برای Edge و IoT.

معماری RKE2

در ساده‌ترین شکل: یک باینری روی هر نودی که در کلاستر شرکت می‌کند. پس از start، RKE2 نقش server یا agent را bootstrap می‌کند و محتوا را از شبکه (یا air-gap) می‌گیرد.

پشتهٔ فناوری

طبق Architecture، RKE2 این‌ها را گرد هم می‌آورد:

Bootstrap محتوا

1. جستجوی image rancher/rke2-runtime در /var/lib/rancher/rke2/agent/images/*.tar یا pull از رجیستری
2. استخراج /bin/ → containerd، shims، kubelet، runc، به‌همراه ctr / crictl / kubectl / socat
3. استخراج charts به /var/lib/rancher/rke2/server/manifests
4. server: static pod برای etcd، apiserver، controller-manager، scheduler
5. agent: containerd + kubelet؛ helm-controller charts شبکه/DNS/Ingress را اعمال می‌کند

rke2 process (systemd)
   ├─ containerd
   ├─ kubelet
   │     └─ static pods: etcd, apiserver, controller-manager, scheduler
   └─ helm-controller → Canal/Cilium + CoreDNS + Ingress + metrics-server …

فرآیند RKE2 تا SIGTERM/SIGKILL یا خروج containerd زنده می‌ماند.

پورت‌های مهم

امنیت و Compliance

CIS

RKE2 طوری طراحی شده که hardened by default باشد و بخش عمدهٔ کنترل‌های CIS را بدون تغییر پاس کند. برای عبور کامل معمولاً:

1. تنظیمات سطح host (sysctl، کاربر etcd، …)
2. اجرای با profile: cis (یا cis-1.XX بسته به نسخه) در /etc/rancher/rke2/config.yaml

# /etc/rancher/rke2/config.yaml  — قبل از start
profile: "cis"

با profile فعال می‌شود از جمله:

• بررسی پیش‌نیازهای host (وگرنه fatal exit)
• اجرای etcd با کاربر etcd
• NetworkPolicy روی namespaceهای سیستمی
• Pod Security Admission در حالت restricted (با استثنای kube-system و چند namespace سیستمی)
• پارامترهای audit-log روی API Server

راهنما: CIS Hardening Guide. Self-assessmentها برای CIS v1.12 (RKE2 v1.33+) و نسخه‌های قبلی مستند شده‌اند.

نمونهٔ sysctl (نصب tarball):

sudo cp -f /usr/local/share/rke2/rke2-cis-sysctl.conf /etc/sysctl.d/60-rke2-cis.conf
sudo systemctl restart systemd-sysctl
sudo useradd -r -c "etcd user" -s /sbin/nologin -M etcd -U

FIPS و CVE

• FIPS 140-2 روی پشتهٔ built-in (containerd، etcd، …) مسیر استقرار در محیط‌های الزام رمزنگاری را باز می‌کند
• اسکن Trivy در pipeline ساخت برای کاهش CVE شناخته‌شده

K3s چنین اعتبار رسمی FIPS/STIG ندارد — تفاوت عملی بزرگ برای تیم‌های امنیت.

شبکه، Ingress و تغییر بزرگ ۲۰۲۶

CNI

گزینه‌ها از طریق charts در manifests: Canal (پیش‌فرض رایج)، Cilium، Calico، Flannel، Multus.

نکتهٔ عملی مهم (از تجربیات جامعه و docs): پس از bootstrap اولیه، عوض کردن CNI اصلی یا CIDR کلاستر/سرویس معمولاً پشتیبانی نمی‌شود — از اول درست انتخاب کنید. برای مقایسهٔ عمیق CNI: CNI در کوبرنتیز. برای Cilium: Cilium eBPF.

Ingress NGINX → Traefik

Ingress NGINX در مارس ۲۰۲۶ EOL شد. طبق اعلام docs و Migration Guide:

• از RKE2 v1.36 برای کلاسترهای جدید، Traefik پیش‌فرض است
• کلاسترهای موجود مسیر مهاجرت مستند دارند (فعال‌سازی Traefik روی پورت موقت، سازگاری annotation، سپس حذف NGINX)

اگر هنوز annotationهای خاص NGINX دارید، قبل از مهاجرت ابزار/مستندات Traefik برای Ingress NGINX annotations را چک کنید.

نصب سریع

طبق Quick Start:

پیش‌نیازها: الزامات سخت‌افزار/شبکه؛ اگر NetworkManager دارید، اینترفیس‌های CNI را ignore کنید؛ در صورت پشتیبانی کرنل از AppArmor، ابزار apparmor-parser؛ اجرا به‌عنوان root/sudo.

Server

curl -sfL https://get.rke2.io | sh -
systemctl enable rke2-server.service
systemctl start rke2-server.service
journalctl -u rke2-server -f

پس از نصب:

export KUBECONFIG=/etc/rancher/rke2/rke2.yaml
export PATH=$PATH:/var/lib/rancher/rke2/bin
kubectl get nodes

برای HA: تعداد فرد server برای quorum etcd.

Agent (Linux)

curl -sfL https://get.rke2.io | INSTALL_RKE2_TYPE="agent" sh -
systemctl enable rke2-agent.service
mkdir -p /etc/rancher/rke2
cat >/etc/rancher/rke2/config.yaml <<EOF
server: https://<SERVER_IP>:9345
token: <NODE_TOKEN>
EOF
systemctl start rke2-agent.service

Agent (Windows)

Windows workers با Calico یا Flannel پشتیبانی می‌شوند — مزیتی که K3s ندارد. نیاز به Windows Containers feature، سپس install.ps1 و سرویس rke2 agent.

مقایسهٔ حس نصب با K3s

# K3s — یک خط، اغلب همه چیز آماده
curl -sfL https://get.k3s.io | sh -

# RKE2 — حس مشابه، ولی سرویس جدا + etcd + hardening سنگین‌تر
curl -sfL https://get.rke2.io | sh -
systemctl enable --now rke2-server

هر دو «آسان»اند؛ RKE2 برای production امن، K3s برای سرعت و سبکی.

عملیات روزمره

برای GitOps روی هر دو توزیع: Flux · Helm. برای multi-cluster: Karmada. برای runtime: containerd.

چه وقت RKE2، چه وقت K3s، چه وقت هر دو؟

                    منابع کم؟ ──yes──► K3s
                         │
                         no
                         ▼
              نیاز CIS/FIPS/STIG یا audit؟ ──yes──► RKE2
                         │
                         no
                         ▼
              Windows worker؟ ──yes──► RKE2
                         │
                         no
                         ▼
              ترجیح «upstream خالص» در datacenter؟ ──yes──► RKE2
                         │
                         no
                         ▼
              Edge + Core یک سازمان؟ ──► RKE2 (core) + K3s (edge)

الگوی رایج سازمانی با Rancher: یک پنل، چند کلاستر — RKE2 برای production حساس، K3s برای فروشگاه‌ها / دستگاه‌ها / شعب.

یکپارچگی با استک P30Light

خلاصه

قدم بعدی

1. یک VM با ≥۴GB RAM بردارید و Quick Start server را اجرا کنید.
2. یک agent لینوکس با token روی :9345 join کنید.
3. profile: cis را روی lab جدا با sysctl و کاربر etcd تست کنید (نه روی کلاستر شلوغ بدون آمادگی).
4. CNI و استراتژی Ingress (Traefik) را قبل از production قفل کنید.
5. اگر edge هم دارید، همان workload را روی K3s مقایسه کنید و با Rancher مدیریت متمرکز را ارزیابی کنید.
6. برای کلاسترهای قدیمی NGINX، Migration Guide را قبل از ارتقا به v1.36+ بخوانید.

منابع

• RKE2 Docs — Introduction
• Architecture
• Quick Start
• CIS Hardening Guide
• Ingress NGINX → Traefik Migration
• SUSE — When to Use K3s and RKE2
• K3s — مقاله P30Light

منتشر شده در P30Light — بخش زیرساخت و سرور