Práticas recomendadas para atualizações de clusters do Google Distributed Cloud

Este documento descreve as práticas recomendadas e as considerações para atualizar o Google Distributed Cloud. Aprende a preparar-se para as atualizações de clusters e as práticas recomendadas a seguir antes da atualização. Estas práticas recomendadas ajudam a reduzir os riscos associados às atualizações de clusters.

Se tiver vários ambientes, como teste, desenvolvimento e produção, recomendamos que comece pelo ambiente menos crítico, como teste, e verifique a funcionalidade de atualização. Depois de confirmar que a atualização foi bem-sucedida, avance para o ambiente seguinte. Repita este processo até atualizar os seus ambientes de produção. Esta abordagem permite-lhe passar de um ponto crítico para o seguinte e verificar se a atualização e as suas cargas de trabalho são executadas corretamente.

Lista de verificação da atualização

Para tornar o processo de atualização o mais simples possível, reveja e conclua as seguintes verificações antes de começar a atualizar os seus clusters:

Planeie a atualização

As atualizações podem ser disruptivas. Antes de iniciar a atualização, planeie cuidadosamente para se certificar de que o seu ambiente e aplicações estão prontos e preparados. Também pode ter de programar a atualização após o horário de funcionamento normal, quando o tráfego está no mínimo.

Estime o tempo necessário e planeie um período de manutenção

Por predefinição, todos os conjuntos de nós são atualizados em paralelo. No entanto, em cada conjunto de nós, os nós são atualizados sequencialmente porque cada nó tem de ser esvaziado e recriado. Assim, o tempo total de uma atualização depende do número de nós no node pool maior. Para calcular uma estimativa aproximada do tempo de atualização, multiplique 15 minutos pelo número de nós no maior conjunto de nós. Por exemplo, se tiver 10 nós no conjunto maior, o tempo total de atualização seria de cerca de 15 * 10 = 150 minutos ou 2,5 horas.

Seguem-se várias formas de reduzir o tempo de atualização e facilitar o planeamento e a agendamento de atualizações:

  • Na versão 1.28 e posteriores, pode acelerar uma atualização definindo o valor de maxSurge para pools de nós individuais. Quando atualiza as notas com maxSurge, vários nós são atualizados ao mesmo tempo que demora a atualizar um único nó.

  • Se os seus clusters estiverem na versão 1.16 ou superior, pode ignorar uma versão secundária ao atualizar os conjuntos de nós. A execução de uma atualização de versão ignorada reduz para metade o tempo necessário para atualizar sequencialmente os node pools duas versões. Além disso, as atualizações de versões ignoradas permitem-lhe aumentar o tempo entre as atualizações necessárias para permanecer numa versão suportada. Reduzir o número de atualizações reduz as interrupções da carga de trabalho e o tempo de validação. Para mais informações, consulte o artigo Ignore uma versão ao atualizar conjuntos de nós.

  • Pode atualizar o painel de controlo de um cluster de utilizadores separadamente dos node pools. Esta flexibilidade pode ajudar a planear várias janelas de manutenção mais curtas em vez de uma janela de manutenção longa para atualizar todo o cluster. Para ver detalhes, consulte o artigo Atualize pools de nós.

Faça uma cópia de segurança do cluster de utilizadores e administradores

Antes de iniciar uma atualização, faça uma cópia de segurança dos clusters de utilizadores e de administrador.

Uma cópia de segurança do cluster de utilizadores é uma imagem instantânea do armazenamento etcd do cluster de utilizadores. O etcd armazena todos os objetos Kubernetes e objetos personalizados necessários para gerir o estado do cluster. A imagem instantânea contém os dados necessários para recriar os componentes e as cargas de trabalho do cluster. Para mais informações, veja como fazer uma cópia de segurança de um cluster de utilizadores.

