De meeste Kubernetes gebruikers weten wel hoe ze Environment Variabelen op een container moeten definiëren. Wat niet iedereen weet is dat je naast het hardcoden van deze variabelen ze ook op meerdere manieren uit ConfigMaps en Secrets kunt alten komen, of zelfs uit specifieke velden van je Pod zelf.

Tegenwoordig is “Kubernetes” het standaard antwoord op de vraag “Hoe moeten we dit draaien?”. Wander is het hier niet mee eens. Hoe leuk hij Kubernetes ook vind, het zou niet per definitie het goede antwoord moeten zijn. Kubernetes voegt een laag aan beheer en complexiteit toe die in veel gevallen vermeden kan worden, of in ieder geval zwaar gereduceerd tot een meer Linux-native oplossing.

Op dit kanaal hebben we in het verleden al eens gekeken naar Kyverno, een handige manier om beleid af te dwingen op Kubernetes objecten, en externe certificaten voor OpenShift Routes. Met de release van Kyverno 1.15 een aantal maanden geleden is er een aantal nieuwe policy types beschikbaar gekomen voor Kyverno die gebruiken maken van Common Expression Lanaguage (CEL), dezelfde taal die ook door Kubernetes zelf gebruikt wordt op objecten als validatingadmissionpolicies, maar ook door dingen als Tekton Webhook Triggers. CEL regels evalueren meestal sneller, en met minder resource gebruik dan traditionele Kyverno regels.