Cloud native applications are the future of software development. Container-packaged, dynamically managed, and microservice-oriented, cloud native systems enable faster development velocity while maintaining operational stability.

Kubernetes is an open source container orchestration platform. It is designed to automate your management of application containers, from deploying and scaling to operating. Kubernetes orchestration allows you to partition as you go scaling up and down as necessary. You can respond quickly and efficiently to customer demand while limiting hardware usage and minimizing disruption to feature rollouts.

GitLab CI (Continuous Integration) service is a part of GitLab that build and test the software whenever developer pushes code to application. GitLab CI/CD lets you easily manage deployments to multiple environments. Run automated tests in parallel with auto-scaling GitLab Runners.

Deployment through GitLab

Configuring environment variables

The following environment variables need to be configured in gitlab:

KUBE_URL ->The kubernetes cluster URL

->The kubernetes cluster URL KUBE_TOKEN ->The Kubernetes token of the environment service account.

->The Kubernetes token of the environment service account. KUBE_CA_PEM ->Raw PEM data. Only if a custom CA bundle was specified.

From the gitlab UI, navigate to your project’s Settings > CI/CD and expand Variables. Create a new variable by choosing its type, naming it in the field Input variable key, and defining its value in the Input variable value field:

The KUBE_TOKEN value can be retrieved from kubernetes by running this command and copying the token value:

kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | grep eks-admin | awk '{print $1}')

Configuring Gitlab CI/CD

Once you have a running Kubernetes cluster, you can deploy your containerized applications on top of it. To do so, you create a Kubernetes Deployment configuration: E.g. deployment.yaml

The Deployment instructs Kubernetes how to create and update instances of your application. Once you’ve created a Deployment, the Kubernetes master schedules mentioned application instances onto individual Nodes in the cluster.

The .gitlab-ci.yml file is where you configure what CI does with your project. It lives in the root of your repository.

In this file you will add the stage responsible of Kubernetes deployment (E.g. deploy) and add the following configuration:

... deploy:

image: centos

stage: deploy

before_script:

— curl -LO https://storage.googleapis.com/kubernetes-release/release/`curl -s https://storage.googleapis.com/kubernetes-release/release/stable.txt`/bin/linux/amd64/kubectl

— chmod +x ./kubectl

— mv ./kubectl /usr/bin/kubectl

— kubectl config set-cluster clusterName --server=”$KUBE_URL” --certificate-authority=”$KUBE_CA_PEM”

— kubectl config set-credentials admin --token=”$KUBE_TOKEN”

— kubectl config set-context default —-cluster=clusterName --user=admin

— kubectl config use-context default

script:

— kubectl apply -f deployment.yaml ...

In this example we use the centos image but you can use any supporting curl command.

The before_script section is responsible of downloading and installing the kubectl binary and setting up the connection to the kubernetes cluster.

The script section contains the command that creates and updates resources in the cluster.

If you don’t want to use the KUBE_CA_PEM, instead of option certificate-authority=”$KUBE_CA_PEM” you can use insecure-skip-tls-verify=true.

Conclusion

With this configuration you will be able to automatically connect to kubernetes and use the kubectl command from Gitlab CI/CD.

Combining this stage with the ones that build, test and dockerize your application will create a complete CI workflow.