Ik begon deze blogpost te schrijven de dag nadat ik thuiskwam van KubeCon en CloudNativeCon 2022. Het belangrijkste wat me opviel was dat de inhoud van de gesprekken de afgelopen jaren is veranderd.
Als je kijkt naar de onderwerpen van KubeCon / CloudNativeCon van dit jaar, voelt het alsof veel vragen over Kubernetes, soorten cloud, logging tools en meer worden beantwoord voor de meeste bedrijven. Dat is logisch, want steeds meer organisaties hebben Kubernetes al met succes geïmplementeerd. Kubernetes wordt niet langer beschouwd als het volgende grote ding, maar eerder als de logische keuze. We hebben echter gemerkt (tijdens de gesprekken, maar ook in ons eigen traject) dat er nieuwe problemen en uitdagingen zijn ontstaan, die tot andere vragen leiden:
Een van de mogelijke manieren om functionaliteiten aan Kubernetes toe te voegen is het gebruik van Operators. In deze blogpost zal ik kort uitleggen hoe Operators werken.
Het concept van een operator is vrij eenvoudig. Ik denk dat de makkelijkste manier om het uit te leggen is door daadwerkelijk een operator te installeren.
Binnen ACA gebruiken we de istio operator. De exacte stappen van het installeren hangen af van de operator die je installeert, maar meestal lijken ze erg op elkaar.
Installeer eerst de istioctl binary op de machine die toegang heeft tot de Kubernetes api. De volgende stap is het uitvoeren van het commando om de operator te installeren.
Dit zal de operator resource(s) aanmaken in de istio-system namespace. Je zou een pod moeten zien draaien.
Zoals je kunt zien, is er een nieuwe CustomResourceDefinition genaamd istiooperators.install.istio.io gemaakt. Dit is een blauwdruk die specificeert hoe resource definities moeten worden toegevoegd aan het cluster. Om config aan te maken, moeten we weten welk 'soort' config de CRD verwacht aangemaakt te worden.
Laten we een eenvoudig configuratiebestand maken.
Zodra de ResourceDefinition die de configuratie bevat is toegevoegd aan het cluster, zal de operator ervoor zorgen dat de resources in het cluster overeenkomen met wat is gedefinieerd in de configuratie. Je zult zien dat er nieuwe resources worden aangemaakt.
Omdat ik een klein soort cluster draai, kan de istiod pod niet worden ingepland en staat deze vast in de status Pending. Laat me eerst het proces uitleggen voordat ik dit verander.
De istio-operator blijft het IstioOperator configuratiebestand in de gaten houden voor wijzigingen. Als er wijzigingen worden aangebracht in het bestand, zal het alleen de wijzigingen aanbrengen die nodig zijn om de bronnen in het cluster bij te werken zodat ze overeenkomen met de status die is gespecificeerd in het configuratiebestand. Dit gedrag wordt reconciliatie genoemd.
Laten we eens kijken naar de status van het configuratiebestand IstioOperator. Merk op dat het is aangemaakt in de istio-system naamruimte.
Zoals je kunt zien, is dit nog steeds aan het afstemmen, omdat de pod niet kan starten. Na enige tijd zal deze in een ERROR status gaan.
Je kunt ook de istio-operator log bekijken voor nuttige informatie.
kubectl -n istio-operator logs istio-operator-564d46ffb7-nrw2t --tail 20
- Verwerken van bronnen voor Istiod.
- Verwerking van middelen voor Istiod. Wachten op implementatie/istio-systeem/istiod
✘ Istiod kwam een fout tegen: wacht niet op bron: bronnen niet klaar na 5m0s: timed out wachten op de voorwaarde.
Aangezien ik een klein demo-cluster draai, zal ik de geheugenlimiet aanpassen zodat de POD ingepland kan worden. Dit wordt gedaan in het spec: deel van de IstioOperator-definitie.
kubectl -n istio-system edit istiooperator istio-controlplane
spec:
profiel: minimaal
componenten:
piloot:
k8s:
middelen:
aanvragen:
geheugen: 128Mi
De istiooperator gaat terug naar een RECONCILING status.
En na enige tijd wordt het HEALTHY.
Je kunt zien dat de istiod pod draait.
Afgezien van de istiod implementatie, zijn er ook veel nieuwe CRDs toegevoegd.
Zoals je kunt zien, is dit een zeer eenvoudige manier om istio snel in te stellen binnen ons cluster. In het kort zijn dit de stappen:
De operator-benadering maakt het eenvoudig om een verzameling resources zoals Deployments, Jobs, CustomResourceDefinitions te verpakken. Op deze manier is het eenvoudig om extra gedrag en mogelijkheden aan Kubernetes toe te voegen.
Er is een bibliotheek met een overzicht van de beschikbare operators die te vinden zijn op https://operatorhub.io/. Op het moment van schrijven zijn er 255 operators. De operators worden meestal geïnstalleerd met slechts een paar commando's of regels code.
Het is ook mogelijk om je eigen operatoren te maken. Het kan zinvol zijn om een set van deployments, jobs, CRD's, ... die een specifieke functionaliteit bieden te verpakken als een operator. De operator kan worden afgehandeld als operators en pipelines gebruiken voor CVE-validaties, E2E-tests, uitrol naar testomgevingen en meer voordat een nieuwe versie naar productie wordt gepromoot.
We gebruiken Kubernetes al lange tijd binnen de ACA Group en hebben in deze periode een aantal best-practices op het gebied van beveiliging verzameld. We hebben gemerkt dat one-bestand-deployments en helikopters van het internet meestal niet zo goed geconfigureerd zijn als we zouden willen. Denk aan RBAC regels die te veel rechten geven, resources die op dit moment geen namespaced hebben of containers die als root draaien.
Wanneer je operators van operatorhub.io gebruikt, vertrouw je er in principe op dat de leverancier of provider de best practices op het gebied van beveiliging volgt. Echter ... één van de gesprekken op KubeCon 2022 die de grootste indruk op me maakte, stelde dat veel van de operators problemen hebben met de beveiliging. Ik raad je aan om Tweezering Kubernetes Resources te bekijken : Operating on Operators - Kevin Ward, ControlPlane te bekijken voordat je gaat installeren.
Wat we ook hebben gemerkt is dat het gebruik van operators het proces om nieuwe tools en functies te implementeren kan versnellen. Zorg ervoor dat je de documentatie leest die is geleverd door de maker van een operator voordat je in de geavanceerde configuratie duikt. Het is mogelijk dat niet alle mogelijkheden daadwerkelijk zijn geïmplementeerd op het CRD dat is aangemaakt door de operator. Het is echter een slechte gewoonte om de bronnen die door de operator zijn aangemaakt direct te manipuleren. De operator is niet getest tegen je handmatige wijzigingen en dit kan inconsistenties veroorzaken. Bovendien kunnen nieuwe versies van de operator je wijzigingen (gedeeltelijk) ongedaan maken, wat ook problemen kan veroorzaken.
Op dat moment zit je in principe vast, tenzij je je eigen operator maakt die extra mogelijkheden biedt. We hebben ook gemerkt dat er geen echt 'regelboek' is over hoe CRD's aan te bieden en documentatie is niet altijd gemakkelijk te vinden of te begrijpen.
Operators zijn momenteel een hot topic binnen de Kubernetes-gemeenschap. Het aantal beschikbare operators groeit snel, waardoor het eenvoudig is om functionaliteit aan je cluster toe te voegen. Er is echter geen regelboek of een minimale basislijn van kwaliteit. Als je operators installeert vanaf de operatorhub, controleer dan de inhoud of valideer de aangemaakte resources op een lokale opstelling. We verwachten in de nabije toekomst enkele veranderingen en verbeteringen, maar op dit moment kunnen ze al erg nuttig zijn.