Discovering the Kubernetes Artifacts of the WSO2 API Manager deployment.
This is the follow up article of “First Steps to deploy WSO2 API Manager in Kubernetes”
In this article I am going to describe the Kubernetes artifacts which we used to deploy in the previous article and it can be found in the following git reprository.
Overview This development would require main steps , please follow the each step in details. 1.1 Install Prerequisites…
At this point I have already explained some of the related artifacts in “Persisting Custom Implementations on WSO2 Products in Kubernetes Deployments”
Here I have described what are the config maps and volume mounts in order to persist data in Kubernetes. So I highly recommend to read these 2 articles that I have mentioned above before go through this article.
Here I am going to focus on the important configurations that we do in wso2apim-deployment.yaml which reside inside the my-kubernetes-apim/kubernetes-apim/apim directory. This is the main configuration related to the APIM server pod. So it is important to identify the key configurations that we may have to change in order to achieve specific requirements when creating deployments.
This is where we define the version of the Kubernetes API that we are using to create the object. There are some different API versions that we can use. There are some slight differences of configurations depending on the API version that we use.
Since this is not an critical factor for the WSO2 deployments lets move on to the next one.
This is where we define what kind og objact that we want to create. There are several kinds of objects in Kubernetes for different purposes. In WSO2 artifacts, we mainly use Deployments and Statefulsets.
Deployments : A Deployment provides declarative updates for Pods and Replicas.
Statefulsets : StatefulSet is the workload API object used to manage stateful applications
When we are creating a distributed setup, there will be different profiles of APIM like Publisher, Devportal, Gateway, Key Manager and Traffic Manager. Out of these profiles there are some profiles which are acting like stateful applications and some as stateless applications. Depending on that we can use the kind that we need for the profile. For an example for Publisher and Devportal profiles, statefulset kind will be used and for Gateway profile Deployments will be used.
We can find the name in the metadata section in the yaml file. This is the unique name given for the object. This unique name will be used when mapping the this object with the Kubernetes services.
Name itself gives you an idea right? Yes this is where we define number of replicas of this object. For an example if we want to increase the number of gateway nodes, We can increase the number of replicas. Same way we can reduce the gateway nodes as well.
This is where we define the WSO2 docker image. Here there are 2 parts. All docker images will be kept in a docker reprository. In WSO2 it is docker.wso2.com. When defining the image, We need to include the repository which this docker image is located. Below example shows how define the wso2am:3.1.0 docker image which is reside in the wso2 provate repository.
Many applications running for long periods of time eventually transition to broken states, and cannot recover except by being restarted. Kubernetes provides liveness probes to detect and remedy such situations
- nc -z localhost 9443
Sometimes, applications are temporarily unable to serve traffic. For example, WSO2 APIM will take considerable amount of time for the server startup and the server will not be able to serve traffic during this server startup period. In such cases, you don’t want to kill the application, but you don’t want to send it requests either. Kubernetes provides readiness probes to detect and mitigate these situations. A pod with containers reporting that they are not ready does not receive traffic through Kubernetes Services
- nc -z localhost 9443
Here both liveness and readiness will be checked using a simple netcat command to check the server availability.
Lets say WSO2 APIM server is taking a lot of time to start due to an dependency. At that point if the server startup is higher than to the readeness probe, This pos will be killed and recreated. So in these cases we need to increase the readiness and liveness probes than the server startup time period. We can increase this by increasing the “initialDelaySeconds” value in seconds.
This is where we define the the resources required for this pod. Memory and the CPU required for this pod is defined here. There are 2 parts of the resources. In the requests part, We define the resource limits which will be allocated at the pod initialization. In limits part, We define the maximum limits that these pods can acquire. If these limits exceeds, pods will be restarted as liveness probe fails.
A container is just a virtual machine. Hence we need to define the ports that we hope to expose. Here we can expose all the ports required for APIM.
This is where we mount the created volumes to the relevant location inside the continer. Lets say we have created a config map using the deploymet.toml of the APIM server. We need to mount it the <APIM_HOME>/repository/conf directory to make the necessary config changes. So we can mount this as below.
volumeMounts:- name: apim-conf mountPath: /home/wso2carbon/wso2am-3.1.0/repository/conf/deployment.toml subPath: deployment.toml
A volume is a storage defined using either from a configmap or persistent volume claim inside the pod. We have discussed these volumes in detail in previous articles.
volumes:- name: apim-conf configMap:
So these are the key configurations that we have to get familiarized IMO.
Hope this may help you at any point of your career.
See you around…..!!! 😉
“The Deeper You Dig, The Deeper You get”.“The Tired You Feel, The Success You Achieve”- Shiran