Risoluzione dei problemi relativi al runtime del container

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

Se hai bisogno di ulteriore assistenza, contatta Assistenza clienti Google Cloud.

I percorsi di montaggio con lettere di unità semplici hanno esito negativo sui pool di nodi Windows con containerd

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

Cluster GKE che eseguono pool di nodi Windows Server che utilizzano Il runtime containerd precedente alla versione 1.6.6 potrebbe riscontrare errori all'avvio di container come i seguenti:

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

Per maggiori dettagli, consulta la pagina relativa al problema GitHub n. 6589.

Soluzione

Per risolvere il problema, esegui l'upgrade dei pool di nodi all'ultima versione di GKE che utilizza il runtime containerd 1.6.6 o versioni successive.

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

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

Cluster GKE che eseguono pool di nodi Windows Server che utilizzano containerd runtime 1.5.X potrebbe riscontrare errori durante l'avvio dei container, ad esempio le seguenti:

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

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

Soluzione

Per risolvere il problema, esegui l'upgrade dei pool di nodi all'ultima versione di GKE che utilizza il runtime containerd 1.6.6 o versioni successive.

I volumi di immagini container con percorsi non esistenti o percorsi di tipo Linux (barra) hanno esito negativo sui pool di nodi Windows con containerd

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

Cluster GKE che eseguono pool di nodi Windows Server che utilizzano containerd runtime 1.5.X potrebbe riscontrare errori durante l'avvio dei container, ad esempio le seguenti:

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

Per maggiori dettagli, consulta la pagina relativa al problema GitHub #5671.

Soluzione

Per risolvere il problema, esegui l'upgrade dei pool di nodi all'ultima versione di GKE che utilizza il runtime containerd 1.6.x o versioni successive.

/etc/mtab: il file o la directory non sono presenti

Il runtime del container Docker compila questo link simbolico all'interno del container predefinito, al contrario del runtime containerd.

Per maggiori dettagli, consulta la pagina relativa al problema 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 pull immagine: non è una directory

Versioni GKE interessate: tutte

Quando crei un'immagine con kaniko, potrebbe non essere possibile eseguire il pull con containerd con il messaggio di errore "non è una directory". Questo errore si verifica se l'immagine è stata creata in un modo speciale, ad esempio quando 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 maggiori dettagli, consulta la pagina relativa al problema GitHub n. 4659.

Soluzione

Per risolvere il problema, crea l'immagine utilizzando docker build, che rimane invariato da questo problema.

Se docker build non è un'opzione per te, combina i comandi in un solo comando. 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

Versioni GKE interessate: tutte

L'endpoint Kubelet /metrics/cadvisor fornisce metriche Prometheus, come documentato in Metriche per i componenti di sistema Kubernetes. Se installi un raccoglitore delle metriche che dipende da quell'endpoint, potresti vedere 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>.

  • Sul 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 limitare il 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 nel daemonset Kubernetes di cAdvisor per creare il daemonset.
  3. Punta il raccoglitore delle metriche installate per utilizzare cAdvisor /metrics 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 l'insieme completo delle metriche container.
  2. Raccogliere metriche dall'API Kubelet summary con un endpoint di /stats/summary.

Le operazioni basate su collegamenti non funzionano correttamente dopo il riavvio 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

Cluster GKE che eseguono pool di nodi Windows Server che utilizzano il runtime containerd (versione 1.5.4 e 1.5.7-gke.0) potrebbe riscontrare problemi se il runtime del container viene riavviato forzatamente, con le operazioni di collegamento a i container in esecuzione non riescono a ricollegare l'I/O. Il problema non causerà errori nelle chiamate API, ma i dati non verranno inviati o ricevuti. Sono inclusi dati per collegare e registrare le interfacce a riga di comando e le API 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.

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

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

I cluster GKE che eseguono pool di nodi che utilizzano containerd rilevare problemi di fughe 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 ulteriori informazioni sul problema, consulta containerd GitHub numero 5438 e il problema n. 5768 di GitHub.

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

Soluzione

Per risolvere il problema, segui le soluzioni citate nel Soluzioni per i cluster GKE standard per GKE Dataplane V2.

Differenza di 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 su dockershim immagini. Quando il probe exec, definito per il pod, supera la soglia dichiarato Kubernetes timeoutSeconds su dockershim immagini, viene considerato come un errore del probe. Sulle immagini containerizzate, i risultati del probe sono restituiti dopo il valore timeoutSeconds dichiarato vengono ignorate.

Soluzione

In GKE, il gate di funzionalità ExecProbeTimeout è impostato su false e non possono essere modificate. Per risolvere il problema, aumenta il Soglia timeoutSeconds per tutti i probe exec interessati o implementa il timeout come parte della logica del probe.

Risolvere i problemi relativi ai registri privati

Questa sezione fornisce informazioni sulla risoluzione dei problemi relativi al 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 è riuscito a trovare un certificato per un dominio privato del registry specifico. Puoi verificare la presenza di 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 esiste 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 nella di configurazione del deployment sia corretto.

  4. Verifica che il certificato esista in Secret Manager.

Certificato non presente

Questo problema si verifica se GKE non è riuscito a eseguire il pull del 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 Il campo secretURI è corretto.
  3. Verifica che l'account di servizio IAM del cluster sia corretto autorizzazioni per accedere al secret.
  4. Verifica che il cluster abbia l'ambito di accesso cloud-platform. Per istruzioni, consulta Controllare gli ambiti di accesso.

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

