Risoluzione dei problemi del runtime del container

I problemi con il runtime del container sui nodi Google Kubernetes Engine (GKE) possono causare una serie di errori dei workload, impedendo l'avvio o l'esecuzione affidabile dei container. Questi problemi sono spesso causati da problemi come configurazioni errate della rete, problemi di autorizzazione o differenze tra i runtime dei container.

Utilizza questa pagina per risolvere i problemi comuni con il runtime del container sui node pool GKE. Trova soluzioni per problemi come errori del percorso di montaggio su Windows, pull delle immagini non riusciti da registri privati, metriche del file system mancanti, errori di inizializzazione CNI e differenze di comportamento nei probe exec.

Queste informazioni sono importanti per gli amministratori e gli operatori della piattaforma e per gli sviluppatori di applicazioni che gestiscono ed eseguono il deployment dei workload sui cluster GKE. La comprensione di questi passaggi per la risoluzione dei problemi può contribuire a garantire che i container vengano eseguiti in modo affidabile su diverse immagini e configurazioni dei nodi. Per ulteriori informazioni sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei Google Cloud contenuti, consulta Ruoli e attività comuni degli utenti GKE .

I percorsi di montaggio con lettere di unità semplici non funzionano sui node pool Windows con containerd

Questo problema è stato risolto nella versione 1.6.6 e successive di containerd.

I cluster GKE che eseguono node pool Windows Server che utilizzano il runtime containerd precedente alla versione 1.6.6 potrebbero riscontrare errori all'avvio dei container, ad esempio:

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

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

Soluzione

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

Le immagini container con righe di comando CMD o ENTRYPOINT pre-escape non array non funzionano sui node pool Windows con containerd

Questo problema è stato risolto nella versione 1.6 e successive di containerd.

I cluster GKE che eseguono node pool Windows Server che utilizzano il runtime containerd 1.5.X potrebbero riscontrare errori all'avvio dei container, ad esempio:

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

Per ulteriori dettagli, consulta il problema n. 5067 di GitHub e il problema n. 6300 di GitHub.

Soluzione

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

I volumi delle immagini container con percorsi inesistenti o di tipo Linux (barra) non funzionano sui node pool Windows con containerd

Questo problema è stato risolto nella versione 1.6 e successive di containerd.

I cluster GKE che eseguono node pool Windows Server che utilizzano il runtime containerd 1.5.X potrebbero riscontrare errori all'avvio dei container, ad esempio:

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

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

Soluzione

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

/etc/mtab: No such file or directory

Il runtime del container Docker popola questo link simbolico all'interno del container per impostazione predefinita, ma il runtime containerd no.

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

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: not a directory

Versioni GKE interessate: tutte

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

Il seguente esempio di Dockerfile con npm illustra questo problema.

RUN npm cache clean --force
RUN npm install

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

Soluzione

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

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

RUN npm cache clean --force && npm install

Alcune metriche del file system sono mancanti e il formato delle metriche è diverso

Versioni GKE interessate: tutte

L'endpoint /metrics/cadvisor di Kubelet fornisce metriche Prometheus, come descritto in Metriche per i componenti di sistema 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> mentre il formato sul nodo containerd è <container-id>.

  • Alcune metriche del file system sono mancanti sul nodo containerd, 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 attenuare questo problema utilizzando cAdvisor come DaemonSet autonomo.

  1. Trova la release più recente di cAdvisor con il pattern di nome vX.Y.Z-containerd-cri (ad esempio, v0.42.0-containerd-cri).
  2. Segui i passaggi descritti in cAdvisor Kubernetes Daemonset per creare il DaemonSet.
  3. Indica all'agente di raccolta di metriche installato di utilizzare l'endpoint /metrics di cAdvisor che fornisce l'insieme completo di metriche dei container Prometheus.

Alternative

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

