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.

Planeje a migração de clusters para recursos recomendados

Visão geral

O Google Distributed Cloud é baseado no Kubernetes e em muitas outras tecnologias relacionadas, que são continuamente atualizadas e aprimoradas para oferecer melhor escalonabilidade, desempenho, segurança e recursos de integração. Por isso, o Google Distributed Cloud está sempre se adaptando e melhorando.

Na versão 1.30, as mudanças e atualizações chegaram a um ponto em que recomendamos enfaticamente que você migre as implantações legadas para aproveitar melhorias significativas. Esta página descreve os benefícios da migração de recursos desatualizados para os recursos recomendados mais recentes.

Você tem as seguintes opções para cada área de recurso:

Área do recurso	Opções recomendadas	Opções originais
Interface de rede de contêiner (CNI)	Dataplane V2 (`enableDataplaneV2: true`)	Dataplane V1 (Calico) (`enableDataplaneV2: false`)
Balanceador de carga	`ManualLB` (funciona com agentes F5 Big-IP) (`loadBalancer.kind: "ManualLB"`) MetalLB (`loadBalancer.kind: "MetalLB"`)	F5 Big-IP integrado¹ (`loadBalancer.kind: "F5BigIP"`) Seesaw (`loadBalancer.kind: "Seesaw"`)
Plano de controle do cluster do administrador	Cluster de administrador de alta disponibilidade (HA) (`adminMaster.replicas: 3`)	Cluster de administrador sem HA (`adminMaster.replicas: 1`)
Plano de controle do cluster de usuário	Plano de controle V2 (`enableControlplaneV2: true`)	Cluster de usuário do Kubeception (`enableControlplaneV2: false`)

^{1 F5 BIG-IP integrado se refere a loadBalancer.kind: "F5BigIP" e configurações relacionadas na seção loadBalancer.f5BigIP do arquivo de configuração do cluster.}

As tabelas a seguir mostram a matriz de suporte para esses recursos em clusters de administrador e de usuário:

Tipo de cluster	Recurso desatualizado	Adicionar para um novo cluster	Permitir upgrade do cluster	Migração para o novo recurso
Versão 1.30
Administrador	Sem alta disponibilidade	Não	Sim	Sim
	Seesaw	Não	Sim	Sim
	F5 Big-IP integrado	Não	Sim	Sim
Usuário	Kubeception	Não	Sim	Sim
	Seesaw	Não	Sim	Sim
	F5 Big-IP integrado	Não	Sim	Sim
	Dataplane V1	Não	Sim	Sim
Versão 1.29
Administrador	Sem alta disponibilidade	Não	Sim	Sim (Visualização)
	Seesaw	Não	Sim	Sim
	F5 Big-IP integrado	Sim	Sim	Sim (Visualização)
Usuário	Kubeception	Sim	Sim	Sim (Visualização)
	Seesaw	Sim	Sim	Sim
	F5 Big-IP integrado	Sim	Sim	Sim (Visualização)
	Dataplane V1	Sim	Sim	Não
Versão 1.28
Administrador	Sem alta disponibilidade	Não	Sim	Não
	Seesaw	Não	Sim	Sim
	F5 Big-IP integrado	Sim	Sim	Não
Usuário	Kubeception	Sim	Sim	Não
	Seesaw	Sim	Sim	Sim
	F5 Big-IP integrado	Sim	Sim	Não
	Dataplane V1	Sim	Sim	Não

Pontos principais:

A partir da versão 1.30, todas as soluções de migração estão disponíveis para migrar clusters para as alternativas recomendadas.
Ao criar novos clusters, estas são as versões em que os recursos originais não são permitidos:
- Clusters de administrador:
  - Plano de controle sem HA: 1.28 e mais recentes
  - Balanceamento de carga do Seesaw: 1.28 e mais recentes
  - F5 Big IP integrado: 1.30 e mais recentes
- Clusters de usuários:
  - Kubeception: 1.30 e versões mais recentes
  - Seesaw: 1.30 e versões mais recentes
  - F5 Big IP integrado: 1.30 e mais recentes
  - Dataplane V1: 1.30 e versões mais recentes
Você ainda pode fazer upgrade dos clusters com os recursos originais.

Migrar clusters de usuários para o Dataplane V2

É possível escolher uma interface de rede de contêiner (CNI) que ofereça recursos de rede de contêineres, como Calico ou Dataplane V2. O Dataplane V2, a implementação de CNI do Google, é baseado no Cilium e é usado no Google Kubernetes Engine (GKE) e no Google Distributed Cloud.

O Dataplane V2 oferece um design otimizado e uma utilização de recursos eficiente, resultando em melhor desempenho de rede e maior escalonabilidade, principalmente para clusters ou ambientes grandes com demandas de tráfego de rede elevadas. Recomendamos que você migre os clusters para o Dataplane V2 para ter acesso aos recursos mais recentes, inovações de rede e recursos.

