Risoluzione dei problemi relativi al runtime del container

---

Questo documento fornisce i passaggi per la risoluzione dei problemi comuni che potresti riscontrare con il runtime dei container sui nodi di Google Kubernetes Engine (GKE).

Se hai bisogno di ulteriore aiuto, contatta l'assistenza clienti Google Cloud.

I percorsi di montaggio con lettere di unità semplici non riescono nei pool di nodi Windows con containerd

Questo problema è stato risolto in Containerd 1.6.6 e versioni successive.

I cluster GKE che eseguono pool di nodi Windows Server che utilizzano il runtime containerd precedente alla versione 1.6.6 potrebbero riscontrare errori durante l'avvio di container come il seguente:

failed to create containerd task : CreateComputeSystem : The parameter is incorrect : unknown

Per maggiori dettagli, consulta il problema di GitHub n. 6589.

Soluzione

Per risolvere questo problema, esegui l'upgrade dei pool di nodi alle versioni GKE più recenti che utilizzano il runtime containerd 1.6.6 o versioni successive.

Le immagini container con righe di comando CMD o ENTRYPOINT pre-escape non array hanno esito negativo nei pool di nodi Windows con containerd

Questo problema è stato risolto in Containerd 1.6 e versioni successive.

I cluster GKE che eseguono pool di nodi Windows Server che utilizzano il runtime containerd 1.5.X potrebbero riscontrare errori all'avvio dei container come riportato di seguito:

failed to start containerd task : hcs::System::CreateProcess : The system cannot find the file specified.: unknown

Per maggiori dettagli, consulta gli articoli Problema di GitHub n. 5067 e Problema di GitHub n. 6300.

Soluzione

Per risolvere questo problema, esegui l'upgrade dei pool di nodi alle versioni GKE più recenti che utilizzano il runtime containerd 1.6.6 o versioni successive.

I volumi delle immagini container con percorsi non esistenti o percorsi simili a Linux (barra) non riescono nei pool di nodi Windows con containerd

Questo problema è stato risolto in Containerd 1.6 e versioni successive.

I cluster GKE che eseguono pool di nodi Windows Server che utilizzano il runtime containerd 1.5.X potrebbero riscontrare errori all'avvio dei container come riportato di seguito:

failed to generate spec: failed to stat "<volume_path>": CreateFile : The system cannot find the path specified.

Per maggiori dettagli, consulta il problema di GitHub n. 5671.

Soluzione

Per risolvere questo problema, esegui l'upgrade dei pool di nodi alle versioni GKE più recenti che utilizzano il runtime containerd 1.6.x o versioni successive.

/etc/mtab: file o directory non presenti

Per impostazione predefinita, il runtime del container Docker completa questo collegamento simbolico all'interno del container, ma non il runtime containerd.

Per maggiori dettagli, consulta il problema di GitHub n. 2419.

Soluzione

Per risolvere il problema, crea manualmente il link simbolico /etc/mtab durante la creazione dell'immagine.

ln -sf /proc/mounts /etc/mtab

Errore di pull dell'immagine: non è una directory

Versioni GKE interessate: tutte

Quando crei un'immagine con kaniko, potrebbe non essere possibile eseguirla con containerd e visualizzare il messaggio di errore "non una directory". Questo errore si verifica se l'immagine viene creata in un modo speciale: quando un comando precedente rimuove una directory e il comando successivo ricrea gli stessi file in quella directory.

L'esempio di Dockerfile seguente con npm che illustra questo problema.

RUN npm cache clean --force
RUN npm install

Per maggiori dettagli, consulta il problema di GitHub n. 4659.

Soluzione

Per risolvere il problema, crea l'immagine utilizzando docker build, che non è interessata da questo problema.

Se docker build non è un'opzione, combina i comandi in uno solo. Il seguente esempio di Dockerfile combina RUN npm cache clean --force e RUN npm install:

RUN npm cache clean --force && npm install

Mancano alcune metriche del file system e il formato delle metriche è diverso

Nota: questo problema non interessa i clienti che utilizzano Cloud Monitoring.

Versioni GKE interessate: tutte

L'endpoint /metrics/cadvisor di Kubelet fornisce metriche di Prometheus, come documentato in Metriche per i componenti di sistema di Kubernetes. Se installi un raccoglitore di metriche che dipende da questo endpoint, potresti riscontrare i seguenti problemi:

• Il formato delle metriche sul nodo Docker è k8s_<container-name>_<pod-name>_<namespace>_<pod-uid>_<restart-count>, ma il formato sul nodo containerd è <container-id>.

• Nel nodo containerd mancano alcune metriche del file system, come segue:

  container_fs_inodes_free
  container_fs_inodes_total
  container_fs_io_current
  container_fs_io_time_seconds_total
  container_fs_io_time_weighted_seconds_total
  container_fs_limit_bytes
  container_fs_read_seconds_total
  container_fs_reads_merged_total
  container_fs_sector_reads_total
  container_fs_sector_writes_total
  container_fs_usage_bytes
  container_fs_write_seconds_total
  container_fs_writes_merged_total
  

Soluzione

Puoi mitigare questo problema utilizzando cAdvisor come daemonset autonomo.

1. Trova l'ultima release di cAdvisor con il pattern del nome vX.Y.Z-containerd-cri (ad esempio, v0.42.0-containerd-cri).
2. Segui i passaggi in cAdvisor Kubernetes Daemonset per creare il daemonset.
3. Punta al raccoglitore delle metriche installato per utilizzare l'endpoint /metrics cAdvisor che fornisce il set completo di metriche del container Prometheus.

Alternative

1. Esegui la migrazione della tua soluzione di monitoraggio a Cloud Monitoring, che fornisce il set completo di metriche dei container.
2. Raccogli metriche dall'API Kubelet summary con un endpoint /stats/summary.

Le operazioni basate sui collegamenti non funzionano correttamente dopo il riavvio del runtime dei container su GKE Windows

Versioni GKE interessate: da 1.21 a 1.21.5-gke.1802, da 1.22 a 1.22.3-gke.700

I cluster GKE che eseguono pool di nodi Windows Server che utilizzano il runtime containerd (versione 1.5.4 e 1.5.7-gke.0) potrebbero riscontrare problemi se il runtime del container viene riavviato forzatamente, in quanto le operazioni di collegamento ai container in esecuzione esistenti non sono in grado di associare di nuovo gli I/O. Il problema non causerà errori nelle chiamate API, ma i dati non verranno inviati o ricevuti. Ciò include i dati per le interfacce a riga di comando e le API di collegamento e log tramite il server API del cluster.

Soluzione

Per risolvere il problema, esegui l'upgrade alla versione del runtime dei container con patch (1.5.7-gke.1) con le release GKE più recenti.

I pod mostrano failed to allocate for range 0: no IP addresses available in range set messaggio di errore

Versioni di GKE interessate: 1.24.6-gke.1500 o precedenti, 1.23.14-gke.1800 o precedenti e 1.22.16-gke.2000 o precedenti

I cluster GKE che eseguono pool di nodi che utilizzano containerd potrebbero riscontrare problemi di perdita di IP ed esaurire tutti gli IP dei pod su un nodo. Un pod pianificato su un nodo interessato mostra un messaggio di errore simile al seguente:

failed to allocate for range 0: no IP addresses available in range set: 10.48.131.1-10.48.131.62

Per maggiori informazioni sul problema, consulta il problema di GitHub n. 5438 containerd e il problema di GitHub n. 5768.

Esiste un problema noto in GKE Dataplane V2 che può attivare questo problema. Tuttavia, questo problema può essere causato da altre cause, tra cui runc bloccato.

Soluzione

Per risolvere il problema, segui le soluzioni alternative indicate in Soluzioni per i cluster GKE standard per GKE Dataplane V2.

Differenza nel comportamento del probe di esecuzione quando il probe supera il timeout

Versioni GKE interessate: tutte

Il comportamento del probe di esecuzione sulle immagini containerd è diverso da quello delle immagini dockershim. Quando il probe exec, definito per il pod, supera la soglia dichiarata Kubernetes timeoutSeconds, per dockershim immagini viene considerato un errore del probe. Nelle immagini containerd, i risultati del probe restituiti dopo la soglia timeoutSeconds dichiarata vengono ignorati.

Soluzione

In GKE, la porta di funzionalità ExecProbeTimeout è impostata su false e non può essere modificata. Per risolvere il problema, aumenta la soglia timeoutSeconds per tutti i probe exec interessati o implementa la funzionalità di timeout come parte della logica del probe.

Risolvere i problemi relativi ai registry privati

