Migre um cluster de administrador para HA

Esta página mostra como migrar para um cluster de administrador de alta disponibilidade (HA) a partir de um cluster de administrador sem HA na versão 1.29.

1.29: pré-visualização
1.28: não disponível

Antes e depois da migração, o cluster de administrador tem três nós:

• Um cluster de administrador não HA tem um nó do plano de controlo e dois nós de suplementos.
• Um cluster de administrador de HA tem três nós do plano de controlo e nenhum nó de suplemento, e a disponibilidade é significativamente melhorada.

Prepare-se para a migração

Se a versão do cluster de administrador for 1.29.0 a 1.29.600 ou 1.30.0 a 1.30.100 e se a encriptação de segredos sempre ativada tiver sido ativada no cluster de administrador na versão 1.14 ou anterior, tem de rodar a chave de encriptação antes de iniciar a migração. Caso contrário, o novo cluster de administrador de HA não vai conseguir desencriptar segredos.

Para verificar se o cluster pode estar a usar uma chave de encriptação antiga:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get secret -n kube-system admin-master-component-options -o jsonpath='{.data.data}' | base64 -d | grep -oP '"GeneratedKeys":\[.*?\]'

Se o resultado mostrar uma chave vazia, como no exemplo seguinte, tem de alternar a chave de encriptação.

"GeneratedKeys":[{"KeyVersion":"1","Key":""}]

Alterne a chave de encriptação, se necessário

Se os passos na secção anterior mostraram que tem de rodar a chave de encriptação, execute os seguintes passos:

1. Aumente o valor de keyVersion no ficheiro de configuração do cluster de administrador.

2. Atualize o cluster de administrador:

   gkectl update admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
     --config ADMIN_CLUSTER_CONFIG
   

   Esta ação cria uma nova chave correspondente ao novo número da versão, volta a encriptar cada segredo e apaga os segredos antigos de forma segura. Todos os novos segredos subsequentes são encriptados com a nova chave de encriptação.

Vista geral do procedimento

A migração envolve estes passos principais:

1. Edite o ficheiro de configuração do cluster de administrador.

2. Corrida gkectl update admin. Este comando faz o seguinte:

   • Abre um cluster externo (Kind) e garante que o cluster de administrador não HA atual está em bom estado.

   • Cria um novo plano de controlo do cluster de administrador com a especificação de HA e um novo VIP do plano de controlo.

   • Desativa o plano de controlo do cluster de administrador existente.

   • Cria uma captura de ecrã do etcd do cluster de administrador existente.

   • Restaura os dados do cluster de administrador antigo no novo plano de controlo de HA.

   • Reconcilia o cluster de administrador restaurado para cumprir o estado final do cluster de administrador de HA.

Notas

• Durante a migração, não existe indisponibilidade para a carga de trabalho do cluster de utilizadores.

• Durante a migração, existe algum tempo de inatividade para o plano de controlo do cluster de administrador. (O tempo de inatividade é inferior a 18 minutos, com base nos nossos testes, mas a duração real depende dos ambientes de infraestrutura individuais).

• Os requisitos para clusters de administrador de HA continuam a aplicar-se à migração de não HA para HA. Por exemplo, os clusters de administrador de HA não suportam o Seesaw. Por isso, se estiver a usar o equilibrador de carga do Seesaw para um cluster de administrador que não seja de HA, tem de migrar primeiro para o MetalLB antes de migrar para um cluster de administrador de HA.

• Após a conclusão bem-sucedida da migração, os recursos restantes, como a VM principal de administrador não HA, são mantidos intencionalmente para recuperação de falhas.

Antes e depois da migração

A tabela seguinte mostra as principais diferenças no cluster antes e depois da migração:

Edite o ficheiro de configuração do cluster de administrador

Tem de especificar quatro endereços IP adicionais:

• Três endereços IP para os nós do plano de controlo do cluster de administrador
• Um novo VIP do plano de controlo para o equilibrador de carga do cluster de administrador

Também tem de alterar alguns outros campos no ficheiro de configuração do cluster de administrador, conforme descrito nas secções seguintes.

Especifique endereços IP

1. No ficheiro de configuração do cluster de administrador, preencha a secção network.controlPlaneIPBlock. Por exemplo:

   controlPlaneIPBlock:
     netmask: "255.255.255.0"
     gateway: "172.16.20.1"
     ips:
     - ip: "172.16.20.50"
       hostname: "admin-cp-node-1"
     - ip: "172.16.20.51"
       hostname: "admin-cp-node-2"
     - ip: "172.16.20.52"
       hostname: "admin-cp-node-3"
   

2. Preencha a secção hostconfig. Se o cluster de administrador usar endereços IP estáticos, esta secção já está preenchida. Por exemplo:

   hostConfig:
     dnsServers:
     - 203.0.113.1
     - 198.51.100.1
     ntpServers:
     - 216.239.35.12
   

3. Substitua o valor de loadBalancer.vips.controlPlaneVIP por um novo VIP. Por exemplo:

   loadBalancer:
    vips:
      controlPlaneVIP: "172.16.20.59"
   

Atualize campos de configuração adicionais

1. Defina adminMaster.replicas como 3:

   adminMaster:
    replicas: 3
    cpus: 4
    memoryMB: 8192
   

2. Remova o campo vCenter.dataDisk. Para um cluster de administrador de HA, os caminhos dos três discos de dados usados pelos nós do plano de controlo são gerados automaticamente no diretório raiz anthos no arquivo de dados.

3. Se loadBalancer.manualLB.controlPlaneNodePort tiver um valor diferente de zero, defina-o como 0.

Ajuste a configuração manual do balanceador de carga

Se o cluster de administrador usar o equilíbrio de carga manual, preencha esta secção. Caso contrário, ignore esta secção.

Para cada um dos três novos endereços IP do nó do plano de controlo que especificou na secção network.controlPlaneIPBlock, configure o seguinte mapeamento no equilibrador de carga:

(old controlPlaneVIP:443) -> (NEW_NODE_IP_ADDRESS:old controlPlaneNodePort)

Esta associação garante que o VIP do plano de controlo antigo funciona durante a migração.

Atualize o cluster de administrador

Reveja as alterações de configuração que fez, uma vez que os campos são imutáveis. Quando confirmar que as alterações estão corretas, atualize o cluster.

1. Inicie a migração:

   gkectl update admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG
   

   Substitua o seguinte:

   • ADMIN_CLUSTER_KUBECONFIG: o caminho do ficheiro kubeconfig do cluster de administrador.

   • ADMIN_CLUSTER_CONFIG: o caminho do ficheiro de configuração do cluster de administrador

2. O comando apresenta o progresso da migração.

   Quando lhe for pedido, introduza Y para continuar.

3. Quando a migração estiver concluída, o ficheiro kubeconfig do cluster de administrador é atualizado automaticamente para usar o novo VIP do plano de controlo. O VIP do plano de controlo mais antigo continua a funcionar e também pode ser usado para aceder ao novo cluster de administrador de HA.