Um cluster Kubernetes com um único control plane tem um problema óbvio: se esse nó cai, você perde a capacidade de gerenciar o cluster. As aplicações que já estão rodando continuam por um tempo, mas você fica cego e sem controle — não consegue fazer deploy, escalar ou reagir. Para produção séria, control plane único não é opção.

O que precisa ser redundante

Alta disponibilidade em Kubernetes se concentra em três peças do control plane:

• API Server: a porta de entrada de tudo. Precisa de múltiplas instâncias atrás de um balanceador.
• etcd: o banco que guarda todo o estado do cluster. É o coração — se o etcd corrompe ou perde quórum, o cluster inteiro sofre.
• Controllers e scheduler: rodam em modo líder-eleito; múltiplas instâncias, uma ativa por vez.

Duas topologias possíveis

Antes de configurar, escolha o desenho — e a escolha tem consequências de operação:

O modelo empilhado é o padrão razoável para a maior parte dos ambientes. Ele traz um acoplamento a considerar: perder um nó significa perder simultaneamente um API Server e um membro do etcd. Com três nós isso é perfeitamente tolerável — apenas reforça por que dois nunca é suficiente.

etcd: o quórum de novo

Se você leu sobre cluster Proxmox, o conceito volta aqui: o etcd é distribuído e depende de quórum. Por isso o padrão é número ímpar de membros — três ou cinco. Com três, você tolera a perda de um; com cinco, de dois. Número par não melhora a tolerância e ainda aumenta o risco de empate. E etcd é sensível a latência e disco: coloque-o em armazenamento rápido e rede de baixa latência, ou você terá instabilidade difícil de diagnosticar.

Vale ser específico sobre o disco, porque é a causa número um de cluster instável sem motivo aparente. O etcd confirma cada escrita de forma síncrona antes de responder; latência alta nessa confirmação se traduz em eleições de líder desnecessárias, timeouts no API Server e a sensação de que "o Kubernetes está lento". Disco mecânico ou SSD de consumo sem proteção de energia simplesmente não servem aqui. E se as VMs de control plane rodam sobre um storage compartilhado, confira a latência percebida dentro da VM, não a do array.

Três rotinas mantêm o etcd saudável ao longo dos anos:

• Backup periódico do estado, guardado fora do cluster, com restauração testada. Backup de etcd nunca restaurado é o item mais perigoso de qualquer plano de recuperação de Kubernetes.
• Acompanhamento do tamanho do banco, com compactação e desfragmentação na rotina. O etcd tem limite de tamanho e, ao atingi-lo, entra em modo somente leitura — o cluster para de aceitar mudanças.
• Monitoramento de latência de escrita e de trocas de líder, que são os primeiros sinais de degradação.

Balanceando o API Server

Múltiplos API Servers só ajudam se houver algo distribuindo as requisições entre eles. As abordagens comuns:

• HAProxy + Keepalived: um balanceador externo com IP virtual que migra entre nós.
• kube-vip: solução que provê o IP virtual do control plane dentro do próprio ecossistema, sem um balanceador externo dedicado.

O objetivo é o mesmo: um endereço estável para o control plane que continua respondendo mesmo com um nó fora.

Dois cuidados que fazem a diferença entre um balanceador que ajuda e um que engana: a verificação de saúde precisa consultar o endpoint de prontidão do API Server, não apenas testar se a porta abre — porta aberta com API degradado é o pior dos cenários. E o próprio balanceador não pode ser o novo ponto único de falha: se for externo, precisa de par redundante com IP virtual; se for uma solução distribuída no cluster, confirme o comportamento quando o nó que anuncia o endereço cai.

Certificados: a falha silenciosa mais comum

Cluster montado com as ferramentas padrão gera certificados internos com validade de aproximadamente um ano. Se nada for feito, no aniversário do cluster o API Server para de aceitar conexões e o diagnóstico costuma levar horas — porque nada mudou na infraestrutura, e ninguém suspeita de certificado.

Duas providências resolvem: uma rotina de renovação anual documentada, com alerta agendado meses antes do vencimento, e o hábito de atualizar o cluster dentro do ciclo suportado, o que renova os certificados no caminho. Coloque a data de expiração no monitoramento — é a checagem mais barata do seu cluster.

