Doe meer met Kubernetes dankzij Operators

Nieuwe uitdagingen voor Kubernetes

Als je een blik werpt op de onderwerpen van KubeCon / CloudNativeCon van dit jaar, ziet het ernaar uit dat veel vragen over Kubernetes, soorten cloud, logging tools enz. beantwoord zijn voor de meeste bedrijven. Logisch ook, want steeds meer organisaties maken al met succes gebruik van Kubernetes. Kubernetes wordt niet langer als de 'next big thing’ beschouwd, maar eerder als een logische keuze. We hebben echter gemerkt (tijdens de lezingen, maar ook op ons eigen traject) dat er nieuwe problemen en uitdagingen rijzen, die op hun beurt tot andere vragen leiden:

• Hoe kan ik meer automatisering implementeren?
• Hoe kan ik de kosten voor deze set-ups onder controle houden/drukken?
• Is er een manier om wat er al bestaat uit te breiden en mijn eigen functionaliteiten toe te voegen aan Kubernetes?

Een van die manieren om functionaliteiten toe te voegen aan Kubernetes is het gebruik van operators. In deze blog leg ik kort uit hoe operators werken.

Hoe operators werken

Het concept van een operator is eigenlijk vrij eenvoudig. De makkelijkste manier om het uit te leggen, is volgens mij door effectief een operator te installeren.

Bij ACA gebruiken we de istio-operator. De exacte installatiestappen hangen af van de operator die je installeert, maar meestal zijn ze gelijkaardig.

Installeer eerst de istioctl binary op de machine die toegang heeft tot de Kubernetes-API. De volgende stap is het uitvoeren van de opdracht om de operator te installeren.

Op die manier creëer je de operator resource(s) in de istio-system namespace. Je zou nu een pod moeten zien werken.

Zoals je kunt zien, wordt een nieuwe CustomResourceDefinition met de naam istiooperators.install.istio.io aangemaakt. Dit is een blauwdruk die bepaalt hoe resource-definities aan de cluster moeten worden toegevoegd. Om config aan te maken, moeten we weten welke 'soort' config de CRD verwacht.

Laten we een eenvoudig config-bestand aanmaken.

Zodra de ResourceDefinition die de configuratie bevat, aan de cluster is toegevoegd, zorgt de operator ervoor dat de resources in de cluster overeenkomen met wat er in de configuratie werd gedefinieerd. Je zult zien dat er nieuwe resources worden aangemaakt.

Omdat ik een klein soort cluster uitvoer, kan de istiod-pod niet ingepland worden en zit hij vast in een Pending-status. Ik zal eerst het proces uitleggen voor ik dat verander.

De istio-operator zal het IstioOperator-configuratiebestand in de gaten blijven houden om te zien of er wijzigingen optreden. Als er wijzigingen worden aangebracht in het bestand, zal hij alleen die wijzigingen doorvoeren die nodig zijn om de resources in de cluster bij te werken, zodat ze overeenkomen met de status die in het configuratiebestand is gespecificeerd. Dit gedrag wordt reconciliation genoemd.

Laten we de status van het IstioOperator-configuratiebestand even bekijken. Deze wordt aangemaakt in de istio-system namespace.

Zoals je kunt zien, is de reconciliation hier nog aan de gang omdat de pod niet kan starten. Uiteindelijk zal deze in ERROR-status gaan.

Je kunt ook de istio-operatorlog bekijken voor nuttige informatie.

kubectl -n istio-operator logs istio-operator-564d46ffb7-nrw2t --tail 20

- Processing resources for Istiod.

- Processing resources for Istiod. Waiting for Deployment/istio-system/istiod

✘ Istiod encountered an error: failed to wait for resource: resources not ready after 5m0s: timed out waiting for the condition.

Aangezien ik een kleine democluster uitvoer, zal ik de geheugenlimiet bijwerken zodat de pod ingepland kan worden. Dit wordt gedaan binnen de spec: een deel van de IstioOperator-definitie.

kubectl -n istio-system edit istiooperator istio-controlplane

spec:

  profile: minimal

  components:

pilot:

  k8s:

     resources:

       requests:

         memory: 128Mi

De IstioOperator zal terugkeren naar een status van RECONCILING.

En na verloop van tijd wordt hij HEALTHY.

Je kunt zien dat de istiod-pod wordt uitgevoerd.

