Partager via

Utiliser des adresses IP publiques au niveau de l’instance dans Azure Kubernetes Service (AKS)

  • Article

Les nœuds AKS n’ont pas besoin de leurs propres adresses IP publiques pour communiquer. Toutefois, certains scénarios peuvent exiger que les nœuds d'un pool de nœuds reçoivent leurs propres adresses IP publiques dédiées. C’est par exemple le cas pour les charges de travail de gaming, où une console doit être directement connectée à une machine virtuelle du cloud afin de réduire les tronçons. Ce scénario peut être exécuté sur AKS à l’aide de l’adresse IP publique des nœuds.

Dans un premier temps, créez un nouveau groupe de ressources.

az group create --name <resourceGroup> --location <region>

Créez un cluster AKS et attachez une adresse IP publique pour vos nœuds. Chacun des nœuds du pool reçoit une adresse IP publique unique. Pour le vérifier, il suffit de regarder les instances du groupe de machines virtuelles identiques.

az aks create \
    --resource-group <resourceGroup> \
    --name <aksClusterName> \
    --location <region> \
    --enable-node-public-ip \
    --generate-ssh-keys

Pour les clusters AKS existants, vous pouvez également ajouter un nouveau pool de nœuds et attacher une adresse IP publique pour vos nœuds.

az aks nodepool add --resource-group <resourceGroup> --cluster-name <aksClusterName> --name <newNodePool> --enable-node-public-ip

Utiliser un préfixe d’adresse IP publique

Il existe un certain nombre d’avantages liés à l’utilisation d’un préfixe d’adresse IP publique. AKS prend en charge l’utilisation d’adresses à partir d’un préfixe d’adresse IP publique existant pour vos nœuds en passant l’ID de ressource avec l’indicateur --node-public-ip-prefix-id lors de la création d’un cluster ou de l’ajout d’un pool de nœuds.

Commencez par créer un préfixe d’adresse IP publique à l’aide de la commande az network public-ip prefix create :

az network public-ip prefix create --length 28 --location <region> --name <publicIPPrefixName> --resource-group <resourceGroup>

Affichez la sortie et notez l’id pour le préfixe :

{
  ...
  "id": "/subscriptions/<subscription-id>/resourceGroups/<resourceGroup>/providers/Microsoft.Network/publicIPPrefixes/<publicIPPrefixName>",
  ...
}

Enfin, lors de la création d’un cluster ou de l’ajout d’un pool de nœuds, utilisez l’indicateur --node-public-ip-prefix-id et transmettez l’ID de ressource du préfixe :

az aks create \
    --resource-group <resourceGroup> \
    --name <aksClusterName> \
    --location <region> \
    --enable-node-public-ip \
    --node-public-ip-prefix-id /subscriptions/<subscription-id>/resourceGroups/<resourceGroup>/providers/Microsoft.Network/publicIPPrefixes/<publicIPPrefixName> \
    --generate-ssh-keys

Localiser des adresses IP publiques pour des nœuds

Vous pouvez localiser les adresses IP publiques de vos nœuds de différentes manières :

Important

Le groupe de ressources du nœud contient les nœuds et leurs adresses IP publiques. Utilisez le groupe de ressources du nœud lorsque vous exécutez des commandes pour rechercher les adresses IP publiques de vos nœuds.

az vmss list-instance-public-ips --resource-group <MC_region_aksClusterName_region> --name <virtualMachineScaleSetName>

Utiliser des balises IP publiques sur des adresses IP publiques de nœud

Les balises IP publiques peuvent être utilisées sur les adresses IP publiques de nœud pour utiliser la fonctionnalité De préférence de routage Azure .

Spécifications

  • AKS version 1.29 ou ultérieure est obligatoire.

Créer un cluster à l’aide de la préférence de routage Internet

az aks create \
    --name <aksClusterName> \
    --location <region> \
    --resource-group <resourceGroup> \
    --enable-node-public-ip \
    --node-public-ip-tags RoutingPreference=Internet \
    --generate-ssh-keys

