Bijna iedereen heeft wel eens set -euo pipefail bovenaan een shell script zien staan.

Maar wat betekent dat nou precies? En waarom gebruiken we dat? Waar vind ik daar de documentatie van? Wat is de betekenis van het leven?

In het verleden hebben we op dit kanaal al vaker gekeken naar het configureren van metrics, voornamelijk op Kubernetes platformen. In die gevallen was het vaak een eenvoudige setup met behulp van bijvoorbeeld een Operator, waardoor je met een paar klikken klaar was.

Nu is het tegenwoordig bijna net zo makkelijk om goede, robuuste, metrics te verzamelen van je “klassieke” systemen. De RHEL System Roles Ansible collection heeft een een role genaamd metrics die gebruikt kan worden om Performance Co-Pilot (PCP) te configureren om metrics te verzamelen, maar ook om een Valkey (of Redis op oudere systemen) te configureren om metrics van meerdere hosts te verzamelen, en een Grafana (inclusief dashboards en datasources) op te zetten.

Als je een digitale foto (of ander plaatje) van lage resolutie of kwaliteit hebt, en je wilt die toch kunnen gebruiken ergens waar je een hogere resolutie nodig hebt, dan kun je grijpen naar wat standaard beeldbewerkings software zoals Gimp. Een beetje “scale”, een beetje “sharpen”, en je hebt waarschijnlijk al redelijk snel iets dat je met trots “mèh” mag noemen, misschien zelfs wel “mid”.

Gelukkig zijn er applicaties die niks anders als doen hebben dan het vergroten/verbeteren van plaatjes. Sommigen daarvan zullen niet veel betere resultaten halen dan wat je zelf met generieke bewerking software kon doen, maar anderen gebruiken wat modernere (en CPU/GPU intensievere) algoritmes om een beter resultaat te behalen.

Op zich lijkt YAML niet zo raar. Whitespace is misschien belangrijk, en het inline gebruik van JSON kan er soms wat vies uit zien, maar over het algemeen lijkt het toch redelijk eenvoudig.

Totdat het niet meer zo eenvoudig blijkt te zijn. Waardes die spontaan lijken te veranderen, landen die blijkbaar niet mogen bestaan, port-mappings die veranderen in (schijnbaar) willekeurige getallen…

Wanneer je op OpenShift een cluster-brede (AllNamespaces) operator installeerd wordt er door de Operator Lifecycle Manager (OLM) een kopie van de Cluster Service Version (CSV) in elke namespace op je cluster neergezet. Deze kopie is hier voor de informatie van je eindgebruikers, zodat ze kunnen kijken welke operators beschikbaar zijn in hun namespaces.

Dit klinkt natuurlijk heel nobel en eervol, maar wanneer je honderden, of zelfs duizenden, namespaces hebt op een cluster kost dit behoorlijk wat resources (CPU, Geheugen) voor OLM zelf om bij elke reconcile deze CSVs bij te werken. Ook is het een grote aanslag op de performance van Etcd en de Kubernetes APIServer, want die moeten al die aanpassingen op al die objecten verwerken.

Wanneer we enge dingen gaan op virtuele machine maken we vaak op Hypervisor niveau een “Snapshot”, zodat we in het geval dat dingen een ventilator geraakt hebben we makkelijk een stapje terug kunnen doen om het nogmaals te proberen.

Wanneer je op Bare-Metal draait, of een virtualisatie omgeving zonder snapshot mogelijkheid, wordt dit een stukje moeilijker.

Je kunt LVM of Stratis snapshots maken (als je die gebruikt natuurlijk), maar de snapshots van verschillende volumes synchroniseren, je bootloader entries en bijbehorende kernels ook meenemen, als ook het terugzetten van die snapshots kan wat ingewikkelder zijn.

Gelukkig is daar een tooltje voor Snapshot manager (Snapm), die dit alles voor je kan automatiseren.

Wanneer je RHEL systemen wilt upgrade tussen major versies, bijvoorbeeld van RHEL9 naar RHEL10, dan is een schone installatie altijd de voorkeursmethode. Maar soms heb je systemen, of processen, waarbij dat niet kan. In die gevallen zul je een in-place upgrade moeten uitvoeren.

Op RHEL-familie systemen kan dat met het leapp tooltje. Deze weet precies welke aanpassingen er gemaakt moeten worden aan een systeem om de upgrade succesvol uit te voeren.

In het verleden hebben we op dit kanaal al gekeken naar de verschillende soorten “Services” die je op Kubernetes kunt aanmaken, maar eentje zijn we toen overgeslagen: “ExternalName”.

Met dit soort services kun je een Service op Kubernetes laten doorverwijzen (via DNS CNAME) naar een externe service.

Het is al een lange tijd mogelijk om uitgaand netwerk verkeer vanuit een namespace op OpenShift vanaf een ander IP adres te laten komen dan het andere cluster verkeer. Vroeger, met OpenShiftSDN, was dit puur op namespace basis, als het verkeer kwam vanaf een apart IP adres, of niet. IP adressen konden ook niet door meer dan één namespace gebruikt worden.

Tegenwoordig, met OVN Kubernetes als SDN, kan dit een stuk fijnmaziger. Egress IPs kunnen geselecteerd worden door labels op zowel de namespace als de workload zelf, waardoor het mogelijk wordt om IP adressen te delen tussen namespaces, en zelf meerdere IP adressen te gebruiken voor verschillende workloads in een namespace.

Het klinkt in deze tijd van Observability misschien raar, maar soms is het gewenst om minder te monitoren.

Wanneer je clusters groeien, en de CPU, geheugen, en opslag druk van je monitoring stack blijft groeien, kan het soms gewenst zijn om minder verschillende metrics te verzamelen om die druk lager te houden. In die gevallen kun je op een OpenShift cluster terugvallen op het minimal CollectionProfile.