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.
Un cluster Azure Kubernetes Service (AKS) configuré avec l’intégration au réseau virtuel du serveur d’API projette le point de terminaison du serveur d’API directement dans un sous-réseau délégué au sein du réseau virtuel où AKS est déployé. 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. L’intégration au réseau virtuel du serveur d’API permet de veiller à ce que le trafic réseau entre votre serveur d’API et vos pools de nœuds reste limité au réseau privé.
Connectivité du serveur d’API
Le plan de contrôle ou le serveur d’API se trouve dans un abonnement Azure géré par AKS. Votre cluster ou pool de nœuds se trouve dans votre abonnement Azure. Le serveur et les machines virtuelles qui composent les nœuds de cluster peuvent communiquer entre eux par le biais de l’adresse IP virtuelle du serveur d’API et des adresses IP de pod qui sont projetées dans le sous-réseau délégué.
L’intégration au réseau virtuel du serveur d’API est prise en charge pour les clusters publics ou privés. Vous pouvez ajouter ou supprimer l’accès public après l’approvisionnement du cluster. Contrairement aux clusters non intégrés au réseau virtuel, les nœuds d’agent communiquent toujours directement avec l’adresse IP privée de l’équilibreur de charge interne (ILB) du serveur d’API sans utiliser DNS. Tout le trafic entre le nœud et le serveur d’API est conservé sur un réseau privé et aucun tunnel n’est nécessaire pour la connectivité entre le serveur d’API et le nœud. Les clients hors cluster qui ont besoin de communiquer avec le serveur d’API peuvent le faire normalement si l’accès au réseau public est activé. Si l’accès au réseau public est désactivé, vous devez suivre la même méthodologie d’installation de DNS privé que pour des clusters privés standard.
Prérequis
- Azure CLI version 2.73.0 ou ultérieure doit être installé. Vous pouvez vérifier votre version à l’aide de la
az --versioncommande.
Limites
- L’intégration au réseau virtuel du serveur d’API ne prend pas en charge le chiffrement de réseau virtuel. Les clusters déployés sur les références SKU de nœud AKS v3 ou antérieures (qui ne prennent pas en charge le chiffrement de réseau virtuel) sont autorisés, mais le trafic ne sera pas chiffré. Les clusters déployés sur des références SKU de nœud AKS v4 ou ultérieures (qui prennent en charge le chiffrement de réseau virtuel) sont bloqués, car les réseaux virtuels chiffrés sont incompatibles avec l’intégration au réseau virtuel du serveur d’API. Pour plus d’informations, consultez les références SKU de machine virtuelle prises en charge par AKS .
Availability
- L’intégration au réseau virtuel du serveur d’API est disponible dans toutes les régions de cloud public en disponibilité générale, sauf eastus2 et qatarcentral. Nous travaillons continuellement à l’activation de cette fonctionnalité dans ces régions et nous allons mettre à jour cette page lorsque ces régions deviennent disponibles.
Créer un cluster AKS doté de l’intégration au réseau virtuel du serveur d’API en mode VNet managé
Vous pouvez configurer les clusters AKS dotés de l’intégration au réseau virtuel du serveur d’API en mode VNet managé ou en mode Apporter votre propre VNet. Vous pouvez les créer en tant que clusters publics (avec accès au serveur d’API disponible par une adresse IP publique) ou privés (avec le serveur d’API accessible uniquement par la connectivité du réseau virtuel privé). Vous pouvez également basculer entre un état public et un état privé sans redéployer votre cluster.
Créer un groupe de ressources
Créez un groupe de ressources à l’aide de la commande
az group create.az group create --location westus2 --name <resource-group>
Déployer un cluster public
Déployez un cluster AKS public avec l’intégration au réseau virtuel du serveur d’API pour le VNET managé à l’aide de la commande
az aks createavec l’indicateur--enable-api-server-vnet-integration.az aks create --name <cluster-name> \ --resource-group <resource-group> \ --location <location> \ --network-plugin azure \ --enable-apiserver-vnet-integration \ --generate-ssh-keys
Déployer un cluster privé
Déployez un cluster AKS privé avec l’intégration au réseau virtuel du serveur d’API pour le VNET managé à l’aide de la commande
az aks createavec les indicateurs--enable-api-server-vnet-integrationet--enable-private-cluster.az aks create --name <cluster-name> \ --resource-group <resource-group> \ --location <location> \ --network-plugin azure \ --enable-private-cluster \ --enable-apiserver-vnet-integration \ --generate-ssh-keys
Créer un cluster privé AKS doté de l’intégration au réseau virtuel du serveur d’API en mode Apporter votre propre VNet
Lorsque vous utilisez bring-your-own VNet, vous devez créer et déléguer un sous-réseau de serveur API à Microsoft.ContainerService/managedClusters, qui accorde au service AKS des autorisations pour injecter les pods de serveur d’API et l’équilibreur de charge interne dans ce sous-réseau. Vous ne pouvez pas utiliser le sous-réseau pour d’autres charges de travail, mais vous pouvez l’utiliser pour différents clusters AKS situés dans le même réseau virtuel. La taille minimale de sous-réseau de serveur d’API prise en charge est de /28.
L’identité du cluster doit disposer d’autorisations sur le sous-réseau du serveur d’API ainsi que sur le sous-réseau du nœud. L’absence d’autorisations sur le sous-réseau du serveur d’API peut entraîner un échec d’approvisionnement.
Avertissement
Un cluster AKS réserve au moins 9 adresses IP dans l’espace d’adressage du sous-réseau. Le fait de manquer d’adresses IP peut empêcher la mise à l’échelle du serveur d’API et provoquer une panne de celui-ci.
Créer un groupe de ressources
- Créez un groupe de ressources à l’aide de la commande
az group create.
az group create --location <location> --name <resource-group>
Créez un réseau virtuel
Créer un réseau virtuel en utilisant la commande
az network vnet create.az network vnet create --name <vnet-name> \ --resource-group <resource-group> \ --location <location> \ --address-prefixes 172.19.0.0/16Créez un sous-réseau de serveur d’API à l’aide de la commande
az network vnet subnet create.az network vnet subnet create --resource-group <resource-group> \ --vnet-name <vnet-name> \ --name <apiserver-subnet-name> \ --delegations Microsoft.ContainerService/managedClusters \ --address-prefixes 172.19.0.0/28Créez un sous-réseau de cluster à l’aide de la commande
az network vnet subnet create.az network vnet subnet create --resource-group <resource-group> \ --vnet-name <vnet-name> \ --name <cluster-subnet-name> \ --address-prefixes 172.19.1.0/24
Créer une identité managée et lui accorder des autorisations sur le réseau virtuel
Créez une identité managée à l’aide de la commande
az identity create.az identity create --resource-group <resource-group> --name <managed-identity-name> --location <location>Attribuez le rôle Contributeur réseau au sous-réseau du serveur d’API à l’aide de la commande
az role assignment create.az role assignment create --scope <apiserver-subnet-resource-id> \ --role "Network Contributor" \ --assignee <managed-identity-client-id>Attribuez le rôle Contributeur réseau au sous-réseau du serveur d’API à l’aide de la commande
az role assignment create.az role assignment create --scope <cluster-subnet-resource-id> \ --role "Network Contributor" \ --assignee <managed-identity-client-id>
Déployer un cluster public
Déployez un cluster AKS public avec l’intégration au réseau virtuel du serveur d’API pour le réseau virtuel managé à l’aide de la commande
az aks createavec l’indicateur--enable-api-server-vnet-integration.az aks create --name <cluster-name> \ --resource-group <resource-group> \ --location <location> \ --network-plugin azure \ --enable-apiserver-vnet-integration \ --vnet-subnet-id <cluster-subnet-resource-id> \ --apiserver-subnet-id <apiserver-subnet-resource-id> \ --assign-identity <managed-identity-resource-id> \ --generate-ssh-keys
Déployer un cluster privé
Déployez un cluster AKS privé avec l’intégration au réseau virtuel du serveur d’API à l’aide de la commande
az aks createavec les indicateurs--enable-api-server-vnet-integrationet--enable-private-cluster.az aks create --name <cluster-name> \ --resource-group <resource-group> \ --location <location> \ --network-plugin azure \ --enable-private-cluster \ --enable-apiserver-vnet-integration \ --vnet-subnet-id <cluster-subnet-resource-id> \ --apiserver-subnet-id <apiserver-subnet-resource-id> \ --assign-identity <managed-identity-resource-id> \ --generate-ssh-keys
Convertir un cluster AKS existant en intégration au réseau virtuel du serveur d’API
Avertissement
L’intégration au réseau virtuel du serveur d’API est une fonctionnalité unidirectionnel et sensible à la capacité.
Redémarrage manuel requis.
Après avoir activé l’intégration au réseau virtuel du serveur d’API à l’aideaz aks update --enable-apiserver-vnet-integrationde , vous devez redémarrer immédiatement le cluster pour que la modification prenne effet. Ce redémarrage n’est pas automatisé. Le retard du redémarrage augmente le risque d’indisponibilité de la capacité, ce qui peut empêcher le démarrage du serveur d’API.La capacité est validée, mais pas réservée.
AKS valide la capacité régionale lorsque vous activez la fonctionnalité sur un cluster existant, mais cette validation ne réserve pas de capacité. Si le redémarrage est retardé et que la capacité devient indisponible en attendant, le cluster risque de ne pas démarrer après un arrêt ou un redémarrage. Les clusters qui ont activé cette fonctionnalité avant la disponibilité générale (GA) ou qui n’ont pas encore redémarré depuis l’activation ne seront pas soumis à la validation de la capacité.La fonctionnalité ne peut pas être désactivée.
Une fois activée, la fonctionnalité est permanente. Vous ne pouvez pas désactiver l’intégration au réseau virtuel du serveur d’API.
Cette mise à niveau effectue une mise à jour de la version de l'image de nœud sur tous les pools de nœuds et redémarre toutes les charges de travail pendant qu'elles subissent une mise à jour de l'image.
Avertissement
La conversion d’un cluster en intégration au réseau virtuel du serveur d’API entraîne la modification de l’adresse IP du serveur d’API, bien que le nom d’hôte reste le même. Si l’adresse IP du serveur d’API a été configurée dans des pare-feu ou des règles de groupe de sécurité réseau, ces règles peuvent nécessiter une mise à jour.
Mettez à jour votre cluster vers API Server VNet Integration à l’aide de la commande
az aks updateavec l’indicateur--enable-apiserver-vnet-integration.az aks update --name <cluster-name> \ --resource-group <resource-group> \ --enable-apiserver-vnet-integration \ --apiserver-subnet-id <apiserver-subnet-resource-id>
Activer ou désactiver le mode cluster privé sur un cluster existant avec l’intégration au réseau virtuel du serveur d’API
Les clusters AKS configurés avec l’intégration au réseau virtuel du serveur d’API peuvent avoir l’accès au réseau public ou le mode cluster privé activé ou désactivé sans redéploiement du cluster. Le nom d’hôte du serveur d’API ne change pas, tandis que les entrées DNS publiques sont modifiées ou supprimées si nécessaire.
Remarque
--disable-private-cluster est actuellement en préversion. Pour plus d’informations, consultez Niveaux de référence et de support.
Activer le mode cluster privé
Activez le mode cluster privé à l’aide de la commande
az aks updateavec l’indicateur--enable-private-cluster.az aks update --name <cluster-name> \ --resource-group <resource-group> \ --enable-private-cluster
Désactiver le mode cluster privé
Désactivez le mode cluster privé à l’aide de la commande
az aks updateavec l’indicateur--disable-private-cluster.az aks update --name <cluster-name> \ --resource-group <resource-group> \ --disable-private-cluster
Se connecter au cluster à l’aide de kubectl
Configurez
kubectlpour qu’il se connecte à votre cluster à l’aide de la commandeaz aks get-credentials.az aks get-credentials --resource-group <resource-group> --name <cluster-name>
Exposer le serveur d’API via Private Link
Vous pouvez exposer le point de terminaison du serveur d’API d’un cluster privé avec l’intégration au réseau virtuel du serveur d’API à l’aide d’Azure Private Link. Les étapes suivantes montrent comment créer un service Private Link (PLS) dans le réseau virtuel du cluster et comment se connecter à celui-ci à partir d’un autre réseau virtuel ou d’un autre abonnement à l’aide d’un point de terminaison privé.
Créer un cluster privé d’intégration de réseau virtuel du serveur d’API
Créez un cluster AKS privé avec l'intégration du serveur d'API au réseau virtuel en utilisant la commande
az aks createavec les indicateurs--enable-api-server-vnet-integrationet--enable-private-cluster.az aks create --name <cluster-name> \ --resource-group <resource-group> \ --location <location> \ --enable-private-cluster \ --enable-apiserver-vnet-integration
Pour plus d’informations sur la configuration de Private Link avec l’intégration au réseau virtuel du serveur d’API, consultez Private Link avec l’intégration au réseau virtuel du serveur d’API.
Règles de sécurité du groupe de sécurité réseau
Tout le trafic au sein du réseau virtuel est autorisé par défaut. Toutefois, si vous avez ajouté des règles de groupe de sécurité réseau (règles NSG) pour restreindre le trafic entre différents sous-réseaux, assurez-vous que les règles de sécurité NSG autorisent les types de communication suivants :
| Destination | Origine | Protocol | Port | Utilisation |
|---|---|---|---|---|
| CIDR du sous-réseau APIServer | Sous-réseau de cluster | TCP | 443 et 4443 | Obligatoire pour activer la communication entre Nodes et le serveur d’API. |
| CIDR du sous-réseau APIServer | Azure Load Balancer | TCP | 9 988 | Obligatoire pour activer la communication entre Azure Load Balancer et le serveur d’API. Vous pouvez également activer toutes les communications entre Azure Load Balancer et le CIDR du sous-réseau du serveur d’API. |
Étapes suivantes
- Pour connaître les meilleures pratiques associées, consultez Meilleures pratiques relatives à la connectivité réseau et à la sécurité dans AKS.
- Pour obtenir des conseils sur la configuration d’une liaison privée avec l’intégration au réseau virtuel du serveur d’API, consultez Private Link with API Server VNet Integration.