Kubernetes is sinds versie 1.31 volledig vendor-neutraal, gedreven door de grootste codemigratie die het Kubernetes-project ooit heeft moeten uitvoeren.
Deze versie van Kubernetes hebben we eerder al uitgebreid omschreven. Toch is het goed om nog even stil te staan bij de transitie die nu voltooid is binnen de populaire technologie. “In-tree integration” van de grootste vijf cloudproviders is vanaf nu verleden tijd. De kerncode van Kubernetes staat voortaan los van AWS, Azure, Google Cloud, OpenStack en VMware vSphere. Hierdoor is de codebase gekrompen, wat de wendbaarheid en ontwikkeltijd voor toekomstige updates versimpelt.
Dit levert echter ook uitdagingen op. De adoptie van Kubernetes-versies gaat zeer geleidelijk, deels gevoed door het feit dat er geen inherente security-laag zit ingebouwd en een update dus zelden uit veiligheidsoverwegingen uitkomt. Kortom: eindgebruikers hebben nog de tijd om zich te voegen naar de veranderingen binnen 1.31. Voor velen zijn de benodigde veranderingen allang verricht, aangezien ondersteuning voor OpenStack (1.26) en AWS (1.27) al was weggevallen. Separate componenten zijn vereist om de verbinding met een specifieke cloud te maken; soms zijn dat externe cloud controller managers. De migraties zijn goed gedocumenteerd en eenvoudig te volgen.
Nodige stap
Het is een logische en ook nodige stap voor Kubernetes om daadwerkelijk vendor neutral te zijn. Het voortrekken van de meest gebruikte cloudspelers past niet bij een algemene tool die door meer dan 60 procent van enterprise-organisaties is geadopteerd. Hoewel Kubernetes is geboren in de cloud, is gebruik van cloud native tools inmiddels ook ingeburgerd in on-prem omgevingen. Een zo licht mogelijke Kubernetes-laag past daar nu eenmaal bij.
Daarnaast past het bij de richting waarin Kubernetes zich beweegt, met modulaire componenten die zich onafhankelijk kunnen ontwikkelen. Dat gold al voor securitymiddelen, die broodnodig maar extern zijn voor Kubernetes. Een recent voorbeeld van deze decentralisering is de Gateway API, dat los zal worden geüpdatet van de Kubernetes-versies.
Echte hybrid cloud
De volgende stap voor Kubernetes is om hybride omgevingen beter te benutten. De tool moet ‘slimmer’ worden door te herkennen wnneer nodes in een cluster in een public of in een private cloud kunnen draaien. Daarnaast gaat het team achter Kubernetes verder werken aan het integreren met andere clouds via betere tools en frameworks. Zo wordt dat proces gestandaardiseerd in plaats van dat het binnen Kubernetes zelf moet zitten en bijgehouden moet worden.
Die stap naar een échte hybrid cloud zonder al te veel handwerk klinkt als de meest veelbelovende. Als basistechnologie voor de cloud native wereld levert dit voor ontwikkelaars een stuk minder kopzorgen op, en vermoedelijk voor organisaties een stuk minder kosten.
Lees ook: CAST AI inroduceert KSPM voor detectie Kubernetes-securitydreigingen