Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Aplica-se a: ✔️ Gerenciador de Frotas ✔️ Gerenciador de Frotas com cluster de hub
Azure Kubernetes Fleet Manager fornece uma solução dedicada de rede entre clusters que estende o caminho de dados do Kubernetes em vários clusters. O uso de rede entre clusters conectados permite que qualquer cluster conectado se comunique diretamente com qualquer outro cluster conectado e seus pontos de extremidade, com a aplicação completa das políticas de rede. Usando a rede entre clusters, permitindo que os clusters publiquem serviços de modo que qualquer cluster conectado possa chamá-los como se fossem locais.
Vários perfis de rede entre clusters podem ser criados no Fleet Manager, com a única restrição sendo que os clusters de membros só podem participar de uma única rede entre clusters.
Neste artigo, apresentamos os principais conceitos de rede entre clusters para Azure o Kubernetes Fleet Manager.
Importante
A versão prévia do recurso Gerenciador de Frota de Kubernetes do Azure está disponível com base em autoatendimento e aceitação. As versões prévias são fornecidas “no estado em que se encontram” e “conforme disponíveis” e são excluídas dos contratos de nível de serviço e da garantia limitada. A versão prévia do Gerenciador de Frota de Kubernetes do Azure é parcialmente coberta pelo suporte ao cliente com base no melhor esforço. Dessa forma, esses recursos não são destinados ao uso em produção.
Pré-requisitos e limitações
- Uma rede entre clusters pode ter até 255 clusters de membros.
- Os clusters membros do Fleet Manager só podem participar de uma única rede entre clusters a qualquer momento.
- Os clusters devem executar o Kubernetes v1.32 ou superior e ter ACNS (Serviços Avançados de Rede de Contêiner) com Cilium habilitado.
- Os clusters devem estar conectados a uma única rede simples (rede virtual ou várias redes emparelhadas).
- Não há suporte para rede sobreposta com túneis.
- Não é possível implantar o multicluster autogerenciado do Cilium simultaneamente.
- O ACNS define a versão do Cilium e os recursos habilitados. No momento, elas não podem ser modificadas diretamente.
Conceitos fundamentais
A rede entre clusters para o Gerenciador de Frotas de Kubernetes do Azure fornece uma implantação do multicluster do Cilium gerenciada pela frota, que remove a sobrecarga de configuração e gerenciamento dos componentes do plano de dados do multicluster do Cilium em cada cluster membro.
Quando um cluster se junta a uma rede entre clusters, o agente Cilium (cilium-agent) e clustermesh-apiserver são implantados no plano de controle do cluster pelo Gerenciador de Frota. Os clusters existentes na mesma rede entre clusters são atualizados com os detalhes do cluster recém-adicionado e o agente Cilium configura o roteamento baseado em eBPF para permitir que os pods em cada cluster se comuniquem diretamente sem proxies ou gateways.
Cada cluster mantém sua configuração de endereçamento CIDR IP local para pods e serviços. Os componentes do Cilium local são responsáveis pelo roteamento, permitindo que os pods em um cluster alcancem serviços em clusters remotos como se fossem locais.
Para o controle de fluxo de tráfego, as políticas de rede do Cilium (CiliumNetworkPolicy) podem ser usadas para controlar o fluxo de dados entre clusters, permitindo que os administradores imponham limites dentro da rede entre clusters.
Definindo serviços globais
Os Serviços do Kubernetes em qualquer membro de rede entre clusters podem ser disponibilizados globalmente na rede entre clusters quando ambas as seguintes condições forem atendidas:
- O Namespace que contém o Serviço tem a anotação
clustermesh.cilium.io/globalcom um valor detrue. - O Serviço tem a anotação
service.cilium.io/globalcom um valor detrue.
A implantação de um Serviço com essas anotações em vários clusters membros de uma rede entre clusters permite equilibrar de maneira transparente as solicitações entre esses clusters.
Note
A instalação multicluster do Cilium gerenciada pelo Fleet Manager define clustermesh-default-global-namespace: false, o que difere do padrão do Cilium. Essa configuração melhora a escalabilidade ao limitar a quantidade de estado (CiliumEndpoints, CiliumIdentities e Serviços) sincronizada entre clusters apenas aos recursos em Namespaces com a anotação clustermesh.cilium.io/global definida com o valor true. Como resultado, é necessária uma adesão explícita para cada Namespace ao definir essa anotação.
Você pode remover temporariamente um Serviço de um serviço global com balanceamento de carga removendo a service.cilium.io/global anotação (ou definindo-a como false) nesse Serviço. Para interromper o compartilhamento de cada serviço em um namespace de um determinado cluster, remova a clustermesh.cilium.io/global anotação no Namespace (ou defina-a como false) nesse cluster.
Depuração e solução de problemas
As ferramentas padrão da CLI (interface de linha de comando) do Cilium funcionam com rede entre clusters para o Fleet Manager. Alguns comandos desse tipo upgrade e clustermesh connect não funcionam porque executam ações pelas quais o Fleet Manager agora é responsável.
Aqui estão as etapas de alto nível para começar a depurar e solucionar problemas:
- Instale a CLI estável mais recente do Cilium para o seu sistema operacional a partir do repositório do Cilium CLI no GitHub.
- Selecione um cluster de membro de rede entre clusters e recupere seu kubeconfig usando o comando
az aks get-credentials. - Use a CLI do Cilium, passando o contexto do cluster usando o
--contextparâmetro.
A CLI do Cilium pode gerenciar várias versões do Cilium.
Atualizando a rede entre clusters
Um motivo para adotar a rede entre clusters em vez da instalação e da execução multicluster do Cilium por conta própria é que o Gerenciador de Frota mantém os componentes do Cilium atualizados.
As atualizações do componente do Cilium para rede entre clusters são agrupadas como parte dos lançamentos do Kubernetes no AKS. As atualizações são simplificadas pela pré-validação de que os componentes do Cilium funcionam com a versão do Kubernetes que seu cluster executa, garantindo que a rede entre clusters permaneça estável.
Essa abordagem significa que você pode usar as Execuções e Estratégias de Atualização do Fleet Manager para atualizar o plano de controle de seus clusters, definindo a ordem na qual os clusters são atualizados.