Práticas recomendadas para recursos do Agendador básico no serviço de Kubernetes do Azure (AKS)

À medida que você gerencia clusters no Serviço de Kubernetes do Azure (AKS), geralmente é necessário isolar equipes e cargas de trabalho. O agendador do Kubernetes permite controlar a distribuição de recursos de computação e limitar o impacto dos eventos de manutenção.

Este artigo sobre práticas recomendadas se concentra em recursos de agendamento de Kubernetes básicos para os operadores do cluster. Neste artigo, você aprenderá como:

Impor cotas de recursos

Orientação de melhor prática

Planejar e aplicar cotas de recursos no nível do namespace. Use cotas e limite de intervalos para exigir ou fornecer solicitações e limites de recursos padrão para pods. Monitorare o uso de recursos e ajuste as cotas conforme necessário.

Defina solicitações de recurso e limites de recursos na especificação do pod. Uma solicitação de recurso é a quantidade de CPU ou memória que o agendador do Kubernetes usa para colocar um pod. Um limite de recursos restringe quanto desse recurso um contêiner pode usar. O sistema impõe limites de CPU por limitação, enquanto impõe limites de memória reativamente por meio da terminação OOM (fora da memória). Para obter mais informações, consulte Definir solicitações e limites de recursos do pod.

Use cotas de recursos para limitar o consumo de recursos agregados para uma equipe ou projeto de desenvolvimento. Definir cotas no nível do namespace para:

• Recursos de computação, como CPU e memória ou GPUs.
• Recursos de armazenamento, incluindo o número total de volumes ou quantidade de espaço em disco para uma classe de armazenamento específica.
• Contagem de objetos, como o número máximo de segredos, serviços ou trabalhos que podem ser criados.

O agendador do Kubernetes usa solicitações de recurso para colocar pods. Os contêineres podem usar mais CPU ou memória do que o solicitado quando a capacidade está disponível e os limites de recursos podem exceder as solicitações. Uma cota de recursos limita separadamente o consumo de namespace agregado. Se a criação ou atualização de um recurso exceder uma cota rígida, o servidor de API rejeitará a solicitação com uma resposta HTTP 403 Forbidden . Você ainda pode criar um objeto de carga de trabalho, como uma Implantação, mesmo quando a cota impede que seu controlador crie todos os pods solicitados.

Se uma cota de recursos rastrear a CPU ou a memória, cada novo pod deverá especificar uma solicitação ou um limite para esse recurso. Caso contrário, o servidor de API poderá rejeitar o pod. Você pode configurar solicitações e limites padrão para um namespace usando um LimitRange.

O manifesto YAML do exemplo a seguir chamado dev-app-team-quotas.yaml define um limite rígido de um total de 10 CPUs, Gi 20 de memória, e 10pods:

apiVersion: v1
kind: ResourceQuota
metadata:
  name: dev-app-team
spec:
  hard:
    cpu: "10"
    memory: 20Gi
    pods: "10"

Essa cota limita as solicitações de CPU de agregação a 10 CPUs, solicitações de memória agregadas a 20Gi e o número de pods nãominais em 10 no namespace.

Aplique essa cota de recursos a um namespace, como aplicativos de desenvolvimento:

kubectl apply -f dev-app-team-quotas.yaml --namespace dev-apps

Trabalhe com seus desenvolvedores de aplicativos e proprietários para entender suas necessidades e aplicar as cotas de recurso apropriado.

Para obter mais informações sobre objetos de recursos disponíveis, escopos e prioridades, consulte Cotas de recursos no Kubernetes.

Limitar o impacto da interrupção usando PDBs (orçamentos de interrupção do pod)

Orientação de melhor prática

Defina PDBs (Orçamentos de Interrupção do Pod) para aplicativos replicados para limitar remoções voluntárias simultâneas durante eventos como drenos de nós do AKS. Mantenha réplicas íntegras suficientes e permita pelo menos uma interrupção quando a carga de trabalho permitir para que a manutenção do cluster possa continuar.

Eventos disruptivos que removem pods se enquadram em duas categorias:

Interrupções involuntárias

Interrupções involuntárias são eventos além do controle típico do operador de cluster ou o proprietário do aplicativo. Os exemplos incluem:

• Falha de hardware no computador físico
• Pane do kernel
• Exclusão de uma máquina virtual de nó

Você pode atenuar interrupções involuntárias:

• Usar várias réplicas dos seus pods em uma implantação.
• Executar vários nós no cluster AKS.