Questa sezione fornisce informazioni sulla risoluzione dei problemi per le configurazioni del registro privato in containerd.

Il pull dell'immagine non riesce e restituisce l'errore x509: certificato firmato da un'autorità sconosciuta

Questo problema si verifica se GKE non riesce a trovare un certificato per un dominio del registry privato specifico. Puoi verificare questo errore in Cloud Logging utilizzando la seguente query:

1. Vai alla pagina Esplora log nella console Google Cloud:

   Vai a Esplora log

2. Esegui questa query:

   ("Internal error pulling certificate" OR
   "Failed to get credentials from metadata server" OR
   "Failed to install certificate")
   

Per risolvere il problema, prova a procedere nel seguente modo:

1. In GKE Standard, apri il file di configurazione esistente nel seguente percorso:

   /etc/containerd/hosts.d/DOMAIN/config.toml
   

   Sostituisci DOMAIN con il nome di dominio completo del registro.

2. Verifica che il file di configurazione contenga il nome di dominio completo corretto.

3. Verifica che il percorso del certificato nel campo secretURI del file di configurazione sia corretto.

4. Verifica che il certificato esista in Secret Manager.

Certificato non presente

Questo problema si verifica se GKE non riesce a estrarre il certificato da Secret Manager per configurare containerd sui tuoi nodi.

Per risolvere il problema, prova a procedere nel seguente modo:

1. Assicurati che il nodo interessato esegua Container-Optimized OS. I nodi Ubuntu e Windows non sono supportati.
2. Nel file di configurazione, assicurati che il percorso del secret nel campo secretURI sia corretto.
3. Verifica che l'account di servizio IAM del cluster disponga delle autorizzazioni corrette per accedere al secret.
4. Verifica che il cluster abbia l'ambito di accesso cloud-platform. Per le istruzioni, consulta Controllare gli ambiti di accesso.

L'opzione del Registro di sistema non sicuro non è configurata per la rete locale (10.0.0.0/8)

Versioni GKE interessate: tutte

Nelle immagini containerd, l'opzione del registro non sicuro non è configurata per la rete locale 10.0.0.0/8. Se utilizzi registri privati non sicuri, potresti notare errori simili ai seguenti:

pulling image: rpc error: code = Unknown desc = failed to pull and unpack image "IMAGE_NAME": failed to do request: Head "IMAGE_NAME": http: server gave HTTP response to HTTPS client

Per risolvere il problema, prova a procedere nel seguente modo:

• Utilizza Artifact Registry.
• Configura TLS sui registri privati se il tuo caso d'uso supporta questa opzione. Puoi utilizzare un file di configurazione containerd per indicare a GKE di utilizzare i certificati archiviati in Secret Manager per accedere al tuo registro privato. Per le istruzioni, consulta Accedere a registri privati con certificati CA privati.

Configura i DaemonSet con privilegi per modificare la configurazione containerd

Per i cluster standard, prova i seguenti passaggi. Questa soluzione alternativa non è disponibile in Autopilot perché i container con privilegi rappresentano un rischio per la sicurezza. Se il tuo ambiente è esposto a internet, valuta la tua tolleranza di rischio prima di eseguire il deployment di questa soluzione. In tutti i casi, consigliamo vivamente di configurare TLS per il registro privato e utilizzare invece l'opzione Secret Manager.

Attenzione: questa operazione richiede un riavvio containerd, che potrebbe causare interruzioni dei carichi di lavoro già in esecuzione sul nodo.

1. Esamina il seguente manifest:

   apiVersion: apps/v1
   kind: DaemonSet
   metadata:
     name: insecure-registries
     namespace: default
     labels:
       k8s-app: insecure-registries
   spec:
     selector:
       matchLabels:
         name: insecure-registries
     updateStrategy:
       type: RollingUpdate
     template:
       metadata:
         labels:
           name: insecure-registries
       spec:
         nodeSelector:
           cloud.google.com/gke-container-runtime: "containerd"
         hostPID: true
         containers:
           - name: startup-script
             image: gcr.io/google-containers/startup-script:v1
             imagePullPolicy: Always
             securityContext:
               privileged: true
             env:
             - name: ADDRESS
               value: "REGISTRY_ADDRESS"
             - name: STARTUP_SCRIPT
               value: |
                 set -o errexit
                 set -o pipefail
                 set -o nounset
   
                 if [[ -z "$ADDRESS" || "$ADDRESS" == "REGISTRY_ADDRESS" ]]; then
                   echo "Error: Environment variable ADDRESS is not set in containers.spec.env"
                   exit 1
                 fi
   
                 echo "Allowlisting insecure registries..."
                 containerd_config="/etc/containerd/config.toml"
                 hostpath=$(sed -nr 's;  config_path = "([-/a-z0-9_.]+)";\1;p' "$containerd_config")
                 if [[ -z "$hostpath" ]]; then
                   echo "Node uses CRI config model V1 (deprecated), adding mirror under $containerd_config..."
                   grep -qxF '[plugins."io.containerd.grpc.v1.cri".registry.mirrors."'$ADDRESS'"]' "$containerd_config" || \
                     echo -e '[plugins."io.containerd.grpc.v1.cri".registry.mirrors."'$ADDRESS'"]\n  endpoint = ["http://'$ADDRESS'"]' >> "$containerd_config"
                 else
                   host_config_dir="$hostpath/$ADDRESS"
                   host_config_file="$host_config_dir/hosts.toml"
                   echo "Node uses CRI config model V2, adding mirror under $host_config_file..."
                   if [[ ! -e "$host_config_file" ]]; then
                     mkdir -p "$host_config_dir"
                     echo -e "server = \"https://$ADDRESS\"\n" > "$host_config_file"
                   fi
                   echo -e "[host.\"http://$ADDRESS\"]\n  capabilities = [\"pull\", \"resolve\"]\n" >> "$host_config_file"
                 fi
                 echo "Reloading systemd management configuration"
                 systemctl daemon-reload
                 echo "Restarting containerd..."
                 systemctl restart containerd

   Nel campo .spec.containers.env, sostituisci il valore REGISTRY_ADDRESS della variabile ADDRESS con l'indirizzo del tuo registro HTTP locale nel formato DOMAIN_NAME:PORT. Ad esempio:

   containers:
   - name: startup-script
     ...
     env:
     - name: ADDRESS
       value: "example.com:5000"
   

2. Esegui il deployment del DaemonSet:

   kubectl apply -f insecure-registry-ds.yaml
   

Il DaemonSet aggiunge il registro non sicuro alla configurazione containerd su ogni nodo.

containerd ignora qualsiasi mappatura dei dispositivi per i pod con privilegi

Versioni GKE interessate: tutte

Per i pod Kubernetes con privilegi, il runtime del container ignora qualsiasi mappatura dei dispositivi che volumeDevices.devicePath passa al container e rende disponibile per il container ogni dispositivo sull'host in /dev.

processi di shim delle perdite containerd quando i nodi sono sotto pressione di I/O

Versioni di GKE interessate: da 1.25.0 a 1.25.15-gke.1040000, da 1.26.0 a 1.26.10-gke.1030000, da 1.27.0 a 1.27.6-gke.1513000 e da 1.28.0.0 a 1.28.0

Quando un nodo GKE è sottoposto a pressione di I/O, containerd potrebbe non riuscire a eliminare i processi containerd-shim-runc-v2 quando viene eliminato un pod, con conseguenti perdite di processi. Quando si verifica la perdita su un nodo, vedrai più processi containerd-shim-runc-v2 sul nodo rispetto al numero di pod su quel nodo. Potresti anche notare un aumento dell'utilizzo di memoria e CPU insieme a PID aggiuntivi. Per maggiori dettagli, consulta il problema di GitHub Correggere la perdita di shim causata da un'elevata pressione I/O.

Per risolvere questo problema, esegui l'upgrade dei nodi alle seguenti versioni o a versioni successive:

• 1.25.15-gke.1040000
• 1.26.10-gke.1030000
• 1.27.6-gke.1513000
• 1.28.3-gke.1061000

La famiglia di indirizzi IPv6 è abilitata sui pod che eseguono containerd

Versioni di GKE interessate: 1.18, 1.19, da 1.20.0 a 1.20.9

La famiglia di immagini IPv6 è abilitata per i pod in esecuzione con containerd. L'immagine dockershim disabilita IPv6 su tutti i pod, al contrario dell'immagine containerd. Ad esempio, localhost viene risolto prima nell'indirizzo IPv6 ::1. In genere questo non costituisce un problema, ma in alcuni casi potrebbe verificarsi un comportamento imprevisto.

Soluzione

