Kubernetes aims to achieve both resilience and scalability by deploying multiple pods with varying resource allocations, ensuring redundancy for your applications. While you have the option to manually adjust your deployments according to your requirements, Kubernetes offers excellent support for on-demand scaling through its Horizontal Pod Autoscaling feature. This closed loop system automatically adjusts the allocation of resources, i.e., application Pods, based on your current needs. Simply create a HorizontalPodAutoscaler (HPA) resource for each application deployment requiring autoscaling, and it will handle the process seamlessly for you.<\/p>\n
HPA functions in the following manner at a broad perspective:<\/p>\n
A HorizontalPodAutoscaler operates by using a dedicated controller within the Control Plane of your cluster, functioning as a CRD (Custom Resource Definition). To apply the HPA resource in your cluster, you need to generate a HorizontalPodAutoscaler YAML manifest that specifically targets your application Deployment and execute it using kubectl.<\/p>\n
To function properly, HPA requires a metrics server within your cluster to gather essential metrics like CPU and memory usage. A convenient choice for this is the Kubernetes Metrics Server. This server collects resource metrics from Kubelets and makes them accessible to the Horizontal Pod Autoscaler through the Kubernetes API Server. In case necessary, the Metrics API can also be accessed using kubectl top.<\/p>\n
In this tutorial, you will learn:<\/p>\n
If you are searching for a hosted Kubernetes service, take a look at our straightforward, managed Kubernetes solution designed to facilitate scalability.<\/p>\n
To follow this guide, you will require:<\/p>\n
To begin, include the metrics-server repository in your helm package listings. You may utilize helm repo add for this purpose.<\/p>\n
<\/code><\/pre>\n\n- helm repo add<\/span> metrics-server https:\/\/kubernetes-sigs.github.io\/metrics-server<\/li>\n<\/ol>\n
<\/code><\/pre>\n <\/p>\n
<\/code><\/pre>\nAfterwards, employ the command helm repo update to renew the list of accessible packages.<\/p>\n
<\/code><\/pre>\n\n- helm repo update metrics-server<\/li>\n<\/ol>\n
<\/code><\/pre>\n <\/p>\n
<\/code><\/pre>\n<\/code><\/pre>\nOutput<\/div>\n<\/code><\/pre>\nHang tight while we grab the latest from your chart repositories… …Successfully got an update from the “metrics-server” chart repository Update Complete. \u2388Happy Helming!\u2388<\/p>\n
<\/code><\/pre>\nAfter integrating the repository with helm, you will have the capability to include metrics-server in your Kubernetes deployments. While you have the option to create your own deployment configuration, this tutorial will use Silicon Cloud\u2019s Kubernetes Starter Kit, which already includes a configuration for metrics-server.<\/p>\n
To accomplish that, duplicate the Kubernetes Starter Kit Git repository.<\/p>\n
<\/code><\/pre>\n\n- git<\/span> clone https:\/\/github.com\/digitalocean\/Kubernetes-Starter-Kit-Developers.git<\/li>\n<\/ol>\n
<\/code><\/pre>\n <\/p>\n
<\/code><\/pre>\nYou can find the configuration for metrics-server at Kubernetes-Starter-Kit-Developers\/09-scaling-application-workloads\/assets\/manifests\/metrics-server-values-v3.8.2.yaml. To view or edit it, you can utilize nano or any text editor of your choice.<\/p>\n
<\/code><\/pre>\n\n- nano<\/span> Kubernetes-Starter-Kit-Developers\/09-scaling-application-workloads\/assets\/manifests\/metrics-server-values-v3.8.2.yaml<\/li>\n<\/ol>\n
<\/code><\/pre>\n <\/p>\n
<\/code><\/pre>\nThe set of parameters is limited, with the replicas always being fixed at a value of 2.<\/p>\n
yaml file with version 3.8.2 of metrics server values.<\/div>\n## Starter Kit metrics-server configuration\r\n## Ref: https:\/\/github.com\/kubernetes-sigs\/metrics-server\/blob\/metrics-server-helm-chart-3.8.2\/charts\/metrics-server\r\n##\r\n\r\n# Number of metrics-server replicas to run\r\nreplicas: 2<\/mark>\r\n\r\napiService:\r\n # Specifies if the v1beta1.metrics.k8s.io API service should be created.\r\n #\r\n # You typically want this enabled! If you disable API service creation you have to\r\n # manage it outside of this chart for e.g horizontal pod autoscaling to\r\n # work with this release.\r\n create: true\r\n\r\nhostNetwork:\r\n # Specifies if metrics-server should be started in hostNetwork mode.\r\n #\r\n # You would require this enabled if you use alternate overlay networking for pods and\r\n # API server unable to communicate with metrics-server. As an example, this is required\r\n # if you use Weave network on EKS\r\n enabled: false\r\n<\/code><\/pre>\nFor information on the available metrics-server parameters, please refer to the Metrics Server chart page.<\/p>\n
\nNote<\/p>\n
Be cautious when aligning Kubernetes deployments with the appropriate version of Kubernetes, as the helm charts are also versioned to ensure compatibility. The metrics-server helm chart available now is 3.8.2 and it deploys version 0.6.1 of metrics-server. Referring to the Metrics Server Compatibility Matrix, it is evident that version 0.6.x is compatible with Kubernetes 1.19 or later versions.<\/div>\n<\/div>\nOnce you have examined the file and made necessary modifications, you can move forward with deploying metrics-server by including this file in the helm install command.<\/p>\n
<\/code><\/pre>\n\n- HELM_CHART_VERSION<\/span>=<\/span>“3.8.2”<\/span><\/li>\n
- <\/li>\n
- helm install<\/span> metrics-server metrics-server\/metrics-server –version<\/span> “$HELM_CHART_VERSION<\/span>“<\/span> \\<\/span><\/li>\n
- –namespace<\/span> metrics-server \\<\/span><\/li>\n
- –create-namespace \\<\/span><\/li>\n
- -f<\/span> “Kubernetes-Starter-Kit-Developers\/09-scaling-application-workloads\/assets\/manifests\/metrics-server-values-v${HELM_CHART_VERSION}<\/span>.yaml”<\/span><\/li>\n<\/ol>\n
<\/code><\/pre>\n <\/p>\n
<\/code><\/pre>\nYour configured Kubernetes cluster will have metrics-server deployed.<\/p>\n
<\/code><\/pre>\nOutput<\/div>\n<\/code><\/pre>\nNAME: metrics-server LAST DEPLOYED: Wed May 25 11:54:43 2022 NAMESPACE: metrics-server STATUS: deployed REVISION: 1 TEST SUITE: None NOTES: *********************************************************************** * Metrics Server * *********************************************************************** Chart version: 3.8.2 App version: 0.6.1 Image tag: k8s.gcr.io\/metrics-server\/metrics-server:v0.6.1 ***********************************************************************<\/p>\n
<\/code><\/pre>\nOnce you have deployed, you can utilize the helm ls command to confirm the addition of metrics-server to your deployment.<\/p>\n
<\/code><\/pre>\n\n- helm ls<\/span> -n<\/span> metrics-server<\/li>\n<\/ol>\n
<\/code><\/pre>\n <\/p>\n
<\/code><\/pre>\n<\/code><\/pre>\nOutput<\/div>\n<\/code><\/pre>\nNAME NAMESPACE REVISION UPDATED STATUS CHART APP VERSION metrics-server metrics-server 1 2022-02-24 14:58:23.785875 +0200 EET deployed metrics-server-3.8.2 0.6.1<\/p>\n
<\/code><\/pre>\nAfterward, you have the option to verify the condition of all Kubernetes resources that have been deployed to the metrics-server namespace.<\/p>\n
<\/code><\/pre>\n\n- kubectl get all -n<\/span> metrics-server<\/li>\n<\/ol>\n
<\/code><\/pre>\n <\/p>\n
<\/code><\/pre>\nAccording to the configuration you used for deployment, you should have a total of two available instances for both deployment.apps and replicaset.apps.<\/p>\n
<\/code><\/pre>\nOutput<\/div>\n<\/code><\/pre>\nNAME READY STATUS RESTARTS AGE pod\/metrics-server-694d47d564-9sp5h 1\/1 Running 0 8m54s pod\/metrics-server-694d47d564-cc4m2 1\/1 Running 0 8m54s NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE service\/metrics-server ClusterIP 10.245.92.63 <none> 443\/TCP 8m54s NAME READY UP-TO-DATE AVAILABLE AGE deployment.apps\/metrics-server 2\/2 2 2 8m55s NAME DESIRED CURRENT READY AGE replicaset.apps\/metrics-server-694d47d564 2 2 2 8m55s<\/p>\n
<\/code><\/pre>\nYou have successfully installed metrics-server in your Kubernetes cluster. Next, you will examine a few parameters of a HorizontalPodAutoscaler Custom Resource Definition.<\/p>\n
Step 2 – Familiarizing oneself with HPAs<\/h2>\n
Until now, your setup has been using a constant value to deploy the ReplicaSet instances. In this next phase, you will discover how to define a HorizontalPodAutoscaler CRD, which will enable the value to expand or contract dynamically.<\/p>\n
The structure of a regular HorizontalPodAutoscaler CRD appears as follows:<\/p>\n
\nPlease provide an alternative for “crd.yaml” in a more native way:<\/p>\n
file.crd<\/p>\n<\/div>\n
apiVersion: autoscaling\/v2beta2\r\nkind: HorizontalPodAutoscaler\r\nmetadata:\r\n name: my-app-hpa\r\nspec:\r\n scaleTargetRef:\r\n apiVersion: apps\/v1\r\n kind: Deployment\r\n name: my-app-deployment\r\n minReplicas: 1\r\n maxReplicas: 3\r\n metrics:\r\n - type: Resource\r\n resource:\r\n name: cpu\r\n target:\r\n type: Utilization\r\n averageUtilization: 50\r\n<\/code><\/pre>\nThe parameters utilized in this setup are listed below:<\/p>\n
\n- spec.scaleTargetRef: A named reference to the resource being scaled.<\/li>\n
- spec.minReplicas: The lower limit for the number of replicas to which the autoscaler can scale down.<\/li>\n
- spec.maxReplicas: The upper limit.<\/li>\n
- spec.metrics.type: The metric to use to calculate the desired replica count. This example is using the Resource type, which tells the HPA to scale the deployment based on average CPU (or memory) utilization. averageUtilization is set to a threshold value of 50.<\/li>\n<\/ul>\n
You can choose between two options when creating an HPA for your application deployment.<\/p>\n
\n- \n
Just follow these steps:<\/ol>\n<\/li>\n<\/ol>\n <\/p>\n
\n- \n
1. Employ the kubectl autoscale command for a current deployment.<\/ol>\n<\/li>\n<\/ol>\n <\/p>\n
2. Generate a HPA YAML manifest and apply the alterations to your cluster using kubectl.<\/ol>\nYou will start with option #1, utilizing a different setup provided by Silicon Cloud Kubernetes Starter Kit. This setup includes a deployment named myapp-test.yaml, which will showcase the functionality of Horizontal Pod Autoscaling (HPA) by generating a random CPU workload.<\/p>\n
You are able to examine that document by utilizing either nano or your preferred text editor.<\/p>\n
<\/code><\/pre>\n\n- nano<\/span> Kubernetes-Starter-Kit-Developers\/09-scaling-application-workloads\/assets\/manifests\/hpa\/metrics-server\/myapp-test.yaml<\/li>\n<\/ol>\n
<\/code><\/pre>\n <\/p>\n
<\/code><\/pre>\nCould you provide more context or information about “myapp-test.yaml” to help me provide an appropriate paraphrase?<\/div>\napiVersion: apps\/v1\r\nkind: Deployment\r\nmetadata:\r\n name: myapp-test\r\nspec:\r\n selector:\r\n matchLabels:\r\n run: myapp-test\r\n replicas: 1\r\n template:\r\n metadata:\r\n labels:\r\n run: myapp-test\r\n spec:\r\n containers:\r\n - name: busybox\r\n image: busybox\r\n resources:\r\n limits:\r\n cpu: 50m\r\n requests:\r\n cpu: 20m\r\n command: [\"sh\", \"-c\"]\r\n args:\r\n - while [ 1 ]; do<\/mark>\r\n echo \"Test\";<\/mark>\r\n sleep 0.01;<\/mark>\r\n done<\/mark>\r\n<\/code><\/pre>\nTake note of the closing lines in this document. They incorporate shell syntax to continuously display the word “Test” one hundred times per second, imitating a load. Once you finish evaluating the document, you can utilize kubectl to deploy it into your cluster.<\/p>\n
<\/code><\/pre>\n\n- kubectl apply -f<\/span> Kubernetes-Starter-Kit-Developers\/09-scaling-application-workloads\/assets\/manifests\/hpa\/metrics-server\/myapp-test.yaml<\/li>\n<\/ol>\n
<\/code><\/pre>\n <\/p>\n
<\/code><\/pre>\nAfterwards, proceed to utilize kubectl autoscale for the myapp-test deployment, thus creating a HorizontalPodAutoscaler.<\/p>\n
<\/code><\/pre>\n\n- kubectl autoscale deployment myapp-test –cpu-percent=<\/span>50<\/span> –min<\/span>=<\/span>1<\/span> –max<\/span>=<\/span>3<\/span><\/li>\n<\/ol>\n
<\/code><\/pre>\n <\/p>\n
<\/code><\/pre>\nTake note of the parameters given to this command. It implies that your deployment will automatically adjust the number of replicas between 1 and 3 based on CPU utilization, triggered when it reaches 50 percent.<\/p>\n
To determine if the HPA resource has been created, execute the command “kubectl get hpa”.<\/p>\n
<\/code><\/pre>\n\n- kubectl get hpa<\/li>\n<\/ol>\n
<\/code><\/pre>\n <\/p>\n
<\/code><\/pre>\nThe TARGETS column in the output will eventually display the current usage percentage compared to the target usage percentage.<\/p>\n
<\/code><\/pre>\nOutput<\/div>\n<\/code><\/pre>\nNAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE myapp-test Deployment\/myapp-test 240%\/50% 1 3 3 52s<\/p>\n
<\/code><\/pre>\n\nNote<\/p>\n
Please be aware that for a brief period of about 15 seconds, the TARGETS column will show \/50%. This is a normal occurrence as HPA requires some time to gather average values and it will not have sufficient data before the initial 15-second interval. HPA follows a default setting of checking metrics every 15 seconds.<\/div>\n<\/div>\nTo view the logged events generated by a Horizontal Pod Autoscaler, you can utilize kubectl describe command.<\/p>\n
<\/code><\/pre>\n\n- kubectl describe hpa myapp-test<\/li>\n<\/ol>\n
<\/code><\/pre>\n <\/p>\n
<\/code><\/pre>\n<\/code><\/pre>\nOutput<\/div>\n<\/code><\/pre>\nName: myapp-test Namespace: default Labels: <none> Annotations: <none> CreationTimestamp: Mon, 28 May 2022 10:10:50 -0800 Reference: Deployment\/myapp-test Metrics: ( current \/ target ) resource cpu on pods (as a percentage of request): 240% (48m) \/ 50% Min replicas: 1 Max replicas: 3 Deployment pods: 3 current \/ 3 desired … Events: Type Reason Age From Message —- —— —- —- ——- Normal SuccessfulRescale 17s horizontal-pod-autoscaler New size: 2; reason: cpu resource utilization (percentage of request) above target Normal SuccessfulRescale 37s horizontal-pod-autoscaler New size: 3; reason: cpu resource utilization (percentage of request) above target<\/p>\n
<\/code><\/pre>\nThe recommended approach for creating Horizontal Pod Autoscalers (HPA) in a production environment is to utilize a dedicated YAML manifest instead of the kubectl autoscale method. By maintaining the manifest in a Git repository, you can easily monitor changes and make necessary modifications.<\/p>\n
In the final step of this tutorial, you will go through an example of this. However, before proceeding, make sure to delete the myapp-test deployment and its corresponding HPA resource.<\/p>\n
<\/code><\/pre>\n\n- kubectl delete hpa myapp-test<\/li>\n
- kubectl delete deployment myapp-test<\/li>\n<\/ol>\n
<\/code><\/pre>\n <\/p>\n
<\/code><\/pre>\nStep 3 – Automatically scale applications using the Metrics Server.<\/h2>\n
In this final stage, you will conduct experiments using two methods to generate server load and scale through a YAML manifest.<\/p>\n
\n- \n
One possible paraphrasing could be:<\/ol>\n<\/li>\n<\/ol>\nA software deployment that generates a consistent workload by executing computationally intensive tasks.
\nA shell script emulates that external workload by making rapid and consecutive HTTP requests for a web application.<\/p>\n
Continuous Load Test<\/h3>\n
You will be developing a sample application utilizing Python in this situation. The application will execute some computationally intensive tasks. This Python code is present in one of the example manifests in the starter kit, just like the shell script in the previous step. To access it, you can use nano or any other preferred text editor to open the constant-load-deployment-test.yaml file.<\/p>\n
<\/code><\/pre>\n\n- nano<\/span> Kubernetes-Starter-Kit-Developers\/09-scaling-application-workloads\/assets\/manifests\/hpa\/metrics-server\/constant-load-deployment-test.yaml<\/li>\n<\/ol>\n
<\/code><\/pre>\n <\/p>\n
<\/code><\/pre>\nconstant-load-deployment-test.yaml can be paraphrased as a YAML file for testing continuous deployment under consistent load.<\/div>\n---\r\napiVersion: v1\r\nkind: ConfigMap\r\nmetadata:\r\n name: python-test-code-configmap\r\ndata:\r\n entrypoint.sh: |-\r\n #!\/usr\/bin\/env python\r\n\r\n import math<\/mark>\r\n\r\n while True:<\/mark>\r\n x = 0.0001<\/mark>\r\n for i in range(1000000):<\/mark>\r\n x = x + math.sqrt(x)<\/mark>\r\n print(x)<\/mark>\r\n print(\"OK!\")<\/mark>\r\n\r\n---\r\napiVersion: apps\/v1\r\nkind: Deployment\r\nmetadata:\r\n name: constant-load-deployment-test\r\nspec:\r\n selector:\r\n matchLabels:\r\n run: python-constant-load-test\r\n replicas: 1\r\n template:\r\n metadata:\r\n labels:\r\n run: python-constant-load-test\r\n spec:\r\n containers:\r\n - name: python-runtime\r\n image: python:alpine3.15\r\n resources:\r\n limits:\r\n cpu: 50m\r\n requests:\r\n cpu: 20m\r\n command:\r\n - \/bin\/entrypoint.sh\r\n volumeMounts:\r\n - name: python-test-code-volume\r\n mountPath: \/bin\/entrypoint.sh\r\n readOnly: true\r\n subPath: entrypoint.sh\r\n volumes:\r\n - name: python-test-code-volume\r\n configMap:\r\n defaultMode: 0700\r\n name: python-test-code-configmap\r\n<\/code><\/pre>\nAbove, you can see the highlighted Python code that continuously generates random square roots. To execute this code, the deployment process will retrieve a docker image containing the necessary python runtime. It will then connect a ConfigMap to the application Pod that hosts the Python script given earlier.<\/p>\n
To improve observability, begin by generating a distinct namespace for this deployment. Subsequently, deploy it using kubectl.<\/p>\n
<\/code><\/pre>\n\n- kubectl create ns hpa-constant-load<\/li>\n
- <\/li>\n
- kubectl apply -f<\/span> Kubernetes-Starter-Kit-Developers\/09-scaling-application-workloads\/assets\/manifests\/hpa\/metrics-server\/constant-load-deployment-test.yaml -n<\/span> hpa-constant-load<\/li>\n<\/ol>\n
<\/code><\/pre>\n <\/p>\n
<\/code><\/pre>\n<\/code><\/pre>\nOutput<\/div>\n<\/code><\/pre>\nconfigmap\/python-test-code-configmap created deployment.apps\/constant-load-deployment-test created<\/p>\n
<\/code><\/pre>\n\nNote<\/p>\n
Please ensure that resource request limits are set for the Pods of the sample application as it is crucial for the HPA logic to function properly. It is recommended to set resource request limits for all your application Pods to prevent any unforeseen bottlenecks.<\/div>\n<\/div>\nPlease confirm that the deployment was successfully created and is operational.<\/p>\n