Implementando apps para conjuntos de trabalhadores onde o ajuste automático de escala está ativado

Para limitar uma implementação de pod a um conjunto de trabalhadores específico que é gerenciado pelo escalador automático de cluster, use uma combinação de rótulos e nodeSelector ou nodeAffinity para implementar apps somente nos conjuntos de trabalhadores escalados automaticamente. Com nodeAffinity, você tem mais controle sobre como o comportamento de planejamento funciona para corresponder os pods aos nós do trabalhador. Em seguida, use contaminações e tolerâncias para que somente esses apps possam ser executados em seus conjuntos de trabalhadores escalados automaticamente.

Para obter mais informações, consulte os docs do Kubernetes a seguir:

Antes de iniciar:

Para limitar os pods a serem executados em determinados conjuntos de trabalhadores escalados automaticamente:

Certifique-se de que você tenha rotulado e contaminado seu conjunto de trabalhadores escalado automaticamente, conforme descrito em Preparando seu cluster para ajuste automático de escala.

Em seu modelo de especificação de pod, corresponda o nodeSelector ou nodeAffinity ao rótulo que você usou em seu conjunto de trabalhadores.

Exemplo de nodeSelector:

...
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  nodeSelector:
    app: nginx
...

Exemplo de nodeAffinity:

spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  affinity:
    nodeAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions:
          - key: use
            operator: In
            values:
            - autoscale

Em seu modelo de especificação de pod, corresponda a toleration à contaminação que você configurou em seu conjunto de trabalhadores.

Exemplo de tolerância de NoExecute:
```
tolerations:
  - key: use
    operator: "Exists"
    effect: "NoExecute"
```
Implemente o pod. Devido ao rótulo correspondente, o pod é planejado em um nó do trabalhador que está no conjunto de trabalhadores rotulados. Devido à tolerância correspondente, o pod pode ser executado no conjunto de trabalhadores contaminados.
```
oc apply -f pod.yaml
```

Aumentando a capacidade dos nós do trabalhador antes que o conjunto de trabalhadores tenha recursos insuficientes

Conforme descrito no tópico Entendendo como o autoscaler de cluster funciona e nas Perguntas frequentes sobre o autoscaler de cluster Kubernetes, o autoscaler de cluster dimensiona seus pools de trabalho em resposta aos recursos solicitados da carga de trabalho em relação aos recursos disponíveis do pool de trabalho. No entanto, é possível que você queira que o escalador automático de cluster aumente a capacidade dos nós do trabalhador antes que o conjunto de trabalhadores fique sem recursos. Nesse caso, sua carga de trabalho não precisa esperar o fornecimento dos nós do trabalhador porque a capacidade do conjunto de trabalhadores já foi aumentada para atender às solicitações de recurso.

O escalador automático de cluster não suporta ajuste de escala antecipado (fornecimento extra) de conjuntos de trabalhadores. No entanto, é possível configurar outros recursos do Kubernetes para trabalhar com o escalador automático de cluster para atingir o ajuste de escala antecipado.

Pausar pods

É possível criar uma implementação que instale contêineres pause em pods com solicitações de recursos específicas e designar à implementação uma prioridade de pod baixa. Quando esses recursos são necessários por cargas de trabalho de prioridade mais alta, o pod de pausa é priorizado e torna-se um pod pendente. Esse evento aciona o autoscaler de cluster para aumentar a escala.

Para obter mais informações sobre a configuração de uma implementação de pod pause, consulte as FAQs do Kubernetes. É possível usar este exemplo de arquivo de configuração de superprovisionamento para criar a classe de prioridade, a conta do serviço e as implementações.

Se usar esse método, certifique-se de entender como a prioridade de pod funciona e como configurá-la para suas implementações. Por exemplo, se o pod de pausa não tiver recursos suficientes para um pod de prioridade mais alta, o pod não será priorizado. A carga de trabalho de prioridade mais alta permanece pendente, portanto, o escalador automático de cluster é acionado para aumentar a capacidade. No entanto, nesse caso, a ação de aumento de escala não é precoce, pois a carga de trabalho que você deseja executar não pode ser planejada devido a recursos insuficientes. O pod de pausa deve ter o nodeAffinity ou nodeSelector correspondente, bem como as tolerâncias correspondentes que você configura para o seu conjunto de trabalhadores.

HPA (Horizontal pod autoscaling)

Como o ajuste automático de escala de pod horizontal é baseado no uso médio de CPU dos pods, o limite de uso de CPU que você configura é atingido antes que o conjunto de trabalhadores fique sem recursos.

Mais pods são solicitados, o que aciona o escalador automático de cluster para aumentar a capacidade do conjunto de trabalhadores. Para obter mais informações sobre a configuração do HPA, consulte os Docs do Kubernetes.