Ajouter un pool de nœuds avec préférence de routage Internet

az aks nodepool add --cluster-name <aksClusterName> \
  --name <nodePoolName> \
  --location <region> \
  --resource-group <resourceGroup> \
  --enable-node-public-ip \
  --node-public-ip-tags RoutingPreference=Internet

Autoriser les connexions du port hôte et ajouter des pools de nœuds aux groupes de sécurité des applications

Les nœuds AKS utilisant des adresses IP publiques de nœud qui hébergent des services sur leur adresse hôte doivent avoir une règle de groupe de sécurité réseau ajoutée pour autoriser le trafic. L’ajout des ports souhaités dans la configuration du pool de nœuds crée les règles d’autorisation appropriées dans le groupe de sécurité réseau du cluster.

Si un groupe de sécurité réseau est en place sur le sous-réseau avec un cluster utilisant le réseau virtuel apportez votre propre réseau, une règle d’autorisation doit être ajoutée à ce groupe de sécurité réseau. Cela peut être limité aux nœuds d’un pool de nœuds donné en ajoutant le pool de nœuds à un groupe de sécurité d’application (ASG). Un ASG managé est créé par défaut dans le groupe de ressources managé si les ports hôtes autorisés sont spécifiés. Les nœuds peuvent également être ajoutés à un ou plusieurs ASG personnalisés en spécifiant l’ID de ressource du ou des groupes de sécurité réseau dans les paramètres du pool de nœuds.

Format de spécification du port hôte

Lorsque vous spécifiez la liste des ports à autoriser, utilisez une liste séparée par des virgules avec des entrées au format port/protocol ou startPort-endPort/protocol.

Exemples :

  • 80/tcp
  • 80/tcp,443/tcp
  • 53/udp,80/tcp
  • 50000-60000/tcp

Spécifications

  • AKS version 1.29 ou ultérieure est obligatoire.

Créer un cluster avec des ports et des groupes de sécurité d’application autorisés

az aks create \
    --resource-group <resourceGroup> \
    --name <aksClusterName> \
    --nodepool-name <nodePoolName> \
    --nodepool-allowed-host-ports 80/tcp,443/tcp,53/udp,40000-60000/tcp,40000-50000/udp\
    --nodepool-asg-ids "<asgId>,<asgId>" \
    --generate-ssh-keys

Ajouter un nouveau pool de nœuds avec des ports autorisés et des groupes de sécurité d’application

az aks nodepool add \
  --resource-group <resourceGroup> \
  --cluster-name <aksClusterName> \
  --name <nodePoolName> \
  --allowed-host-ports 80/tcp,443/tcp,53/udp,40000-60000/tcp,40000-50000/udp \
  --asg-ids "<asgId>,<asgId>"

Mettre à jour les ports autorisés et les groupes de sécurité d’application pour un pool de nœuds

az aks nodepool update \
  --resource-group <resourceGroup> \
  --cluster-name <aksClusterName> \
  --name <nodePoolName> \
  --allowed-host-ports 80/tcp,443/tcp,53/udp,40000-60000/tcp,40000-50000/udp \
  --asg-ids "<asgId>,<asgId>"

Attribuer automatiquement des ports hôtes pour les charges de travail de pod (PRÉVERSION)

Lorsque les adresses IP publiques sont configurées sur des nœuds, les ports hôtes peuvent être utilisés pour permettre aux pods de recevoir directement le trafic sans avoir à configurer un service d’équilibreur de charge. Cela est particulièrement utile dans les scénarios comme les jeux, où la nature éphémère de l’adresse IP et du port du nœud n’est pas un problème, car un service de matchmaker sur un nom d’hôte bien connu peut fournir l’hôte et le port appropriés à utiliser au moment de la connexion. Toutefois, étant donné qu’un seul processus sur un hôte peut être à l’écoute sur le même port, l’utilisation d’applications avec des ports hôtes peut entraîner des problèmes de planification. Pour éviter ce problème, AKS offre la possibilité au système d’attribuer dynamiquement un port disponible au moment de la planification, ce qui évite les conflits.