HA de control plane ≠ HA de aplicação

Um ponto que confunde muita gente: control plane redundante mantém o cluster gerenciável, mas a disponibilidade das suas aplicações depende de outras decisões — múltiplas réplicas dos pods, distribuídas entre nós (anti-affinity), PodDisruptionBudgets e um storage adequado para cargas com estado. Um control plane perfeito não salva uma aplicação que roda em réplica única.

Na camada da aplicação, quatro ajustes cobrem a maior parte do caminho:

• Réplicas suficientes para tolerar a perda de um nó sem perder capacidade crítica.
• Distribuição forçada entre nós e, quando houver, entre domínios de falha diferentes — nada de três réplicas no mesmo servidor físico.
• Orçamento de interrupção definido, para que manutenções e atualizações não derrubem todas as réplicas ao mesmo tempo.
• Sondas de prontidão e vivacidade corretas, para que o tráfego só chegue a instâncias realmente prontas. Sonda mal configurada causa mais indisponibilidade do que falha de hardware.

Os nós de trabalho também contam

Distribua os workloads por vários worker nodes e configure o Kubernetes para não concentrar réplicas no mesmo nó. Assim, a queda de um worker reduz capacidade, mas não derruba o serviço. Combine com autoscaling para repor capacidade automaticamente.

E mantenha folga real: um cluster com todos os nós próximos do limite não tem onde realocar os pods do nó que caiu. A mesma lógica de N+1 da virtualização vale aqui.

A camada de baixo importa: onde as VMs moram

Se o cluster Kubernetes roda sobre a sua própria virtualização, a redundância lógica pode ser desmentida pela física. Três control planes em VMs que vivem no mesmo servidor Proxmox formam um cluster que cai por completo quando aquele hardware falha.

O desenho correto distribui as VMs de control plane por hosts físicos diferentes, de preferência em circuitos elétricos e switches distintos, e usa regras que impeçam o orquestrador de virtualização de juntá-las novamente durante uma migração ou recuperação. É um ajuste barato que preserva o sentido de todo o resto.

Testar a falha, sempre

Como em qualquer arquitetura de HA: um cluster que nunca teve um nó derrubado de propósito é uma promessa não verificada. Em janela controlada, tire um control plane do ar e confirme que o IP virtual migra, que o API Server responde e que o etcd mantém quórum. Só então o "HA" é real.

Um roteiro de exercício que vale repetir a cada semestre:

1. Desligar um control plane sem aviso e cronometrar quanto tempo o cluster fica indisponível para operações de gestão.
2. Isolar a rede de um nó e observar o comportamento do quórum e do endereço virtual.
3. Derrubar um worker com carga de produção e confirmar que as réplicas se redistribuem.
4. Restaurar o etcd de um backup em ambiente isolado, cronometrando o processo do início ao fim.
5. Simular a expiração de certificado em laboratório, para que o procedimento de renovação já esteja praticado.

O item 4 é o mais desconfortável e o mais valioso: é o único que prova que você consegue reconstruir o cluster se o pior acontecer.

Erros comuns

• Dois control planes, na crença de que dois é melhor que um — em quórum, dois é pior.
• etcd em disco lento ou compartilhado com carga pesada.
• Balanceador único, sem redundância, na frente de três API Servers.
• Verificação de saúde que só testa se a porta responde.
• Nenhum backup de etcd, ou backup nunca restaurado.
• Certificados esquecidos até o dia em que expiram.
• VMs de control plane no mesmo host físico.
• Aplicações em réplica única em um cluster caro e redundante.

Onde a Solvefy/Cloud entra

Montamos clusters Kubernetes com control plane em HA (HAProxy/kube-vip), etcd saudável, distribuição de workloads e testes de falha reais. Como parte da consultoria DevOps, entregamos com documentação, runbooks e transferência de conhecimento, cobrada por hora com escopo definido. E, quando o cluster roda sobre Proxmox VE, cuidamos das duas camadas com o mesmo critério.

Seu cluster tem ponto único de falha? Diagnóstico gratuito, sem compromisso, em solvefy.cloud.

Solvefy/Cloud — Infraestrutura que cresce com você.