Como preparar um nó do Kubernetes para manutenção

Os nós do Kubernetes precisam de manutenção ocasional. Você pode atualizar o kernel do nó, redimensionar seu recurso de computação em sua conta de nuvem ou substituir componentes de hardware físico em uma instalação auto-hospedada.

Os cabos e drenos do Kubernetes são dois mecanismos que você pode usar para se preparar com segurança para o tempo de inatividade do nó. Eles permitem que as cargas de trabalho executadas em um nó de destino sejam reprogramadas em outros. Você pode então desligar o nó ou removê-lo do cluster sem afetar a disponibilidade do serviço.

Aplicando um cordão de nó

Isolar um nó o marca como indisponível para o agendador do Kubernetes. O nó não estará qualificado para hospedar novos pods que serão adicionados posteriormente ao cluster.

Use o kubectl cordon comando para colocar um cordão em torno de um nó nomeado:

$ kubectl cordon node-1
node/node-1 cordoned

Os pods existentes já em execução no nó não serão afetados pelo cordão. Eles permanecerão acessíveis e continuarão sendo hospedados pelo Nó Cordoado.

Você pode verificar quais de seus nós estão atualmente isolados com o get nodes domínio:

$ kubectl get nodes
NAME       STATUS                     ROLES                  AGE   VERSION
node-1     Ready,SchedulingDisabled   control-plane,master   26m   v1.23.3

Nós cordoneados aparecem com o SchedulingDisabled doença.

Drenar um nó

A próxima etapa é drenar os pods restantes do Node. Este procedimento ejetará os pods a serem reprogramados para outros nós em seu cluster. Os pods podem terminar normalmente antes de serem removidos à força do nó de destino.

Corre kubectl drain para iniciar um procedimento de drenagem. Especifique o nome do Node que você está retirando para manutenção:

$ kubectl drain node-1
node/node-1 already cordoned
evicting pod kube-system/storage-provisioner
evicting pod default/nginx-7c658794b9-zszdd
evicting pod kube-system/coredns-64897985d-dp6lx
pod/storage-provisioner evicted
pod/nginx-7c658794b9-zszdd evicted
pod/coredns-64897985d-dp6lx evicted
node/node-1 evicted

O procedimento de drenagem primeiro isola o Node se você ainda não tiver colocado um manualmente. Em seguida, ele despejará as cargas de trabalho do Kubernetes em execução, reprogramando-as com segurança para outros nós em seu cluster.

Você pode desligar ou destruir o nó assim que a drenagem estiver concluída. Você liberou o nó de suas responsabilidades com seu cluster. O cabo garante que nenhuma nova carga de trabalho foi programada desde que a drenagem foi concluída.

Ignorar períodos de carência do pod

Às vezes, os drenos podem demorar um pouco para serem concluídos se seus pods tiverem longos períodos de carência. Isso pode não ser ideal quando você precisa colocar um nó offline com urgência. Use o --grace-period marque para substituir os períodos de carência de encerramento do pod e forçar um despejo imediato:

$ kubectl drain node-1 --grace-period 0

Isso deve ser usado com cuidado – algumas cargas de trabalho podem não responder bem se forem interrompidas sem oferecer uma chance de limpeza.

Correção de bug de drenagem

Às vezes, os drenos podem falhar dependendo dos tipos de pods que existem em seu cluster. Aqui estão dois problemas comuns com suas resoluções.

1. “Não é possível excluir pods não gerenciados por ReplicationController, ReplicaSet, Job ou StatefulSet”

Essa mensagem aparece se o nó hospedar pods que não são gerenciados por um controlador. Refere-se a pods que foram criados como objetos autônomos, onde eles não fazem parte de um recurso de nível superior, como uma implantação ou um conjunto de réplicas.

O Kubernetes não pode reagendar automaticamente esses pods “nus”, portanto, despejá-los os tornará indisponíveis. Direcione manualmente esses pods antes de drenar ou use o --force flag para permitir sua exclusão:

$ kubectl drain node-1 --force

2. “Não é possível remover pods gerenciados pelo DaemonSet”

