Imagine that your application can automatically add another container to serve more request and delete unused container when requests are declining, with this approach, you can preserve the resources for another application and also decrease the bill for cloud resource usage.
With kubernetes, you can achieve this using HPA (Horizontal pod autoscaler) or using vertical autoscaler. But in this tutorial, we will only show how to use HPA. The case for this tutorial is to autoscale DNS to serve approximately thousand users. We need external Load Balancer to forward requests to kubernetes.
Below is the network diagram for this tutorial.
The DNS will be deployed in all node and number of pod will be expanded or reduced until the max and min value that is configured in HPA setting. We need to define the resource that will be used by each pod so that kubernetes know when to expand and reduce the pod.
Preparation
We need to create these following files:
- app-hpa.yaml
- app-service.yaml
- app-deployment.yaml
- db.xzone
- named.conf
- supervisord.conf
- Dockerfile
- .gitlab-ci.yml
I am using gitlab CI/CD to automate the deployment. The structure in the project will be like this:
The main recipe of the automation is in file .gitlab-ci.yml, it contains the way how you deploy the container in k8s. You need to put your k8s authentication file in rke2.yaml, this is not recommended if your project is not private. In this example, the image creation is using kaniko, because my environment is using containerd, so you need to adjust the .gitlab-ci.yml accordingly.
The dns configurations are located in folder server_config. Named.conf and db.xzone are used for bind configuration and supervisord.conf is used to load bind at the initial boot. The db.xzone is used to define your own domain or blocking restricted domain.
The server_deployment folder contain all files that are needed to create image and deploy it to k8s cluster. I use proxy configuration in the deployment yaml and gitlab-ci file, if you are not behind proxy, you must delete it. You also need to define secret in your k8s cluster to authenticate into your gitlab private registry with name new-registry. All configuration can be accessed in my
github. Once you commit any changes, your dns cache will be deployed in to k8s cluster and can be accessed by k8s worker ip with port 30053.
The initial pod for the dns is 2, the pod will expand until maximum 10 when the pod usage about 80% cpu limit.
References
Comments