Práticas recomendadas para upgrades de cluster do Google Distributed Cloud

Neste documento, descrevemos as práticas recomendadas e considerações para fazer upgrade do Google Distributed Cloud. Saiba como se preparar para upgrades de cluster e as práticas recomendadas a serem seguidas antes do upgrade. Essas práticas recomendadas ajudam a reduzir os riscos associados aos upgrades de cluster.

Se você tiver vários ambientes, comoteste, desenvolvimento e produção, recomendamos que você comece com o ambiente menos crítico, como teste e verifique a funcionalidade do upgrade. Depois de verificar se o upgrade foi concluído, passe para o próximo ambiente. Repita esse processo até fazer upgrade dos ambientes de produção. Essa abordagem permite que você se mova de um ponto crítico para o próximo e verifique se o upgrade e as cargas de trabalho são executados corretamente.

Lista de verificação do upgrade

Recomendamos que você siga todas as práticas recomendadas neste documento. Use a lista de verificação a seguir para monitorar seu progresso. Cada item da lista é vinculado a uma seção deste documento com mais informações:

Depois que essas verificações forem concluídas, você poderá iniciar o processo de upgrade. Monitore o progresso até que todos os clusters sejam atualizados.

Planejar o upgrade

As atualizações podem causar interrupções. Antes de iniciar o upgrade, planeje com cuidado para garantir que o ambiente e os aplicativos estejam prontos e preparados.

Estime o compromisso de tempo e planeje uma janela de manutenção

O tempo necessário para atualizar um cluster varia de acordo com o número de nós e a densidade da carga de trabalho executada neles. Para concluir um upgrade de cluster, use uma janela de manutenção com tempo suficiente.

Para calcular uma estimativa aproximada para o upgrade, use 10 minutes * the number of nodes para o upgrade de nó único simultâneo.

Por exemplo, se você tiver 50 nós em um cluster, o tempo total de upgrade será de cerca de 500 minutos: 10 minutes * 50 nodes = 500 minutes.

Verificar a compatibilidade de outros componentes do GKE Enterprise

Se o cluster executar componentes do GKE Enterprise, como o Anthos Service Mesh, o Config Sync, o Policy Controller ou o Config Controller, confira a versão do GKE Enterprise e o suporte ao upgrade e verifique as versões compatíveis com o Google Distributed Cloud antes e depois do upgrade.

A verificação de compatibilidade é baseada no cluster de administrador ou de usuário em que o Anthos Service Mesh, o Config Sync, o Policy Controller ou o Config Controller está implantado.

Verificar a utilização de recursos do cluster

Para garantir que os pods possam ser evacuados quando o nó for drenado e que haja recursos suficientes no cluster sendo atualizado para gerenciar o upgrade, verifique o uso atual de recursos do cluster. Para verificar o uso de recursos do seu cluster, use os painéis personalizados da observabilidade do Google Cloud.

É possível usar comandos como kubectl top nodes para ver o uso atual de recursos do cluster, mas os painéis podem fornecer uma visão mais detalhada dos recursos que estão sendo consumidos ao longo do tempo. Esses dados de uso de recursos podem ajudar a indicar quando um upgrade causaria a menor interrupção, como durante fins de semana ou à noite, dependendo da carga de trabalho em execução e dos casos de uso.

O tempo para o upgrade do cluster de administrador pode ser menos crítico do que o dos clusters de usuário, porque um upgrade de cluster de administrador geralmente não introduz a inatividade do aplicativo. No entanto, ainda é importante verificar os recursos disponíveis antes de iniciar um upgrade do cluster de administrador. Além disso, o upgrade do cluster de administrador pode sugerir algum risco e, portanto, é recomendado durante períodos de uso menos ativos quando o acesso de gerenciamento ao cluster é menos crítico.

Recursos do plano de controle do cluster de administrador

Todos os jobs e controladores de upgrade são executados nos nós do plano de controle do cluster de administrador. Verifique o consumo de recursos desses nós do plano de controle para ver os recursos de computação disponíveis. O processo de upgrade geralmente requer 1.000 milicores de CPU (1.000 mCPU) e 2 a 3 GiB de RAM para cada conjunto de controladores de ciclo de vida. Observe que a unidade de CPU "mCPU" significa "milionário de um núcleo". Portanto, 1.000 milicores é equivalente a um núcleo em cada nó para cada conjunto de controladores de ciclo de vida. Para reduzir os recursos extras de computação necessários durante um upgrade, tente manter os clusters de usuário na mesma versão.

