Risoluzione dei problemi relativi al runtime del container

Questo documento fornisce la procedura di risoluzione dei problemi comuni che potresti riscontrare con il runtime del contenitore sui nodi Google Kubernetes Engine (GKE).

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

I percorsi di montaggio con lettere di unità semplici non vanno a buon fine nei pool di nodi Windows con containerd

Questo problema è stato risolto in containerd versione 1.6.6 e 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 all'avvio dei container, ad esempio:

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

Per maggiori dettagli, consulta il problema 6589 di GitHub.

Soluzione

Per risolvere il 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 con escape precedente non array non vanno a buon fine 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 durante l'avvio dei container, ad esempio:

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

Per maggiori dettagli, consulta l'issue 5067 di GitHub e l'issue 6300 di GitHub.

Soluzione

Per risolvere il 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 dei container con percorsi non esistenti o percorsi simili a Linux (barra) non vanno a buon fine 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 durante l'avvio dei container, ad esempio:

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

Per maggiori dettagli, consulta il problema 5671 di GitHub.

Soluzione

Per risolvere il 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: nessun file o directory corrispondente

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

Per maggiori dettagli, consulta il problema 2419 di GitHub.

Soluzione

Per risolvere il problema, crea manualmente il link simbolico /etc/mtab durante la compilazione 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 estrarla 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 che illustra questo problema.

RUN npm cache clean --force
RUN npm install

Per maggiori dettagli, consulta il problema 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 per te, 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

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

Versioni GKE interessate: tutte

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

  • Alcune metriche del file system mancano 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 cAdvisor più recente con il pattern di nome vX.Y.Z-containerd-cri (ad es. v0.42.0-containerd-cri).
  2. Segui i passaggi descritti in Daemonset Kubernetes cAdvisor per creare il daemonset.
  3. Indica al raccoglitore delle metriche installato di utilizzare il punto di contatto /metrics cAdvisor che fornisce l'insieme completo di metriche dei contenitori Prometheus.

Alternative

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

Le operazioni basate su attach non funzionano correttamente dopo i riavvii del runtime del contenitore 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 (versioni 1.5.4 e 1.5.7-gke.0) potrebbero riscontrare problemi se il runtime del contenitore viene riavviato forzatamente, con le operazioni di attacco ai contenitori in esecuzione esistenti che non riescono a eseguire nuovamente il binding dell'I/O. Il problema non causerà errori nelle chiamate API, ma i dati non verranno inviati o ricevuti. Sono inclusi i dati per l'attacco e i log delle interfacce a riga di comando e delle API tramite il server API del cluster.

Soluzione

Per risolvere il problema, esegui l'upgrade alla versione del runtime del contenitore con patch (1.5.7-gke.1) con 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 precedente, 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 potrebbero riscontrare problemi di fuga 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 il problema GitHub 5438 e il problema GitHub 5768 relativi a containerd.

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 alternative indicate nella sezione Soluzioni alternative per i cluster GKE standard per GKE Dataplane V2.

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

Versioni GKE interessate: tutte

Il comportamento della prova di esecuzione sulle immagini containerd è diverso da quello sulle immagini dockershim. Quando il probe di esecuzione definito per il pod supera la soglia timeoutSeconds Kubernetes dichiarata, nelle immagini dockershim viene trattato come un errore del probe. Nelle immagini containerd, i risultati del probe restituiti dopo la soglia timeoutSeconds declarata 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 tutte le prove exec interessate o implementa la funzionalità di timeout nell'ambito della logica della prova.

Risolvere i problemi relativi ai registry privati

Questa sezione fornisce informazioni sulla risoluzione dei problemi relativi alle configurazioni del registry privato in containerd.

Il recupero delle immagini non va a buon fine con 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 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 quanto segue:

  1. In GKE Standard, apri il file di configurazione che si trova nel seguente percorso:

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

    Sostituisci DOMAIN con il FQDN per il registry.

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

Certificato non presente

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

Per risolvere il problema, prova quanto segue:

  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 della chiave nel 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 Verificare gli ambiti di accesso.

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

Versioni GKE interessate: tutte

Nelle immagini containerd, l'opzione del registry non sicuro non è configurata per la rete locale 10.0.0.0/8. Se utilizzi registry 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 quanto segue:

  • Utilizzare Artifact Registry
  • Configura TLS nei tuoi registry 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 registry privato. Per le istruzioni, consulta Accedere ai registry privati con certificati CA privati.

Configura DaemonSet con privilegi per modificare la configurazione di 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 al rischio prima di implementare questa soluzione. In ogni caso, ti consigliamo vivamente di configurare TLS per il tuo registry 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: registry.k8s.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 valore REGISTRY_ADDRESS della variabile ADDRESS con l'indirizzo del registry 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 registry non sicuro alla configurazione di containerd su ogni nodo.

containerd ignora le mappature dei dispositivi per i pod con privilegi

Versioni GKE interessate: tutte

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

containerd perde 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 viene eliminato un pod, con conseguente perdita di processi. Quando la perdita si verifica su un nodo, vedrai più processi containerd-shim-runc-v2 sul nodo rispetto al numero di pod sul nodo. Potresti anche notare un aumento dell'utilizzo di memoria e CPU, oltre a PID aggiuntivi. Per maggiori dettagli, consulta il problema GitHub Correzione della perdita di shim causata da una pressione IO elevata.

Per risolvere il problema, esegui l'upgrade dei tuoi nodi alle seguenti versioni o 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 è attivata 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 disattiva IPv6 su tutti i pod, mentre l'immagine containerd no. Ad esempio, localhost viene risolto prima nell'indirizzo IPv6 ::1. In genere non è un problema, ma in alcuni casi potrebbe verificarsi 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.

Il provisioning automatico dei nodi esegue il provisioning solo di Container-Optimized OS con pool di nodi Docker

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

Il provisioning automatico dei nodi consente di eseguire 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 il 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 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 a o proveniente da questo intervallo potrebbe non essere indirizzato correttamente (ad esempio, un pod potrebbe non essere in grado di connettersi a un host connesso alla VPN con un indirizzo IP compreso tra 172.17/16).

Metriche 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 maggiori informazioni, consulta l'articolo su GitHub 4756. Queste immagini non sono compatibili con la specifica Open Container Initiative e sono considerate errate. Queste immagini funzionano con Docker per fornire compatibilità con le versioni precedenti, mentre in containerd non sono supportate.

Sintomo e diagnosi

Esempio di errore 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 manifest dell'immagine si trova nel registry in cui è ospitato. Una volta ottenuto il manifest, controlla config.mediaType per stabilire 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 del container deve essere ricostruita con Docker 1.11 o versioni successive 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 riesce a creare nodi durante un upgrade, una 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 del nodo nei file di log mentre GKE installa la configurazione CNI.
  • 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 presenta errori. In questo modo, GKE non può creare un pod netd o calico-node. Se i pod netd o calico-node sono stati avviati correttamente, ma 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 seguendo queste istruzioni:

    1. Elenca i webhook:

          $ kubectl get mutatingwebhookconfigurations
    $ kubectl get validatingwebhookconfigurations

    2. Rimuovi i webhook configurati in modo errato:

          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.

  • Configura i webhook in modo da ignorare i pod di sistema.

Passaggi successivi

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