Argo Rollouts op OpenShift

Met Argo Rollouts kun je Deployment objecten vervangen door Rollout objecten die meer controle geven over hoe updates aan een Deployment uitgerold worden. Langzaam aan met Canaries, atomisch met Green-Blue changeover, en meer. Dit alles kan automatisch gebeuren, met handmatige promotie stappen, combinaties daarvan, en zelfs met probes die kijken of een nieuwe versie goed werkt.

Één van de uitdagingen die wij vaak zien bij klanten op het gebied van platform management is het “right-sizen” van applicaties; Het goed zetten van de requests en limits voor applicaties zodat ze altijd aan resources kunnen gebruiken wat ze nodig hebben, maar niet onnodig veel aanvragen dat niet door de rest van de applicaties op het cluster gebruikt kan worden.

Naast educatie van applicatie teams, een belangrijke stap, kan het ook handig zijn om teams (geautomatiseerde) adviezen te geven over de “juiste” instellingen voor hun applicaties. Een tool die daarbij kan helpen is de Vertical Pod Autoscaler van OpenShift.

Met de release van OpenShift 4.17 is er een feature in Technology Preview gekomen waar Wander al heel lang op zat te wachten: User Namespaces.

User Namespaces hebben niks te maken met Kubernetes Namespaces, maar met Linux Kernel Namespaces. Met User Namespaces kan een container een ander idee hebben van wat user ids zijn dan het onderliggende OS. Zo kan een proces in een container denken root te zijn, en alle rechten hebben (binnen de container) die daarbij horen, maar buiten de container stiekem een ander UID hebben. Dit is hetzelfde principe als met Rootless Podman, maar nu beschikbaar (als beta) op Kubernetes, en dus ook op OpenShift.

Met deze feature hoeven cluster beheerders minder vaak uitzonderingen te maken voor onder andere COTS applicaties door toegang to verlenen tot de anyuid of nonroot Security Context Constraints (SCC), wat kan leiden tot een beter security posture.

In de Kubernetes wereld is “Kustomize” één van de handigste manieren om met je manifesten om te gaan als je naar meerdere omgevingen of life cycle fases wilt uitrollen. Het is niet voor niks dat de basis-functionalieit van Kustomize ook in het kubectl en oc commando zit ingebakken.

Naast alle ingebouwde transformatie die Kustomize kan uitvoeren op zaken als replicas, images, labels, etc. is er ook een ingebouwde transformer die patches kan uitvoeren, zowel Strategic Merge patches die misschien kent van kubectl apply als JSON6902 patches zoals bekend van kubectl patch.

Vorige week hebben we met jullie gekeken naar een interactieve tutorial over het schrijven van je eerste Containerfile. Deze week bouwen we verder op die kennis, en willen we jullie via een nieuws scenario kennis laten maken met “Multi-Stage Builds”.

Op dit kanaal hebben we het vaak over containers en container-gerelateerde zaken zoals Kubernetes. Één van de dingen die we daarentegen nog nooit besproken hebben is de basis van het zelf maken van containers en container images.

Deze week gaan we hier wat nieuws mee uitproberen, in plaats van een video met uitleg, en eventueel wat source-code, krijgen jullie een interactieve leeromgeving met instructies waar je de uitleg tegelijk in de praktijk kunt toepassen.

Je kunt dit lab vinden op Killercoda in de HCS Sudo Friday omgeving

Veel beheerders brengen (terecht) een groot deel van hun dag door op de command prompt. Nu wordt natuurlijk alles wat geautomatiseerd kan worden ook geautomatiseerd, maar wat handwerk zal er altijd zijn. Nu kan het zijn dat sommig van dat handwerk een kans van falen heeft, bijvoorbeeld omdat een remote systeem (tijdelijk) niet bereikbaar is, omdat een mirror nog niet gesynchroniseerd is, of gewoon omdat de stand van de maan je systeem niet aanstaat.

In plaats van een commando dan met de hand meerdere keren te proberen kun je ook je shell dit voor je laten doen. Één van de manieren waarop dat kan is met een until block.

Bij veel bedrijven draaien er naast de standaard software die door de OS leverancier is aangeleverd ook custom applicaties op de servers. Soms zijn deze in huis geschreven, soms zijn deze door een andere leverancier aangeleverd. Maar in beide gevallen is de kans klein dat deze services al restricties opgelegd hebben gekregen via een SELinux policy.

Het is gelukkig mogelijk om zelf policy modules te schrijven die de bestaande SELinux policy uitbreiden met extra types en regels voor je custom applicaties. Hoever je wilt gaan in het opleggen van restricties is aan jou.

Praktisch elke Kubernetes/OpenShift beheerder kent het principe van de NetworkPolicy, objecten binnen een namespace die bepalen welk verkeer van en naar je pods is toegestaan binnen die namespace.

Om hier gezonde defaults voor af te dwingen hebben de meeste (multi-tenant) clusters ook al maatregelen, zoals DefaultProjectRequestTemplates of Kyverno “generate” regels, die een set “standaard” NetworkPolicies in elke namespace neerzetten.

Het probleem dat nu ontstaat is dat als tenants hun eigen NetworkPolicies moeten kunnen maken, om de toegang binnen hun applicaties fijnschalig te kunnen regelen, ze ook rechten moeten hebben om de defaults aan te passen of te verwijderen. Nu hoeft dat geen probleem te zijn, maar als teams minder voorzichtig of ervaren zijn kan dat al snel leiden tot support calls omdat de OpenShift ingress pods bijvoorbeeld niet meer bij hun applicatie mogen, en hun Routes zijn stukgegaan.

Gelukkig hebben in OpenShift 4.14 NetworkPolicies een uitbreiding gehad, die in 4.16 GA gegaan is en dus ondersteund gebruikt kan worden: AdminNetworkPolicies.

Op moderne Linux systemen kun je (terugkerende) taken voor de toekomst plannen met Systemd “timer” units. Maar de oudere, bekendere, methode van at en cron is meestal ook nog beschikbaar.

In deze video laat Wander zien hoe je deze twee klassiekers zowel als gewone gebruiker en als root kunt gebruiken.