Le operazioni basate su attach non funzionano correttamente dopo i riavvii del runtime del 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 node pool Windows Server che utilizzano il runtime containerd (versioni 1.5.4 e 1.5.7-gke.0) potrebbero riscontrare problemi se il runtime del container viene riavviato forzatamente, con le operazioni di attach ai container in esecuzione esistenti che non sono in grado di associare nuovamente l'I/O. Il problema non causerà errori nelle chiamate API, ma i dati non verranno inviati o ricevuti. Sono inclusi i dati per le API e le CLI di attach e log tramite il server API del cluster.

Soluzione

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

Differenza di comportamento del probe exec quando il probe supera il timeout

Versioni GKE interessate: tutte

Il comportamento del probe exec sulle immagini containerd è diverso dal comportamento sulle immagini dockershim. Quando il probe exec definito per il pod supera la soglia Kubernetes timeoutSeconds dichiarata, sulle immagini dockershim viene trattato come un errore del probe. Sulle immagini containerd, i risultati del probe restituiti dopo la soglia timeoutSeconds dichiarata vengono ignorati.

Soluzione

In GKE, il gate di funzionalità ExecProbeTimeout è impostato su false e non può essere modificato. 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 registri privati

Questa sezione fornisce informazioni per la risoluzione dei problemi relativi alle configurazioni dei registri privati in containerd.

Il pull dell'immagine non riesce con l'errore x509: certificate signed by unknown authority

Questo problema si verifica se GKE non è riuscito a trovare un certificato per un dominio di registro privato specifico. Puoi verificare la presenza di questo errore in Cloud Logging utilizzando la seguente query:

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

    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 nel seguente percorso:

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

    Sostituisci DOMAIN con l'FQDN del registro.

  2. Verifica che il file di configurazione contenga l'FQDN 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.

Certificate not present

Questo problema si verifica se GKE non è riuscito a eseguire il pull del certificato da Secret Manager per configurare containerd sui nodi. Se GKE non riesce ad accedere al certificato, il nodo viene avviato senza il certificato. I workload in esecuzione sul nodo non possono accedere al registro privato.

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 il 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 istruzioni, consulta Controllare gli ambiti di accesso.

  5. Ricrea il nodo utilizzando uno dei seguenti metodi:

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

Versioni GKE interessate: tutte

Sulle 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:

Configurare i DaemonSet con privilegi per modificare la configurazione di containerd

Per i cluster Standard, prova a seguire questi 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 al rischio prima di eseguire il deployment di questa soluzione. In tutti i casi, ti consigliamo vivamente di configurare TLS per il registro privato e di utilizzare l'opzione Secret Manager.

  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: gke.gcr.io/startup-script:v2
          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 REGISTRY_ADDRESS valore della variabile ADDRESS con l'indirizzo del 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 di containerd su ogni nodo.

containerd ignora tutti i mapping dei dispositivi per i pod con privilegi

Versioni GKE interessate: tutte

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

containerd perde i processi shim quando i nodi sono sotto pressione I/O

Versioni 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 a 1.28.3-gke.1061000

Quando un nodo GKE è sotto pressione I/O, containerd potrebbe non riuscire a eliminare i processi containerd-shim-runc-v2 quando un pod viene eliminato, causando perdite di processi. Quando si verifica una 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 i dettagli, consulta il problema di GitHub Correzione della perdita di shim causata da un'elevata pressione I/O.

Per risolvere il problema, esegui l'upgrade dei nodi alle seguenti versioni o 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 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, mentre l'immagine containerd no. Ad esempio, localhost viene risolto prima nell'indirizzo IPv6 ::1. In genere non si tratta di un problema, ma in alcuni casi potrebbe comportare un comportamento imprevisto.

Soluzione

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

Conflitto con l'intervallo di indirizzi IP 172.17/16

Versioni GKE interessate: da 1.18.0 a 1.18.14

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

Metriche della GPU non raccolte