No exemplo de implantação a seguir, os dois clusters de usuário estão em versões diferentes do cluster de administrador:

Cluster de administrador Cluster de usuário 1 Cluster de usuário 2
1.13.3 1.13.0 1.13.2

Um conjunto de controladores de ciclo de vida é implantado no controlador de administrador para cada versão em uso. Neste exemplo, há três conjuntos de controladores de ciclo de vida: 1.13.3, 1.13.0 e 1.13.2. Cada conjunto de controladores de ciclo de vida consome um total de 1.000 mCPU e 3 GiB de RAM. O consumo total atual de recursos desses controladores de ciclo de vida é de 3.000 mCPU e 9 GiB de RAM.

Se o cluster de usuário 2 for atualizado para 1.13.3, agora haverá dois conjuntos de controladores de ciclo de vida: 1.13.3 e 1.13.0:

Cluster de administrador Cluster de usuário 1 Cluster de usuário 2
1.13.3 1.13.0 1.13.3

Agora, os controladores do ciclo de vida consomem um total de 2.000 mCPU e 6 GiB de RAM.

Se o cluster de usuário 1 for atualizado para 1.13.3, a frota agora será executada na mesma versão: 1.13.3:

Cluster de administrador Cluster de usuário 1 Cluster de usuário 2
1.13.3 1.13.3 1.13.3

Agora, há apenas um conjunto de controladores de ciclo de vida, que consomem um total de 1.000 mCPU e 3 GiB de RAM.

No exemplo a seguir, todos os clusters de usuário são a mesma versão. Se o cluster de administrador for atualizado, apenas dois conjuntos de controladores de ciclo de vida serão usados, então o consumo de recursos de computação será reduzido:

Cluster de administrador Cluster de usuário 1 Cluster de usuário 2
1.14.0 1.13.3 1.13.3

Neste exemplo, os controladores de ciclo de vida consomem novamente um total de 2.000 mCPU e 6 GiB de RAM até que todos os clusters de usuário sejam atualizados para a mesma versão que o cluster de administrador.

Se os nós do plano de controle não tiverem recursos de computação extras durante o upgrade, você verá pods comoanthos-cluster-operator ecapi-controller-manager ,cap-controller-manager ou cap-kubeadm-bootstraper em umaPending estado. Para resolver esse problema, faça upgrade de alguns clusters de usuário para a mesma versão, consolidando as versões e reduzindo o número de controladores de ciclo de vida em uso. Se o upgrade já estiver travado, também é possível usar kubectl edit deployment para editar as implantações pendentes para diminuir as solicitações de CPU e RAM para que elas se ajustem ao plano de controle do cluster de administrador.

A tabela a seguir detalha os requisitos de recursos de computação para diferentes cenários de upgrade:

Cluster Recursos necessários do cluster de administrador
Upgrade do cluster de usuário Fazer upgrade para a mesma versão de outros clusters: N/A

Fazer upgrade para versões diferentes de outros clusters de administrador ou de usuário: 1.000 mCPU e 3 GiB de RAM

Os clusters de usuário em um cluster híbrido têm os mesmos requisitos de recursos.
Upgrade do cluster de administrador (com cluster de usuário) 1.000 mCPU e 3 GiB de RAM
Upgrade de cluster híbrido (sem cluster de usuário) 1.000 mCPU e sobrecarga de RAM de 3 GiB. Os recursos são retornados após o uso.
Independente Sobrecarga de RAM de 200 mCPU e 1 GiB. Os recursos são retornados após o uso.

Fazer backup de clusters

Antes de iniciar um upgrade, faça backup dos clusters usando o comando bmctl backup cluster.

Como o arquivo de backup contém informações confidenciais, armazene-o com segurança.

Verificar se os clusters estão configurados e funcionando corretamente

Para verificar a integridade de um cluster antes de um upgrade, execute bmctl check cluster no cluster. O comando executa verificações avançadas, como para identificar nós que não estão configurados corretamente ou que têm pods que estão em um estado travado.

