Kubernetes versie 1.31 staat gepland voor 13 augustus. Deze open-source container orkestratietechnologie wordt tegenwoordig op grote schaal ingezet. Oorspronkelijk ontwierp Google het in 2014. Het werd ondergebracht bij de Cloud Native Computing Foundation (CNCF), opgericht om de technologie te verspreiden. Kubernetes-releases komen momenteel drie keer per jaar uit en de levenscyclus van elke verbetering valt uiteen in drie centrale fasen: definitie, implementatie en stabilisatie. Nu Kubernetes versie 1.31 klaar is om deel uit te maken van de operationele cloud-stack in bedrijven overal ter wereld, waar moeten we dan aan denken met betrekking tot het huidige pad van deze fundamentele technologie?
De Kubernetes-projectpagina’s vertellen ons dat dit een open-source en wendbaar project is, waarbij de planning en implementatie van functies voortdurend plaatsvindt. Gezien de schaal van het project en de wereldwijd verspreide ontwikkelaarsbasis, is het cruciaal voor de snelheid van het project om niet te vertrouwen op een “slepende stabilisatiefase”… In plaats daarvan werkt het project met “continue integratietesten”. Deze zijn ontworpen om de technologie altijd stabiel te krijgen. Zo kunnen individuele commits gemarkeerd worden als iets kapot is.
Kubernetes-versies zijn logisch gelabeld onder de numerieke naamgevingsconventie x.y.z, waarbij x de hoofdversie is, y de kleine versie en z de patchversie.
Red Hat: nieuwe workloads
“Red Hat is enthousiast over de release van Kubernetes 1.31”, zegt Mike Barrett, VP en general manager van Red Hat Hybrid Platforms. “Velen in onze community geloven dat Kubernetes oorspronkelijk is ontworpen voor de webservices en de bestaande applicatiepatronen van de wereld. Dit jaar zijn AI en machine learning echter naar voren gekomen als belangrijke nieuwe workloads. Die stellen andere eisen aan het Kubernetes-platform.”
In Kubernetes 1.31 ziet Barrett verbeteringen in de Dynamic Resource Allocation (DRA) implementatie, die het aanvragen en delen van machine-level resources zoals GPU’s in een gedistribueerd systeem vereenvoudigt.
“Verbeteringen in GPU-beheer, apparaatselectie en scheduler-gedrag verbeteren de coördinatie tussen gebruikers en beheerders”, zegt hij. “Daarnaast maken Custom Resource Field Selectors en Authorize with Selectors het mogelijk om specifieke nodes veilig te targeten voor hardwareversnellers, wat cruciaal is voor inference-workloads. Deze functies zorgen er samen voor dat Kubernetes 1.31 beter in staat is om AI workloads veilig te draaien, een ontwikkeling waar we erg enthousiast over zijn.”
Craig Box, senior director of developer relations bij Solo & CNCF bestuurslid is ook enthousiast. Hij suggereert dat het volwassen ontwerp van Kubernetes als host voor API’s betekent dat de gemeenschap veel van haar werk buiten de reguliere release-cyclus kan doen.
Itereren in je eigen tempo
“Een van de grootste verbeteringen aan Kubernetes in de afgelopen vijf jaar is de Gateway API; deze is ontworpen als een ‘ingress v2’. Het is ontwikkeld als een externe API, in plaats van strak gekoppeld te zijn aan de kern”, aldus Box. “Dat betekent dat het op zijn eigen tempo kan evolueren. Versie 1.1 werd uitgebracht tussen Kubernetes 1.30 en 1.31 in. Het kan geïnstalleerd worden op elk van de vijf meest recente versies van Kubernetes, waardoor gebruikers minder vaak clusters hoeven te upgraden om de nieuwe functies te kunnen gebruiken. Aan boord gaan met de Gateway API vereenvoudigt de configuratie van service mesh en betekent dat je één taal kunt gebruiken om tientallen ondersteunde projecten te configureren.”
Hoofd developer relations bij New Relic Jemiah Sius sluit zich aan bij Box. Hij zegt dat om de adoptie en het gebruik van Kubernetes 1.31 te verbeteren, het verminderen van de complexiteit en het verlagen van de toetredingsdrempel een topprioriteit moet zijn. Het is volgens hem de sleutel voor het aantrekken van de nog wat minder ervaren gebruikers.
“Door functies te introduceren zoals verbeterde standaardconfiguraties, voortdurende verbetering van documentatie, gestroomlijnde implementatieprocessen en geavanceerde securitymaatregelen, kan Kubernetes toegankelijker worden voor nieuwe gebruikers. Dit terwijl het doorgewinterde professionals de tools biedt om robuuste en veerkrachtige applicaties te bouwen en te onderhouden. Verbeteringen in schaalbaarheid, multi-cluster management en native ondersteuning voor serverless workloads zullen de adoptie in verschillende industriële sectoren verder stimuleren,” stelt Sius.
Een Kubernetes-wishlist
Voor veel ontwikkelaars was de meest ‘gemiste feature’ tot nu toe de sidecar container-aanduiding. Deze werd beschikbaar gemaakt in versie 1.29. We kunnen nu ook constateren dat volume snapshots al beschikbaar zijn als CRD’s, maar alleen voor CSI drivers. Nadenkend over wat hij graag zou willen zien, zegt medeoprichter en CTO van Daytona Vedran Jukic dat cross-cluster netwerken nu mogelijk zijn via kubefed of een service mesh, maar ingebouwd multi-cluster beheer zou een geweldige toevoeging zijn.
“Daarnaast zijn zero trust networking, betere auditing en rapportage altijd doelen om naar te streven. Ik zou graag de mogelijkheid hebben om de Storage Class van bestaande Persistent Volumes (PV’s) te wijzigen en een verbeterde afhandeling van stateful workloads in termen van schalen en updaten,” zegt Jukic. “Wat betreft volume back-ups, het opzetten en beheren van volume snapshots en back-ups in Kubernetes: dat vereist vaak tools van derden en uitgebreide configuratie, die native automatisering voor routinetaken missen. Hoewel Kubernetes een VolumeSnapshot API heeft, zou meer robuuste en functierijke native ondersteuning nuttig zijn, inclusief betere integratie met verschillende opslagproviders.”
Zijn opmerkingen vinden ook weerklank bij Rashmi Agrawal, vice president of engineering for application modernization bij Rocket Software. Agrawal merkt op dat ‘wij’ [ontwikkelaars] tegenwoordig sterk afhankelijk zijn van Kubernetes Clusters voor het bouwen en onderhouden van testomgevingen voor zakelijke producten bij verschillende cloudproviders, maar heeft nog steeds een oog op de toekomst voor deze technologie.
Een meer cloudneutrale toekomst
“De prestatie-optimalisaties die Kubernetes 1.31 met zich meebrengt, zullen ons helpen om de algehele inzet van onze testomgevingen schaalbaarder en efficiënter te maken. Dit met name in termen van resourcegebruik en responstijden, waardoor de algehele productiviteit zal verbeteren”, zegt hij. “Daarnaast helpen verfijnde observability tools met deze nieuwe versie ons om onze clusterimplementaties beter te onderhouden en te monitoren. Met 1.31 zou Kubernetes nog cloudneutraler zijn, wat ons zou helpen om iets te bouwen voor onze klanten. Dat helpt om implementaties van onze producten over de infrastructuur van verschillende cloud providers effectiever en sneller te laten verlopen. Security-verbeteringen in deze versie moeten ons helpen met compliance-activiteiten.”
Deze opmerkingen omtrent een (nog) meer alomtegenwoordige Kubernetes sturen aan op één punt. Het duwt de technologie naar een nog opener universum van open-source dat Kubernetes laat evolueren naar een meer cloudneutrale status. Dit is iets dat al gebeurt sinds versie 1.26 en dat is een goede zaak.
Als deze progressie samengaat met het door de community aanpakken van de gestelde complexiteit, dan kunnen we echt gaan bepalen waar Kubernetes naartoe gaat. Als Kubernetes cloudneutraal is en zich niet langer te binden aan specifieke cloudplatforms met de propriëtaire codeverantwoordelijkheden die dat met zich meebrengt… dan kan Kubernetes misschien echt de open zeeën bevaren.
Lees ook: Hoe Kubernetes in tien jaar tijd de cloud heeft veroverd
