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.

Esta página foi traduzida pela API Cloud Translation.

Migrar um cluster de administrador para alta disponibilidade

Neste documento, mostramos como migrar de um cluster de administrador que não é de alta disponibilidade para um cluster de administrador de alta disponibilidade (HA, na sigla em inglês).

1.29: visualização
1.28: não disponível
1.16: não disponível

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

Visão geral do procedimento

Estas são as principais etapas envolvidas em uma migração:

Edite o arquivo de configuração do cluster de administrador.
Execute gkectl update admin. Este comando faz o seguinte:
- Crie um cluster externo (tipo) e verifique se o cluster de administrador atual que não é de alta disponibilidade está íntegro.
- Crie um novo plano de controle do cluster de administrador usando a especificação de alta disponibilidade e um novo VIP do plano de controle.
- Desative o plano de controle do cluster de administrador atual.
- Crie um snapshot do etcd do cluster de administrador atual.
- Restaure os dados do cluster de administrador antigo no novo plano de controle de alta disponibilidade.
- Reconcilie o cluster de administrador restaurado para atender ao estado final do cluster de administrador de alta disponibilidade.

Observações

Durante a migração, não há inatividade para a carga de trabalho do cluster de usuário.
Durante a migração, há um período de inatividade no plano de controle do cluster de administrador. Com base em nosso teste, o tempo de inatividade é inferior a 18 minutos, mas a duração real depende de ambientes de infraestrutura individuais.
Os requisitos dos clusters de administrador de alta disponibilidade ainda são válidos para migrações que não são de alta disponibilidade para alta disponibilidade. Ou seja, se você estiver usando o balanceador de carga Seesaw para um cluster de administrador que não seja de alta disponibilidade, primeiro precisará migrar para o MetalLB e depois migrar para um cluster de administrador de alta disponibilidade. Isso ocorre porque um cluster de administrador de alta disponibilidade não é compatível com o Seesaw.
Após a migração ser concluída, alguns recursos restantes (por exemplo, a VM mestre de administrador sem alta disponibilidade) serão mantidos intencionalmente para fins de recuperação de falhas. É possível limpá-los manualmente, se necessário.

Antes e depois da migração

Estas são 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 complementos	2	0
Réplicas de pod do plano de controle (kube-apiserver, kube-etcd etc.)	1	3
Tamanho do disco de dados	100GB * 1	25GB * 3
Caminho dos discos de dados	Definido por vCenter.dataDisk no arquivo de configuração do cluster de administrador	Gerada 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.	Três 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

É necessário 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 alterar alguns outros campos no arquivo de configuração do cluster de administrador.

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 usar endereços IP estáticos, essa seção já estará 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 campos de configuração adicionais

Defina adminMaster.replicas como 3:

adminMaster:
 replicas: 3
 cpus: 4
 memoryMB: 8192

Remova o campo vCenter.dataDisk. Isso ocorre porque, para um cluster de administrador de alta disponibilidade, os caminhos para os 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 manual do balanceador de carga

Se o cluster de administrador usar balanceamento de carga manual, siga a etapa desta 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 esse mapeamento no balanceador de carga:

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

Assim, o VIP antigo do plano de controle funcionará durante a migração.

Atualizar o cluster de administrador

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 exibe 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. Enquanto isso, o VIP antigo do plano de controle ainda funciona e pode ser usado para acessar o novo cluster de administrador de alta disponibilidade.

Limpe manualmente os recursos restantes, se necessário

Durante a migração, gkectl não exclui a VM do plano de controle do cluster de administrador. Em vez disso, ele apenas encerra a VM em vez de excluí-la do vSphere. Se você quiser excluir a VM antiga do plano de controle após uma migração bem-sucedida, faça a exclusão manualmente.

Para excluir manualmente a antiga VM do plano de controle e os recursos relacionados, faça o seguinte:

Verifique se a VM mestre do administrador sem alta disponibilidade gke-admin-master-xxx já está desativada.
Exclua a VM mestre de administrador sem alta disponibilidade gke-admin-master-xxx do vSphere.
Exclua o modelo de VM mestre do administrador sem alta disponibilidade gke-admin-master-xxx-tmpl do vSphere.
Exclua o disco de dados de administradores que não são de alta disponibilidade e o arquivo de checkpoint do administrador.
Limpe os arquivos temporários salvos em /home/ubuntu/admin-ha-migration/[ADMIN_CLUSTER_NAME]/.

Se preferir usar a CLI, confira os comandos do govc:

  // Configure govc credentials
  export GOVC_INSECURE=1
  export GOVC_URL=VCENTER_URL
  export GOVC_DATACENTER=DATACENTER
  export GOVC_DATASTORE=DATASTORE
  export GOVC_USERNAME=USERNAME
  export GOVC_PASSWORD=PASSWORD

  // Configure admin master VM name (you can find the master VM name from the "[HA Migration]" logs)
  export ADMIN_MASTER_VM=ADMIN_MASTER_VM_NAME

  // Configure datadisk path (remove ".vmdk" suffix)
  export DATA_DISK_PATH=DATADISK_PATH_WITHOUT_VMDK

  // Check whether admin master is in "poweredOff" state:
  govc vm.info $ADMIN_MASTER_VM | grep Power

  // Delete admin master VM
  govc vm.destroy $ADMIN_MASTER_VM

  // Delete admin master VM template
  govc vm.destroy "$ADMIN_MASTER_VM"-tmpl

  // Delete data disk
  govc datastore.ls $DATA_DISK_PATH
  govc datastore.rm $DATA_DISK_PATH

  // Delete admin checkpoint file
  govc datastore.ls "$DATA_DISK_PATH"-checkpoint.yaml
  govc datastore.rm "$DATA_DISK_PATH"-checkpoint.yaml