Migre um cluster de utilizadores para funcionalidades recomendadas

Vista geral

Esta página mostra como migrar clusters de utilizadores da versão 1.30 ou superior para as seguintes funcionalidades recomendadas:

• Migre para o Dataplane V2 como a interface de rede de contentores (CNI).
• Migre clusters de utilizadores através do kubeception para o plano de controlo V2.

• Migre a configuração do balanceador de carga:

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

    ou

  • Do balanceador de carga do Seesaw integrado para o MetalLB.

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

Práticas recomendadas

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.

Recomendamos que crie um novo cluster de utilizadores com o Controlplane V2 ativado para saber mais sobre as diferenças arquitetónicas com os clusters de kubeception. O novo cluster não afeta as suas cargas de trabalho. No entanto, no pior cenário, se a migração falhar, tem um cluster pronto para as suas cargas de trabalho.

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

Requisitos

Para esta migração:

• O cluster de utilizadores tem de estar na versão 1.30 ou superior.
• Todos os conjuntos de nós têm de ter a mesma versão que o cluster de utilizadores.
• Se o cluster estiver a usar o balanceador de carga do Seesaw, certifique-se de que não está a depender do Seesaw para a preservação do IP do cliente, conforme descrito na secção seguinte.

Preservação do IP do cliente do Seesaw

Aviso: não migre para o MetalLB se estiver a usar o Seesaw para a preservação do endereço IP do cliente. Em concreto, não migre para o MetalLB se existirem serviços no cluster com spec.externalTrafficPolicy definido como Local.

Para verificar o externalTrafficPolicy, execute o seguinte comando:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get svc -A -o yaml | grep "externalTrafficPolicy: Local"

Se tiver este problema, contacte o Apoio técnico da Google.

Estime o tempo necessário e planeie um período de manutenção

Quando atualiza o cluster, por predefinição, todos os node pools são atualizados em paralelo. No entanto, em cada node pool, os nós são atualizados sequencialmente. Por conseguinte, o tempo total de atualização depende do número de nós no conjunto de nós mais grande. Para calcular uma estimativa aproximada para cada atualização:

• Se estiver a migrar do Seesaw para o MetalLB, estime 15 minutos para que a atualização escolha um conjunto de nós para o equilibrador de carga do MetalLB. Para esta atualização, apenas o node pool selecionado é atualizado.
• Para qualquer outra atualização no processo de migração, multiplique 15 minutos pelo número de nós no node pool.

Para estimar o tempo necessário, conte o número de vezes que tem de atualizar o cluster. Os seguintes passos de nível elevado mostram quando tem de executar gkectl update cluster para atualizar o cluster:

1. Se o cluster de utilizadores usar a encriptação secreta sempre ativa, desative a funcionalidade e execute gkectl update cluster.
2. Se o cluster de utilizadores tiver enableDataplaneV2 não definido ou definido como false, faça as alterações de configuração e, em seguida, execute gkectl update cluster para migrar para o Dataplane V2.

3. Prepare-se para a migração do balanceador de carga e do plano de controlo:

   1. Se o cluster de administrador tiver a reparação automática ativada, desative-a. Em seguida, execute gkectl update admin. Esta atualização termina rapidamente porque não recria os nós do cluster de administrador.
   2. Se o cluster de utilizadores usar o Seesaw, escolha um conjunto de nós para o balanceador de carga do MetalLB usar e, em seguida, execute gkectl update cluster. Esta atualização só atualiza os nós no node pool selecionado.

4. Faça todas as alterações de configuração necessárias para atualizar o equilibrador de carga e migrar para o plano de controlo V2. Em seguida, execute gkectl update cluster.

5. Após a migração, se desativou a encriptação secreta sempre ativa, reative a funcionalidade e execute gkectl update cluster.

