Gestire i pool di nodi per un cluster nel servizio Azure Kubernetes

  • Articolo

Nel servizio Azure Kubernetes i nodi della stessa configurazione vengono raggruppati in pool di nodi. Questi pool di nodi contengono le macchine virtuali sottostanti che eseguono le applicazioni. Quando si crea un cluster del servizio Azure Kubernetes, si definisce il numero iniziale di nodi e le relative dimensioni (SKU). Quando le richieste dell'applicazione cambiano, potrebbe essere necessario modificare le impostazioni nei pool di nodi. Ad esempio, potrebbe essere necessario ridimensionare il numero di nodi in un pool di nodi o aggiornare la versione Kubernetes di un pool di nodi.

Questo articolo illustra come gestire uno o più pool di nodi in un cluster del servizio Azure Kubernetes.

Operazioni preliminari

Limiti

Quando si creano e si gestiscono cluster del servizio Azure Kubernetes che supportano pool di nodi multipli, si applicano le limitazioni seguenti:

  • Vedere Quote, limitazioni delle dimensioni delle macchine virtuali e disponibilità delle aree nel servizio Azure Kubernetes.
  • I pool di sistema devono contenere almeno un nodo e i pool di nodi utente possono contenere zero o più nodi.
  • Non è possibile modificare le dimensioni della macchina virtuale di un pool di nodi dopo averlo creato.
  • Quando si creano più pool di nodi in fase di creazione del cluster, tutte le versioni di Kubernetes usate dai pool di nodi devono corrispondere al set di versioni per il piano di controllo. È possibile eseguire aggiornamenti dopo il provisioning del cluster usando le operazioni per pool di nodi.
  • Non è possibile eseguire contemporaneamente operazioni di aggiornamento e scalabilità in un cluster o in un pool di nodi. Se si tenta di eseguirli contemporaneamente, viene visualizzato un errore. Ogni tipo di operazione deve essere completato nella risorsa di destinazione prima della richiesta successiva sulla stessa risorsa. Per altre informazioni, vedere la guida alla risoluzione dei problemi.

Aggiornare un pool a nodo singolo

Nota

La versione dell'immagine del sistema operativo del pool di nodi è associata alla versione Kubernetes del cluster. Si ottengono solo gli aggiornamenti delle immagini del sistema operativo, dopo un aggiornamento del cluster.

In questo esempio viene aggiornato il pool di nodi mynodepool. Poiché sono presenti due pool di nodi, è necessario usare il comando az aks nodepool upgrade per eseguire l'aggiornamento.

  1. Verificare la presenza di eventuali aggiornamenti disponibili usando il comando az aks get-upgrades.

    az aks get-upgrades --resource-group myResourceGroup --name myAKSCluster

  2. Aggiornare il pool di nodi mynodepool usando il comando az aks nodepool upgrade.

    az aks nodepool upgrade \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name mynodepool \
    --kubernetes-version KUBERNETES_VERSION \
    --no-wait

  3. Elencare lo stato dei pool di nodi usando il comando az aks nodepool list.

    az aks nodepool list --resource-group myResourceGroup --cluster-name myAKSCluster

    L'output di esempio seguente mostra mynodepool si trova nello stato Aggiornamento:

    [
  {
    ...
    "count": 3,
    ...
    "name": "mynodepool",
    "orchestratorVersion": "KUBERNETES_VERSION",
    ...
    "provisioningState": "Upgrading",
    ...
    "vmSize": "Standard_DS2_v2",
    ...
  },
  {
    ...
    "count": 2,
    ...
    "name": "nodepool1",
    "orchestratorVersion": "1.15.7",
    ...
    "provisioningState": "Succeeded",
    ...
    "vmSize": "Standard_DS2_v2",
    ...
  }
]

    L'aggiornamento dei nodi alla versione specificata richiede alcuni minuti.

Come procedura consigliata, è consigliabile aggiornare tutti i pool di nodi in un cluster del servizio Azure Kubernetes alla stessa versione di Kubernetes. Il comportamento predefinito di az aks upgrade consiste nell'aggiornare tutti i pool di nodi insieme al piano di controllo per ottenere questo allineamento. La possibilità di aggiornare singoli pool di nodi consente di eseguire un aggiornamento in sequenza e pianificare i pod tra i pool di nodi per mantenere il tempo di attività dell'applicazione entro i vincoli indicati in precedenza.

