Why deploying an API Management platform on Kubernetes is a good idea

API Management is a crucial part of a modern business architecture. It provides governance, discoverability, enhanced security, observability, and auditing for your APIs. When we talk about APIs, we don’t just think of REST APIs. Modern API Management solutions support not only HTTP but also other protocols such as Kafka, MQTT, and websockets. Some even support low-level TCP communication. APIs form the foundation of modern system integration.

As you can see in the above diagram, a typical API Management platform consists of multiple components, such as a gateway, a management portal, and a developer portal. For various reasons (such as security and availability), it makes sense to host these components on different (virtual) machines. But this can lead us to a large number of virtual machines, especially considering that certain components need to be deployed multiple times, for instance, if we want to support multiple environments or if we want a highly available solution.

Fortunately, there is another (and better) solution than setting up and managing countless virtual machines to host applications.

Instead of hosting application components on different (virtual) machines, it is often more efficient to package them as independent units that can then run on the same machine. We call these units containers, and this can be achieved using Docker technology.

What is a container?

A container is a single workload (for example: a microservice, a database, a web server, …) that is packaged along with all its dependencies in a standardized way (OCI) and can run anywhere (cloud, desktop, VMs, Kubernetes clusters, …). It requires a container runtime to manage the container's lifecycle (create, start, stop, destroy).

The benefits

• Lightweight: containers share the host operating system kernel, meaning they consume fewer resources compared to VMs
• Portable: build once, run anywhere (requires a container runtime engine)
• Repeatable: deploy the same container multiple times with the same result
• Fast: creating and destroying containers is a lightweight operation
• Integrates seamlessly with both infrastructure as code (IaC) and the DevSecOps way of working 

Managing the containers

As the number of workloads running in containers grows, manually maintaining them becomes a nightmare. Aspects like high availability, scaling, scheduling, and task distribution all need to be configured and maintained manually. Therefore, the industry has devised a new type of platform that maintains and orchestrates containers for you: Kubernetes.

The goal of Kubernetes is to run and orchestrate containers. These containers can be containerd, cri-o or Docker containers.

Why Kubernetes?

Like any technology, containers come with many benefits, but they are not a cure-all and bring their own challenges. Some solutions/additional advantages that Kubernetes offers when working with containers are as follows:

Container orchestration

• Problem: Manually managing individual containers at medium/large scale is difficult. Containers need to be deployed, scaled, monitored, and updated.
• Solution: Kubernetes automates container management. It schedules containers, ensures high availability, and handles scaling seamlessly.

Service discovery and load balancing

• Problem: How do containers find each other in a dynamic environment? How do we distribute traffic among them?
• Solution: Kubernetes provides DNS-based service discovery and an integrated load balancer. Containers can communicate via service names.

Scaling and self-healing

• Problem: Containers crash and traffic and load fluctuate. How do we deal with these scenarios?
• Solution: Kubernetes monitors containers and automatically restarts failed containers. It scales up or down based on demand.

Rolling updates and rollbacks

• Problem: Deploying new versions without downtime or rolling back to a previous version can be tricky.
• Solution: Kubernetes supports rolling updates, where old containers are gradually replaced by new ones. Rolling back is also seamless.

Storage orchestration

• Problem: Containers need persistent storage. How do we handle volumes?
• Solution: Kubernetes abstracts storage with Persistent Volumes (PVs) and Persistent Volume Claims (PVCs).

The control plane has an API server (REST API) that is used by tools like kubectl to communicate with the cluster through manifest files and commands. The API server collaborates with other components of the control plane, such as etcd, scheduler, cloud manager, and controller manager to maintain the desired state configuration (deployments, services, cron jobs, … active).
 
The desired state configuration (DSC) reflects the wishes of the application owner that were specified during deployment regarding the status of the workload. The Kubernetes cluster will always strive to meet these requirements. This means that in the event of an incident, for example if a worker node becomes unavailable, the cluster automatically re-evaluates the current status against the DSC and takes action to restore the cluster and the workloads running on it back to their DSC.
 
Compared to the traditional deployment model (native installation or using Docker on a set of VMs) where failover and HA had to be designed, installed, monitored, and managed separately for each workload, this now only needs to be managed once at the Kubernetes cluster level and is then available for all workloads running within the cluster.

• etcd is the configuration store
• cloud manager serves as a bridge between the cluster and the cloud provider's own management APIs for things like load balancers, vaults, ...
• controller manager is responsible for bringing and keeping the cluster in the so-called Desired State Configuration (DSC)
• scheduler is a crucial component for bringing and keeping the server in its DSC 

The worker nodes are responsible for executing the workloads. A pod is the smallest deployable unit and can run one or more containers (side cars, init containers). Each worker node has a container engine for running the containers. The kubelet component is the link between the control plane and the worker node.

Since the first general availability of Kubernetes in 2016, adoption by the global market has steadily increased. Kubernetes is now widely used by enterprises of all sizes. Market adoption has benefited from the fact that all (major) cloud providers today offer Kubernetes as a service (AKS, EKS, GKS, Nutanix, Akamai, …). This allows small to medium-sized organisations to use Kubernetes without needing to hire additional staff. The decision to choose a cloud service offering is driven by the availability of internal expertise necessary to run Kubernetes.
 
With the adoption of Kubernetes, we see a shift of both legacy and containerised workloads from running on VMs to the Kubernetes cluster. This shift, from an operational perspective, to Kubernetes makes perfect sense, as it alleviates the pressure on your operational team that deals with maintaining a large number of VMs. Consider tasks like keeping the operating system up to date, applying the latest security patches, and doing all of this without disrupting the normal operation of the highly available workload. But, there is always a but 😉, Kubernetes itself is a complex technology that requires good vision, planning, preparation, and skilled and trained personnel to set it up correctly.

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 je wil voor jouw 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 jou 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:

• je moet vooraf weten hoeveel trafiek/belasting er zal zijn, om te bepalen hoeveel API-gateways nodig zijn. Er is geen oplossing voor geautomatiseerde schaalbaarheid.
• je 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.
• je moet handmatig een container starten/maken die plotseling is gestopt/gecrasht.
• je 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.

Kubernetes is the perfect deployment technology for API Management solutions. It addresses many important non-functional requirements out-of-the-box. If your organisation already uses Kubernetes for other workloads, it's definitely worth checking whether your APIM provider supports Kubernetes. If so, you might consider moving it to your Kubernetes cluster.

Want to know more?