Skip to main content

Cluster Update Process

Sabemos que o Kubernetes é um emaranhado de projetos. Vamos focar só nesses por agora.

Alt text

Não é obrigatório que todos os componentes estejam na mesma versão, mas como todo mundo se comunica com o kube-apiserver, ninguém pode estar em uma versão acima dele.

Temos a exceção do kubectl podendo estar com 1 a mais até um a menos para dar comandos no cluster. A regra para essa distorção é o seguinte considerando o minor.

Alt text

Isso nos permite fazer o update de componentes por componente separadamente.

Agora vamos às recomendações para um upgrade do cluster levando em consideração a regra que temos acima. Não podemos ter uma distorção maior que 2 entre kube-apiserver e kubelet e kube-proxy.

Vamos imaginar que estamos na versão 1.10 e foi lançado a versão 1.11 e 1.12. Seria ok fazer o upgrade dos componentes do master com essa diferença de 2 para os nodes workers que contém o kubelet e o kube-proxy.

Alt text

Se a versão 1.13 fosse lançada não seria mais possível. A melhor hora para fazer o upgrade de um cluster é antes da próxima versão não suportável.

Para não ficar fazendo upgrade toda hora, é interessante esperar essa diferença de 2, mas nunca de 3.

O ideal e recomendável é que se faça o upgrade 1 por 1.

Alt text

O processo de upgrade depende muito de como o cluster foi construído.

  • Em clouds, geralmente com poucos cliques podemos fazer o upgrade de um cluster inteiro, pois eles nos dão essa facilidade.

  • Se foi construído um cluster usando o kubeadm podemos utilizar o próprio kubeadm para fazer o upgrade.

  • Se o cluster foi construído do zero precisa ser feito manualmente.

Alt text

Kubeadm Update

É necessário 2 etapas para atualizar um cluster.

  • Primeiro atualizar TODOS os masters

    • Enquanto os masters estão sofrendo atualizações não é possível criar, deletar e modificar nada no cluster, mas o que já existe funciona normalmente desde que os nodes não fiquem fora.
    • Se algo parar, por exemplo um pod morrer, ele não será recriado pois os controllers estão sofrendo update.
    • Não é possível acessar o cluster usando o kubectl pois o kube-apiserver estará sofrendo update também.
    • Quando os nodes master voltarem tudo deve funcionar normalmente.
    • Lembrando que somente deve estar no máximo 2 versões acima do kubelet e do kube-proxy que rodam nos workers.
  • Segundo atualizar os nodes

    • Estratégia all in once (todos de uma vez)
      • Se for fazer o upgrade de todos os workers de uma vez, todas as aplicações do cluster ficarão inoperantes.
      • Quando os nodes estiverem prontos novas aplicações serão scheduladas para os nodes e tudo deverá voltar a funcionar normalmente.
    • Estratégia one node as time a time (Um por vez)
      • Usamos a estratégia de drenar os um nó por vez e fazer o update deste nó.
    • Adicionar novos nodes com versões mais recentes
      • Esse caso é um dos melhores cenários principalmente se estiver com o cluster em uma cloud ao invés de um ambiente on premisse.
      • Uma vez adicionado novos nodes, podemos ir eliminando os nodes antigos já que os pods serão automaticamente relocados para os novos nodes (com recurso disponível).
      • Boa hora para atualização do sistema operacional.

Um detalhe muito importante; a versão mostrada abaixo é a versão do Kubelet dentro de cada um dos nodes.

Dependendo do tipo de instalação, caso o Kubelet não esteja disponível no master, ele nem apareceria aqui. Ou seja, o comando get nodes somente trás os nodes com o Kubelet instalado.

kubectl get nodes
NAME STATUS ROLES AGE VERSION
k3d-k3s-default-agent-1 Ready <none> 2d13h v1.27.4+k3s1
k3d-k3s-default-agent-0 Ready <none> 2d13h v1.27.4+k3s1
k3d-k3s-default-server-0 Ready control-plane,master 2d13h v1.27.4+k3s1

O comando kubeadm não atualiza o Kubelet

No node master você pode rodar o comando para ver quais os possíveis upgrade. Mesmo que seja possível fazer dois upgrades pra frente você deve fazer um de cada vez.

O kubeadm mantém as versões iguais dos componentes do Kubernetes então faça o upgrade dele para a versão que irá instalar.

Sempre é bom seguir a documentação https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/

Mas aqui vai um breve resumo.

Só de observar isso podemos ver que é sempre bom ir de um em um no minor.

Atualize o repositório para a versão que deseja faze o update.

Alt text

# Neste exemplo temos a versão 1.28, mas se fosse fazer para 1.29 edite o arquivo abaixo.
nano /etc/apt/sources.list.d/kubernetes.list
deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.28/deb/ /

sudo apt update
sudo apt-cache madison kubeadm
sudo apt-get install kubeadm

sudo apt-mark unhold kubeadm && \
sudo apt-get update && sudo apt-get install -y kubeadm='1.28.x-*' && \
sudo apt-mark hold kubeadm

kubeadm version
# Geralmente em masters não se tem pod rodando que é a boa pratica mas se tiver precisa drenar.
kubectl drain <node_name_master> --ignore-daemonsets

# Atualize o repo
apt-get update

# Geralmente os esses pacotes estão marcados para não serem atualizados
apt-mark unhold kubeadm
apt-get upgrade -y kubeadm=1.XX+1.0-00
#apt-get upgrade -y kubeadm=1.XX+1.0-00 --allow-downgrade
apt-mark hold kubeadm # Marca novamente
# O kubeadm também atualiza o kubectl, mas sempre é bom conferir

# Agora você pode executar novamente o plan para ver até onde voce pode ir com o novo kubeadm
kubeadm upgrade plan
# Agora com a versão do kubeadm correta
kubeadm upgrade apply v1.XX.Y

#Se for outros control planes ao invés do primeiro somente atualiza
kubeadm upgrade node

# Caso o master tenha o kubelet, é necessário atualizar também
apt-mark unhold kubelet
apt-get upgrade -y kubelet=1.XX+1.0-00 --allow-downgrades
apt-mark hold kubelet

systemctl daemon-reload
systemctl restart kubelet

# Se no caso teve que drenar
kubectl uncordon <node_name_master>

Agora cada um dos nodes workers workers nodes (um por um).

kubectl drain nodeX --ignore-daemonsets # Drenar os pods
cat /etc/*release* # irá mostrar para voce qual distro é (Se for diferente de ubuntu)

# Também precisa fazer o upgrade o kubeadm
apt-mark unhold kubeadm
apt-get upgrade -y kubeadm=1.XX+1.0-00
apt-mark hold kubeadm

sudo kubeadm upgrade node # Mas precisa chamar depois para atualizar com os masters

# Agora vamos fazer do kubectl e do kubelet
apt-mark unhold kubelet kubectl
apt-get upgrade -y kubelet=1.XX+1.0-00 kubectl=1.XX+1.0-00 # dentro do node atualize o kubelet
apt-mark hold kubelet kubectl

systemctl daemon-reload
systemctl restart kubelet # para reiniciar o serviço com o novo binário

kubectl uncordon nodeX # libera o node para schedule

Tudo isso deve ser feito novamente depois que fizermos um cluster from strath usando também o kubeadm.

É bom fazer os testes com mais de um master.