Kubernetes-cluster sizing voor hoge beschikbaarheid
Kort antwoord
Drie nodes is de kleinste betrouwbare basis. Gebruik voor een hoogbeschikbare control plane drie control-plane-nodes plus twee of meer workers. Reserveer, voordat je de sizing voor je workloads bepaalt, ongeveer een vijfde van de totale clustercapaciteit voor het platform zelf, etcd, de control plane en system pods.
De kleinste betrouwbare basis is drie nodes
Als je iets bouwt dat je "betrouwbaar" noemt, is drie nodes de ondergrens, niet het doel om naartoe te krimpen. Eén node heeft geen failure domain: gaat die node uit, dan valt het hele cluster uit. Twee nodes lost dat ook niet op, want de meeste consensusmechanismen (etcd inbegrepen) hebben een meerderheid nodig om te blijven werken, en een meerderheid van twee is gewoon twee.
Voor een écht hoogbeschikbare control plane is de aanbevolen opzet drie control-plane-nodes plus twee of meer worker-nodes. De drie control-plane-nodes geven etcd een quorum dat een storing van één node overleeft; de workers dragen de daadwerkelijke applicatielast en kunnen onafhankelijk van de control plane schalen.
Wat er capaciteit opeet voordat je workloads dat doen
Elk Kubernetes-cluster besteedt een deel van zijn resources aan zichzelf voordat je applicaties iets krijgen. Als planningsbasis:
- Elke control-plane-node (master) heeft ruwweg 2 tot 4GB RAM nodig voor de control-plane-componenten zelf (API server, scheduler, controller-manager, etcd).
- Elke worker-node heeft ruwweg 100 tot 300MB RAM nodig voor system pods: de CNI-agent, kube-proxy, monitoring op node-niveau en vergelijkbare componenten.
- Als vuistregel: reken op ongeveer 20% extra capaciteit in het hele cluster voor het platform zelf, bovenop wat je workloads nodig hebben.
Die 20% is geen harde grens, het verschuift afhankelijk van hoeveel add-ons en DaemonSets je draait (ingress controllers, service meshes, logging agents), maar het is een redelijk startpunt voor het sizen van worker-nodes, zodat je die overhead niet pas ontdekt nadat workloads geëvict raken.
Houd control-plane-sizing en worker-sizing gescheiden
Control-plane-nodes en worker-nodes hebben verschillende taken, en het loont om ze apart te sizen in plaats van voor beide identieke hardware te bestellen.
Control-plane-nodes worden vooral beperkt door de gevoeligheid van etcd voor schijf- en netwerklatency, en bij grotere clusters door de doorvoer van de API server. Ze hoeven niet mee te schalen met je applicatielast, alleen met het aantal objecten (pods, services, secrets) dat het cluster bijhoudt. Voor kleine en middelgrote clusters volstaat meestal een bescheiden, consistente node-grootte, en het is belangrijker dat alle drie vergelijkbaar gespecificeerd zijn dan dat één ervan bijzonder krachtig is.
Worker-nodes worden beperkt door wat je applicaties daadwerkelijk nodig hebben: CPU, geheugen, en naarmate clusters groeien en je meer pods per node stopt, steeds vaker ook het aantal cores. Naarmate een cluster groeit van een handvol services naar een grotere omvang, is het normaal dat de specificaties van worker-nodes onafhankelijk van de control plane omhoog (of uit) schalen; de control plane blijft doorgaans relatief bescheiden, ook als de rest van het cluster meegroeit.
Een basispatroon voor HA-sizing
| Clustergrootte | Control plane | Workers | Opmerkingen |
|---|---|---|---|
| Kleinste betrouwbare opzet (HA) | 3 nodes | 2+ nodes | De ondergrens voor een cluster dat je productiewaardig zou noemen |
| Kleine productieomgeving | 3 nodes, bescheiden specificatie | 3 tot 5 nodes | Ruimte om een worker te verliezen zonder capaciteitsdruk |
| Groeiend / middelgroot | 3 nodes, consistente specificatie | Geschaald naar workload, stapsgewijs uitgebreid | De control plane hoeft meestal niet even snel te groeien als de workers |
Welke omvang je ook kiest, houd de 20% platform-overhead en de bovenstaande cijfers per node voor control plane en system pods vanaf het begin mee in je sizing. Achteraf ruimte inbouwen in een cluster dat al krap zit qua capaciteit, is voor iedereen vervelender dan het vooraf goed plannen.
Meer dan alleen het aantal nodes
Het aantal nodes en de sizing van een hoogbeschikbare control plane zijn het startpunt, niet het hele verhaal. Zodra je voorbij de minimale basis bent, gaat gangbare Kubernetes-praktijk ook over zaken als replica's spreiden over nodes met pod anti-affinity, PodDisruptionBudgets instellen zodat gepland onderhoud niet in één keer een hele service platlegt, en storage-zware of stateful workloads scheiden van de rest van de scheduling pool. Zie Omgaan met stateful services in containers voor het state-specifieke deel daarvan.