Com o Google Distributed Cloud versão 1.8 e posterior, pode configurar uma cópia de segurança automática com clusterBackup.datastore no ficheiro de configuração do cluster de administrador. Para ativar esta funcionalidade num cluster existente, edite o ficheiro de configuração do cluster de administrador e adicione o campo clusterBackup.datastore, e, em seguida, execute gkectl update admin.

Depois de ativar a opção clusterBackup.datastore, é feita automaticamente uma cópia de segurança do cluster de administrador em etcd no arquivo de dados do vSphere configurado. Este processo de cópia de segurança repete-se sempre que houver uma alteração ao cluster de administração. Quando inicia uma atualização do cluster, é executada uma tarefa de cópia de segurança antes de atualizar o cluster.

Para restaurar um cluster de administrador a partir da respetiva cópia de segurança se tiver problemas, consulte o artigo Faça uma cópia de segurança e restaure um cluster de administrador com gkectl.

Reveja a utilização do PodDisruptionBudgets

No Kubernetes, os PodDisruptionBudgets (PDBs) podem ajudar a evitar tempo de inatividade ou interrupções indesejáveis das aplicações. Os PDBs dão instruções ao programador para manter sempre um número de pods em execução, enquanto outros pods podem estar a falhar. Este comportamento é uma forma útil de garantir a disponibilidade da aplicação.

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

    kubectl get pdb -A --kubeconfig KUBECONFIG

    Substitua KUBECONFIG pelo nome do seu ficheiro kubeconfig.

    O exemplo de saída seguinte mostra PDBs com os nomes 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 tem de estar sempre disponível. Esta disponibilidade torna-se fundamental durante as atualizações quando os nós são esvaziados.

Verifique se existem PDBs que não podem ser cumpridos. Por exemplo, pode definir uma disponibilidade mínima de 1 quando a implementação tiver apenas 1 réplica. Neste exemplo, a operação de esgotamento é interrompida porque o PDB não pode ser satisfeito pelo controlador de recursos.

Para se certificar de que os PDBs não interferem com o procedimento de atualização, verifique todos os PDBs num determinado cluster antes de iniciar a atualização. Pode ter de coordenar com as equipas de desenvolvimento e os proprietários das aplicações para alterar ou desativar temporariamente os PDBs durante uma atualização do cluster.

O Google Distributed Cloud executa uma verificação prévia durante o processo de atualização para emitir um aviso sobre os PDBs. No entanto, também deve validar manualmente os PDBs para garantir uma experiência de atualização sem problemas. Para saber mais acerca dos PDBs, consulte o artigo Especificar um orçamento de interrupção para a sua aplicação.

Reveja os endereços IP disponíveis

As seguintes considerações sobre endereços IP aplicam-se às atualizações de clusters de utilizadores e clusters de administrador não de HA (ou seja, clusters de administrador que não estão altamente disponíveis):

  • O processo de atualização do cluster cria um novo nó e esgota os recursos antes de eliminar o nó antigo. Recomendamos que tenha sempre N+1 endereços IP para o cluster, onde N é o número de nós no cluster. Esta recomendação aplica-se apenas a clusters de administrador não de HA (que só têm um nó do plano de controlo) e clusters de utilizadores.

  • Quando usar endereços IP estáticos, os endereços IP necessários têm de estar listados nos ficheiros de blocos de IP.

    • Quando atualizar clusters de administrador não de HA, adicione o endereço IP adicional no ficheiro de bloqueio de IPs usado pelo cluster de administrador. O caminho para este ficheiro tem de ser especificado no campo network.ipMode.ipBlockFilePath do ficheiro de configuração do cluster de administrador.
    • Quando atualizar clusters de utilizadores, adicione o endereço IP adicional no ficheiro de bloqueio de IP usado pelo cluster de utilizadores. O caminho para este ficheiro tem de ser especificado no campo network.ipMode.ipBlockFilePath do ficheiro de configuração do cluster de utilizadores.

  • Se usar o DHCP, certifique-se de que as novas VMs podem obter concessões de IP adicionais na sub-rede aplicável durante uma atualização.

    Se precisar de adicionar endereços IP, atualize o ficheiro de bloqueio de IP e, em seguida, execute o comando gkectl update. Para mais informações, consulte o artigo Planeie os seus endereços IP.

  • Se usar endereços IP estáticos e quiser acelerar o processo de atualização do cluster de utilizadores, liste endereços IP suficientes no ficheiro de bloco de IP para que cada conjunto de nós possa ter um endereço IP adicional disponível. Esta abordagem permite que o processo acelere o procedimento de adição e remoção de VMs, uma vez que é realizado por pool de nós.

    Embora esta abordagem seja uma boa opção para acelerar as atualizações dos clusters de utilizadores, considere a disponibilidade de recursos e o desempenho do seu ambiente vSphere antes de continuar.

  • Se existir apenas um IP adicional para todo o cluster de utilizadores, esta limitação torna o processo de atualização mais lento, limitando-o a uma VM de cada vez, mesmo quando são usados vários conjuntos de nós.