Aggiornare un piano di controllo del cluster con più pool di nodi

Nota

Kubernetes usa lo schema di controllo del Versionamento Semantico standard. Il numero di versione è espresso come x.y.z, dove x è la versione principale, y è la versione secondaria e z è la versione patch. Ad esempio, nella versione 1.12.6, 1 è la versione principale, 12 è la versione secondaria e 6 è la versione patch. La versione Kubernetes del piano di controllo e il pool di nodi iniziale vengono impostati durante la creazione del cluster. Gli altri pool di nodi hanno la versione di Kubernetes impostata quando vengono aggiunti al cluster. Le versioni di Kubernetes possono variare tra pool di nodi e tra un pool di nodi e il piano di controllo.

A un cluster del servizio Azure Kubernetes sono associati due oggetti risorsa cluster con le versioni di Kubernetes:

  1. Versione Kubernetes del piano di controllo del cluster e
  2. Pool di nodi con una versione di Kubernetes.

Il piano di controllo esegue il mapping a uno o più pool di nodi. Il comportamento di un'operazione di aggiornamento dipende dal comando dell'interfaccia della riga di comando di Azure usato.

  • az aks upgrade aggiorna il piano di controllo e tutti i pool di nodi nel cluster alla stessa versione di Kubernetes.
  • az aks upgrade con il flag --control-plane-only aggiorna solo il piano di controllo del cluster e lascia invariati tutti i pool di nodi.
  • az aks nodepool upgrade aggiorna solo il pool di nodi di destinazione con la versione di Kubernetes specificata.

Regole di convalida per gli aggiornamenti

Gli aggiornamenti di Kubernetes per un piano di controllo del cluster e i pool di nodi vengono convalidati usando i set di regole seguenti:

  • Regole per le versioni valide per aggiornare i pool di nodi:

    • La versione del pool di nodi deve avere la stessa versione principale del piano di controllo.
    • Il pool di nodi versione secondaria deve essere entro due versioni secondarie della versione del piano di controllo.
    • La versione del pool di nodi non può essere maggiore della versione del controllo major.minor.patch.

  • Regole per l'invio di un'operazione di aggiornamento:

    • Non è possibile effettuare il downgrade del piano di controllo o di una versione Kubernetes del pool di nodi.
    • Se non viene specificata una versione Kubernetes del pool di nodi, il comportamento dipende dal client. Nei modelli di Resource Manager la dichiarazione esegue il fallback alla versione esistente definita per il pool di nodi. Se non viene impostato alcun valore, viene utilizzata la versione del piano di controllo per eseguire il fallback.
    • Non è possibile inviare contemporaneamente più operazioni su un singolo piano di controllo o su una singola risorsa del pool di nodi. È possibile aggiornare o ridimensionare un piano di controllo o un pool di nodi in un determinato momento.

Ridimensionare manualmente un pool di nodi

Man mano che le richieste del carico di lavoro dell'applicazione cambiano, potrebbe essere necessario ridimensionare il numero di nodi in un pool di nodi. Il numero di nodi può essere ridimensionato verso l'alto o verso il basso.

  1. Ridimensionare il numero di nodi in un pool di nodi usando il comando az aks node pool scale.

    az aks nodepool scale \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name mynodepool \
    --node-count 5 \
    --no-wait

  2. Elencare lo stato dei pool di nodi usando il comando az aks node pool list.

    az aks nodepool list --resource-group myResourceGroup --cluster-name myAKSCluster

    L'output di esempio seguente mostra che mynodepool si trova nello stato Scaling con un nuovo conteggio di cinque nodi:

    [
  {
    ...
    "count": 5,
    ...
    "name": "mynodepool",
    "orchestratorVersion": "1.15.7",
    ...
    "provisioningState": "Scaling",
    ...
    "vmSize": "Standard_DS2_v2",
    ...
  },
  {
    ...
    "count": 2,
    ...
    "name": "nodepool1",
    "orchestratorVersion": "1.15.7",
    ...
    "provisioningState": "Succeeded",
    ...
    "vmSize": "Standard_DS2_v2",
    ...
  }
]

    Il completamento dell'operazione di scalabilità richiede alcuni minuti.

Ridimensionare automaticamente un pool di nodi specifico usando il ridimensionamento automatico del cluster

Il servizio Azure Kubernetes offre una funzionalità separata per ridimensionare automaticamente i pool di nodi con una funzionalità denominata scalabilità automatica del cluster. È possibile abilitare questa funzionalità con conteggi di scalabilità minimo e massimo univoci per pool di nodi.

Per altre informazioni, vedere usare l'utilità di scalabilità automatica del cluster.

Rimuovere macchine virtuali specifiche nel pool di nodi esistente

Nota

Quando si elimina una macchina virtuale con questo comando, il servizio Azure Kubernetes non esegue il blocco e lo svuotamento. Per ridurre al minimo l'interruzione dei pod di riprogrammazione attualmente in esecuzione nella macchina virtuale che si prevede di eliminare, eseguire un blocco e uno svuotamento nella macchina virtuale prima dell'eliminazione. Per altre informazioni su come eseguire il blocco e lo svuotamento, vedere lo scenario di esempio fornito nell'esercitazione sul ridimensionamento dei pool di nodi.

  1. Elencare i nodi esistenti tramite il comando kubectl get nodes.

    kubectl get nodes

    L'output dovrebbe essere simile all'esempio di output seguente:

    NAME                                 STATUS   ROLES   AGE   VERSION
aks-mynodepool-20823458-vmss000000   Ready    agent   63m   v1.21.9
aks-mynodepool-20823458-vmss000001   Ready    agent   63m   v1.21.9
aks-mynodepool-20823458-vmss000002   Ready    agent   63m   v1.21.9

  2. Eliminare le macchine virtuali specificate tramite il comando az aks nodepool delete-machines. Assicurarsi di sostituire i segnaposto con i propri valori.

    az aks nodepool delete-machines \
    --resource-group <resource-group-name> \
    --cluster-name <cluster-name> \
    --name <node-pool-name>
    --machine-names <vm-name-1> <vm-name-2>

  3. Verificare che le macchine virtuali siano state eliminate correttamente tramite il comando kubectl get nodes.

    kubectl get nodes

    L'output non deve più includere le macchine virtuali specificate nel comando az aks nodepool delete-machines.

Associare gruppi di prenotazioni di capacità ai pool di nodi

Man mano che le richieste del carico di lavoro cambiano, è possibile associare i gruppi di prenotazioni di capacità esistenti ai pool di nodi per garantire la capacità allocata per i pool di nodi.

Prerequisiti per l'uso dei gruppi di prenotazioni di capacità con il servizio Azure Kubernetes

  • Usare l'interfaccia della riga di comando versione 2.56 o successiva e l'API versione 2023-10-01 o successiva.

  • Il gruppo di prenotazioni di capacità deve esistere già e deve contenere almeno una prenotazione di capacità. In caso contrario, il pool di nodi viene aggiunto al cluster con un avviso e non viene associato alcun gruppo di prenotazioni di capacità. Per altre informazioni, vedere gruppi di prenotazioni di capacità.

  • È necessario creare un'identità gestita assegnata dall'utente per il gruppo di risorse che contiene il gruppo di prenotazioni di capacità (CRG). Le identità gestite assegnate dal sistema non funzioneranno per questa funzionalità. Nell'esempio seguente sostituire le variabili di ambiente con valori personalizzati.

    IDENTITY_NAME=myID
RG_NAME=myResourceGroup
CLUSTER_NAME=myAKSCluster
VM_SKU=Standard_D4s_v3
NODE_COUNT=2
LOCATION=westus2
az identity create --name $IDENTITY_NAME --resource-group $RG_NAME  
IDENTITY_ID=$(az identity show --name $IDENTITY_NAME --resource-group $RG_NAME --query identity.id -o tsv)

  • È necessario assegnare il ruolo Contributor all'identità assegnata dall'utente creata in precedenza. Per altre informazioni, vedere Passaggi per assegnare un ruolo di Azure.

  • Creare un nuovo cluster e assegnare l'identità appena creata.

      az aks create \
      --resource-group $RG_NAME \
      --name $CLUSTER_NAME \
      --location $LOCATION \
      --node-vm-size $VM_SKU --node-count $NODE_COUNT \
      --assign-identity $IDENTITY_ID \
      --generate-ssh-keys

  • È anche possibile assegnare l'identità gestita dall'utente in un cluster gestito esistente con il comando update.

    az aks update \
    --resource-group $RG_NAME \
    --name $CLUSTER_NAME \
    --location $LOCATION \
    --node-vm-size $VM_SKU \
    --node-count $NODE_COUNT \
    --enable-managed-identity \
    --assign-identity $IDENTITY_ID

Associare un gruppo di prenotazioni di capacità esistente a un pool di nodi

Associare un gruppo di prenotazioni di capacità esistente a un pool di nodi usando il comando az aks nodepool add e specificare un gruppo di prenotazioni di capacità con il flag --crg-id. Nell'esempio seguente si presuppone che sia presente un CRG denominato "myCRG".

RG_NAME=myResourceGroup
CLUSTER_NAME=myAKSCluster
NODEPOOL_NAME=myNodepool
CRG_NAME=myCRG
CRG_ID=$(az capacity reservation group show --capacity-reservation-group $CRG_NAME --resource-group $RG_NAME --query id -o tsv)
az aks nodepool add --resource-group $RG_NAME --cluster-name $CLUSTER_NAME --name $NODEPOOL_NAME --crg-id $CRG_ID

Associare un gruppo di prenotazioni di capacità esistente a un pool di nodi di sistema

Per associare un gruppo di prenotazioni di capacità esistente a un pool di nodi di sistema, associare il cluster all'identità assegnata dall'utente con il ruolo Collaboratore nel CRG e il CRG stesso durante la creazione del cluster. Usare il comando az aks create con i flag --assign-identity e --crg-id.

IDENTITY_NAME=myID
RG_NAME=myResourceGroup
CLUSTER_NAME=myAKSCluster
NODEPOOL_NAME=myNodepool
CRG_NAME=myCRG
CRG_ID=$(az capacity reservation group show --capacity-reservation-group $CRG_NAME --resource-group $RG_NAME --query id -o tsv)
IDENTITY_ID=$(az identity show --name $IDENTITY_NAME --resource-group $RG_NAME --query identity.id -o tsv)

az aks create \
    --resource-group $RG_NAME \
    --cluster-name $CLUSTER_NAME \
    --crg-id $CRG_ID \
    --assign-identity $IDENTITY_ID \
    --generate-ssh-keys

Nota

L'eliminazione di un pool di nodi dissocia in modo implicito il pool di nodi da qualsiasi gruppo di prenotazioni di capacità associato prima dell'eliminazione del pool di nodi. L'eliminazione di un cluster dissocia in modo implicito tutti i pool di nodi in tale cluster dai gruppi di prenotazioni di capacità associati.

Nota

Non è possibile aggiornare un pool di nodi esistente con un gruppo di prenotazioni di capacità. L'approccio consigliato consiste nell'associare un gruppo di prenotazioni di capacità durante la creazione del pool di nodi.

Specificare le dimensioni di una macchina virtuale per un pool di nodi

Potrebbe essere necessario creare pool di nodi con dimensioni e funzionalità diverse delle macchine virtuali. Ad esempio, è possibile creare un pool di nodi che contiene nodi con grandi quantità di CPU o memoria o un pool di nodi che fornisce supporto GPU. Nella sezione successiva si usano taint e tolleranze per indicare all'utilità di pianificazione Kubernetes come limitare l'accesso ai pod che possono essere eseguiti in questi nodi.

Nell'esempio seguente viene creato un pool di nodi basato su GPU che usa le dimensioni della macchina virtuale Standard_NC6s_v3. Queste macchine virtuali sono basate sulla scheda NVIDIA Tesla K80. Per informazioni, vedere Dimensioni disponibili per le macchine virtuali Linux in Azure.

  1. Creare un pool di nodi usando il comando az aks node pool add. Specificare il nome gpunodepool e usare il parametro --node-vm-size per specificare le dimensioni Standard_NC6.

    az aks nodepool add \
    --resource-group myResourceGroup \
    --cluster-name myAKSCluster \
    --name gpunodepool \
    --node-count 1 \
    --node-vm-size Standard_NC6s_v3 \
    --no-wait

  2. Controllare lo stato del pool di nodi usando il comando az aks nodepool list.

    az aks nodepool list --resource-group myResourceGroup --cluster-name myAKSCluster

    L'output di esempio seguente mostra che il pool di nodi gpunodepool sta Creando nodi con il VmSize specificato:

    [
  {
    ...
    "count": 1,
    ...
    "name": "gpunodepool",
    "orchestratorVersion": "1.15.7",
    ...
    "provisioningState": "Creating",
    ...
    "vmSize": "Standard_NC6s_v3",
    ...
  },
  {
    ...
    "count": 2,
    ...
    "name": "nodepool1",
    "orchestratorVersion": "1.15.7",
    ...
    "provisioningState": "Succeeded",
    ...
    "vmSize": "Standard_DS2_v2",
    ...
  }
]

    La creazione del gpunodepool richiede alcuni minuti.

Specificare un taint, un'etichetta o un tag per un pool di nodi

Quando si crea un pool di nodi, è possibile aggiungere tag, etichette o tag. Quando si aggiunge un taint, un'etichetta o un tag, tutti i nodi all'interno del pool di nodi ottengono anche tale taint, etichetta o tag.

Importante

L'aggiunta di taint, etichette o tag ai nodi deve essere eseguita per l'intero pool di nodi usando az aks nodepool. Non è consigliabile usare kubectl per applicare taint, etichette o tag a singoli nodi in un pool di nodi.

Impostare i contenitori del pool di nodi

L'AKS supporta due tipi di taint dei nodi: taint dei nodi e taint di inizializzazione dei nodi (anteprima). Per altre informazioni, vedere Usare i taint dei nodi in un cluster del servizio Azure Kubernetes.

Per altre informazioni su come usare le funzionalità pianificate di Kubernetes avanzate, vedere Procedure consigliate per le funzionalità avanzate dell'utilità di pianificazione nel servizio Azure Kubernetes

Impostare le tolleranze del pool di nodi

Nel passaggio precedente è stato applicato il taint sku=gpu:NoSchedule durante la creazione del pool di nodi. Il manifesto YAML di esempio seguente usa una tolleranza per consentire all'utilità di pianificazione Kubernetes di eseguire un pod NGINX in un nodo del pool di nodi.

  1. Creare un file denominato nginx-toleration.yaml e copiarlo nell'esempio YAML seguente.

    apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
 - image: mcr.microsoft.com/oss/nginx/nginx:1.15.9-alpine
    name: mypod
    resources:
      requests:
        cpu: 100m
        memory: 128Mi
      limits:
        cpu: 1
        memory: 2G
  tolerations:
 - key: "sku"
    operator: "Equal"
    value: "gpu"
    effect: "NoSchedule"

  2. Pianificare il pod usando il comando kubectl apply.

    kubectl apply -f nginx-toleration.yaml

    Sono necessari alcuni secondi per pianificare il pod ed eseguire il pull dell'immagine NGINX.

  3. Controllare lo stato usando il comando kubectl describe pod.

    kubectl describe pod mypod

    L'output di esempio condensato seguente mostra che viene applicata la tolleranza sku=gpu:NoSchedule. Nella sezione degli eventi l'utilità di pianificazione ha assegnato il pod al nodo aks-taintnp-28993262-vmss0000000:

    [...]
Tolerations:     node.kubernetes.io/not-ready:NoExecute for 300s
                 node.kubernetes.io/unreachable:NoExecute for 300s
                 sku=gpu:NoSchedule
Events:
  Type    Reason     Age    From                Message
  ----    ------     ----   ----                -------
  Normal  Scheduled  4m48s  default-scheduler   Successfully assigned default/mypod to aks-taintnp-28993262-vmss000000
  Normal  Pulling    4m47s  kubelet             pulling image "mcr.microsoft.com/oss/nginx/nginx:1.15.9-alpine"
  Normal  Pulled     4m43s  kubelet             Successfully pulled image "mcr.microsoft.com/oss/nginx/nginx:1.15.9-alpine"
  Normal  Created    4m40s  kubelet             Created container
  Normal  Started    4m40s  kubelet             Started container

    Solo i pod con questa tolleranza applicata possono essere pianificati nei nodi in taintnp. Tutti gli altri pod vengono pianificati nel pool di nodi nodepool1. Se si creano più pool di nodi, è possibile usare taint e tolleranze per limitare i pod pianificati in tali risorse del nodo.