Interrupções voluntárias

_ Disruptions_ voluntários são eventos que o operador de cluster ou o proprietário do aplicativo solicita. Os exemplos incluem:

• Esvaziando um nó durante uma atualização de cluster
• Atualizando um modelo de implantação
• Excluindo diretamente um pod

Nem todas as interrupções voluntárias são restritas por PDBs. A exclusão direta de um pod ou objeto de carga de trabalho ignora PDBs e os controladores de carga de trabalho, como Implantações e StatefulSets, não são limitados por PDBs durante atualizações sem interrupção. Configure a estratégia de distribuição da carga de trabalho separadamente para manter a disponibilidade durante as atualizações do aplicativo. Para obter mais informações, consulte Interrupções no Kubernetes.

Os PDBs limitam remoções voluntárias simultâneas para pods selecionados por meio da API de Remoção do Kubernetes. Durante uma atualização sem interrupção do AKS, o AKS adiciona capacidade de aumento de acordo com as configurações do pool de nós, isola e drena um nó e, em seguida, reimageia ou substitui o nó drenado. A API de Remoção avalia o PDB durante o dreno. Após uma remoção, o controlador de carga de trabalho cria um pod de substituição e o agendador o coloca em um nó com capacidade disponível. Um PDB restritivo, réplicas íntegras insuficientes ou capacidade insuficiente do cluster podem atrasar ou bloquear o dreno.

Definir um número mínimo de pods disponíveis

Considere um ReplicaSet com cinco pods NGINX rotulados app: nginx-frontend. Durante um evento de interrupção voluntária, como uma atualização de cluster, pelo menos três pods devem permanecer disponíveis. O manifesto PodDisruptionBudget a seguir define esse requisito:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: nginx-pdb
spec:
  minAvailable: 3
  unhealthyPodEvictionPolicy: AlwaysAllow
  selector:
    matchLabels:
      app: nginx-frontend

Esse orçamento requer que pelo menos três pods com o rótulo app: nginx-frontend permaneçam íntegros durante uma remoção voluntária.

Você pode especificar uma porcentagem, como 60%, para que o orçamento seja ajustado quando o ReplicaSet for dimensionado.

Definir um número máximo de pods indisponíveis

Um PDB pode definir um minAvailable ou maxUnavailable, mas não ambos. Para restringir remoções voluntárias com base em pods indisponíveis, especifique maxUnavailable como um inteiro ou uma porcentagem. O manifesto a seguir permite uma remoção voluntária somente quando não mais de dois pods no ReplicaSet ficarão indisponíveis após a remoção:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: nginx-pdb
spec:
  maxUnavailable: 2
  unhealthyPodEvictionPolicy: AlwaysAllow
  selector:
    matchLabels:
      app: nginx-frontend

Esse orçamento permite uma remoção voluntária somente quando não mais do que dois pods com o rótulo app: nginx-frontend estariam indisponíveis após o despejo. Interrupções involuntárias ainda podem fazer com que a disponibilidade fique abaixo desse limite.

A AlwaysAllow política de remoção de pod não íntegra permite esvaziar pods em execução que não estão íntegros. Sem essa configuração, a política padrão IfHealthyBudget pode bloquear um dreno enquanto aguarda que pods não íntegros se tornem íntegros. Use AlwaysAllow quando a drenabilidade for mais importante do que dar a um pod não íntegro mais tempo para recuperação.

Salve o manifesto PDB que você deseja usar como nginx-pdb.yaml e aplique-o ao cluster do AKS:

kubectl apply -f nginx-pdb.yaml

Antes da manutenção do cluster, verifique se cada PDB permite a remoção esperada:

kubectl get poddisruptionbudgets --namespace <namespace>

Um ALLOWED DISRUPTIONS valor de pode bloquear um dreno de 0 nós do AKS. Trabalhe com seus desenvolvedores e proprietários de aplicativos para manter réplicas íntegras suficientes e escolher um orçamento que balancee a disponibilidade do aplicativo com os requisitos de manutenção.

Para obter mais informações sobre como usar os orçamentos de interrupção de pod, consulte Especificar um orçamento de interrupção para o seu aplicativo.

Conteúdo relacionado

Este artigo se concentra nos recursos básicos do agendador do Kubernetes. Para obter mais informações sobre operações de cluster no AKS, consulte os seguintes artigos de práticas recomendadas:

• Isolamento de cluster e multilocação
• Recursos avançados de Agendador Kubernetes
• Autenticação e autorização