Casos de uso de rede entre clusters para o Gerenciador de Frota do Azure Kubernetes (versão prévia)

A rede entre clusters do Gerenciador de Frota de Kubernetes do Azure (Fleet) é uma oferta gerenciada criada com base no Cilium Cluster Mesh que permite estabelecer comunicação direta de pod para pod entre vários clusters do Serviço de Kubernetes do Azure (AKS). Ao criar uma rede entre clusters, você pode habilitar a conectividade contínua leste-oeste sem a necessidade de gateways, ao mesmo tempo em que obtém a observabilidade de vários clusters e a imposição de segurança consistente.

Arquitetura e funcionalidades

Em uma configuração de rede entre clusters, uma rede virtual plana permite que pods em clusters diferentes encaminhem tráfego diretamente através dos limites entre clusters. Cada cluster normalmente recebe duas sub-redes: uma para os nós e outra para os pods. Essa arquitetura consistente garante que a rede de pod permaneça plana em toda a rede entre clusters, sem o uso de sobreposições ou túneis.

Diagrama mostrando a arquitetura do Azure Kubernetes Fleet Manager gerenciando a conectividade leste-oeste entre clusters. Pods em clusters diferentes se comunicam diretamente por meio de agentes do Cilium em redes virtuais emparelhadas.

Os principais componentes e recursos para este cenário incluem:

  • Azure CNI com plano de dados baseado no Cilium: ambos os clusters do AKS devem usar o Azure CNI com o plano de dados do Cilium.
  • ACNS (Serviços Avançados de Rede de Contêiner): o ACNS deve estar habilitado nos clusters para dar suporte a esse cenário.
  • Azure Kubernetes Fleet Manager: a Fleet gerencia o ciclo de vida e a configuração da rede entre clusters por meio de recursos como o perfil ClusterMesh.
  • Desempenho nativo: o roteamento ip do pod ocorre entre clusters em desempenho nativo por meio de roteamento direto, contornando a necessidade de gateways ou proxies.
  • Imposição unificada de política de rede: estende a imposição da política de rede da Camada 3-7 do Cilium a todos os clusters na rede entre clusters, garantindo uma abordagem de segurança consistente.
  • Observabilidade de vários clusters: fornece visibilidade de ponta a ponta em fluxos de tráfego entre clusters. Essa visibilidade ajuda você a monitorar a integridade do aplicativo, a solucionar problemas de conectividade e a analisar padrões de tráfego em toda a rede entre clusters.

Casos de uso

A rede entre clusters permite vários cenários importantes de múltiplos clusters. As seções a seguir descrevem os casos de uso mais comuns para a rede entre clusters com o Fleet.

Caso de uso: descoberta de serviço transparente e balanceamento de carga

Quando você usa os serviços padrão no Kubernetes e os marca como globais, o Cilium detecta automaticamente endpoints desses serviços em todos os clusters da rede entre clusters. Qualquer tráfego destinado a um serviço ClusterIP global é automaticamente balanceado por carga em todos os clusters que contribuem, simplificando a comunicação entre clusters.

Os aplicativos podem descobrir e interagir com os serviços independentemente do cluster em que residem, sem a necessidade de alterações no nível do aplicativo ou registros de serviço externos.

Caso de uso: alta disponibilidade e tolerância a falhas

Alta disponibilidade é o caso de uso mais comum para rede entre clusters. Esse caso de uso inclui a operação de clusters do Kubernetes em várias regiões ou zonas de disponibilidade e a execução de réplicas dos mesmos serviços em cada cluster. Em caso de falha, as solicitações podem ser redirecionadas para outros clusters na rede entre clusters.

O cenário de falha abordado nesse caso de uso não é principalmente a indisponibilidade completa de uma região inteira ou domínio de falha. Um cenário mais provável é a indisponibilidade temporária de recursos ou configuração incorreta em um cluster, levando à incapacidade de executar ou dimensionar serviços específicos nesse cluster. Com a rede entre clusters, o tráfego destinado ao serviço afetado é automaticamente encaminhado para endpoints saudáveis em outros clusters, mantendo seu aplicativo disponível.

Diagrama que mostra dois clusters do AKS em diferentes regiões. Os front-ends em cada cluster roteiam para um serviço de pedidos local, com suporte de pods de pedidos. Quando os pods no cluster B se tornam não íntegros, o serviço de pedidos no cluster B faz a comutação para o serviço de pedidos no cluster A.

Caso de uso: serviços compartilhados

Embora a tendência inicial das plataformas baseadas em Kubernetes fosse criar clusters grandes e multilocatários, está se tornando cada vez mais comum criar clusters individuais por locatário ou criar clusters para diferentes categorias de serviços, como diferentes níveis de confidencialidade de segurança.

