Wanneer je Kustomize gebruikt om je Kubernetes applicaties (of configuraties) uit te rollen kun je tegen het probleem aanlopen dat je een wijziging wilt maken aan je bases of je components, maar zonder dat deze tegelijk al je verschillende omgevingen raakt.

Gelukkig gebruikt Kustomize voor het ophalen van externe resources een handige library genaamd go-getter die met een simpele syntax verschillende Git revisies kan ophalen.

Dashboards en statuspagina’s zijn twee verschillende dingen. Een dashboard is bedoeld voor beheerders en laat gedetailleerde statistieken zien die gebruikt kunnen worden voor correlatie. Een statuspagina is daarentegen bedoeld voor eindgebruikers, en laat een simpel beschikbaar/niet beschikbaar zien.

Wanneer je eenb statuspagina wilt toevoegen aan je infrastructuur dan heb je een hoop keuzes uit self-hosted (open-source) paketten, en betaalde diensten die door third-parties gehost worden. ZO kun je bijvoorbeeld beginnen met het overzicht van Awesome Status Pages op GitHub.

Wander vond daarentegen dat er iets simpels miste dat je met een enkel configuratie bestand ergens in een container of een VM kon draaien, specifiek geënt op OpenShift/Kubernetes of andere dingen die je met Prometheus kunt monitoren.

In deze video laat hij openshift-status zien, een klein tooltje dat een statuspagina voor één of meerdere clusters maakt aan de hand van Prometheus queries. Geen externe databases, of andere dependencies, alleen een enkele binary en een configuratie bestand.

Hier bij Sudo Friday hebben we al vaker gekeken naar manieren om Kubernetes Resource Requests en Limits te werken, bijvoorbeeld hoe dat geïmplementeerd wordt met CGroups, of hoe je ze “Correct” kunt zetten met een Vertical Pod Autoscaler (VPA).

Wat we daarentegen nog nooit hebben gedaan is uitleggen wat Requests en Limits nou precies inhouden, en waarom een applicatieteam zelf er om zou moeten geven.

In het verleden hebben we hier gekeken naar een manier om namespaces op een Kubernetes cluster te managen met een ArgoCD ApplicationSet en Kustomize. Toen gebruikten we veelvuldig “Replacements”, maar omdat deze buiten de Kustomize tree stonden moesten we ArgoCD vertellen om de Kustomize LoadRestrictor op None te zetten.

Maar in 2½ jaar tijd veranderd er veel, tools krijgen nieuwe functionaliteit, mensen krijgen voortschrijdende inzichten, en we worden allemaal wat ouder en wijzer.

In het verleden hebben we op dit kanaal al vaker gekeken naar grafische management tools voor Kubernetes.

Een grote die we toen niet gedaan hebben was Lens, aangezien deze niet meer open-source is. Gelukkig is er ook Freelens, een fork van de open core van Lens (Openlens) die actief ontwikkelt wordt.

Op OpenShift gebruiken veel mensen voor monitoring/metrics de standaard Prometheus stack die wordt meegeleverd, maar er zijn ook andere opties. Vooral als je naar een lichtere oplossing zoekt kan het handig zijn om naar alternatieven te kijken.

In het verleden hebben we hier op dit kanaal al gekeken naar Podman Desktop en al meerdere malen naar Quadlets.

Maar wat we nog niet gedaan hebben is kijken naar de combinatie van die twee. Gelukkig is daar een extensie voor die makkelijk geïnstalleerd kan worden.

Met ArgoCD kun je op meerdere manieren een groep van (verwante) applicaties beheren. Een klassieke methode is met het zogenaamde “App-of-Apps” patroon. Één applicatie die andere applicaties aanmaakt binnen ArgoCD. Dit kan in sommige gevallen handig zijn, maar soms wil je wat meer automatisering en wat minder handwerk. In die gevallen kan een ArgoCD “ApplicationSet” nuttig zijn: Een ArgoCD objectr dat automagisch aan de hand van een lijst van “generators” applicaties opbouwt.

Last Friday we released v0.2.0 of kustomize-promote.

We have discussed kustomize-promote in a “Sudo Friday” video (in Dutch) before. If you want more information on what the tool does, and why YOU wil want to use it, check out that video.

This release has a bugfix for an issue where trying to promote images between two overlays where neither overlay has an image defined resulted in a merge error, but also brings a new feature: Promoting the version of a HelmChart being used between two overlays.

In sommige omgevingen krijgen OpenShift beheerders te horen dat (specifieke) workloads gelimiteerd moeten worden in wat ze (buiten het cluster) kunnen aanspreken aan externe diensten en hosts. Nu kun je dit met standaard NetworkPolicy objecten oplossen, maar aangezien afnemers over het algemeenNetworkPolicy objecten in hun eigen namespaces mogen editen is dit niet de meest robuuste oplossing.

Je zou ook kunnen gaan werken met EgressIP objecten, en verkeer van die IP adressen buiten het cluster laten filteren, maar dan kom je al snel in een wereld waar je honderden extra IPv4 adressen nodig hebt.

Je zou ook met AdminNetworkPolicy objecten bezig kunnen gaan, maar deze zijn nog redelijk nieuw, en werken nog niet buiten OpenShift.

Gelukkig is er ook nog een vierde optie voor gebruikers van het OVN-Kubernetes SDN: EgressFirewalls