Wanneer je kustomize gebruikt om met Overlays de lifecycle-fases van je applicatie te beheren dan ga je vroeger dan later een keer de vragen stellen hoe je promoties van images (en Bases) tussen deze fases kunt automatiseren. Met de hand references en image transformers doorzetten is meestal geen optie vanwege de kans op fouten, en het willen automatiseren van de promotie pipelines.

Nu zijn er bestaande oplossingen met tools als Renovate die dit (gedeeltelijk) voor je kunnen oplossen, maar die hebben vaak wat meer infrastructuur nodig. Als je deze tools nog niet gebruikt dan zou je zelf wat scriptjes kunnen schrijven, maar nu heb je nog iets extras om te beheren en bij te houden.

Één van de nieuwe features in RHEL9.5 is de mogelijkheid om in Cockpit, de grafische management console van RHEL, bestanden te beheren alsof je in een grafische file-manager werkt.

In a typical containerized application we have a lifecycle that goes a little like this:

1. Developers push code to an application repository.
2. A pipeline builds the latest code and pushes the resulting image to a registry
3. The pipeline updates the images: transformer in a Kustomization Overlay for the dev environment with the new image by using a command like kustomize edit set image foobar=registry.example.com/foobar@sha256:deadbeef
4. A tool like ArgoCD picks up the new image and starts a new deployment.

This works well for the dev environment, but when that image needs to be promoted to a new environment like tst we either need to copy the updated image transformer manually, or try to read the updated version from the dev Kustomization.

And images are not the only thing. A typical Kustomize Overlay will include a versioned Base with something like this:

1apiVersion: kustomize.config.k8s.io/v1beta1
2kind: Kustomization
3resources:
4- git.example.com/foobar.git/deploy/base?ref=v0.2.1

In this example we see that the Base that is being used comes from the Git tag or branch called v0.2.1. If a newer version of the application needs a newer Base a developer can update that reference in the dev Overlay, but promotions will need to be handled as well.

Simply copying the kustomization.yaml file between Overlays will most likely not work, since different Overlays typically use different Replica transformers, different ConfigMap en Secret Generators etc.

Read on to learn how you can automate this.

Basis Kubernetes kent maar twee manieren van authenticatie: Een lijst van statische oauth bearer tokens, gekoppeld aan gebruikers en groepen, en client TLS certificaten met de gebruikersnaam in het “CN” (Common Name) veld en eventuele groepen in één of meer “O” (Organization) velden.

Op een Linux systeem heb je de keuze uit een aantal compressie tools en algoritmes voor het verkleinen van je bestanden en/of archieven. Ook kunnen sommige bestandsystemen (zoals Btrfs) transparant compressie toepassen op bestanden waar nodig.

Op dit kanaal hebben we al vaker gekeken naar Podman. Zo hebben we gekeken naar het maken van systemd units van je containers, het werken met podman-compose, het draaien van Kubernetes manifesten met Podman, en meer.

Maar één van de dingen die we nog nooit gedaan hebben is het gebruiken van Pods met Podman, en dat terwijl dat zelfs in de naam zit.

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.