Shulou(Shulou.com)05/31 Report--

This article mainly introduces "what is Kubernetes automatic scaling". In daily operation, I believe many people have doubts about what Kubernetes automatic scaling is. Xiaobian consulted all kinds of data and sorted out simple and easy-to-use methods of operation. I hope it will be helpful for you to answer the doubts of "what is Kubernetes automatic scaling?" Next, please follow the editor to study!

Editor's note

Many Kubernetes users, especially those at the enterprise level, quickly encounter the need for automatic scaling of the environment. Fortunately, Kubernetes Horizontal Pod Autoscaler (HPA) allows you to configure your deployment to scale horizontally in a variety of ways. One of the biggest advantages of using Kubernetes Autoscaling is that your cluster can track the load capacity of existing Pod and calculate whether more Pod is needed.

Kubernetes Autoscaling

By coordinating the built-in two layers of extensibility, you can take full advantage of efficient Kubernetes Autoscaling:

Automatic scaling at the Pod level: includes Horizontal Pod Autoscaler (HPA) and Vertical Pod Autoscaler (VPA); both can extend the resources available to the container.

Automatic scaling at the cluster level: the Cluster Auto regulator (CA) manages this scalability plane by expanding the number of nodes in the cluster up or down as necessary.

Kubernetes Autoscaling details Horizontal Pod Autoscaler (HPA)

HPA scales the number of Pod replicas in the cluster. This operation is triggered by CPU or memory to scale up or down as needed. However, HPA can also be configured to extend Pod based on various external and custom metrics (metrics.k8s.io,external.metrics.k8s.io and custom.metrics.k8s.io).

Vertical Pod Autoscaler (VPA)

VPA is mainly used for stateful services, which can add CPU or memory to Pod as needed-- it is also suitable for stateless Pod. To apply these changes, VPA restarts Pod to update new CPU and memory resources, which can be configured to start in response to OOM (out of memory) events. When you restart Pod, VPA always ensures that the minimum quantity is determined based on the Pod allocation budget (PDB), and you can set the maximum and minimum rates for that resource allocation.

Cluster Autoscaler (CA)

The automatic scaling of the second layer involves CA, which automatically resizes the cluster in the following cases:

Due to insufficient capacity in the cluster, no Pod/s can run and go into a suspended state (in which case the CA will scale up).

The nodes in the cluster are underutilized for a period of time, and it is possible to migrate the Pod on the node (in which case the CA will shrink).

CA performs a routine check to determine if any pod is pending due to waiting for additional resources, or whether the cluster node is underutilized. If more resources are needed, the number of Cluster nodes will be adjusted accordingly. CA interacts with the cloud provider to request other nodes or shut down idle nodes and ensures that the scaled-up cluster remains within the limits set by the user. It works with AWS,Azure and GCP.

5 steps to using HPA and CA with Amazon EKS

This article provides step-by-step instructions for installation and automatic extension through HPA and CA through the Amazon Elastic container service for Kubernetes (Amazon EKS) clusters. The following guidelines are examples of two test cases:

Cluster requirements

Amazon VPC and a security group that meet the requirements of the EKS cluster.

Alternatively, CloudFormation templates that create VPC and EKS are provided to avoid manual creation of VPC,AWS

CloudFormation YAML file

EKS roles applied to the cluster

1. Create an AWS EKS cluster (control panel and work node) according to the official guide. Once you have started the worker nodes in the form of auto scaling group, they will automatically register with the EKS cluster, and you can start deploying K8s applications.

two。 Deploy a metrics server so that HPA can automatically scale the number of POD replicas based on the CPU/ memory data provided by API. Metrics.k8s.io api is usually provided by metrics-server, which is responsible for collecting cpu and memory metrics from summary api.

3. Apply the following strategy to the Role of the worker node created by EKS

