Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Dans cet article, vous allez découvrir les options de mise en réseau du plan de contrôle pour Azure Kubernetes Service (AKS). Nous posons d’abord une question pour vous aider à guider votre planification, puis à fournir des options, des recommandations et des meilleures pratiques.
Comment voulez-vous accéder à votre serveur d’API ?
Le plan de contrôle AKS géré par Azure se compose de plusieurs composants qui aident à gérer le cluster, y compris le serveur d’API. Vous devez configurer la mise en réseau afin que les nœuds et les utilisateurs finaux puissent accéder au serveur d’API pour des éléments tels que les mises à jour et la gestion des clusters.
Options de mise en réseau du plan de contrôle
Lors de la configuration de la mise en réseau du plan de contrôle, vous pouvez choisir un cluster public ou un cluster privé :
| Option de mise en réseau du plan de contrôle | Diagramme des composants réseau | Caractéristiques et fonctionnalités |
|---|---|---|
| Cluster public |
|
• Serveur d’API accessible via une adresse IP publique, ce qui permet aux utilisateurs et aux nœuds de se connecter sans configuration supplémentaire. • Vous pouvez restreindre l’accès à certaines plages d’adresses IP sources. • Utilise le tunnel konnectivity pour l’accès aux nœuds et aux pods. • Prend en charge l’intégration au réseau virtuel du serveur d’API. |
| Cluster privé |
|
• Serveur d’API accessible via une adresse IP interne, avec le DNS privé Azure utilisé pour le nom d’hôte du serveur d’API. • Utilise Azure Private Link pour se connecter en toute sécurité au serveur d’API. • Utilise le tunnel Konnectivity pour accéder aux nœuds et aux pods. • Prend en charge l’intégration au réseau virtuel du serveur d’API. |
Intégration au réseau virtuel du serveur d’API (préversion)
L’intégration au réseau virtuel du serveur d’API est prise en charge pour les clusters publics ou privés. L’intégration au réseau virtuel du serveur d’API permet une communication réseau entre le serveur d’API et les nœuds du cluster sans qu’il soit nécessaire d’utiliser un tunnel ni une liaison privée. Le serveur d’API est disponible derrière une adresse IP virtuelle d’équilibreur de charge interne dans le sous-réseau délégué, que les nœuds sont configurés pour utiliser.
Avec l’intégration au réseau virtuel du serveur d’API :
- Le serveur d’API provisionne dans un sous-réseau délégué au sein de votre réseau virtuel (VNet).
- Il est possible d’utiliser un tunnel Konnectivity pour accéder aux pods dans les clusters Overlay ou BYO CNI.
- Peut ajouter ou supprimer un accès public au serveur d’API à tout moment sans interruption du cluster.
Recommendations
Notre recommandation générale est d’utiliser un cluster public, car il simplifie la configuration réseau et permet d’accéder plus facilement au serveur d’API. Toutefois, si vous avez des exigences de sécurité ou de conformité spécifiques, un cluster privé peut être plus approprié.
Une fois en disponibilité générale, nous vous recommandons d’activer l’intégration au réseau virtuel du serveur d’API pour les clusters publics et privés afin d’améliorer la sécurité et de simplifier la gestion du réseau.