This article is based on technical content originally published on thenewstack.io, covering cloud-native API management patterns and the WSO2 API Manager 3.0 feature set.
APIs as the Foundation of Cloud-Native Businesses
APIs have become the essential building blocks of modern digital businesses. As organizations grow their reliance on microservices, containers, and cloud infrastructure, the demands placed on API management have evolved significantly. DevOps teams now need API management solutions that address the following challenges:
- Creating, publishing, and monetizing APIs and API products at scale.
- Maximizing application adoption and reuse across internal and external APIs.
- Enforcing consistent API security policies.
- Supporting cloud environments built on Kubernetes, microservices, service meshes, and CI/CD pipelines.
WSO2 API Manager 3.0 addresses these demands by introducing native Kubernetes support through a Kubernetes Operator and an API Microgateway — two capabilities that treat APIs as first-class citizens in a Kubernetes environment.
Kubernetes Operators: Extending Automation Beyond Core Kubernetes
Kubernetes is designed around automation, but as application complexity grows, so does the operational burden on DevOps teams. Native Kubernetes constructs are powerful but limited to general-purpose workload management. Kubernetes Operators extend that automation by combining two primitives:
- Custom Resources (CRDs): Define new API objects that represent domain-specific concepts — in this case, APIs, security policies, and rate-limiting rules.
- Custom Controllers: Watch those custom resources and reconcile the actual cluster state with the desired state, automating tasks that would otherwise require manual intervention.
This extensible architecture allows teams to encode operational knowledge — such as how to deploy an API microgateway — into the cluster itself, without modifying any core Kubernetes code. The result is repeatable, auditable deployments that reduce human error.
API Microgateway: Decentralized Policy Enforcement for Microservices
In a microservices architecture, applications are decomposed into small, independently deployable services organized around business capabilities. This model allows smaller, focused teams to build, test, and deploy services autonomously — but it also means API governance must be applied at the service boundary level, not just at a central gateway.
The WSO2 API Microgateway treats an OpenAPI definition as the single source of truth for each API. The OpenAPI specification contains all required information about an API — its paths, parameters, authentication requirements, and rate limits. By supplying this definition to the WSO2 API Microgateway toolkit, teams can generate a lightweight, purpose-built microgateway for that specific API, enforcing governance policies at the point of ingress.
WSO2 API Operator for Kubernetes: What It Solves
API developers typically want to focus on their domain — defining backend services, setting security policies, and configuring rate limits — not on Kubernetes internals such as pod scheduling or service discovery. The WSO2 API Operator bridges this gap by abstracting Kubernetes complexity while delivering the capabilities API teams actually need:
- Publishing APIs to a developer portal to build an API marketplace.
- Protecting and monetizing APIs through policy enforcement.
- Monitoring and analyzing API usage in real time.
- Generating business insights from API traffic data.
By providing an OpenAPI definition to the apictl (API Controller) command-line toolkit, the API Operator automatically deploys an API microgateway with the appropriate policy enforcement configured — no manual Kubernetes YAML authoring required for API-specific concerns.
Custom Resource Definitions Introduced by the API Operator
The WSO2 API Operator for Kubernetes introduces four Custom Resource Definitions (CRDs) that map directly to API management concepts:
| CRD | Purpose |
|---|---|
| Security | Holds security-related configuration such as authentication schemes and token validation settings. |
| RateLimiting | Defines rate-limiting policies to protect backend services from traffic overload. |
| TargetEndpoint | Describes the backend service being exposed, supporting multiple deployment patterns. |
| API | Holds the OpenAPI definition, replica count, and microgateway deployment mode for a given API. |
TargetEndpoint Deployment Patterns
The TargetEndpoint CRD supports three deployment patterns, giving teams flexibility depending on their architecture:
- Shared mode: Multiple APIs share a single microgateway instance, suitable for lower traffic or development environments.
- Private-jet mode: Each API gets its own dedicated microgateway instance, providing strong isolation for high-traffic or sensitive APIs.
- Sidecar mode: The microgateway runs in the same Kubernetes pod as the backend service, eliminating network hops between the gateway and the service.
If the backend service is already running and only needs to be exposed via a microgateway, the target URL can be defined directly in the Swagger/OpenAPI file. If the backend service is not yet running but will be deployed in the same Kubernetes cluster, the TargetEndpoint CRD can reference a Docker image, and the API Operator will automatically spin up the corresponding Kubernetes Deployment for that backend alongside the microgateway.
How the API Controller Automates Microgateway Builds
When a user applies an API custom resource to the cluster, the following sequence occurs automatically:
- The custom API Controller reads the OpenAPI definition from the referenced ConfigMap.
- It creates a Kaniko job — Kaniko is an open-source tool for building container images from a Dockerfile inside a container or Kubernetes cluster, without requiring a Docker daemon. This job uses a multi-step Dockerfile that includes the pre-built API Microgateway toolkit base image.
- The Microgateway toolkit processes the OpenAPI definition and generates the microgateway runtime configuration tailored to that API.
- Kaniko builds a new, API-specific microgateway Docker image and pushes it to the configured container registry.
- The API Controller then creates the required Kubernetes Deployments and Services for both the microgateway and backend services, based on the selected deployment mode.
This pipeline encodes deployment best practices into the operator itself, freeing DevOps engineers from manually orchestrating each step and reducing the surface area for configuration errors.
Installation and Getting Started
Installing the WSO2 API Manager 3.0 Kubernetes Operator is designed to be straightforward. The primary installation path involves applying the operator manifests to an existing Kubernetes cluster using kubectl. From there, teams download and configure apictl, the API Controller CLI, on their local machines to interact with the API management layer.
Full installation instructions, manifest files, and usage examples are available in the WSO2 Kubernetes API Operator Git repository. Always verify the current installation steps against the official repository, as procedures may have been updated since this article was written.
Key Takeaways
Kubernetes is rapidly becoming the de facto orchestration standard for cloud-native workloads. Managing APIs in this environment requires tooling that integrates natively with Kubernetes primitives rather than sitting alongside them as an afterthought. The WSO2 API Manager 3.0 approach — using a Kubernetes Operator with domain-specific CRDs — achieves this integration by:
- Giving API developers a familiar, API-centric interface rather than exposing raw Kubernetes complexity.
- Automating microgateway image builds and deployments through the Kaniko-based build pipeline.
- Supporting flexible deployment patterns (shared, private-jet, sidecar) to match diverse architectural requirements.
- Treating OpenAPI definitions as the authoritative source of truth for policy enforcement.
The net result is higher productivity for developers, DevOps engineers, and cloud administrators when building, deploying, and governing APIs at scale in a Kubernetes-native environment.