Ondernemers hebben de cloud steeds meer nodig. Ze vereisen cloud computing-services die snel inzetbaar, flexibel en robuust zijn. Maar waar al deze eigenschappen eigenlijk op neerkomen, is het feit dat bedrijven cloud computing-services willen die schalen. Remy Vandepoel, technical cloud evangelist bij OVHcloud, legt uit hoe Kubernetes Operator-tool bijdragen aan dit proces. Maar wat is deze technologie, hoe past het in de wereld van microservices en wat moeten we weten over de kracht ervan?
Een Kubernetes-operator is een methode om een Kubernetes-applicatie te verpakken, in te zetten en te beheren, legt Red Hat uit. Een Kubernetes-applicatie wordt zowel ingezet op Kubernetes als beheerd met behulp van de Kubernetes API (Application Programming Interface) en kubectl-tooling.
Nu meer dan tweederde van de organisaties microservices gebruikt, concludeert Vandepoel dat bedrijven wereldwijd al erg profiteren van containerisatie. Deze ontwikkeling is mogelijk gemaakt door Docker, oorspronkelijk opgericht als DotCloud in 2008. Toch liggen de echte wortels van microservices bij SOA en SOAP, dat al van de jaren ’90 afstamt.
De mogelijkheid om een grote, monolithische applicatie op te splitsen in een groot aantal kleinere, meer flexibele componenten, heeft bedrijven in staat gesteld om veel flexibeler te zijn. Dit maakt het mogelijk om afzonderlijke delen van de applicatie te monitoren, beheren, verbeteren of omwisselen. Essentieel is dat dit onafhankelijk kan plaatsvinden van de rest van de functionaliteit.
“Dit betekent echter ook meer complexiteit voor DevOps-teams,” zegt Vandepoel. “Kubernetes helpt hier tot op zekere hoogte bij door containers te orkestreren, routinetaken op te pakken en deze te automatiseren. Echt complexe implementaties vereisen alleen veel meer werk. We hebben het niet alleen over twintig of dertig microservices voor één applicatie. Het gaat mogelijk zelfs over duizenden hiervan voor meerdere applicaties, servers en regio’s. Voor elk object moet DevOps dus een oplossing vinden. Dus ook voor elk object moet DevOps de ingress, services, uitrol, upgrades, testen enzovoort beheren.”
Tip: Microsoft AKS ondersteunt nu ook Kubernetes 1.29
Software neemt het roer over
Dit is waar verdere automatisering om de hoek komt kijken. Het OVHcloud-team zegt dat ze hebben gezien dat veel gebruikers naar management suites zoals Helm grijpen om Kubernetes-packages te beheren. Helm is een handige tool die door veel software engineers wordt gebruikt. Het kan ontwikkelaars bijvoorbeeld voorzien van – onder andere – een globale grafiek die alle ingress services beschrijft. Het is ook een goede manier om de complexiteit te beheren als je rollbacks doet, maar het heeft zijn beperkingen.
“De belangrijkste beperking is dat Helm alleen echt helpt bij het installeren en upgraden van microservices. Het leven van het DevOps-team is veel complexer dan dat alleen. Menselijke operators hebben ondersteuning nodig gedurende de hele lifecycle van de applicatie, meten, inzichten verschaffen enzovoort, en Helm biedt geen lifecycle management voor de laatste paar fasen,” legt Vandepoel uit. “Wat we echt moeten doen, is meer automatiseren en idealiter een deel van de kennis van een menselijke operator opnemen in geautomatiseerde processen. Dit zou DevOps-medewerkers vrijmaken om te werken aan meer innovatieve taken en vermijden dat ze hun tijd besteden aan routine-activiteiten die weinig waard zijn.”
Controllers & aangepaste middelen
OVHcloud heeft het graag over dit vraagstuk, gemotiveerd door feedback uit gesprekken met klanten in daadwerkelijke implementatieomgevingen. Het bedrijf belicht daarbij de Kubernetes Operator-optie, die twee eenvoudige tools combineert. Ten eerste gebruikt het Kubernetes Controllers. Dit zijn ‘reconciliation loops‘ die de huidige status van een cluster kunnen bekijken. Vervolgens vergelijken ze die met de gewenste status die is opgeslagen in een .yaml-bestand. De controllers observeren, vinden het verschil en reageren daarop.
Lees ook: Red Hat zet breed aanbod cloud-native tools op de kaart
“Maar dit is niet altijd genoeg, omdat omgevingen vaak anders, nieuw of ongebruikelijk zijn en we systeemelementen niet altijd meteen kunnen beschrijven aan Kubernetes Operators,” verduidelijkt Vandepoel. “Dit is waar Custom Resource Definitions (CRD’s) om de hoek komen kijken. Met CRD’s kunnen we onze eigen API’s in een systeem introduceren, zodat we meer dan alleen containers kunnen beheren. Met CRD’s kun je bijvoorbeeld routers definiëren en beheren met behulp van Kubernetes. Kubernetes Operators combineren deze twee concepten. In feite coderen ze menselijke kennis binnen CRD’s, waarbij de systeemomgeving wordt gedefinieerd en vervolgens controllers worden toegepast om belangrijke taken te automatiseren.”
Hij geeft hier praktische voorbeelden van die te maken hebben met een vrij alledaagse taak: databasebeheer. Kijken naar database back-up kan een complexe taak zijn, maar door er logisch over na te denken, kan het worden geautomatiseerd. Vandepoel zegt dat we een CRD moeten definiëren om het databasecluster en elke instance weer te geven en vervolgens de controller moeten gebruiken om het proces te definiëren.
“De controller moet bijvoorbeeld controleren of het tijd is om een back-up te maken en als dat het geval is, moet hij het schrijven van data naar elke instance stopzetten. Dit is om ervoor te zorgen dat de back-up correct kan worden uitgevoerd. Vervolgens moet de controller de snapshot uitvoeren en opslaan in de juiste omgeving. Er kunnen andere nuances in het proces zitten omdat je omgeving altijd iets anders is, maar zoals de meeste processen is het in wezen een flowchart,” stelt hij.
Op dezelfde manier kunnen cloud-native ontwikkelaars Operators gebruiken om nieuwe database shards te maken. Ook hier gebruiken ze de CRD om het databasecluster en elke instance te representeren. Vervolgens gebruiken ze de controller om het proces te definiëren. In dit geval moet de controller controleren hoe vol elke instance is en dit vergelijken met de gewenste ‘state‘ om te beslissen of er al dan niet een nieuwe instance moet worden aangemaakt. Als de ‘load‘ dichtbij of boven de limiet is, dan wordt er een nieuwe shard aangemaakt.
Kies je eigen operator
“Operators kunnen zo eenvoudig of zo complex zijn als je nodig hebt, van basisinstallaties en upgrades tot volledige ‘automatische piloot’-gevallen, zoals het voorbeeld hierboven. Hierbij besluit een operator dat een databasecluster een nieuwe instance nodig heeft en het maakt deze zonder menselijke tussenkomst aan,” bevestigt Vandepoel. “Operators zijn relatief eenvoudig aan te maken. Je moet het project aanmaken en de CRD schrijven, de bronnen specificeren die in de gaten moeten worden gehouden en welke acties nodig zijn. En aan de andere kant moet je ook de ‘reconciliation logic‘ in de controllers definiëren, waarmee de overkoepelende operator wordt opgebouwd.”
Er zijn een aantal andere tools in deze ruimte die het leven makkelijker kunnen maken. Kubebuilder helpt bij het bouwen van API’s. Dit is een SDK voor het snel bouwen en publiceren van Kubernetes API’s in de programmeertaal Go. Het bouwt voort op de vertrouwde technieken om de kern-API’s van Kubernetes te bouwen. Dit biedt eenvoudige abstracties die boilerplate code en gezwoeg verminderen. Het OVHcloud-team zegt dat Operator Framework ook kan helpen. Deze technologie heeft een SDK die helpt bij het bouwen, testen en itereren in Helm, Ansible of Go. OperatorHub.io is ook de moeite waard omdat het al een groot aantal open-source operators heeft die zijn geschreven om je te helpen het wiel niet opnieuw uit te vinden.
Microservice migraine & vrolijkheid
OVHcloud biedt een grote verscheidenheid aan cloudservices. Het bedrijf kan ons dus een helder idee geven van de complexe aard van publieke en private cloudproducten, shared hosting en dedicated server-oplossingen. Het is actief in 140 landen en ziet dus alle mogelijke manieren waarop organisaties de cloud toepassen.
Het bedrijf is nog breder dan dat. Naast de cloudactiviteiten is het ook gespecialiseerd in domeinnaamregistratie, telefoniediensten en het eenvoudig opzetten van internettoegang. Vandepoel spreekt dus uit ervaring wanneer hij stelt dat microservices veel positiefs maar ook veel kopzorgen bieden. De klinkende boodschap hier is echter dat organisaties met de juiste tools en automatisering zelfs de meest ingewikkelde omgevingen kunnen temmen.
Beluister ook onze Techzine Talks-aflevering over Kubernetes na ons bezoek aan Kubecon + CloudNativeCon Europe 2024: