encerramento adequado de um cluster do kubernetes

Question

Imagine o seguinte cenário:

• Você executa um cluster do kubernetes no seu datacenter, que foi implantado com o kubeadm.
• Consiste em um masternode (executando o etcd como um pod estático, conforme implementado pelo kubeadm) e 3 nós de trabalho
• os nós como máquinas virtuais em execução no vmware

Hoje, você abre seu e-mail e é notificado de que o datacenter mudará para um novo local. Os servidores físicos serão desligados, movidos para o novo local e ligados novamente.

Qual é o procedimento de desligamento correto para o seu cluster do kubernetes (sem bagunçar seus dados do etcd)?

Isso foi o que eu fiz:

• parou o servidor master primeiro (isso inclui o etcd ofc), para evitar que os pods sejam reprogramados para outros nós quando eu desligar os nós do trabalhador.
• parou cada nó do trabalhador

Após a migração:

• ativado nos nós do trabalhador primeiro
• ligado no nó principal a seguir

Depois de fazer isso, acabei com um dos dois cenários:

• os dados do etcd estão corrompidos e o pod do etcd sai com um erro
• recebendo erros como este: "A operação não pode ser preenchida nos nós" worker-002 ": o objeto foi modificado; aplique as alterações à versão mais recente e tente novamente". meus logs estão sendo inundados com essas mensagens.

Como isso poderia ter sido evitado? Eu não acho que rodar o etcd no modo HA ajudaria aqui, já que todos os nós do etcd teriam que ser desligados de uma vez também, então você acaba com uma situação similar a um cenário de nó único. Tenho a impressão de que o Etcd é bastante ... frágil, comparado a outras lojas K / V como a Consul.

    

Answer 1

Você precisará parar no mestre

• kupe-apiserver
• agendador de kube
• controlador de kube
• kubelet (se aplicável)
• kube-proxy (se aplicável)

Se você tiver federação, também pare de federation-apiserver

Execute um backup (snapshot) do etcd e pare o etcd quando terminar

Para cada parada de nó

• kubelet
• kube-proxy

Etcd é tão robusto quanto consul, o que você quer dizer com instable ?!

Quando você restaurar os dados do etcd, isso não é válido imediatamente ... você deve ler em backups no kubernetes

    

Answer 2

Na verdade, o etcd é bastante resiliente com sua abordagem baseada em diário, mas, como sempre, você deve ter um backup feito antes da migração / encerramento, apenas para estar em um lado seguro. Se houver algum problema com o etcd, basta recuperar o backup e pronto.

Como você vai reiniciar todo o seu cluster, a ordem que você faz não é realmente tão importante, todos os containers terão que começar de novo de qualquer maneira, o que significa que o kubelet terá que se conectar a uma API.

De onde você tirou essa impressão instável do etcd, não faço ideia.