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.

Migrar um cluster de usuário para recursos recomendados

Visão geral

Nesta página, mostramos como migrar clusters de usuários da versão 1.30 ou mais recente para os recursos recomendados a seguir:

Migrar para o Dataplane V2 como a interface de rede de contêineres (CNI).
Migrar clusters de usuários usando o kubeception para o Controlplane V2.
Migrar 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 em pacote para o MetalLB.

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 os papéis comuns e as tarefas de exemplo referenciados no conteúdo do Google Cloud, consulte Funções e tarefas de usuário comuns do GKE Enterprise.

Práticas recomendadas

Recomendamos que você migre 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.

Recomendamos que você crie um novo cluster de usuário com o Controlplane V2 ativado para saber mais sobre as diferenças de arquitetura com clusters kubeception. O novo cluster não afeta suas cargas de trabalho. No entanto, no pior cenário, se a migração falhar, você terá um cluster pronto para suas cargas de trabalho.

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

Requisitos

Para essa migração:

O cluster de usuário precisa estar na versão 1.30 ou mais recente.
Todos os pools de nós precisam ter a mesma versão do cluster de usuário.
Se o cluster estiver usando o balanceador de carga Seesaw, verifique se você não está dependendo dele para a preservação do IP do cliente, conforme descrito na próxima seção.

Preservação do IP do cliente do Seesaw

Para verificar o externalTrafficPolicy, execute o seguinte comando:

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

Se você tiver esse problema, entre em contato com o Suporte do Google.

Estime o compromisso de tempo e planeje uma janela de manutenção

Por padrão, quando você atualiza o cluster, todos os pools de nós são atualizados em paralelo. No entanto, dentro de cada pool de nós, os nós são atualizados sequencialmente. Portanto, o tempo total de atualização depende do número de nós no maior pool de nós. Para calcular uma estimativa aproximada para cada atualização:

Se você estiver migrando do Seesaw para o MetalLB, estime 15 minutos para a atualização escolher um pool de nós para o balanceador de carga do MetalLB. Para essa atualização, apenas o pool de nós selecionado é atualizado.
Para qualquer outra atualização no processo de migração, multiplique 15 minutos pelo número de nós no pool de nós.

Para estimar o tempo necessário, conte o número de vezes que você precisa atualizar o cluster. As etapas gerais a seguir mostram quando você precisa executar gkectl update cluster para atualizar o cluster:

Se o cluster de usuário usar a criptografia de secrets sempre ativada, desative o recurso e execute gkectl update cluster.
Se o cluster de usuário tiver enableDataplaneV2 desativado ou definido como false, faça as mudanças de configuração e execute gkectl update cluster para migrar para o Dataplane V2.
Prepare-se para a migração do balanceador de carga e do plano de controle:
1. Se o cluster de administrador tiver o reparo automático ativado, desative-o. Depois execute gkectl update admin. Essa atualização é concluída rapidamente porque não recria os nós do cluster de administrador.
2. Se o cluster de usuários usar o Seesaw, escolha um pool de nós para o balanceador de carga MetalLB e execute gkectl update cluster. Essa atualização só atualiza os nós no pool de nós selecionado.
Faça todas as mudanças de configuração necessárias para atualizar o balanceador de carga e migrar para o Controlplane V2. Depois execute gkectl update cluster.
Após a migração, se você tiver desativado a criptografia de secrets sempre ativada, ative o recurso novamente e execute gkectl update cluster.

O tempo total da migração depende de quantas vezes você precisa executar gkectl cluster update, que depende da sua configuração. Por exemplo, suponha que você esteja migrando para o Dataplane V2, o ControlPlane V2 e o MetalLB. Suponha também que há 10 nós no maior pool de nós e 3 no pool 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 pool = 150 minutos.
45 minutos para o pool de nós usado pelo MetalLB, porque 15 minutos * 3 nós nesse pool = 45 minutos.
150 minutos para a atualização do Controlplane V2 e do MetalLB, porque 15 minutos * 10 nós no maior pool = 150 minutos.

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

Se necessário, você pode fazer a migração em etapas. Usando o exemplo anterior, você pode fazer a migração para o Dataplane V2 em uma janela de manutenção e o restante da migração em uma ou duas janelas de manutenção.

Planejar o tempo de inatividade durante a migração

Ao planejar a migração, considere estes tipos de inatividade:

Tempo de inatividade do plano de controle: o acesso ao servidor da API Kubernetes é afetado durante a migração. Se você estiver migrando para o Controlplane V2, haverá um período de inatividade do plano de controle para clusters de usuário kubeception, já que o loadBalancer.vips.controlPlaneVIP está sendo migrado. O tempo de inatividade geralmente é inferior a 10 minutos, mas a duração depende da sua infraestrutura.
Tempo de inatividade do workload: os IPs virtuais (VIPs) usados por Serviços do tipo: LoadBalancer estão indisponíveis. Isso só ocorre durante uma migração do Seesaw para o MetalLB. O processo de migração do MetalLB vai interromper as conexões de rede com todos os VIPs no cluster de usuário para Serviços do Kubernetes do tipo LoadBalancer por cerca de dois a dez minutos. Depois que a migração for concluída, as conexões vão voltar a funcionar.

A tabela a seguir descreve o impacto da migração:

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

Para garantir uma migração bem-sucedida, siga as etapas nas seções a seguir.

Alocar novos endereços IP

Se você estiver migrando para o ControlPlane V2, aloque novos endereços IP estáticos na mesma VLAN dos nós de trabalho (os nós nos pools de nós).

Você precisa de um endereço IP para o loadBalancer.vips.controlPlaneVIP.
Aloque um endereço IP para cada nó do plano de controle. O número de endereços IP que você precisa alocar depende se o cluster de usuário será de alta disponibilidade (HA) ou não.
- Sem HA: um endereço IP
- HA: três endereços IP

Atualizar regras de firewall

Se você estiver migrando para o Controlplane V2, atualize as regras de firewall nos clusters de usuário. Verifique se os endereços IP recém-alocados para os nós do plano de controle no cluster de usuário podem acessar todas as APIs e outros destinos necessários, conforme descrito em Regras de firewall para nós do cluster de usuário.

Verificar as versões do cluster e do pool de nós

Verifique se todos os pools de nós usam a mesma versão do cluster de usuário, que precisa ser a versão 1.30 ou mais recente. Caso contrário, faça upgrade dos pools de nós para a gkeOnPremVersion no arquivo de configuração do cluster de usuário 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 arquivo kubeconfig do cluster de usuário.

Verificar a integridade do cluster

Verifique a integridade do cluster e corrija os problemas relatados pelo comando gkectl diagnose cluster:

gkectl diagnose cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --cluster-name <var>USER_CLUSTER_NAME</var>

Substitua:

ADMIN_CLUSTER_KUBECONFIG: o caminho do arquivo kubeconfig do cluster de administrador.
USER_CLUSTER_NAME: o nome do cluster do usuário.

Desativar o reparo automático no cluster de administrador

Se você estiver migrando o cluster de usuário para usar o Controlplane V2 e o reparo automático estiver ativado no cluster de administrador, desative o reparo automático. Verifique o campo autoRepair.enabled do arquivo de configuração do cluster de administrador. Se esse campo não estiver definido ou estiver definido como true, siga estas etapas:

No arquivo de configuração do cluster de administrador, defina autoRepair.enabled como false. Por exemplo:
```
autoRepair:
  enabled: true
```

Atualize o cluster de administrador:

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

Substitua:

ADMIN_CLUSTER_KUBECONFIG: o caminho até o arquivo kubeconfig do cluster de administrador.
ADMIN_CLUSTER_CONFIG: o caminho até o arquivo de configuração do cluster de administrador.

Depois que a migração for concluída, ative novamente o reparo automático no cluster de administrador.

Verificar se há um problema com a criptografia de secrets sempre ativada

Se você estiver migrando o cluster de usuário para usar o Controlplane V2, verifique se há um problema com a criptografia de segredos sempre ativada.

Se a criptografia de secrets sempre ativada tiver sido ativada no cluster de usuários, siga as etapas em Desativar a criptografia de secrets sempre ativada e descriptografar secrets antes de iniciar a migração. Caso contrário, o novo cluster do Controlplane V2 não conseguirá descriptografar segredos.

Antes de iniciar a migração, execute o comando abaixo para saber se a criptografia de secrets sempre ativa 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 a saída do comando anterior estiver vazia, a criptografia de secrets sempre ativada nunca foi ativada. Você pode iniciar a migração.

Se a saída do comando anterior não estiver vazia, a criptografia de secrets sempre ativada foi ativada anteriormente. Antes de migrar, siga as etapas na próxima seção para garantir que o novo cluster do Controlplane V2 possa descriptografar secrets.

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

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

Desativar a criptografia de secrets sempre ativada e descriptografar secrets, se necessário

Para desativar a criptografia de secrets sempre ativada e descriptografar secrets, siga estas etapas:

No arquivo de configuração do cluster de usuário, para desativar a criptografia de segredos sempre ativa, adicione um campo disabled: true à seção secretsEncryption:
```
secretsEncryption:
    mode: GeneratedKey
    generatedKey:
        keyVersion: KEY_VERSION
        disabled: true
```
Atualize o cluster:
```
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG
```
Substitua:
- ADMIN_CLUSTER_KUBECONFIG: o caminho do arquivo kubeconfig do cluster de administrador
- USER_CLUSTER_CONFIG: é o caminho do arquivo de configuração do cluster de usuário

Faça uma atualização gradual em um DaemonSet específico, da seguinte maneira:

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

Receba os manifestos de todos os segredos no cluster de usuários no formato YAML:

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

Para que todos os secrets sejam armazenados no etcd como texto simples, reaplique todos os secrets no cluster de usuários:
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG \
  apply -f SECRETS_MANIFEST.yaml
```
Agora você pode iniciar a migração para o Controlplane V2. Depois que a migração for concluída, você poderá reativar a criptografia de secrets sempre ativada no cluster.

Ativar um pool de nós para uso pelo MetalLB

Se você estiver migrando do balanceador de carga do Seesaw em pacote para o MetalLB, siga as etapas desta seção. O cluster está usando o Seesaw se loadBalancer.kind: Seesaw estiver no arquivo de configuração do cluster de usuário. Se você estiver migrando a configuração integrada do F5 BIG-IP, pule para a próxima seção, Migrar para o Dataplane V2.

Escolha um pool de nós e ative-o para uso com o MetalLB. A migração implanta o MetalLB nos nós desse pool de nós.

Na seção nodePools do arquivo de configuração do cluster de usuário, escolha um pool de nós ou adicione um novo, e defina enableLoadBalancer como true. Por exemplo:
```
nodePools:
  - name: pool-1
    replicas: 3
    enableLoadBalancer: true
```

Atualize o cluster:

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

Para mais informações sobre o MetalLB, consulte Balanceamento de carga em pacote com o MetalLB.

Migrar para o Dataplane V2

Antes de migrar, 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, pule para a próxima seção, Prepare-se para a migração do balanceador de carga.

Para migrar para o Dataplane V2, siga estas etapas. Se você tiver dúvidas sobre como remover temporariamente a especificação NetworkPolicy, entre em contato com o Suporte do Google.

Se o cluster estiver usando um NetworkPolicy, remova temporariamente a especificação dele do cluster, conforme mostrado abaixo:

Verifique se há algum NetworkPolicy não do sistema aplicado ao cluster:

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

Se a saída da etapa anterior não estiver vazia, salve cada especificação NetworkPolicy em um arquivo:
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get networkpolicy NETWORK_POLICY_NAME -n NETWORK_POLICY_NAMESPACE -o yaml > NETWORK_POLICY_NAME.yaml
```
Substitua:
- NETWORK_POLICY_NAME: o nome do NetworkPolicy que você está salvando.
- NETWORK_POLICY_NAMESPACE: o namespace do NetworkPolicy.

Exclua o NetworkPolicy usando o seguinte comando:

kubectl --kubeconfig USER_CLUSTER_KUBECONFIG delete networkpolicy NETWORK_POLICY_NAME -n NETWORK_POLICY_NAMESPACE

Migre para o Dataplane V2 seguindo estas etapas:

Defina enableDataplaneV2 como true no arquivo de configuração do cluster de usuário.

Para ativar o DataPlane V2, atualize o cluster:

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

Se você removeu especificações NetworkPolicy que não são do sistema em uma etapa anterior, replique-as após a conclusão da atualização com este comando:
```
kubectl --kubeconfig USER_CLUSTER_KUBECONFIG apply -f NETWORK_POLICY_NAME.yaml
```

Depois de concluir essas etapas, o Dataplane V2 será ativado. Em seguida, prepare-se para migrar seu cluster para o balanceador de carga recomendado e o Control Plane V2.

Preparar para a migração do balanceador de carga

Se os clusters de usuários estiverem usando o balanceador de carga Seesaw ou o F5 BIG-IP integrado, siga as etapas desta seção para fazer as mudanças necessárias no arquivo de configuração do cluster de usuários. Caso contrário, pule para a próxima seção, Prepare-se para a migração para o Controlplane V2.

F5 BIG-IP

Se os clusters usarem a configuração integrada do F5 BIG-IP, prepare-se para a migração para ManualLB fazendo as seguintes alterações no arquivo de configuração do cluster de usuário:

Altere loadBalancer.kind para "ManualLB".
Mantenha o mesmo valor para o campo loadBalancer.vips.ingressVIP.
Se você estiver migrando para o Control Plane V2, mude o valor do campo loadBalancer.vips.controlPlaneVIP para o endereço IP que você alocou Caso contrário, você pode manter o mesmo valor.
Exclua toda a seção loadBalancer.f5BigIP.

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

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 clusters de usuários usarem o balanceador de carga Seesaw, prepare-se para a migração para o MetalLB seguindo as etapas nas seções a seguir.

Especificar pools de endereços

O controlador MetalLB gerencia endereços IP para os Serviços. Portanto, quando um desenvolvedor de aplicativos cria um Serviço do tipo LoadBalancer em um cluster de usuário, não é necessário especificar manualmente um endereço IP para o Serviço. Em vez disso, o controlador MetalLB escolhe um endereço IP de um pool de endereços especificado.

Considere o número máximo de serviços LoadBalancer que provavelmente estarão ativos no cluster de usuários. Em seguida, na seção loadBalancer.metalLB.addressPools do arquivo de configuração do cluster de usuário, especifique endereços IP suficientes para acomodar esses Serviços.

Ao especificar pools de endereços, inclua o VIP de entrada do cluster de usuários em um dos pools. Isso ocorre porque o proxy de entrada é exposto por um Serviço do tipo LoadBalancer.

Os endereços precisam estar no formato CIDR ou de intervalo. Se você quiser especificar um endereço individual, use um CIDR /32, como 198.51.100.10/32.

Atualizar o arquivo de configuração do cluster

Atualize o arquivo de configuração do cluster para remover a seção Seesaw e adicionar uma seção MetalLB, conforme mostrado abaixo:

Defina loadBalancer.kind como "MetalLB".
Você pode manter o mesmo valor para o campo loadBalancer.vips.ingressVIP.
Adicione o VIP de entrada a um pool de endereços do MetalLB.
Se você estiver migrando para o Control Plane V2, mude o valor do campo loadBalancer.vips.controlPlaneVIP para o endereço IP que você alocou Caso contrário, você pode manter o mesmo valor.
Remova a seção loadBalancer.seesaw.
Adicione uma seção loadBalancer.metalLB.

A parte a seguir de um arquivo de configuração de cluster de usuário mostra essas mudanças e a configuração do MetalLB de:

Um pool de endereços para o controlador do MetalLB escolher e atribuir a serviços do tipo LoadBalancer. O VIP de entrada, que neste exemplo é 198.51.100.10, está neste pool na notação de formato de intervalo, 198.51.100.10/32.
O VIP designado para o servidor da API Kubernetes do cluster de usuário.
O VIP de entrada que você configurou para o proxy de entrada.
Um pool de nós ativado para usar MetalLB. A migração implanta o MetalLB nos nós desse pool de nós.

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"
      enableLoadBalancer: true
      addresses:
      - "198.51.100.10/32"
      - "198.51.100.80 - 198.51.100.89"

Preparar-se para a migração para o Control Plane V2

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

Atualize o arquivo de configuração do cluster de usuário.
Se o cluster estiver usando o balanceamento de carga manual (loadBalancer.kind: "ManualLB"), atualize também a configuração no balanceador de carga.

Essas opções são descritas nas seções a seguir.

Se o cluster já tiver o Controlplane V2 ativado, pule para a seção Migrar o cluster de usuário.

Atualizar o arquivo de configuração do cluster de usuário

Faça as seguintes alterações no arquivo de configuração do cluster de usuário atual:

Defina enableControlplaneV2 como verdadeiro.
Opcionalmente, torne o plano de controle do cluster de usuário do Controlplane V2 altamente disponível (HA). Para mudar de um cluster sem HA para um cluster HA, mude masterNode.replicas de 1 para 3.
Adicione o endereço IP estático (ou os endereços) para os nós do plano de controle do cluster de usuário à seção network.controlPlaneIPBlock.ips. O endereço IP (ou endereços) dos nós do plano de controle precisa estar na mesma VLAN que os nós de trabalho.
Preencha netmask e gateway na seção network.controlPlaneIPBlock.
Se a seção network.hostConfig estiver vazia, preencha-a.
Verifique se o campo loadBalancer.vips.controlPlaneVIP tem o novo endereço IP para o VIP do plano de controle. O endereço IP precisa estar na mesma VLAN dos IPs do nó do plano de controle.
Se o cluster de usuário usar o balanceamento de carga manual, defina loadBalancer.manualLB.controlPlaneNodePort e loadBalancer.manualLB.konnectivityServerNodePort como 0. Elas não são necessárias quando o ControlPlane V2 está ativado, mas precisam ter 0 como valor.
Se o cluster de usuário usar o balanceamento de carga manual, configure o balanceador de carga conforme descrito na próxima seção.

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

Se o cluster de usuário já estiver usando o balanceamento de carga manual, será necessário configurar alguns mapeamentos no balanceador de carga. Se você estiver migrando da configuração integrada do F5 BIG-IP para o balanceamento de carga manual, não será necessário fazer mudanças de configuração no balanceador de carga. Pule para a próxima seção, Migrar o cluster de usuários.

Para cada endereço IP especificado na seção network.controlPlaneIPBlock, configure os seguintes mapeamentos no balanceador de carga para os nós do plano de controle:

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

Esses mapeamentos são necessários para todos os nós no cluster de usuário, tanto nós do plano de controle quanto nós de worker. Como os NodePorts sã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 vai detectar o tráfego no endereço IP que você configurou para o VIP de entrada do cluster de usuários nas portas HTTP e HTTPS padrão. O balanceador de carga encaminha solicitações para qualquer nó no cluster. Depois que uma solicitação é roteada para um dos nós do cluster, a rede interna do Kubernetes encaminha a solicitação para o pod de destino.

Migrar o cluster de usuário

Primeiro, revise cuidadosamente todas as mudanças feitas no arquivo de configuração do cluster de usuário. Todas as configurações do balanceador de carga e do Controlplane V2 são imutáveis, exceto quando você está atualizando 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 Controlplane V2

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

Cria o plano de controle de um novo cluster com o ControlPlane V2 ativado.
Interrompe o plano de controle do Kubernetes do cluster kubeception.
Tira um snapshot do etcd do cluster kubeception.
Desliga os nós do plano de controle do cluster de usuário do cluster kubeception. Até a conclusão da migração, os nós não são excluídos, o que permite a recuperação de falhas voltando para o cluster kubeception.
Restaura os dados do cluster no novo plano de controle usando o snapshot do etcd criado em uma etapa anterior.
Conecta os nós do nodepool do cluster kubeception ao novo plano de controle, que pode ser acessado com o novo controlPlaneVIP.
Reconcilia o cluster de usuário restaurado para atender ao estado final do cluster com o ControlPlane V2 ativado.

Observe o seguinte:

Não há tempo de inatividade para as cargas de trabalho do cluster de usuários durante a migração.
Há algum tempo de inatividade do plano de controle do cluster de usuário durante a migração. Especificamente, o plano de controle fica indisponível entre a interrupção do plano de controle do Kubernetes do cluster kubeception e a conclusão da conexão dos nós do nodepool do cluster kubeception ao novo plano de controle. Nos testes, esse tempo de inatividade foi de menos de 7 minutos, mas a duração real depende da sua infraestrutura.
Ao final da migração, os nós do plano de controle do cluster de usuário dos clusters kubeception são excluídos. Se o cluster de administrador tiver network.ipMode.type definido como "static", você poderá reciclar alguns dos endereços IP estáticos não usados. É possível listar os objetos de nó do cluster de administrador com kubectl get nodes -o wide para saber quais endereços IP estão em uso. Para reciclar esses endereços IP, remova-os do arquivo de configuração do cluster de administrador e execute gkectl update admin.

Após a migração

Depois que a atualização for concluída, siga estas etapas:

Verifique se o cluster de usuário está em execução:

kubectl get nodes --kubeconfig var>USER_CLUSTER_KUBECONFIG

O resultado será assim:

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

Se você migrou para o Controlplane V2, atualize as regras de firewall no cluster de administrador para remover os nós do plano de controle do cluster de usuário kubeception.
Se você desativou a criptografia de secrets sempre ativada, ative o recurso novamente.
1. No arquivo de configuração do cluster de usuário, remova o campo disabled: true.
2. Atualize o cluster de usuário:
```
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config USER_CLUSTER_CONFIG
```
Se você desativou o reparo automático no cluster de administrador, reative o recurso.
1. No arquivo 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 você migrou o balanceador de carga, verifique se os componentes do balanceador de carga estão em execução.

Migração do MetalLB

Se você migrou para o MetalLB, verifique se os componentes do MetalLB estão sendo executados corretamente:

kubectl --kubeconfig USER_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 usuário. É possível encontrar os nomes de VMs do Seesaw na seção vmnames do arquivo 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 seus clusters não é interrompido. Isso ocorre porque os recursos F5 ainda existem, como pode ser visto ao executar 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

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