Os pods que fazem parte de conjuntos de daemon representam um desafio para os despejos. Os controladores DaemonSet ignoram o estado programável de seus nós. A exclusão de um Pod que faz parte de um DaemonSet fará com que ele retorne imediatamente, mesmo que você tenha isolado o Node. Portanto, as operações de drenagem são canceladas com um erro para avisá-lo sobre esse comportamento.

Você pode prosseguir com o despejo adicionando o --ignore-daemonsets bandeira. Isso despejará todo o resto enquanto ignora quaisquer DaemonSets existentes.

$ kubectl drain node-1 --ignore-daemonsets

Você pode precisar usar esse sinalizador mesmo que não tenha criado um DaemonSet por conta própria. Componentes internos dentro do kube-system O namespace pode estar usando recursos do DaemonSet.

Minimizando o tempo de inatividade com orçamentos de interrupção de pod

A drenagem de um nó não garante que suas cargas de trabalho permaneçam sempre acessíveis. Seus outros nós precisarão de tempo para atender às solicitações de agendamento e criar novos contêineres.

Isso pode ser particularmente impactante se você estiver drenando vários nós em um curto espaço de tempo. A drenagem do primeiro nó pode reprogramar seus pods no segundo nó, que é removido.

Os orçamentos de interrupção de pods são um mecanismo para evitar essa situação. Você pode usá-los com Deployments, ReplicationControllers, ReplicaSets e StatefulSets.

Os itens direcionados por um orçamento de interrupção de Pod têm a garantia de ter um número específico de Pods acessíveis a qualquer momento. O Kubernetes bloqueará os drenos de nós que tornariam o número de pods disponíveis muito baixo.

Aqui está um exemplo de um PodDisruptionBudget Objeto YAML:

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: demo-pdb
spec:
  minAvailable: 4
  selector:
    matchLabels:
      app: my-app

Esta política exige que haja pelo menos quatro pods em execução com o app=my-app etiqueta. Drenos de nós que tornariam apenas três pods programáveis ​​serão evitados.

O nível de interrupção permitido é expresso como o maxUnavailable qualquer minAvailable campo. Apenas um deles pode existir em um único objeto de orçamento de interrupção de pod. Cada um aceita um número absoluto de Pods ou uma porcentagem relativa ao número total de Pods em plena disponibilidade:

• minAvailable: 4 – Exigir que pelo menos quatro Pods estejam disponíveis.
• maxUnavailable: 50% – Permitir que até metade do número total de Pods fique indisponível.

Substituir orçamentos de interrupção de pod

Os orçamentos de interrupção do pod são um mecanismo que fornece proteção para suas cargas de trabalho. Eles não devem ser abortados, a menos que você precise desligar imediatamente um aplicativo Node. a drain de comando --disable-eviction sinalizador fornece uma maneira de fazer isso.

$ kubectl drain node-1 --disable-eviction

Isso ignora o processo regular de despejo de pods. As cápsulas serão diretamente removido em vez disso, ignorando os orçamentos de interrupção aplicados.

recuperação de nó

Depois de concluir a manutenção, você pode ligar o nó novamente para reconectá-lo ao cluster. Então você precisa remover o cordão que você criou para marcar o Node como programável novamente:

$ kubectl uncordon node-1
node/node-1 uncordoned

O Kubernetes começará a atribuir novas cargas de trabalho ao Node, retornando-o ao serviço ativo.

Resumo

A manutenção de nós do Kubernetes não deve ser tentada até que você tenha esgotado as cargas de trabalho existentes e estabelecido um cordão. Essas medidas ajudam a evitar tempo de inatividade inesperado ao manter nós usados ​​ativamente.

Drenos básicos geralmente são apropriados se você tiver capacidade em seu cluster para reprogramar imediatamente suas cargas de trabalho para outros nós. Use orçamentos de interrupção de pod em situações em que a disponibilidade constante deve ser garantida. Eles permitem que você se proteja contra paralisações não intencionais quando vários drenos são iniciados ao mesmo tempo.