background

When a NODE pool is configured for a TKE cluster and elastic scaling is enabled, automatic capacity expansion (buying machines and adding them to the cluster) can be triggered when node resources are insufficient. However, the capacity expansion process takes some time to complete. In some scenarios with high traffic, the capacity expansion speed may be too slow, affecting services. Tke-autohistamy-placeholder can be used to achieve second scaling on TKE for such high traffic scenarios.

How does it work?

Tke-autoscaly-placeholder actually uses low-priority pods to hold resources in advance (pause containers with request do not actually consume resources), reserving some resources for high-priority services that may experience traffic spikes. When capacity expansion is required, high-priority PODS can quickly seize the resources of low-priority pods for scheduling, while low-priority TKE-autoscaly-placeholder pods will be “crowded” and their state will become Pending. If a node pool is configured and elastic scaling is enabled, node capacity expansion is triggered. In this way, with some resources as a buffer, even if the node expansion is slow, it can ensure that some PODS can be rapidly expanded and scheduled to achieve second scaling. To adjust the amount of reserved buffer resources, adjust the number of REQUESTS or copies in the TKE-autoscaly-placeholder according to actual demand.

What are the restrictions?

The application requires a cluster version of 1.18 or older.

How to use it?

Install tke – autoscaling – placeholder

Find tKE-Autoscaly-Placeholder in the app market, click on the App details, and then click Create App:

ReplicaCount and Resources.request are the most important parameters in the application configuration. Represents respectively the number of copies in TKE-autoscaly-placeholder and the resource size of each copy placeholder, which together determine the size of buffer resources, and can be estimated and set according to the amount of additional resources required by traffic surges.

Finally, click Create, and you can check whether the pods for resource placeholder are started successfully:

$ kubectl get pod -n default
tke-autoscaling-placeholder-b58fd9d5d-2p6ww   1/1     Running   0          8s
tke-autoscaling-placeholder-b58fd9d5d-55jw7   1/1     Running   0          8s
tke-autoscaling-placeholder-b58fd9d5d-6rq9r   1/1     Running   0          8s
tke-autoscaling-placeholder-b58fd9d5d-7c95t   1/1     Running   0          8s
tke-autoscaling-placeholder-b58fd9d5d-bfg8r   1/1     Running   0          8s
tke-autoscaling-placeholder-b58fd9d5d-cfqt6   1/1     Running   0          8s
tke-autoscaling-placeholder-b58fd9d5d-gmfmr   1/1     Running   0          8s
tke-autoscaling-placeholder-b58fd9d5d-grwlh   1/1     Running   0          8s
tke-autoscaling-placeholder-b58fd9d5d-ph7vl   1/1     Running   0          8s
tke-autoscaling-placeholder-b58fd9d5d-xmrmv   1/1     Running   0          8s
Copy the code

The full allocation of TKE-autoscaly-placeholder is shown in the table below:

parameter describe The default value
replicaCount Placeholder copies 10
image Placeholder mirror address ccr.ccs.tencentyun.com/library/pause:latest
resources.requests.cpu CPU resource size occupied by a single placeholder copy 300m
resources.requests.memory Size of memory occupied by a single placeholder copy 600Mi
lowPriorityClass.create Whether to create a low-priority PriorityClass (referenced by the placeholder) true
lowPriorityClass.name The name of the low-priority PriorityClass low-priority
nodeSelector The specified placeholder is scheduled to nodes with specific labels {}
tolerations Specifies stains that the placeholder will tolerate []
affinity Specify affinity configuration for placeholder {}

Deploy high-priority PODS

The priority of TKE-Autoscaly-placeholder is very low, so our business Pod can specify a PriorityClass with a high priority, which is convenient to seize resources and achieve rapid expansion. If not, we can create one first:

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000000
globalDefault: false
description: "high priority class"
Copy the code

Specify priorityClassName as the high-priority PriorityClass in our business Pod:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 8
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      priorityClassName: high-priority This specifies the high priority PriorityClass
      containers:
      - name: nginx
        image: nginx
        resources:
          requests:
            cpu: 400m
            memory: 800Mi
Copy the code

When cluster node resources are insufficient, expanded high-priority business PODS can seize Pod resources from lower-priority TKE-Autoscale-placeholder and schedule them. Then tKE-autoscaly-placeholder Pod Pending:

$ kubectl get pod -n default
NAME                                          READY   STATUS    RESTARTS   AGE
nginx-bf79bbc8b-5kxcw                         1/1     Running   0          23s
Copy the code