O tempo total da migração depende do número de vezes que tem de executar o comando gkectl cluster update, que depende da sua configuração. Por exemplo, suponha que está a migrar para o Dataplane V2, o ControlPlane V2 e o MetalLB. Suponha também que existem 10 nós no maior conjunto de nós e 3 nós no conjunto de nós que o MetalLB vai usar. Para calcular uma estimativa do tempo de migração, adicione o seguinte:

• 150 minutos para a migração para o Dataplane V2, porque 15 minutos * 10 nós no maior conjunto = 150 minutos.
• 45 minutos para o conjunto de nós usado pelo MetalLB, porque 15 minutos * 3 nós nesse conjunto de nós = 45 minutos.
• 150 minutos para a atualização do Controlplane V2 e do MetalLB, porque 15 minutos * 10 nós no maior conjunto = 150 minutos.

O tempo total da migração é de aproximadamente 345 minutos, o que equivale a 5 horas e 45 minutos.

Se necessário, pode fazer a migração em fases. Usando o exemplo anterior, pode fazer a migração para o Dataplane V2 numa janela de manutenção e fazer o resto da migração numa ou duas janelas de manutenção.

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

Ao planear a migração, planeie estes tipos de indisponibilidade:

• Tempo de inatividade do plano de controlo: o acesso ao servidor da API Kubernetes é afetado durante a migração. Se estiver a migrar para o plano de controlo V2, existe um tempo de inatividade do plano de controlo para os clusters de utilizadores do kubeception à medida que o loadBalancer.vips.controlPlaneVIP é migrado. Normalmente, o tempo de inatividade é inferior a 10 minutos, mas a duração do tempo de inatividade depende da sua infraestrutura.
• Tempo de inatividade da carga de trabalho: os IPs virtuais (VIPs) usados pelos serviços do tipo: LoadBalancer estão indisponíveis. Isto só ocorre durante uma migração do Seesaw para o MetalLB. O processo de migração do MetalLB vai interromper as ligações de rede a todos os VIPs no cluster do utilizador para os serviços Kubernetes do tipo LoadBalancer durante cerca de dois a dez minutos. Quando a migração estiver concluída, as associações voltam a funcionar.

A tabela seguinte descreve o impacto da migração:

De	Para	Acesso à API Kubernetes	Cargas de trabalho do utilizador
Cluster Kubeception que usa o Calico, que tem enableDataplaneV2 não definido ou definido como false	Cluster Kubeception com Dataplane V2	Não afetado	Não afetado
Cluster Kubeception, que tem enableControlplaneV2 não definido ou definido como false com MetalLB ou ManualLB	Cluster do plano de controlo V2 com o mesmo tipo de balanceador de carga	Afetado	Não afetado
Cluster Kubeception com loadBalancer.kind: "F5BigIP"	Cluster do plano de controlo V2 com configuração manual do balanceador de carga	Afetado	Não afetado
Cluster Kubeception com loadBalancer.kind: "Seesaw"	Cluster do plano de controlo V2 com MetalLB	Afetado	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

Para garantir uma migração bem-sucedida, siga os passos nas secções seguintes.

Atribua novos endereços IP

Se estiver a migrar para o plano de controlo V2, atribua novos endereços IP estáticos na mesma VLAN que os nós de trabalho (os nós nos conjuntos de nós).

• Precisa de um endereço IP para o loadBalancer.vips.controlPlaneVIP.

• Atribua um endereço IP a cada nó do plano de controlo. O número de endereços IP que tem de atribuir depende de o cluster de utilizadores ter alta disponibilidade (HA) ou não.

  • Não HA: um endereço IP
  • HA: três endereços IP

Atualize as regras de firewall

Se estiver a migrar para o Controlplane V2, atualize as regras da firewall nos seus clusters de utilizadores. Certifique-se de que os endereços IP recém-atribuídos para os nós do plano de controlo no cluster de utilizadores podem alcançar todas as APIs necessárias e outros destinos, conforme descrito em Regras de firewall dos nós do cluster de utilizadores.

