Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
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 e 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:
- Use quotas de recursos para dar às equipas ou cargas de trabalho uma quantidade fixa de recursos
- Limitar o impacto da manutenção programada utilizando orçamentos para desmantelamento de cápsulas
Impor cotas de recursos
Orientações sobre boas práticas
Planeje e aplique cotas de recursos no nível do namespace. Use quotas e limites de intervalos para exigir ou fornecer pedidos de recursos por defeito e limites para pods. Monitore o uso de recursos e ajuste as cotas conforme necessário.
Defina pedidos de recursos e limites de recursos na especificação do pod. Um pedido de recurso é a quantidade de CPU ou memória que o escalonador Kubernetes usa para colocar um pod. Um limite de recursos limita quanto desse recurso um contentor pode usar. O sistema impõe limites de CPU através de throttling, enquanto aplica limites de memória de forma reativa através da terminação fora de memória (OOM). Para mais informações, veja Definir pedidos de recursos pod e limites.
Use quotas de recursos para limitar o consumo agregado de recursos para uma equipa de desenvolvimento ou projeto. Defina quotas ao 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 a quantidade de espaço em disco para uma dada classe de armazenamento.
- Contagem de objetos, como o número máximo de segredos, serviços ou trabalhos que podem ser criados.
O escalonador Kubernetes utiliza pedidos de recursos para colocar pods. Os contentores podem usar mais CPU ou memória do que o solicitado quando a capacidade está disponível, e os limites de recursos podem exceder os pedidos. Uma quota de recursos limita separadamente o consumo agregado de espaços de nomes. Se criar ou atualizar um recurso exceder uma quota rígida, o servidor API rejeita o pedido com uma resposta HTTP 403 Forbidden . Ainda podes criar um objeto de carga de trabalho, como um Deployment, mesmo quando a quota impede o controlador de criar todos os pods solicitados.
Se uma quota de recursos acompanha CPU ou memória, cada novo pod deve especificar um pedido ou limite para esse recurso. Caso contrário, o servidor API pode rejeitar o pod. Pode configurar pedidos e limites por defeito para um namespace usando um LimitRange.
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 limita os pedidos de CPU agregados a 10 CPUs, os pedidos de memória agregados a 20 Gi e o número de pods não terminais a 10 no namespace.
Aplicar esta quota de recursos a um 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.
Limitar o impacto da perturbação utilizando orçamentos de disrupção de pods (PDBs)
Orientações sobre boas práticas
Defina Orçamentos de Disrupção de Pods (PDBs) para aplicações replicadas, de modo a limitar despejos voluntários simultâneos durante eventos como drenagens de nós AKS. Manter réplicas saudáveis suficientes e permitir pelo menos uma perturbação quando a carga de trabalho o permitir, para que a manutenção do cluster possa avançar.
Eventos disruptivos que removem cápsulas dividem-se em duas categorias:
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. Os exemplos incluem:
- Falha de hardware na máquina física
- Pânico do kernel
- Eliminação de uma VM de nó
Pode mitigar perturbações involuntárias 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
_ Os disruptions_ voluntários são eventos solicitados pelo operador do cluster ou pelo proprietário da aplicação. Os exemplos incluem:
- Drenar um nó durante uma atualização de cluster
- Atualização de um modelo de implementação
- Apagar diretamente um pod
Nem todas as perturbações voluntárias estão limitadas por PDBs. Eliminar diretamente um pod ou objeto de carga de trabalho contorna PDBs, e controladores de carga de trabalho como Deployments e StatefulSets não são limitados por PDBs durante atualizações contínuas. Configure a estratégia de implementação da carga de trabalho separadamente para manter a disponibilidade durante as atualizações da aplicação. Para mais informações, consulte Disrupções no Kubernetes.
Os PDBs limitam despejos voluntários simultâneos para pods selecionados através da API de Despejos do Kubernetes. Durante uma atualização contínua do AKS, o AKS adiciona capacidade de pico de acordo com as definições do pool de nós, limita e drena um nó, e depois reimagina ou substitui o nó drenado. A API de Despejo avalia o PDB durante o dreno. Após uma expulsão, o controlador de carga de trabalho cria um pod de substituição, e o agendador coloca-o num nó com capacidade disponível. Um PDB restritivo, réplicas saudáveis insuficientes ou capacidade insuficiente do cluster podem atrasar ou bloquear o dreno.
Defina um número mínimo de pods disponíveis
Considere um ReplicaSet com cinco pods NGINX rotulados app: nginx-frontend. Durante um evento voluntário de perturbação, como uma atualização de cluster, pelo menos três pods devem permanecer disponíveis. O seguinte PodDisruptionBudget manifesto define este requisito:
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: nginx-pdb
spec:
minAvailable: 3
unhealthyPodEvictionPolicy: AlwaysAllow
selector:
matchLabels:
app: nginx-frontend
Este orçamento exige pelo menos três pods com a etiqueta app: nginx-frontend para se manterem saudáveis durante uma expulsão voluntária.
Podes especificar uma percentagem, como 60%, para que o orçamento se ajuste quando o ReplicaSet escala.
Defina um número máximo de pods indisponíveis
Um PDB pode definir ou minAvailable ou maxUnavailable, mas não ambos. Para restringir despejos voluntários com base em pods indisponíveis, especifique maxUnavailable como um número inteiro ou uma percentagem. O seguinte manifesto permite uma expulsão voluntária apenas quando não mais do que dois pods no ReplicaSet estiverem indisponíveis após a expulsão:
apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
name: nginx-pdb
spec:
maxUnavailable: 2
unhealthyPodEvictionPolicy: AlwaysAllow
selector:
matchLabels:
app: nginx-frontend
Este orçamento permite um despejo voluntário apenas quando não mais do que dois pods com o rótulo app: nginx-frontend ficam indisponíveis após o despejo. Interrupções involuntárias podem ainda assim fazer com que a disponibilidade fique abaixo deste limiar.
A AlwaysAllow política de despejo de pods insalubres permite que um drenador despeje pods em funcionamento que não sejam saudáveis. Sem esta definição, a política padrão IfHealthyBudget pode bloquear um dreno enquanto se espera que os pods doentes fiquem saudáveis. Use AlwaysAllow quando a drenabilidade for mais importante do que dar mais tempo a uma cápsula doente para recuperar.
Guarda o manifesto PDB que queres usar como nginx-pdb.yaml, e depois aplica-o ao teu cluster AKS:
kubectl apply -f nginx-pdb.yaml
Antes da manutenção do cluster, verifique se cada PDB permite o despejo esperado:
kubectl get poddisruptionbudgets --namespace <namespace>
Um ALLOWED DISRUPTIONS valor de 0 pode bloquear um dreno de nó AKS. Trabalhe com os seus programadores e proprietários de aplicações para manter réplicas saudáveis suficientes e escolha um orçamento que equilibre a disponibilidade da aplicação com os requisitos de manutenção.
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.
Conteúdo relacionado
Este artigo foca-se nas funcionalidades básicas do escalonador Kubernetes. Para mais informações sobre operações de cluster no AKS, consulte os seguintes artigos sobre boas práticas: