Waarom een API Management platform deployen op Kubernetes een goed idee is

In deze blog bespreken we twee verschillende concepten. Enerzijds API Management, een type platform dat het ontwerpen, beveiligen, beheren, documenteren, ontdekken en analyseren van API's ondersteunt. Anderzijds Kubernetes, een platform dat het mogelijk maakt om container-workloads efficiënt te orkestreren. Tot slot ontdekt u waarom het een goed idee is om uw API Management platform op Kubernetes te deployen. Laten we er meteen in duiken!

API Management

API Management is een cruciaal onderdeel van een moderne bedrijfsarchitectuur. Het biedt governance, discoverability, verbeterde beveiliging, observatie en auditing voor uw API's. Als we het over API’s hebben, denken we overigens niet alleen aan REST API’s. Moderne API Management-oplossingen ondersteunen niet alleen HTTP, maar ook andere protocollen zoals Kafka, MQTT en websockets. Sommigen ondersteunen zelfs TCP-communicatie op laag niveau. API's vormen de basis van moderne systeemintegratie.

Zoals u in het bovenstaande schema kunt zien, bestaat een typisch API Management-platform uit meerdere componenten, zoals een gateway, een beheerportaal en een ontwikkelaarsportaal. Om verschillende redenen (zoals veiligheid en beschikbaarheid) is het zinvol om deze componenten op verschillende (virtuele) machines te hosten. Maar dan kunnen we op een groot aantal virtuele machines uitkomen, zeker als we er rekening mee houden dat bepaalde componenten meerdere keren ingezet moeten worden, bijvoorbeeld als we meerdere omgevingen willen ondersteunen of als we een highly available oplossing willen.

Gelukkig is er een andere (en betere) oplossing dan het inrichten en beheren van talloze virtuele machines om applicaties te hosten.

Wat is een container?

Een container is een enkele werklast (bijvoorbeeld: een microservice, een database, een webserver, …) die samen met al zijn afhankelijkheden op een gestandaardiseerde manier (OCI) is verpakt en overal kan draaien (cloud, desktop, VM’s, Kubernetes-clusters, …). Het vereist een containerruntime om de levenscyclus van de container te beheren (maken, starten, stoppen, vernietigen).

De voordelen

• Lightweight: containers delen de host-besturingssysteemkernel, wat betekent dat ze minder hulpbronnen verbruiken in vergelijking met VM's
• Portable: één keer bouwen, overal gebruiken (vereist een container runtime engine)
• Herhaalbaar: zet dezelfde container meerdere keren in met hetzelfde resultaat
• Snel: het aanmaken en vernietigen van containers is een lightweight operatie
• Integreert perfect met zowel de infrastructuur als code (IaC) als de DevSecOps manier van werken

Het beheren van de containers

Wanneer de hoeveelheid werklasten die in containers worden uitgevoerd groeit, wordt het handmatig onderhouden ervan een nachtmerrie. Zaken als high availability, scaling, planning en taakverdeling moeten allemaal handmatig worden geconfigureerd en onderhouden. Daarom heeft de industrie een nieuw type platform bedacht dat containers voor u onderhoudt en orkestreert: Kubernetes.

Wat is Kubernetes?

Het doel van Kubernetes is het draaien en orkestreren van containers. Deze containers kunnen containerd, cri-o of Docker containers zijn.

Waarom Kubernetes?

Zoals bij elke technologie brengen containers veel voordelen met zich mee, maar ze zijn geen wondermiddel en brengen hun eigen uitdagingen met zich mee. Enkele oplossingen/extra voordelen die Kubernetes biedt bij het werken met containers zijn de volgende:

Containerorkestratie

• Probleem: Het handmatig beheren van individuele containers op middelgrote/grote schaal is moeilijk. Containers moeten worden ingezet, geschaald, gemonitord en bijgewerkt.
• Oplossing: Kubernetes automatiseert containerbeheer. Het plant containers, zorgt voor een hoge beschikbaarheid en verwerkt de schaalbaarheid naadloos.

Servicedetectie en taakverdeling

• Probleem: Hoe vinden containers elkaar in een dynamische omgeving? Hoe verdelen we het verkeer over hen?
• Oplossing: Kubernetes biedt op DNS gebaseerde servicedetectie en een geïntegreerde load balancer. Containers kunnen communiceren via servicenamen.

Scaling en self-healing

• Probleem: Containers crashen en het verkeer en de belasting fluctueert. Hoe gaan we om met deze scenario’s?
• Oplossing: Kubernetes houdt containers in de gaten en start mislukte containers automatisch opnieuw op. Het schaalt op of af op basis van de vraag.

Rollende updates en rollbacks

• Probleem: Het implementeren van nieuwe versies zonder downtime of het terugkeren naar een eerdere versie kan lastig zijn.
• Oplossing: Kubernetes ondersteunt rolling updates, waarbij oude containers geleidelijk worden vervangen door nieuwe. Terugdraaien gaat ook naadloos.

Opslagorkestratie

• Probleem: Containers hebben permanente opslag nodig. Hoe gaan we om met volumes?
• Oplossing: Kubernetes abstraheert opslag met Persistent Volumes (PV's) en Persistent Volume Claims (PVC's).

Het control plane beschikt over een API-server (REST API) die door tools als kubectl wordt gebruikt om met de cluster te communiceren door middel van manifestbestanden en opdrachten. De API-server werkt samen met andere componenten van het control plane, zoals etcd , planner , cloud manager en controller manager om de gewenste statusconfiguratie (implementaties, services, cronjob, … actief) te behouden.

De desired state configuration (DSC) weerspiegelt de wensen van de applicatie-eigenaar die tijdens de implementatie zijn opgegeven met betrekking tot de status van de werklast. De Kubernetes-cluster zal die vereiste te allen tijde proberen tegemoet te komen. Dit betekent dat in het geval van een incident, bijvoorbeeld als een worker node niet meer beschikbaar is, de cluster automatisch de huidige status opnieuw evalueert aan de hand van de DSC en actie onderneemt om de cluster en de werklasten die erop draaien, terug te brengen naar hun DSC.

Vergeleken met het traditionele implementatiemodel (native installatie of het gebruik van docker op een set VM's) waarbij failover en HA voor elke werklast afzonderlijk moesten worden ontworpen, geïnstalleerd, gemonitord en beheerd, hoeft dit nu slechts één keer te worden beheerd op het Kubernetes clusterniveau en is vervolgens beschikbaar voor alle werklasten die binnen de cluster worden uitgevoerd.

• etcd is het configuratiearchief
• cloud manager fungeert als brug tussen de cluster en de eigen beheer-API's van de cloud provider voor zaken als load balancers, vaults, ...
• controller manager is verantwoordelijk voor het in de zogenaamde Desired State Configuration (DSC) brengen en houden van de cluster
• planner is een cruciaal onderdeel om de server in zijn DSC te brengen en te houden

De worker nodes zijn verantwoordelijk voor het uitvoeren van de werklasten. Een pod is de kleinste inzetbare eenheid en kan één of meerdere containers (side cars, init-container) laten draaien. Elke worker node heeft een container engine voor het uitvoeren van de container. De kubelet- component is de koppeling tussen de control plane en de worker node.

Huidige marktstatus

Sinds de eerste algemene beschikbaarheid van Kubernetes in 2016 is de adoptie door de mondiale markt gestaag toegenomen. Kubernetes wordt nu op grote schaal toegepast door ondernemingen van elke omvang. De marktadaptatie heeft geprofiteerd van het feit dat alle (grote) cloudproviders vandaag de dag Kubernetes as a service aanbieden (AKS, EKS, GKS, Nutanix, Akamai, …). Hierdoor kunnen kleine tot middelgrote organisaties Kubernetes gebruiken zonder extra personeel in te huren. De beslissing om voor een cloudserviceaanbod te kiezen wordt ingegeven door de beschikbaarheid van interne expertise die nodig is om Kubernetes te laten draaien.

Met de adoptie van Kubernetes zien we een verschuiving van zowel oudere als gecontaineriseerde workloads van het draaien op VM’s naar de Kubernetes cluster. Deze verschuiving, vanuit operationeel oogpunt, naar Kubernetes is heel logisch, omdat het de druk verlicht op uw operationele team dat te maken heeft met het onderhouden van een groot aantal VM’s. Denk aan taken als het up-to-date houden van het besturingssysteem, het toepassen van de nieuwste beveiligingspatches en dat alles zonder de normale werking van de hoge beschikbare werklast te verstoren. Maar, er is altijd een maar 😉, Kubernetes zelf is een complexe technologie die vraagt om een goede visie, planning en voorbereiding en bekwaam en opgeleid personeel om het zelf op te zetten.

Waarom wij vinden dat u uw API Management platform op Kubernetes moet deployen

Nu we de concepten en voordelen van zowel API Management-platforms als het Kubernetes-platform hebben uitgelegd, is de voor de hand liggende volgende vraag: moeten we de API Management-componenten deployen en uitvoeren op een Kubernetes-cluster?
De meeste APIM-leveranciers ondersteunen de implementatie van hun oplossing op Kubernetes. Gravitee is een voorbeeld. IBM's API Connect gaat zelfs nog een stap verder en kan uitsluitend op een Kubernetes-cluster worden ingezet.

De voordelen

Resilience

Een k8s-cluster is (doorgaans) veerkrachtig ingesteld en biedt hoge beschikbaarheid voor de werklasten die binnen de cluster worden uitgevoerd. Dat is precies wat u wilt voor uw API Gateways. Dit is dus een perfecte match. Voer uw API Gateway-implementatie eenvoudig uit met een aantal replica's > 2 en de cluster zal het werk voor u doen.

Schaalbaarheid

VM-bronnen (geheugen, CPU, netwerkbandbreedte) voor workloads met zeer volatiele gebruiksstatistieken zijn traditioneel te groot om piekbelastingen op te vangen. Het implementeren van horizontale schaling met VM's vereist gespecialiseerde vaardigheden en is voor de meeste IT-teams niet eenvoudig te realiseren. Kubernetes schiet te hulp…
Horizontale schaling in Kubernetes is automatisch beschikbaar via automatisch schalen. Er zijn geen gespecialiseerde vaardigheden vereist om deze functionaliteit te gebruiken. De gebruiksstatistieken worden verzameld en actief bewaakt door de cluster om uw workloads naar boven of naar onder te schalen.
Op dezelfde manier is verticale schaling beschikbaar via declaratieve resource requests en limietdefinities, die automatisch door de cluster worden afgehandeld. Dit leidt tot een beter/geoptimaliseerd gebruik van resources en vooral tot stabiele responstijden voor uw API's.

Horizontaal schalen kan erg handig zijn voor een aantal APIM-componenten:

• API Gateway (dit is een no-brainer)
• Ontwikkelaarsportaal (openbaar beschikbaar) waar de verkeersbelasting een grote variatie kent

Eenvoudig beheer

Containers hebben het een stuk eenvoudiger gemaakt om software te installeren en te upgraden. Geen gedoe meer met incompatibele bibliotheken en andere afhankelijkheden. Tools als Helm, FluxDB en Argo CD (GitOps for Kuberneters) maken het nog eenvoudiger om complexe oplossingen met meerdere componenten te installeren.

Uniforme monitoring en alerting

Een belangrijk onderdeel van elk oplossingsontwerp is het implementeren van een goede monitoring- en alertingoplossing. Dit is niet anders voor workloads die op Kubernetes draaien. Het feit dat de implementatietechnologie wordt gedeeld tussen verschillende workloads betekent dat een uniforme monitoring- en alertingoplossing voor al deze workloads kan (opnieuw) worden gebruikt. Gebruik de ingebouwde instrumentatieoplossing van Kubernetes of gebruik/combineer deze met een third party monitoring-/logoplossing die in de cluster kan worden geïntegreerd.

Use case

Beschouw een traditionele HA-oplossing waarbij u minimaal twee VM's opstart met op elk daarvan een API-gateway. Voor de gateways wordt een load balancer geplaatst om de beschikbaarheid te monitoren en de trafiek over de beschikbare gateways te verdelen.

Er zijn veel dingen die u moet doen/weten om een dergelijke oplossing op te zetten:

• U moet vooraf weten hoeveel trafiek/belasting er zal zijn, om te bepalen hoeveel API-gateways nodig zijn. Er is geen oplossing voor geautomatiseerde schaalbaarheid.
• U moet ook monitoring (VM en container) instellen om ervoor te zorgen dat er altijd minimaal 1 load balancer en 1 API-gateway actief zijn. Er is geen sprake van self-healing met deze oplossing.
• U moet handmatig een container starten/maken die plotseling is gestopt/gecrasht.
• U moet de VM's in verschillende patch-/onderhoudsgroepen groeperen om downtime als gevolg van gepland onderhoud te voorkomen.

Andere voordelen

De overstap naar Kubernetes brengt ook nieuwe mogelijkheden voor APIM-leveranciers met zich mee.

Een goed voorbeeld is de Gravitee Kubernetes Operator (GKO) die het Kubernetes-operatorpatroon gebruikt om vereenvoudigd API-definitiebeheer te benutten met behulp van zogenaamde Custom Resource Definitions (CRD's). Dit leidt tot een vereenvoudigd APIM-deploymentmodel (geen configuratiedatabase vereist) dat beter past bij de moderne DevSecOps-manier van werken. Een API-definitie kan op een echt declaratieve manier (GitOps) worden beheerd via een CRD-manifestbestand (yaml).

Valkuilen

Zelfbeheerde Kubernetes-clusters zijn moeilijk op te zetten en te onderhouden. Er is een team van hoogopgeleide en getrainde professionals voor nodig om het op te zetten en draaiende te houden. Gelukkig zijn er voor degenen die niet over het vereiste team beschikken, veel goede cloudserviceproviders die beheerde Kubernetes Engines als service aanbieden.

API Management draait in de kern om protocolbemiddeling en het proxyen (http/tcp/…) van netwerkverkeer. Ingress en interne clusternetwerken moeten correct worden ingesteld, zodat verkeer op een veilige en performante manier tussen de API-abonnee en de backend-service (noord-zuid-verkeer) kan stromen.
Het opzetten van externe gebruikersauthenticatie en rolmapping met een bestaande (derde partij) IAM-oplossing die gebruik maakt van het OIDC-protocol dat binnen of buiten de kubernetes cluster draait, kan ook een uitdaging zijn.

Conclusie

Kubernetes is de perfecte deploymenttechnologie voor API Management-oplossingen. Het lost veel belangrijke niet-functionele vereisten out-of-the-box op. Als uw organisatie Kubernetes al voor andere workloads gebruikt, is het zeker de moeite waard om te controleren of uw APIM-leverancier Kubernetes ondersteunt. Als dit het geval is, kunt u overwegen om het naar uw Kubernetes-cluster te verplaatsen.

Geschreven door Steven Janssens, Integration and Solution Architect bij AXI