Esegui la migrazione dei nodi a containerd 2

I cluster Google Kubernetes Engine (GKE) utilizzano immagini dei nodi containerd con tutti i nodi worker che eseguono la versione 1.24 e successive. I nodi worker utilizzano una versione specifica di containerd, in base al sistema operativo e alla versione secondaria di GKE:

  • Nodi Container-Optimized OS e Ubuntu (Linux):
    • I nodi Linux che eseguono GKE 1.32 o versioni precedenti, con immagini dei nodi containerd, utilizzano containerd 1.7 o versioni precedenti.
    • I nodi Linux che eseguono GKE 1.33 utilizzano containerd 2.0.
  • Nodi Windows Server:
    • I nodi Windows Server che eseguono GKE 1.34 o versioni precedenti, con immagini dei nodi containerd, utilizzano containerd 1.7 o versioni precedenti.
    • I nodi Windows Server che eseguono GKE 1.35 utilizzano containerd 2.0.

Quando viene eseguito l'upgrade dei nodi GKE alla rispettiva versione secondaria di GKE, i nodi eseguono la migrazione dall'utilizzo di containerd 1.7 alla nuova versione principale, containerd 2.0. Non puoi modificare la versione di containerd utilizzata da una versione di GKE.

Puoi saltare la lettura di questa pagina se sai che i tuoi workload vengono eseguiti come previsto su containerd 2.

Come GKE sta eseguendo la transizione a containerd 2

Esamina la seguente sequenza temporale per capire come GKE sta eseguendo la transizione dei cluster esistenti all'utilizzo di containerd 2:

  • Per i nodi Linux con 1.32 e i nodi Windows Server con 1.34, GKE utilizza containerd 1.7. containerd 1.7 ha ritirato sia le immagini Docker schema 1 sia l'API Container Runtime Interface (CRI) v1alpha2. Per scoprire di più su altre funzionalità ritirate nelle versioni precedenti, consulta Proprietà di configurazione ritirate.
  • Per i nodi Linux con 1.33 e i nodi Windows Server con 1.35, GKE utilizza containerd 2.0, che rimuove il supporto per le immagini Docker schema 1 e l'API CRI v1alpha2.
  • Le seguenti proprietà di configurazione di containerd nel plug-in CRI sono ritirate e verranno rimosse in containerd 2.4 o versioni successive, con una versione di GKE ancora da annunciare: registry.auths, registry.configs, registry.mirrors. Tuttavia, registry.configs.tls è già stata rimossa in containerd 2.0.

Per i tempi approssimativi degli upgrade automatici alle versioni secondarie successive, consulta la pianificazione stimata per i canali di rilascio.

Impatto della transizione a containerd 2

Leggi la sezione seguente per comprendere l'impatto di questa transizione a containerd 2.

Upgrade automatici in pausa

GKE mette in pausa gli upgrade automatici nei seguenti modi, a seconda della versione secondaria corrente del cluster e se i nodi del cluster sono nodi Linux o nodi Windows Server.

Upgrade automatici in pausa per i nodi Linux

GKE mette in pausa gli upgrade automatici alla versione 1.33 per i cluster con nodi Linux quando rileva che il cluster utilizza le funzionalità ritirate. Tuttavia, se i nodi del cluster utilizzano queste funzionalità, ti consigliamo di creare un'esclusione della manutenzione per impedire gli upgrade del cluster. L'esclusione della manutenzione garantisce che non venga eseguito l'upgrade del cluster se GKE non rileva l'utilizzo.

Dopo aver eseguito la migrazione dall'utilizzo di queste funzionalità, GKE riprende gli upgrade automatici secondari alla versione 1.33 se sono vere le seguenti condizioni:

  • GKE non ha rilevato l'utilizzo di funzionalità ritirate da 14 giorni o da 3 giorni per le proprietà registry.configs CRI ritirate.
  • La versione 1.33 è una destinazione di upgrade automatico per il tuo cluster.
  • Non ci sono altri fattori di blocco. Per saperne di più, consulta la sezione relativa a The timing of automatic upgrades.

Puoi anche eseguire l'upgrade manuale del cluster.

Upgrade automatici in pausa per i nodi Windows Server

GKE mette in pausa gli upgrade automatici alla versione 1.35 per tutti i cluster con nodi Windows Server, indipendentemente dal fatto che il cluster utilizzi o meno le funzionalità ritirate. GKE non è in grado di rilevare se i nodi Windows Server utilizzano le funzionalità ritirate.

Per eseguire l'upgrade del cluster con nodi Windows Server alla versione 1.35, segui prima le istruzioni per eseguire la migrazione dalle funzionalità ritirate. Dopo aver seguito queste istruzioni, puoi eseguire manualmente l'upgrade del cluster alla versione 1.35.

Fine del supporto e impatto della mancata preparazione alla migrazione

GKE mette in pausa gli upgrade automatici fino alla fine del supporto standard. Se il tuo cluster è registrato nel canale esteso, i nodi possono rimanere su una versione fino alla fine del supporto esteso. Per maggiori dettagli sugli upgrade automatici dei nodi alla fine del supporto, consulta Upgrade automatici alla fine del supporto.

Se non esegui la migrazione da queste funzionalità, quando la versione 1.32 (per i nodi Linux) o 1.34 (per i nodi Windows Server) raggiunge la fine del supporto e viene eseguito automaticamente l'upgrade dei nodi del cluster alla versione 1.33 o 1.35, potresti riscontrare i seguenti problemi con i cluster:

  • I workload che utilizzano immagini Docker schema 1 non vanno a buon fine.
  • Le applicazioni che chiamano l'API CRI v1alpha2 riscontrano errori durante la chiamata all'API.

Identificare i cluster interessati

GKE monitora i tuoi cluster e utilizza il servizio Recommender per fornire indicazioni tramite insight e suggerimenti per identificare i nodi Linux nel cluster che utilizzano queste funzionalità ritirate. GKE non rileva l'utilizzo dai nodi Windows Server.

Requisiti della versione

I cluster ricevono questi insight e suggerimenti se eseguono le seguenti versioni o successive:

  • 1.28.15-gke.1159000
  • 1.29.9-gke.1541000
  • 1.30.5-gke.1355000
  • 1.31.1-gke.1621000

Visualizzare insight e suggerimenti

Segui le istruzioni per visualizzare insight e suggerimenti. Puoi ottenere insight utilizzando la Cloud de Confiance console. Puoi anche utilizzare Google Cloud CLI o l'API Recommender, filtrando con i seguenti sottotipi:

  • DEPRECATION_CONTAINERD_V1_SCHEMA_IMAGES: immagini Docker schema 1
  • DEPRECATION_CONTAINERD_V1ALPHA2_CRI_API: API CRI v1alpha2
  • DEPRECATION_CONTAINERD_V2_CONFIG_REGISTRY_CONFIGS: proprietà CRI registry.configs ritirate, incluse registry.configs.auth e registry.configs.tls

Eseguire la migrazione dalle funzionalità ritirate

Esamina i seguenti contenuti per capire come eseguire la migrazione dalle funzionalità ritirate con containerd 2.

Eseguire la migrazione dalle immagini Docker schema 1

Identifica i workload che utilizzano le immagini di cui deve essere eseguita la migrazione, quindi esegui la migrazione di questi workload.

Un'immagine fornita da Google interessata da questo problema è gcr.io/google-containers/startup-script.

  • gcr.io/google-containers/startup-script:v1: utilizza il formato schema 1 ritirato e non può essere eseguito il pull su GKE 1.33 e versioni successive per i nodi Linux.
  • gcr.io/google-containers/startup-script:v2: utilizza il formato schema 2 supportato e può essere eseguito il pull correttamente.

Se utilizzi gcr.io/google-containers/startup-script:v1 in uno dei tuoi workload (ad esempio DaemonSet o Deployment), devi aggiornare il riferimento all'immagine a gcr.io/google-containers/startup-script:v2.

Trovare le immagini di cui eseguire la migrazione

Puoi utilizzare diversi strumenti per trovare le immagini di cui deve essere eseguita la migrazione.

Utilizzare insight e suggerimenti o Cloud Logging

Come spiegato nella sezione Identificare i cluster interessati, puoi utilizzare insight e suggerimenti per trovare i cluster con nodi Linux che utilizzano immagini Docker schema 1 se il cluster esegue una versione minima o successiva. Inoltre, puoi utilizzare la seguente query in Cloud Logging per controllare i log di containerd e trovare le immagini Docker schema 1 nel cluster:

jsonPayload.SYSLOG_IDENTIFIER="containerd"
"conversion from schema 1 images is deprecated"

Se sono trascorsi più di 30 giorni dall'esecuzione del pull dell'immagine, potresti non visualizzare i log per un'immagine.

Utilizzare il comando ctr direttamente su un nodo

Per eseguire una query su un nodo specifico per restituire tutte le immagini non eliminate di cui è stato eseguito il pull come schema 1, esegui il seguente comando su un nodo:

  ctr --namespace k8s.io images list 'labels."io.containerd.image/converted-docker-schema1"'

Questo comando può essere utile, ad esempio, se stai risolvendo i problemi di un nodo specifico e non vedi voci di log in Cloud Logging perché sono trascorsi più di 30 giorni dall'esecuzione del pull dell'immagine.

Utilizzare lo strumento open source crane

Puoi anche utilizzare strumenti open source come crane per verificare la presenza di immagini.

Esegui il seguente comando crane per controllare la versione dello schema di un'immagine:

crane manifest $tagged_image | jq .schemaVersion

Preparare i workload

Per preparare i workload che eseguono immagini Docker schema 1, devi eseguire la migrazione di questi workload a immagini Docker schema 2 o immagini Open Container Initiative (OCI). Valuta le seguenti opzioni per la migrazione:

  • Trovare un'immagine sostitutiva: potresti essere in grado di trovare un'immagine open source disponibile pubblicamente o fornita dal fornitore.
  • Convertire l'immagine esistente: se non riesci a trovare un'immagine sostitutiva, puoi convertire le immagini Docker schema 1 esistenti in immagini OCI seguendo questi passaggi:
    1. Esegui il pull dell'immagine Docker in containerd, che la converte automaticamente in un'immagine OCI.
    2. Esegui il push della nuova immagine OCI nel registro.

Eseguire la migrazione dall'API CRI v1alpha2

L'API CRI v1alpha2 è stata rimossa in Kubernetes 1.26. Devi identificare i workload che accedono al socket containerd e aggiornare queste applicazioni per utilizzare l'API v1.

Identificare i workload potenzialmente interessati

Puoi utilizzare diverse tecniche per identificare i workload di cui potrebbe essere necessario eseguire la migrazione. Queste tecniche potrebbero generare falsi positivi che devi esaminare ulteriormente per determinare se non è necessaria alcuna azione.

Utilizzare insight e suggerimenti

Puoi utilizzare insight e suggerimenti per trovare i cluster con nodi Linux che utilizzano l'API v1alpha2 se il cluster esegue una versione minima o successiva. Per maggiori dettagli, consulta Identificare i cluster interessati.

Quando visualizzi gli insight nella Cloud de Confiance console, consulta il riquadro della barra laterale Esegui la migrazione dei workload dall'API CRI v1alpha2 ritirata. La tabella Workload da verificare in questo riquadro elenca i workload che potrebbero essere interessati. Questo elenco include tutti i workload non gestiti da GKE che hanno hostPath volumi contenenti il percorso del socket containerd (ad esempio, /var/run/containerd/containerd.sock o /run/containerd/containerd.sock).

È importante comprendere quanto segue:

  • L'elenco dei workload da verificare può contenere falsi positivi. Utilizzalo solo per le indagini. La visualizzazione di un workload in questo elenco non significa in modo definitivo che utilizzi l'API ritirata e la presenza di un falso positivo non metterà in pausa gli upgrade automatici. La messa in pausa si basa solo sull'utilizzo effettivamente osservato dell'API ritirata.
  • Questo elenco potrebbe essere vuoto o incompleto. Un elenco vuoto o incompleto può verificarsi se i workload che utilizzano l'API ritirata sono stati di breve durata e non erano in esecuzione quando GKE ha eseguito il controllo periodico. La presenza del suggerimento stesso indica che è stato rilevato l'utilizzo dell'API CRI v1alpha2 su almeno un nodo del cluster. Gli upgrade automatici riprendono dopo che l'utilizzo dell'API ritirata non è stato rilevato per 14 giorni.

Pertanto, ti consigliamo di eseguire ulteriori indagini utilizzando i seguenti metodi per confermare l'utilizzo effettivo dell'API.

Verificare la presenza di workload di terze parti interessati

Per il software di terze parti di cui è stato eseguito il deployment nei cluster, verifica che questi workload non utilizzino l'API CRI v1alpha2. Potresti dover contattare i rispettivi fornitori per verificare quali versioni del loro software sono compatibili.

Utilizzare kubectl

Il seguente comando ti aiuta a trovare i workload potenzialmente interessati cercando quelli che accedono al socket containerd. Utilizza una logica simile a quella utilizzata per la Workload da verificare tabella nel Cloud de Confiance console suggerimento. Restituisce i workload non gestiti da GKE che hanno volumi hostPath che includono il percorso del socket. Come il suggerimento, questa query potrebbe restituire falsi positivi o non rilevare i workload di breve durata.

Esegui questo comando:

kubectl get pods --all-namespaces -o json | \
jq -r '
  [
    "/", "/var", "/var/","/var/run", "/var/run/",
    "/var/run/containerd", "/var/run/containerd/", "/var/run/containerd/containerd.sock",
    "/run", "/run/", "/run/containerd", "/run/containerd/",
    "/run/containerd/containerd.sock"
  ] as $socket_paths |
  [
    "kube-system", "kube-node-lease", "istio-system", "asm-system",
    "gatekeeper-system", "config-management-system", "config-management-monitoring",
    "cnrm-system", "hnc-system", "gke-managed-system", "gke-gmp-system",
    "gmp-system", "gke-managed-cim"
  ] as $excluded_namespaces |
  .items[] |
  select(
    (.spec.volumes[]?.hostPath.path as $p | $socket_paths | index($p))
    and
    ([.metadata.namespace] | inside($excluded_namespaces) | not)
  ) |
  .metadata.namespace + "/" + .metadata.name
'
Utilizzare la traccia eBPF per identificare i chiamanti API

Per un modo più definitivo per identificare i workload in esecuzione sui nodi Linux che chiamano l'API CRI v1alpha2, puoi eseguire il deployment di due DaemonSet specializzati:

  • The containerd-socket-tracer registra qualsiasi processo che apre una connessione al containerd socket, insieme ai dettagli del pod e del container.
  • cri-v1alpha2-api-deprecation-reporter registra l'ultima volta che è stata chiamata l'API CRI v1alpha2.

Questi strumenti utilizzano Extended Berkeley Packet Filter (eBPF) per tracciare le connessioni al containerd socket e correlare le connessioni con le chiamate API ritirate effettive.

Non puoi eseguire il deployment di questi DaemonSet sui nodi Windows Server.

Correlando i timestamp di questi due strumenti, puoi individuare il workload esatto che effettua la chiamata API ritirata. Questo metodo offre un grado di affidabilità maggiore rispetto al solo controllo dei volumi hostPath, perché osserva le connessioni socket effettive e l'utilizzo dell'API.

Per istruzioni dettagliate su come eseguire il deployment e utilizzare questi strumenti e su come interpretare i relativi log, consulta Tracciare le connessioni socket containerd.

Se, dopo aver utilizzato questi strumenti, non riesci ancora a identificare l'origine delle chiamate API ritirate, ma il suggerimento rimane attivo, consulta Richiedere assistenza.

Dopo aver identificato un workload che utilizza l'API CRI v1alpha2, tramite i metodi precedenti o esaminando la codebase, devi aggiornarne il codice per utilizzare l'API v1.

Aggiornare il codice dell'applicazione

Per aggiornare l'applicazione, rimuovi il punto in cui l'applicazione importa la k8s.io/cri-api/pkg/apis/runtime/v1alpha2 libreria client e modifica il codice per utilizzare la v1 versione dell'API. Questo passaggio prevede la modifica del percorso di importazione e l'aggiornamento del modo in cui il codice chiama l'API.

Ad esempio, vedi il seguente codice golang, che utilizza la libreria ritirata:

  package main

  import (
    ...

    runtimeapi "k8s.io/cri-api/pkg/apis/runtime/v1alpha2"
  )

  func foo() {
    ...

    client := runtimeapi.NewRuntimeServiceClient(conn)
    version, err := client.Version(ctx, &runtimeapi.VersionRequest{})

    ...
  }

Qui, l'applicazione importa la libreria v1alpha2 e la utilizza per emettere RPC. Se le RPC utilizzano la connessione al socket containerd, questa applicazione fa sì che GKE metta in pausa gli upgrade automatici per il cluster.

