Ako sme prešli na k3s a prečo to dáva zmysel
Po troch rokoch s plným Kubernetes sme prešli na lightweight distribúciu. Dôvody, prekvapenia a čísla.
Pred troma rokmi sme si nasadili plný Kubernetes na sadu vlastných serverov. Bola to dobrá voľba — vtedy. Mali sme tím, ktorý vedel, čo robí, a aplikácie, ktoré z toho ťažili.
Postupom času sa však ukázalo, že väčšinu toho, čo Kubernetes ponúka, sme vôbec nevyužívali. A údržba samotného control-plane začala zaberať viac času než prevádzka aplikácií, ktoré na ňom bežali.
Prečo k3s
k3s je distribúcia Kubernetes od Rancher Labs, ktorá vmestí celý cluster do jediného binárneho súboru. Žiadne samostatné etcd, žiadny oddelený kube-proxy, žiadna hodinová inštalácia.
# single-node install
curl -sfL https://get.k3s.io | sh -
sudo k3s kubectl get node
# NAME STATUS ROLES AGE VERSION
# infra01 Ready control-plane,master 42s v1.30.2+k3s1
Štyridsaťdva sekúnd. Predtým nám kubeadm init s prípravou etcd clustra trval dobrých dvadsať minút — a to sme mali Ansible rolu, ktorá to robila za nás.
Čo sme museli zmeniť
Nie je to úplne bezbolestné. Tri veci nás zdržali:
- Traefik namiesto ingress-nginx. k3s prichádza s Traefikom out of the box. Dá sa vypnúť (
--disable traefik), ale my sme sa rozhodli migrovať anotácie. Trvalo to pol dňa. - local-path-provisioner namiesto Ceph RBD. Pre stateful workloady sme si museli premyslieť, čo naozaj potrebuje sieťové úložisko. Ukázalo sa, že len databázy — a tie sme presunuli mimo clustra.
- SQLite namiesto etcd. Pre single-node je to fajn. Pre HA setup treba embedded etcd alebo externú DB. My sme zvolili embedded etcd na troch nodoch.
Najlepší kód je ten, ktorý nemusíš písať. Najlepšia infraštruktúra je tá, ktorú nemusíš spravovať.
Čísla
Merania sú z produkčného clustra, tri nody, rovnaký hardware pred aj po migrácii.
| Metrika | Pred (kubeadm) | Po (k3s) |
|---|---|---|
| RAM, control plane idle | 2.1 GB | 480 MB |
| Doba bootu nodu | ~120 s | ~55 s |
Podov v kube-system | 14 | 6 |
| Mesačné CPU minúty | baseline | −38 % |
Rozdiel v RAM bol najväčšie prekvapenie. Uvoľnené 1.6 GB na node znamenalo, že sme na tie isté stroje zmestili o polovicu viac aplikačných podov.
Kedy k3s nie je dobrá voľba
- Ak beží viac než ~100 podov na cluster a rastiete ďalej.
- Ak potrebujete cloud-provider integrácie (AWS ELB controller, EBS CSI a pod.).
- Ak máte compliance požiadavku na konkrétnu certifikovanú distribúciu.
- Ak vám niekto iný platí za správu control-plane. Vtedy je EKS/GKE lacnejší z pohľadu vášho času.
Záver
Pre nás to bola jasná výhra. Menej pohyblivých častí, rýchlejšie recovery, nižšia spotreba. A hlavne — celý cluster vieme obnoviť z jedného shell skriptu a zálohy, čo sa o predchádzajúcom setupe povedať nedalo.
Ak máte pod 50 podov a nemáte špecifické požiadavky na HA control plane, skúste to. Inštalácia trvá minútu, odinštalovanie tiež.