Os clusters de administrador de HA não requerem endereços IP N+1 para atualizações. Os três nós do plano de controlo num cluster de administrador de HA são recriados um a um, o que garante que não são necessários endereços IP adicionais.

Verifique a utilização do cluster

Certifique-se de que os pods podem ser evacuados quando o nó é esvaziado e que existem recursos suficientes no cluster que está a ser atualizado para gerir a atualização. Para verificar a utilização atual de recursos do cluster, pode usar painéis de controlo personalizados no Google Cloud Observability ou diretamente no cluster através de comandos como kubectl top nodes.

Os comandos que executa no cluster mostram uma captura instantânea da utilização de recursos do cluster atual. Os painéis de controlo podem oferecer uma vista mais detalhada dos recursos que estão a ser consumidos ao longo do tempo. Estes dados de utilização de recursos podem ajudar a indicar quando uma atualização causaria a menor interrupção, como durante os fins de semana ou à noite, consoante a carga de trabalho em execução e os exemplos de utilização.

A sincronização da atualização do cluster de administrador pode ser menos crítica do que para os clusters de utilizador, porque uma atualização do cluster de administrador normalmente não introduz tempo de inatividade da aplicação. No entanto, continua a ser importante verificar se existem recursos gratuitos no vSphere antes de iniciar uma atualização do cluster de administrador. Além disso, a atualização do cluster de administrador pode implicar algum risco e, por isso, pode ser recomendada durante períodos de utilização menos ativos, quando o acesso de gestão ao cluster é menos crítico.

Para mais informações, consulte que serviços são afetados durante uma atualização do cluster.

Verifique a utilização do vSphere

Verifique se existem recursos suficientes na infraestrutura vSphere subjacente. Para verificar a utilização deste recurso, selecione um cluster no vCenter e reveja o separador Resumo.

O separador Resumo mostra o consumo geral de memória, CPU e armazenamento de todo o cluster. Uma vez que as atualizações do Google Distributed Cloud exigem recursos adicionais, também deve verificar se o cluster consegue processar estes pedidos de recursos adicionais.

Por norma, o cluster do vSphere tem de conseguir suportar os seguintes recursos adicionais:

  • +1 VM por atualização do cluster de administrador
  • +1 VM por node pool por atualização do cluster de utilizadores

Por exemplo, suponha que um cluster de utilizadores tem 3 conjuntos de nós em que cada conjunto de nós tem nós que usam 8 vCPUs e 32 GB ou mais de RAM. Uma vez que a atualização é feita em paralelo para os 3 conjuntos de nós por predefinição, o procedimento de atualização consome os seguintes recursos adicionais para os 3 nós de pico adicionais:

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

O processo de atualização cria VMs através da operação de clonagem do vSphere. A clonagem de várias VMs a partir de um modelo pode introduzir stress no sistema de armazenamento subjacente sob a forma de um aumento das operações de E/S. A atualização pode ser significativamente mais lenta se o subsistema de armazenamento subjacente não conseguir oferecer um desempenho suficiente durante uma atualização.

Embora o vSphere seja concebido para a utilização simultânea de recursos e tenha mecanismos para fornecer recursos, mesmo quando estão em excesso, recomendamos vivamente que não exceda a memória da VM. O excesso de compromisso de memória pode levar a impactos graves no desempenho que afetam todo o cluster, uma vez que o vSphere fornece a "RAM em falta" ao trocar páginas para o arquivo de dados. Este comportamento pode causar problemas durante uma atualização de um cluster e ter um impacto 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 satisfazer estes requisitos adicionais e evitar uma potencial redução no desempenho.

Verifique o estado de funcionamento e a configuração do cluster

Execute as seguintes ferramentas em todos os clusters antes da atualização:

  • O comando gkectl diagnose: gkectl diagnose garante que todos os clusters estão em bom estado. O comando executa verificações avançadas, como identificar nós que não estão configurados corretamente ou que têm pods num estado bloqueado. Se o comando gkectl diagnose apresentar um aviso Cluster unhealthy, corrija os problemas antes de tentar uma atualização. Para mais informações, consulte o artigo Diagnostique problemas de clusters.

  • A ferramenta de pré-atualização: além de verificar o estado e a configuração do cluster, a ferramenta de pré-atualização verifica potenciais problemas conhecidos que podem ocorrer durante uma atualização do cluster.

Além disso, quando atualizar os clusters de utilizadores para a versão 1.29 e superior, recomendamos que execute o comando gkectl upgrade cluster com a flag --dry-run. O sinalizador --dry-run executa verificações prévias mas não inicia o processo de atualização. Embora as versões anteriores do Google Distributed Cloud executem verificações preliminares, não podem ser executadas separadamente da atualização. Ao adicionar a flag --dry-run, pode encontrar e corrigir quaisquer problemas que as verificações prévias encontrem no seu cluster de utilizadores antes da atualização.

Use implementações para minimizar a interrupção da aplicação

Uma vez que os nós têm de ser esvaziados durante as atualizações, as atualizações de clusters podem provocar interrupções nas aplicações. A drenagem dos nós significa que todos os pods em execução têm de ser encerrados e reiniciados nos nós restantes no cluster.

Se possível, as suas aplicações devem usar implementações. Com esta abordagem, as aplicações são concebidas para processar interrupções. Qualquer impacto deve ser mínimo para implementações com várias réplicas. Ainda pode atualizar o cluster se as aplicações não usarem implementações.

Também existem regras para as implementações para garantir que um número definido de réplicas está sempre em execução. Estas regras são conhecidas como PodDisruptionBudgets (PDBs). Os PDBs permitem-lhe limitar a interrupção de uma carga de trabalho quando os respetivos pods têm de ser reagendados por algum motivo, como atualizações ou manutenção nos nós do cluster, e são importantes para verificar antes de uma atualização.

Use um par de balanceadores de carga de alta disponibilidade

Se usar o Seesaw como um equilibrador de carga num cluster, os equilibradores de carga são atualizados automaticamente quando atualiza o cluster. Esta atualização pode causar uma interrupção do serviço. Para reduzir o impacto de uma atualização e de uma eventual falha do equilibrador de carga, pode usar um par de alta disponibilidade (par de HA). Nesta configuração, o sistema cria e configura duas VMs do balanceador de carga para que possa ocorrer uma comutação por falha para o outro par.

Para aumentar a disponibilidade do serviço (ou seja, para o servidor da API Kubernetes), recomendamos que use sempre um par de HA à frente do cluster de administrador. Para saber mais acerca do Seesaw e da respetiva configuração de HA, consulte a documentação da versão 1.16 Equilíbrio de carga integrado com o Seesaw.

Para evitar uma interrupção do serviço durante uma atualização com um par de HA, o cluster inicia uma comutação por falha antes de criar a nova VM do balanceador de carga. Se um cluster de utilizadores usar apenas uma instância do equilibrador de carga, ocorre uma interrupção do serviço até que a atualização do equilibrador de carga esteja concluída.

