O que acontece durante uma falha no plano de controle do Kubernetes?

O Kubernetes é o principal orquestrador para distribuição de instâncias de contêiner em vários nós físicos. Os nós são gerenciados pelo plano de controle do Kubernetes, uma coleção de componentes que mantêm o estado do cluster, respondem a mudanças nas condições e lidam com decisões de agendamento.

Compreender a função do plano de controle é fundamental ao operar clusters que precisam de disponibilidade constante. Neste artigo, você aprenderá o que acontece quando o plano de controle falha para que você possa planejar com antecedência e implementar proteções.

Entenda o plano de controle

O plano de controle do Kubernetes é responsável pelas operações gerais do seu cluster. Ele coordena ações que afetam seus nós de trabalho. O plano de controle também fornece armazenamento de dados etcd para o cluster, bem como o servidor de API com o qual você interage usando ferramentas como Kubectl.

Aqui estão algumas das principais responsabilidades do plano de controle:

• kube-apiserver hospeda o servidor da API Kubernetes.
• kube-controller-manager inicia e executa controladores em seu cluster, permitindo detectar e aplicar alterações de estado solicitadas pelo servidor de API.
• kube-scheduler atribui Pods a nós do trabalhador determinando qual nó está melhor equipado para dar suporte a cada novo Pod.
• etc. é um armazenamento de dados de valor-chave que contém todos os dados de cluster e informações de estado do Kubernetes.

A arquitetura do Kubernetes depende da disponibilidade contínua desses componentes. Eles trabalham juntos para criar o estado operacional normal em que tudo está funcionando sem problemas e seu cluster atende às expectativas.

O que acontece durante a falha do plano de controle?

O plano de controle não é imune a falhas. O grande número de componentes envolvidos significa que peças individuais podem parar de funcionar e causar efeitos indiretos em seu grupo. Um componente pode falhar ou o host físico que executa o plano de controle pode sofrer uma falha de hardware.

Os efeitos reais em seu cluster irão variar dependendo de qual componente está tendo o problema. No entanto, uma falha no plano de controle normalmente impede que você gerencie seu cluster e pode impedir que as cargas de trabalho existentes reajam a novos eventos:

• Se o servidor da API falhar, o Kubectl, o Kubernetes Dashboard e outras ferramentas de gerenciamento deixarão de funcionar.
• Se o agendador falhar, os novos pods não serão atribuídos aos nós, portanto, ficarão inacessíveis e serão exibidos como travados no estado Pendente. Isso também afetará os pods que precisam ser reprogramados porque um nó ficou sem recursos ou uma solicitação de dimensionamento foi enviada.
• Quando o Controller Manager falha, quaisquer alterações que você aplicar ao seu cluster não serão selecionadas, portanto, suas cargas de trabalho parecerão manter seu estado anterior.

As falhas do plano de controle impedem que você modifique efetivamente o estado do cluster. As alterações falharão completamente ou não terão efeito no cluster.

O que acontece com os nós do trabalhador e os pods em execução?

O plano de controle é uma camada de gerenciamento que fica no topo e se estende por seus nós do trabalhador e Pods. O plano de controle e os trabalhadores são independentes um do outro. Depois que um pod é agendado para um nó, esse nó se torna responsável por adquirir a imagem correta e executar uma instância de contêiner.

Isso significa que as falhas do plano de controle não necessariamente matarão as cargas de trabalho que já estão íntegras. Muitas vezes, você pode continuar acessando os pods existentes, mesmo quando não consegue se conectar ao cluster com o Kubectl. Os usuários não notarão necessariamente uma interrupção do plano de controle de curto prazo.

Períodos mais longos de tempo de inatividade aumentam a probabilidade de que os nós do trabalhador comecem a ter problemas também. Os nós não poderão reconciliar seu status, portanto, podem ocorrer inconsistências. A rede também pode começar a quebrar se o DNS estiver inativo e o conteúdo das solicitações em cache expirar.

Uma falha pode se tornar mais grave se um nó do trabalhador começar a apresentar problemas enquanto o plano de controle estiver inativo. Nessa situação, os pods no nó podem parar de ser executados, mas o restante do cluster não saberá o que está acontecendo. Será impossível reprogramar os pods para outro nó, pois os nós funcionam de forma independente na ausência do plano de controle. Isso fará com que sua carga de trabalho fique offline.

Evite a falha do plano de controle

Você pode se defender contra falhas do plano de controle configurando um cluster altamente disponível que replica as funções do plano de controle em várias máquinas. Assim como você usa o Kubernetes para distribuir e dimensionar seus próprios contêineres, você pode aplicar alta disponibilidade (HA) ao Kubernetes para aumentar a resiliência.

O Kubernetes oferece dois mecanismos para configurar uma implementação de plano de controle altamente disponível:

1. Uso de nós do plano de controle “empilhados”. – Esta abordagem requer menos infraestrutura e funciona com um mínimo de três máquinas. Cada máquina executará seu próprio plano de controle que replica os dados das outras. Um host assumirá a responsabilidade pelo cluster sendo designado como líder. Se o líder ficar offline, os outros nós notarão sua ausência e um novo líder será eleito. Idealmente, você precisa de um número ímpar de hosts, como 3, 5 ou 7, para otimizar o processo de eleição.
2. Usando um armazenamento de dados etcd externo. – Essa abordagem é semelhante ao modelo empilhado, mas com uma diferença fundamental. Ele se baseia em uma instância etcd externa que será compartilhada pelos nós do plano de controle. Isso pode evitar a replicação de dados desperdiçada. Você deve considerar configurar manualmente a replicação de cluster etcd para que ela não se torne um ponto de falha separado.

O Kubernetes agora tem um bom suporte para clusters com vários planos de controle. Se você gerencia seu próprio cluster, pode adicionar outro nó do plano de controle simplesmente incluindo o --control-plane marca quando você executa o kubeadm join domínio:

$ kubeadm join <cluster-control-plane-leader-ip>:6443 
    --token <cluster-join-token>
    --discovery-token-ca-cert-hash sha256:<cluster-discovery-token-ca-cert-hash>  
    --certificate-key <cluster-certificate-key> 
    --control-plane

Resumo

O plano de controle do Kubernetes é responsável por manter as operações no nível do cluster. Ele monitora seus nós do trabalhador, manipula solicitações de API e aplica ações dentro do cluster para atingir o estado desejado.

Quando o plano de controle ficar inativo, esses recursos não estarão disponíveis, mas você poderá continuar usando os pods existentes por um período limitado. O plano de controle é o que une os nós para formar um grupo; sem ele, os nós são forçados a operar independentemente, sem o conhecimento um do outro.

Como o plano de controle é um ponto único de falha centralizado, os clusters de missão crítica devem replicá-lo em vários nós mestres para maximizar a confiabilidade. Os clusters multimestres distribuem funções de gerenciamento de cluster semelhantes a como os nós do trabalhador tornam seus contêineres altamente disponíveis. Embora possam ser mais complicados de configurar, a redundância adicional vale a pena. Um plano de controle altamente disponível também é oferecido como um recurso das ofertas de Kubernetes gerenciadas de muitos provedores de nuvem.