Práticas recomendadas para upgrades de cluster do GKE no VMware

Neste documento, descrevemos as práticas recomendadas e considerações para fazer upgrade do GKE no VMware. 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

Para tornar o processo de upgrade o mais simples possível, revise e conclua as verificações a seguir antes de começar a fazer upgrade dos clusters:

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

Por padrão, todos os pools de nós são atualizados em paralelo, mas, em cada pool, os nós são atualizados sequencialmente. Portanto, o tempo total do upgrade depende do número de nós no maior pool de nós. Para calcular uma estimativa aproximada do tempo de upgrade, use 15 minutos * o número de nós no maior pool de nós. Por exemplo, se você tiver 10 nós no maior pool, o tempo total do upgrade será de cerca de 150 minutos.

Na versão 1.28 e mais recentes, é possível acelerar um upgrade definindo o valor de maxSurge para pools de nós individuais.

Fazer backup do cluster de usuário e administrador

Antes de iniciar um upgrade, faça backup dos clusters de usuário e de administrador.

Um backup de cluster de usuário é um snapshot do armazenamento etcd do cluster de usuário. O armazenamento etcd contém todos os objetos do Kubernetes e objetos personalizados necessários para gerenciar o estado do cluster. O snapshot contém os dados necessários para recriar os componentes e as cargas de trabalho do cluster. Para mais informações, veja como fazer backup de um cluster de usuário.

A partir da versão 1.8 do GKE no VMware, é possível configurar o backup automático com clusterBackup.datastore no arquivo de configuração do cluster de administrador. Para ativar esse recurso em um cluster existente, edite o arquivo de configuração do cluster de administrador e adicione o campo clusterBackup.datastore. Em seguida, execute gkectl update admin.

Depois que clusterBackup.datastore for ativado, o cluster de administrador será salvo automaticamente em etcd no repositório de dados configurado do vSphere. Esse processo de backup será repetido sempre que houver uma alteração no cluster de administrador. Quando você inicia um upgrade de cluster, uma tarefa de backup é executada antes do upgrade do cluster.

Se você tiver problemas, consulte Fazer backup e restaurar um cluster de administrador com gkectl para restaurar um cluster de administrador usando o backup.

Revise o uso de PodDisruptionBudgets

No Kubernetes, os PDBs PodDisruptionBudgets podem ajudar a evitar inatividade ou interrupções indesejadas do aplicativo. Os PDBs instruem o programador a sempre manter vários pods em execução, enquanto outros pods podem falhar. Esse comportamento é uma maneira útil de informar a disponibilidade do aplicativo.

  1. Para verificar quais PDBs estão configurados no cluster, use o comando kubectl get pdb:

    kubectl get pdb -A --kubeconfig KUBECONFIG

    Substitua KUBECONFIG pelo nome do seu arquivo kubeconfig.

    O exemplo de saída a seguir mostra PDBs chamados istio-ingress, istiod e kube-dns:

    NAMESPACE     NAME            MIN AVAILABLE   MAX UNAVAILABLE   ALLOWED DISRUPTIONS   AGE
gke-system    istio-ingress   1               N/A               1                     16d
gke-system    istiod          1               N/A               1                     16d
kube-system   kube-dns        1               N/A               1                     16d

Na tabela anterior, cada PDB especifica que pelo menos um pod precisa estar sempre disponível. Essa disponibilidade se torna crítica durante os upgrades quando os nós são drenados.

Verifique se há PDBs que não podem ser atendidos. Por exemplo, é possível definir uma disponibilidade mínima de 1, quando a implantação apresentar apenas uma réplica. Neste exemplo, a operação de drenagem foi interrompida porque o PDB não pode ser atendido pelo controlador de recursos.

Para garantir que os PDBs não interfiram no procedimento de upgrade, verifique todos os PDBs em um determinado cluster antes de iniciar o upgrade. Talvez seja necessário coordenar com as equipes de desenvolvimento e proprietários do aplicativo para alterar ou desativar temporariamente os PDBs durante um upgrade de cluster.