No entanto, alguns serviços, como gerenciamento de segredos, registro em log, monitoramento ou DNS, geralmente ainda são compartilhados entre todos os clusters. Centralizar esses serviços em um cluster de "serviço" compartilhado evita a sobrecarga operacional de mantê-los em cada cluster de locatários.

A principal motivação desse modelo é o isolamento entre clusters de locatários. Para manter essa meta, os clusters de locatário são conectados apenas ao cluster de serviços compartilhados e não estão conectados a outros clusters de locatários.

Diagrama que mostra dois clusters AKS de locatários com aplicativos que chamam um cliente de segredos. Ambos os clusters de locatários encaminham o tráfego para um cluster de serviços compartilhados que hospeda o serviço de segredos com suporte de pods vault-1 e vault-2. Os clusters de locatários se conectam apenas ao cluster de serviços compartilhados, não entre si.

Caso de uso: separação com estado e sem estado

Você pode isolar a complexidade operacional de serviços com estado, como bancos de dados e armazenamento, em clusters dedicados. Essa separação mantém os clusters de aplicativos sem estado ágeis e fáceis de migrar. Ele também melhora a segurança, simplifica o gerenciamento do ciclo de vida do cluster e permite dimensionar cargas de trabalho sem estado independentemente das cargas de trabalho com estado.

Diagrama mostrando dois clusters AKS sem estado, cada um com roteamento de entrada para um cliente de front-end e armazenamento de dados. Ambos os clusters sem estado se conectam a um cluster dedicado com estado que hospeda o serviço de armazenamento de dados com suporte de pods data-1, data-2 e data-n.

Caso de uso: segurança de vários clusters e imposição de política

A rede entre clusters estende a aplicação da política de rede de camadas 3 a 7 do Cilium a todos os clusters da rede entre clusters. Essa imposição unificada garante uma postura de segurança consistente e simplifica o gerenciamento de políticas, evitando a necessidade de replicar manualmente as políticas em todos os ambientes. As políticas aplicadas em um cluster são respeitadas em todos os outros clusters, fornecendo segurança unificada e com reconhecimento de identidade em toda a sua frota.

Caso de uso: observabilidade de vários clusters

A rede entre clusters fornece visibilidade de ponta a ponta sobre o tráfego que flui entre serviços entre clusters. Ao agregar dados de fluxo de cada cluster na rede entre clusters, você pode visualizar o tráfego leste-oeste, monitorar a integridade do aplicativo entre regiões, solucionar problemas de conectividade entre clusters e analisar padrões de tráfego para planejamento de capacidade.

Com logs de rede de contêineres, os operadores obtêm uma visão unificada da comunicação de pod para pod, independentemente de em qual cluster a origem ou o destino estejam, sem instrumentar os aplicativos.

Serviços globais

Para habilitar o fluxo de tráfego entre clusters, você deve configurar seus serviços do Kubernetes como serviços globais. Em uma rede entre clusters, um serviço global é um serviço kubernetes padrão que é compartilhado entre vários clusters. Quando você marca um serviço como global, Cilium descobre automaticamente os endpoints desse serviço em todos os clusters da rede entre clusters e realiza o balanceamento de carga entre eles.

Depois que um serviço é marcado como global, todas as políticas aplicadas em um cluster são respeitadas entre os outros clusters na rede entre clusters, fornecendo uma postura de segurança consistente. Essa configuração permite:

  • Descoberta de Serviço Transparente: os aplicativos podem descobrir e interagir com os serviços independentemente do cluster em que residem.
  • Alta Disponibilidade: se um serviço em um cluster ficar indisponível, o tráfego será automaticamente deslocado para uma instância íntegra em outro cluster.

O Cilium gerencia essa descoberta observando os serviços com a anotação io.cilium/global-service: "true". Para esses serviços, todos os endpoints com o mesmo nome e namespace em todos os clusters são mesclados em um único serviço global. Qualquer tráfego destinado a ClusterIP desse serviço é então balanceado por carga em todos os clusters que contribuem.

Limitações

  • Um cluster membro pode participar de apenas uma rede entre clusters por vez.
  • Uma única rede entre clusters dá suporte a até 255 clusters de membros.
  • Configurações multicluster do Cilium autogerenciado não têm suporte em conjunto com a rede entre clusters gerenciada pelo Fleet.
  • Os comandos da CLI do Cilium que modificam a malha, como cilium clustermesh connect ou cilium upgrade, não têm suporte porque o Fleet gerencia essas operações.
  • A comunicação entre clusters é limitada a clusters que estejam dentro do mesmo domínio de roteamento plano acessível. Não oferece suporte à conectividade em malha entre redes virtuais não emparelhadas.

Próximas Etapas 

  • Last updated on