Gestione dei cluster GKE con Config Controller e i progetti KRM

Questo tutorial mostra come scrivere i progetti KRM con Config Controller per il provisioning di un cluster Google Kubernetes Engine (GKE) e dell'infrastruttura di rete richiesta, come un Virtual Private Cloud (VPC) e una subnet per ospitare il cluster GKE, e intervalli IP denominati per pod e servizi. Segui la procedura se sei un operatore di cluster GKE e vuoi gestire in modo dichiarativo la configurazione del cluster e l'infrastruttura di networking.

Config Controller è un servizio ospitato per eseguire il provisioning e l'orchestrazione delle risorse Anthos e Google Cloud. Offre un endpoint API in grado di eseguire il provisioning, attivare e orchestrare le risorse Google Cloud come parte di Anthos Config Management.

I progetti KRM sono un modo per pacchettizzare le risorse comunemente utilizzate insieme durante la codifica delle best practice che possono essere implementate in tutta l'organizzazione.

Il progetto base del cluster GKE è un progetto base di KRM che include tutte le risorse necessarie per gestire un cluster GKE oltre a un VPC, a una subnet e a intervalli IP Google Cloud esistenti. Puoi ispirare più volte il progetto base per configurare più cluster.

I progetti di rete sono un insieme di progetti di KRM che ti aiutano a creare i componenti di networking necessari, come VPC, subnet e intervalli IP alias, necessari per creare un cluster GKE. Puoi creare un'istanza di questi progetti più volte per configurare più subnet e intervalli IP alias come richiesto per più cluster.

Obiettivi

  • Crea in modo dichiarativo l'infrastruttura di networking necessaria per ospitare un cluster GKE.
  • Configura un cluster GKE in modo dichiarativo in questa infrastruttura di rete.
  • Applicare la configurazione utilizzando Config Controller.

Costi

Questo tutorial utilizza i seguenti componenti fatturabili di Google Cloud:

Per un elenco completo delle risorse incluse nel progetto base del cluster GKE, consulta la sezione Risorse del pacchetto GKE e i relativi sottopacchetti.

Per generare una stima dei costi basata sull'utilizzo previsto, utilizza il Calcolatore prezzi.

Al termine di questo tutorial, puoi evitare di continuare la fatturazione eliminando le risorse create. Per ulteriori informazioni, consulta la sezione Pulizia.

Requisiti

Prima di iniziare

  1. In Cloud Console, attiva Cloud Shell.

    Attiva Cloud Shell

    Nella parte inferiore di Cloud Console, viene avviata una sessione Cloud Shell che mostra un prompt della riga di comando. Cloud Shell è un ambiente shell con l'interfaccia a riga di comando di Google Cloud già installata e con valori già impostati per il progetto attuale. L'inizializzazione della sessione può richiedere alcuni secondi.

    2. Esegui tutti i comandi in questo tutorial da Cloud Shell.

Configura l'ambiente

In Cloud Shell, esegui questi comandi:

  1. Installa kubectl, l'interfaccia a riga di comando principale per Kubernetes:

    gcloud components install kubectl

  2. Installa kpt, l'interfaccia a riga di comando principale per i progetti KRM:

    gcloud components install kpt

  3. Configura kubectl e kpt per connetterti a Config Controller:

    gcloud anthos config controller get-credentials CONFIG_CONTROLLER_NAME \
    --location COMPUTE_REGION \
    --project CONFIG_CONTROLLER_PROJECT_ID

    Sostituisci quanto segue:

    • CONFIG_CONTROLLER_NAME: il nome del cluster di Config Controller.

    • COMPUTE_REGION: l'area geografica del cluster di Config Controller (ad esempio us-central1).

    • CONFIG_CONTROLLER_PROJECT_ID: l'ID progetto del cluster di Config Controller.

  4. Abilita l'API Resource Manager:

    gcloud services enable cloudresourcemanager.googleapis.com \
    --project PROJECT_ID

    Sostituisci PROJECT_ID con l'ID del progetto.

  5. Verifica che Config Connector sia configurato e in stato integro nello spazio dei nomi del progetto:

    kubectl get ConfigConnectorContext -n PROJECT_NAMESPACE \
    -o "custom-columns=NAMESPACE:.metadata.namespace,NAME:.metadata.name,HEALTHY:.status.healthy"

    Sostituisci PROJECT_NAMESPACE con lo spazio dei nomi che vuoi utilizzare per gestire le risorse del progetto (ad esempio config-control).

    Output di esempio:

    NAMESPACE        NAME                                                HEALTHY