O GKE no VMware executa uma verificação de simulação durante o processo de upgrade para avisar sobre PDBs. No entanto, você também precisa verificar manualmente os PDBs para garantir uma experiência de upgrade tranquila. Para saber mais sobre PDBs, consulte Como especificar um orçamento de interrupção para seu aplicativo.

Analise os endereços IP disponíveis

As seguintes considerações sobre endereços IP se aplicam durante os upgrades de cluster:

  • O processo de upgrade de clusters cria um novo nó e drena os recursos antes de excluir o nó antigo. Recomendamos que você sempre tenha endereços IP N+1 para o cluster de administrador ou de usuário, em que N é o número de nós no cluster.
  • Ao usar endereços IP estáticos, os endereços IP necessários precisam ser listados nos arquivos de blocos de IP.
  • Se você usa o DHCP, verifique se as novas VMs podem receber leases de IP adicionais na sub-rede desejada durante um upgrade.
    • Se você precisar adicionar endereços IP, atualize o arquivo de bloco de IP e execute o comando gkectl update. Para mais informações, consulte Planejar seus endereços IP.
  • Se você usa endereços IP estáticos e quer acelerar o processo de upgrade do cluster de usuários, liste endereços IP suficientes no arquivo de bloco de IP para que cada pool de nós possa ter um endereço IP extra disponível. Essa abordagem permite que o processo acelere o procedimento de adição e remoção de VMs, já que ele é executado a cada pool de nós.
    • Embora essa abordagem seja uma boa opção para acelerar os upgrades de clusters de usuário, considere a disponibilidade de recursos e desempenho do ambiente do vSphere antes de continuar.
  • Se houver apenas um IP reserva para todo o cluster de usuário, essa limitação atrasará o processo de upgrade para apenas uma VM por vez, mesmo quando vários pools de nós forem usados.

Verificar a utilização do cluster

Verifique se os pods podem ser evacuados quando o nó é drenado e se há recursos suficientes no cluster sendo atualizados para gerenciar o upgrade. Para verificar o uso atual de recursos do cluster, use painéis personalizados na seção de observabilidade do Google Cloud ou diretamente no cluster usando comandos como kubectl top nodes.

Os comandos que você executa no cluster mostram um snapshot do uso atual de recursos do cluster. 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.

Para mais informações, consulte quais serviços são afetados durante um upgrade de cluster.

Verificar o uso do vSphere

Verifique se há recursos suficientes na infraestrutura subjacente do vSphere. Para verificar o uso de recursos, selecione um cluster no vCenter e consulte a guia Resumo.

A guia de resumo mostra a memória geral, a CPU e o consumo de armazenamento de todo o cluster. Como os upgrades do GKE em VMware exigem outros recursos, também é necessário verificar se o cluster pode processar essas solicitações de recursos extras.

Como regra geral, o cluster do vSphere precisa oferecer suporte aos seguintes recursos extras:

  • Upgrade de +1 VM por cluster de administrador
  • +1 VM por pool de nós por upgrade de cluster de usuário

Por exemplo, suponha que um cluster de usuário tenha três pools de nós, cada um com nós que usam 8 vCPUs e 32 GB ou mais de RAM. Como o upgrade acontece em paralelo nos três pools de nós por padrão, o procedimento de upgrade consome os seguintes recursos extras para os outros três nós de sobretensão:

  • 24 vCPUs
  • 256 GB de RAM
  • Espaço em disco da VM + 256 GB de vSwap

O processo de upgrade cria VMs usando a operação de clone do vSphere. Clonar várias VMs de um modelo pode gerar estresse para o sistema de armazenamento substancial na forma de operações de E/S crescentes. O upgrade poderá ser muito lento se o subsistema de armazenamento subjacente não for capaz de fornecer desempenho suficiente durante um upgrade.

Embora o vSphere tenha sido projetado para uso simultâneo de recursos e tenha mecanismos para fornecer recursos, mesmo quando comprometido demais, recomendamos não comprimir a memória da VM. A alocação excessiva de memória pode levar a sérios impactos no desempenho que afetam todo o cluster, já que o vSphere fornece a "RAM ausente" ao trocar páginas para o armazenamento de dados. Esse comportamento pode causar problemas durante o upgrade de um cluster e causar impactos no desempenho de outras VMs em execução no cluster do vSphere.

Se os recursos disponíveis já forem escassos, desligue as VMs desnecessárias para ajudar a cumprir esses requisitos adicionais e evitar possíveis hits de desempenho.

Verificar a integridade e a configuração do cluster

Execute as seguintes ferramentas em todos os clusters antes do upgrade:

  • O comando gkectl diagnose: gkectl diagnose garante a integridade de todos os clusters. 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.

  • A ferramenta de pré-upgrade: além de verificar a integridade e a configuração do cluster, a ferramenta de pré-upgrade verifica possíveis problemas conhecidos que podem acontecer durante um upgrade do cluster.

Embora o comando gkectl upgrade execute verificações de simulação e interrompa o processo de upgrade se elas não forem bem-sucedidas, as verificações de simulação existem para proteger os clusters contra possíveis danos. Recomendamos que você use as ferramentas para identificar e corrigir problemas antes do upgrade, em vez de confiar nas verificações de simulação.

Se o comando gkectl diagnose mostrar um aviso Cluster unhealthy, corrija os problemas antes de tentar um upgrade.

Para saber mais, consulte Como diagnosticar problemas de cluster.

Usar implantações para minimizar a interrupção do aplicativo

Como os nós precisam ser drenados durante as atualizações, os upgrades de cluster podem causar interrupções do aplicativo. Drenar os nós significa que todos os pods em execução precisam ser encerrados e reiniciados nos nós restantes no cluster.

Se possível, os aplicativos devem usar implantações. Com essa abordagem, os aplicativos são projetados para lidar com interrupções. Qualquer impacto precisa ser mínimo nas implantações com várias réplicas. Ainda é possível fazer upgrade do cluster se os aplicativos não usarem implantações.

Também existem regras para que as implantações possam garantir que um número definido de réplicas continue em execução. Essas regras são conhecidas como PodDisruptionBudgets (PDBs). Os PDBs permitem limitar a interrupção a uma carga de trabalho quando os pods precisam ser reprogramados por algum motivo, como upgrades ou manutenção nos nós de cluster, e são importantes para verificar antes de um upgrade.

Usar um par de balanceador de carga de alta disponibilidade

Se você usar o Seesaw como balanceador de carga em um cluster, ele será atualizado automaticamente quando você fizer upgrade do cluster. Esse upgrade pode causar a interrupção do serviço. Para reduzir o impacto de um upgrade e de um erro de balanceador de carga, use um par de alta disponibilidade (par de alta disponibilidade). Nessa configuração, o sistema cria e configura duas VMs de balanceador de carga para que um failover para o outro peering possa acontecer.

Para aumentar a disponibilidade do serviço, ou seja, para o servidor da API Kubernetes, recomendamos que você sempre use um par de alta disponibilidade na frente do cluster de administrador. Para saber mais sobre o Seesaw e a configuração de alta disponibilidade dele, consulte Balanceamento de carga em pacote com o Seesaw.

Para evitar a interrupção do serviço durante um upgrade com um par de alta disponibilidade, o cluster inicia um failover antes de criar a nova VM do balanceador de carga. Se um cluster de usuário usar apenas uma única instância do balanceador de carga, haverá uma interrupção do serviço até que o upgrade seja concluído.

Recomendamos que você tenha um par de balanceador de carga de alta disponibilidade se o próprio cluster de usuário também estiver configurado para ser altamente disponível. Esta série de práticas recomendadas pressupõe que um cluster de usuário de alta disponibilidade use um par de balanceador de carga de alta disponibilidade.