A partir da versão 1.30, o Dataplane V2 é a única opção de CNI para criar novos clusters.

A transição do Calico para o Dataplane V2 requer planejamento e coordenação, mas foi projetada para não envolver tempo de inatividade para cargas de trabalho atuais. Ao migrar proativamente para o Dataplane V2, você pode aproveitar:

Melhoria no desempenho e na capacidade de escalonabilidade: o design otimizado do Dataplane V2 e a utilização eficiente de recursos podem melhorar o desempenho da rede e a capacidade de escalonamento, principalmente em clusters grandes ou ambientes com demandas de tráfego de rede altas. Isso ocorre devido ao uso de EBPF em vez de IPTables, o que permite que o cluster seja dimensionado usando mapas BPF.
Gerenciamento e suporte simplificados: a padronização do Dataplane V2 no Google Distributed Cloud e no GKE pode simplificar o gerenciamento e a solução de problemas do cluster, já que você pode contar com um conjunto consistente de ferramentas e documentação.
Recursos de rede avançados: EgressNAT e outros recursos de rede avançados têm suporte apenas no Dataplane V2. Todas as solicitações de rede futuras serão implementadas na camada do Dataplane V2.

	Antes da migração	Depois da migração
kube-proxy	Obrigatório e implantado automaticamente	Não obrigatório e não implantado
Roteamento	kube-proxy + iptables	eBPF

Migrar o tipo de balanceador de carga

Os tipos de balanceador de carga recomendados (loadBalancer.kind) são "ManualLB" e "MetalLB". Use "ManualLB" se você tiver um balanceador de carga de terceiros, como F5 BIG-IP ou Citrix. Use "MetalLB" para nossa solução de balanceamento de carga em pacote usando o balanceador de carga MetalLB.

A partir da versão 1.30, essas são as únicas opções para criar novos clusters. Para clusters que usam o F5 Big IP integrado ou o balanceador de carga do Seesaw em pacote, fornecemos guias de migração para migrar as configurações "F5BigIP" para "ManualLB" e migrar o balanceador de carga em pacote do Seesaw para o MetalLB.

Migrar as definições de configuração do balanceador de carga F5 BIG-IP

Planeje migrar todos os clusters que usam o F5 Big IP integrado para ManualLB. O F5 Big IP integrado usa o F5 BIG-IP com agentes de balanceador de carga, que consistem nos seguintes controladores:

Controlador F5 (pod prefix: load-balancer-f5): reconcilia os serviços do tipo LoadBalancer do Kubernetes no formato F5 Common Controller Core Library (CCCL, na sigla em inglês) ConfigMap.
F5 BIG-IP CIS Controller v1.14 (pod prefix: k8s-bigip-ctlr-deployment): converte ConfigMaps em configurações do balanceador de carga F5.

O F5 Big IP integrado original tem as seguintes limitações:

Expressividade limitada: o F5 Big IP integrado restringe o potencial total do F5 BIG-IP ao limitar a expressividade da API Service. Isso pode impedir que você configure o controlador BIG-IP para seus requisitos específicos ou aproveite os recursos avançados do F5 que podem ser essenciais para seu aplicativo.
Componente legado: a implementação atual depende de tecnologias mais antigas, como a API CCCL ConfigMap e o CIS 1.x. Esses componentes legados podem não ser compatíveis com os avanços mais recentes nas ofertas do F5, o que pode levar a oportunidades perdidas de melhorias de desempenho e de segurança.

As mudanças após a migração do F5 BIG-IP integrado para o ManualLB incluem:

	Antes da migração	Depois da migração
Componentes dos agentes do F5	Controlador F5 Controlador CIS do OSS	Controlador F5 (sem alteração) Controlador CIS do OSS (sem alteração)
Upgrade da versão do componente F5	É necessário fazer upgrade dos clusters para atualizar os componentes do F5. As versões disponíveis do componente são limitadas, conforme explicado anteriormente.	Você pode fazer upgrade das versões dos componentes do F5 conforme necessário.
Criação de serviços	Gerenciado por agentes do F5	Processado por agentes do F5 (sem alteração)

Migrar do Seesaw para o MetalLB

O MetalLB oferece as seguintes vantagens em comparação com o Seesaw:

Gerenciamento simplificado e recursos reduzidos: ao contrário do Seesaw, o MetalLB é executado diretamente nos nós do cluster, permitindo o uso dinâmico de recursos do cluster para balanceamento de carga.
Atribuição de IP automática: o controlador do MetalLB gerencia endereços IP para os Serviços, para que você não precise escolher manualmente um endereço IP para cada Serviço.
Distribuição de carga entre nós de LB: instâncias ativas do MetalLB para diferentes serviços podem ser executadas em nós diferentes.
Recursos aprimorados e proteção para o futuro: o desenvolvimento ativo do MetalLB e a integração com o ecossistema mais amplo do Kubernetes o tornam uma solução mais protegida para o futuro em comparação com o Seesaw. O uso do MetalLB garante que você possa aproveitar os avanços mais recentes na tecnologia de balanceamento de carga.

	Antes da migração	Depois da migração
Nós de LB	VMs extras do Seesaw (fora do cluster)	Nós de LB no cluster com escolhas do cliente
Preservação do IP do cliente	Pode ser feito por meio de `externalTrafficPolicy: Local`	Pode ser alcançado pelo modo DSR do DataplaneV2
Criação de serviços	IP do serviço especificado manualmente	IP do serviço atribuído automaticamente do pool de endereços

Migrar clusters de usuário para o Controlplane V2 e clusters de administrador para HA

O plano de controle recomendado para clusters de usuário é o Controlplane V2. Com o Controlplane V2, o plano de controle é executado em um ou mais nós no cluster do próprio usuário. Com o plano de controle legado, chamado de kubeception, o plano de controle de um cluster de usuário é executado em um cluster de administrador. Para criar um cluster de administrador de alta disponibilidade (HA), seus clusters de usuário precisam ter o Controlplane V2 ativado.

A partir da versão 1.30, novos clusters de usuário precisam ter o Controlplane V2 ativado, e novos clusters de administrador serão de alta disponibilidade. Os upgrades de clusters de usuário com o plano de controle legado ainda são aceitos, assim como upgrades de clusters de administrador não HA.

Migrar clusters de usuários para o Controlplane V2

Historicamente, os clusters de usuários usavam o kubeception. A versão 1.13 introduziu o Controlplane V2 como um recurso em fase de pré-lançamento, que fez a transição para a disponibilidade geral na versão 1.14. Desde a versão 1.15, o Controlplane V2 é a opção padrão para criar clusters de usuário, e é a única opção na versão 1.30.

Em comparação com o kubeception, os benefícios do Controlplane V2 incluem:

Consistência da arquitetura: os clusters de administrador e de usuário usam a mesma arquitetura.
Isolamento de falhas: uma falha no cluster de administrador não afeta os clusters de usuário.
Separação operacional: um upgrade do cluster de administrador não causa inatividade para clusters de usuário.
Separação de implantação: é possível colocar os clusters de administrador e de usuário em diferentes domínios de topologia ou em vários locais. Por exemplo, em um modelo de implantação de computação de borda, um cluster de usuário pode estar em um local diferente do cluster de administrador.

Durante a migração, não há tempo de inatividade para as cargas de trabalho do cluster de usuário. Dependendo do ambiente vSphere, o plano de controle passará por um tempo mínimo de inatividade durante a troca para o Controlplane V2. O processo de migração faz o seguinte:

Cria um novo plano de controle no cluster de usuário.
Copia os dados do etcd do plano de controle antigo.
Faz a transição dos nós do pool de nós (também chamados de nós de trabalho) para o novo plano de controle.

	Antes da migração	Depois da migração
Objetos de nó do Kubernetes do plano de controle	Nó do cluster de administrador	Nó do cluster de usuário
Pods do plano de controle do Kubernetes	Statefulsets/implantações de cluster de administrador (namespace do cluster de usuário)	Pods estáticos do cluster de usuários (namespace kube-system)
Outros pods do plano de controle	Statefulsets/implantações de cluster de administrador (namespace do cluster de usuário)	Statefulsets/implantações de cluster de usuário (namespace kube-system)
VIP do plano de controle	Serviço de balanceador de carga do cluster de administrador	keepalived + haproxy (pods estáticos do cluster de usuários)
Dados do etcd	Volume permanente do cluster de administrador	Disco de dados
Gerenciamento de IP de máquina do plano de controle	IPAM ou DHCP	IPAM
Rede do plano de controle	VLAN do cluster de administrador	VLAN do cluster de usuário

Migrar para um cluster de administrador de HA

Historicamente, o cluster de administrador só podia executar um único nó do plano de controle, criando um risco inerente de um único ponto de falha. Além do nó do plano de controle, os clusters de administrador que não são de alta disponibilidade também têm dois nós de complemento. Um cluster de administrador de HA tem três nós do plano de controle sem nós de complemento. Portanto, o número de VMs que um novo cluster de administrador exige não mudou, mas a disponibilidade melhorou significativamente. A partir da versão 1.16, é possível usar um cluster de administrador de alta disponibilidade (HA, na sigla em inglês), que se tornou a única opção para a criação de novos clusters na versão 1.28.

A migração para um cluster de administrador de HA oferece os seguintes benefícios:

