KRO
Kubernetes is de onbetwiste standaard voor container orchestration, maar de complexiteit ervan kan overweldigend zijn. Platformteams zijn daarom continu op zoek naar manieren om die onderliggende complexiteit te verbergen, zodat developers zich volledig kunnen richten op het schrijven van code. Het Kubernetes Resource Orchestrator (KRO)-project is één van de nieuwste en meest veelbelovende antwoorden op deze uitdaging.
Wat is KRO?
In de kern is KRO een open-source controller die direct binnen je Kubernetes-cluster draait en fungeert als een krachtige abstractielaag. In plaats van het handmatig beheren van losse Deployments, Services en Ingress-regels, maakt KRO het mogelijk om deze te bundelen in één logische, herbruikbare eenheid: een ResourceGraphDefinition (RGD).
Zie een RGD als de “blauwdruk” van je applicatie. Zodra je deze code in het cluster deployt, neemt KRO het over en automatiseert het werk dat normaal gesproken handmatig moet worden gedaan.
- Automatische aanmaak van CRD’s: KRO genereert de benodigde Custom Resource Definitions (CRD’s) op basis van jouw definitie
- Een slimme in-cluster controller: een dedicated controller monitort de volledige applicatie en zorgt ervoor dat alle resources up-to-date blijven.
- Intelligente dependency-afhandeling: KRO begrijpt onderlinge relaties en weet precies in welke volgorde resources moeten worden aangemaakt. Dit voorkomt vervelende race conditions die vaak voorkomen bij handmatige deployments.
- Flexibele configuratie: je kunt defaultwaarden, afhankelijke velden en zelfs waarden over verschillende resources heen doorgeven met CEL, waardoor je manifests krachtiger en beter herbruikbaar worden.
KRO maakt gebruik van CEL (Common Expression Language), wat zorgt voor voorspelbaardere en veiligere resultaten dan de Go templating language van Helm. Dit is een bewuste keuze: waar Go templating zeer krachtig is en willekeurige logica kan uitvoeren (wat ook risico’s met zich meebrengt), is CEL beperkt tot het evalueren van eenvoudige, veilige expressies. Hierdoor is het systeem fundamenteel veiliger en zijn de uitkomsten van deployments zeer voorspelbaar. Deze aanpak verlaagt de instapdrempel aanzienlijk en maakt het implementeren van operators een stuk eenvoudiger.
Toekomstperspectief
KRO klinkt veelbelovend en heeft het potentieel om de complexiteit van applicatiedeployments drastisch te verminderen. Wel is er een belangrijke kanttekening: KRO is nog volop in ontwikkeling en moet worden beschouwd als een alpha product. Hoewel het nog niet geschikt is voor bedrijfskritische productieomgevingen, geeft het wel een duidelijk inkijkje in de vereenvoudiging die het kan brengen binnen het Kubernetes-ecosysteem.
Talos Linux
Een andere opvallende ontwikkeling is de groeiende populariteit van Talos Linux van Sidero Labs, een Linux-distributie die specifiek is ontworpen voor het draaien van Kubernetes. Met Talos is traditioneel Linux-beheer niet langer nodig, waardoor je je volledig kunt richten op het beheren van Kubernetes.
Een paar belangrijke inzichten:
- Immutable: er draait geen SSH-daemon op de host; je kunt dus niet inloggen. De node wordt geconfigureerd via een declaratief YAML-bestand. Daarna is de node immutable. Elke node in je cluster blijft identiek, waardoor “configuration drift” wordt voorkomen. Uiteraard kun je de node nog steeds benaderen voor reboots en andere noodzakelijke acties. Dit markeert de verschuiving van “pets” naar “cattle”.
- API-gedreven: in plaats van in te loggen op een server beheer je nodes via de Kubernetes API. Dit sluit naadloos aan op de manier waarop je al met Kubernetes werkt. Alle beheer- en onderhoudstaken, inclusief updates en reboots, worden uitgevoerd via API-calls. Dit vereenvoudigt automatisering en maakt het mogelijk om infrastructuur als code te behandelen.
- Veiliger en voorspelbaarder: het minimalistische ontwerp van Talos zorgt voor een zeer klein aanvalsoppervlak. Minder componenten en services betekenen minder kwetsbaarheden. Geen shell of SSH-toegang betekent dat veel gangbare aanvalsvectoren simpelweg niet bestaan. Updates zijn atomair, wat de kans op fouten verkleint. Het resultaat is een robuuster en voorspelbaarder platform, met aanzienlijk minder risico op menselijke fouten.
Uit presentaties en praktijkvoorbeelden blijkt duidelijk dat veel organisaties Talos gebruiken als een solide basis onder hun clusters. Het elimineert node-specifieke configuratie-eigenaardigheden. In plaats daarvan krijg je een schoon, betrouwbaar OS dat precies doet wat nodig is en niets meer dan dat. Door te kiezen voor Talos Linux neem je de complexiteit van Linux-beheer weg en kun je je volledig focussen op het efficiënt draaien van Kubernetes workloads.
Gateway API
Daarna volgde de talk van Traefik Labs over de Gateway API, een fascinerend en sterk toekomstgericht onderwerp.
Tot nu toe was Ingress de standaardmanier om applicaties binnen Kubernetes beschikbaar te maken. Dat werkt, maar vereist al snel complexe annotaties. Het resultaat: uitwaaierende regels in één enkel bestand, wat leidt tot chaos en onduidelijkheid.
De Gateway API is de opvolger en lost dit probleem definitief op. Dit is waarom het de toekomst is:
- Duidelijke rollen: verantwoordelijkheden zijn helder gescheiden. Admins beheren de infrastructuur (Gateway), terwijl developers de routes naar hun applicaties beheren (HTTPRoute). Geen discussies meer over wie waarvoor verantwoordelijk is.
- Standaardisatie: vendor-specifieke annotaties verdwijnen. De Gateway API definieert standaardregels voor features zoals traffic splitting en header-based routing. Configuraties worden daardoor portable over verschillende vendors.
- Meer controle: de Gateway API biedt fijnmazigere controle over al het verkeer, zowel inkomend als uitgaand.
Traefik Labs omarmt de Gateway API volledig. Wij zien hoe deze aanpak de complexiteit van Ingress wegneemt en de weg vrijmaakt voor een schonere, veiligere en krachtigere cloud-native networking-toekomst. In vergelijking met een CNI-oplossing zoals Cilium, die de Gateway API integreert in een compleet networkingplatform, richt Traefik zich op waar het in uitblinkt: een gespecialiseerde, intelligente en gebruiksvriendelijke reverse proxy.
Common Expression Language (CEL)
Een hot topic na de recente introductie van ValidatingAdmissionPolicies en MutatingAdmissionPolicies in Kubernetes.
Deze nieuwe, native features draaien direct in de API server en elimineren daarmee de risico’s van externe webhooks. Policies kunnen nu declaratief worden beheerd met de Common Expression Language (CEL). Voorbeelden hiervan zijn het blokkeren van :latest images of het afdwingen van resource limits en labels. Dit zorgt voor een aanzienlijke verbetering van zowel security als efficiëntie.
Een meer geavanceerd voorbeeld is het instellen van een limiet op het aantal replicas, zoals hieronder weergegeven.
Hoewel dit een grote stap vooruit is, blijven tools zoals Kyverno, OPA Gatekeeper en Kubewarden essentieel voor complexe scenario’s, dankzij hun rijkere functionaliteit en abstracties. Tegelijkertijd is het duidelijk: voor basaal policy management zal Kubernetes zelf binnenkort voldoende zijn.
CEL zorgt voor een toekomst van Kubernetes security die lichter, veiliger en sterker geïntegreerd is dan ooit tevoren.
See you next year!
ContainerDays was opnieuw een bevestiging dat de Kubernetes-community nooit stilstaat. Van het fundamenteel veiliger maken van onze clusters met Talos Linux en CEL tot het vereenvoudigen van deployments met KRO: we zijn klaar voor de volgende fase van Cloud-Native engineering. Deze inzichten vormen de basis voor onze aankomende projecten en zorgen ervoor dat de platforms die we bouwen future-proof zijn en van de hoogste kwaliteit. Het waren een paar ongelooflijke dagen. Tot volgend jaar!
