Cas d’utilisation de la mise en réseau entre clusters pour Azure Kubernetes Fleet Manager (préversion)

La mise en réseau inter-clusters pour Azure Kubernetes Fleet Manager (Fleet) est une offre gérée basée sur Cilium Cluster Mesh qui vous permet d’établir une communication directe entre pods sur plusieurs clusters Azure Kubernetes Service (AKS). En créant un réseau inter-clusters, vous pouvez activer une connectivité est-ouest transparente sans avoir besoin de passerelles, tout en obtenant également une observabilité multi-cluster et une mise en œuvre cohérente de la sécurité.

Architecture et fonctionnalités

Dans une configuration réseau entre clusters, un réseau virtuel plat permet aux pods de différents clusters d’acheminer le trafic directement entre les limites du cluster. Chaque cluster est généralement affecté à deux sous-réseaux : un pour les nœuds et un pour les pods. Cette architecture cohérente garantit que le réseau de pods reste plat sur le réseau inter-clusters, sans utiliser de superpositions ou de tunnels.

Schéma montrant l’architecture d’Azure Kubernetes Fleet Manager, qui gère la connectivité est-ouest inter-clusters. Les pods de différents clusters communiquent directement via des agents Cilium à travers des réseaux virtuels appairés.

Les principaux composants et fonctionnalités de ce scénario sont les suivants :

  • Azure CNI avec plan de données Cilium : les deux clusters AKS doivent utiliser Azure CNI avec le Azure CNI alimenté par le plan de données Cilium.
  • Advanced Container Networking Services (ACNS) : ACNS doit être activé sur les clusters pour prendre en charge ce scénario.
  • Azure Kubernetes Fleet Manager : Fleet gère le cycle de vie et la configuration du réseau inter-clusters via des ressources telles que le profil ClusterMesh.
  • Performances natives : le routage IP de pod se produit sur des clusters aux performances natives via le routage direct, en contournant la nécessité de passerelles ou de proxys.
  • Application de la stratégie de réseau unifiée : étend l’application de la stratégie réseau de couche 3-7 de Cilium à tous les clusters du réseau inter-clusters, ce qui garantit une approche de sécurité cohérente.
  • Observabilité multi-cluster : offre une visibilité de bout en bout sur les flux de trafic entre clusters. Cette visibilité vous permet de surveiller l’intégrité des applications, de résoudre les problèmes de connectivité et d’analyser les modèles de trafic sur le réseau inter-clusters.

Cas d’utilisation

La mise en réseau inter-clusters permet plusieurs scénarios de plusieurs clusters clés. Les sections suivantes décrivent les cas d’usage les plus courants pour la mise en réseau entre clusters avec Fleet.

Cas d’usage : découverte de services transparents et équilibrage de charge

Lorsque vous utilisez des services Kubernetes standard et que vous les marquez comme globaux, Cilium découvre automatiquement les points de terminaison de ces services sur tous les clusters du réseau inter-clusters. Tout trafic destiné à un service ClusterIP global est automatiquement équilibré sur tous les clusters contributeurs, ce qui simplifie la communication entre clusters.

Les applications peuvent découvrir et interagir avec les services quel que soit le cluster dans lequel elles résident, sans nécessiter de modifications au niveau de l’application ou de registres de services externes.

Cas d’usage : Haute disponibilité et tolérance de panne

La haute disponibilité est le cas d’usage le plus courant pour la mise en réseau entre clusters. Ce cas d’usage inclut l’exploitation de clusters Kubernetes dans plusieurs régions ou zones de disponibilité et l’exécution de réplicas des mêmes services dans chaque cluster. En cas de défaillance, les demandes peuvent basculer vers d’autres clusters dans le réseau inter-clusters.

Le scénario d’échec abordé dans ce cas d’usage n’est pas principalement l’indisponibilité complète d’une région entière ou d’un domaine d’échec. Un scénario plus probable est l’indisponibilité temporaire des ressources ou de la mauvaise configuration dans un cluster, ce qui entraîne l’incapacité d’exécuter ou de mettre à l’échelle des services particuliers dans ce cluster. Avec la mise en réseau inter-clusters, le trafic destiné au service concerné est automatiquement acheminé vers des points de terminaison sains dans d’autres clusters, en gardant votre application disponible.

Diagramme montrant deux clusters AKS répartis sur plusieurs régions. Les composants frontaux de chaque cluster redirigent vers un service de commandes local s’appuyant sur des pods de commandes. Lorsque les pods du cluster B ne sont plus sains, le service de commandes du cluster B bascule sur le service de commandes du cluster A.

Cas d’usage : Services partagés

Bien que la tendance initiale des plateformes kubernetes ait été de créer des clusters volumineux et multilocataires, il devient de plus en plus courant de créer des clusters individuels par locataire ou de créer des clusters pour différentes catégories de services, tels que différents niveaux de sensibilité de sécurité.

Toutefois, certains services tels que la gestion des secrets, la journalisation, la surveillance ou le DNS sont souvent partagés entre tous les clusters. La centralisation de ces services dans un cluster « service » partagé évite la surcharge opérationnelle de leur maintenance dans chaque cluster client.

La principale motivation de ce modèle est l’isolation entre les clusters clients. Pour maintenir cet objectif, les clusters de locataires sont connectés uniquement au cluster de services partagés et ne sont pas connectés à d’autres clusters clients.

Diagramme montrant deux clusters AKS clients avec des applications appelant un client de secrets. Les deux clusters clients sont acheminés vers un cluster de services partagés qui héberge le service de secrets sauvegardé par les pods vault-1 et vault-2. Les clusters clients se connectent uniquement au cluster de services partagés, et non les uns aux autres.

Cas d’utilisation : séparation avec état et sans état

Vous pouvez isoler la complexité opérationnelle des services avec état, tels que les bases de données et le stockage, dans des clusters dédiés. Cette séparation permet aux clusters d’applications sans état d’être agiles et faciles à migrer. Cela améliore également la sécurité, simplifie la gestion du cycle de vie du cluster et vous permet de faire évoluer les charges de travail sans état indépendamment des charges de travail avec état.

Diagramme montrant deux clusters AKS sans état, chacun avec routage d’entrée vers un client frontal et un client de magasin de données. Les deux clusters sans état se connectent à un cluster avec état dédié hébergeant le service de magasin de données soutenu par les pods data-1, data-2 et data-n.

Cas d’usage : Mise en œuvre de la sécurité et de la stratégie multi-cluster

La mise en réseau entre clusters étend l’application de la stratégie réseau de couche 3-7 de Cilium sur tous les clusters du réseau inter-clusters. Cette application unifiée garantit une posture de sécurité cohérente et simplifie la gestion des stratégies en évitant la nécessité de répliquer manuellement des stratégies dans chaque environnement. Les stratégies appliquées sur un cluster sont également appliquées sur les autres clusters, assurant une sécurité unifiée tenant compte des identités dans l’ensemble de votre flotte.

Cas d’usage : observabilité multi-cluster

La mise en réseau entre clusters offre une visibilité de bout en bout sur le trafic transitant entre les services entre les clusters. En agrégeant les données de flux de chaque cluster dans le réseau inter-clusters, vous pouvez visualiser le trafic est-ouest, surveiller l’intégrité des applications entre les régions, résoudre les problèmes de connectivité entre clusters et analyser les modèles de trafic pour la planification de la capacité.

Avec les journaux réseau de conteneurs, les opérateurs obtiennent une vue unifiée de la communication pod-à-pod, quel que soit le cluster dans lequel réside la source ou la destination, sans instrumenter les applications.

Services globaux

Pour activer le flux de trafic entre les clusters, vous devez configurer vos services Kubernetes en tant que services globaux. Dans un réseau inter-clusters, un service global est un service Kubernetes standard partagé entre plusieurs clusters. Lorsque vous marquez un service comme global, Cilium découvre automatiquement les points de terminaison de ce service dans tous les clusters au sein du réseau inter-clusters et effectue l’équilibrage de charge entre eux.

Une fois qu’un service est marqué comme global, toutes les stratégies appliquées sur un cluster sont respectées sur les autres clusters du réseau inter-clusters, ce qui offre une posture de sécurité cohérente. Cette configuration permet les éléments suivants :

  • Transparent Service Discovery : les applications peuvent découvrir et interagir avec les services, quel que soit le cluster dans lequel elles résident.
  • Haute disponibilité : si un service d’un cluster devient indisponible, le trafic est automatiquement déplacé vers une instance saine d’un autre cluster.

Cilium gère cette découverte en surveillant les services portant l’annotation io.cilium/global-service: "true". Pour ces services, tous les points de terminaison portant le même nom et le même espace de noms entre les clusters sont fusionnés dans un seul service global. Tout trafic destiné à ce service ClusterIP est ensuite équilibré en charge sur tous les clusters contributeurs.

Limitations

  • Un cluster membre ne peut participer qu’à un seul réseau inter-clusters à la fois.
  • Un seul réseau inter-clusters prend en charge jusqu’à 255 clusters membres.
  • Les configurations multi-cluster auto-gérées par Cilium ne sont pas prises en charge en même temps que la mise en réseau inter-cluster gérée par la flotte.
  • Les commandes CLI Cilium qui modifient le maillage, tels que cilium clustermesh connect ou cilium upgrade, ne sont pas prises en charge, car Fleet gère ces opérations.
  • La mise en réseau inter-clusters est limitée aux clusters au sein du même domaine de routage plat accessible. Elle ne prend pas en charge la connectivité mesh entre des réseaux virtuels non appairés.

Étapes suivantes

  • Last updated on