Melhores práticas para funcionalidades básicas do scheduler no Azure Kubernetes Service (AKS)

Ao gerenciar clusters no Serviço Kubernetes do Azure (AKS), muitas vezes você precisa isolar equipes e cargas de trabalho. O escalonador Kubernetes permite-lhe controlar a distribuição dos recursos de computação ou limitar o impacto dos eventos de manutenção.

Este artigo de boas práticas foca-se nas funcionalidades básicas de agendamento do Kubernetes para operadores de cluster. Neste artigo, você aprenderá a:

Impor cotas de recursos

Orientações sobre boas práticas

Planeje e aplique cotas de recursos no nível do namespace. Se os pods não definirem pedidos de recursos e limites, rejeite a implementação. Monitore o uso de recursos e ajuste as cotas conforme necessário.

Os pedidos de recursos e os limites são colocados na especificação do pod. As solicitações são usadas pelo escalonador do Kubernetes durante o momento da implementação para encontrar um nó disponível no cluster. Limites e pedidos funcionam no nível individual de cada pod. Para mais informações sobre como definir estes valores, consulte Definir pedidos de recursos pod e limites.

Para proporcionar uma forma de reservar e limitar recursos numa equipa de desenvolvimento ou projeto, deve usar quotas de recursos. Estas quotas são definidas num namespace e podem ser usadas para definir quotas com base na seguinte base:

• Recursos de computação, como CPU e memória, ou GPUs.
• Recursos de armazenamento, incluindo o número total de volumes ou a quantidade de espaço em disco para uma dada classe de armazenamento.
• A contagem de objetos, como o número máximo de segredos, serviços ou trabalhos, pode ser criada.

O Kubernetes não sobrecarrega recursos. Quando o total acumulado de pedidos de recursos ultrapassar a quota atribuída, todas as implantações seguintes serão infrutíferas.

Quando você define cotas de recursos, todos os pods criados no namespace devem fornecer limites ou solicitações em suas especificações de pod. Se não fornecerem esses valores, pode-se rejeitar o desdobramento. Em vez disso, pode configurar pedidos e limites padrão para um namespace.

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

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

Esta quota de recursos pode ser aplicada especificando o namespace, como dev-apps:

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

Trabalhe com os seus desenvolvedores e proprietários de aplicações para compreender as suas necessidades e aplicar as quotas de recursos adequadas.

Para mais informações sobre objetos, âmbitos e prioridades de recursos disponíveis, consulte Quotas de recursos no Kubernetes.

Planeie a disponibilidade usando orçamentos para perturbação de pods

Orientações sobre boas práticas

Para manter a disponibilidade das aplicações, defina Pod Disruption Budgets (PDBs) para garantir que há um número mínimo de pods disponíveis no cluster.

Existem dois eventos disruptivos que fazem com que os pods sejam removidos:

Interrupções involuntárias

Interrupções involuntárias são eventos fora do controlo típico do operador do cluster ou do proprietário da aplicação. Include:

• Falha de hardware na máquina física
• Kernel panic
• Eliminação de uma VM de nó

As perturbações involuntárias podem ser mitigadas através de:

• Usar múltiplas réplicas dos teus pods numa implementação.
• Executar múltiplos nós no cluster AKS.

Interrupções voluntárias

Interrupções voluntárias são eventos solicitados pelo operador do cluster ou pelo proprietário da aplicação. Incluir:

• Atualizações de cluster
• Modelo de implementação atualizado
• Apagar acidentalmente um pod

O Kubernetes disponibiliza orçamentos de disrupções nos pods para disrupções voluntárias, permitindo-lhe planear como as implementações ou conjuntos de réplicas respondem quando ocorre um evento de disrupção voluntária. Usando orçamentos de disrupção de pods, os operadores de cluster podem definir um número mínimo de recursos disponíveis ou máximo de recursos indisponíveis.

Se atualizar um cluster ou um modelo de implementação, o escalonador Kubernetes agendará pods adicionais noutros nós antes de permitir que ocorrências de perturbação voluntária continuem. O escalonador espera para reiniciar um nó até que o número definido de pods seja alocado com êxito noutros nós do cluster.

Vamos ver um exemplo de um conjunto réplica com cinco pods que funcionam com NGINX. Os pods no ReplicaSet recebem a etiqueta app: nginx-frontend. Durante um evento voluntário de perturbação, como uma atualização de cluster, deve-se garantir que pelo menos três pods continuem a funcionar. O seguinte manifesto YAML para um objeto PodDisruptionBudget define estes requisitos:

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

Também podes definir uma percentagem, como 60%, que te permite compensar automaticamente ao aumentar-se o número de pods no conjunto de réplicas.

Podes definir um número máximo de instâncias indisponíveis num conjunto de réplicas. Pode também ser definida, mais uma vez, uma percentagem para o número máximo de pods indisponíveis. O seguinte manifesto YAML do orçamento de perturbação de pods define que não mais do que dois pods no conjunto de réplicas devem estar indisponíveis:

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

Depois de definido o seu orçamento de disrupção de pods, cria-o no seu cluster AKS como em qualquer outro objeto Kubernetes:

kubectl apply -f nginx-pdb.yaml

Trabalhe com os seus programadores e proprietários de aplicações para compreender as suas necessidades e aplicar os orçamentos adequados para a interrupção dos pods.

Para mais informações sobre a utilização de interrupções de pods, consulte Como especificar um orçamento de interrupção para a sua aplicação.

Passos seguintes

Este artigo focou-se nas funcionalidades básicas do escalonador do Kubernetes. Para obter mais informações sobre operações de cluster no AKS, consulte as seguintes práticas recomendadas:

• Multilocação e isolamento de cluster
• Funcionalidades avançadas do escalonador Kubernetes
• Autenticação e autorização