Melhores práticas do Kubernetes. Atualização de cluster de tempo de inatividade zero do Kubernetes

Melhores práticas do Kubernetes. Criando
práticas recomendadas para Kubernetes de contêineres pequenos. Organização Kubernetes com o namespace Kubernetes
Best Practices. Teste de viabilidade Kubernetes com testes de prontidão e vida
Práticas recomendadas de Kubernetes . Definindo consultas e limites de
recursos Melhores práticas do Kubernetes. Corrigir
encerrar desativando as práticas recomendadas de Kubernetes. Mapeando serviços externos

Todo mundo sabe como é bom manter seus aplicativos atualizados. O Kubernetes e o Docker podem facilitar muito o processo de atualização, para que você possa criar um novo contêiner com dependências atualizadas e implantá-lo facilmente. Além de atualizar as dependências do aplicativo, o Kubernetes está atualizando constantemente os recursos e as políticas de segurança.
Portanto, os nós de base e a infraestrutura do Kubernetes devem estar atualizados. Nesta série, aprenderemos como o Google Kubernetes Engine pode atualizar facilmente o cluster Kubernetes.

Portanto, ao atualizar um cluster, você precisa atualizar os assistentes e nós, e os assistentes devem ser atualizados primeiro. Vamos ver como atualizar os dois elementos usando o Google Kubernetes Engine. Este sistema atualiza automaticamente o assistente à medida que libera pontos. No entanto, como regra, ele não será atualizado para a nova versão, por exemplo, 1.7-1.8, automaticamente. Quando você estiver pronto para atualizar para a nova versão, basta clicar no link Atualizar disponível no console do GKE, após o qual uma caixa de diálogo aparecerá na tela. Ele contém um aviso de que a alteração da versão principal pode levar alguns minutos, durante os quais você não pode editar este cluster, enquanto durante a atualização do assistente, suas implantações e serviços continuarão funcionando normalmente. No entanto, toda a infraestrutura que precisa da API do Kubernetes não funcionará.



Isso significa que o QPTL e todos os aplicativos que usam a API Kubernetes para obter informações do cluster serão desativados e você não poderá fazer alterações no cluster.

Vamos ver como você pode resolver esse problema atualizando o assistente com zero tempo de inatividade.



Enquanto o cluster de zonas GKE padrão suporta apenas um assistente, você pode criar clusters regionais que fornecem assistentes de alta disponibilidade com várias zonas. Portanto, ao criar seu cluster, escolha uma opção regional.

Seus nós e assistentes serão criados automaticamente em três zonas e os assistentes terão endereços IP com balanceamento de carga. Isso manterá a API do Kubernetes funcionando sem problemas durante a atualização.

Ao atualizar nós, existem várias estratégias diferentes que você pode usar. Quero focar sua atenção em duas coisas - atualizações sem interrupção e migração usando pools de nós.

A maneira mais fácil de atualizar os nós do Kubernetes é usar a atualização sem interrupção, o mecanismo de atualização padrão que o GKE usa para atualizar seus nós. Funciona da seguinte maneira.



Os nós da versão antiga são desativados um após o outro para que todos os módulos deixem de funcionar neles. Em seguida, esses nós são excluídos e, em vez deles, novos nós da versão atualizada do Kubernetes aparecem um após o outro. Depois que um nó começa a funcionar, o outro continua com o processo de atualização, e isso continua até que todos os nós sejam atualizados. Você pode permitir que o GKE gerencie esse processo ativando a atualização automática de nós no pool de nós, selecionando Ativado.



Caso contrário, o painel do GKE avisará quando uma nova atualização estiver disponível. Nesse caso, para executar a atualização, você precisa clicar no link Atualizações automáticas do nó e seguir as instruções.



Ao mesmo tempo, é muito importante garantir que seus pods sejam controlados usando o conjunto de réplicas, um conjunto com estado ou algo semelhante. Em seguida, os lares autônomos não serão reestruturados.

Embora as atualizações contínuas sejam bastante fáceis de fazer com o GKE, ainda existem algumas desvantagens. Uma delas é que, quando você atualiza, a capacidade do seu cluster diminui em um nó. Essa desvantagem é facilmente eliminada escalando o conjunto de nós, adicionando capacidade adicional e reduzindo-o após a atualização.