config-control   configconnectorcontext.core.cnrm.cloud.google.com   true

Configura gli intervalli IP VPC, di una subnet e di un alias per il cluster

Configura il VPC

Per impostare e configurare il VPC con i progetti base di networking, esegui i comandi seguenti.

  1. Recupera i progetti di rete con kpt dall'interno della directory di lavoro desiderata:

    kpt pkg get \
  https://github.com/GoogleCloudPlatform/blueprints.git/catalog/networking/network/vpc@networking-blueprint-v0.4.0 \
  VPC_NAME

    Sostituisci VPC_NAME con il nome da utilizzare per il VPC (ad esempio, my-vpc).

  2. Passa alla directory appena creata:

    cd VPC_NAME

  3. Configura il pacchetto modificando il file setters.yaml:

    Aggiorna i seguenti campi nel file. Assicurati di specificare il tuo ID progetto:

      namespace: PROJECT_NAMESPACE
  network-name: VPC_NAME
  project-id: PROJECT_ID

    Sostituisci quanto segue:

    • PROJECT_ID: l'ID del progetto.

      Per questo tutorial, viene eseguito il deployment del cluster e della rete nello stesso progetto.

    • PROJECT_NAMESPACE: lo spazio dei nomi da utilizzare per la gestione delle risorse del progetto (ad esempio config-control).

      Per questo tutorial, l'abilitazione del cluster, della rete e del servizio viene gestita nello stesso spazio dei nomi.

  4. Aggiungi un nuovo campo chiamato prefisso alla fine del file. Assicurati che il rientro sia corretto:

      prefix: NAT-PREFIX

    Sostituisci NAT-PREFIX con un prefisso (ad esempio nat).

    Viene usato come prefisso per il nome NAT durante la configurazione del VPC.

    Il file sarà simile al seguente:

    apiVersion: v1
kind: ConfigMap
metadata: # kpt-merge: /setters
  name: setters
data:
  namespace: PROJECT_NAMESPACE
  network-name: VPC_NAME
  project-id: PROJECT_ID
  prefix: NAT-PREFIX

  5. Utilizza la funzione set-namespace di kpt per modificare lo spazio dei nomi nel progetto base come segue:

      kpt fn eval --image set-namespace:v0.1 -- namespace=PROJECT_NAMESPACE

    Sostituisci PROJECT_NAMESPACE con lo spazio dei nomi utilizzato per gestire le risorse del progetto (ad esempio config-control).

Configura la subnet

  1. Recupera il progetto base della subnet con kpt dalla directory VPC_NAME:

    kpt pkg get \
  https://github.com/GoogleCloudPlatform/blueprints.git/catalog/networking/network/subnet@networking-blueprint-v0.4.0 \
  SUBNET_NAME

    Sostituisci SUBNET_NAME con lo spazio dei nomi utilizzato per gestire le risorse del progetto (ad esempio gke-subnet).

  2. Passa alla directory della subnet:

    cd SUBNET_NAME

  3. Modifica il file subnet.yaml e aggiungi il seguente snippet alla fine del file, nella sezione spec. Definisce i due intervalli denominati che verranno utilizzati per allocare gli indirizzi IP per i pod e i servizi del cluster GKE:

      secondaryIpRange:
  - ipCidrRange: 172.17.0.0/16
    rangeName: pods
  - ipCidrRange: 172.18.0.0/16
    rangeName: services

    Il file subnet.yaml dovrebbe essere simile al seguente:

    apiVersion: compute.cnrm.cloud.google.com/v1beta1
kind: ComputeSubnetwork
metadata: # kpt-merge: networking/network-name-subnetwork
  name: network-name-subnetwork # kpt-set: ${prefix}${network-name}-subnetwork
  namespace: networking # kpt-set: ${namespace}
  annotations:
    cnrm.cloud.google.com/project-id: project-id # kpt-set: ${project-id}
    cnrm.cloud.google.com/blueprint: cnrm/landing-zone:networking/v0.4.0
spec:
  description: Subnetwork
  ipCidrRange: 10.2.0.0/16 # kpt-set: ${ip-cidr-range}
  logConfig:
    metadata: INCLUDE_ALL_METADATA
    aggregationInterval: INTERVAL_10_MIN
    flowSampling: 0.5
  networkRef:
    name: network-name # kpt-set: ${network-name}
  privateIpGoogleAccess: false
  region: us-central1 # kpt-set: ${region}
  secondaryIpRange:
  - ipCidrRange: 172.17.0.0/16
    rangeName: pods
  - ipCidrRange: 172.18.0.0/16
    rangeName: services

Visualizza il progetto base

Prima di poter essere applicato, il progetto base deve essere visualizzato prima. Questo passaggio esegue la pipeline delle funzioni, come definito nel Kptfile, sulle risorse nel progetto base. Un esempio tipico di una funzione che può essere eseguita è apply-setters, che applica i setter modificati in precedenza.

  1. Ora torna alla directory VPC_NAME e utilizza kpt per visualizzare i valori del setter nelle risorse basate su modelli:

    cd ..
kpt fn render

    L'output dovrebbe essere simile al seguente:

    [RUNNING] "gcr.io/kpt-fn/apply-setters:v0.1"
[PASS] "gcr.io/kpt-fn/apply-setters:v0.1" in 5.4s
  Results:
    [INFO] set field value to "ALL_SUBNETWORKS_ALL_IP_RANGES" in file "nat.yaml" in field "spec.sourceSubnetworkIpRangesToNat"
    [INFO] set field value to "10.2.0.0/16" in file "subnet.yaml" in field "spec.ipCidrRange"

Package "my-vpc":
[RUNNING] "gcr.io/kpt-fn/apply-setters:v0.1"
[PASS] "gcr.io/kpt-fn/apply-setters:v0.1" in 2.3s
  Results:
    [INFO] set field value to "00-my-vpc-router-nat" in file "nat.yaml" in field "metadata.name"
    [INFO] set field value to "config-control" in file "nat.yaml" in field "metadata.namespace"
    [INFO] set field value to "krm-playground-00" in file "nat.yaml" in field "metadata.annotations.cnrm.cloud.google.com/project-id"
    [INFO] set field value to "00-my-vpc-router" in file "nat.yaml" in field "spec.routerRef.name"
    ...(13 line(s) truncated, use '--truncate-output=false' to disable)

Successfully executed 2 function(s) in 2 package(s).

Applica modifiche alla configurazione

Le modifiche locali apportate ai passaggi precedenti non hanno effetto sul cloud finché non viene applicato.

Per applicare le modifiche alla configurazione, esegui i comandi seguenti.

  1. Inizializza la directory di lavoro con kpt, che crea una risorsa per monitorare le modifiche:

    kpt live init --namespace PROJECT_NAMESPACE

    Sostituisci PROJECT_NAMESPACE con lo spazio dei nomi utilizzato per gestire le risorse del progetto (ad esempio config-control).

    initializing Kptfile inventory info (namespace: config-control)...success

  2. Visualizza l'anteprima delle risorse che verranno create:

    kpt live apply --dry-run

    Tutte le risorse devono essere indicate come "create" (esecuzione a secco).

    Output di esempio:

    computerouter.compute.cnrm.cloud.google.com/my-vpc-router created (dry-run)
computerouternat.compute.cnrm.cloud.google.com/my-vpc-router-nat created (dry-run)
computesubnetwork.compute.cnrm.cloud.google.com/my-vpc-subnetwork created (dry-run)
service.serviceusage.cnrm.cloud.google.com/proj-id-00-compute created (dry-run)
computenetwork.compute.cnrm.cloud.google.com/my-vpc created (dry-run)
5 resource(s) applied. 5 created, 0 unchanged, 0 configured, 0 failed (dry-run)

  3. Applica le risorse con kpt:

    kpt live apply

    Tutte le risorse devono essere indicate in "Riconciliazione".

    Output di esempio:

    computenetwork.compute.cnrm.cloud.google.com/my-vpc created
computerouter.compute.cnrm.cloud.google.com/my-vpc-router created
computerouternat.compute.cnrm.cloud.google.com/my-vpc-router-nat created
computesubnetwork.compute.cnrm.cloud.google.com/my-vpc-subnetwork created
service.serviceusage.cnrm.cloud.google.com/proj-id-00-compute created
5 resource(s) applied. 5 created, 0 unchanged, 0 configured, 0 failed