Segui questi passaggi per cercare e aggiornare il codice dell'applicazione:

  1. Identifica le applicazioni golang problematiche eseguendo il seguente comando per cercare il percorso di importazione v1alpha2:

      grep -r "k8s.io/cri-api/pkg/apis/runtime/v1alpha2"

    Se l'output di questo comando mostra che la libreria v1alpha2 viene utilizzata nel file, devi aggiornare il file.

    Ad esempio, sostituisci il seguente codice dell'applicazione:

      runtimeapi "k8s.io/cri-api/pkg/apis/runtime/v1alpha2"

  2. Aggiorna il codice per utilizzare v1:

      runtimeapi "k8s.io/cri-api/pkg/apis/runtime/v1"

Eseguire la migrazione dalle proprietà di configurazione di containerd ritirate

Le proprietà di configurazione di containerd registry.auths, registry.configs e registry.mirrors nel plug-in CRI sono ritirate e verranno rimosse in containerd 2.4 o versioni successive, con una versione di GKE ancora da annunciare. Tuttavia, registry.configs.tls è già stata rimossa in containerd 2.0.

Identificare i workload

Puoi utilizzare diverse tecniche per identificare i workload di cui deve essere eseguita la migrazione.

Utilizzare insight e suggerimenti

Come approccio iniziale, puoi utilizzare insight e suggerimenti per trovare i cluster con nodi Linux che utilizzano le proprietà di configurazione di containerd ritirate. È necessaria una versione minima di GKE. Per saperne di più su questo approccio, consulta Identificare i cluster interessati.

Quando visualizzi gli insight nella Cloud de Confiance console, consulta il riquadro della barra laterale Esegui la migrazione della configurazione containerd dal campo "auths" del registro CRI ritirato o Esegui la migrazione della configurazione containerd dal campo "mirrors" del registro CRI ritirato . Per trovare i workload che potrebbero accedere alla configurazione di containerd, controlla la sezione Workload da verificare.

Utilizzare kubectl

In alternativa, puoi utilizzare kubectl per identificare i workload.

Individua i workload che modificano la configurazione di containerd controllando i workload con i seguenti attributi:

  • Workload che contengono un volume hostPath che include la configurazione di containerd
  • Workload che hanno un container con accesso con privilegi (spec.containers.securityContext.privileged: true) e utilizzano lo spazio dei nomi PID (ID processo) dell'host (spec.hostPID: true)

Questo comando potrebbe restituire falsi positivi perché il workload potrebbe accedere ad altri file in queste directory che non sono la configurazione di containerd. In alternativa, questo comando potrebbe non restituire i workload che accedono al file di configurazione di containerd in altri modi meno comuni.

Esegui il seguente comando per verificare la presenza dei DaemonSet:

kubectl get daemonsets --all-namespaces -o json | \
jq -r '
  [
    "/", "/etc", "/etc/",
    "/etc/containerd", "/etc/containerd/",
    "/etc/containerd/config.toml"
  ] as $host_paths |
  [
    "kube-system", "kube-node-lease", "istio-system", "asm-system",
    "gatekeeper-system", "config-management-system", "config-management-monitoring",
    "cnrm-system", "hnc-system", "gke-managed-system", "gke-gmp-system",
    "gmp-system", "gke-managed-cim"
  ] as $excluded_namespaces |
  .items[] |
  select(
    ([.metadata.namespace] | inside($excluded_namespaces) | not)
    and
    (
      (any(.spec.template.spec.volumes[]?.hostPath.path; IN($host_paths[])))
      or
      (
        .spec.template.spec.hostPID == true and
        any(.spec.template.spec.containers[]; .securityContext?.privileged == true)
      )
    )
  ) |
  .metadata.namespace + "/" + .metadata.name
'

Eseguire la migrazione dalle proprietà auths o configs.auth del registro CRI

Se i tuoi workload utilizzano le proprietà auths o configs.auth nella configurazione di containerd per l'autenticazione a un registro privato per il pull delle immagini container, devi eseguire la migrazione dei workload che utilizzano queste immagini al campo imagePullSecrets. Per saperne di più, consulta Eseguire il pull di un'immagine da un registro privato.

Per identificare ed eseguire la migrazione dei workload che utilizzano le proprietà auths o configs.auth ritirate, esamina le seguenti istruzioni.

