Partager via


Création d’un cluster Azure Kubernetes Service doté de l’intégration au réseau virtuel du serveur d’API (préversion)

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.

Disponibilité des régions

L’intégration au réseau virtuel du serveur d’API est disponible dans toutes les régions Azure.

Prérequis

  • Azure CLI avec l’extension aks-preview 0.5.97 ou version ultérieure.
  • Si vous utilisez ARM ou l’API REST, la version de l’API AKS doit être 2022-04-02-preview ou une version ultérieure.

Installer l’extension Azure CLI aks-preview

Important

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

  • Installez l’extension aks-preview à l’aide de la commande az extension add.

    az extension add --name aks-preview
    
  • Mettez à jour vers la dernière version de l’extension publiée à l’aide de la commande az extension update.

    az extension update --name aks-preview
    

Inscrivez le drapeau de fonctionnalité 'EnableAPIServerVnetIntegrationPreview'

  1. Inscrivez l’indicateur de fonctionnalité EnableAPIServerVnetIntegrationPreview à l’aide de la commande az feature register.

    az feature register --namespace "Microsoft.ContainerService" --name "EnableAPIServerVnetIntegrationPreview"
    

    Quelques minutes sont nécessaires pour que l’état s’affiche Registered (Inscrit).

  2. Vérifiez l’état de l’inscription en utilisant la commande az feature show :

    az feature show --namespace "Microsoft.ContainerService" --name "EnableAPIServerVnetIntegrationPreview"
    
  3. Quand l’état reflète Inscrit, actualisez l’inscription du fournisseur de ressources Microsoft.ContainerService à l’aide de la commande az provider register.

    az provider register --namespace Microsoft.ContainerService
    

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 avec 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

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

Vous pouvez convertir des clusters AKS publics/privés existants en clusters d’intégration au réseau virtuel du serveur API en fournissant un sous-réseau de serveur API qui répond aux exigences répertoriées précédemment. Ces exigences sont les suivantes : dans le même réseau virtuel que les nœuds de cluster, les autorisations accordées pour l’identité du cluster AKS, non utilisées par d’autres ressources telles que le point de terminaison privé et la taille d’au moins /28. La conversion de votre cluster est une migration unidirectionnel. L’intégration au réseau virtuel du serveur d’API ne peut pas être désactivée après son activation sur les clusters.

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 version préliminaire. 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>
    

Règles de sécurité des groupes 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 Source Protocole 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 Équilibrage de charge Azure 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.