Naast de istiod deployment werden er ook veel nieuwe CRD’s toegevoegd.

Hoe de operator werkt – samenvatting

Zoals je kunt zien, is dit een heel eenvoudige manier om snel istio in te stellen binnen onze cluster. Kort samengevat, zijn dit de stappen:

1. Installeer de operator.
2. Een (of meer) CustomResourceDefinition(s) wordt (worden) toegevoegd als blauwdruk voor de objecten die kunnen worden aangemaakt/beheerd. Er wordt een deployment aangemaakt, die op zijn beurt een pod creëert die de configuraties monitort van de soorten die door de CRD werden gespecificeerd.
3. De gebruiker voegt een configuratie toe aan de cluster, met het door de CRD gespecificeerde type.
4. De operator-pod merkt de nieuwe configuratie op en onderneemt alle stappen die nodig zijn om ervoor te zorgen dat de cluster zich in de gewenste status bevindt die door de configuratie werd gespecificeerd.

Voordelen van de operatoraanpak

De operatoraanpak maakt het makkelijk om een reeks resources zoals Deployments, Jobs, CustomResourceDefinitions, ... te bundelen. Op die manier is het eenvoudig om extra gedrag en mogelijkheden toe te voegen aan Kubernetes.

Je vindt een bibliotheek met een lijst van de beschikbare operators op https://operatorhub.io/, met 255 operators op het moment van schrijven. De operators worden meestal geïnstalleerd met slechts een paar commando's of enkele regels code.

Het is ook mogelijk om je eigen operators te creëren. Het kan interessant zijn om een reeks Deployments, Jobs, CRD’s, ... die een specifieke functionaliteit bieden, te bundelen als een operator. De operator kan worden behandeld als operatoren en pijplijnen gebruiken voor CVE-validaties, E2E-tests, roll-outs naar testomgevingen, ... voordat een nieuwe versie in productie gaat.

Valkuilen

Binnen de ACA Group gebruiken we Kubernetes al een hele tijd en in die periode hebben we een aantal best practices omtrent beveiliging verzameld. We hebben gemerkt dat one-file-deployments en helm charts van het internet meestal niet zo goed geconfigureerd zijn als we zouden willen. Denk maar aan RBAC-regels die te veel toestemmingen geven, resources die momenteel niet namespaced zijn of containers die als root worden uitgevoerd.

Als je operators van operatorhub.io gebruikt, vertrouw je er in principe op dat de leverancier of provider best practices omtrent beveiliging naleeft. Maar een van de lezingen op KubeCon 2022 die me het meest is bijgebleven, ging er net over dat heel wat operators beveiligingsproblemen hebben. Bekijk dus zeker eens Tweezering Kubernetes Resources: Operating on Operators - Kevin Ward, ControlPlane voor je begint te installeren.

Daarnaast hebben we gemerkt dat het gebruik van operators het implementatieproces van nieuwe tools en functies kan versnellen. Lees er zeker de documentatie van de ontwikkelaar van een operator op na voordat je je aan geavanceerde configuratie waagt. Mogelijk zijn niet alle functies ook effectief geïmplementeerd in de CRD die door de operator werd aangemaakt. Het is echter een slecht idee om de resources die door de operator werden gecreëerd, rechtstreeks te manipuleren. De operator werd niet getest op manuele wijzigingen en dit zou dus inconsistenties kunnen veroorzaken. Bovendien kunnen nieuwe versies van de operator je wijzigingen (gedeeltelijk) ongedaan maken, wat ook tot problemen kan leiden.

Op dat punt zit je eigenlijk vast, tenzij je je eigen operator maakt die extra functies biedt. We hebben ook vastgesteld dat er geen echte ‘spelregels’ zijn voor de aanmaak van CRD’s en dat documentatie niet altijd makkelijk te vinden of te begrijpen is.

Conclusie

Operators zijn momenteel het gespreksonderwerp binnen de Kubernetes-community. Het aantal beschikbare operators neemt snel toe, waardoor het makkelijk is om functionaliteit toe te voegen aan je cluster. Regels of een minimale kwaliteitsnorm zijn er echter niet. Controleer daarom de inhoud wanneer je operators van de operatorhub installeert of valideer de gecreëerde resources op een lokale set-up. We verwachten ons in de nabije toekomst nog aan enkele wijzigingen en verbeteringen, maar op dit moment kunnen ze al erg nuttig zijn.