Verifique as versões do cluster e do node pool

Verifique se todos os conjuntos de nós usam a mesma versão que o cluster de utilizadores, que tem de ser a versão 1.30 ou superior. Caso contrário, atualize os node pools para a gkeOnPremVersion no ficheiro de configuração do cluster de utilizadores antes de continuar com a migração. Para verificar as versões, execute o seguinte comando:

gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG --details

Substitua ADMIN_CLUSTER_KUBECONFIG pelo caminho para o ficheiro kubeconfig do cluster de administrador.

Verifique o estado do cluster

Verifique o estado do cluster e corrija quaisquer problemas que o comando gkectl diagnose cluster comunique:

gkectl diagnose cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --cluster-name USER_CLUSTER_NAME

Substitua o seguinte:

• ADMIN_CLUSTER_KUBECONFIG: o caminho do ficheiro kubeconfig do cluster de administrador.
• USER_CLUSTER_NAME: o nome do cluster de utilizadores.

Desative a reparação automática no cluster de administração

Se estiver a migrar o cluster de utilizadores para usar o plano de controlo V2 e a reparação automática estiver ativada no cluster de administrador, desative a reparação automática. Verifique o campo autoRepair.enabled do ficheiro de configuração do cluster de administrador. Se esse campo não estiver definido ou estiver definido como true, execute os seguintes passos:

1. No ficheiro de configuração do cluster de administrador, defina autoRepair.enabled como false . Por exemplo:

   autoRepair:
     enabled: false
   

2. Atualize o cluster de administrador:

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

Substitua o seguinte:

• ADMIN_CLUSTER_KUBECONFIG: o caminho para o ficheiro kubeconfig do cluster de administrador.
• ADMIN_CLUSTER_CONFIG: o caminho para o ficheiro de configuração do cluster de administrador.

Após a conclusão da migração, certifique-se de que reativa a reparação automática no cluster de administração.

Verifique se existe um problema com a encriptação secreta sempre ativada

Se estiver a migrar o cluster de utilizadores para usar o plano de controlo V2, verifique se existe um problema com a encriptação secreta sempre ativa.

Se a encriptação de segredos sempre ativa tiver sido ativada no cluster de utilizadores, tem de seguir os passos em Desative a encriptação de segredos sempre ativa e desencripte os segredos antes de iniciar a migração. Caso contrário, o novo cluster do plano de controlo V2 não consegue desencriptar segredos.

Antes de iniciar a migração, execute o seguinte comando para ver se a encriptação de segredos sempre ativada foi ativada em algum momento:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  get onpremusercluster USER_CLUSTER_NAME \
  -n USER_CLUSTER_NAME-gke-onprem-mgmt \
  -o jsonpath={.spec.secretsEncryption}

Se o resultado do comando anterior estiver vazio, significa que a encriptação de segredos sempre ativada nunca foi ativada. Pode iniciar a migração.

Se o resultado do comando anterior não estiver vazio, significa que a encriptação de segredos sempre ativos foi ativada anteriormente. Antes da migração, tem de seguir os passos na secção seguinte para garantir que o novo cluster do plano de controlo V2 consegue desencriptar segredos.

O exemplo seguinte mostra uma saída não vazia:

{"generatedKeyVersions":{"keyVersions":[1]}}

Aviso: se iniciou a migração sem primeiro seguir os passos na secção seguinte, contacte a Google para receber apoio técnico.

Desative a encriptação de segredos sempre ativa e desencripte os segredos, se necessário

Para desativar a encriptação de segredos sempre ativa e desencriptar segredos, siga os passos abaixo:

1. No ficheiro de configuração do cluster de utilizadores, para desativar a encriptação de segredos sempre ativos, adicione um campo disabled: true à secção secretsEncryption:

   secretsEncryption:
       mode: GeneratedKey
       generatedKey:
           keyVersion: KEY_VERSION
           disabled: true
   