Avertissement

Le trafic du port de l’hôte de pod est bloqué par les règles de groupe de sécurité réseau par défaut en place sur le cluster. Cette fonctionnalité doit être combinée avec l’autorisation des ports hôtes sur le pool de nœuds pour autoriser le trafic à circuler.

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 :

Spécifications

  • AKS version 1.29 ou ultérieure est obligatoire.

Enregistrer l'indicateur de fonctionnalité « PodHostPortAutoAssignPreview »

Inscrivez l’indicateur de fonctionnalité PodHostPortAutoAssignPreview à l’aide de la commande az feature register, comme indiqué dans l’exemple suivant :

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

Quelques minutes sont nécessaires pour que l’état s’affiche Registered (Inscrit). Vérifiez l’état de l’inscription à l’aide de la commande az feature show :

az feature show --namespace "Microsoft.ContainerService" --name "PodHostPortAutoAssignPreview"

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

Affecter automatiquement un port hôte à un pod

Le déclenchement de l’attribution automatique de port hôte s’effectue en déployant une charge de travail sans ports hôtes et en appliquant l’annotation kubernetes.azure.com/assign-hostports-for-containerports avec la liste des ports qui nécessitent des affectations de ports hôtes. La valeur de l’annotation doit être spécifiée sous la forme d’une liste d’entrées séparées par des virgules, comme port/protocol, où le port est un numéro de port individuel qui est défini dans la spécification pod et le protocole est tcp ou udp.

Les ports seront attribués à partir de la plage 40000-59999 et seront uniques au sein du cluster. Les ports attribués seront également ajoutés aux variables d’environnement à l’intérieur du pod afin que l’application puisse déterminer quels ports ont été attribués. Le nom de la variable d’environnement mydeployment_PORT_8080_TCP_HOSTPORT: 41932sera au format suivant (exemple ci-dessous) : <deployment name>_PORT_<port number>_<protocol>_HOSTPORT.

Voici un exemple echoserver de déploiement montrant le mappage des ports hôtes pour les ports 8080 et 8443 :

apiVersion: apps/v1
kind: Deployment
metadata:
  name: echoserver-hostport
  labels:
    app: echoserver-hostport
spec:
  replicas: 3
  selector:
    matchLabels:
      app: echoserver-hostport
  template:
    metadata:
      annotations:
        kubernetes.azure.com/assign-hostports-for-containerports: 8080/tcp,8443/tcp
      labels:
        app: echoserver-hostport
    spec:
      nodeSelector:
        kubernetes.io/os: linux
      containers:
        - name: echoserver-hostport
          image: k8s.gcr.io/echoserver:1.10
          ports:
            - name: http
              containerPort: 8080
              protocol: TCP
            - name: https
              containerPort: 8443
              protocol: TCP

Lorsque le déploiement est appliqué, les hostPort entrées sont dans le YAML des pods individuels :

$ kubectl describe pod echoserver-hostport-75dc8d8855-4gjfc
<cut for brevity>
Containers:
  echoserver-hostport:
    Container ID:   containerd://d0b75198afe0612091f412ee7cf7473f26c80660143a96b459b3e699ebaee54c
    Image:          k8s.gcr.io/echoserver:1.10
    Image ID:       k8s.gcr.io/echoserver@sha256:cb5c1bddd1b5665e1867a7fa1b5fa843a47ee433bbb75d4293888b71def53229                                                                                                      Ports:          8080/TCP, 8443/TCP
    Host Ports:     46645/TCP, 49482/TCP
    State:          Running
      Started:      Thu, 12 Jan 2023 18:02:50 +0000
    Ready:          True
    Restart Count:  0
    Environment:
      echoserver-hostport_PORT_8443_TCP_HOSTPORT:  49482
      echoserver-hostport_PORT_8080_TCP_HOSTPORT:  46645

Étapes suivantes