Recomendamos que tenha um par de balanceadores de carga de HA se o próprio cluster de utilizadores também estiver configurado para ser altamente disponível. Esta série de práticas recomendadas pressupõe que um cluster de utilizadores de HA usa um par de equilibradores de carga de HA.

Se usar o MetalLB como um equilibrador de carga integrado, não é necessária nenhuma configuração pré-atualização. O equilibrador de carga é atualizado durante o processo de atualização do cluster.

Decida como atualizar cada cluster de utilizadores

Na versão 1.14 e posteriores, pode optar por atualizar um cluster de utilizador como um todo (ou seja, pode atualizar o painel de controlo e todos os conjuntos de nós no cluster) ou pode atualizar o painel de controlo do cluster de utilizador e deixar os conjuntos de nós na versão atual. Para obter informações sobre o motivo pelo qual pode querer atualizar o painel de controlo separadamente, consulte Atualizações de clusters de utilizadores.

Num ambiente de vários clusters, acompanhe os clusters de utilizadores que foram atualizados e registe o respetivo número de versão. Se decidir atualizar o painel de controlo e os conjuntos de nós separadamente, registe a versão do painel de controlo e de cada conjunto de nós em cada cluster.

Verifique as versões dos clusters de utilizadores e administradores

gkectl

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

    gkectl list clusters --kubeconfig ADMIN_CLUSTER_KUBECONFIG

    Substitua ADMIN_CLUSTER_KUBECONFIG pelo caminho do ficheiro kubeconfig para o cluster de administrador.

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

    gkectl list admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG

CLI gcloud

Para clusters inscritos na API GKE On-Prem, pode usar a CLI gcloud para obter as versões dos clusters de utilizadores, dos conjuntos de nós no cluster de utilizadores e nos clusters de administrador.

  1. Certifique-se de que tem a versão mais recente da CLI gcloud. Se necessário, atualize os componentes da CLI gcloud:

    gcloud components update

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

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

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

    Substitua PROJECT_ID pelo ID do projeto do seu projeto anfitrião da frota.

    Quando define --location=-, significa que quer listar todos os clusters em todas as regiões. Se precisar de reduzir o âmbito da lista, defina --location para a região que especificou quando inscreveu o cluster.

    O resultado 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:

Pode usar kubectl para obter a versão dos nós do cluster, mas kubectl devolve a versão do Kubernetes. Para obter a versão correspondente do Google Distributed Cloud para uma versão do Kubernetes, consulte a secção Controlo de versões.

kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG

Substitua USER_CLUSTER_KUBECONFIG pelo caminho do ficheiro kubeconfig do cluster de utilizadores.

Verifique se os certificados da AC têm de ser rodados

Durante uma atualização, os certificados finais são rodados, mas os certificados da AC não. Tem de rodar manualmente os seus certificados de CA, pelo menos, uma vez a cada cinco anos. Para mais informações, consulte os artigos Rode as autoridades de certificação do cluster de utilizadores e Rode os certificados de AC do cluster de administrador.

Diferenças entre tipos de clusters

Existem dois tipos diferentes de clusters:

  • Cluster de utilizadores
  • Cluster de administrador

Consoante a forma como cria um cluster de utilizadores, este pode conter nós de trabalho e nós do plano de controlo (Controlplane V2) ou apenas nós de trabalho (kubeception). Com o kubeception, o plano de controlo de um cluster de utilizador é executado num ou mais nós num cluster de administrador. Em ambos os casos, na versão 1.14 e posteriores, pode atualizar o painel de controlo de um cluster de utilizador separadamente dos conjuntos de nós que executam as suas cargas de trabalho.

Diferentes efeitos das atualizações de clusters de utilizadores em comparação com as atualizações de clusters de administradores

