Práticas recomendadas para upgrades de clusters do Anthos no VMware

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

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 os clusters do Anthos no VMware versão 1.8 e posterior, é 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.

Os clusters do Anthos no VMware executam 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, use painéis personalizados no Cloud Operations Suite 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 dos clusters do Anthos no 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, se você fizer upgrade de um cluster de usuário com três nós em que cada nó tem 8 vCPUs e 32 GB ou mais de RAM, o procedimento de upgrade consumirá os recursos a seguir:

  • 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.

Diagnosticar problemas de cluster.

Para verificar a integridade de um cluster antes de um upgrade, execute gkectl diagnose 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.

O comando gkectl upgrade executa verificações de simulação e interrompe o processo de upgrade se essas verificações não forem bem-sucedidas. É melhor identificar e corrigir proativamente esses problemas em vez de depender das verificações de simulação, que existem para proteger os clusters de possíveis danos. Como o comando gkectl diagnose faz mais verificações do que as verificações regulares de simulação, recomendamos que você execute manualmente esse comando antes de um upgrade.

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.

Quando os clusters do Anthos no VMware versão 1.11 ou 1.12 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.

Fazer upgrade da sequência

Os upgrades no local desde a versão 1.7 precisam sempre seguir uma sequência de upgrade específica:

  1. Faça upgrade da estação de trabalho do administrador.

  2. Upgrade de clusters de usuário, um de cada vez.

    Se você decidir não fazer upgrade de todos os clusters de usuário, não será possível fazer upgrade do cluster de administrador. Se você fizer upgrade de todos os clusters de usuários, terá a opção de fazer upgrade do cluster de administrador.

  3. Faça upgrade do cluster de administrador como a última e opcional etapa.

Diferenças entre tipos de cluster

Há dois tipos diferentes de clusters:

  • Cluster de usuário
  • Cluster de administrador

Quando um cluster de usuário é criado, ele contém apenas nós de trabalho e nenhum nó de plano de controle. Os nós do plano de controle são adicionados ou criados no cluster de administrador para todos os clusters de usuário anexados. Essa abordagem permite que os clusters do Anthos no VMware lidem com os upgrades de maneira diferente e mais flexível, porque as cargas de trabalho do usuário e os nós do plano de controle são separados.

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

O procedimento de upgrade dos clusters do Anthos no VMware envolve um processo de drenagem de nós que remove todos os pods de um nó. O processo cria uma nova VM para cada worker drenado e a adiciona ao cluster. Em seguida, os workers 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 de recursos do cluster, os clusters do Anthos no VMware fazem upgrade de um nó de cada 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/A Afetado 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.

O upgrade do cluster de administrador não interrompe as cargas de trabalho do cluster de usuário. O cluster de administrador contém apenas nós do plano de controle do usuário, que não executam cargas de trabalho do usuário. Durante o upgrade, esses nós do plano de controle são drenados e, em seguida, atualizados.

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/A Não afetado Não afetado
PodDisruptionBudgets Afetado 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