Este documento descreve as práticas recomendadas e as considerações para atualizar o Google Distributed Cloud. Aprende a preparar-se para as atualizações de clusters e as práticas recomendadas a seguir antes da atualização. Estas práticas recomendadas ajudam a reduzir os riscos associados às atualizações de clusters.
Se tiver vários ambientes, como teste, desenvolvimento e produção, recomendamos que comece pelo ambiente menos crítico, como teste, e verifique a funcionalidade de atualização. Depois de confirmar que a atualização foi bem-sucedida, avance para o ambiente seguinte. Repita este processo até atualizar os seus ambientes de produção. Esta abordagem permite-lhe passar de um ponto crítico para o seguinte e verificar se a atualização e as suas cargas de trabalho são executadas corretamente.
Lista de verificação da atualização
Recomendamos que siga todas as práticas recomendadas neste documento. Use a seguinte lista de verificação para ajudar a acompanhar o seu progresso. Cada item na lista remete para uma secção neste documento com mais informações:
Após a conclusão destas verificações, pode iniciar o processo de atualização. Monitorize o progresso até que todos os clusters sejam atualizados com êxito.
Planeie a atualização
As atualizações podem ser disruptivas. Antes de iniciar a atualização, planeie cuidadosamente para se certificar de que o seu ambiente e aplicações estão prontos e preparados.
Estime o tempo necessário e planeie um período de manutenção
O tempo necessário para atualizar um cluster varia consoante o número de nós e a densidade da carga de trabalho que é executada neles. Para concluir com êxito uma atualização do cluster, use um período de manutenção com tempo suficiente.
Para calcular uma estimativa aproximada da atualização, use 10 minutes * the number of
nodes para a atualização de um único nó em simultâneo.
Por exemplo, se tiver cinquenta nós num cluster, o tempo total de atualização seria de cerca de quinhentos minutos: 10 minutes * 50 nodes = 500 minutes.
Verifique a compatibilidade de outros Google Cloud produtos
Se o seu cluster executar o Cloud Service Mesh, o Config Sync ou o Policy Controller, verifique o apoio técnico de versões e atualizações e valide as versões suportadas com o Google Distributed Cloud antes e depois da atualização.
A verificação de compatibilidade baseia-se no cluster de administrador ou de utilizador no qual o Cloud Service Mesh, o Config Sync ou o Policy Controller estão implementados.
Verifique a utilização de recursos do cluster
Para garantir que os pods podem ser evacuados quando o nó é esgotado e que existem recursos suficientes no cluster que está a ser atualizado para gerir a atualização, verifique a utilização atual de recursos do cluster. Para verificar a utilização de recursos do seu cluster, use os painéis de controlo personalizados no Google Cloud Observability.
Pode usar comandos, como kubectl top nodes, para obter a utilização atual de recursos do cluster, mas os painéis de controlo podem fornecer uma vista mais detalhada dos recursos que estão a ser consumidos ao longo do tempo. Estes dados de utilização de recursos podem ajudar a indicar quando uma atualização causaria a menor interrupção, como durante os fins de semana ou à noite, consoante a carga de trabalho em execução e os exemplos de utilização.
A sincronização da atualização do cluster de administrador pode ser menos crítica do que para os clusters de utilizador, porque uma atualização do cluster de administrador normalmente não introduz tempo de inatividade da aplicação. No entanto, continua a ser importante verificar os recursos disponíveis antes de iniciar uma atualização do cluster de administrador. Além disso, a atualização do cluster de administrador pode implicar algum risco e, por isso, pode ser recomendada durante períodos de utilização menos ativos, quando o acesso de gestão ao cluster é menos crítico.
Recursos do plano de controlo do cluster de administrador
Todos os controladores e tarefas de atualização são executados nos nós do painel de controlo do cluster de administrador. Verifique o consumo de recursos destes nós do plano de controlo para ver os recursos de computação disponíveis. Normalmente, o processo de atualização requer 1000 milicores de CPU (1000 mCPU) e 2 a 3 GiB de RAM para cada conjunto de controladores do ciclo de vida. Tenha em atenção que a unidade de CPU "mCPU" significa "milésimo de um núcleo" e, por isso, 1000 milinúcleos equivalem a um núcleo em cada nó para cada conjunto de controladores do ciclo de vida. Para reduzir os recursos de computação adicionais necessários durante uma atualização, tente manter os clusters de utilizadores na mesma versão.
Na implementação de exemplo seguinte, os dois clusters de utilizadores estão em versões diferentes do cluster de administrador:
| Cluster de administrador | Cluster de utilizadores 1 | Cluster de utilizadores 2 |
|---|---|---|
| 1.13.3 | 1.13.0 | 1.13.2 |
É implementado um conjunto de controladores do ciclo de vida no controlador de administração para cada versão em utilização. Neste exemplo, existem três conjuntos de controladores do ciclo de vida:
1.13.3, 1.13.0 e 1.13.2. Cada conjunto de controladores do ciclo de vida consome um total de 1000 mCPU e 3 GiB de RAM. O consumo total de recursos atual destes controladores do ciclo de vida é de 3000 mCPU e 9 GiB de RAM.
Se o cluster de utilizadores 2 for atualizado para 1.13.3, existem agora dois conjuntos de controladores do ciclo de vida: 1.13.3 e 1.13.0:
| Cluster de administrador | Cluster de utilizadores 1 | Cluster de utilizadores 2 |
|---|---|---|
| 1.13.3 | 1.13.0 | 1.13.3 |
Os controladores do ciclo de vida consomem agora um total de 2000 mCPU e 6 GiB de RAM.
Se o cluster de utilizadores 1 for atualizado para 1.13.3, toda a frota passa a ser executada na mesma versão: 1.13.3:
| Cluster de administrador | Cluster de utilizadores 1 | Cluster de utilizadores 2 |
|---|---|---|
| 1.13.3 | 1.13.3 | 1.13.3 |
Agora, existe apenas um conjunto de controladores do ciclo de vida, que consomem um total de 1000 mCPU e 3 GiB de RAM.
No exemplo seguinte, todos os clusters de utilizadores são a mesma versão. Se o cluster de administrador for atualizado, são usados apenas dois conjuntos de controladores do ciclo de vida, pelo que o consumo de recursos de computação é reduzido:
| Cluster de administrador | Cluster de utilizadores 1 | Cluster de utilizadores 2 |
|---|---|---|
| 1.14.0 | 1.13.3 | 1.13.3 |
Neste exemplo, os controladores do ciclo de vida consomem novamente um total de 2000 mCPU e 6 GiB de RAM até que todos os clusters de utilizadores sejam atualizados para a mesma versão que o cluster de administrador.
Se os nós do plano de controlo não tiverem recursos de computação adicionais durante a atualização, pode ver pods como anthos-cluster-operator, capi-controller-manager, cap-controller-manager ou cap-kubeadm-bootstraper num estado Pending. Para resolver este problema, atualize
alguns dos clusters de utilizadores para a mesma versão para consolidar as versões e
reduzir o número de controladores do ciclo de vida em utilização. Se a atualização já estiver
bloqueada, também pode usar kubectl edit deployment para editar as implementações pendentes
de modo a reduzir os pedidos de CPU e RAM para que se enquadrem no plano de controlo
do cluster de administrador.
A tabela seguinte detalha os requisitos de recursos de computação para diferentes cenários de atualização:
| Cluster | Recursos do cluster de administrador necessários |
|---|---|
| Atualização do cluster de utilizadores | Atualização para a mesma versão de outros clusters: N/A Atualização para uma versão diferente de outros clusters de administrador ou de utilizador: 1000 mCPU e 3 GiB de RAM Os clusters de utilizadores num cluster híbrido têm os mesmos requisitos de recursos. |
| Atualização do cluster de administrador (com cluster de utilizador) | 1000 mCPU e 3 GiB de RAM |
| Atualização do cluster híbrido (sem cluster de utilizadores) | Aumento de 1000 mCPU e 3 GiB de RAM. Os recursos são devolvidos após a utilização. |
| Autónomo | Aumento de 200 mCPU e 1 GiB de RAM. Os recursos são devolvidos após a utilização. |
Faça uma cópia de segurança dos clusters
Antes de iniciar uma atualização,
faça uma cópia de segurança dos clusters com o comando bmctl backup cluster.
Uma vez que o ficheiro de cópia de segurança contém informações confidenciais, armazene-o em segurança.
Verifique se os clusters estão configurados e a funcionar corretamente
Para verificar o estado de um cluster antes de uma atualização, execute bmctl check cluster no cluster. O comando executa verificações avançadas, como identificar nós que não estão configurados corretamente ou que têm pods num estado bloqueado.
Quando executa o comando bmctl upgrade cluster para atualizar os clusters, são executadas algumas verificações
preflight. O processo de atualização é interrompido se estas verificações não forem
bem-sucedidas. É melhor identificar e corrigir proativamente estes problemas com o comando bmctl check cluster, em vez de confiar nas verificações de pré-publicação, que existem para proteger os clusters de possíveis danos.
Reveja as implementações de cargas de trabalho dos utilizadores
Existem duas áreas a considerar para as cargas de trabalho do utilizador: drenagem e compatibilidade da API.
Consumo da carga de trabalho
A carga de trabalho do utilizador num nó é esgotada durante uma atualização. Se a carga de trabalho tiver uma única réplica ou todas as réplicas estiverem no mesmo nó, a drenagem da carga de trabalho pode causar interrupções nos serviços em execução no cluster. Execute as suas cargas de trabalho com várias réplicas. O número de réplicas deve ser superior ao número de nós concorrentes.
Para evitar uma atualização bloqueada, o processo de esgotamento da atualização até à versão 1.33 não respeita os orçamentos de interrupção de pods (PDBs). As cargas de trabalho podem ser executadas num estado degradado e a réplica de publicação mínima seria total
replica number - concurrent upgrade number.
Compatibilidade da API
Para a compatibilidade da API, verifique a compatibilidade da API da carga de trabalho com a versão secundária mais recente do Kubernetes quando fizer uma atualização da versão secundária. Se necessário, atualize a carga de trabalho para uma versão compatível. Sempre que possível, a equipa de engenharia do GKE fornece instruções para identificar cargas de trabalho que usam APIs incompatíveis, como APIs Kubernetes removidas.
Se usar o Cloud Service Mesh, o Config Sync ou o Policy Controller, verifique se a versão instalada é compatível com a nova versão do Google Distributed Cloud. Para informações sobre a compatibilidade de versões, consulte o artigo Apoio técnico de versões e atualizações.
Audite a utilização de webhooks
Verifique se o seu cluster tem webhooks, especialmente recursos de pods para fins de auditoria, como o Policy Controller. O processo de esgotamento durante a atualização do cluster pode interromper o serviço webhook do Policy Controller, o que pode fazer com que a atualização fique bloqueada ou demore muito tempo. Recomendamos que desative temporariamente estes webhooks ou use uma implementação de alta disponibilidade (HA).
Reveja a utilização das funcionalidades de pré-visualização
As funcionalidades de pré-visualização estão sujeitas a alterações e são fornecidas apenas para fins de teste e avaliação. Não use funcionalidades de pré-visualização nos seus clusters de produção. Não garantimos que seja possível atualizar clusters que usam funcionalidades de pré-visualização. Em alguns casos, bloqueamos explicitamente as atualizações para clusters que usam funcionalidades de pré-visualização.
Para obter informações sobre alterações interruptivas relacionadas com a atualização, consulte as notas de lançamento.
Verifique o estado do SELinux
Se quiser ativar o SELinux para proteger os seus contentores, tem de se certificar de que o SELinux está ativado no modo Enforced em todas as suas máquinas anfitriãs. A partir da versão 1.9.0 ou posterior do Google Distributed Cloud, pode ativar ou desativar o SELinux antes ou depois da criação ou das atualizações do cluster. O SELinux está ativado por predefinição no Red Hat Enterprise Linux (RHEL). Se o SELinux estiver desativado nas suas máquinas anfitriãs ou não tiver a certeza, consulte o artigo Proteger os contentores com o SELinux para obter instruções sobre como o ativar.
O Google Distributed Cloud suporta o SELinux apenas em sistemas RHEL.
Não alterar a configuração de densidade do Pod
O Google Distributed Cloud suporta a configuração de um máximo de 250 pods por nó com nodeConfig.PodDensity.MaxPodsPerNode. Só pode configurar a densidade de pods durante a criação do cluster. Não é possível atualizar as definições de densidade de pods para clusters existentes. Não tente alterar a configuração de densidade do pod durante uma atualização.
Certifique-se de que os nós do plano de controlo e do equilibrador de carga não estão no modo de manutenção
Certifique-se de que os nós do painel de controlo e do equilibrador de carga não estão em manutenção antes de iniciar uma atualização. Se algum nó estiver no modo de manutenção, a atualização é pausada para garantir que o plano de controlo e os conjuntos de nós do balanceador de carga estão suficientemente disponíveis.
O que se segue?
- Atualize o Google Distributed Cloud
- Saiba mais acerca do ciclo de vida e das fases das atualizações
- Resolva problemas de atualização de clusters