Confiabilidade e tempo de atividade aprimorados: a configuração de HA elimina o ponto único de falha, permitindo que o cluster de administrador continue operacional mesmo que um dos nós do plano de controle apresente um problema.
Experiência aprimorada de upgrade e atualização: todas as etapas necessárias para fazer upgrade e atualizar um cluster de administrador agora são executadas no cluster, em vez de em uma VM de administrador separada. Isso garante que os upgrades e as atualizações continuem mesmo que a sessão inicial para a VM de administrador seja interrompida.
Fonte confiável de verdade para estados de cluster: os clusters de administrador que não são de alta disponibilidade dependem de um "arquivo de ponto de controle" fora da banda para armazenar o estado do cluster de administrador. Por outro lado, o cluster de administrador de HA armazena o estado atualizado do cluster no próprio cluster de administrador, fornecendo uma fonte de verdade mais confiável para o estado do cluster.

Você pode migrar seu cluster de administrador não HA para um cluster de administrador HA, o que não envolve tempo de inatividade para as cargas de trabalho do usuário. O processo causa um tempo de inatividade mínimo e interrupções nos clusters de usuários existentes, principalmente associados à mudança de plano de controle. O processo de migração faz o seguinte:

Cria um novo plano de controle de HA.
Restaura os dados do etcd do cluster que não é de alta disponibilidade.
Faz a transição dos clusters de usuário para o novo cluster de administrador HA.

	Antes da migração	Depois da migração
Réplicas de nós do plano de controle	1	3
Nós de complemento	2	0
Tamanho do disco de dados	100GB * 1	25GB * 3
Caminho dos discos de dados	Definido por vCenter.dataDisk no arquivo de configuração do cluster de administrador	Gerado automaticamente no diretório: `/anthos/[ADMIN_CLUSTER_NAME]/default/[MACHINE_NAME]-data.vmdk`
VIP do plano de controle	Definido por loadBalancer.kind no arquivo de configuração do cluster de administrador	keepalived + haproxy
Alocação de endereços IP para nós do plano de controle do cluster de administrador	DHCP ou estático, dependendo de network.ipMode.type	3 endereços IP estáticos

Migrações de balanceadores de carga e planos de controle em grupo

Normalmente, ao atualizar clusters, recomendamos que você atualize apenas um recurso ou configuração por vez. Na versão 1.30 e mais recentes, no entanto, é possível agrupar as mudanças de configuração para a migração do balanceador de carga e do plano de controle. Em seguida, atualize o cluster uma única vez para fazer as duas mudanças.

Se você tiver clusters de usuários usando uma CNI antiga, primeiro será necessário migrar para o DataPlane V2. Depois disso, você pode agrupar a migração para o balanceador de carga e o plano de controle. O agrupamento da migração oferece os seguintes benefícios:

Um processo mais simples: se você precisar migrar um plano de controle e um balanceador de carga, normalmente só será necessário atualizar o cluster uma vez. E você não precisa decidir quais recursos precisa migrar primeiro.
Reduzir o tempo de inatividade geral: algumas migrações envolvem tempo de inatividade do plano de controle. Portanto, agrupar essas migrações em uma operação de atualização reduz o tempo de inatividade geral em comparação com atualizações individuais sequenciais.

O processo varia de acordo com as configurações do cluster. No geral, realize a migração de cada cluster na seguinte ordem:

Migre cada cluster de usuário para usar o CNI recomendado, o Dataplane V2.
1. Faça as mudanças de configuração e atualize o cluster de usuário para acionar uma migração do cluster de usuário do Calico para o Dataplane V2.
  
  Observação: esta etapa não é necessária para o cluster de administrador. Quando você faz upgrade do cluster de administrador para a versão 1.30, ele é migrado automaticamente para o Dataplane V2.
Migrar cada cluster de usuário para usar o balanceador de carga e o Controle V2 recomendados.
1. Faça mudanças na configuração para usar o balanceador de carga recomendado (MetalLB ou ManualLB).
2. Faça mudanças na configuração para ativar o Controlplane V2.
3. Atualize o cluster de usuário para migrar o balanceador de carga e o plano de controle.
Migre o cluster de administrador para usar o balanceador de carga recomendado e tornar o plano de controle altamente disponível.
1. Faça mudanças na configuração para usar o balanceador de carga recomendado (MetalLB ou ManualLB).
2. Faça mudanças de configuração para migrar o plano de controle do cluster de administrador de não HA para HA.
3. Atualize o cluster de administrador para migrar o balanceador de carga e o plano de controle.
Realize etapas de limpeza opcionais, como limpar a VM do plano de controle não HA.

Se o cluster de administrador e todos os clusters de usuário estiverem na versão 1.30 ou mais recente, use o processo de migração de grupo. Para conferir as etapas detalhadas, consulte: