Kubernetes is open source, en uw eigen cluster draaien is een legitieme keuze. Wat de moeite waard is om in detail te bekijken, is wat een productiecluster doorlopend van u vraagt — op basis van de eigen documentatie en het releasebeleid van het Kubernetes-project, niet op basis van marketingclaims.
Elke Kubernetes-versie heeft een houdbaarheidsdatum
Het Kubernetes-project onderhoudt releasebranches voor de drie meest recente minor releases. Elke minor release krijgt ongeveer veertien maanden patchondersteuning: twaalf maanden standaardondersteuning, gevolgd door een onderhoudsperiode van twee maanden, waarna de reeks end-of-life bereikt en geen fixes meer ontvangt.
Per september 2026 zijn de actief onderhouden minor releases 1.37, 1.36 en 1.35. Versie 1.34 zit in zijn laatste onderhoudsvenster en bereikt end-of-life op 27 oktober 2026. Versie 1.33 bereikte al end-of-life op 28 juni 2026.
Achterblijven is duur, want upgrades mogen geen minor versies overslaan. Het version-skew-beleid vereist dat kube-apiserver telkens één minor versie opschuift, ook in clusters met één instantie. Een cluster dat nog op 1.33 draait, heeft dus vier opeenvolgende control-plane-upgrades nodig — 1.34, 1.35, 1.36 en 1.37 — om weer actueel te zijn, en elke upgrade vraagt om eigen voorbereiding, bijvoorbeeld controleren of uw admission webhooks de API-versies aankunnen die de nieuwe server ze stuurt.
Nodes brengen extra werk mee. Minor-versie-upgrades van kubelet ter plekke worden niet ondersteund: elke node moet eerst worden gedraineerd. Een kubelet mag tot drie minor versies achterlopen op de API-server, maar de documentatie waarschuwt dat een cluster met kubelets die permanent drie versies achterlopen deze moet upgraden voordat het control plane überhaupt kan doorschuiven.
Hoge beschikbaarheid is een ontwerp waarvoor u zelf verantwoordelijk bent
Eén control-plane-node is een single point of failure. De high-availability-gids van kubeadm beschrijft twee topologieën. In de standaard gestapelde topologie draait elke control-plane-node ook een etcd-lid, dus het verlies van één node betekent het verlies van zowel een control-plane-instantie als een etcd-lid; de documentatie zegt dat u minimaal drie gestapelde control-plane-nodes moet draaien. Het alternatief, externe etcd, scheidt de twee maar vereist minimaal drie control-plane-hosts plus drie etcd-hosts.
etcd heeft een quorum nodig — een meerderheid van zijn leden — om wijzigingen te accepteren. Een cluster met drie leden verdraagt het uitvallen van één lid en een cluster met vijf leden van twee, terwijl het toevoegen van een vierde lid geen extra storingstolerantie oplevert. De Kubernetes-documentatie beveelt een oneven aantal leden en een cluster met vijf leden voor productie aan.
etcd is bovendien gevoelig voor de omgeving waarin het draait:
- Schijf en netwerk. De prestaties van etcd hangen af van schijf- en netwerk-I/O. Een tekort aan resources kan heartbeat-timeouts veroorzaken en het cluster zonder leader achterlaten — en een cluster zonder leader kan zijn status niet wijzigen, wat betekent dat er geen nieuwe pods meer kunnen worden ingepland.
- Dedicated resources. De documentatie adviseert etcd op dedicated machines of geïsoleerde omgevingen te draaien, zodat de benodigde resources gegarandeerd zijn, en de eigen FAQ van etcd raadt SSD's sterk aan.
- Toegang staat gelijk aan root. Toegang tot etcd is gelijk aan root-rechten in het cluster, dus idealiter kan alleen de API-server erbij, beveiligd met x509-TLS-certificaten.
Een back-up telt pas als u eruit hebt hersteld
De Kubernetes-documentatie is duidelijk: als uw cluster etcd als backing store gebruikt, zorg dan voor een back-upplan voor die gegevens. In de praktijk betekent dat geplande snapshots met etcdctl, opgeslagen op een plek die geen faaldomein deelt met het cluster, en een herstelprocedure met etcdutl die iemand daadwerkelijk heeft ingeoefend.
Snapshots vragen ook om zorgvuldige omgang, omdat ze alles bevatten wat de API-server weet. Standaard slaat de API-server resources in etcd op als platte tekst, zonder versleuteling in rust, tenzij u dit configureert. Een snapshot van een onversleuteld cluster kan dus uw Secrets bevatten.
Certificaten verlopen volgens een schema
Clientcertificaten die door kubeadm worden gegenereerd, verlopen na een jaar. kubeadm vernieuwt ze automatisch wanneer u het control plane upgradet, dus een cluster dat minstens één keer per jaar wordt geüpgraded, is in orde — en een cluster dat meer dan een jaar zonder upgrade blijft, niet. U kunt de vervaldatum controleren met kubeadm certs check-expiration en handmatig vernieuwen met kubeadm certs renew all, wat bij een gerepliceerd control plane op elke control-plane-node moet worden uitgevoerd.
De add-ons zijn aparte projecten met eigen levenscycli
Een cluster is meer dan zijn control plane. Netwerken, ingress of Gateway API, storage drivers, certificaatbeheer, metrics en monitoring zijn aparte projecten, elk met een eigen releasecyclus, eigen versies en eigen end-of-life-data. Op een zelf gehost cluster is het bijhouden van al die onderdelen uw taak.
In november 2025 kondigde het Kubernetes-project de uitfasering aan van Ingress NGINX, een van de meest gebruikte ingress controllers. Onderhoud op best-effortbasis eindigde in maart 2026: er zijn geen nieuwe releases, bugfixes of beveiligingsupdates meer. Bestaande deployments blijven werken en de artefacten blijven beschikbaar, maar elke kwetsbaarheid die later wordt ontdekt, wordt niet meer gepatcht. In januari 2026 omschreven de Kubernetes Steering en Security Response Committees het als kritieke infrastructuur voor ongeveer de helft van de cloud-native omgevingen en riepen ze op om te migreren naar Gateway API of een andere controller.
De eigen migratiegids van het project voegt een waarschuwing toe: Ingress NGINX heeft impliciet gedrag, en een vertaling die correct lijkt, kan toch storingen veroorzaken. Niets hiervan is een tekortkoming van Kubernetes. Het is het normale leven van een groot open-sourceecosysteem — en precies het werk dat een zelf gehost cluster op uw team afwentelt.
Zij-aan-zij vergelijking
| Categorie | Zelf gehost | Kube-DC beheerd cluster |
|---|---|---|
| Versielevenscyclus | U houdt release- en end-of-life-data bij en upgradet één minor versie tegelijk, met ongeveer veertien maanden ondersteuning per minor release | Gefaseerde, door de tenant beheerde upgrades: het control plane en de worker pools schuiven afzonderlijk door, stap voor stap. U kiest nog steeds de doelversie en het moment |
| Control plane | Drie of meer control-plane-nodes die u zelf ontwerpt, beveiligt en patcht | Gehoste control planes draaien als beheerde pods op het platform: u krijgt uw eigen Kubernetes-API en PKI per cluster zonder masters te beheren |
| etcd | Quorumdimensionering, dedicated schijven, TLS, defragmentatie en monitoring zijn aan u | Een dedicated of gedeelde datastore die door het platform wordt beheerd, met verticale autoscaling van control plane en etcd standaard ingeschakeld |
| Back-ups | U ontwerpt het snapshotschema, de opslag en de herstel-oefeningen | Geplande etcd-snapshots, per cluster te configureren, met optionele envelopversleuteling, en herstel — self-service voor datastores met één replica, ondersteund voor meerdere replica's. Snapshots worden opgeslagen in de S3-opslag van het project op het platform, dus bewaar uw eigen kopie buiten het platform als u er een nodig hebt buiten het storingsdomein van de platformopslag |
| Certificaten | Kubeadm-certificaten met een jaar geldigheid, vernieuwd bij een upgrade of door u | PKI per cluster en etcd-TLS-certificaten worden automatisch met het cluster geprovisioneerd |
| Worker nodes | U provisioneert, imaget, patcht en vervangt nodes | Worker pools, per pool gedimensioneerd (CPU, geheugen, schijf, image), met autoscalinggrenzen per pool |
| Metrics-API | U installeert en onderhoudt metrics-server | Vooraf geïnstalleerd en werkend in onze eigen end-to-endtest van augustus 2026 |
| Tijd tot het eerste cluster | Uren tot dagen aan set-up, plus doorlopend onderhoud | Aangemaakt vanuit een project in het portaal of met één manifest; de platformdocumentatie beschrijft provisioning in enkele minuten |
| Storingsdienst | Uw team | 24/7 support via e-mail en tickets met een oplostijddoel van 4 uur (MTTR), inbegrepen in de prijs |
| Wat van u blijft | Alles, van hardware tot workloads | Uw workloads, toegangsbeheer en de add-ons die u in uw cluster installeert — het is een volwaardig, door de tenant beheerd Kubernetes-cluster |
Wanneer zelf hosten de juiste keuze is
Als uw team al etcd in productie draait, de releasenotes van Kubernetes en add-ons volgt, herstel-oefeningen doet en over een storingsdienst beschikt, is zelf hosten een redelijke uitbreiding van bestaande praktijk. Het is ook de juiste keuze wanneer u controle nodig hebt die een beheerde dienst niet kan bieden, zoals een aangepaste control-plane-configuratie of een volledig geïsoleerde omgeving. Voor een team dat die capaciteit nog niet heeft, wordt elk bovenstaand onderdeel nieuw, doorlopend werk.
Bronnen
- Kubernetes releases and patch support policy
- Kubernetes patch releases: support period
- Kubernetes version skew policy
- kubeadm: options for highly available topology
- Operating etcd clusters for Kubernetes
- etcd FAQ: cluster size and failure tolerance
- Encrypting confidential data at rest
- Certificate management with kubeadm
- Ingress NGINX retirement: what you need to know
- Ingress NGINX: statement from the Steering and Security Response Committees
- Kube-DC platform datasheet
Ontdek het platform
Cloud Acropolis Kube-DC geeft u uw eigen door de tenant beheerde Kubernetes-clusters — gehoste control planes, worker pools en gefaseerde upgrades — op dedicated vCPU, op Ceph gebaseerde NVMe-opslag, een dedicated publiek IPv4-adres en S3-compatibele objectopslag. U bestelt en beheert alles in een self-serviceportaal, met 24/7 support via e-mail en tickets en een oplostijddoel van 4 uur inbegrepen. Elk pakket bevat geneste Kubernetes-clusters, en gedeelde GPU is als optie beschikbaar.
Ontdek Kube-DC Kubernetes