{"Version": "2012-10-17", "Statement": [{"Effect": "Allow", "Action": ["autoscaling:DescribeAutoScalingGroups", "autoscaling:DescribeAutoScalingInstances", "autoscaling:DescribeLaunchConfigurations", "autoscaling:DescribeTags", "autoscaling:SetDesiredCapacity", "autoscaling:TerminateInstanceInAutoScalingGroup"] "Resource": "*"]}

4. Deploy k8s CA feature

Depending on the linux distribution you use, you may need to update the deployment file and certificate path. For example, if you use AMI Linux, you need to replace / etc/ssl/certs/ca-certificates.crt with / etc/ssl/certs/ca-bundle.crt

5. Update CA's deployment YAML file to find the specified AWS AG (k8s.io/cluster-autoscaler/ should contain the real cluster name) tag. Also update the AWS_REGION environment variable.

Add the following tag to AWS AG so that the cluster autoscaler of k8s automatically recognizes AWS AG:

K8s.io/cluster-autoscaler/enabled k8s.io/cluster-autoscaler/

Kubernetes Autoscaling Test case # 1

Test k8s hpa feature and k8s ca feature to use at the same time

Request:

A running eks cluster

Install metric server

The k8s cluster autoscaler feature is installed

1. Deploy a test app to create HPA resources for app deployment.

two。 Initiate requests from different geographic locations to increase the load.

3. HPA should start scaling the number of pod as the load increases. It will scale as specified by the hpa resource. At some point, the new POD will be waiting while waiting for other resources.

$kubectl get nodes-wNAME STATUS ROLES AGE VERSIONip-192-168189-29.ec2.internal Ready 1h v1.10.3ip-192-168200-20.ec2.internal Ready 1h v1.10.3$ kubectl get Pods-o wide-wNAME READY STATUS RESTARTS AGE IP NODEip-192-168200-20.ec2.internalphp-apache-8699449574-4mg7w 0 Pending 0 17mphp ip-192 Running 01h 192.168.210.90 ip-192-168200-20php Muhammad apachem 8699449574-8nqwk 0 Pending 0 17mphp-apache-8699449574-cl8lj 1 Running 0 27m 192.168.172.71 ip-192-168189-29php-apache-8699449574-cpzdn 1 Running 0 17m 192.168.219.71 ip-192-168200-20php-apache-8699449574-dn9tb 0 Pending 0 17m

4. CA detects the pods that has entered the waiting state due to insufficient capacity, and adjusts the size of the AWS auto-scaling group. A new node has joined:

$kubectl get nodes-wNAME STATUS ROLES AGE VERSIONip-192-168189-29.ec2.internal Ready 2h v1.10.3ip-192-168200-20.ec2.internal Ready 2h v1.10.3ip-192-16892-187.ec2.internal Ready 34s v1.10.3

5. HPA can schedule the waiting POD to the new node. The average cpu usage is lower than the specified target, so there is no need to schedule new pod.

$kubectl get hpaNAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGEphp-apache Deployment/php-apache 40% kubectl get Pods 50 2 25 20 1h $kubectl get Pods-o wide-w $kubectl get Pods-o wide-wNAME READY STATUS RESTARTS AGE IP NODEphp-apache-8699449574-4mg7w 1 Running 0 25m 192.168.74.4 ip-192-16892-187php -apache-8699449574- 64zkm 1 Running 0 1h 192.168.210.90 ip-192-168200-20php-apache-8699449574-8nqwk 1 Running 0 25m 192.168.127.85 ip-192-92-187php-apache-8699449574-cl8lj 1 187php-apache-8699449574-cl8lj 1 Running 035m 192.168.172.71 ip-192-188189-29.

6. Turn off a few terminal, stop some load

7. The average CPU utilization decreased, so HPA began to change the number of pod replicas in the deployment and kill some pods

$kubectl get hpaNAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGEphp-apache Deployment/php-apache 47% ip-192 50 0 20 7 1h $kubectl get Pods-o wide-wNAME READY STATUS RESTARTS AGE IP NODE...php-apache-8699449574-v5kwf 1 Running 0 36m 192.168.250.0 ip-192-168200-20php- Apache-8699449574-vl4zj 1 Running 0 36m 192.168.242.153 ip-192-168200-20php-apache-8699449574-8nqwk 1 Terminating 0 26m 192.168.127.85 ip-192-92-187php-apache-8699449574-dn9tb 1 187php-apache-8699449574-dn9tb 1 Terminating 0 26m 192.168.124.108 ip-192-92-187php-apache-8699449574-k5ngv 1 Terminating 026m 192.168.108.58 ip-192-92-187.

8. CA has detected that one node is underutilized and the running pod can be scheduled to other nodes.

$kubectl get nodesNAME STATUS ROLES AGE VERSIONip-192-188189-29.ec2.internal Ready 2h v1.10.3ip-192-168200-20.ec2.internal Ready 2h v1.10.3ip-192-16892-187.ec2.internal NotReady 23m v1.10.3$ kubectl get nodesNAME STATUS ROLES AGE VERSIONip-192-168189-29.ec2.internal Ready 2h v1.10.3ip-192-168200-20.ec2.internal Ready 2h v1.10.3

9. When zooming down, there should be no obvious timeout in terminal

Kubernetes Autoscaling Test case # 2

Test whether CA can automatically resize the cluster if there is not enough CPU capacity to schedule pod

Request:

A running aws eks cluster

The Kubernetes ca feature is installed

1. Create 2 deployment with requests less than 1vcpu

$kubectl run nginx-image=nginx:latest-requests=cpu=200m$ kubectl run nginx2-image=nginx:latest-requests=cpu=200m

two。 Create a new deployment and request more resources than the remaining cpu

$kubectl run nginx3-image=nginx:latest-requests=cpu=1

3. The new POD will be waiting because there are no resources available:

$kubectl get Pods-wNAME READY STATUS RESTARTS AGEnginx-5fcb54784c-lcfht 1 66667bf959 1 Running 0 13mnginx2-66667bf959-2fmlr 1 Running 0 3mnginx3-564b575974-xcm5t 0 Pending 0 41s

When describing pod, you may see events that do not have enough cpu

$kubectl describe Pod nginx3-564b575974-xcm5t... ... .. Events:Type Reason Age From Message---- Warning FailedScheduling 32s (x7 over 1m) default-scheduler 0bat 1 nodes are available: 1 Insufficient cpu

4. CA automatically adjusts the size of the cluster and adds a new node

$kubectl get nodesNAME STATUS ROLES AGE VERSIONip-192-168142-179.ec2.internal Ready 1mv1.10.3

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.