O procedimento de atualização do Google Distributed Cloud envolve um processo de esvaziamento de nós que remove todos os pods de um nó. O processo cria uma nova VM para cada nó de trabalho esgotado e adiciona-a ao cluster. Em seguida, os nós de trabalho esgotados são removidos do inventário do VMware. Durante este processo, qualquer carga de trabalho executada nestes nós é parada e reiniciada noutros nós disponíveis no cluster.

Consoante a arquitetura escolhida da carga de trabalho, este procedimento pode ter um impacto na disponibilidade de uma aplicação. Para evitar uma sobrecarga excessiva das capacidades de recursos do cluster, o Google Distributed Cloud atualiza um nó de cada vez.

Interrupção do cluster de utilizadores

A tabela seguinte descreve o impacto de uma atualização no local do cluster de utilizadores:

Função Cluster de administrador Cluster de utilizadores não HA Cluster de utilizadores de HA
Acesso à API Kubernetes Não afetado Não afetado Não afetado
Cargas de trabalho do utilizador Não afetado Não afetado Não afetado
PodDisruptionBudgets* Não afetado Não afetado Não afetado
Nó do plano de controlo Não afetado Afetado Não afetado
Redimensionador automático de pods (VMware) Não afetado Não afetado Não afetado
Reparação automóvel Não afetado Não afetado Não afetado
Escala automática de nós (VMware) Não afetado Não afetado Não afetado
Escala automática horizontal de pods Afetado Afetado Não afetado
  • * : Os PDBs podem fazer com que a atualização falhe ou pare.
  • Afetado: uma interrupção do serviço durante a atualização é percetível até a atualização estar concluída.
  • Não afetado: pode ocorrer uma interrupção do serviço durante um período muito curto, mas é quase impercetível.

Os nós do plano de controlo do cluster de utilizadores, quer sejam executados no cluster de administrador (kubeception) ou no próprio cluster de utilizadores (Controlplane V2), não executam cargas de trabalho do utilizador. Durante uma atualização, estes nós do plano de controlo são esvaziados e, em seguida, atualizados em conformidade.

Em ambientes com planos de controlo de alta disponibilidade (HA), a atualização do plano de controlo de um cluster de utilizadores não interrompe as cargas de trabalho dos utilizadores. Num ambiente de HA, a atualização de um cluster de administrador não interrompe as cargas de trabalho do utilizador. Para clusters de utilizadores que usam o Controlplane V2, a atualização apenas do plano de controlo não interrompe as cargas de trabalho do utilizador.

Durante uma atualização num ambiente de plano de controlo não de HA, o plano de controlo não pode controlar as ações de escalamento de pods, recuperação ou implementação. Durante a breve interrupção do plano de controlo durante a atualização, as cargas de trabalho do utilizador podem ser afetadas se estiverem num estado de escalabilidade, implementação ou recuperação. Isto significa que as implementações falham durante uma atualização num ambiente não de HA.

Para melhorar a disponibilidade e reduzir a interrupção dos clusters de utilizadores de produção durante as atualizações, recomendamos que use três nós do plano de controlo (modo de alta disponibilidade).

Interrupção do cluster de administração

A tabela seguinte descreve o impacto de uma atualização no local do cluster de administrador:

Função Cluster de administrador Cluster de utilizadores não HA Cluster de utilizadores de HA
Acesso à API Kubernetes Afetado Afetado Não afetado
Cargas de trabalho do utilizador Não afetado Não afetado Não afetado
Nó do plano de controlo Afetado Afetado Não afetado
Redimensionador automático de pods Afetado Afetado Não afetado
Reparação Automóvel Afetado Afetado Não afetado
Escala automática de nós Afetado Afetado Não afetado
Escala automática horizontal de pods Afetado Afetado Não afetado
  • Afetado: uma interrupção do serviço durante a atualização é percetível até a atualização estar concluída.
  • Não afetado: pode ocorrer uma interrupção do serviço durante um período muito curto, mas é quase impercetível.

O que se segue?