Per risolvere questo problema, utilizza un indirizzo IPv4 come 127.0.0.1 in modo esplicito oppure configura un'applicazione in esecuzione nel pod in modo che funzioni su entrambe le famiglie di indirizzi.

Solo il provisioning automatico dei nodi esegue il provisioning Container-Optimized OS con i pool di nodi Docker

Versioni GKE interessate: 1.18, 1.19, da 1.20.0 a 1.20.6-gke.1800

Il provisioning automatico dei nodi consente la scalabilità automatica dei pool di nodi con qualsiasi tipo di immagine supportato, ma può creare solo nuovi pool di nodi con il tipo di immagine Container-Optimized OS con Docker.

Soluzione

Per risolvere questo problema, esegui l'upgrade dei cluster GKE alla versione 1.20.6-gke.1800 o successiva. In queste versioni di GKE, il tipo di immagine predefinito può essere impostato per il cluster.

Conflitto con 172.17/16 intervallo di indirizzi IP

Versioni di GKE interessate: dalla 1.18.0 alla 1.18.14

L'intervallo di indirizzi IP 172.17/16 è occupato dall'interfaccia docker0 sulla VM nodo con containerd abilitato. Il traffico inviato a o proveniente da quell'intervallo potrebbe non essere instradato correttamente (ad esempio, un pod potrebbe non riuscire a connettersi a un host connesso a VPN con un indirizzo IP all'interno di 172.17/16).

Metriche GPU non raccolte

Versioni di GKE interessate: dalla 1.18.0 alla 1.18.18

Le metriche di utilizzo della GPU non vengono raccolte quando si utilizza containerd come runtime nelle versioni di GKE precedenti alla 1.18.18.

Soluzione

Per risolvere questo problema, esegui l'upgrade dei cluster a GKE versione 1.18.18 o successiva.

Le immagini con config.mediaType impostato su application/octet-stream non possono essere utilizzate in containerd

Versioni GKE interessate: tutte

Le immagini con config.mediaType impostato su "application/octet-stream" non possono essere utilizzate in containerd. Per maggiori informazioni, consulta il problema di GitHub n. 4756. Queste immagini non sono compatibili con la specifica Open Container Initiative e sono considerate errate. Queste immagini funzionano con Docker per garantire la compatibilità con le versioni precedenti, mentre in containerd non sono supportate.

Sintomo e diagnosi

Errore di esempio nei log del nodo:

Error syncing pod <pod-uid> ("<pod-name>_<namespace>(<pod-uid>)"), skipping: failed to "StartContainer" for "<container-name>" with CreateContainerError: "failed to create containerd container: error unpacking image: failed to extract layer sha256:<some id>: failed to get reader from content store: content digest sha256:<some id>: not found"

In genere, il file manifest dell'immagine si trova nel registro in cui è ospitato. Una volta ottenuto il manifest, controlla config.mediaType per determinare se riscontra il problema:

"mediaType": "application/octet-stream",

Soluzione

Poiché la community di containerd ha deciso di non supportare queste immagini, tutte le versioni di containerd sono interessate e non è disponibile alcuna soluzione. L'immagine container deve essere ricreata con Docker versione 1.11 o successiva e devi assicurarti che il campo config.mediaType non sia impostato su "application/octet-stream".

Configurazione CNI non inizializzata

Versioni GKE interessate: tutte

GKE non è in grado di creare nodi durante un upgrade, un ridimensionamento o un'altra azione.

Sintomo e diagnosi

Esempio di errore nella console Google Cloud:

Error: "runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not ready: cni config uninitialized".

Questo errore può verificarsi nelle seguenti situazioni:

• Durante il bootstrap dei nodi nei file di log, mentre GKE installa la configurazione CNN.
• Come stato di errore del nodo nella console Google Cloud se un webhook personalizzato che intercetta il comando del controller DaemonSet per creare un pod contiene errori. Ciò impedisce a GKE di creare un pod netd o calico-node. Se i pod netd o calico-node sono stati avviati correttamente mentre l'errore persiste, contatta l'assistenza.

Soluzione

Per risolvere il problema, prova le seguenti soluzioni:

• Attendi il completamento dell'installazione della configurazione CNI da parte di GKE.
• Rimuovi eventuali webhook configurati in modo errato.
• Configura webhook per ignorare i pod di sistema.

Passaggi successivi

Se hai bisogno di ulteriore aiuto, contatta l'assistenza clienti Google Cloud.