Cluster Update Process
Sabemos que o Kubernetes é um emaranhado de projetos. Vamos focar só nesses por agora.
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.
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.
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.
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.
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.
- Estratégia all in once (todos de uma vez)
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.
# 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.