Kubernetes-upgrades zijn een van de meest onderschatte risico’s in cloud-native omgevingen. Veel teams stellen upgrades maanden uit — niet uit onverschilligheid, maar uit angst. Een mislukte control plane upgrade kan uren downtime veroorzaken, en deprecated API’s kunnen uw workloads onverwacht breken. In 2026, met Kubernetes 1.30+ als standaard, is een gestructureerde upgrade-strategie geen luxe maar een vereiste.
Waarom upgrades uitstellen gevaarlijker is dan upgraden
Elke minor versie die u overslaat, vergroot de sprong en daarmee het risico. API-deprecations stapelen zich op: wat in versie 1.27 deprecated was, is in 1.30 verwijderd. Helm charts die nog deprecated API’s gebruiken, falen silently tot u upgrade. En security patches voor container runtime en etcd worden niet backported naar oude versies.
Bij DevDock hanteren wij een N-1 beleid: productie draait maximaal één minor versie achter op de nieuwste stable release. Staging loopt altijd op de target versie minimaal twee weken voor productie volgt.
DevDock Upgrade Framework
| Fase | Activiteit | Duur | Rollback |
|---|---|---|---|
| Pre-check | API deprecation scan, Helm audit, PDB review | 1 dag | N.v.t. |
| Staging upgrade | Control plane + nodes, volledige test suite | 1-2 dagen | Snapshot restore |
| Canary nodes | 10% productie nodes upgraden, 48u monitoring | 2-3 dagen | Node drain + replace |
| Full rollout | Restante nodes, control plane final | 1 dag | Snapshot restore |
| Post-verify | API health, workload status, performance baseline | 1 dag | N.v.t. |
API deprecation check automatiseren
# Pluto — deprecated API detection
helm plugin install https://github.com/FairwindsOps/pluto
pluto detect-helm -o wide
# Kubent — deprecated API usage in cluster
kubectl apply -f https://raw.githubusercontent.com/doitintl/kube-no-trouble/master/artifacts/install.yaml
kubent
Voer deze checks uit vóór elke upgrade — niet erna. Wij integreren ze in onze maandelijkse platform review en in CI/CD pipelines als gate voor productie-deployments.
Node upgrade strategieën
Voor managed Kubernetes (EKS, AKS, GKE) gebruiken wij de provider-native rolling upgrade met surge nodes. Voor self-managed clusters implementeren wij cordon-and-drain met PodDisruptionBudgets die kritieke workloads beschermen. Altijd: snapshot etcd en persistent volumes vóór de upgrade.
Meer over ons clusterbeheer: Kubernetes & container hosting. Wilt u uw upgrade-risico’s in kaart brengen? Plan een platformscan.
DevDock Cloud Technologies B.V.
Uw contactpersoon: Sven van de Berg
Herengracht 124
1015 BT Amsterdam
Telefoon: +31 20 244 8917
E-mail: [email protected]