Se as versões 1.11 ou 1.12 do GKE em VMware usam o MetalLB como um balanceador de carga em pacote, nenhuma configuração de pré-upgrade é necessária. O balanceador de carga é atualizado durante o processo de upgrade do cluster.

Decidir como fazer upgrade de cada cluster de usuário

Na versão 1.14 e mais recentes, é possível fazer upgrade de um cluster de usuário como um todo (ou seja, fazer upgrade do plano de controle e de todos os pools de nós no cluster) ou fazer upgrade do plano de controle do cluster de usuário e deixar os pools de nós na versão atual. Para informações sobre os motivos para fazer upgrade do plano de controle separadamente, consulte Upgrades de cluster de usuário.

Em um ambiente de vários clusters, acompanhe quais clusters de usuário foram atualizados e registre o número de versão deles. Se você decidir fazer upgrade do plano de controle e dos pools de nós separadamente, registre a versão do plano de controle e cada pool de nós em cada cluster.

Verificar as versões do cluster de usuário e administrador

gkectl

  • Para verificar a versão dos clusters de usuário:

    gkectl list clusters --kubeconfig ADMIN_CLUSTER_KUBECONFIG

    Substitua ADMIN_CLUSTER_KUBECONFIG pelo caminho do arquivo kubeconfig do cluster de administrador.

  • Para verificar a versão dos clusters de administrador:

    gkectl list admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG

CLI da gcloud

Para clusters registrados na API GKE On-Prem, é possível usar a CLI gcloud para acessar as versões de clusters de usuário, pools de nós no cluster de usuário e clusters de administrador.

  1. Verifique se você tem a versão mais recente da CLI gcloud. Atualize os componentes da CLI gcloud, se necessário:

    gcloud components update

  2. Execute os seguintes comandos para verificar as versões:

  • Para verificar a versão dos clusters de usuário:

    gcloud container vmware clusters list \
    --project=PROJECT_ID \
    --location=-

    Substitua PROJECT_ID pelo ID do projeto do seu projeto host da frota.

    Definir --location=- significa listar todos os clusters em todas as regiões. Se você precisar reduzir o escopo da lista, defina --location como a região especificada ao registrar o cluster.

    A saída do comando inclui a versão do cluster.

  • Para verificar a versão dos clusters de administrador:

    gcloud container vmware admin-clusters list \
    --project=PROJECT_ID \
    --location=-

Verifique a versão dos nós do cluster:

É possível usar kubectl para conseguir a versão dos nós do cluster, mas kubectl retorna a versão do Kubernetes. Para conseguir a versão correspondente do GKE no VMware para uma versão do Kubernetes, consulte Histórico de versões.

kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG

Substitua USER_CLUSTER_KUBECONFIG pelo caminho do arquivo kubeconfig do cluster de usuário.

Verificar se os certificados de CA precisam ser alternados

Durante um upgrade, os certificados de folha são alternados, mas os de CA não. É preciso fazer a rotação manual dos certificados de CA pelo menos uma vez a cada cinco anos. Para mais informações, consulte Rotacionar autoridades certificadoras de cluster de usuário e Rotacionar certificados de CA de cluster de administrador.

Diferenças entre tipos de cluster

Há dois tipos diferentes de clusters:

  • Cluster de usuário
  • Cluster de administrador

Dependendo de como você cria um cluster de usuário, ele pode conter nós de trabalho e nós do plano de controle (Controlplane V2) ou apenas nós de trabalho (kubeception). Com o kubeception, o plano de controle de um cluster de usuário é executado em um ou mais nós em um cluster de administrador. Em ambos os casos, na versão 1.14 e mais recentes, é possível fazer upgrade do plano de controle de um cluster de usuário separadamente dos pools de nós que executam suas cargas de trabalho.

Diferentes efeitos do cluster de usuário e das atualizações de cluster de administrador

