Shulou(Shulou.com)06/03 Report--

What is the automatic expansion and reduction of HPA capacity of Kubernetes? I believe that many novice rookies' understanding of HPA is ignorant. Through the summary of this article, I hope you can get something. The following information is about HPA.

HPA introduction

Kubernetes HPA (horizontal Pod automatic scaling) Pod is automatically scaled horizontally. With simple configuration, you can automatically expand or reduce the number of Pod in the service using monitoring metrics (cpu utilization, disk, memory, etc.). When the business demand increases, the system will automatically increase the appropriate amount of containers for you to improve system stability. Here we will explain in detail the core design principles of HPA and how to use Hepaster.

prerequisite

The system should be able to get access to the current Pod resource usage (meaning you can execute kubectl top pod commands and get feedback).

To achieve automatic capacity expansion, you also need to deploy heapster services to collect and count the utilization of resources, support kubectl top commands, and heapster services are integrated into prometheus (Prometheus) MertricServer services. So, for convenience, I deploy HPA (dynamic scaling) services based on prometheus services here.

Experimental environment host IP address service master192.168.1.21k8snode01192.168.1.22k8snode02192.168.1.23k8s

The experiment based on [https://blog.51cto.com/14320361/2473879]()] continues

Heapster: this component was previously integrated in the K8s cluster, but was removed after version 1.12. If you still want to use this feature, you should deploy metricServer, the aggregator for K8s cluster resource usage. Cousom: it is also in the beta stage (autoscaling/v2beta1), but when it comes to the development of custom REST API, it will be more complex, and when you need to obtain data from custom monitoring, you can only set the absolute value, not the usage. Automatic extension is mainly divided into two types: horizontal extension (scale out), which is aimed at increasing or decreasing the number of instances. Vertical scaling (scal up) is the increase or decrease of resources that can be used by a single instance, such as increasing cpu and increasing memory.

HPA belongs to the former. It can automatically expand the number of Pod based on CPU usage or apply custom metrics (supports replication controller, deployment, and replica set). The workflow creates HPA resources, sets the target CPU usage limit, and the maximum / minimum number of instances. Be sure to set the resource limit parameter of Pod: request, otherwise HPA will not work. The control manager queries the resource usage of metrics every 30s (which can be modified through-- horizontal-pod-autoscaler-sync-period in kube-controller-manager.service). Then it is compared with the values and indicators set at the time of creation (the sum of averages / limits), and the number of instances adjusted by the target is calculated. The number of instances adjusted by the target cannot exceed the maximum / minimum number of instances set in the first article. If it is not exceeded, the capacity is expanded; if so, the capacity is expanded to the maximum number of instances. Repeat steps 2-4.

Here, we use a test image based on the docker image created by php-apache and contains some code that can run cpu intensive computing tasks.

1. Create a deployment controller [root@master ~] # docker pull mirrorgooglecontainers/hpa-example:latest// download hpa-example image [root@master ~] # kubectl run php-apache-- image=mirrorgooglecontainers/hpa-example-- requests=cpu=200m-- expose-- port=80// is based on hpa-example image, run a deployment controller, request a CPU resource of 200m, expose an 80-port view [root@master ~] # kubectl get deployments.

2. Create HPA controller [root@master ~] # kubectl autoscale deployment php-apache-- cpu-percent=50-- min=1-- max=10//. When the CPU utilization of deployment resource object reaches 50%, you can expand the capacity. You can expand the capacity to a maximum of 10 to check [root@master ~] # kubectl get hpa.

3. Test (master opens three ports)

Multiple terminals are opened to request the pod of php-apache in an endless loop to pod.

Port 1 (1) creates an application that constantly accesses the svc resources of the php-apache we just created. [root@master] # kubectl run-I-- tty load-generator-- image=busybox / bin/sh (2) enter into Pod and execute the following command. Used to simulate access to svc resources for php-apache. [root@master ~] # while true; do wget-Q-O-http://php-apache.default.svc.cluster.local; done// keeps sending ok port two [root@master ~] # kubectl get hpa-w to php-apache 's svc resources / check the cpu status of pod in real time

You can see that the cpu usage of php-apache has exceeded 50%.

Port 3 [root@master images] # kubectl get pod-w kubectl get pod / view the status of the pod in real time

You can see that when the cpu usage of php-apache exceeds 50%, new php-apache will continue to be generated for load balancing (10 when the current setting is online). Of course, if the cpu usage drops to 50%, php-apache will be deleted one after another, which can reduce unnecessary resource waste and uneven resource distribution.

After reading the above, do you have a general understanding of Kubernetes's automatic HPA capacity expansion and reduction? If you want to know more about the content of the article, welcome to follow the industry information channel, thank you for reading!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.