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.

Wanneer het gaat over TLS certificaten toevoegen aan Ingress objecten op OpenShift dan is er altijd een groot verschil geweest tussen OpenShift Routes en andere vormen van Ingress: Bij OpenShift Routes moesten de certificaten ge-embed in het Route objectr, terwijl je bij andere Ingress objecten naar een certificaat in een Secret kon wijzen.

Deze situatie is, zoals zoveel OpenShift dingen, historisch gegroeid, maar met een goede reden: De OpenShift Engineers waren nogal huiverig voor het geven van algemene Secret lees-rechten aan de OpenShift Router. Met de release van OpenShift 4.19 is hier verandering ingekomen, je mag nu in een Route naar een Secret wijzen met je certificaat info. Wel moet je expliciet een Role en een Rolebinding aanmaken die de OpenShift Router expliciete leesrechten geeft op je Secret.

Dit maakt het werken met tools als cert-manager en External Secrets Operator een stuk makkelijker, deze hebben nu geen extra tooling meer nodig om de opgehaalde of gegenereerde certificaten in de Route te embedden.

Soms zijn er tooltjes die een fractie van de functionaliteit hebben van een een grotere tool, maar juist daarom veel beter geschikt zijn voor bepaalde taken.

Deze week bekijkt Wander met jullie één van dit soort tools: Gradia

Sinds kort is het mogelijk om de volledige Red Hat Knowledge Base en Documentation Portal self-hosted en airgapped te draaien vanuit een container. Dit maakt het mogelijk om ook in een volledig disconnected omgeving toegang te hebben tot je product documentatie, CVE en Errata databases, support artikelen, en meer.

Om dit op te zetten heb je niet meer nodig dan een Red Hat account met een actieve Satellite subscriptie, een machine die wel internet heeft om de images op te halen, en een machine met minimaal 30GiB vrije diskruimte om de Red Hat Offline Knowledge Portal (RHOKP) op te draaien.

Deze week neemt Wander jullie mee terug in de tijd naar het begin van de jaren tachtig. En wat is er nou beter om te tijdreizen dan revisie beheer software? Specifieker, de grootvader van alle revisie beheer software: Revision Control System (RCS).

Voor sommigen van jullie zal dit een herinnering zijn aan beter tijden, voor anderen een hoofdstuk van hun leven dat ze gesloten hebben en hopen nooit meer te hoeven openen. Voor de chronologisch minder bevoordeelde mensen is het misschien dat irritante commando dat je bestanden liet verdwijnen op RHEL4 en ouder als je per ongeluk ci typte in plaats van vi.

Vorige week is tijdens de Red hat Summit Red hat Enterprise Linux 10 (RHEL10) uitgebracht. Ook al zitten er wat leuke nieuwe dingen in deze versie, toch wordt Wander heerlijk blij van hoe saai de release is. Het is een evolutie, geen revolutie, voor het OS.

Sommige van de “nieuwe” features waren ook al (gedeeltelijk) beschikbaar op RHEL9, zoals RHEL Image Mode, waarbij je (virtuele) machines uitrolt en update vanuit container images. Andere dingen draaien meer in de cloud bij Red Hat, zoals alle nieuwe Insights features.

In deze video laat Wander jullie één van de echt nieuwe features zien in RHEL10: Commandline Assistant.

Vroeger (toen alles nog beter was) kon je met redelijk gemak een grafische applicatie op een remote machine draaien met de ouput op je lokale machine door ssh -X te gebruiken. Dit zette de DISPLAY variabele op de remote machine naar een nep display, en stuurde al het verkeer van die display over de SSH verbinding door naar je lokale display.

Dit was natuurlijk erg handig, maar het was ook niet erg veilig. Tegenwoordig gebruikt bijna alles Wayland in plaats van X11, en dat maakt dingen als stiekem alle toetsenbord input stelen, of de inhoud van vensters van andere applicaties lezen een stuk moeilijker, een win voor de beveiliging. Helaas maakt dat het over het netwerk draaien van grafische applicaties ook wat moeilijker.

Gelukkig is daar natuurlijk ook een oplossing voor.

In het verleden hebben we hier op dit kanaal al eens gekeken naar het automatisch schalen van je applicaties aan de hand van custom metrics. Maar dat waren custom metrics, en met Keda. De basis, de standaard Kubernetes HorizontalPodAutoscaler, hebben we nog niet behandeld.

Deze week een keertje geen leuke technische nieuwigheden, maar een (korte) verhandeling en oproep van Wander over het begrijpen van wat je doet.

Te vaak ziet Wander dat mensen wel weten hoe ze een kunstje moeten uitvoeren, maar niet snappen wat dat kunstje op de achtergrond voor ze doet, of hoe het werkt.

Meestal als je KubeVirt (OpenShift Virtualization voor de OpenShift gebruikers onder ons) draait, en je wilt virtuele machines van buiten het cluster beschikbaar maken, dan grijp je naar zaken als Secundaire netwerken met OVS of Multus. Dit is dan ook de methode die bijvoorbeeld door Red Hat wordt aangeraden voor OpenShift. Het voordeel hiervan is dat het mooi samenwerkt met dingen als UserDefinedNetworks (UDN), VLAN tagging/trunking, etc.

Maar we hebben niet altijd allemaal toegang tot nodes met extra netwerk-kaarten, mooie netwerk setups, enzovoort. Sommige van ons doen veel werk met dingen als Kind, OpenShift Local (CRC), of andere kleine setups. In die gevallen kun je je VMs wel exposen aan het externe netwerk als je een beetje vals speelt door bijvoorbeeld MetalLB te gebruiken.