Verifica che le risorse di networking siano state create correttamente

Per verificare che le modifiche vengano applicate e che sia stato eseguito il provisioning delle risorse specificate, esegui i comandi seguenti.

  1. Attendi che le risorse siano pronte:

    kpt live status --output table --poll-until current

    Questo comando eseguirà il polling finché tutte le risorse non avranno uno stato Current e una condizione Ready.

    Usa ctrl-c per interrompere, se necessario.

    Output di esempio:

    NAMESPACE   RESOURCE                                STATUS      CONDITIONS      AGE     MESSAGE
config-con  ComputeNetwork/my-vpc                   Current     Ready           2m      Resource is Ready
config-con  ComputeRouter/my-vpc-router             Current     Ready           2m      Resource is Ready
config-con  ComputeRouterNAT/my-vpc-router-nat      Current     Ready           2m      Resource is Ready
config-con  ComputeSubnetwork/my-vpc-subnetwork     Current     Ready           2m      Resource is Ready
config-con  Service/proj-id-00-compute              Current     Ready           2m      Resource is Ready

  2. In caso di errore, utilizza l'output dell'evento predefinito per visualizzare i messaggi di errore completi:

    kpt live status

    La creazione e la preparazione di tutte le risorse richiede alcuni minuti.

    Una volta create le risorse di networking, sposta una directory verso l'alto per iniziare a configurare il cluster GKE.

    cd ..

Configura un cluster GKE

Per configurare un cluster GKE con il progetto base del cluster GKE, esegui i comandi seguenti.

  1. Recupera il progetto base del cluster GKE con kpt, dalla directory di lavoro desiderata:

    kpt pkg get \
    https://github.com/GoogleCloudPlatform/blueprints.git/catalog/gke@gke-blueprint-v0.4.0 \
    CLUSTER_NAME

    Sostituisci CLUSTER_NAME con il nome da utilizzare per il cluster GKE (ad esempio, hello-cluster).

  2. Passa alla directory del cluster:

    cd ./CLUSTER_NAME/

  3. Configura il pacchetto modificando il file setters.yaml:

    cat > setters.yaml << EOF
apiVersion: v1
kind: ConfigMap
metadata: # kpt-merge: /setters
  name: setters
data:
  # The name of this cluster
  cluster-name: CLUSTER_NAME
  # The compute location (region for a regional cluster or zone for a zonal cluster)
  location: us-central1
  # The private IP range for masters to use when peering to the VPC
  master-ip-range: 10.254.0.0/28
  # The reference to the network
  network-ref: projects/PROJECT_ID/global/networks/VPC_NAME
  # The reference to the subnet
  subnet-ref: projects/PROJECT_ID/regions/us-central1/subnetworks/subnetwork
  # The namespace in which to manage cluster resources
  platform-namespace: PROJECT_NAMESPACE
  # The project in which to manage cluster resources
  project-id: PROJECT_ID
  # The namespace in which to manage service enablement resources
  projects-namespace: PROJECT_NAMESPACE
  # The private IP range name for Pods to use, this range must already exist
  pods-range-name: pods
  # The private IP range name for services to use, this range must already exist
  services-range-name: services
  # The group in which to manage the list of groups that can be used for RBAC.
  # Must be named exactly 'gke-security-groups'.
  security-group: gke-security-groups@YOUR_DOMAIN
EOF

    Sostituisci quanto segue:

    • PROJECT_ID: l'ID del progetto.

      Per questo tutorial, viene eseguito il deployment del cluster e della rete nello stesso progetto.

    • PROJECT_NAMESPACE: lo spazio dei nomi da utilizzare per la gestione delle risorse del progetto (ad esempio config-control).

      Per questo tutorial, l'abilitazione del cluster, della rete e del servizio viene gestita nello stesso spazio dei nomi.

    • YOUR_DOMAIN: il dominio utilizzato dai tuoi gruppi (ad esempio example.com).

    • network-ref: il riferimento selfLink alla rete in cui deve essere creato il cluster.

      Nel formato: projects/{network-project-id}/global/networks/{vpc-name}

    • subnet-ref il riferimento selfLink alla subnet in cui deve essere creato il cluster.

      Nel formato: projects/{network-project-id}/regions/{region}/subnetworks/{subnet-name}

    Tutti gli altri campi di dati possono essere riconfigurati come previsto.

    I valori predefiniti forniti dovrebbero funzionare in un progetto vuoto con la rete predefinita.

