Argo Rollouts op OpenShift

Met Argo Rollouts kun je Deployment objecten vervangen door Rollout objecten die meer controle geven over hoe updates aan een Deployment uitgerold worden. Langzaam aan met Canaries, atomisch met Green-Blue changeover, en meer. Dit alles kan automatisch gebeuren, met handmatige promotie stappen, combinaties daarvan, en zelfs met probes die kijken of een nieuwe versie goed werkt.

Één van de uitdagingen die wij vaak zien bij klanten op het gebied van platform management is het “right-sizen” van applicaties; Het goed zetten van de requests en limits voor applicaties zodat ze altijd aan resources kunnen gebruiken wat ze nodig hebben, maar niet onnodig veel aanvragen dat niet door de rest van de applicaties op het cluster gebruikt kan worden.

Naast educatie van applicatie teams, een belangrijke stap, kan het ook handig zijn om teams (geautomatiseerde) adviezen te geven over de “juiste” instellingen voor hun applicaties. Een tool die daarbij kan helpen is de Vertical Pod Autoscaler van OpenShift.

Met de release van OpenShift 4.17 is er een feature in Technology Preview gekomen waar Wander al heel lang op zat te wachten: User Namespaces.

User Namespaces hebben niks te maken met Kubernetes Namespaces, maar met Linux Kernel Namespaces. Met User Namespaces kan een container een ander idee hebben van wat user ids zijn dan het onderliggende OS. Zo kan een proces in een container denken root te zijn, en alle rechten hebben (binnen de container) die daarbij horen, maar buiten de container stiekem een ander UID hebben. Dit is hetzelfde principe als met Rootless Podman, maar nu beschikbaar (als beta) op Kubernetes, en dus ook op OpenShift.

Met deze feature hoeven cluster beheerders minder vaak uitzonderingen te maken voor onder andere COTS applicaties door toegang to verlenen tot de anyuid of nonroot Security Context Constraints (SCC), wat kan leiden tot een beter security posture.

Praktisch elke Kubernetes/OpenShift beheerder kent het principe van de NetworkPolicy, objecten binnen een namespace die bepalen welk verkeer van en naar je pods is toegestaan binnen die namespace.

Om hier gezonde defaults voor af te dwingen hebben de meeste (multi-tenant) clusters ook al maatregelen, zoals DefaultProjectRequestTemplates of Kyverno “generate” regels, die een set “standaard” NetworkPolicies in elke namespace neerzetten.

Het probleem dat nu ontstaat is dat als tenants hun eigen NetworkPolicies moeten kunnen maken, om de toegang binnen hun applicaties fijnschalig te kunnen regelen, ze ook rechten moeten hebben om de defaults aan te passen of te verwijderen. Nu hoeft dat geen probleem te zijn, maar als teams minder voorzichtig of ervaren zijn kan dat al snel leiden tot support calls omdat de OpenShift ingress pods bijvoorbeeld niet meer bij hun applicatie mogen, en hun Routes zijn stukgegaan.

Gelukkig hebben in OpenShift 4.14 NetworkPolicies een uitbreiding gehad, die in 4.16 GA gegaan is en dus ondersteund gebruikt kan worden: AdminNetworkPolicies.

In a previous post we looked at how to add extensions to the new Keycloak operator. In that article we used a ConfigMap to store those extensions. In the real world a PersistentVolumeClaim (PVC) would be a more realistic choice, especially for larger or more extensions.

In this post we will look at how to change out the ConfigMap for a PVC, and how to set up a Job that can fill that PVC with the content we want.

In recent times the Keycloak Operator for OpenShift has moved from the old EAP based implementation to a new implementation based on Quarkus. At the same time the Custom Resource Definition for a Keycloak object has moved from apiVersion v1alpha1 to v2alpha1.

While on average this is a good move, and it brings many improvements, some functionality appears to have not made the transition yet, most notably the ability to easily add custom extensions and providers.

Since one of our customers encountered this and asked for our help we went and sought a solution to this, without having to resort to building custom images, as those would add an extra maintenance burden on an already busy team.

Één van de meest onmisbare tools bij het debuggen van problemen ope een Kubernetes/OpenShift cluster zijn de “Events”. Kleine stukjes informatie/logging die door de verschillende controllers gegeneerd worden (als Kubernetes objecten) met informatie over wat er allemaal gebeurt en misgaat. Zo zul je in deze events berichten tegenkomen over het al dn niet succesvol ophalen van container images, het starten van pods en containers, het aanmaken van Jobs vanuit een CronJob, het falen van de verschillende probes die op een pod kunnen staan, en meer.

Als je een applicatie die via Hem charts wordt gedistribueerd in je OpenShift GitOps (ArgoCD) wilt opnemen heb je twee opties:

1. Een ArgoCD applicatie van het type “Helm” maken
2. De Helm chart via kustomize laten renderen, en de kustomization.yaml in je ArgoCD opnemen.

De eerste oplossing is het makkelijkst, en heeft weinig extra configuratie nodig. Het nadeel is wel dat je wat betreft aanpassingen gelimiteerd bent op wat de schrijver van de chart via de values.yaml heeft aangeboden.

Wanneer je extra aanpassingen nodig hebt kom je dus al snel uit op de tweede methode: De helm chart via kustomize laten renderen (inclusief aanpassingen via values.yaml), en daar extra aanpassingen op doen via de bekende kustomize transformers zoals images:, patches:, replicas:, etc.

Door het automatisch bijwerken van je base images op je containerplatform is het mogelijk om de nieuwste versies op je OpenShift platform te hebben. Het kan natuurlijk ook voorkomen dat per direct een nieuwe base image gebouwd moet worden. Dit moet je dan met de hand kunnen doen. Wat nu?

Via het upstream “kubevirt” project is het mogelijk om virtuele machines te draaien als pods op een Kubernetes cluster. Op OpenShift is hier een door Red Hat ondersteunde versie van genaamd “OpenShift Virtualization”. Op deze manier kun je je VMs makkelijk (bijna) hetzelfde beheren als je containers, bijvoorbeeld met een tool als ArgoCD, of met Tekton Pipelines.

De hardcore CLI fanaten onder ons zullen het niet willen geloven, maar er zijn echt mensen die de voorkeur geven aan een grafische omgeving waar ze in mogen klikken met een muis of een touchscreen voor hun beheer-werkzaamheden.

Als jij ook van die mensen kent, of er zelf eentje bent natuurlijk, dan ben je waarschijnlijk blij om te weten dat er meerdere applicaties zijn die je een grafische omgeving willen geven om je Kubernetes en/of OpenShift clusters te beheren.

OpenShift Network Observability Operator

In recente versies van OpenShift kun je de “Network Observability Operator” installeren om een beter inzicht te krijgen in de netwerk flows tussen de verschillende componenten/pods/services/etc op je cluster, als ook het netwerk verkeer dat je cluster verlaat.

Deze inzichten kunnen dan gebruikt worden voor verschillende zaken; Het doorberekenen van netwerk gebruik, optimalisatie van traffic-flow tussen de componenten van een micro service, of zelfs het detecteren van “ongebruikelijk” verkeer in een applicatie.

Als je vaak op de command line met Kubernetes of OpenShift werkt dan wil je soms specifieke stukken of velden van een manifest pakken om daar wat mee te doen. Dit kan je natuurlijk met -o yaml of -o json doen om daar vervolgens met yq of jq leuke dingen mee te doen, maar je zou ook de ingebouwde JsonPath of Go-Template functionaliteit kunnen gebruiken.

Wanneer je bezig gaat met SSL certificaten op OpenShift kom je al snel uit bij cert-manager, een operator die certificaten kan laten (genereren en) ondertekenen door een aantal verschillende vormen van Certificate Authorities.

Een nadeel aan cert-manager is dat het niet automatisch certificaten kan genereren voor OpenShift Routes, maar wel voor reguliere Ingress objecten.

Een applicatie op Kubernetes beheren is nog lang niet altijd zo gemakkelijk. Gelukkig is daar iets voor uitgevonden: Kubernetes operators. Een operator is als het ware een controller op Kubernetes (of OpenShift) om instanties van complexe applicaties te maken, configureren en beheren.

Er zijn een hoop gevallen waarbij een OpenShift cluster vanuit technische- of veiligheidsredenen niet aan het internet verbonden mag of kan zijn. Nu geeft dit natuurlijk nogal wat problemen bij het installeren, upgraden, en gebruiken van zo’n cluster.

Nu heeft OpenShift de mogelijkheid om verzoeken voor images vanaf externe container registries om te leiden naar een registry van jouw keuze. Nu moet je alleen die registry nog vullen met de goede images, en dat zijn er nogal wat…

Met de release van OpenShift 4.13 is de support voor het gebruik van de nieuwste generatie Control Groups (cgroup v2) van Technology Preview (TP) naar General Availability (GA) gegaan. Wel staat de standaard instelling nog op de eerste generatie.

Met de release van OpenShift 4.13 is de Custom Metrics Autoscaler Operator gepromoveerd naar General Availability (GA). Met deze operator kun je het aantal replica’s van je deployments automatisch laten schalen aan de hand van CPU gebruik, geheugen gebruik, custom Prometheus metrics, of Kafka Queues (die laatste is wel nog Technology Preview).

Door het automatisch bijwerken van je base images op je containerplatform is het mogelijk om de nieuwste versies op je OpenShift platform te hebben, zonder dat je hiervoor nog handmatig iets hoeft te doen!

De API servers op Kubernetes clusters (en dus ook OpenShift) zijn gelimiteerd op het aantal acties dat ze gelijktijdig uit willen voeren. Kom je hierboven, dan zegt de API server gewoon “NEE”.

Sinds Kubernetes 1.20 kun je daarentegen wel bepalen hoe belangrijk dingen zijn. Want: Alle API requests zijn gelijk, maar sommige API requests zijn gelijker dan anderen. Wel is het natuurlijk noodzakelijk dat we wel alle soorten requests worden afgehandeld, we moeten wel eerlijk blijven…

Wanneer je applicatie teams op je OpenShift cluster toelaat, en die gaan gebruik maken van BuildConfigs en/of DeploymentConfigs, dan zou het zomaar kunnen dat er niet netjes wordt opgeruimd. Deze objecten laten vaak artefacten performance van je cluster negatief kan beïnvloeden.

In een Multi-Tenant OpenShift (of standaard Kubernetes) omgeving wil je als beheerder je eindgebruikers soms de vrijheid geven om zelf Project(Requests)s of Namespaces aan te maken, maar wwel binnen vastomlijnde naamgevings protocollen. In het verleden hebben we al eens gekeken hoe je dit met OPA Gatekeeper kunt doen, en hoe je zelf een Validating of Mutating Admission Webhook kunt maken. Dit keer kijken we hoe je dit met Kyverno kunt doen.

In veel gevallen wil je voor je databases bij je Cloud Native applicaties een externe database gebruiken, of iets op een groot database cluster in je datacenter, of iets gemanaged door je cloud provider. Maar er zijn ook veel gevallen waarin je zelf meer controle wilt over de databases, of waar het extern afnemen niet kan of niet handig is. In die gevallen kun je zelf je databases hosten in je Kubernetes/OpenShift cluster.

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.

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.

Één van de dingen waar je tegenaan loopt als je een OpenShift cluster wilt uitrollen op je eiegen infrastructuur, en dus niet in de publieke cloud, is het opzetten van een goede externe loadbalancer voor de verschillende diensten op het cluster. Het is mogelijk om een self-hosted load-balancer met keepalived en haproxy te draaien op je cluster zelf, maar dit wordt door Red Hat alleen maar officieel ondersteund op UPI VMWare installaties.

In dit artikel leggen we uit wat je moet configureren aan de hand van een voorbeeld haproxy.cfg.

Sinds kort is het mogelijk om op OpenShift Sandboxed Containers te draaien, containers die niet het kernel delen met de rest van de containers op een systeem, maar containers die draaien met hun eigen kernel, in hun eigen virtuele machine.

One of the most important aspects of speeding up delivery is to make sure the quality of the deliveries are up to the highest possible standards. Automated testing can help reduce the number of escaped defects which helps in getting the trust of the business to more frequently deploy. From a micro-service perspective, automated tests are usually a combination of unit tests and integration tests. In unit tests we mock most of the external components away, while in integration testing we typically test against ‘real’ external components.

Tekton is een cloud native framework om een eigen CI/CD oplossing mee te ontwikkelen. Het gebruik maken van bouwblokken staat binnen dit cloud native framework centraal. Tekton gebruikt hiervoor Kubernetes resources binnen de pipelines. Ideaal als je simpel en snel pipelines wilt aanmaken. Na het lezen van dit artikel weet jij precies wat Tekton is en hoe het jouw organisatie kan helpen!

Vele van jullie kennen OpenShift inmiddels wel. OpenShift is een Kubernetes plus platform dat je in staat stelt om traditionele statefull applicaties in te zetten, naast cutting-edge cloud-native applicaties, door moderne architecturen zoals microservices of serverless te ondersteunen. Een platform dat naast alle development hulpmiddelen ook gebouwd is met een focus op up-time. Men wil natuurlijk dat zijn of haar horizontaal - of sinds OpenShift 4 ook verticaal - geschaalde applicaties wel blijven draaien. Maar wat nou als je zo’n platform als OpenShift uit moet zetten? Wat komt daar dan bij kijken?

Deze week was het zover: het jaarlijkse Red Hat Summit vanuit Amerika. Collega Klaas-Pieter Majoor bracht gisteren al verslag uit van dag 1. Vandaag een verslag van dag 2, en stiekem ook een terugblik op dag 1, maar dan vanuit mijn perspectief als OpenShift / DevOps Engineer.  

Er is veel veranderd door de komst van containers en de container platformen. We kunnen het platform in zijn geheel als een nieuwe computer beschouwen, met Kubernetes als operating system. Net als ieder operating system, is er hier ook een API. Dus waarom gebruiken wij dit niet in onze applicaties?

Ansible en OpenShift zijn uitermate goed samen te gebruiken. In dit artikel zullen we kijken hoe we Ansible kunnen inzetten om een OpenShift cluster te beheren en applicaties uit te rollen op een OpenShift cluster. Traditioneel worden applicaties uitgerold vanuit OpenShift templates, Helm charts, pipelines en soortgelijke tools. In dit artikel zullen we de basis leggen voor het uitbreiden of vervangen van deze deployment methodes met Ansible.

Je kent het wel, voordat je namespace, of OpenShift project, helemaal klaar is voor gebruik heb je een kleine waslijst van acties die je met de hand moet uitvoeren. Misschien is er een bepaalde deployment die je in elke namespace standaard wil draaien, misschien zijn er service accounts die je nodig hebt, of moet er een specifieke token toegevoegd worden. Het zijn in ieder geval handelingen die je niet met de hand zou willen uitvoeren. Hoe kun je dit nu eenvoudig automatiseren? Lees in dit blog hoe je een operator voor je kan laten werken.

Sinds deze week is het officieel; Red Hat OpenShift 4.2 is  gereleased en voor het grote publiek beschikbaar. Waarschijnlijk kun je niet wachten om er mee aan de slag te gaan, maar wat is er nu precies nieuw? Als Red Hat Accelerator vind ik het altijd leuk om met de nieuwste technieken bezig te zijn en deze te onderzoeken. In dit blog neem ik jullie mee in een paar mooie nieuwe features die mij persoonlijk zijn opgevallen in OpenShift 4.2. 

Kwetsbaarheid in runc gevonden, wat nu?!

Er is een fout gedetecteerd in runc waardoor een schadelijke container toegang op rootniveau op de hostcomputer kan krijgen.

Dit beveiligingslek raakt zowel de docker– als runc-pakketten die beschikbaar zijn op Red Hat Enterprise Linux 7, die worden geleverd via het kanaal Extra’s. OpenShift Container Platform (OCP) 3.x is afhankelijk van deze pakketten, afkomstig van Red Hat Enterprise Linux 7 Extras en wordt ook beïnvloed.

Laatst werd mij gevraagd om eens te kijken of het mogelijk was om het gebruik van het OpenShift cluster terug te schakelen op basis van tijdschema’s. Een bijzondere vraag. Een OpenShift tijdschakelaar. Meestal is de vraagstelling of het mogelijk is om een applicatie automatisch te schalen op basis van CPU- of geheugengebruik. Waarom dan deze vraagstelling? In deze situatie wordt het OpenShift platform intern afgenomen. Is er een quota ingesteld en wordt er een pay per use afrekenmodel gehanteerd.