Quando você executa o comando bmctl upgrade cluster para fazer upgrade dos clusters, algumas verificações de simulação são executadas. O processo de upgrade será interrompido se essas verificações não forem bem-sucedidas. É melhor identificar e corrigir proativamente esses problemas com o comando bmctl check cluster em vez de depender das verificações de simulação, que existem para proteger os clusters de possíveis danos.

Revisar implantações da carga de trabalho do usuário

Há duas áreas a serem consideradas para as cargas de trabalho do usuário: drenagem e compatibilidade de API.

Diminuição da carga de trabalho

A carga de trabalho do usuário em um nó é reduzida durante um upgrade. Se a carga de trabalho tiver uma réplica única ou se todas as réplicas estiverem no mesmo nó, a diminuição da carga de trabalho pode causar a interrupção dos serviços em execução no cluster. Execute as cargas de trabalho com várias réplicas. O número da réplica precisa estar acima do número de nós simultâneo.

Para evitar um upgrade travado, o processo de drenagem do upgrade para a versão 1.29 não respeita os orçamentos de interrupção de pods (PDBs, na sigla em inglês). As cargas de trabalho podem ser executadas em um estado degradado, e a menor réplica de exibição seria total replica number - concurrent upgrade number.

Compatibilidade de API

Para compatibilidade da API, verifique a compatibilidade da API da carga de trabalho com a versão secundária mais recente do Kubernetes ao fazer um upgrade da versão secundária. Se necessário, faça upgrade da carga de trabalho para uma versão compatível. Sempre que possível, a equipe de engenharia do GKE Enterprise fornece instruções para identificar cargas de trabalho que usam APIs incompatíveis, como APIs Kubernetes removidas.

Se você usa o Anthos Service Mesh, o Config Sync, o Policy Controller, o Config Controller ou outros componentes do GKE Enterprise, verifique se a versão instalada é compatível com a nova versão do Google Distributed Cloud. Para informações sobre a compatibilidade da versão do componente GKE Enterprise, consulte Suporte para versão e upgrade do GKE Enterprise.

Auditar o uso de webhooks

Verifique se o cluster tem webhooks, especialmente recursos de pod para fins de auditoria, como o Policy Controller. O processo de drenagem durante o upgrade do cluster pode interromper o serviço webhook do Policy Controller, o que pode fazer com que o upgrade seja travado ou leve muito tempo. Recomendamos desativar esses webhooks temporariamente ou usar uma implantação de alta disponibilidade (HA, na sigla em inglês).

Revisar o uso dos recursos de visualização

Os recursos de Visualização estão sujeitos a alterações e são fornecidos apenas para fins de teste e avaliação. Não use recursos de pré-lançamento nos clusters de produção. Não garantimos que os clusters que usam recursos em fase de pré-lançamento possam ser atualizados. Em alguns casos, bloqueamos explicitamente os upgrades de clusters que usam recursos da Visualização.

Para informações sobre alterações interruptivas relacionadas a upgrade, consulte as notas da versão.

Verificar o status do SELinux

Se você quiser ativar o SELinux para proteger seus contêineres, verifique se o SELinux está ativado no modo Enforced em todas as máquinas host. A partir da versão 1.9.0 ou mais recente do Google Distributed Cloud, é possível ativar ou desativar o SELinux antes ou depois da criação ou dos upgrades do cluster. O SELinux é ativado por padrão no Red Hat Enterprise Linux (RHEL). Se o SELinux estiver desativado em suas máquinas host ou se você não tiver certeza, consulte Como proteger seus contêineres usando o SELinux para instruções sobre como ativá-lo.

O Google Distributed Cloud oferece suporte ao SELinux apenas em sistemas RHEL.

Não altere a configuração de densidade de pods

O Google Distributed Cloud oferece suporte à configuração de até 250 pods por nó com nodeConfig.PodDensity.MaxPodsPerNode. É possível configurar a densidade do pod apenas durante a criação do cluster. Não é possível atualizar as configurações de densidade de pods para clusters. Não tente alterar a configuração da densidade de pods durante um upgrade.

Verificar se os nós do plano de controle e do balanceador de carga não estão no modo de manutenção

Verifique se os nós do plano de controle e do balanceador de carga não estão em manutenção antes de iniciar um upgrade. Se qualquer nó estiver no modo de manutenção, o upgrade será pausado para garantir que o plano de controle e os pools de nós do balanceador de carga estejam disponíveis o suficiente.

A seguir