Discovering the Kubernetes Artifacts of the WSO2 API Manager deployment.
Tags: Deployment, Configuration, Wso2, Kubernetes, Wso2 Api Manager

Hi Mates,

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.

https://github.com/shiransilva/my-kubernetes-apim

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.

Let’s Go….!

apiVersion

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.

apiVersion: extensions/v1beta1

Since this is not an critical factor for the WSO2 deployments lets move on to the next one.

2. kind

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

kind: Deployment

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.

3. name

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.

metadata:

name: wso2apim

4. replicas

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.

spec:

replicas: 1

5. image

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.

image: docker.wso2.com/wso2am:3.1.0

6. livenessProbe

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

livenessProbe:

exec:

command:

- /bin/bash

- -c

- nc -z localhost 9443

initialDelaySeconds: 100

periodSeconds: 10

7. readinessProbe

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

readinessProbe:

exec:

command:

- /bin/bash

- -c

- nc -z localhost 9443

initialDelaySeconds: 100

periodSeconds: 10

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.

8. resources

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.

resources:

requests:

memory: "2Gi"

cpu: "2000m"

limits:

memory: "3Gi"

cpu: "3000m"

9. ports

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.

ports:

-

containerPort: 8280

protocol: "TCP"

-

containerPort: 8243

protocol: "TCP"

10. volumeMounts

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

11. volumes

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:

name: apim-conf

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