Individuare i dettagli di autenticazione per il registro

Puoi individuare i dettagli di autenticazione per il registro in uno dei seguenti modi:

  • Esamina le sezioni auths e configs.auth del registro CRI nel file /etc/containerd/config.toml connettendoti a un nodo GKE.
  • Trova il workload che modifica il file di configurazione di containerd e vedi quali dettagli di autenticazione sono inclusi utilizzando i metodi descritti in precedenza per identificare i workload. GKE non utilizza queste impostazioni per i suoi workload di sistema.

Se utilizzi la proprietà registry.configs.auth, i dettagli di autenticazione potrebbero essere simili ai seguenti:

  [plugins."io.containerd.grpc.v1.cri".registry.configs."$REGISTRY_DOMAIN".auth]
    username = "example-user"
    password = "example-password"

Raccogli questi dettagli di autenticazione per ogni dominio del registro specificato nella configurazione.

Aggiornare il workload per utilizzare il campo imagePullSecrets
  1. Crea un secret con i dettagli di autenticazione della sezione precedente seguendo le istruzioni per eseguire il pull di un'immagine da un registro privato.

  2. Identifica i workload di cui deve essere eseguita la migrazione al campo imagePullSecrets eseguendo il seguente comando:

    kubectl get pods -A -o json |
jq -r ".items[] |
  select(.spec.containers[] |
        .image | startswith(\"$REGISTRY_DOMAIN\")) |
  .metadata.namespace + \"/\" + .metadata.name"

    Devi creare un secret per ogni spazio dei nomi utilizzato dai workload con immagini di questo dominio del registro.

  3. Aggiorna i workload in modo che utilizzino il campo imagePullSecrets con i secret creati nel passaggio precedente.

    In alternativa, se devi eseguire la migrazione di un numero elevato di workload, puoi implementare un MutatingAdmissionWebhook per aggiungere il campo imagePullSecrets.

Aggiornare la configurazione di containerd per interrompere l'impostazione delle autorizzazioni del registro

Dopo aver eseguito la migrazione dei workload in modo che utilizzino il campo imagePullSecrets, devi aggiornare i workload che modificano la configurazione di containerd per interrompere l'impostazione delle autorizzazioni del registro. Per tutti i workload identificati come modificatori della configurazione, modificali in modo che non impostino più le autorizzazioni del registro.

Eseguire il test con un nuovo pool di nodi ed eseguire la migrazione dei workload al nuovo pool di nodi

Per ridurre il rischio di causare problemi con i workload:

  1. Crea un nuovo pool di nodi.
  2. Pianifica il workload aggiornato che modifica la configurazione di containerd sui nodi del nuovo pool di nodi.
  3. Esegui la migrazione dei workload rimanenti al nuovo pool di nodi seguendo le istruzioni per eseguire la migrazione dei workload tra i node pool.

Eseguire la migrazione dalla proprietà configs.tls del registro CRI

Se i tuoi workload utilizzano la proprietà registry.configs.tls, devi eseguire la migrazione di questi workload per accedere ai registri privati con certificati CA privati.

Segui le istruzioni per eseguire la migrazione dai DaemonSet di configurazione. Questa procedura viene eseguita seguendo questi passaggi:

  1. Aggiorna i workload che modificano la configurazione di containerd per interrompere l'impostazione dei dettagli TLS.
  2. Archivia i certificati in Secret Manager.
  3. Crea un file di configurazione del runtime che rimandi ai certificati.
  4. Crea un nuovo pool di nodi e verifica che i workload che utilizzano le immagini ospitate dal registro privato funzionino come previsto.
  5. Applica la configurazione a un nuovo cluster e inizia a eseguire i workload su quel cluster oppure applica la configurazione al cluster esistente. L'applicazione della configurazione al cluster esistente potrebbe potenzialmente interrompere altri workload esistenti. Per saperne di più su questi due approcci, consulta Creare un file di configurazione del runtime.

Dopo la migrazione, assicurati di interrompere l'applicazione di eventuali modifiche al campo registry.configs o potresti riscontrare problemi con containerd.

Richiedere assistenza

Se non riesci ancora a determinare l'origine delle chiamate API ritirate e i suggerimenti rimangono attivi, valuta il seguente passaggio successivo: