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.

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.

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.

In a previous post we looked at how to add extensions to the new Keycloak operator. In that article we used a ConfigMap to store those extensions. In the real world a PersistentVolumeClaim (PVC) would be a more realistic choice, especially for larger or more extensions.

In this post we will look at how to change out the ConfigMap for a PVC, and how to set up a Job that can fill that PVC with the content we want.

Één van de handige Podman functionaliteiten waar we in het verleden een keertje kort wat over gezegd hebben, maar nooit dieper hebben laten zien, is het podman kube subcommando. Dit stukje Podman laat je twee dingen doen, een lokale Podman container of pod als Pod op een Kubernetes cluster deployen, en Kubernetes manifesten deployen als Podman pods en containers.

Één van de meest onmisbare tools bij het debuggen van problemen ope een Kubernetes/OpenShift cluster zijn de “Events”. Kleine stukjes informatie/logging die door de verschillende controllers gegeneerd worden (als Kubernetes objecten) met informatie over wat er allemaal gebeurt en misgaat. Zo zul je in deze events berichten tegenkomen over het al dn niet succesvol ophalen van container images, het starten van pods en containers, het aanmaken van Jobs vanuit een CronJob, het falen van de verschillende probes die op een pod kunnen staan, en meer.

In een vorige aflevering van Sudo Friday hebben we gekeken naar een aantal grafische applicaties om je Kubernetes clusters mee te managen. Een applicatie die daarvoor op Wander zijn lijst stond om te onderzoeken, maar die helaas (nog) niet met alle authenticatie methodes werkte, en dus helaas ook niet met OpenShift, was “Seabird”.

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.

OpenShift Network Observability Operator

In recente versies van OpenShift kun je de “Network Observability Operator” installeren om een beter inzicht te krijgen in de netwerk flows tussen de verschillende componenten/pods/services/etc op je cluster, als ook het netwerk verkeer dat je cluster verlaat.

Deze inzichten kunnen dan gebruikt worden voor verschillende zaken; Het doorberekenen van netwerk gebruik, optimalisatie van traffic-flow tussen de componenten van een micro service, of zelfs het detecteren van “ongebruikelijk” verkeer in een applicatie.

Als je vaak op de command line met Kubernetes of OpenShift werkt dan wil je soms specifieke stukken of velden van een manifest pakken om daar wat mee te doen. Dit kan je natuurlijk met -o yaml of -o json doen om daar vervolgens met yq of jq leuke dingen mee te doen, maar je zou ook de ingebouwde JsonPath of Go-Template functionaliteit kunnen gebruiken.

Regelmatig terugkerende taken op een container paltform kun je op Kubernetes inregelen met een CronJob. Maar als je die taak elke minuut gaat uitvoeren levert dat misschien een belastingspatroon op op je cluster dat ongewenst is, helemaal als de taak veel resources als externe filesystemen nodig heeft.

Nu zou je natuurlijk een traditionele Cron daemon in een container kunnen draaien, maar dan kom je er al snel achter dat deze graag als root draaien, met setgid en setuid permissies, en dat vind een container platform als OpenShift weer minder grappig zonder dat je SecurityContextConstraints met veel rechten gaat uitdelen. Ook zul je een init systeem in je container moeten stoppen omdat anders mogelijke zombie processen niet goed opgeruimd worden, en voor je het weet ben je een half OS in je container aan het stoppen.

Ook als je je taken vaker dan eens per minuut wilt draaien, of als je specifieke scheduling wensen hebt zoals “elke derde dinsdag van September” voldoet een traditionele Cron daemon of een Kubernetes CronJob al snel niet meer.

De API servers op Kubernetes clusters (en dus ook OpenShift) zijn gelimiteerd op het aantal acties dat ze gelijktijdig uit willen voeren. Kom je hierboven, dan zegt de API server gewoon “NEE”.

Sinds Kubernetes 1.20 kun je daarentegen wel bepalen hoe belangrijk dingen zijn. Want: Alle API requests zijn gelijk, maar sommige API requests zijn gelijker dan anderen. Wel is het natuurlijk noodzakelijk dat we wel alle soorten requests worden afgehandeld, we moeten wel eerlijk blijven…

In een Multi-Tenant OpenShift (of standaard Kubernetes) omgeving wil je als beheerder je eindgebruikers soms de vrijheid geven om zelf Project(Requests)s of Namespaces aan te maken, maar wwel binnen vastomlijnde naamgevings protocollen. In het verleden hebben we al eens gekeken hoe je dit met OPA Gatekeeper kunt doen, en hoe je zelf een Validating of Mutating Admission Webhook kunt maken. Dit keer kijken we hoe je dit met Kyverno kunt doen.

In veel gevallen wil je voor je databases bij je Cloud Native applicaties een externe database gebruiken, of iets op een groot database cluster in je datacenter, of iets gemanaged door je cloud provider. Maar er zijn ook veel gevallen waarin je zelf meer controle wilt over de databases, of waar het extern afnemen niet kan of niet handig is. In die gevallen kun je zelf je databases hosten in je Kubernetes/OpenShift cluster.

In een vorige video hebben we gekeken hoe je namespaces kunt beheren met behulp van GitOps methodologieën. Deze week gaan we hierop verder bouwen en gaan we ook (Cluster)ResourceQuotas introduceren.

In het verleden hebben we op dit kanaal al vaker gekeken naar het managen van namespaces voor applicatie-teams op Kubernetes en OpenShift clusters. Deze keer kijken we naar hetzelfde probleem, maar pakken we het op een GitOps methode aan.

Als je op Kubernetes requests en limits zet op een pod, doet dit op het onderliggende OS hele interessante dingen om je instellingen te garanderen. In deze video laat Wander (in vogelvlucht) zien hoe CPU en geheugen requests en limits worden omgezet naar CGroup instellingen naar de per-pod slices die worden aangemaakt.

One of the most important aspects of speeding up delivery is to make sure the quality of the deliveries are up to the highest possible standards. Automated testing can help reduce the number of escaped defects which helps in getting the trust of the business to more frequently deploy. From a micro-service perspective, automated tests are usually a combination of unit tests and integration tests. In unit tests we mock most of the external components away, while in integration testing we typically test against ‘real’ external components.

Er is veel veranderd door de komst van containers en de container platformen. We kunnen het platform in zijn geheel als een nieuwe computer beschouwen, met Kubernetes als operating system. Net als ieder operating system, is er hier ook een API. Dus waarom gebruiken wij dit niet in onze applicaties?

Ansible en OpenShift zijn uitermate goed samen te gebruiken. In dit artikel zullen we kijken hoe we Ansible kunnen inzetten om een OpenShift cluster te beheren en applicaties uit te rollen op een OpenShift cluster. Traditioneel worden applicaties uitgerold vanuit OpenShift templates, Helm charts, pipelines en soortgelijke tools. In dit artikel zullen we de basis leggen voor het uitbreiden of vervangen van deze deployment methodes met Ansible.

Je kent het wel, voordat je namespace, of OpenShift project, helemaal klaar is voor gebruik heb je een kleine waslijst van acties die je met de hand moet uitvoeren. Misschien is er een bepaalde deployment die je in elke namespace standaard wil draaien, misschien zijn er service accounts die je nodig hebt, of moet er een specifieke token toegevoegd worden. Het zijn in ieder geval handelingen die je niet met de hand zou willen uitvoeren. Hoe kun je dit nu eenvoudig automatiseren? Lees in dit blog hoe je een operator voor je kan laten werken.