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 seja de alta disponibilidade (HA, na sigla em inglês).

1.29: Pré-lançamento
1.28: Indisponível
1.16: Indisponí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 complementares.

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 plano de controle VIP.
- Desative o plano de controle do cluster de administrador atual.
- Tire 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.
- Reconciliar 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. O tempo de inatividade é inferior a 18 minutos, com base no nosso teste, mas a duração real depende de ambientes de infraestrutura individuais.
Os requisitos para clusters de administrador de alta disponibilidade ainda são válidos para a migração sem 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 para um cluster de administrador de alta disponibilidade. Isso ocorre porque um cluster de administrador de alta disponibilidade não oferece suporte ao Seesaw.
Depois que a migração for concluída, haverá recursos restantes (por exemplo, a VM mestre do administrador sem alta disponibilidade) que mantivemos intencionalmente para a recuperação de falhas. É possível limpar os dados 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	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 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

Você precisa especificar mais quatro endereços IP:

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, esta 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, em 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 de nó do plano de controle especificados na seção network.controlPlaneIPBlock, configure esse mapeamento no balanceador de carga:

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

Dessa forma, o antigo VIP do plano de controle vai 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 é concluída, o arquivo kubeconfig do cluster de administrador é atualizado automaticamente para usar o novo VIP do plano de controle. Enquanto isso, o antigo VIP do plano de controle ainda funciona e também 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 desliga a VM em vez de excluí-la do vSphere. Se você quiser excluir a VM do plano de controle antiga após uma migração bem-sucedida, faça a exclusão manualmente.

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

Verifique se a VM mestra gke-admin-master-xxx do administrador que não é de alta disponibilidade já está desligada.
Exclua a VM mestra gke-admin-master-xxx do administrador que não é de alta disponibilidade do vSphere.
Exclua do vSphere o modelo de VM mestre que não seja de alta disponibilidade. gke-admin-master-xxx-tmpl
Exclua o disco de dados de administrador que não seja 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]/.

Veja a seguir os comandos govc, caso prefira usar a CLI:

  // 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