Architecture du réseau d’applications Azure Kubernetes (préversion)

Important

Les fonctionnalités d’évaluation AKS sont disponibles en libre-service et font l’objet d’un abonnement. Les versions d'essai sont fournies « en l’état » et « selon disponibilité », et elles sont exclues des contrats de niveau de service et de la garantie limitée. Les versions préliminaires AKS sont, dans la mesure du possible, partiellement couvertes par le service clientèle. Par conséquent, ces fonctionnalités ne sont pas destinées à une utilisation en production. Pour plus d’informations, consultez les articles de support suivants :

L’architecture azure Kubernetes Application Network est organisée en trois couches : un plan de gestion, un plan de contrôle et un plan de données. Chaque couche a des responsabilités distinctes qui fournissent ensemble une solution de réseau de service basé sur l’environnement complètement managée pour Azure Kubernetes Service (AKS). Cette architecture permet une communication sécurisée basée sur des règles entre les services, sans nécessiter de sidecars ni de modifications de vos applications.

Cet article fournit une vue d’ensemble des couches architecturales d’Azure Kubernetes Application Network, de leur interaction et du modèle de découverte de service multi-cluster qui permet une communication évolutive entre clusters. Pour plus d’informations sur azure Kubernetes Application Network, consultez la vue d’ensemble d’Azure Kubernetes Application Network pour AKS.

Vue d’ensemble des couches architecturales d’Application Network

Les couches architecturales gèrent les responsabilités suivantes :

  • Plan de gestion : gère les opérations de ressources Azure telles que la création, la mise à jour et la suppression de ressources Réseau d’applications et la gestion de l’appartenance au cluster.
  • Plan de contrôle : gère la configuration du maillage, le cycle de vie des certificats et la découverte de service pour chaque cluster membre.
  • Plan de données : sécurise le trafic de service à service directement dans le cluster membre à l’aide du mode ambiant, qui ne nécessite aucun sidecar ni modification de vos applications.

Pour les déploiements à plusieurs clusters, Application Network synchronise les informations de découverte de service entre les clusters membres afin que les services puissent communiquer de manière transparente entre les limites du cluster.

Le diagramme suivant illustre les couches architecturales d’Azure Kubernetes Application Network et leur interaction entre elles et avec vos clusters AKS :

Capture d’écran d’un diagramme illustrant les couches architecturales d’Azure Kubernetes Application Network et leur interaction entre elles et avec les clusters AKS.

Plan de gestion

Le plan de gestion est le fournisseur de ressources Azure qui gère toutes les opérations de ressources réseau d’application. Lorsque vous créez une ressource Application Network ou rejoignez un cluster membre, le plan de gestion valide la demande, approvisionne les ressources Azure telles qu’Azure Key Vault pour le stockage de certificats et orchestre la création d’un plan de contrôle régional pour le membre.

Vous interagissez avec le plan de gestion via Azure CLI (az appnet) ou l’API ARM. Le plan de gestion coordonne l’approvisionnement en aval afin que les composants du plan de contrôle et du plan de données soient déployés sans intervention manuelle.

Plan de contrôle

Le plan de contrôle est une infrastructure entièrement managée qui s’exécute en dehors de votre cluster AKS. Lorsqu’un cluster membre rejoint un réseau d’applications, un plan de contrôle dédié est approvisionné dans la même région Azure que le cluster membre, en conservant la latence entre les composants de plan de données et de contrôle faible.

Note

Les membres de différentes régions Azure ont des plans de contrôle déployés dans leurs régions respectives.

Le plan de contrôle comprend les composants suivants :

  • Istiod : se connecte au serveur d’API Kubernetes du cluster membre pour découvrir les services et surveiller les modifications de configuration. Il envoie (push) la configuration xDS vers ztunnel et les proxys waypoint dans le plan de données. Dans les déploiements multi-cluster, Istiod se connecte également aux serveurs d’API Kubernetes d’autres clusters membres pour obtenir des informations de découverte de service, ce qui permet la découverte de services inter-clusters.
  • Gestion de certificats : provisionne et renouvelle les certificats d’autorité de certification supportés par Azure Key Vault. Une autorité de certification racine établit une limite d’approbation partagée sur tous les clusters membres, et chaque membre reçoit une autorité de certification intermédiaire qui émet des certificats de charge de travail de courte durée. Pour plus d’informations, consultez la vue d’ensemble de la sécurité du réseau d’applications Azure Kubernetes.
  • Gestion du cycle de vie : déploie et met à niveau tous les composants du plan de données dans le cluster membre, notamment ztunnel, Istio CNI, les proxys waypoint et les définitions de ressources personnalisées (CRD). Pour plus d’informations, consultez Configurer des mises à niveau pour les membres du réseau d’applications Azure Kubernetes.

Plan de données

Le plan de données se compose de composants déployés dans l’espace de noms du applink-system cluster membre. Application Network utilise le mode ambiant d’Istio, donc aucun sidecar n’est injecté dans vos charges de travail.

Le plan de données comprend les composants suivants :

  • Ztunnel : proxy L4 de niveau nœud déployé en tant que DaemonSet. Ztunnel intercepte le trafic de service à service sur le nœud, établit des connexions mTLS de manière transparente et applique des stratégies d’autorisation L4.
  • Proxys Waypoint : proxys L7 facultatifs par espace de noms qui fournissent le routage HTTP, le déplacement du trafic, l’injection d’erreurs et l’autorisation L7. Les proxys Waypoint sont déployés uniquement lorsque les stratégies L7 sont configurées pour un espace de noms.
  • Passerelle Est-ouest : gère le trafic entre clusters dans les déploiements multi-clusters. Vous êtes responsable de la fourniture d’une connectivité réseau entre les passerelles est-ouest dans chaque cluster membre. Pour plus d’informations, consultez découverte de service multi-cluster.
  • Istio CNI : DaemonSet qui configure la mise en réseau des pods pour l’interception du trafic de maillage ambiant.
  • CRDs : définitions de ressources personnalisées Kubernetes pour la configuration des stratégies de gestion du trafic et de sécurité.

Lorsqu’une requête est effectuée entre les services, ztunnel intercepte le trafic, établit une connexion mTLS avec le ztunnel de la destination et remet la requête à la charge de travail de destination. Si des stratégies L7 sont configurées, le trafic est acheminé via un proxy waypoint avant d’atteindre sa destination. Pour le trafic entre clusters, ztunnel route via la passerelle est-ouest pour atteindre les charges de travail dans les clusters membres distants.

Découverte de services à plusieurs clusters

Application Network prend en charge la connexion de plusieurs clusters AKS à un maillage de service unifié. Les services d’un cluster membre peuvent communiquer avec les services d’autres clusters membres, avec mTLS appliqué de bout en bout aux limites du cluster.

Dans les déploiements multi-clusters Open Source Istio, les plans de contrôle se connectent généralement aux serveurs d’API Kubernetes d’autres clusters pour découvrir les services et les modifications de configuration. Application Network suit un modèle de découverte de service similaire, où les plans de contrôle obtiennent des informations de service à partir de clusters membres afin que les services puissent être découverts au-delà des limites du cluster. Cette approche permet aux charges de travail d’un cluster membre de résoudre et de communiquer avec les services exécutés dans d’autres clusters sans nécessiter de modifications d’application. L’ajout d’un nouveau cluster membre développe l’appartenance au maillage afin que les services du nouveau cluster deviennent détectables par d’autres membres.

Le trafic entre clusters transite par des passerelles est-ouest déployées dans chaque cluster membre. Vous êtes responsable de la fourniture d’une accessibilité réseau entre les passerelles est-ouest de vos clusters membres, par exemple via le peering de réseaux virtuels, le VPN ou d’autres solutions de connectivité. Tout le trafic entre clusters est chiffré avec mTLS.

Interaction des composants

Le plan de contrôle se connecte au serveur d’API Kubernetes du cluster membre, surveille les modifications de service et de configuration, et envoie (push) les mises à jour xDS vers ztunnel et les proxys waypoint. Lorsqu’il existe plusieurs membres, chaque plan de contrôle échange également des informations de service par le biais de la messagerie managée afin que chaque membre ait une vue cohérente de tous les services sur le maillage.

La gestion des certificats provisionne une autorité de certification racine lorsque la ressource Réseau d’applications est créée et émet des autorités de certification intermédiaires pour chaque cluster membre. Les certificats de charge de travail sont émis avec une période de validité de 24 heures et pivotés automatiquement toutes les 12 heures. Tout le cycle de vie des certificats, de l'autorité de certification racine aux certificats intermédiaires et de charge de travail, est géré sans intervention manuelle.

Pour connaître la hiérarchie complète des certificats et la planification de la rotation, consultez la vue d’ensemble de la sécurité du réseau d’applications Azure Kubernetes.

Contenu connexe

Pour plus d’informations sur Azure Kubernetes Application Network, consultez les articles suivants :

  • Dernière mise à jour :