Autoscaling WSO2 API Gateway and WSO2 Choreo Connect on Kubernetes — Part 1
Introduction
Is it cloud-native ? Does it support containerization? Can it be scaled automatically and dynamically? These are some of the most compelling questions Solutions Architects are often curious about nowadays when they are evaluating new pieces of software applications. It has become a practice of most IT firms who are building world-class software to often design their applications in such a way that their applications answer the aforementioned most commonly asked questions. We will focus on the API Management domain and see how WSO2 API Manager and WSO2 Choreo Connect (Evolution of the WSO2 Microgateway) support the above architectures.
Both WSO2 API Manager[1] and WSO2 Choreo Connect[2] have evolved architecturally over the years to provide optimum deployment patterns which enable the foundation to achieve the answers to the above questions. After the release of WSO2 API Manager 4.0.0 it has simplified the deployment by absorbing some components into single components which has expedited the ability to deploy architectures rapidly.
- Control Plane — Encompasses API Publisher for API Development, API DevPortal for API consumers, and a Resident Key Manager for API Key Management
- API Gateway — Caters API traffic.
- Traffic Manager — Regulates API traffic and makes the APIs and Subscriptions available for the API Gateways and secures the API Gateways from attacks. Traffic Manager can also be deployed as a part of the Control Plane to further simplify the deployment.
Similarly, the WSO2 Choreo Connect is also implemented following a component-based architecture where it answers the above questions as well. The main components of Choreo Connect are listed below.
- Router — Routing API traffic from consumers to backends. Choreo Connect uses Envoy Proxy [3] as the underlying routing engine.
- Enforcer — Provides API QoS aspects such as security, rate limiting, analytics, and validation.
- Adapter —Responsible for translating and deploying the API definitions and QoS parameters in the router and the enforcer.
This post illustrates how WSO2 API Manager and Choreo Connect can be deployed on Kubernetes in a distributed manner with a single control plane and how the gateways can be independently scaled based on CPU metric.
Target Deployment Architecture
The following depicts the target architecture.
Creating a Kubernetes cluster in AWS EKS using eksctl tool
- Install eksctl tool in your computer using the relevant steps for your operating system.
2. Create a Kubernetes cluster in AWS EKS using the following command.
eksctl create cluster — name wso2-apim — version 1.21 — region ap-south-1 — nodegroup-name wso2-apim-node-group — node-type c5.2xlarge — nodes 3Note: Use the command aws configure to configure your AWS CLI using a generated AWS APIKey and a SecretKey generated for your account. eksctl will deploy the EKS cluster in the currently configured AWS CLI environment
Eksctl sets the created k8s cluster as the current context in the .kube/config file so that your kubectl command will work seamlessly with the newly created cluster.
Deploy WSO2 API Manager in the created kubernetes cluster
- Install helm version 3 in your computer using the relevant steps for your operating system.
2. Install kubectl on your computer using the relevant steps for your operating system.
3. Checkout the kubernetes-apim git repository and checkout the relevant tag. For this document we will checkout the v4.0.0.3 tag.
4. In this example we will be deploying am-pattern-3 of the kubernetes-apim repository.
5. Install the nginx ingress controller in your kubernetes environment.
6. Update the values.yaml file with your credentials to download images. Install the helm chart in the kubernetes cluster.
helm dependency update <KUBERNETES-APIM_REPO-HOME>/advanced/am-pattern-3/ && helm install wso2-apim <KUBERNETES-APIM_REPO-HOME>/advanced/am-pattern-3 — version 4.0.0–3 — namespace wso2 — create-namespaceWait for a while and confirm that all the pods in the wso2 namespace are up and running and are on Ready state.
7. List the ingresses deployed in the namespaces used above.
kubectl get ing -n wso2
8. Update the host file with the following hostnames and the ingress ip.
113.109.225.55 am.wso2.com113.109.225.55 gateway.am.wso2.com
9. Now you should be able to access the carbon, publisher, devportal and the admin apps via the am.wso2.com host. (e.g. https://am.wso2.com/publisher)
Note: The above will deploy the vanilla API Manager 4.0.0 with CP and GW separated. If you want to use a particular update level, you can find it via https://docker.wso2.com/tags.php?repo=wso2am and configure it in the values.yaml file in the helm chart. E.g. imageTag: “4.0.0.102”. You will need to have a valid and active WSO2 subscription to do this.
This marks the end of Part 1. Check out Part 2 from below link to learn how to deploy Choreo Connect and integrate with the same Control Plane.
References
[1] https://wso2.com/api-manager/
