Este documento descreve as práticas recomendadas e considerações para fazer upgrade do GDCV para Bare Metal. 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 Anthos Service Mesh, Config Sync, Policy Controller ou Config Controller, verifique a matriz de compatibilidade do GKE Enterprise e verifique as versões compatíveis com o GDCV para Bare Metal 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 cluster, utilize os painéis personalizados da seção "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 se há recursos gratuitos no vSphere antes de iniciar um upgrade de 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 diminuição de até
1,15 não respeita os orçamentos de interrupção de pods (PDBs). 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 e o Config Controller ou outros componentes do GKE Enterprise, verifique se a versão instalada é compatível com a nova versão do GDCV para Bare Metal. Para informações de compatibilidade da versão do componente do GKE Enterprise, consulte Suporte à 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 os recursos de Visualização nos clusters de produção. Não podemos garantir que os clusters que usam recursos de Visualização podem 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 do GKE em Bare Metal 1.9.0, é possível ativar ou desativar o SELinux
antes ou depois da criação do cluster ou dos upgrades do cluster. O SELinux é ativado por padrão no Red Hat Enterprise Linux (RHEL) e no CentOS. 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 GKE em Bare Metal é compatível com o SELinux apenas nos sistemas RHEL e CentOS.
Não altere a configuração de densidade de pods
O GKE em Bare Metal é compatível com a configuração de até 250 pods no máximo 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
- Fazer upgrade de clusters
- Saiba mais sobre o ciclo de vida e os estágios dos upgrades
- Resolver problemas de upgrade de cluster