Versioni GKE interessate: da 1.18.0 a 1.18.18

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

Soluzione

Per risolvere il problema, esegui l'upgrade dei cluster alle versioni GKE 1.18.18 o successive.

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

Versioni GKE interessate: tutte

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

Sintomi e diagnosi

Esempio di errore nei log dei nodi:

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 manifest dell'immagine si trova nel registro in cui è ospitata. Una volta ottenuto il manifest, controlla config.mediaType per determinare se hai questo 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 esiste una correzione. L'immagine container deve essere ricompilata con Docker versione 1.11 o successive e devi assicurarti che il config.mediaType campo non sia impostato su "application/octet-stream".

CNI not initialized

Versioni GKE interessate: tutte

Se visualizzi un errore simile al seguente, la configurazione dell'interfaccia di rete del container (CNI) non è pronta:

Error: "network is not ready: container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:Network plugin returns error: cni plugin not initialized".

Questo errore si verifica principalmente per due motivi:

  • L'installazione di CNI non è stata completata
  • Il webhook non è configurato correttamente

Assicurarsi che l'installazione di CNI sia stata completata

Potresti visualizzare questo errore nei file di log durante il bootstrapping del nodo mentre GKE installa la configurazione CNI. Se visualizzi questo errore, ma GKE sta creando correttamente tutti i nodi, puoi ignorarlo in sicurezza.

Questa situazione può verificarsi perché CNI fornisce ai pod la connettività di rete, quindi i pod hanno bisogno di CNI per funzionare. Tuttavia, Kubernetes utilizza le incompatibilità per contrassegnare i nodi non pronti e i pod di sistema possono tollerare queste incompatibilità. Ciò significa che i pod di sistema possono essere avviati su un nuovo nodo prima che la rete sia pronta, causando l'errore.

Per risolvere il problema, attendi che GKE completi l'installazione della configurazione CNI. Al termine della configurazione della rete da parte di CNI, i pod di sistema vengono avviati correttamente senza richiedere alcun intervento.

Correggere i webhook configurati in modo errato

Se l'errore di inizializzazione di CNI persiste e noti che GKE non riesce a creare nodi durante un upgrade, una modifica delle dimensioni o un'altra azione, potresti avere un webhook configurato in modo errato.

Se hai un webhook personalizzato che intercetta il comando del controller DaemonSet per creare un pod e questo webhook non è configurato correttamente, potresti visualizzare l'errore come stato di errore del nodo nella Google Cloud console. Questa configurazione errata 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 clienti.

Per correggere eventuali webhook configurati in modo errato, completa i seguenti passaggi:

  1. Identifica i webhook configurati in modo errato.

    Se utilizzi un cluster con l'applicazione dei criteri di rete Dataplane V1 abilitata, puoi anche controllare lo stato del pod calico-typha per informazioni sui webhook che causano questo errore:

    kubectl describe pod -n kube-system -l k8s-app=calico-typha

    Se il pod presenta un errore, l'output è simile al seguente:

    Events:
Type     Reason        Age                     From                   Message
----     ------        ----                    ----                   -------
Warning  FailedCreate  9m15s (x303 over 3d7h)  replicaset-controller  Error creating: admission webhook WEBHOOK_NAME denied the request [...]

    In questo output, WEBHOOK_NAME è il nome di un webhook non riuscito. L'output potrebbe includere informazioni su un tipo di errore diverso.

  2. Se vuoi conservare i webhook configurati in modo errato, risolvi i problemi. Se non sono necessari, eliminali eseguendo i seguenti comandi:

    kubectl delete mutatingwebhookconfigurations WEBHOOK_NAME
kubectl delete validatingwebhookconfigurations WEBHOOK_NAME

    Sostituisci WEBHOOK_NAME con il nome del webhook configurato in modo errato che vuoi rimuovere.

  3. Configura i webhook in modo che ignorino i pod di sistema.

Passaggi successivi