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

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 dentro de cada pool de nó os nós são atualizados sequencialmente. O tempo total de um upgrade depende do número de nós no maior pool de nós. Para calcular uma estimativa geral do tempo de upgrade, utilize 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 o tempo total de upgrade será de cerca de 150 minutos.

Na versão 1.28 e mais recentes, é possível acelerar um upgrade definindo o valor do 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.

Com o Google Distributed Cloud versão 1.8 e mais recentes, é 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.

Para restaurar um cluster de administrador do backup se tiver problemas, consulte Fazer backup e restaurar um cluster de administrador com gkectl.

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 Google Distributed Cloud executa uma verificação de simulação durante o processo de upgrade para alertar 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, é possível usar painéis personalizados do Google Cloud Observability ou diretamente no cluster com 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 Google Distributed Cloud demandam mais recursos, verifique também se o cluster pode lidar com essas solicitações adicionais de recursos.

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 que todos os clusters estejam íntegros. 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. 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.

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

Além disso, ao fazer upgrade de clusters de usuário para a versão 1.29 e mais recentes, recomendamos executar o comando gkectl upgrade cluster com a sinalização --dry-run. A sinalização --dry-run executa verificações de simulação, mas não inicia o processo de upgrade. Embora versões anteriores do Google Distributed Cloud Run executem verificações de simulação, elas não podem ser executadas separadamente do upgrade. Ao adicionar a sinalização --dry-run, é possível encontrar e corrigir problemas que as verificações de simulação encontram no cluster de usuário antes do upgrade.

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 utilize um par de balanceador de carga de alta disponibilidade.

Se você usar MetalLB como um balanceador de carga em pacote, nenhuma configuração pré-upgrade será 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, é possível fazer upgrade do plano de controle e de todos os pools de nós do cluster. Também é possível fazer upgrade do plano de controle do cluster de usuário e deixar os pools de nós na versão atual. Para saber por que fazer upgrade do plano de controle separadamente, consulte Upgrades de cluster de usuário.

Em um ambiente de vários clusters, monitore quais clusters de usuário foram atualizados e registre o número da versão. Se você decidir atualizar o os pools de nós e o plano de controle separadamente, registre a versão do plano de controle e de 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 para o cluster de administrador;

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

    gkectl list admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG

CLI da gcloud

Para clusters que estão registrados na API GKE On-Prem, é possível usar a gcloud CLI para acessar as versões dos 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. O ID do 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 acessar o serviço correspondente do Google Distributed Cloud para uma versão do Kubernetes, consulte Controle 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 alternar manualmente os certificados de CA pelo menos uma vez a cada cinco anos. Para mais informações, consulte Alternar autoridades certificadoras de cluster de usuário e Alternar certificados de CA de cluster de administrador.

Diferenças entre tipos de cluster

Há dois tipos diferentes de cluster:

  • Cluster de usuário
  • Cluster de administrador

Dependendo de como você cria um cluster de usuário, ele pode conter os 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 atualizar um plano de controle do 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 Google Distributed Cloud envolve um processo de drenagem de nós que remove todos os pods de um nó. O processo cria uma nova VM para cada nó de trabalho drenado e a adiciona ao cluster. Depois, 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 muita pressão nas atividades do recurso do cluster, o Google Distributed Cloud faz upgrade de um nó ao longo do tempo.

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 eles executados no cluster de administrador (kubeception) ou o próprio cluster de usuário (Controlplane V2), não execute nenhuma carga de trabalho de usuário. Durante um upgrade, esses nós do plano de controle são drenados e, em seguida, atualizados.

Em ambientes com planos de controle de alta disponibilidade (HA, na sigla em inglês), fazer upgrade do plano de controle de um cluster de usuário não causa a interrupção das cargas de trabalho do usuário. Em um ambiente de alta disponibilidade, o upgrade de um cluster de administrador não causa a interrupção das cargas de trabalho de usuário. Para clusters de usuários usando o Controlplane V2, o upgrade apenas do plano de controle não causa a interrupção das cargas de trabalho de usuário.

Durante um upgrade em um ambiente de plano de controle que não é de alta disponibilidade, o plano de controle não consegue 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 de usuário podem ser afetadas se estiverem em um estado de escalonamento, implantação ou recuperação. Isso significa que 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ê utilize 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
Oficina de automóveis 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