Migrar clusters de administrador para recursos recomendados

Visão geral

Nesta página, mostramos como migrar um cluster de administrador da versão 1.30 ou mais recente para estes recursos recomendados:

• A configuração do balanceador de carga:

  • A configuração do balanceador de carga F5 BIG-IP integrado para ManualLB.

    ou

  • O balanceador de carga do Seesaw em pacote para o MetalLB.

• Migrar para um cluster de administrador de alta disponibilidade (HA) de um cluster de administrador que não é HA. A disponibilidade é significativamente melhorada com um cluster de administrador de alta disponibilidade usando o mesmo número de VMs. Um cluster de administrador que não é de HA tem um nó do plano de controle e dois nós de complemento. Os três nós de um cluster de administrador de HA são todos nós do plano de controle sem nós de complemento.

Esta página é destinada a administradores de TI e operadores que gerenciam o ciclo de vida da infraestrutura de tecnologia subjacente. Para saber mais sobre papéis comuns e tarefas de exemplo referenciados no conteúdo do Google Cloud, consulte Tarefas e papéis de usuário comuns do GKE Enterprise.

Para mais informações sobre o planejamento de migração, consulte Planejar a migração de clusters para recursos recomendados.

Práticas recomendadas

Se você tiver vários ambientes, como teste, desenvolvimento e produção, recomendamos migrar primeiro o ambiente menos crítico, como o de teste. Depois de verificar se a migração foi bem-sucedida, repita esse processo para cada ambiente, migrando o ambiente de produção por último. Isso permite validar o sucesso de cada migração e garantir que as cargas de trabalho estejam sendo executadas corretamente, antes de passar para o próximo ambiente mais crítico.

Requisitos

• O cluster de administrador precisa estar na versão 1.30 ou mais recente.
• Todos os clusters de usuário gerenciados pelo cluster de administrador precisam ter sido migrados para recursos recomendados, conforme descrito em Migrar um cluster de usuário para recursos recomendados.

Planejar o tempo de inatividade durante a migração

Para a migração, planeje um tempo de inatividade limitado do plano de controle. O acesso à API do Kubernetes fica indisponível para clusters de administrador não HA por cerca de 20 minutos, mas o plano de controle do Kubernetes continua disponível para clusters de administrador HA com F5. Durante as migrações, o plano de dados do Kubernetes continua funcionando em um estado estável.

Observação: as cargas de trabalho do usuário só podem ser executadas em clusters de usuário, que não são afetados durante a migração dos clusters de administrador.

De	Para	Acesso à API Kubernetes	Cargas de trabalho de usuário
Clusters de administrador de HA com o F5 BIG-IP	Clusters de administrador de HA com ManualLB	Não afetado	Não afetado
Clusters de administrador que não são de alta disponibilidade com MetalLB ou ManualLB	Clusters de administrador de HA com o mesmo tipo de balanceador de carga	Afetado	Não afetado
Clusters de administrador sem HA com o F5 BIG-IP	Clusters de administrador de HA com ManualLB	Afetado	Não afetado
Clusters de administrador sem HA com o Seesaw	Clusters de administrador de HA com o MetalLB	Afetado	Não afetado

• Afetado: há uma interrupção perceptível do serviço durante a migração.
• Não afetado: não há interrupção do serviço ou ela é quase imperceptível.

Prepare-se para a migração

Se o cluster de administrador não for HA, prepare-se para migrar para um cluster de administrador HA seguindo as etapas desta seção. Se o cluster de administrador já estiver em HA, pule para a próxima seção, Preparar para a migração do balanceador de carga.

Alocar endereços IP adicionais

Ao migrar o cluster de administrador de não HA para HA, aloque quatro endereços IP adicionais. Verifique se esses endereços IP estão na mesma VLAN que os nós do cluster de administrador e se não estão sendo usados por nenhum nó:

• Aloque um endereço IP para o novo VIP do plano de controle, para o campo loadBalancer.vips.controlPlaneVIP no arquivo de configuração do cluster de administrador.
• Aloque um novo endereço IP para cada um dos três nós do plano de controle, para a seção network.controlPlaneIPBlock no arquivo de configuração do cluster de administrador.

Atualizar regras de firewall

Ao migrar o cluster de administrador de não HA para HA, atualize as regras de firewall no cluster de administrador. Isso garante que os endereços IP recém-alocados para os nós do plano de controle possam acessar todas as APIs e outros destinos necessários, conforme descrito em Regras de firewall para clusters de administrador.

Preparar para a migração do balanceador de carga

Se o cluster de administrador estiver usando a configuração integrada do F5 BIG-IP ou o balanceador de carga do Seesaw em pacote, siga as etapas desta seção para fazer as mudanças necessárias no arquivo de configuração do cluster de administrador. Caso contrário, pule para a próxima seção, Preparar para migrar de não HA para HA.

F5 BIG-IP

Se o cluster de administrador estiver usando a configuração integrada do F5 BIG-IP, faça as seguintes mudanças no arquivo de configuração do cluster de administrador:

1. Defina o campo loadBalancer.kind como "ManualLB".
2. Defina ou mantenha o valor do campo loadBalancer.vips.controlPlaneVIP. Se o cluster de administrador já tiver alta disponibilidade, mantenha o mesmo valor. Se você estiver migrando de um cluster de administrador que não é HA para um cluster de administrador HA, mude o valor do campo loadBalancer.vips.controlPlaneVIP para o endereço IP alocado.
3. Exclua toda a seção loadBalancer.f5BigIP.

O exemplo de arquivo de configuração do cluster de administrador a seguir mostra essas mudanças:

loadBalancer:
vips:
  controlPlaneVIP: 192.0.2.6 192.0.2.50
kind: "F5BigIP" "ManualLB"
f5BigIP:
    address: "203.0.113.20"
  credentials:
    fileRef:
      path: ""my-config-folder/user-creds.yaml"
      entry: "f5-creds"
  partition: "my-f5-user-partition"
  

Seesaw

Se o cluster de administrador usar o balanceador de carga do Seesaw, faça as seguintes mudanças no arquivo de configuração do cluster de administrador:

1. Defina o campo loadBalancer.kind como MetalLB.
2. Mantenha a seção network.hostConfig.
3. Defina ou mantenha o valor do campo loadBalancer.vips.controlPlaneVIP]5. Se o cluster de administrador já tiver HA, você poderá manter o mesmo valor. Se você estiver migrando de um cluster de administrador que não é HA para um cluster de administrador HA, mude o valor do campo loadBalancer.vips.controlPlaneVIP do endereço IP alocado.
4. Remova a seção loadBalancer.seesaw.

O exemplo de arquivo de configuração do cluster de administrador a seguir mostra essas mudanças:

network:
hostConfig:
  dnsServers:
  - "203.0.113.1"
  - "203.0.113.2"
  ntpServers:
  - "203.0.113.3"
loadBalancer:
vips:
  controlPlaneVIP: 192.0.2.6 192.0.2.50
kind: "MetalLB" "Seesaw"
seesaw:
  ipBlockFilePath: "user-cluster-1-ipblock.yaml"
  vrid: 1
  masterIP: ""
  cpus: 4
  memoryMB: 3072

Preparar-se para migrar de não HA para HA

Se o cluster de administrador não for HA, siga as etapas desta seção para migrar para HA.

Se o cluster de administrador já for HA, pule para a próxima seção, Migrar o cluster de administrador.

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:

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

2. 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.

Aviso: se você iniciou a migração sem girar a chave de criptografia, entre em contato com o suporte do Google.

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

Faça estas mudanças no arquivo de configuração do cluster de administrador:

1. Preencha o network.controlPlaneIPBlock com os três endereços IP alocados para os nós do plano de controle.
2. Verifique se você preencheu a seção network.hostConfig. Esta seção contém informações sobre servidores NTP, servidores DNS e domínios de pesquisa DNS usados pelas VMs que são os nós do cluster.
3. Verifique se você substituiu o valor de loadBalancer.vips.controlPlaneVIP pelo endereço IP alocado.
4. Defina adminMaster.replicas como 3.
5. 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.
6. Se loadBalancer.kind foi definido como "ManualLB", defina loadBalancer.manualLB.controlPlaneNodePort como 0.

O exemplo de arquivo de configuração do cluster de administrador a seguir mostra essas mudanças:

vCenter:
  address: "my-vcenter-server.my-domain.example"
  datacenter: "my-data-center"
  dataDisk: "xxxx.vmdk"