O procedimento de upgrade do GKE no VMware envolve um processo de drenagem de nós que remove todos os pods de um nó. Uma nova VM é criada para cada nó de trabalho drenado e adicionada ao cluster. Os nós de trabalho drenados são removidos do inventário do VMware. Durante esse processo, qualquer carga de trabalho executada nesses nós é interrompida e reiniciada em outros nós disponíveis no cluster.

Dependendo da arquitetura escolhida da carga de trabalho, este procedimento pode ter impacto na disponibilidade de um aplicativo. Para evitar sobrecarga nos recursos do cluster, o GKE em VMware faz upgrade de um nó por vez.

Interrupção do cluster de usuário

A tabela a seguir descreve o impacto de um upgrade no cluster de usuário no local:

Função Cluster de administrador Cluster de usuário não de alta disponibilidade Cluster de usuário de alta disponibilidade
Acesso à API Kubernetes Não afetado Não afetado Não afetado
Cargas de trabalho de usuário Não afetado Não afetado Não afetado
PodDisruptionBudgets* Não afetado Não afetado Não afetado
Nó do plano de controle Não afetado Afetado Não afetado
Escalonamento automático de pods (VMware) Não afetado Não afetado Não afetado
Reparo automático Não afetado Não afetado Não afetado
Escalonamento automático de nós (VMware) Não afetado Não afetado Não afetado
Escalonamento automático de pod horizontal Afetado Afetado Não afetado
  • * : os PDBs podem causar falha ou interrupção do upgrade.
  • Afetado: uma interrupção do serviço durante o upgrade é perceptível até que ela seja concluída.
  • Não afetado: uma interrupção do serviço pode ocorrer durante um período muito curto, mas é quase imperceptível.

Os nós do plano de controle do cluster de usuário, sejam executados no cluster de administrador (kubeception) ou no próprio cluster de usuário (Controlplane V2), não executam cargas de trabalho do usuário. Durante um upgrade, esses nós do plano de controle são drenados e atualizados conforme necessário.

Em ambientes com planos de controle de alta disponibilidade (HA, na sigla em inglês), o upgrade do plano de controle de um cluster de usuário não interrompe as cargas de trabalho do usuário. Em um ambiente de alta disponibilidade, o upgrade de um cluster de administrador não interrompe as cargas de trabalho do usuário. Para clusters de usuário que usam o Controlplane V2, o upgrade apenas do plano de controle não interrompe as cargas de trabalho do usuário.

Durante um upgrade em um ambiente de plano de controle que não seja de alta disponibilidade, o plano de controle não pode controlar ações de escalonamento, recuperação ou implantação de pods. Durante a breve interrupção do plano de controle durante o upgrade, as cargas de trabalho do usuário poderão ser afetadas se estiverem em um estado de escalonamento, implantação ou recuperação. Isso significa que os lançamentos vão falhar durante um upgrade em um ambiente que não seja de alta disponibilidade.

Para melhorar a disponibilidade e reduzir as interrupções dos clusters de usuário de produção durante os upgrades, recomendamos que você use três nós do plano de controle (modo de alta disponibilidade).

Interrupção do cluster de administrador

A tabela a seguir descreve o impacto de um upgrade no cluster de administrador local:

Função Cluster de administrador Cluster de usuário não de alta disponibilidade Cluster de usuário de alta disponibilidade
Acesso à API Kubernetes Afetado Afetado Não afetado
Cargas de trabalho de usuário Não afetado Não afetado Não afetado
Nó do plano de controle Afetado Afetado Não afetado
Escalonador automático de pod Afetado Afetado Não afetado
Reparo automático Afetado Afetado Não afetado
Escalonamento automático de nós Afetado Afetado Não afetado
Escalonamento automático de pod horizontal Afetado Afetado Não afetado
  • Afetado: uma interrupção do serviço durante o upgrade é perceptível até que ela seja concluída.
  • Não afetado: uma interrupção do serviço pode ocorrer durante um período muito curto, mas é quase imperceptível.

A seguir