Share via

Usare gli IP pubblici a livello di istanza nel servizio Azure Kubernetes (AKS)

  • Articolo

I nodi del servizio Azure Kubernetes non richiedono i propri IP pubblici per la comunicazione. Tuttavia, gli scenari possono richiedere che i nodi in un pool di nodi ricevano i propri indirizzi IP pubblici dedicati. Uno scenario comune riguarda i carichi di lavoro di gioco, in cui una console deve stabilire una connessione diretta a una macchina virtuale cloud per ridurre al minimo gli hop. Questo scenario può essere ottenuto nel servizio Azure Kubernetes usando l'IP pubblico del nodo.

Fare clic su Crea un nuovo gruppo di risorse.

az group create --name myResourceGroup2 --location eastus

Creare un nuovo cluster del servizio Azure Kubernetes e collegare un IP pubblico per i nodi. Ogni nodo nel pool di nodi riceve un IP pubblico univoco. È possibile verificarlo esaminando le istanze del set di scalabilità di macchine virtuali.

az aks create --resource-group MyResourceGroup2 --name MyManagedCluster --location eastus  --enable-node-public-ip

Per i cluster del servizio Azure Kubernetes esistenti, è possibile anche aggiungere un nuovo pool di nodi e collegare un IP pubblico per i nodi.

az aks nodepool add --resource-group MyResourceGroup2 --cluster-name MyManagedCluster --name nodepool2 --enable-node-public-ip

Usare un prefisso IP pubblico

Sono molti i vantaggi dell'uso di un prefisso IP pubblico. Il servizio Azure Kubernetes supporta l'uso di indirizzi da un prefisso IP pubblico esistente per i nodi passando l'ID risorsa con il flag node-public-ip-prefix durante la creazione di un nuovo cluster o l'aggiunta di un pool di nodi.

Innanzitutto, creare un prefisso IP pubblico usando il comando az network public-ip prefix create:

az network public-ip prefix create --length 28 --location eastus --name MyPublicIPPrefix --resource-group MyResourceGroup3

Visualizzare l'output e prendere nota dell'id per il prefisso:

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

Infine, quando si crea un nuovo cluster o si aggiunge un nuovo pool di nodi, usare il flag node-public-ip-prefix e passare l'ID risorsa del prefisso:

az aks create --resource-group MyResourceGroup3 --name MyManagedCluster --location eastus --enable-node-public-ip --node-public-ip-prefix /subscriptions/<subscription-id>/resourcegroups/MyResourceGroup3/providers/Microsoft.Network/publicIPPrefixes/MyPublicIPPrefix

Individuare IP pubblici per i nodi

Per individuare gli IP pubblici per i nodi è possibile usare le seguenti procedure:

Importante

Il gruppo di risorse del nodo contiene i nodi e i relativi IP pubblici. Usare il gruppo di risorse del nodo durante l'esecuzione dei comandi per individuare gli IP pubblici per i nodi.

az vmss list-instance-public-ips --resource-group MC_MyResourceGroup2_MyManagedCluster_eastus --name YourVirtualMachineScaleSetName

Usare tag IP pubblici in indirizzi IP pubblici del nodo

I tag di IP pubblici possono essere usati negli IP pubblici dei nodi per applicare la funzionalità Preferenza di routing di Azure.

Requisiti

  • È obbligatorio il servizio Azure Kubernetes versione 1.24 o successiva.

Creare un nuovo cluster usando la preferenza di routing Internet

az aks create --name <clusterName> --location <location> --resource-group <resourceGroup> \
  --enable-node-public-ip \
  --node-public-ip-tags RoutingPreference=Internet

Aggiungere un pool di nodi con la preferenza di routing Internet

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

Consentire le connessioni alle porte host e aggiungere pool di nodi ai gruppi di sicurezza delle applicazioni

I nodi del servizio Azure Kubernetes che usano IP pubblici dei nodi che ospitano i servizi nell'indirizzo host devono avere una regola del gruppo di sicurezza di rete aggiunta per consentire il traffico. L'aggiunta delle porte desiderate nella configurazione del pool di nodi creerà le regole di autorizzazione appropriate nel gruppo di sicurezza di rete del cluster.

Se nella subnet è presente un gruppo di sicurezza di rete con un cluster che usa una rete virtuale bring-your-own, è necessario aggiungere una regola di autorizzazione a tale gruppo di sicurezza di rete. Ciò può essere limitato ai nodi di un determinato pool di nodi aggiungendo il pool di nodi a un gruppo di sicurezza delle applicazioni (ASG). Un ASG verrà creato per impostazione predefinita nel gruppo di risorse gestite se sono specificate le porte host consentite. I nodi possono anche essere aggiunti a uno o più gruppi di sicurezza di rete personalizzati specificando l'ID risorsa dei gruppi di sicurezza di rete nei parametri del pool di nodi.

