Migre clusters de administrador para funcionalidades recomendadas

Vista geral

Esta página mostra como migrar um cluster de administrador da versão 1.30 ou superior para estas funcionalidades recomendadas:

• 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 incluído no MetalLB.

• Migre para um cluster de administrador de alta disponibilidade (HA) a partir de um cluster de administrador sem HA. A disponibilidade é significativamente melhorada com um cluster de administrador de HA enquanto usa o mesmo número de VMs. Um cluster de administrador não HA tem um nó do plano de controlo e dois nós de suplementos. Os três nós de um cluster de administrador de HA são todos nós do plano de controlo sem nós suplementares.

Esta página destina-se a administradores de TI e operadores que gerem o ciclo de vida da infraestrutura tecnológica subjacente. Para saber mais sobre as funções comuns e as tarefas de exemplo a que fazemos referência no Google Cloud conteúdo, consulte o artigo Funções e tarefas comuns do utilizador do GKE.

Para mais informações sobre o planeamento da migração, consulte o artigo Planeie a migração de clusters para as funcionalidades recomendadas.

Práticas recomendadas

Se tiver vários ambientes, como teste, desenvolvimento e produção, recomendamos que migre primeiro o ambiente menos crítico, como o de teste. Depois de verificar se a migração foi bem-sucedida, repita este processo para cada ambiente, migrando o ambiente de produção por último. Isto permite-lhe validar o êxito de cada migração e garantir que as suas cargas de trabalho estão a ser executadas corretamente antes de passar para o ambiente seguinte, mais crítico.

Requisitos

• O cluster de administrador tem de ter a versão 1.30 ou superior.
• Todos os clusters de utilizadores geridos pelo cluster de administrador já têm de estar migrados para as funcionalidades recomendadas, conforme descrito no artigo Migre um cluster de utilizadores para as funcionalidades recomendadas.

Planeie o período de descanso durante a migração

Para a migração, planeie algum tempo de inatividade limitado do plano de controlo. O acesso à API Kubernetes está indisponível para clusters de administrador não de HA durante cerca de 20 minutos, mas o plano de controlo do Kubernetes permanece disponível para clusters de administrador de HA com F5. Durante as migrações, o plano de dados do Kubernetes continua a funcionar de forma estável.

Nota: as cargas de trabalho do utilizador só devem ser executadas em clusters de utilizadores, que não são afetados quando migra os clusters de administrador.

De	Para	Acesso à API Kubernetes	Cargas de trabalho do utilizador
Clusters de administrador de HA com F5 BIG-IP	Clusters de administrador de HA com ManualLB	Não afetado	Não afetado
Clusters de administrador não HA com MetalLB ou ManualLB	Clusters de administrador de HA com o mesmo tipo de balanceador de carga	Afetado	Não afetado
Clusters de administrador não de HA com F5 BIG-IP	Clusters de administrador de HA com ManualLB	Afetado	Não afetado
Clusters de administrador não de HA com Seesaw	Clusters de administrador de HA com MetalLB	Afetado	Não afetado

• Afetado: existe uma interrupção do serviço notória durante a migração.
• Não afetado: não existe interrupção do serviço ou é quase impercetível.

Prepare-se para a migração

Se o cluster de administrador não for de HA, prepare-se para migrar para um cluster de administrador de HA seguindo os passos nesta secção. Se o cluster de administração já tiver HA, avance para a secção seguinte, Prepare-se para a migração do equilibrador de carga.

Atribua endereços IP adicionais

Quando migrar o cluster de administrador de não HA para HA, atribua quatro endereços IP adicionais. Certifique-se de que estes endereços IP estão na mesma VLAN que os nós do cluster de administrador existentes e que ainda não são usados por nenhum nó existente:

• Atribua um endereço IP para o novo VIP do plano de controlo, para o campo loadBalancer.vips.controlPlaneVIP no ficheiro de configuração do cluster de administrador.
• Atribua novos endereços IP a cada um dos três nós do plano de controlo para a secção network.controlPlaneIPBlock no ficheiro de configuração do cluster de administrador.

Atualize as regras de firewall

Quando migrar o cluster de administrador de não HA para HA, atualize as regras de firewall no cluster de administrador. Isto garante que os endereços IP recém-atribuídos para os nós do plano de controlo podem alcançar todas as APIs necessárias e outros destinos, conforme descrito nas regras de firewall para clusters de administrador.

Prepare-se para a migração do balanceador de carga

Se o cluster de administrador estiver a usar a configuração integrada do F5 BIG-IP ou o equilibrador de carga do Seesaw incluído, siga os passos nesta secção para fazer as alterações necessárias ao ficheiro de configuração do cluster de administrador. Caso contrário, avance para a secção seguinte: Prepare-se para migrar de não HA para HA.

F5 BIG-IP

Se o cluster de administrador estiver a usar a configuração integrada do F5 BIG-IP, faça as seguintes alterações ao ficheiro 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 administração já tiver HA, mantenha o mesmo valor. Se estiver a migrar de um cluster de administrador não de HA para um cluster de administrador de HA, altere o valor do campo loadBalancer.vips.controlPlaneVIP para o endereço IP que atribuiu.
3. Eliminar toda a secção loadBalancer.f5BigIP.

O ficheiro de configuração do cluster de administrador de exemplo seguinte mostra estas alterações:

loadBalancer:
vips:
  controlPlaneVIP: 192.0.2.6
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 equilibrador de carga do Seesaw, faça as seguintes alterações ao ficheiro de configuração do cluster de administrador:

1. Defina o campo loadBalancer.kind como "MetalLB".
2. Mantenha a secção network.hostConfig.
3. Defina ou mantenha o valor do campo loadBalancer.vips.controlPlaneVIP]5. Se o cluster de administrador já tiver HA, pode manter o mesmo valor. Se estiver a migrar de um cluster de administrador não de HA para um cluster de administrador de HA, altere o valor do campo loadBalancer.vips.controlPlaneVIP para o endereço IP que atribuiu.
4. Remova a secção loadBalancer.seesaw.

O ficheiro de configuração do cluster de administrador de exemplo seguinte mostra estas alterações:

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

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

Se o cluster de administrador não for de alta disponibilidade, prepare-se para migrar para a alta disponibilidade seguindo os passos nesta secção.

Se o cluster de administrador já tiver HA, avance para a secção seguinte, Migre o cluster de administrador.

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 rodar a chave de encriptação através dos passos descritos neste problema conhecido.

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

Aviso: se iniciou a migração sem rodar a chave de encriptação, contacte o apoio técnico da Google.

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

Faça estas alterações ao ficheiro de configuração do cluster de administrador:

1. Preencha o campo network.controlPlaneIPBlock com os três endereços IP que atribuiu aos nós do plano de controlo.
2. Certifique-se de que preencheu a secção network.hostConfig Esta secção contém informações sobre os servidores NTP, os servidores DNS e os domínios de pesquisa DNS usados pelas VMs que são os nós do cluster.
3. Certifique-se de que substituiu o valor de loadBalancer.vips.controlPlaneVIP pelo endereço IP que atribuiu.
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 controlo são gerados automaticamente no diretório raiz anthos no arquivo de dados.
6. Se loadBalancer.kind estiver definido como "ManualLB", defina loadBalancer.manualLB.controlPlaneNodePort como 0.

O ficheiro de configuração do cluster de administrador de exemplo seguinte mostra estas alterações:

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

Ajuste os mapeamentos no equilibrador de carga, se necessário

Se o cluster de administrador tiver usado o equilíbrio de carga manual, conclua o passo nesta secção.

Se estiver a migrar do F5 BIG-IP integrado para o equilíbrio de carga manual ou se estiver a migrar para o MetalLB, avance para a secção seguinte, Migre o cluster de administrador.

Para cada um dos três novos endereços IP de nós do plano de controlo que especificou na secção network.controlPlaneIPBlock, configure este mapeamento no equilibrador de carga externo (como F5 BIG-IP ou Citrix):

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

Isto garante que o VIP do plano de controlo antigo continua a funcionar durante a migração.

Migre o cluster de administrador

Reveja cuidadosamente todas as alterações que fez ao ficheiro de configuração do cluster de administrador. Todas as definições são imutáveis, exceto quando atualiza o cluster 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 ficheiro kubeconfig do cluster de administrador.
• ADMIN_CLUSTER_CONFIG: o caminho do ficheiro de configuração do cluster de administrador.

O comando apresenta o progresso da migração.

Quando lhe for pedido, introduza Y para continuar.

Durante a migração de não HA para HA, o VIP do plano de controlo mais antigo continua a funcionar e pode ser usado para aceder ao novo cluster de administrador de HA. 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.

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

Migração do balanceador de carga

Se migrou o equilibrador de carga, verifique se os componentes do equilibrador de carga estão a ser executados com êxito.

MetalLB

Se migrou para o MetalLB, verifique se os componentes do MetalLB estão a ser executados com êxito através do seguinte comando:

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

O resultado mostra os pods para o controlador e o altifalante 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 uma migração bem-sucedida, elimine as VMs do Seesaw desligadas para o cluster de administrador. Pode encontrar os nomes das VMs do Seesaw na secção vmnames do ficheiro seesaw-for-gke-admin.yaml no diretório de configuração.

ManualLB

Depois de atualizar os clusters para usar o equilíbrio de carga manual, o tráfego para os seus clusters não é interrompido. Isto deve-se ao facto de os recursos F5 existentes ainda existirem, como pode ver executando o seguinte comando:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \

O resultado esperado é semelhante ao seguinte:

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