نصب یک خوشه «واقعی» Kubernetes معمولاً یعنی چند باینری، etcd جدا، CNI جدا، Ingress جدا، و ساعت‌ها تنظیم. برای Edge، Raspberry Pi، لابراتوار، یا CI این هزینه اغلب بیش از حد است.

K3s پاسخ Rancher (اکنون در اکوسیستم SUSE) به همین درد است:

Lightweight Kubernetes — The certified Kubernetes distribution built for IoT & Edge computing.

شعار نصب رسمی کوتاه است:

curl -sfL https://get.k3s.io | sh -
sudo k3s kubectl get node

یک باینری کوچک، خوشه آماده در حدود نیم دقیقه. CNCF Sandbox. Certified Kubernetes (conformance) — یعنی API و رفتار با Kubernetes استاندارد سازگار است، نه یک «شبیه‌ساز سبک».

K3s چیست؟ (و چه چیزی نیست)

طبق README رسمی: K3s یک distribution است چون علاوه بر هسته Kubernetes، اجزای لازم برای cluster آماده (runtime، شبکه، ingress، storage محلی، LB) را با انتخاب‌های مشخص بسته‌بندی می‌کند.

نام «K3s» از شوخی «نصف Kubernetes → K8s → K3s» آمده — اما از نظر API همچنان K8s کامل است.

چرا K3s؟

سه وعده سایت رسمی:

1. Perfect for Edge — production در مکان‌های remote و resource-constrained
2. Simplified & Secure — تک‌باینری <۷۰MB، وابستگی کمتر، سطح حمله کوچک‌تر
3. Optimized for ARM — از Raspberry Pi تا سرورهای ARM ابری

تفاوت K3s با Kubernetes «استاندارد» (kubeadm / vanilla)

هر دو Certified Kubernetesاند. تفاوت در بسته‌بندی، پیش‌فرض‌ها، و حذف چیزهای غیرضروری است — نه در این که «Pod کار نمی‌کند».

جدول یک‌نگاه

چه چیزی از باینری حذف شده؟

طبق توضیح پروژه (و تکامل تاریخی):

نکته مهم: حذف این‌ها conformance را نمی‌شکند چون قابلیت هسته Kubernetes نیستند.

چه چیزی اضافه / opinionated است؟

این‌ها را می‌توان با --disable خاموش کرد و جایگزین گذاشت (مثلاً Cilium به‌جای Flannel، Contour به‌جای Traefik).

معماری: Server و Agent

طبق معماری رسمی:

┌─────────────────────────────────────┐
│  k3s server                         │
│  control-plane + datastore          │
│  + kubelet + containerd + CNI       │
└──────────────┬──────────────────────┘
               │ token / websocket tunnels
     ┌─────────┴─────────┐
     ▼                   ▼
┌──────────┐       ┌──────────┐
│ k3s agent│       │ k3s agent│
│ kubelet  │       │ kubelet  │
│ containerd + CNI │ …
└──────────┘       └──────────┘

• Server: k3s server — API، control plane، datastore
• Agent: k3s agent — بدون datastore/control-plane؛ workloadها را اجرا می‌کند
• هر دو می‌توانند kubelet و runtime و CNI داشته باشند

ارتباط agent ↔ server از طریق tunnel (معادل مفهومی Konnectivity در توزیع‌های دیگر) برقرار می‌شود — مناسب Edge که پورت‌های kubelet را باز نمی‌خواهید.

حالت‌های datastore

Kubeconfig پیش‌فرض: /etc/rancher/k3s/k3s.yaml
Token پیوستن agent: /var/lib/rancher/k3s/server/node-token

چه چیزی پشتیبانی می‌شود / چه چیزی پیش‌فرض نیست

✅ پشتیبانی می‌شود (و معمولاً کار می‌کند)

⚠️ پیش‌فرض نیست یا باید خودتان بیاورید

❌ / خارج از محدوده معمول

غیرفعال کردن اجزای بسته‌شده

طبق Managing Packaged Components:

# مثال: بدون Traefik و بدون ServiceLB
curl -sfL https://get.k3s.io | sh -s - server \
  --disable=traefik \
  --disable=servicelb

اجزای قابل disable رایج: traefik، servicelb، local-storage، metrics-server، coredns (با احتیاط — DNS لازم دارید).

جایگزین CNI:

curl -sfL https://get.k3s.io | sh -s - server \
  --flannel-backend=none \
  --disable-network-policy
# سپس Cilium / Calico را نصب کنید

Manifestهای کاربر در /var/lib/rancher/k3s/server/manifests به‌صورت AddOn اعمال می‌شوند.

نصب عملی

تک‌node (سریع‌ترین مسیر)

curl -sfL https://get.k3s.io | sh -
sudo k3s kubectl get node
sudo k3s kubectl get pods -A

یا با kubectl سیستم:

sudo cp /etc/rancher/k3s/k3s.yaml ~/.kube/config
sudo chown "$USER" ~/.kube/config
kubectl get node

چند node: یک server + چند agent

روی server:

curl -sfL https://get.k3s.io | sh -s - server
sudo cat /var/lib/rancher/k3s/server/node-token

روی agent:

curl -sfL https://get.k3s.io | K3S_URL=https://myserver:6443 \
  K3S_TOKEN="<NODE_TOKEN>" sh -

HA با etcd تعبیه‌شده (۳ server)

# اولین server
curl -sfL https://get.k3s.io | sh -s - server --cluster-init

# serverهای بعدی
curl -sfL https://get.k3s.io | sh -s - server \
  --server https://<first-server>:6443 \
  --token <TOKEN>

سپس agentها را به یک آدرس ثابت (VIP / LB) ثبت کنید.

روی macOS برای آزمایش

برای Linux VM سبک روی مک، مقاله Lima مفید است؛ داخل VM همان دستور get.k3s.io را اجرا کنید.

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

sudo systemctl status k3s          # server
sudo systemctl status k3s-agent    # agent

sudo journalctl -u k3s -f
k3s check-config                   # پیش‌نیازهای کرنل/سیستم

# به‌روزرسانی: معمولاً با نصب مجدد نسخه جدید باینری / اسکریپت

Uninstall:

/usr/local/bin/k3s-uninstall.sh          # server
/usr/local/bin/k3s-agent-uninstall.sh    # agent

قبل از uninstall اگر Cilium نصب کرده‌اید، اینترفیس‌های cilium_* را طبق docs پاک کنید تا شبکه host قطع نشود.

مقایسه با گزینه‌های مشابه

• k3d = K3s داخل Docker — عالی برای dev محلی سریع
• RKE2 = خواهر امنیتی‌تر Rancher برای CIS/FIPS و دیتاسنتر

ارتباط با stack شما

Edge / Lab / CI host
  └── K3s (server ± agents)
        ├── containerd
        ├── Flannel  یا  Cilium
        ├── Traefik  یا  Contour
        ├── local-path  یا  Longhorn
        ├── CoreDNS
        └── Workloads
              ├── GitOps: Argo
              ├── Mesh: Istio / Linkerd (اختیاری)
              └── Registry: Harbor

Control-plane state در حالت کلاسیک K8s با etcd است؛ در K3s تک‌node اغلب SQLite — برای HA به etcd تعبیه‌شده یا DB خارجی بروید.

Best practices

1. برای هر چیزی غیر از lab تک‌node، HA (۳ server + etcd) را جدی بگیرید
2. Traefik/ServiceLB را اگر stack دیگری دارید از روز اول --disable کنید
3. Token و k3s.yaml را مثل secret محافظت کنید
4. برای storage پایدار روی چند node به‌جای local-path از CSI واقعی استفاده کنید
5. نسخه‌های server و agent را هم‌تراز نگه دارید
6. در Edge: کانال به‌روزرسانی و air-gap را از قبل طراحی کنید
7. قبل از production: k3s check-config و backup datastore
8. Monitor کنید: metrics-server نقطه شروع است، نه تمام observability
9. اگر فقط «یک خوشه آزمایشی روی لپ‌تاپ» می‌خواهید، k3d/kind را هم مقایسه کنید
10. برای compliance سخت دیتاسنتر، RKE2 / OpenShift را هم در جدول تصمیم بگذارید

چه زمانی K3s؟

✅ استفاده کنید

• Edge، فروشگاه، کارخانه، IoT gateway
• Raspberry Pi / ARM و منابع محدود
• CI که باید Kubernetes واقعی بالا بیاورد
• تیم کوچک که kubeadm برایش سنگین است
• می‌خواهید همان YAML production را در lab داشته باشید

⚠️ شاید جای دیگر بهتر باشد

جمع‌بندی

K3s «نصف Kubernetes» نیست — Kubernetes کامل در جعبه کوچک است. تفاوت واقعی با K8s استاندارد در این است که چقدر باید خودتان CNI، Ingress، datastore و runtime را سرهم کنید.

قدم بعدی

1. روی یک VM یا Pi: curl -sfL https://get.k3s.io | sh -
2. یک Deployment + Service + Ingress Traefik تست کنید
3. یک agent دوم با token اضافه کنید
4. Traefik را disable و Contour یا Ingress دیگر را امتحان کنید
5. برای storage پایدار Longhorn را روی cluster چند node بگذارید
6. جدول تصمیم داخلی: K3s در برابر kubeadm در برابر k3d برای هر محیط (lab / edge / prod)

منابع

• K3s — k3s.io
• Architecture
• Packaged components
• Network options
• GitHub — k3s-io/k3s
• CNCF / conformance
• containerd (مقاله P30Light)
• Longhorn (مقاله P30Light)
• etcd (مقاله P30Light)

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