Formato della specifica della porta host

Quando si specifica l'elenco di porte da consentire, usare un elenco separato da virgole con voci nel formato di port/protocol o startPort-endPort/protocol.

Esempi:

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

Requisiti

  • È obbligatorio il servizio Azure Kubernetes versione 1.24 o successiva.

Creare un nuovo cluster con porte consentite e gruppi di sicurezza delle applicazioni

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

Aggiungere un nuovo pool con porte consentite e gruppi di sicurezza delle applicazioni

  --resource-group <resourceGroup> \
  --cluster-name <clusterName> \
  --name <nodepoolName> \
  --allowed-host-ports 80/tcp,443/tcp,53/udp,40000-60000/tcp,40000-50000/udp \
  --asg-ids "<asgId>,<asgId>"

Aggiornare le porte consentite e i gruppi di sicurezza delle applicazioni per un pool di nodi

  --resource-group <resourceGroup> \
  --cluster-name <clusterName> \
  --name <nodepoolName> \
  --allowed-host-ports 80/tcp,443/tcp,53/udp,40000-60000/tcp,40000-50000/udp \
  --asg-ids "<asgId>,<asgId>"

Assegnare automaticamente le porte host per i carichi di lavoro dei pod (ANTEPRIMA)

Quando gli IP pubblici sono configurati nei nodi, è possibile usare le porte host per consentire ai pod di ricevere direttamente il traffico senza dover configurare un servizio di bilanciamento del carico. Ciò è particolarmente utile in scenari come il gioco, in cui la natura temporanea dell'IP del nodo e della porta non è un problema perché un servizio matchmaker in un nome host noto può fornire l'host e la porta corretti da usare in fase di connessione. Tuttavia, poiché un solo processo in un host può essere in ascolto sulla stessa porta, l'uso di applicazioni con porte host può causare problemi con la pianificazione. Per evitare questo problema, il servizio Azure Kubernetes consente al sistema di assegnare dinamicamente una porta disponibile in fase di pianificazione, impedendo i conflitti.

Avviso

Il traffico della porta host del pod verrà bloccato dalle regole predefinite del gruppo di sicurezza di rete sul cluster. Questa funzione deve essere combinata con l'autorizzazione delle porte host sul pool di nodi per consentire il flusso del traffico.

Importante

Le funzionalità di anteprima del servizio Azure Kubernetes sono disponibili in modalità self-service e di consenso esplicito. Le anteprime vengono fornite “così come sono” e “come disponibili” e sono escluse dai contratti di servizio e dalla garanzia limitata. Le anteprime del servizio Azure Kubernetes sono parzialmente coperte dal supporto clienti con la massima diligenza possibile. Di conseguenza, queste funzionalità non sono destinate all'uso in produzione. Per altre informazioni, vedere gli articoli di supporto seguenti:

Requisiti

  • È obbligatorio il servizio Azure Kubernetes versione 1.24 o successiva.

Registrare il flag di funzionalità "PodHostPortAutoAssignPreview"

Registrare il flag di funzionalità PodHostPortAutoAssignPreview usando il comando az feature register, come illustrato nell'esempio seguente:

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

Sono necessari alcuni minuti per visualizzare lo stato Registered. Verificare lo stato della registrazione usando il comando az feature show:

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

Quando lo stato diventa Registrato, aggiornare la registrazione del provider di risorse Microsoft.ContainerService usando il comando az provider register:

az provider register --namespace Microsoft.ContainerService

Assegnare automaticamente una porta host a un pod

L'attivazione dell'assegnazione automatica delle porte host viene eseguita distribuendo un carico di lavoro senza porte host e applicando l'annotazione kubernetes.azure.com/assign-hostports-for-containerports con l'elenco di porte che richiedono assegnazioni di porte host. Il valore dell'annotazione deve essere specificato come elenco delimitato da virgole di voci come port/protocol, dove la porta è un singolo numero di porta definito nella specifica Pod e il protocollo è tcp o udp.

Le porte verranno assegnate dall'intervallo 40000-59999 e saranno univoche nel cluster. Le porte assegnate verranno aggiunte anche alle variabili di ambiente all'interno del pod, in modo che l'applicazione possa determinare quali porte sono state assegnate. Il nome della variabile di ambiente sarà nel formato seguente (esempio in basso): <deployment name>_PORT_<port number>_<protocol>_HOSTPORT, quindi un esempio potrebbe essere mydeployment_PORT_8080_TCP_HOSTPORT: 41932.

Di seguito è riportato un esempio di distribuzione echoserver, che mostra il mapping delle porte host per le porte 8080 e 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

Quando viene applicata la distribuzione, le voci hostPort saranno incluse nel file YAML dei singoli pod:

$ 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

Passaggi successivi