Os clusters do Anthos no VMware agora são o Google Distributed Cloud (somente software) para VMware. Para mais informações, consulte a visão geral do produto.

Migrar um cluster de administrador para HA

Esta página mostra como migrar para um cluster de administrador de alta disponibilidade (HA) de um cluster de administrador que não é HA na versão 1.29.

1.29: prévia
1.28: indisponível

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

Um cluster de administrador que não é de HA tem um nó do plano de controle e dois nós de complemento.
Um cluster de administrador de alta disponibilidade tem três nós do plano de controle e nenhum nó de complemento, e a disponibilidade é significativamente melhorada.

Prepare-se para a migração

Se a versão do cluster de administrador for 1.29.0-1.29.600 ou 1.30.0-1.30.100 e a criptografia de segredos ativa tiver sido ativada no cluster de administrador na versão 1.14 ou anterior, será necessário girar a chave de criptografia antes de iniciar a migração. Caso contrário, o novo cluster de administrador de HA não vai conseguir descriptografar segredos.

Para verificar se o cluster está usando uma chave de criptografia 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 a saída mostrar uma chave vazia, como no exemplo a seguir, você precisará girar a chave de criptografia.

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

Alternar a chave de criptografia, se necessário

Se as etapas na seção anterior mostrarem que você precisa girar a chave de criptografia, siga estas etapas:

Aumente o keyVersion no arquivo de configuração do cluster de administrador.
Atualize o cluster de administrador:
```
gkectl update admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --config ADMIN_CLUSTER_CONFIG
```
Isso cria uma nova chave correspondente ao novo número de versão, criptografa novamente cada secret e apaga o secret antigo com segurança. Todos os novos secrets subsequentes são criptografados com a nova chave de criptografia.

Visão geral do procedimento

A migração envolve estas etapas principais:

Edite o arquivo de configuração do cluster de administrador.
Execute gkectl update admin. Esse comando faz o seguinte:
- Mostra um cluster externo (Kind) e garante que o cluster de administrador não HA atual esteja em um estado íntegro.
- Cria um novo plano de controle do cluster de administrador usando a especificação HA e um novo VIP do plano de controle.
- Desativa o plano de controle do cluster de administrador.
- Tira um snapshot do etcd do cluster de administrador atual.
- Restaura os dados antigos do cluster de administrador no novo plano de controle de alta disponibilidade.
- Reconcilia o cluster de administrador restaurado para atender ao estado final do cluster de administrador de HA.

Observações

Durante a migração, não há tempo de inatividade para a carga de trabalho do cluster de usuários.
Durante a migração, há um tempo de inatividade para o plano de controle do cluster de administrador. O tempo de inatividade é menor que 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 ainda são válidos para a migração de não HA para HA. Por exemplo, os clusters de administrador de HA não são compatíveis com a Seesaw. Portanto, se você estiver usando o balanceador de carga da Seesaw para um cluster de administrador sem HA, primeiro migre para o MetalLB, antes de migrar para um cluster de administrador de HA.
Depois que a migração for concluída, os recursos restantes, como a VM mestre de administrador sem HA, serão mantidos intencionalmente para recuperação de falhas.

Antes e depois da migração

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

	Antes da migração	Depois da migração
Réplicas de nós do plano de controle	1	3
Nós de complemento	2	0
Réplicas de pod do plano de controle (kube-apiserver, kube-etcd etc.)	1	3
Tamanho do disco de dados	100 GB * 1	25 GB * 3
Caminho dos discos de dados	Definido por vCenter.dataDisk no arquivo de configuração do cluster de administrador	Gerado automaticamente no diretório: `/anthos/[ADMIN_CLUSTER_NAME]/default/[MACHINE_NAME]-data.vmdk`
Balanceador de carga para o VIP do plano de controle	Definido por loadBalancer.kind no arquivo de configuração do cluster de administrador	`keepalived` + `haproxy`
Alocação de endereços IP para nós do plano de controle do cluster de administrador	DHCP ou estático, dependendo de network.ipMode.type	3 endereços IP estáticos
Alocação de endereços IP para nós do plano de controle do cluster de usuário do kubeception	DHCP ou estático, dependendo de network.ipMode.type	DHCP ou estático, dependendo de network.ipMode.type
Arquivo de checkpoint	Ativado por padrão	Não utilizado

Editar o arquivo de configuração do cluster de administrador

É preciso especificar quatro endereços IP adicionais:

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

Você também precisa mudar alguns outros campos no arquivo de configuração do cluster de administrador, conforme descrito nas seções a seguir.

Especificar endereços IP

No arquivo de configuração do cluster de administrador, preencha a seção network.controlPlaneIPBlock. 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"

Preencha a seção hostconfig. Se o cluster de administrador usa endereços IP estáticos, esta seção já está preenchida. Exemplo:
```
hostConfig:
 dnsServers:
 – 203.0.113.1
 – 198.51.100.1
 ntpServers:
 – 216.239.35.12
```
Substitua o valor de loadBalancer.vips.controlPlaneVIP por um novo VIP. Exemplo:
```
loadBalancer:
 vips:
   controlPlaneVIP: "172.16.20.59"
```

Atualizar outros campos de configuração

Defina adminMaster.replicas como 3:

adminMaster:
 replicas: 3
 cpus: 4
 memoryMB: 8192

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 controle são gerados automaticamente no diretório raiz anthos no armazenamento de dados.
Se loadBalancer.manualLB.controlPlaneNodePort tiver um valor diferente de zero, defina-o como 0.

Ajustar a configuração do balanceador de carga manual

Se o cluster de administrador usar o balanceamento de carga manual, siga esta seção. Caso contrário, pule esta seção.

Para cada um dos três novos endereços IP do nó do plano de controle especificados na seção network.controlPlaneIPBlock, configure o seguinte mapeamento no balanceador de carga:

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

Esse mapeamento garante que o VIP antigo do plano de controle funcione durante a migração.

Atualizar o cluster de administrador

Revise as mudanças de configuração feitas porque os campos são imutáveis. Depois de confirmar que as mudanças estão corretas, atualize o cluster.

Inicie a migração:
```
gkectl update admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG --config ADMIN_CLUSTER_CONFIG
```
Substitua:
- ADMIN_CLUSTER_KUBECONFIG: o caminho do arquivo kubeconfig do cluster de administrador.
- ADMIN_CLUSTER_CONFIG: é o caminho do arquivo de configuração do cluster de administrador
O comando mostra o progresso da migração.

Quando solicitado, digite Y para continuar.
Quando a migração for concluída, o arquivo kubeconfig do cluster de administrador será atualizado automaticamente para usar o novo VIP do plano de controle. O VIP do plano de controle mais antigo continua funcionando e também pode ser usado para acessar o novo cluster de administrador de HA.