O escalonamento automático de um grupo de nós até zero ajuda a economizar recursos quando eles não estão em uso. Isso é útil para tarefas pontuais (por exemplo, Jobs) ou ambientes de staging que ficam inativos durante a noite.
O escalonamento para zero nós é um caso especial de autoescalonamento. Portanto, os mesmos princípios, limitações e requisitos descritos para o autoescalonamento padrão também se aplicam aqui.
Para que o escalonamento até zero funcione, o cluster ainda deve ter pelo menos outro grupo com 1–2 nós permanentemente ativos. Esses nós são necessários para os componentes do sistema do Kubernetes.
Para que o autoscaler inicie nós no grupo desejado, especifique o ID desse grupo no manifesto usando nodeSelector ou nodeAffinity.
https://my.hostman.com/kubernetes/1048329/54289/edit
Onde:
1048329: ID do cluster54289: ID do grupo de nósExemplo com nodeSelector:
nodeSelector:
k8s.hostman.com/cluster-node-group-id: "54289"
Exemplo com nodeAffinity:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: k8s.hostman.com/cluster-node-group-id
operator: In
values:
- "54289"
O autoscaler não poderá remover o último nó de um grupo nos seguintes casos:
cluster-autoscaler.kubernetes.io/safe-to-evict: "false"PodDisruptionBudget impede a exclusão de pods sem exceder o limite definidoDeployment, StatefulSet, Job, ReplicaSet)Neste exemplo, criaremos um grupo de nós com escalonamento automático para zero habilitado, executaremos um Job nele e veremos como o cluster cria automaticamente um nó para executar a tarefa e o remove após a conclusão.
Um cluster Kubernetes existente com pelo menos um grupo de nós.
Após a criação do grupo, um nó será exibido e será removido automaticamente se não houver pods de usuário em execução.
Agora o cluster possui dois grupos:
Execute o comando:
kubectl get nodes
Exemplo de saída:
NAME STATUS ROLES AGE VERSION
worker-192.168.0.25 Ready <none> 21h v1.33.3+k0s
worker-192.168.0.8 Ready <none> 22h v1.33.3+k0s
Crie um arquivo chamado job.yaml com o seguinte conteúdo:
apiVersion: batch/v1
kind: Job
metadata:
name: hello-job
spec:
ttlSecondsAfterFinished: 30
template:
metadata:
name: hello-job
spec:
restartPolicy: Never
nodeSelector:
k8s.hostman.com/cluster-node-group-id: "54289"
containers:
- name: hello
image: busybox
command:
- sh
- -c
- 'i=0; while [ $i -lt 10 ]; do echo "Hello from job"; sleep 30; i=$((i+1)); done'
resources:
requests:
cpu: "50m"
memory: "32Mi"
limits:
cpu: "100m"
memory: "64Mi"
Este Job executa um contêiner usando a imagem busybox que grava uma mensagem no log 10 vezes em intervalos de 30 segundos.
Observação: na seção nodeSelector, especificamos o ID do grupo de nós (54289).
Aplique o manifesto:
kubectl apply -f job.yaml
Verifique a lista de pods:
kubectl get pod
Exemplo de saída:
NAME READY STATUS RESTARTS AGE
hello-job-s7ktd 0/1 Pending 0 4s
O pod está com status Pending porque ainda não há nós no grupo. Vá até a seção Recursos no painel de Hostman; você verá que um novo nó está sendo criado no grupo de autoescalonamento.
Após a criação do nó, verifique novamente:
kubectl get nodes
Exemplo de saída:
NAME STATUS ROLES AGE VERSION
worker-192.168.0.25 Ready <none> 21h v1.33.3+k0s
worker-192.168.0.6 Ready <none> 7m v1.33.3+k0s
worker-192.168.0.8 Ready <none> 22h v1.33.3+k0s
worker-192.168.0.6 é o novo nó criado para o Job.
Verifique o pod novamente:
kubectl get pod
Exemplo de saída:
NAME READY STATUS RESTARTS AGE
hello-job-s7ktd 1/1 Running 0 5m30s
Agora o pod está em execução.
Após a conclusão do Job, o nó onde ele estava em execução receberá um taint. Visualize o taint com:
kubectl describe node worker-192.168.0.6
Procure a linha:
Taints: DeletionCandidateOfClusterAutoscaler=1755679271:PreferNoSchedule
Isso significa que o nó foi marcado para exclusão. Dois minutos após a aplicação do taint, o nó será removido.
Verifique com:
kubectl get nodes