2. Atualize o cluster:

   gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
       --config USER_CLUSTER_CONFIG
   

   Substitua o seguinte:

   • ADMIN_CLUSTER_KUBECONFIG: o caminho do ficheiro kubeconfig do cluster de administrador
   • USER_CLUSTER_CONFIG: o caminho do ficheiro de configuração do cluster de utilizadores

3. Faça uma atualização contínua num DaemonSet específico da seguinte forma:

   kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
     rollout restart statefulsets kube-apiserver \
     -n USER_CLUSTER_NAME

4. Obtenha os manifestos de todos os segredos no cluster do utilizador, no formato YAML:

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
     get secrets -A -o yaml > SECRETS_MANIFEST.yaml

5. Para que todos os segredos sejam armazenados no etcd como texto simples, volte a aplicar todos os segredos no cluster do utilizador:

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
     apply -f SECRETS_MANIFEST.yaml

   Já pode iniciar a migração para o plano de controlo V2. Após a conclusão da migração, pode reativar a encriptação de segredos sempre ativa no cluster.

Verifique se existe um problema com webhooks de carga de trabalho configurados incorretamente

Se estiver a migrar o cluster de utilizadores para usar o plano de controlo V2, verifique se existe um problema com webhooks de carga de trabalho configurados incorretamente.

Se tiver webhooks que incluam pods do sistema no espaço de nomes kube-system, adicione namespaceSelector para filtrar o espaço de nomes kube-system.

Por exemplo,

  namespaceSelector:
    matchExpressions:
    - key: kubernetes.io/metadata.name
      operator: NotIn
      values:
      - kube-system

Ative um conjunto de nós para utilização pelo MetalLB

Se estiver a migrar do equilibrador de carga do Seesaw incluído para o MetalLB, siga os passos nesta secção. O cluster está a usar o Seesaw se loadBalancer.kind: Seesaw estiver no ficheiro de configuração do cluster de utilizadores. Se estiver a migrar a configuração do F5 BIG-IP integrado, avance para a secção seguinte: Migre para o Dataplane V2.

Escolha um grupo de nós e ative-o para utilização com o MetalLB. A migração implementa o MetalLB nos nós desse node pool.

Aviso: certifique-se de que o conjunto de nós que ativa para utilização pelo MetalLB não inclui o endereço IP de um serviço com um volume de entrada de tradução de endereços de rede (NAT) elevado. Isto pode fazer com que as suas cargas de trabalho fiquem sem memória. Em alternativa, use outro conjunto de nós existente ou crie um novo conjunto de nós para o MetalLB usar.

1. Na secção nodePools do ficheiro de configuração do cluster de utilizador, escolha um conjunto de nós ou adicione um novo conjunto de nós e defina enableLoadBalancer como true. Por exemplo:

   nodePools:
     - name: pool-1
       replicas: 3
       enableLoadBalancer: true
   

2. Atualize o cluster:

   gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
       --config USER_CLUSTER_CONFIG
   

Para mais informações sobre o MetalLB, consulte o artigo Equilíbrio de carga integrado com o MetalLB.

Migre para o Dataplane V2

Antes da migração, verifique se o DataPlane V2 está ativado no cluster executando o seguinte comando:

kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG get onpremusercluster USER_CLUSTER_NAME -n USER_CLUSTER_NAME-gke-onprem-mgmt -o yaml | grep enableDataplaneV2

Se o Dataplane V2 já estiver ativado, avance para a secção seguinte, Prepare-se para a migração do equilibrador de carga.

Para migrar para o Dataplane V2, tem as seguintes opções:

• Atualize o cluster para a versão 1.31. Para ver os passos detalhados, consulte o artigo Ative o Dataplane V2.

• Atualize o cluster 1.30.

Em ambos os casos, tem de remover temporariamente a especificação NetworkPolicy, conforme descrito nos passos seguintes.

Para migrar para o Dataplane V2, siga estes passos. Se tiver dúvidas acerca da remoção temporária da especificação NetworkPolicy, contacte o Apoio técnico da Google.

Se o seu cluster estiver a usar um NetworkPolicy, remova temporariamente a respetiva especificação do cluster, da seguinte forma:

1. Verifique se existem NetworkPolicynão pertencentes ao sistema aplicadas ao seu cluster:

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get networkpolicy -A -o wide | grep -v kube-system
   

2. Se o resultado do passo anterior não estiver vazio, guarde cada especificação num ficheiro para que possa reaplicar a especificação após atualizar o cluster.NetworkPolicy

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get networkpolicy NETWORK_POLICY_NAME -n NETWORK_POLICY_NAMESPACE -o yaml > NETWORK_POLICY_NAME.yaml
   

   Substitua o seguinte:

   • NETWORK_POLICY_NAME: o nome do NetworkPolicy que está a guardar.
   • NETWORK_POLICY_NAMESPACE: o espaço de nomes do NetworkPolicy.

3. Elimine o NetworkPolicy através do seguinte comando:

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete networkpolicy NETWORK_POLICY_NAME -n NETWORK_POLICY_NAMESPACE
   

Migre para o Dataplane V2 através destes passos:

1. Defina enableDataplaneV2 como true no ficheiro de configuração do cluster de utilizadores.

2. Para ativar o DataPlane V2, atualize o cluster:

   gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
   --config USER_CLUSTER_CONFIG
   

3. Se removeu especificações NetworkPolicy não relacionadas com o sistema num passo anterior, depois de a atualização estar concluída, volte a aplicá-las com este comando:

   kubectl --kubeconfig USER_CLUSTER_KUBECONFIG apply -f NETWORK_POLICY_NAME.yaml
   

Depois de concluir estes passos, tem o Dataplane V2 ativado. Em seguida, prepare-se para migrar o cluster para o balanceador de carga recomendado e o Controlplane V2.

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

Se os seus clusters de utilizadores estiverem a usar o equilibrador de carga do Seesaw ou o F5 BIG-IP integrado, siga os passos nesta secção para fazer as alterações necessárias ao ficheiro de configuração do cluster de utilizadores. Caso contrário, avance para a secção seguinte: Prepare-se para a migração para o Controlplane V2.

F5 BIG-IP

Se os seus clusters usarem a configuração integrada do F5 BIG-IP, prepare-se para a migração para o ManualLB fazendo as seguintes alterações ao ficheiro de configuração do cluster de utilizadores:

1. Alterar loadBalancer.kind para "ManualLB".
2. Mantenha o mesmo valor para o campo loadBalancer.vips.ingressVIP.
3. Se estiver a migrar para o Controlplane V2, altere o valor do campo loadBalancer.vips.controlPlaneVIP para o endereço IP que atribuiu. Caso contrário, pode manter o mesmo valor.
4. Eliminar a secção loadBalancer.f5BigIP inteira.

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

loadBalancer:
vips:
  controlPlaneVIP: 192.0.2.5
  ingressVIP: 198.51.100.20
kind: "f5BigIP" "ManualLB"
f5BigIP:
  address: "203.0.113.2"
  credentials:
  fileRef:
    path: "my-config-folder/user-creds.yaml"
    entry: "f5-creds"
  partition: "my-f5-user-partition"

Seesaw

Se os seus clusters de utilizadores usarem o equilibrador de carga do Seesaw, prepare-se para a migração para o MetalLB seguindo os passos nas secções seguintes.

Especifique conjuntos de endereços

O controlador MetalLB atribui endereços IP para serviços. Quando um programador de aplicações cria um serviço do tipo LoadBalancer num cluster de utilizadores, o controlador MetalLB atribui automaticamente um endereço IP para o serviço. O controlador MetalLB seleciona um endereço IP de um conjunto de endereços que especificar.

Para garantir que o cluster de utilizadores tem endereços IP suficientes, considere o número máximo de serviços LoadBalancer que provavelmente estarão ativos. Em seguida, especifique endereços IP suficientes na secção loadBalancer.metalLB.addressPools do ficheiro de configuração do cluster de utilizadores.

Ponto-chave: uma vez que um serviço do tipo LoadBalancer expõe o proxy de entrada, tem de incluir o VIP de entrada para o cluster de utilizadores num dos conjuntos de endereços.

As moradas no conjunto têm de estar no formato CIDR ou no formato de intervalo. Para especificar um endereço individual, use um CIDR./32 Por exemplo:

addresses:
  -   "192.0.2.0/26"
  -   "192.0.2.64-192.0.2.72"
  -   "192.0.2.75/32"

Exclua endereços IP usados para outros fins

Não inclua os seguintes endereços IP em nenhum conjunto de endereços:

• VIPs do plano de controlo:

  • admin cluster
  • cluster de utilizadores

• Endereços IP dos nós do plano de controlo:

  • admin cluster
  • cluster de utilizadores

• Endereços IP do gateway:

  • admin cluster
  • cluster de utilizadores

• Endereços IP para serviços:

  • admin cluster
  • cluster de utilizadores

• Endereços IP para pods:

  • admin cluster
  • cluster de utilizadores

• Endereços IP dos nós de trabalho do cluster de utilizadores

• Endereços IP de servidores vCenter, servidores DNS, servidores NTP> e a estação de trabalho do administrador

Atualize o ficheiro de configuração do cluster

Atualize o ficheiro de configuração do cluster para remover a secção do Seesaw e adicionar uma secção do MetalLB, da seguinte forma:

1. Defina loadBalancer.kind como "MetalLB".
2. Pode manter o mesmo valor para o campo loadBalancer.vips.ingressVIP.
3. Adicione o VIP de entrada a um conjunto de endereços do MetalLB.
4. Se estiver a migrar para o Controlplane V2, altere o valor do campo loadBalancer.vips.controlPlaneVIP para o endereço IP que atribuiu. Caso contrário, pode manter o mesmo valor.
5. Remova a secção loadBalancer.seesaw.
6. Adicione uma loadBalancer.metalLB secção.

A parte seguinte de um ficheiro de configuração do cluster de utilizadores mostra estas alterações e a configuração do MetalLB de:

• Um conjunto de endereços para o controlador MetalLB escolher e atribuir a serviços do tipo LoadBalancer. O VIP de entrada, que neste exemplo é 198.51.100.10, está neste conjunto no formato de notação de intervalo, 198.51.100.10/32.
• O IP virtual designado para o servidor da API Kubernetes do cluster de utilizador.
• O VIP de entrada que configurou para o proxy de entrada.
• Um node pool ativado para usar o MetalLB. A migração implementa o MetalLB nos nós neste node pool.

loadBalancer:
  vips:
    controlPlaneVIP: "198.51.100.50"
    ingressVIP: "198.51.100.10"
  kind: "MetalLB" "Seesaw"
  seesaw:
    ipBlockFilePath: "user-cluster-2-ipblock.yaml"
    vrid: 1
    masterIP: ""
    cpus: 4
    memoryMB: 3072
  metalLB:
    addressPools:
      - name: "address-pool-1"
        addresses:
        - "198.51.100.10/32"
        - "198.51.100.80 - 198.51.100.89"

Prepare-se para a migração para o plano de controlo V2

Se o cluster não tiver o Controlplane V2 ativado:

• Atualize o ficheiro de configuração do cluster de utilizadores.
• Se o cluster estiver a usar o balanceamento de carga manual (loadBalancer.kind: "ManualLB"), também tem de atualizar a configuração no balanceador de carga.

Estes passos são descritos nas secções seguintes.

Se o cluster já tiver o Controlplane V2 ativado, avance para a secção Migre o cluster de utilizadores.

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

Faça as seguintes alterações ao ficheiro de configuração do cluster de utilizadores existente:

1. Defina enableControlplaneV2 como verdadeiro.
2. Opcionalmente, torne o plano de controlo do cluster de utilizadores do Controlplane V2 altamente disponível (HA). Para alterar de um cluster não HA para um cluster HA, altere masterNode.replicas de 1 para 3.
3. Adicione o endereço IP estático (ou os endereços) para os nós do plano de controlo do cluster de utilizadores à secção network.controlPlaneIPBlock.ips. O endereço IP (ou os endereços) dos nós do plano de controlo tem de estar na mesma VLAN que os nós de trabalho. Os nomes de anfitrião são obrigatórios.
4. Preencha os campos netmask e gateway na secção network.controlPlaneIPBlock.
5. Se a secção network.hostConfig estiver vazia, preencha-a.
6. Certifique-se de que o campo loadBalancer.vips.controlPlaneVIP tem o novo endereço IP do VIP do plano de controlo. O endereço IP tem de estar na mesma VLAN que os IPs dos nós do plano de controlo.
7. Se o cluster de utilizadores usar o equilíbrio de carga manual, defina loadBalancer.manualLB.controlPlaneNodePort e loadBalancer.manualLB.konnectivityServerNodePort como 0. Não são obrigatórias quando o Controlplane V2 está ativado, mas têm de ter 0 como valor.
8. Se o cluster de utilizadores usar o balanceamento de carga manual, configure o balanceador de carga conforme descrito na secção seguinte.

Nota: certifique-se de que verifica todas as definições. Todos os campos anteriores são imutáveis, exceto quando atualiza o cluster para a migração.

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

Se o cluster de utilizadores já estiver a usar o equilíbrio de carga manual, tem de configurar alguns mapeamentos no equilibrador de carga. Se estiver a migrar da configuração do F5 BIG-IP integrado para o equilíbrio de carga manual, não precisa de fazer alterações de configuração no equilibrador de carga e pode avançar para a secção seguinte, Migre o cluster de utilizadores.

Para cada endereço IP que especificou na secção network.controlPlaneIPBlock, configure os seguintes mapeamentos no equilibrador de carga para os nós do plano de controlo:

(ingressVIP:80) -> (NEW_NODE_IP_ADDRESS:ingressHTTPNodePort)
(ingressVIP:443) -> (NEW_NODE_IP_ADDRESS:ingressHTTPSNodePort)

Estes mapeamentos são necessários para todos os nós no cluster de utilizadores, tanto os nós do plano de controlo como os nós de trabalho. Uma vez que os NodePorts estão configurados no cluster, o Kubernetes abre os NodePorts em todos os nós do cluster para que qualquer nó no cluster possa processar o tráfego do plano de dados.

Depois de configurar os mapeamentos, o balanceador de carga fica a aguardar tráfego no endereço IP que configurou para o VIP de entrada do cluster de utilizadores nas portas HTTP e HTTPS padrão. O balanceador de carga encaminha pedidos para qualquer nó no cluster. Depois de um pedido ser encaminhado para um dos nós do cluster, a rede Kubernetes interna encaminha o pedido para o pod de destino.

Migre o cluster de utilizadores

Primeiro, reveja cuidadosamente todas as alterações que fez ao ficheiro de configuração do cluster de utilizadores. Todas as definições do balanceador de carga e do painel de controlo V2 são imutáveis, exceto quando está a atualizar o cluster para a migração.

Para atualizar o cluster, execute este comando:

gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG

Migração do plano de controlo V2

Durante a migração do plano de controlo V2, a atualização realiza as seguintes ações:

1. Cria o plano de controlo de um novo cluster com o ControlPlane V2 ativado.
2. Para o plano de controlo do Kubernetes do cluster kubeception.
3. Cria um instantâneo do etcd do cluster kubeception.
4. Desliga os nós do plano de controlo do cluster de utilizadores do cluster kubeception. Até a migração ser concluída, os nós não são eliminados porque isso permite a recuperação de falhas ao reverter para esse cluster do kubeception.
5. Restaura os dados do cluster no novo plano de controlo, usando o instantâneo do etcd criado num passo anterior.
6. Liga os nós do conjunto de nós do cluster kubeception ao novo plano de controlo, que é acessível com o novo controlPlaneVIP.
7. Reconcilia o cluster de utilizadores restaurado para cumprir o estado final do cluster com o ControlPlane V2 ativado.

Tenha em conta o seguinte:

• Não existe indisponibilidade para as cargas de trabalho do cluster de utilizadores durante a migração.
• Existe alguma indisponibilidade para o plano de controlo do cluster de utilizadores durante a migração. Especificamente, o plano de controlo fica indisponível entre a paragem do plano de controlo do Kubernetes do cluster kubeception e a conclusão da ligação dos nós do conjunto de nós do cluster kubeception ao novo plano de controlo. (Nos testes, este tempo de inatividade foi inferior a 7 minutos, mas a duração real depende da sua infraestrutura).
• No final da migração, os nós do plano de controlo do cluster de utilizadores dos clusters do Kubeception são eliminados. Se o cluster de administrador tiver network.ipMode.type definido como "static", pode reciclar alguns dos endereços IP estáticos não usados. Pode listar os objetos de nós do cluster de administrador com kubectl get nodes -o wide para ver que endereços IP estão em utilização. Para reciclar esses endereços IP, remova-os do ficheiro de configuração do cluster de administrador e execute gkectl update admin.
• No final da migração, os nós de trabalho passam por uma atualização contínua. Aguarde até que todos os nós fiquem prontos antes de continuar para os passos de pós-migração na secção seguinte.
• Após a migração, o endereço VIP do plano de controlo antigo continua a funcionar, mas é instável. Não confie nisso. Atualize todas as dependências da antiga morada de IP virtual para usar a nova morada de IP virtual assim que possível.

Após a migração

Após a conclusão da atualização, siga estes passos:

1. Verifique se o cluster de utilizadores está em execução:

   kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG
   

   O resultado é semelhante ao seguinte:

   cp-vm-1       Ready    control-plane,master   18m
   cp-vm-2       Ready    control-plane,master   18m
   cp-vm-3       Ready    control-plane,master   18m
   worker-vm-1   Ready                           6m7s
   worker-vm-2   Ready                           6m6s
   worker-vm-3   Ready                           6m14s
   

2. Se migrou para o plano de controlo V2, atualize as regras da firewall no cluster de administrador para remover os nós do plano de controlo do cluster de utilizadores do kubeception.

3. Se desativou a encriptação secreta sempre ativa, reative a funcionalidade.

   1. No ficheiro de configuração do cluster de utilizadores, remova o campo disabled: true.

   2. Atualize o cluster de utilizadores:

      gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
          --config USER_CLUSTER_CONFIG
      

4. Se desativou a autorreparação no cluster de administrador, volte a ativar a funcionalidade.

   1. No ficheiro de configuração do cluster de administrador, defina autoRepair.enabled como true.

   2. Atualize o cluster:

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

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.

Migração do MetalLB

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

kubectl --kubeconfig USER_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 do utilizador. Pode encontrar os nomes das VMs do Seesaw na secção vmnames do ficheiro seesaw-for-[USERCLUSTERNAME].yaml no diretório de configuração.

Migração do F5 BIG-IP

Após a migração para o balanceamento 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 CLUSTER_KUBECONFIG \
api-resources --verbs=list -o name | xargs -n 1 kubectl --kubeconfig
CLUSTER_KUBECONFIG get --show-kind --ignore-not-found
--selector=onprem.cluster.gke.io/legacy-f5-resource=true -A

O resultado esperado é semelhante ao seguinte:

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