Casos de uso em redes cross-cluster para Azure Kubernetes Fleet Manager (pré-visualização)

A rede entre clusters para o Azure Kubernetes Fleet Manager (Fleet) é uma oferta gerida baseada em Cilium Cluster Mesh que lhe permite estabelecer comunicação direta entre pods em vários clusters do Azure Kubernetes Service (AKS). Ao criar uma rede entre clusters, pode ativar uma conectividade este-oeste contínua sem recorrer a gateways, ao mesmo tempo que obtém observabilidade entre clusters e uma aplicação consistente das políticas de segurança.

Arquitetura e capacidades

Numa configuração de rede entre clusters, uma rede virtual plana permite que pods em diferentes clusters encaminhem tráfego diretamente através das fronteiras entre clusters. A cada cluster são normalmente atribuídas duas sub-redes: uma para os nós e outra para os pods. Esta arquitetura consistente garante que a rede pod permanece plana em toda a rede cross-cluster, sem o uso de sobreposições ou túneis.

Diagrama que mostra a arquitetura do Azure Kubernetes Fleet Manager a gerir a conectividade este-oeste entre clusters. Os pods em diferentes clusters comunicam diretamente através de agentes Cilium em redes virtuais emparelhadas.

Componentes e capacidades chave para este cenário incluem:

  • Azure CNI com plano de dados Cilium: Ambos os clusters AKS devem usar Azure CNI com o Azure CNI alimentado pelo plano de dados Cilium.
  • Serviços Avançados de Rede de Contentores (ACNS): O ACNS deve estar ativado nos clusters para suportar este cenário.
  • Azure Kubernetes Fleet Manager: A Fleet gere o ciclo de vida e a configuração da rede cross-cluster através de recursos como o perfil ClusterMesh.
  • Desempenho nativo: O encaminhamento pod IP ocorre em clusters com desempenho nativo através de encaminhamento direto, evitando a necessidade de gateways ou proxies.
  • Aplicação unificada de políticas de rede: Estende a aplicação de políticas de rede das Camadas 3 a 7 do Cilium a todos os clusters da rede entre clusters, garantindo uma abordagem de segurança consistente.
  • Observabilidade multi-cluster: Proporciona visibilidade de ponta a ponta sobre os fluxos de tráfego entre clusters. Esta visibilidade ajuda-o a monitorizar a saúde da aplicação, resolver problemas de conectividade e analisar padrões de tráfego ao longo da rede cross-cluster.

Casos de utilização

A interligação entre clusters permite vários cenários principais de vários clusters. As secções seguintes descrevem os casos de utilização mais comuns da ligação em rede entre clusters com o Fleet.

Caso de uso: Descoberta transparente de serviços e balanceamento de carga

Quando utiliza serviços Kubernetes padrão e os marca como globais, a Cilium descobre automaticamente os endpoints para esses serviços em todos os clusters da rede cross-cluster. Qualquer tráfego destinado a um serviço ClusterIP global é automaticamente balanceado em todos os clusters contribuintes, simplificando a comunicação entre clusters.

As aplicações podem descobrir e interagir com serviços independentemente do cluster em que se encontrem, sem necessidade de alterações ao nível da aplicação ou registos de serviços externos.

Caso de utilização: Alta disponibilidade e tolerância a falhas

A alta disponibilidade é o caso de uso mais comum para redes entre clusters. Este caso de uso inclui operar clusters Kubernetes em múltiplas regiões ou zonas de disponibilidade e executar réplicas dos mesmos serviços em cada cluster. Em caso de falha, os pedidos podem ser redirecionados para outros clusters na rede entre clusters.

O cenário de falha abordado neste caso de uso não é, principalmente, a completa indisponibilidade de toda uma região ou domínio de falha. Um cenário mais provável é a indisponibilidade temporária de recursos ou má configuração num cluster, levando à incapacidade de executar ou escalar determinados serviços nesse cluster. Com a rede cross-cluster, o tráfego destinado ao serviço afetado é automaticamente encaminhado para endpoints saudáveis noutros clusters, mantendo a sua aplicação disponível.

Diagrama que mostra dois clusters do AKS em duas regiões. Os front-ends em cada cluster encaminham o tráfego para um serviço de encomendas local, suportado por pods de encomendas. Quando os pods no cluster B ficam em estado não saudável, o serviço de encomendas no cluster B comuta para o serviço de encomendas no cluster A.

Caso de utilização: Serviços partilhados

Embora a tendência inicial das plataformas baseadas em Kubernetes fosse construir grandes clusters multiinquilino, está a tornar-se cada vez mais comum construir clusters individuais por tenant ou construir clusters para diferentes categorias de serviços, como diferentes níveis de sensibilidade de segurança.

