Continuous Integration /Continuous Delivery in K8s

CICD provides a convenient and fast method to build,test and deliver the software projects.  K8s has become the foundational platform to make the apps containerized and manage these containers in the context of enterprise which usually runs hundreds or thoughts of them.

In this article, I will focus on the two major parts of the coutinuous process,  namely  CI and CD. the first one includes building the app in the docker around a docekerfile and testing it by running the test cases immediately after the build. The second part starts up after successfully passing through the building and testing processes. It mainly aims to deploy the apps to various infrastructural environment and deliver the app functionalities to the users.

Dockerfile still holds the position of most  common tool regarding to the containerization. it starts with a base image which provides all the basic underlying infrastructure which the app requires, such as linux server, language compiler and runtime. For example the base image of golang:1.19-alpine3.16 is the foundation which I run the go cod. It shows the go runtime version as 1.19 and linux server as alphine3.16. Usually these base images are provided by the container vendors like docker.io or redhat.io, which guarantes the reliability and stability on the base foundations. After starting with the base images, the dockerfile continues to setup workdir and  environmental variables , copy the source code , expose the service internal port and run the starting command. With a correct and complete dockerfile, the docker can build a image of the app code and generate containers by running the app image. It can be run locally but most time It runs in a remote server, in which case the built image need be pushed to a image repository ownered by the company. 

Integration comes at the same time when we build the app desribed above. It need pass a group of selected test cases in order to successfully integrate the changed code to exiting ones. if the test cases run failed, then integration would fall out and build result would also be marked as failed, which stop the CD process and certainly block the image from being pushed to the company's remote image repository for continuous delivery.

Continuous Delivery deploys the app code into the decided environment so the user have access to the new functionality. it can be done by company's own servers located on site or through the cloud vendors like Aws, Azure or Aliyun. I would take the example of k8s in Aliyun Cloud. First of all it generate some base components by reading yaml file, such as  service, deployment and virtualService. the service is the network channel between the internet and app service, which exposes and maps the app port so the internet users can access the service by specific port through the service. Deployment springs up the containers by pulling the image from the remote image repository described before, define the containers with various pre-designed specification and wrap them in a component called pod.  VirtualService has been promoted to replace the ingress as the host to access the app running in the pod and it comes up with the newly advanced design of istio under the concept of service mersh, In my opinion it shows the advantage by removing the step of setting up host and reducing the cost thereby. All the k8s components must be classified in a fixed namespace and they can have label attached for other component to select and interact. 

once the base components have been layouted , the specific deployment environment could be setup on these base layouts. in my example, it has two environments for the app to run, which are dev and release. a yaml patch file can be added in each deploy environment in order to extend the component setup in the base. Finally the skaffold can be used as a entry point for the k8s delivery process. It looks for a yaml file called kustomization whch list all the resources that are going to run and deploy them into the specified environment by the profiles set up in the skaffold yaml file.