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.

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.

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.

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.

Niet iedereen is gelukkig genoeg om het budget te hebben voor Ansible Automation Platform (AAP), en sommige mensen gebruiken liever een upstream open-source versie van een product dan de betaalde, ondersteunde, versie. Voor Ansible orkestratie kom je dan al snel uit op Ansible AWX.

Recente versies van AWX zijn alleen geschreven om op een Kubernetes platform te draaien, en uitgerold te worden via een operator. Nu kun je wel een dev versie met podman draaien, maar dat levert ook weer problemen op.

Hoe doe je dat dan als je geen (toegang tot) een Kubernetes cluster hebt? De minikube variant zoals beschreven in de AWX documentatie is alleen bedoelt voor test omgevingen, niet productie… Het antwoord kan zijn: “K3S”. Deze lichtgewicht Kubernetes implementatie is wel geschikt voor productie, en kan ook redelijk eenvoudig geïnstalleerd worden.

Via het upstream “kubevirt” project is het mogelijk om virtuele machines te draaien als pods op een Kubernetes cluster. Op OpenShift is hier een door Red Hat ondersteunde versie van genaamd “OpenShift Virtualization”. Op deze manier kun je je VMs makkelijk (bijna) hetzelfde beheren als je containers, bijvoorbeeld met een tool als ArgoCD, of met Tekton Pipelines.

De hardcore CLI fanaten onder ons zullen het niet willen geloven, maar er zijn echt mensen die de voorkeur geven aan een grafische omgeving waar ze in mogen klikken met een muis of een touchscreen voor hun beheer-werkzaamheden.

Als jij ook van die mensen kent, of er zelf eentje bent natuurlijk, dan ben je waarschijnlijk blij om te weten dat er meerdere applicaties zijn die je een grafische omgeving willen geven om je Kubernetes en/of OpenShift clusters te beheren.

Op een Kubernetes cluster (dus ook OpenShift) kun je je pods bereikbaar maken met Service objecten. Deze objecten kunnen verschillende types hebben, headless, ClusterIP, NodePort, LoadBalancer, en ExternalName.