Versioni GKE interessate: tutte

Nelle immagini containerd, l'opzione del Registro di sistema non sicuro non è configurata per gli indirizzi la rete 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:

  • Utilizzare Artifact Registry
  • Configura TLS nei tuoi registri privati se il tuo caso d'uso supporta questa opzione. Puoi utilizzare un file di configurazione in container per indicare a GKE per utilizzare i certificati archiviati in Secret Manager per accedere del tuo registro privato. Per istruzioni, vedi Accedi ai registri privati con certificati CA privati.

Configurare DaemonSet con privilegi per modificare la configurazione containerd

Per i cluster Standard, prova a seguire questi passaggi. Questa soluzione alternativa disponibile in Autopilot, perché i container con privilegi sono ai rischi. Se il tuo ambiente è esposto a internet, considera il rischio prima di eseguire il deployment di questa soluzione. In ogni caso, ti consigliamo devi configurare TLS per il tuo registro privato e utilizzare 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: 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 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 tuo registro non sicuro alla configurazione containerd su in ogni nodo.

containerd ignora eventuali mappature dei dispositivi per i pod con privilegi

Versioni GKE interessate: tutte

Per i pod Kubernetes con privilegi, il runtime del container ignora eventuali mappature dei dispositivi che volumeDevices.devicePath passibile, rendendo ogni dispositivo sull'host disponibile per il container sotto /dev.

le perdite containerizzate emettono processi shim quando i nodi sono sotto pressione di 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.10.28.0 a 1.20.8.0

Quando un nodo GKE è sottoposto a pressione di I/O, containerd potrebbe non riuscire a dei processi containerd-shim-runc-v2 quando viene eliminato un pod, durante le fughe di dati nei processi. Quando la perdita si verifica su un nodo, vedrai più containerd-shim-runc-v2 processi sul nodo rispetto al numero di pod su quel nodo nodo. Potresti anche notare un aumento dell'utilizzo di memoria e CPU insieme a PID aggiuntivi. Per maggiori dettagli, consulta il problema relativo a GitHub Correzione dello spessore fuoriuscito causato da un'elevata pressione di I/O.

Per risolvere il problema, esegui l'upgrade dei nodi alle versioni seguenti 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, 1.20.0 e 1.20.9

La famiglia di immagini IPv6 è abilitata per i pod in esecuzione con containerd. dockershim disabilita IPv6 su tutti i pod, al contrario dell'immagine containerd. Per Ad esempio, localhost viene prima risolto nell'indirizzo IPv6 ::1. Generalmente non si tratta di un problema, ma in alcuni casi ciò potrebbe causare un comportamento imprevisto.

Soluzione

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

Il provisioning automatico dei nodi esegue solo il provisioning di 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

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

Soluzione

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

Conflitto con l'intervallo di indirizzi IP di 172.17/16

Versioni GKE interessate: dalla 1.18.0 alla 1.18.14

L'intervallo di indirizzi IP 172.17/16 è occupato dall'interfaccia docker0 sul VM nodo con containerd abilitato. Traffico che invia o proviene da lì potrebbe non essere instradato correttamente (ad esempio, un pod potrebbe non essere in grado connettiti a un host connesso a VPN con un indirizzo IP all'interno di 172.17/16).

Metriche GPU non raccolte

Versioni GKE interessate: dalla 1.18.0 alla 1.18.18

Le metriche di utilizzo delle GPU non sono raccolti quando si utilizza containerd come runtime nelle versioni GKE prima del 18.1.18.

Soluzione

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

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

Versioni GKE interessate: tutte

Immagini con config.mediaType impostato su "application/octet-stream" non può essere utilizzato su containerd. Per ulteriori informazioni, vedi GitHub numero 4756. Queste immagini non sono compatibili con la specifica Open Container Initiative e vengono considerate errate. Queste immagini funzionano con Docker per fornire compatibilità, mentre in containerd queste immagini non sono supportate.

Sintomo 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 è disponibile nel registro in cui è ospitato. Una volta ottenuto il manifest, controlla config.mediaType per stabilire se presenti questo problema:

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

Soluzione

Poiché la community containerd ha deciso di non supportare tali immagini, versioni di containerd sono interessate e non c'è soluzione. L'immagine container deve essere ricreato con Docker versione 1.11 o successiva e devi assicurarti che Il campo config.mediaType non è impostato su "application/octet-stream".

Configurazione CNI non inizializzata

Versioni GKE interessate: tutte

GKE non riesce a creare nodi durante un upgrade, un ridimensionamento un'altra azione.

Sintomo e diagnosi

Errore di esempio 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 del nodo nei file di log mentre GKE installa la Config. CNI
  • Come stato di errore del nodo nella console Google Cloud se un webhook personalizzato intercetta il comando DaemonSet controller per creare un pod che presenta errori. Questo impedisce a GKE di creare un pod netd o calico-node. Se netd o calico-node pod sono stati avviati correttamente mentre l'errore persiste. contatta l'assistenza.

Soluzione

Per risolvere il problema, prova le seguenti soluzioni:

  • Attendi che GKE completi l'installazione della configurazione CNI.
  • Rimuovi eventuali webhook configurati in modo errato.
  • Configura webhook per ignorare i pod di sistema.

Passaggi successivi

Se hai bisogno di ulteriore assistenza, contatta Assistenza clienti Google Cloud.