Alle posts van Wander

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.

Op een Kubernetes cluster (dus ook OpenShift) kun je je pods bereikbaar maken met Service objecten. Deze objecten kunnen verschillende types hebben, headless, ClusterIP, NodePort, LoadBalancer, en ExternalName.

Wanneer je een OpenShift cluster aan een (of meerdere) externe authenticatie bronnen hebt gekoppeld is het fijn als je ook de groepen die gedefinieerd staan in die externe bronnen zou kunnen gebruiken. Bij het gebruik van OpenID Connect providers wordt dit automatisch voor je gedaan, maar voor andere providers zul je zelf wat moeten doen.

Het uitrollen (installeren, configureren, integreren) van een OpenShift cluster in een Enterprise omgeving kan een flinke uitdaging zijn. Bij HCS zijn we die uitdaging al vele malen en bij vele klanten aangegaan. Één van de tools die we daar bijna altijd bij gebruiken is onze eigen HCS OpenShift Installer, een set van playbooks die het uitrollen en configureren in een enterprise omgeving makkelijker, en consistenter, maakt.