...
network:
  hostConfig:
    dnsServers:
    – 203.0.113.1
    – 203.0.113.2
    ntpServers:
    – 203.0.113.3
  ...
  controlPlaneIPBlock:
    netmask: "255.255.255.0"
    gateway: "198.51.100.1"
    ips:
    – ip: "192.0.2.1"
      hostname: "admin-cp-hostname-1"
    – ip: "192.0.2.2"
      hostname: "admin-cp-hostname-2"
    – ip: "192.0.2.3"
      hostname: "admin-cp-hostname-3"
...

...
loadBalancer:
  vips:
    controlPlaneVIP: 192.0.2.6 192.0.2.50
  kind: ManualLB
  manualLB:
    controlPlaneNodePort: 30003 0

...
adminMaster:
  replicas: 3
  cpus: 4
  memoryMB: 8192
...

Ajustar os mapeamentos no balanceador de carga, se necessário

Se o cluster de administrador estiver usando o balanceamento de carga manual, conclua a etapa nesta seção.

Se estiver migrando do F5 BIG-IP integrado para o balanceamento de carga manual ou para o MetalLB, pule para a próxima seção, Migrar o cluster de administrador.

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 externo (como F5 BIG-IP ou Citrix):

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

Isso garante que o antigo VIP do plano de controle continue funcionando durante a migração.

Migrar o cluster de administrador

Revise cuidadosamente todas as mudanças feitas no arquivo de configuração do cluster de administrador. Todas as configurações são imutáveis, exceto quando o cluster é atualizado para a migração.

Atualize o cluster:

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

Replace the following:

• 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.

Durante a migração de não HA para HA, o VIP do plano de controle mais antigo continua funcionando e pode ser usado para acessar o novo cluster administrativo de HA. 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.

Após a migração

Após a conclusão da atualização, verifique se o cluster de administrador está em execução:

kubectl get nodes --kubeconfig ADMIN_CLUSTER_KUBECONFIG

A saída esperada terá esta aparência:

Migração do balanceador de carga

Se você migrou o balanceador de carga, verifique se os componentes do balanceador de carga estão em execução.

MetalLB

Se você migrou para o MetalLB, verifique se os componentes do MetalLB estão sendo executados com sucesso usando o seguinte comando:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get pods \
    --namespace kube-system --selector app=metallb

A saída mostra pods do controlador e alto-falante do MetalLB. Por exemplo:

metallb-controller-744884bf7b-rznr9 1/1 Running
metallb-speaker-6n8ws 1/1 Running
metallb-speaker-nb52z 1/1 Running
metallb-speaker-rq4pp 1/1 Running

Após a migração, exclua as VMs do Seesaw desativadas do cluster de administrador. É possível encontrar os nomes de VMs do Seesaw na seção vmnames do arquivo seesaw-for-gke-admin.yaml no diretório de configuração.

ManualLB

Depois de atualizar os clusters para usar o balanceamento de carga manual, o tráfego para os clusters não é interrompido. Isso ocorre porque os recursos F5 ainda existem, como pode ser visto ao executar o seguinte comando:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \

A saída esperada terá esta aparência:

Warning: v1 ComponentStatus is deprecated in v1.19+
NAMESPACE     NAME                        TYPE     DATA   AGE
kube-system   secret/bigip-login-xt697x   Opaque   4      13h
NAMESPACE     NAME                              SECRETS   AGE
kube-system   serviceaccount/bigip-ctlr         0         13h
kube-system   serviceaccount/load-balancer-f5   0         13h
NAMESPACE     NAME                                        READY   UP-TO-DATE   AVAILABLE   AGE
kube-system   deployment.apps/k8s-bigip-ctlr-deployment   1/1     1            1           13h
kube-system   deployment.apps/load-balancer-f5            1/1     1            1           13h
NAME                                                                                ROLE                                       AGE
clusterrolebinding.rbac.authorization.k8s.io/bigip-ctlr-clusterrole-binding         ClusterRole/bigip-ctlr-clusterrole         13h
clusterrolebinding.rbac.authorization.k8s.io/load-balancer-f5-clusterrole-binding   ClusterRole/load-balancer-f5-clusterrole   13h
NAME                                                                 CREATED AT
clusterrole.rbac.authorization.k8s.io/bigip-ctlr-clusterrole         2024-03-25T04:37:34Z
clusterrole.rbac.authorization.k8s.io/load-balancer-f5-clusterrole   2024-03-25T04:37:34Z