Sinds RHEL9 heeft de standaard .bashrc voor nieuwe gebruikers een trucje geleerd: Het laden van bestanden uit de ~/.bashrc.d directory.

Hiermee is het mogelijk om geen custom monolithisch .bashrc bestand meer bij te houden, met alle nare neveneffecten van dien wanneer je gaat automatiseren, maar om over te stappen op een modulair systeem, waarbij je gewoonweg de goede bestanden voor de gewenste functionaliteit kopieert naar de juiste systemen.

Wanneer je in Python een commandline tooltje bouwt, en je behoeftes voor het parsen van opties en argumenten meer wordt dan alleen maar wat argumenten lezen, zul je al snel een library gaan zoeken die daar bij kan helpen.

De twee standaard opties zijn argparse en optparse, maar er zijn ook libraries die meer kunnen, en makkelijker zijn in het gebruik.

Zoals ondertussen bijna traditie is geworden biedt HCS Company jullie ook dit jaar weer een leuke Kerst Puzzel aan. Je kunt hem spelen op https://kerstpuzzel2022.hcs-company.com/.

Nieuw dit jaar is de kleurwedstrijd die op dezelfde site te vinden is.

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.

Sinds enige jaren heeft de RHEL familie van distributies een krachtige web-based management tool: Cockpit

De afgelopen jaren heeft OpenShift voor de logging stack standaard gebruik gemaakt van de EFK stack (ElasticSearch, FluentD, Kibana). Tegenwoordig kunnen cluster beheerders er ook voor kiezen om LokiStack voor de logging te gebruiken.

Als je op OpenShift User Workload Monitoring hebt aangezet kunnen ontwikkelaars wel custom metrics laten ophalen en opslaan, en ze uitvragen via de OpenShift Web Console, maar complexere dashboards zijn (nog) niet in de console mogelijk.

Gelukkig is het wel mogelijk om via de community Grafana Operator deze metrics ook uit te vragen, en via dashboards inzichtelijk te maken. Wel loop je dan tegen het probleem aan dat als je dit via de reguliere instantie van Thanos Querier wilt doen het een alles-of-niks spel wordt: Of je hebt geen toegang tot metrics, of je mag bij alle metrics van het cluster en alle applicaties.

Ook dat laatste probleem kan opgelost, door de speciale tenancy poort van Thanos Querier te gebruiken, waarbij je per query metrics voor één namespace tegelijk mag opvragen, mits je rechten hebt op die namespace.

In OpenShift is een monitoring stack aanwezig, gebaseerd op Prometheus, die standaard al erg veel rijk metrics verzamelt over allerlei onderdelen van je platform. Zo kunnen applicatie-teams hier al standaard van alles in over vinden over het geheugen-, CPU-, disk-, en netwerk-gebruik van hun applicaties.

Wanneer een team hun applicatie wil verrijken met custom metrics dan kan dat ook, maar hier moeten wel zowel aan de platform kant als aan de applicatieve kant een aantal dingen voor gedaan worden.

Om verkeer van buiten een Kubernetes/OpenShift cluster in te krijgen heb je waarschijnlijk een LoadBalancer nodig, om bijvoorbeeld je Ingress te ontsluiten, of om services rechtstreeks aan te bieden.

Wanneer je in een cloud omgeving draait biedt je provider waarschijnlijk loadbalancers aan die rechtstreeks door je cluster aangestuurd kunnen worden, maar wanneer je op Baremetal draait, of op LibVirt, of op VMWare, dan missen deze opties.