No entanto, alguns serviços, como gestão de segredos, registo, monitorização ou DNS, são frequentemente partilhados entre todos os clusters. Centralizar estes serviços num cluster partilhado de "serviços" evita a sobrecarga operacional de os manter em cada cluster de inquilino.

A principal motivação deste modelo é o isolamento entre clusters de inquilinos. Para manter esse objetivo, os clusters de tenant estão ligados exclusivamente ao cluster de serviços partilhados e não aos outros clusters de tenant.

Diagrama que mostra dois clusters AKS de inquilinos com aplicações a chamar um cliente de segredos. Ambos os clusters de inquilinos encaminham o tráfego para um cluster de serviços partilhados que aloja o serviço de segredos, suportado pelos pods vault-1 e vault-2. Os clusters de inquilinos ligam-se apenas ao cluster de serviços partilhados, não uns aos outros.

Caso de utilização: Separação com estado e separação sem estado

Pode isolar a complexidade operacional de serviços com estado, como as bases de dados e o armazenamento, em clusters dedicados. Esta separação mantém clusters de aplicações sem estado ágeis e fáceis de migrar. Também melhora a segurança, simplifica a gestão do ciclo de vida do cluster e permite dimensionar cargas de trabalho sem estado independentemente das com estado.

Diagrama que mostra dois clusters AKS sem estado, cada um com encaminhamento de tráfego de entrada para um frontend e um cliente do datastore. Ambos os clusters sem estado estão ligados a um cluster com estado dedicado que aloja o serviço de datastore, suportado por pods data-1, data-2 e data-n.

Caso de uso: Segurança multi-cluster e aplicação de políticas

A ligação em rede entre clusters estende a aplicação das políticas de rede de Camada 3 a 7 do Cilium a todos os clusters da rede entre clusters. Esta aplicação unificada assegura uma postura de segurança consistente e simplifica a gestão de políticas ao evitar a necessidade de replicar manualmente as políticas em todos os ambientes. As políticas aplicadas a um cluster são aplicadas em todos os outros clusters, proporcionando segurança unificada com reconhecimento de identidade em toda a frota.

Caso de uso: Observabilidade multicluster

A rede entre clusters proporciona visibilidade de ponta a ponta do tráfego que flui entre serviços entre clusters. Ao agregar dados de fluxo de todos os clusters na rede cross-cluster, pode visualizar o tráfego este-oeste, monitorizar a saúde das aplicações entre regiões, resolver problemas de conectividade entre clusters e analisar padrões de tráfego para planeamento de capacidade.

Com registos de rede de contentores, os operadores obtêm uma visão unificada da comunicação pod-a-pod, independentemente do cluster onde reside a origem ou destino, sem aplicações de instrumentação.

Serviços globais

Para permitir o fluxo de tráfego entre clusters, deve configurar os seus serviços Kubernetes como serviços globais. Numa rede cross-cluster, um serviço global é um serviço Kubernetes padrão que é partilhado entre múltiplos clusters. Quando marca um serviço como global, a Cilium descobre automaticamente os endpoints desse serviço em todos os clusters dentro da rede cross-cluster e realiza o balanceamento de carga entre eles.

Uma vez que um serviço é marcado como global, quaisquer políticas aplicadas a um cluster são respeitadas entre os outros clusters da rede cross-cluster, proporcionando uma postura de segurança consistente. Esta configuração permite:

  • Descoberta Transparente de Serviços: As aplicações podem descobrir e interagir com serviços independentemente do cluster em que se encontrem.
  • Alta Disponibilidade: Se um serviço num cluster se tornar indisponível, o tráfego é automaticamente transferido para uma instância saudável noutro cluster.

O Cilium gere esta descoberta monitorizando os serviços com a anotação io.cilium/global-service: "true". Para estes serviços, todos os endpoints com o mesmo nome e namespace entre clusters são fundidos num único serviço global. Qualquer tráfego destinado a esse serviço ClusterIP é então balanceado em carga entre todos os clusters contribuintes.

Limitações

  • Um cluster membro pode participar apenas numa rede cross-cluster de cada vez.
  • Uma única rede entre clusters suporta até 255 clusters integrantes.
  • As configurações multicluster autogeridas do Cilium não são suportadas em conjunto com a rede entre clusters gerida pela Fleet.
  • Os comandos Cilium CLI que modificam a malha, como cilium clustermesh connect ou cilium upgrade, não são suportados porque a Frota gere estas operações.
  • A rede entre clusters está restrita a clusters dentro do mesmo domínio de roteamento plano acessível. Não suporta conectividade em malha entre redes virtuais não emparelhadas.

Passos seguintes

  • Last updated on