Vista geral
O Google Distributed Cloud baseia-se no Kubernetes e em muitas outras tecnologias relacionadas, que são atualizadas e melhoradas continuamente para oferecer melhores capacidades de escalabilidade, desempenho, segurança e integração. Como tal, o Google Distributed Cloud está constantemente a adaptar-se e a melhorar.
Na versão 1.30, as alterações e as atualizações atingiram um ponto em que recomendamos vivamente que migre as implementações antigas para tirar partido das melhorias significativas. Esta página descreve as vantagens da migração de funcionalidades desatualizadas para as funcionalidades recomendadas mais recentes.
Tem as seguintes opções para cada área de funcionalidades:
| Área de funcionalidades | Opções recomendadas | Opções originais |
|---|---|---|
| Interface de rede de contentores (CNI) |
|
|
| Balanceador de carga |
|
|
| Plano de controlo do cluster de administrador |
|
|
| Plano de controlo do cluster de utilizadores |
|
|
1 O F5 BIG-IP integrado refere-se a
loadBalancer.kind: "F5BigIP" e às definições relacionadas na secção
loadBalancer.f5BigIP no ficheiro de configuração do cluster.
As tabelas seguintes mostram a matriz de suporte para estas funcionalidades nos clusters de administrador e de utilizador:
| Tipo de cluster | Funcionalidade desatualizada | Adicionar para novo cluster | Permitir atualização do cluster | Migração para a nova funcionalidade |
|---|---|---|---|---|
| Versão 1.32 e superior | ||||
| Administrador | Não HA | Não | Não | N/A |
| Seesaw | Não | Não | N/A | |
| F5 Big IP integrado | Não | Não | N/A | |
| Utilizador | Kubeception | Não | Não | N/A |
| Seesaw | Não | Não | N/A | |
| F5 Big IP integrado | Não | Não | N/A | |
| Dataplane V1 | Não | Não | N/A | |
| Versões 1.30 e 1.31 | ||||
| Administrador | Não HA | Não | Yes | Yes |
| Seesaw | Não | Yes | Yes | |
| F5 Big IP integrado | Não | Yes | Yes | |
| Utilizador | Kubeception | Não | Yes | Yes |
| Seesaw | Não | Yes | Yes | |
| F5 Big IP integrado | Não | Yes | Yes | |
| Dataplane V1 | Não | Yes | Yes | |
| Versão 1.29 | ||||
| Administrador | Não HA | Não | Yes | Sim (Pré-visualizar) |
| Seesaw | Não | Yes | Yes | |
| F5 Big IP integrado | Yes | Yes | Sim (Pré-visualizar) | |
| Utilizador | Kubeception | Yes | Yes | Sim (Pré-visualizar) |
| Seesaw | Yes | Yes | Yes | |
| F5 Big IP integrado | Yes | Yes | Sim (Pré-visualizar) | |
| Dataplane V1 | Yes | Yes | Não | |
| Versão 1.28 | ||||
| Administrador | Não HA | Não | Yes | Não |
| Seesaw | Não | Yes | Yes | |
| F5 Big IP integrado | Yes | Yes | Não | |
| Utilizador | Kubeception | Yes | Yes | Não |
| Seesaw | Yes | Yes | Yes | |
| F5 Big IP integrado | Yes | Yes | Não | |
| Dataplane V1 | Yes | Yes | Não | |
Pontos-chave:
- A partir da versão 1.30, todas as soluções de migração estão disponíveis para migrar clusters para as respetivas alternativas recomendadas.
Ao criar novos clusters, seguem-se as versões em que não são permitidas funcionalidades originais:
Clusters de administração:
- Plano de controlo sem HA: 1.28 e superior
- Balanceamento de carga de gangorra: 1.28 e superior
- F5 Big IP integrado: 1.30 e superior
Clusters de utilizadores:
- Kubeception: 1.30 e superior
- Seesaw: 1.30 e superior
- F5 Big IP integrado: 1.30 e superior
- Dataplane V1: 1.30 e superior
Continua a poder atualizar clusters existentes com as funcionalidades originais.
Migre clusters de utilizadores para o Dataplane V2
Pode escolher uma interface de rede de contentores (CNI) que ofereça funcionalidades de rede de contentores, Calico ou Dataplane V2. O Dataplane V2, a implementação da CNI da Google, baseia-se no Cilium e é usado no Google Kubernetes Engine (GKE) e no Google Distributed Cloud.
O plano de dados V2 oferece um design otimizado e uma utilização eficiente dos recursos, o que resulta num melhor desempenho da rede e numa melhor escalabilidade, particularmente para clusters grandes ou ambientes com elevadas exigências de tráfego de rede. Recomendamos vivamente que migre os clusters para o Dataplane V2 para aceder às funcionalidades mais recentes, às inovações de rede e às capacidades.
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 planeamento e coordenação, mas foi concebida para não envolver tempo de inatividade para as cargas de trabalho existentes. Ao migrar proativamente para o Dataplane V2, pode beneficiar do seguinte:
Desempenho e escalabilidade melhorados: o design otimizado e a utilização eficiente de recursos do Dataplane V2 podem levar a um melhor desempenho da rede e a uma melhor escalabilidade, especialmente em grandes clusters ou ambientes com elevadas exigências de tráfego de rede. Isto deve-se à utilização de EBPF em vez de IPTables, o que permite que o cluster seja dimensionado através de mapas BPF.
Gestão e apoio técnico simplificados: a padronização no Dataplane V2 em todo o Google Distributed Cloud e o GKE pode simplificar a gestão e a resolução de problemas de clusters, uma vez que pode confiar num conjunto consistente de ferramentas e documentação.
Funcionalidades de rede avançadas: EgressNAT e outras funcionalidades de rede avançadas só são suportadas no Dataplane V2. Quaisquer pedidos de rede futuros serão implementados na camada Dataplane V2.
| Antes da migração | Após a migração | |
|---|---|---|
| kube-proxy | Obrigatório e implementado automaticamente | Não obrigatório e não implementado |
| Encaminhamento | kube-proxy + iptables | eBPF |
Migre o tipo de balanceador de carga
Os tipos de balanceadores de carga recomendados (loadBalancer.kind) são "ManualLB"
e "MetalLB". Use "ManualLB" se tiver um equilibrador de carga de terceiros, como o F5 BIG-IP ou o Citrix. Use "MetalLB" para a nossa solução de balanceamento de carga
agrupada com o balanceador de carga MetalLB.
A partir da versão 1.30, estas são as únicas opções para criar novos clusters. Para clusters existentes que usam o F5 Big IP integrado ou o equilibrador de carga Seesaw incluído, fornecemos guias de migração para migrar as definições de configuração "F5BigIP" para "ManualLB" e para migrar o equilibrador de carga incluído do Seesaw para o MetalLB.
Migre as definições de configuração do seu equilibrador de carga F5 BIG-IP
Planeie migrar todos os clusters que usam o F5 Big IP integrado para o
ManualLB. O F5 Big IP integrado usa o F5 BIG-IP com agentes de balanceamento de carga, que consistem nos dois controladores seguintes:
- Controlador F5 (
pod prefix: load-balancer-f5): reconcilia os serviços Kubernetes do tipo LoadBalancer no formato F5 Common Controller Core Library (CCCL) ConfigMap. - Controlador F5 BIG-IP CIS v1.14 (
pod prefix: k8s-bigip-ctlr-deployment): traduz ConfigMaps em configurações do equilibrador 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. Isto pode impedir que configure o controlador BIG-IP de acordo com as suas necessidades específicas ou tire partido das funcionalidades avançadas da F5 que podem ser cruciais para a sua aplicação.
- Componente antigo: a implementação atual baseia-se em tecnologias mais antigas, como a API CCCL ConfigMap e o CIS 1.x. Estes componentes antigos podem não ser compatíveis com os mais recentes avanços nas ofertas da F5, o que pode levar a oportunidades perdidas de melhorias de desempenho e melhoramentos de segurança.
Depois da migração do F5 BIG-IP integrado para o ManualLB, as alterações incluem:
| Antes da migração | Após a migração | |
|---|---|---|
| Componentes de agentes F5 |
|
|
| Atualização da versão do componente F5 | Tem de atualizar os clusters para atualizar os componentes F5. As versões dos componentes disponíveis estão limitadas, conforme explicado anteriormente. | Pode atualizar as versões dos componentes F5 conforme necessário. |
| Criação de serviços | Processado por agentes da F5 | Processado por agentes do F5 (sem alterações) |
Migre do Seesaw para o MetalLB
O MetalLB oferece as seguintes vantagens em comparação com o Seesaw:
- Gestão simplificada e recursos reduzidos: ao contrário do Seesaw, o MetalLB é executado diretamente nos nós do cluster, o que permite a utilização dinâmica de recursos do cluster para o equilíbrio de carga.
- Atribuição automática de IP: o controlador MetalLB faz a gestão de endereços IP para os serviços, pelo que não tem de escolher manualmente um endereço IP para cada serviço.
- Distribuição da carga entre nós do LB: as instâncias ativas do MetalLB para diferentes serviços podem ser executadas em nós diferentes.
- Funcionalidades melhoradas e preparação para o futuro: o desenvolvimento ativo do MetalLB e a integração com o ecossistema Kubernetes mais amplo tornam-no numa solução mais preparada para o futuro em comparação com o Seesaw. A utilização do MetalLB garante que pode tirar partido dos mais recentes avanços na tecnologia de equilíbrio de carga.
| Antes da migração | Após a migração | |
|---|---|---|
| Nós de LB | VMs do Seesaw adicionais (fora do cluster) | Nós de LB no cluster com escolhas do cliente |
| Preservação do IP do cliente | Pode ser alcançado através de externalTrafficPolicy: Local |
Pode ser alcançado através do modo DSR do DataplaneV2 |
| Criação de serviços | IP de serviço especificado manualmente | IP de serviço atribuído automaticamente a partir do conjunto de endereços |
Migre clusters de utilizadores para o plano de controlo V2 e clusters de administrador para HA
O painel de controlo recomendado para clusters de utilizadores é o Controlplane V2. Com o Controlplane V2, o plano de controlo é executado num ou mais nós no próprio cluster de utilizadores. Com o plano de controlo antigo, denominado kubeception, o plano de controlo de um cluster de utilizador é executado num cluster de administrador. Para criar um cluster de administrador de alta disponibilidade (HA), os seus clusters de utilizadores têm de ter o Controlplane V2 ativado.
A partir da versão 1.30, os novos clusters de utilizadores têm de ter o Controlplane V2 ativado e os novos clusters de administrador vão ter HA. As atualizações de clusters de utilizadores com o painel de controlo antigo continuam a ser suportadas, tal como as atualizações de clusters de administrador não de HA.
Migre clusters de utilizadores para o Controlplane V2
Historicamente, os clusters de utilizadores usaram o kubeception. A versão 1.13 introduziu o Controlplane V2 como uma funcionalidade de pré-visualização, que transitou para DG na versão 1.14. Desde a versão 1.15, o Controlplane V2 tem sido a opção predefinida para criar clusters de utilizadores, e o Controlplane V2 é a única opção na versão 1.30.
Em comparação com o kubeception, as vantagens do plano de controlo V2 incluem:
- Consistência arquitetónica: os clusters de administrador e os clusters de utilizadores usam a mesma arquitetura.
- Isolamento de falhas: uma falha do cluster de administrador não afeta os clusters de utilizadores.
- Separação operacional: uma atualização do cluster de administrador não causa tempo de inatividade para os clusters de utilizadores.
- Separação da implementação: pode colocar os clusters de administrador e de utilizador em domínios de topologia diferentes ou em várias localizações. Por exemplo, num modelo de implementação de computação de limite, um cluster de utilizadores pode estar numa localização diferente do cluster de administrador.
Durante a migração, não há indisponibilidade para as cargas de trabalho do cluster de utilizadores existente. Consoante o seu ambiente vSphere subjacente, o plano de controlo vai sofrer um tempo de inatividade mínimo durante a comutação para o plano de controlo V2. O processo de migração faz o seguinte:
- Cria um novo plano de controlo no cluster de utilizadores.
- Copia os dados do etcd do plano de controlo antigo.
- Faz a transição dos nós do node pool existentes (também denominados nós de trabalho) para o novo plano de controlo.
| Antes da migração | Após a migração | |
|---|---|---|
| Objetos de nós do Kubernetes do plano de controlo | Nó do cluster de administrador | Nó do cluster de utilizadores |
| Pods do plano de controlo do Kubernetes | Statefulsets/implementações do cluster de administrador (namespace do cluster de utilizadores) | Pods estáticos do cluster de utilizadores (namespace kube-system) |
| Outros pods do plano de controlo | Statefulsets/implementações do cluster de administrador (namespace do cluster de utilizadores) | Statefulsets/implementações de clusters de utilizadores (espaço de nomes kube-system) |
| VIP do plano de controlo | Serviço de balanceador de carga do cluster de administrador | keepalived + haproxy (pods estáticos do cluster do utilizador) |
| Dados do Etcd | Volume persistente do cluster de administrador | Disco de dados |
| Gestão de IPs de máquinas do plano de controlo | IPAM ou DHCP | IPAM |
| Rede do plano de controlo | VLAN do cluster de administrador | VLAN do cluster de utilizadores |
Migre para um cluster de administrador de HA
Historicamente, o cluster de administrador só podia executar um único nó do plano de controlo, o que criava um risco inerente de um único ponto de falha. Além do nó do plano de controlo, os clusters de administrador sem HA também têm dois nós de suplementos. Um cluster de administrador de HA tem três nós do plano de controlo sem nós suplementares, pelo que o número de VMs que um novo cluster de administrador requer não se alterou, mas a disponibilidade foi significativamente melhorada. A partir da versão 1.16, pode usar um cluster de administrador de alta disponibilidade (HA), 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 as seguintes vantagens:
- Fiabilidade e tempo de atividade melhorados: a configuração de HA elimina o ponto único de falha, permitindo que o cluster de administrador permaneça operacional mesmo que um dos nós do plano de controlo tenha um problema.
- Experiência de atualização melhorada: todos os passos necessários para atualizar um cluster de administrador são agora executados no cluster, em vez de numa estação de trabalho de administrador separada. Isto garante que as atualizações continuam, mesmo que a sessão inicial na estação de trabalho do administrador possa ser interrompida.
- Fonte de verdade fiável para os estados dos clusters: os clusters de administrador não de HA dependem de um "ficheiro de ponto de verificação" 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, o que fornece uma fonte de verdade mais fiável para o estado do cluster.
Pode optar por migrar o cluster de administrador não de HA para um cluster de administrador de HA, o que não envolve tempo de inatividade para as cargas de trabalho do utilizador. O processo causa um tempo de inatividade mínimo e interrupções nos clusters de utilizadores existentes, principalmente associados à transferência do plano de controlo. O processo de migração faz o seguinte:
- Cria um novo plano de controlo de HA.
- Restaura os dados do etcd do cluster sem HA existente.
- Faz a transição dos clusters de utilizadores para o novo cluster de administrador de HA.
| Antes da migração | Após a migração | |
|---|---|---|
| Réplicas de nós do plano de controlo | 1 | 3 |
| Nós suplementares | 2 | 0 |
| Tamanho do disco de dados | 100GB * 1 | 25GB * 3 |
| Caminho dos discos de dados | Definido por vCenter.dataDisk no ficheiro 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 controlo | Definido por loadBalancer.kind no ficheiro de configuração do cluster de administrador | keepalived + haproxy |
| Atribuição de endereços IP para nós do plano de controlo do cluster de administrador | DHCP ou estático, consoante network.ipMode.type | 3 endereços IP estáticos |
Migrações de balanceadores de carga e painéis de controlo de grupos
Normalmente, quando atualiza clusters, recomendamos que atualize apenas uma funcionalidade ou uma definição de cada vez. No entanto, na versão 1.30 e superior, pode agrupar as alterações de configuração para a migração do balanceador de carga e do plano de controlo e, em seguida, atualizar o cluster apenas uma vez para fazer ambas as alterações.
Se tiver clusters de utilizadores a usar uma CNI antiga, primeiro tem de migrar para o DataPlane V2. Depois disso, pode agrupar a migração para o balanceador de carga e o plano de controlo. O agrupamento da migração oferece as seguintes vantagens:
- Um processo mais simples: se precisar de migrar um painel de controlo e um equilibrador de carga, normalmente, só atualiza o cluster uma vez. Além disso, não tem de decidir que funcionalidades tem de migrar primeiro.
- Reduzir o tempo de inatividade geral: determinadas migrações envolvem o tempo de inatividade do plano de controlo. Por isso, agrupar estas migrações numa operação de atualização reduz o tempo de inatividade geral em comparação com a realização de atualizações individuais sequenciais.
O processo varia consoante as configurações do cluster. No geral, execute a migração para cada cluster conforme descrito nos passos seguintes:
Migre cada cluster de utilizadores para usar a CNI recomendada, Dataplane V2.
Faça as alterações de configuração e atualize o cluster de utilizadores para acionar uma migração do cluster de utilizadores do CNI antigo, Calico, para o Dataplane V2.
Migre cada cluster de utilizadores do antigo equilibrador de carga (LB) e do antigo plano de controlo (CP) para usar o equilibrador de carga recomendado e o plano de controlo V2.
- Faça alterações à configuração para usar o equilibrador de carga recomendado (
MetalLBouManualLB). - Faça alterações de configuração para ativar o Controlplane V2.
- Atualize o cluster de utilizadores para migrar o balanceador de carga e o plano de controlo.
- Faça alterações à configuração para usar o equilibrador de carga recomendado (
Migre o cluster de administrador para usar o equilibrador de carga recomendado e tornar o plano de controlo altamente disponível.
- Faça alterações à configuração para usar o equilibrador de carga recomendado (
MetalLBouManualLB). - Faça alterações de configuração para migrar o plano de controlo do cluster de administrador de Não HA para HA.
- Atualize o cluster de administrador para migrar o balanceador de carga e o plano de controlo.
- Faça alterações à configuração para usar o equilibrador de carga recomendado (
Execute passos de limpeza opcionais, como limpar a VM do plano de controlo sem HA.
O diagrama seguinte ilustra os passos da migração:
Se o cluster de administrador e todos os clusters de utilizadores estiverem na versão 1.30 ou superior, pode usar o processo de migração de grupos. Para ver passos detalhados, consulte os seguintes guias:
- Migre clusters de utilizadores para funcionalidades recomendadas
- Migre o cluster de administração para funcionalidades recomendadas