Atualizando um cluster do Kubernetes |

Atualizando um cluster do Kubernetes |

cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br


(Certifique-se de verificar o Plano de treinamento de ajuste de desempenho SQLpassion GRATUITO – você recebe um e-mail semanal com todo o conhecimento essencial que você precisa saber sobre ajuste de desempenho no SQL Server.)

Na postagem de hoje do blog, quero mostrar como você pode atualizar um cluster do Kubernetes implantado localmente para uma versão mais recente. Esta parece ser uma tarefa muito simples, mas existem algumas armadilhas das quais você deve estar ciente.

Visão geral

Em primeiro lugar, você precisa saber que só pode atualizar seu cluster do Kubernetes para uma versão secundária, que é uma versão superior à atual implantada. Imagine que você tem um cluster do Kubernetes com a versão v1.15 e deseja fazer upgrade para a versão v1.19. Nesse caso, você deve realizar várias atualizações – uma após a próxima:

  • v1.15 a v1.16
  • v1.16 a v1.17
  • v1.17 a v1.18
  • v1.18 a v1.19

Um cluster do Kubernetes contém o (s) nó (s) mestre (s), que executa os componentes do plano de controle e os nós de trabalho, que estão executando seus pods implantados. O Plano de Controle consiste nos seguintes componentes:

  • apitador de cubos
  • gerente de controle kube
  • programador kube
  • kube-proxy
  • kubelet

Em um nó de trabalho, o único componente implantado (além dos pods) é o kubelet. Ao atualizar agora seu cluster do Kubernetes, você pode atualizar esses componentes individualmente, para que não haja tempo de inatividade para seu aplicativo. Isso também significa que os componentes mencionados acima são implantados temporariamente com diferentes versões de software.

o apitador de cubos é o principal componente de um cluster do Kubernetes. Portanto, nenhum outro componente do Plano de Controle deve ter uma versão implantada superior ao apitador de cubos. o gerente de controle kube e a programador kube os componentes podem estar em uma versão inferior ao apitador de cubos.

Leia Também  # TSQL2sday: My Life Hack é uma ampulheta. Sim, uma ampulheta.

E a kube-proxy e a kubelet os componentes podem estar em duas versões inferiores ao apitador de cubos. Uma exceção é aqui o kubectl utilitário, que pode ser uma versão superior ou inferior ao apitador de cubos. A imagem a seguir tenta ilustrar esse conceito quando você faz uma atualização para a versão v1.18.

Nas etapas a seguir, mostrarei a você como fazer upgrade de um cluster do Kubernetes de v1.17 para v1.18.

Atualizando o nó mestre

Em primeiro lugar, estou começando com o nó mestre. Como não tenho uma implantação de HA, meu cluster do Kubernetes contém apenas um único nó mestre, como você pode ver na imagem a seguir.

Meu cluster Kubernetes

Cuidado: é muito importante que você mantenha e libere seus componentes do Kubernetes implantados com o comando apt-mark. Caso contrário, você terá sérios problemas ao atualizar o utilitário kubeadm na primeira etapa.

Quando você não possui a versão atual do kubelet, a atualização do beadm utilitário instala o *Mais recentes* versão do kubelet, que é v1.19.1. E como você já sabe, isso não funciona por causa da incompatibilidade de versão que mencionei anteriormente. Eu tive esse problema ontem, quando inicialmente atualizei meu cluster do Kubernetes de v1.16 para v1.17.

Problemas de incompatibilidade de versão

Como você pode ver na foto, o beadm utilitário foi atualizado para v1.17, e o kubelet também foi atualizado para v1.19.1! Após a atualização, o nó mestre estava no estado Não está pronto, porque o kubelet tinha uma versão implantada que era muito alta! Graças a Anthony E. Nocentino, que me ajudou a entender e solucionar esse problema específico! 🙂

Vamos começar agora atualizando o beadm utilitário na primeira etapa.

Leia Também  confiando em comportamento não documentado - SQLBlog

Na próxima etapa, podemos usar o plano de atualização do kubeadm comando que atualização podemos realizar:

Atualizar o plano de controle do cluster do Kubernetes

E agora realizamos a atualização dos componentes do Plano de Controle executando o comando kubeadm upgrade apply v1.18.0:

Atualizar o plano de controle do cluster do Kubernetes

Os componentes do plano de controle de nosso cluster Kubernetes agora foram atualizados com êxito para a versão v1.18.0:

Atualizar o plano de controle do cluster do Kubernetes

Mas quando você verifica a versão dos nós no cluster, ainda vê a versão antiga da v1.17.0:

O kubelet ainda está na versão v1.17

Isso faz sentido, porque a saída deste comando mostra a versão do kubelet componentes do cluster e ainda não foram atualizados. Então, vamos atualizar agora o kubelet componente no nó mestre.

Atualizar o kubelet no nó mestre

Ao verificar os números da versão dos nós do Kubernetes novamente, você pode ver que o nó mestre finalmente foi atualizado para a versão v1.18. Os nós de trabalho restantes ainda estão na versão v1.17.

O nó mestre foi finalmente atualizado

Vamos continuar agora com a atualização dos nós de trabalho.

Atualizando os nós de trabalho

Por padrão, todos os seus pods implantados em um cluster Kubernetes são programados e executados em nós de trabalho, porque o nó mestre tem um NoSchedule mancha aplicada durante a instalação inicial.

Ao fazer upgrade de um nó de trabalho, você também quer ter certeza de que nenhum pod está sendo executado naquele nó de trabalho e que o programador kube não coloca novos pods nesse nó de trabalho. Você pode cumprir os dois requisitos com o comando kubectl Drain. Ele despeja todos os pods desse nó de trabalho (eles são reprogramados nos nós de trabalho restantes) e também aplica o NoSchedule mancha nesse nó de trabalho.

Drenando o Nó de Trabalho

E então estamos atualizando o beadm utilidade e o kubelet componente diretamente no nó de trabalho:

Leia Também  Feliz Cinco de Mayo e feliz Taco terça-feira! - SQLBlog

Ao verificar a versão dos nós do Kubernetes novamente, você pode ver que o nó do trabalhador foi atualizado para a v1.18.

O Nó de trabalho também é atualizado

A única coisa que você precisa fazer é remover o NoSchedule contaminar executando o Kubectl Unordon comando:

O nó de trabalho agora pode agendar pods novamente

O primeiro Worker Node foi totalmente atualizado para a versão v1.18. Agora você deve aplicar as mesmas etapas de upgrade aos nós de trabalho restantes em seu cluster do Kubernetes. E, no final, você tem um cluster do Kubernetes totalmente atualizado da versão v1.18.

Todo o cluster do Kubernetes foi atualizado para v1.18

Quando você quiser fazer upgrade para a versão mais recente do Kubernetes v1.19, terá que fazer tudo novamente. Como eu disse no início desta postagem do blog, você só pode atualizar seu cluster do Kubernetes de uma versão secundária para a próxima …

Sunmary

Atualizar um cluster do Kubernetes não é tão difícil. O principal fato que você deve estar ciente é que você deve marcar os vários componentes do Kubernetes como aguarde com o apt-mark comando, porque de outra forma você está tendo sérios problemas de incompatibilidade de versão como você viu.

Espero que você tenha gostado desta postagem do blog e agora estou pegando um café até que meu cluster do Kubernetes seja finalmente atualizado para a v1.19 🙂

Obrigado pelo seu tempo,

-Klaus



cupom com desconto - o melhor site de cupom de desconto cupomcomdesconto.com.br