Preparar, instalar e atualizar o cluster

Preparação que evita repetir o bootstrap

Antes de init, prepara nomes e identidades únicos, resolução e conectividade entre os nós, recursos suficientes e acesso às imagens necessárias. Compara o espaço de endereços dos hosts, Pods e Services; redes sobrepostas criam ambiguidades que um objeto Ready não elimina.

O runtime precisa de fornecer CRI compatível. O socket configurado no kubelet tem de corresponder ao runtime em funcionamento; a existência de um serviço com nome containerd não prova que o plugin CRI esteja ativo. Lê os erros de preflight e os logs locais antes de alterar outro componente.

Estado do host e configuração efetiva

A configuração de swap deve corresponder à política suportada pelo kubelet: não confundas failSwapOn: false com autorização para os workloads usarem swap. Esta última depende também de swapBehavior e dos requisitos da versão. Kubelet e runtime precisam de uma visão consistente de cgroups.

Com KubeletCgroupDriverFromCRI ativo e um runtime que suporte RuntimeConfig, a deteção pelo CRI pode prevalecer sobre cgroupDriver no ficheiro. Portanto, compara versões e estado efetivo; editar uma chave sem saber quem a usa pode não alterar nada.

Mudar o driver num nó já utilizado exige uma estratégia de substituição ou manutenção que respeite os Pods existentes.

Init, rede de Pods e join

kubeadm init prepara o control plane e produz instruções de acesso e join. Guarda tokens e material de administração como credenciais, não como texto de um relatório público. Instala um plugin de rede compatível e a respetiva configuração; kubeadm não fornece sozinho toda a conectividade dos Pods.

A aceitação deve observar nós, componentes, resolução de nomes e tráfego a partir de um cliente representativo. No join, separa um timeout para o endpoint, uma rejeição de identidade/CA e um token expirado. Repetir init no worker não corrige essas fases.

Se existem vários sockets CRI, identifica o pretendido em vez de aceitar uma escolha ambígua.

Alta disponibilidade e dependências comuns

Um endpoint API estável deve corresponder ao controlPlaneEndpoint e encaminhar para control planes saudáveis. Três servidores atrás de um único balanceador sem recuperação mantêm uma dependência comum. Num desenho stacked, o membro etcd acompanha o control plane; num desenho com etcd externo, esse conjunto tem operação e falhas próprias.

O quórum precisa de uma maioria: três membros exigem dois disponíveis; distribuir Pods não altera essa conta. Planeia falhas de host, rede e zona, com recuperação dos dados de estado. Um backup presente não prova que o restauro funciona nem que as aplicações recuperam os seus próprios dados.

Atualizar sem violar a compatibilidade

Para passar de 1.35 para 1.37 com kubeadm, percorre 1.36 e depois 1.37, escolhendo patches e pré-requisitos suportados em cada etapa. upgrade plan identifica o caminho e verificações; upgrade apply atua no primeiro control plane e upgrade node nos seguintes, de acordo com a documentação da versão.

Atualizar kubeadm não atualiza automaticamente todos os pacotes kubelet/kubectl ou o CNI. Num conjunto misto de API servers 1.36 e 1.37, um kubelet 1.37 que comunica com ambos fica mais recente que um deles: conclui a etapa dos API servers antes dessa atualização.

O skew máximo entre componentes é um limite de compatibilidade, não uma autorização para saltar versões no procedimento kubeadm.

Decidir com uma sequência de observação

O bloco abaixo recolhe estado. kubeadm version indica a versão do binário local, não a versão de todos os componentes do cluster. Usa o contexto lab apenas se for o nome do teu ambiente autorizado. Compara condições e versões antes e depois de uma etapa, e recolhe o estado do cliente que precisa do serviço.

Um drain bloqueado por PDB é informação para a decisão: verifica réplicas saudáveis, capacidade e risco acordado, em vez de retirar a proteção para cumprir a hora. Para erros locais do kubelet/runtime, mantém observações por nó e correlaciona-as com o API server.

Regista a mudança exata e o critério de aceitação, sem copiar kubeconfigs ou tokens para as evidências partilhadas.

Armadilhas comuns

Repetir init perante qualquer falha; desativar verificações de CA; inferir quórum pela quantidade de Pods; confundir tolerar swap com usá-la; atualizar todos os componentes ao mesmo tempo sem verificar o skew.