Impostazione delle etichette del pool di nodi

Per altre informazioni, vedere Usare le etichette in un cluster del servizio Azure Kubernetes.

Impostazione dei tag di Azure per il pool di nodi

Per altre informazioni, vedere Usare i tag di Azure nel servizio Azure Kubernetes.

Gestire i pool di nodi usando un modello di Resource Manager

Quando si usa un modello di Azure Resource Manager per creare e gestire le risorse, è possibile modificare le impostazioni nel modello e ridistribuirlo per aggiornare le risorse. Con i pool di nodi del servizio Azure Kubernetes non è possibile aggiornare il profilo del pool di nodi iniziale dopo aver creato il cluster del servizio Azure Kubernetes. Questo comportamento significa che non è possibile aggiornare un modello di Resource Manager esistente, apportare una modifica ai pool di nodi e quindi ridistribuire il modello. È invece necessario creare un modello di Resource Manager separato che aggiorna i pool di nodi per il cluster del servizio Azure Kubernetes esistente.

  1. Creare un modello, ad esempio aks-agentpools.json, e incollarlo nel manifesto di esempio seguente. Assicurarsi di modificare i valori in base alle esigenze. Questo modello di esempio configura le impostazioni seguenti:

    • Aggiorna il pool di nodi Linux denominato myagentpool per eseguire tre nodi.
    • Imposta i nodi nel pool di nodi per eseguire Kubernetes versione 1.15.7.
    • Definisce le dimensioni del nodo come Standard_DS2_v2.
    {
    "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "parameters": {
        "clusterName": {
            "type": "string",
            "metadata": {
                "description": "The name of your existing AKS cluster."
            }
        },
        "location": {
            "type": "string",
            "metadata": {
                "description": "The location of your existing AKS cluster."
            }
        },
        "agentPoolName": {
            "type": "string",
            "defaultValue": "myagentpool",
            "metadata": {
                "description": "The name of the agent pool to create or update."
            }
        },
        "vnetSubnetId": {
            "type": "string",
            "defaultValue": "",
            "metadata": {
                "description": "The Vnet subnet resource ID for your existing AKS cluster."
            }
        }
    },
    "variables": {
        "apiVersion": {
            "aks": "2020-01-01"
        },
        "agentPoolProfiles": {
            "maxPods": 30,
            "osDiskSizeGB": 0,
            "agentCount": 3,
            "agentVmSize": "Standard_DS2_v2",
            "osType": "Linux",
            "vnetSubnetId": "[parameters('vnetSubnetId')]"
        }
    },
    "resources": [
        {
            "apiVersion": "2020-01-01",
            "type": "Microsoft.ContainerService/managedClusters/agentPools",
            "name": "[concat(parameters('clusterName'),'/', parameters('agentPoolName'))]",
            "location": "[parameters('location')]",
            "properties": {
                "maxPods": "[variables('agentPoolProfiles').maxPods]",
                "osDiskSizeGB": "[variables('agentPoolProfiles').osDiskSizeGB]",
                "count": "[variables('agentPoolProfiles').agentCount]",
                "vmSize": "[variables('agentPoolProfiles').agentVmSize]",
                "osType": "[variables('agentPoolProfiles').osType]",
                "type": "VirtualMachineScaleSets",
                "vnetSubnetID": "[variables('agentPoolProfiles').vnetSubnetId]",
                "orchestratorVersion": "1.15.7"
            }
        }
    ]
}

  2. Distribuire il modello usando il comando az deployment group create.

    az deployment group create \
    --resource-group myResourceGroup \
    --template-file aks-agentpools.json

    Suggerimento

    È possibile aggiungere un tag al pool di nodi aggiungendo la proprietà tag nel modello, come illustrato nell'esempio seguente:

    ...
"resources": [
{
  ...
  "properties": {
    ...
    "tags": {
      "name1": "val1"
    },
    ...
  }
}
...

    L'aggiornamento del cluster del servizio Azure Kubernetes può richiedere alcuni minuti a seconda delle impostazioni e delle operazioni del pool di nodi definite nel modello di Resource Manager.

Passaggi successivi