Partager via


Créer un cluster Azure Kubernetes Service avec l’intégration au réseau virtuel du serveur d’API

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 --version commande.

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 create avec 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 create avec les indicateurs --enable-api-server-vnet-integration et --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

  1. 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/16
    
  2. Cré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/28
    
  3. Cré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

  1. 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>
    
  2. 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>
    
  3. 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 create avec 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 create avec les indicateurs --enable-api-server-vnet-integration et --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’aide az 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 update avec 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 update avec 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 update avec 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 kubectl pour qu’il se connecte à votre cluster à l’aide de la commande az aks get-credentials.

    az aks get-credentials --resource-group <resource-group> --name <cluster-name>
    

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 create avec les indicateurs --enable-api-server-vnet-integration et --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