Disattivazione di Google Gruppi per RBAC

Se non vuoi configurare RBAC in modo da poter usare Google Gruppi per l'autorizzazione, oltre alle singole persone, puoi modificare la configurazione del cluster in modo da disattivare Google Gruppi per la funzionalità RBAC. Questo potrebbe essere necessario, ad esempio,se non hai creato gke-security-groups e non hai le autorizzazioni per crearlo. Per scoprire di più, vedi Impostazione del gruppo

  1. Per disabilitare Google Gruppi per RBAC, è sufficiente modificare il file cluster/cluster.yaml direttamente.

  2. Individua la sezione con il campo authenticatorGroupsConfig e rimuovi le seguenti tre righe:

      # Enable Groups for GKE, to allow role binding to Google Groups.
  authenticatorGroupsConfig:
    securityGroup: gke-security-group@example.com # kpt-set: ${security-group}

  3. Salva il file.

    Questa operazione disattiva la funzionalità RBAC per Google Gruppi.

Visualizza il progetto base

Questo passaggio esegue la pipeline di funzioni, come definito nel Kptfile, sulle risorse nel progetto base. In genere esegue apply-setters, che applica i setter modificati in precedenza.

  1. Esegui il rendering dei valori del setter nelle risorse basate su modelli:

    kpt fn render

    Output di esempio:

    Package "example/cluster":
[RUNNING] "gcr.io/kpt-fn/apply-setters:v0.1"
[PASS] "gcr.io/kpt-fn/apply-setters:v0.1" in 3.3s
  Results:
    [INFO] set field value to "example-us-west4" in file "cluster.yaml" in field "metadata.name"
    [INFO] set field value to "config-control" in file "cluster.yaml" in field "metadata.namespace"
    [INFO] set field value to "project-id" in file "cluster.yaml" in field "metadata.annotations.cnrm.cloud.google.com/project-id"
    ...(9 line(s) truncated, use '--truncate-output=false' to disable)

Package "test-00/nodepools/primary":
[RUNNING] "gcr.io/kpt-fn/apply-setters:v0.1"
[PASS] "gcr.io/kpt-fn/apply-setters:v0.1" in 2.2s
  Results:
    [INFO] set field value to "gke-example-us-east4-primary" in file "node-iam.yaml" in field "metadata.name"
    [INFO] set field value to "config-control" in file "node-iam.yaml" in field "metadata.namespace"
    [INFO] set field value to "project-id" in file "node-iam.yaml" in field "metadata.annotations.cnrm.cloud.google.com/project-id"
    [INFO] set field value to "gke-example-us-east4-primary" in file "node-iam.yaml" in field "spec.displayName"
    ...(23 line(s) truncated, use '--truncate-output=false' to disable)

Package "test-00":
[RUNNING] "gcr.io/kpt-fn/apply-setters:v0.1"
[PASS] "gcr.io/kpt-fn/apply-setters:v0.1" in 2.3s
  Results:
    [INFO] set field value to "test-00" in file "cluster.yaml" in field "metadata.name"
    [INFO] set field value to "config-control" in file "cluster.yaml" in field "metadata.namespace"
    [INFO] set field value to "krm-playground-00" in file "cluster.yaml" in field "metadata.annotations.cnrm.cloud.google.com/project-id"
    ...(36 line(s) truncated, use '--truncate-output=false' to disable)

Successfully executed 3 function(s) in 3 package(s).

Applica modifiche alla configurazione

Le modifiche locali apportate ai passaggi precedenti non hanno effetto sul cloud finché non viene applicato.

Per applicare le modifiche alla configurazione, esegui i comandi seguenti.

  1. Inizializza la directory di lavoro con kpt, che crea una risorsa per monitorare le modifiche:

    kpt live init --namespace PROJECT_NAMESPACE

    Sostituisci PROJECT_NAMESPACE con lo spazio dei nomi utilizzato per gestire le risorse del progetto (ad esempio config-control).

  2. Visualizza l'anteprima delle risorse che verranno create:

    kpt live apply --dry-run

    Tutte le risorse devono essere indicate come "create" (esecuzione a secco).

    Output di esempio:

    service.serviceusage.cnrm.cloud.google.com/proj-id-00-test-00-container created (dry-run)
containercluster.container.cnrm.cloud.google.com/test-00 created (dry-run)
containernodepool.container.cnrm.cloud.google.com/test-00-primary created (dry-run)
iampolicymember.iam.cnrm.cloud.google.com/artifactreader-gke-test-00-primary created (dry-run)
iampolicymember.iam.cnrm.cloud.google.com/logwriter-gke-test-00-primary created (dry-run)
iampolicymember.iam.cnrm.cloud.google.com/metricwriter-gke-test-00-primary created (dry-run)
iamserviceaccount.iam.cnrm.cloud.google.com/gke-test-00-primary created (dry-run)
7 resource(s) applied. 7 created, 0 unchanged, 0 configured, 0 failed (dry-run)

  3. Applica le risorse con kpt:

    kpt live apply

    Tutte le risorse devono essere indicate come "create".

    Output di esempio:

    iamserviceaccount.iam.cnrm.cloud.google.com/gke-test-00-primary created
service.serviceusage.cnrm.cloud.google.com/proj-id-00-test-00-container created
containercluster.container.cnrm.cloud.google.com/test-00 created
containernodepool.container.cnrm.cloud.google.com/test-00-primary created
iampolicymember.iam.cnrm.cloud.google.com/artifactreader-gke-test-00-primary created
iampolicymember.iam.cnrm.cloud.google.com/logwriter-gke-test-00-primary created
iampolicymember.iam.cnrm.cloud.google.com/metricwriter-gke-test-00-primary created
7 resource(s) applied. 7 created, 0 unchanged, 0 configured, 0 failed

Verifica che le risorse del cluster GKE siano create correttamente

Per verificare che le modifiche vengano applicate e che sia stato eseguito il provisioning delle risorse specificate, esegui i comandi seguenti.

  1. Attendi che le risorse siano pronte:

    kpt live status --output table --poll-until current

    Questo comando eseguirà il polling finché tutte le risorse non avranno uno stato Current e una condizione Ready.

    Usa ctrl-c per interrompere, se necessario.

    Output di esempio:

    NAMESPACE   RESOURCE                                  STATUS      CONDITIONS      AGE     MESSAGE
config-con  ContainerCluster/test-00                  Current     Ready           12m     Resource is Ready
config-con  ContainerNodePool/test-00-primary         Current     Ready           12m     Resource is Ready
config-con  IAMPolicyMember/artifactreader-gke-test-  Current     Ready           12m     Resource is Ready
config-con  IAMPolicyMember/logwriter-gke-test-00-pr  Current     Ready           12m     Resource is Ready
config-con  IAMPolicyMember/metricwriter-gke-test-00  Current     Ready           12m     Resource is Ready
config-con  IAMServiceAccount/gke-test-00-primary     Current     Ready           12m     Resource is Ready
config-con  Service/proj-id-00-test-00-contai         Current     Ready           12m     Resource is Ready

  2. In caso di errore, utilizza l'output dell'evento predefinito per visualizzare i messaggi di errore completi:

    kpt live status

Domande frequenti

Pulizia

Se decidi di interrompere l'utilizzo di Config Controller, devi prima pulire tutte le risorse create con Config Controller ed eliminare successivamente Config Controller stesso.

  1. Elimina prima le risorse del cluster con kpt, dalla directory di lavoro del progetto base del cluster GKE:

    kpt live destroy

  2. Attendi che tutte le risorse vengano eliminate:

    until [ -z "$(kubectl get -R -f . --ignore-not-found | tee /dev/fd/2)" ]; \
do sleep 1; done

    Questo comando eseguirà il polling finché tutte le risorse non avranno lo stato Deleted.

    Usa ctrl-c per interrompere, se necessario.

  3. Elimina le risorse di networking se le hai create come parte di questo tutorial. Utilizza kpt dalla directory VPC che hai creato per il progetto base:

    kpt live destroy

  4. Attendi che tutte le risorse vengano eliminate:

    until [ -z "$(kubectl get -R -f . --ignore-not-found | tee /dev/fd/2)" ]; \
do sleep 1; done

    Questo comando eseguirà il polling finché tutte le risorse non avranno lo stato Deleted.

    Usa ctrl-c per interrompere, se necessario.

Passaggi successivi