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.

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

Wanneer je met Podman een container of pod maakt wordt deze als je niks anders opgeeft aan het standaard “podman” network gekoppeld. Als je meer controle wilt, bijvoorbeeld omdat je een gelaagde applicatie in meerdere containers of pods draait, dan mag je ook zelf extra netwerken aanmaken en bepalen welke containers/pods aan welke netwerken gekoppeld zitten.

Praktisch iedereen die netwerken beheert heeft het wel eens gezien: Twee hosts die hetzelfde IP(v4) adres proberen te gebruiken. Dit zorgt over het algemeen voor veel hilariteit en weinig productiviteit.

Op systemen die “NetworkManager” gebruiken kan er een simpele veiligheidsmaatregel worden aangezet: een ARP request voor het gewenste IPv4 adres voordat deze geactiveerd wordt. Is het adres in gebruik, dan wordt de verbinding niet geactiveerd.

Op RHEL9 en ouder staat deze test standaard uit, op RHEL10 en Fedora41 staat deze test standaard aan.