Além disso, a natureza totalmente automatizada das atualizações contínuas facilita a atualização, mas deixa você com menos controle sobre o processo. Se algo der errado e você precisar reverter para a versão antiga, levará um tempo para interromper as atualizações e descartar as alterações que já foram feitas. Vamos ver como você pode usar conjuntos de vários nós para atualizar seu cluster.



Portanto, em vez de atualizar o pool ativo de nós usando atualizações contínuas, crie um pool de nós completamente novo, aguarde o início de todos os nós e transfira as cargas de trabalho um nó por vez. À medida que você executa esses comandos, você ganha mais controle sobre o processo de migração, enquanto o GKE continua a gerenciar seus nós.
Suponha que um cluster Kubernetes consista em 3 máquinas virtuais. Você pode visualizar os nós usando o comando get nodes.



Para criar um novo pool de nós chamado pool-two, você precisa usar o comando apropriado, configurando-o exatamente da mesma maneira que o comando para o pool antigo.



Opcionalmente, você também pode usar a GUI para criar um novo pool de nós. Para obter mais informações, use o link de criação do pool de nós localizado abaixo deste vídeo.

Se você verificar o número de nós novamente, encontrará três novos nós com o nome do conjunto dois - no entanto, os pods ainda estarão nos nós antigos.



Vamos movê-los para um novo pool de nós, movendo um nó de cada vez no modo contínuo. Para fazer isso, use o comando cordon para cada nó antigo para protegê-los e impedir a formação de novos lares neles.



Assim que todos os nós antigos forem protegidos, a criação de lares será planejada apenas em novos nós. Isso significa que você pode começar a remover os pods dos nós antigos, e o Kubernetes planejará automaticamente criá-los em novos nós. Então você precisa "drenar" cada nó, o que levará à remoção de todas as lareiras no nó.



Depois de fazer isso para um nó, verifique se os novos pods estão prontos e já estão funcionando e depois passe para o próximo nó. Se você teve algum problema durante a migração, execute uncordon para o pool antigo e execute cordon and drain para o novo pool. Nesse caso, os pods serão automaticamente transferidos de volta para o pool antigo. Depois que todos os pods tiverem sido transferidos com segurança, você poderá excluir o pool antigo. Para fazer isso, substitua o pool padrão pelo pool que você deseja excluir.



O Google Kubernetes Engine permite que você mantenha seu cluster Kubernetes atualizado com apenas alguns cliques. Eu recomendo o uso de clusters regionais do GKE para assistentes de alta disponibilidade e atualizações automáticas de nós para garantir atualizações corretas e sem problemas.

Se você precisar de controle adicional sobre o processo de atualização do nó, poderá fornecer a ajuda de pools, sem abrir mão das vantagens da plataforma de gerenciamento fornecida pelo GKE.

Se você não estiver usando o GKE, use o método de atualização sem interrupção ou os nós do conjunto de nós para atualizar os nós do seu cluster. Mas lembre-se de que, nesse caso, você precisa adicionar manualmente novos nós ao cluster e executar atualizações críticas por conta própria, o que pode não ser muito simples.

Para continuar em breve ...

Um pouco de publicidade :)

Obrigado por ficar com a gente. Você gosta dos nossos artigos? Deseja ver materiais mais interessantes? Ajude-nos fazendo um pedido ou recomendando aos seus amigos o VPS baseado em nuvem para desenvolvedores a partir de US $ 4,99 , um analógico exclusivo de servidores básicos que foi inventado por nós para você: Toda a verdade sobre o VPS (KVM) E5-2697 v3 (6 núcleos) 10 GB DDR4 480 GB SSD 1 Gbps de US $ 19 ou como dividir o servidor? (as opções estão disponíveis com RAID1 e RAID10, até 24 núcleos e até 40GB DDR4).

Dell R730xd 2 vezes mais barato no data center Equinix Tier IV em Amsterdã? Somente nós temos 2 TVs Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV a partir de US $ 199 na Holanda!Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - a partir de US $ 99! Leia sobre Como criar um prédio de infraestrutura. classe c usando servidores Dell R730xd E5-2650 v4 que custam 9.000 euros por um centavo?