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.