Questo documento fornisce i passaggi per la risoluzione dei problemi comuni che potresti riscontrare con il runtime dei container sui nodi 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 hanno esito negativo sui pool di nodi Windows con containerd
Questo problema è stato risolto nella versione containerd 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 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 alle versioni GKE più recenti che utilizzano la versione 1.6.6 o successiva del runtime containerd.
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.
I cluster GKE che eseguono pool di nodi Windows Server che utilizzano il runtime containerd 1.5.X potrebbero riscontrare errori all'avvio di container come i seguenti:
failed to start containerd task : hcs::System::CreateProcess : The system cannot find the file specified.: unknown
Per maggiori dettagli, consulta GitHub problema n. 5067 e GitHub problema n. 6300.
Soluzione
Per risolvere il problema, esegui l'upgrade dei pool di nodi alle versioni GKE più recenti che utilizzano la versione 1.6.6 o successiva del runtime containerd.
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.
I cluster GKE che eseguono pool di nodi Windows Server che utilizzano il runtime containerd 1.5.X potrebbero riscontrare errori all'avvio di container come i 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 alle versioni GKE più recenti che utilizzano la versione 1.6.x o successiva del runtime containerd.
/etc/mtab
: il file o la directory non sono presenti
Per impostazione predefinita, il runtime del container Docker compila questo link simbolico all'interno del container, ma non il 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 eseguirne il pull con containerd e visualizzare il messaggio di errore "non è una directory". Questo errore si verifica se l'immagine viene creata in un modo speciale, ovvero 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 maggiori dettagli, consulta la pagina relativa al problema GitHub #4659.
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 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 componenti di sistema Kubernetes.
Se installi un raccoglitore delle metriche che dipende da quell'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>
. 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 mitigare questo problema utilizzando cAdvisor come daemonset autonomo.
- Trova l'ultima release di cAdvisor
con il pattern del nome
vX.Y.Z-containerd-cri
(ad esempio,v0.42.0-containerd-cri
). - Segui i passaggi nel daemonset Kubernetes di cAdvisor per creare il daemonset.
- Punta il raccoglitore delle metriche installate per utilizzare l'endpoint
/metrics
di cAdvisor che fornisce l'insieme completo di metriche del container Prometheus.
Alternative
- Esegui la migrazione della tua soluzione di monitoraggio a Cloud Monitoring, che fornisce il set completo di metriche dei container.
- Raccogli le metriche dall'API Kubelet summary con un endpoint
/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
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, a causa del fatto che le operazioni di collegamento ai container in esecuzione esistenti non riescono a associare di nuovo l'IO. Il problema non causerà errori nelle chiamate API, ma i dati non verranno inviati o ricevuti. Ciò include i dati per il collegamento e il 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 container con patch (1.5.7-gke.1) con release di 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 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 ulteriori informazioni sul problema, consulta le pagine GitHub issue #5438 containerd e GitHub issue #5768.
Esiste un problema noto in GKE Dataplane V2 che può attivare questo problema. Tuttavia, questo problema può essere provocato da altre cause, tra cui runc bloccato.
Soluzione
Per risolvere il problema, segui le soluzioni alternative menzionate in Soluzioni per 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 delle immagini dockershim
. Quando il probe exec, definito per il pod, supera la soglia dichiarata per Kubernetes timeoutSeconds
, nelle immagini dockershim
viene considerato un errore del probe.
Nelle immagini containerizzate, 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 di 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 per le configurazioni private dei registri 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 del registry privato specifico. Puoi verificare la presenza di questo errore in Cloud Logging utilizzando la seguente query:
Vai alla pagina Esplora log nella console Google Cloud:
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:
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.Verifica che il file di configurazione contenga il nome di dominio completo corretto.
Verifica che il percorso del certificato nel campo
secretURI
del file di configurazione sia corretto.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 i container sui tuoi nodi.
Per risolvere il problema, prova a procedere nel seguente modo:
- Assicurati che il nodo interessato esegua Container-Optimized OS. I nodi Ubuntu e Windows non sono supportati.
- Nel file di configurazione, assicurati che il percorso del secret nel campo
secretURI
sia corretto. - Verifica che l'account di servizio IAM del cluster disponga delle autorizzazioni corrette per accedere al secret.
- Verifica che il cluster abbia l'ambito di accesso
cloud-platform
. Per le 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 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:
- Utilizzare Artifact Registry
- Configura TLS nei tuoi registri privati se il tuo caso d'uso supporta questa opzione. Puoi utilizzare un file di configurazione containerizzato per indicare a GKE di utilizzare i certificati archiviati in Secret Manager per accedere al tuo registro privato. Per le istruzioni, consulta Accedere 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 non è disponibile in Autopilot perché i container con privilegi sono 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, ti consigliamo vivamente di configurare TLS per il tuo registro privato e di utilizzare invece l'opzione di Secret Manager.
Esamina il seguente manifest:
Nel campo
.spec.containers.env
, sostituisci il valoreREGISTRY_ADDRESS
della variabileADDRESS
con l'indirizzo del registro HTTP locale nel formatoDOMAIN_NAME:PORT
. Ad esempio,containers: - name: startup-script ... env: - name: ADDRESS value: "example.com:5000"
Esegui il deployment del DaemonSet:
kubectl apply -f insecure-registry-ds.yaml
Il DaemonSet aggiunge il tuo registro non sicuro alla configurazione containerd su 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 tutte le mappature dei dispositivi che volumeDevices.devicePath
passa all'host, rendendo invece disponibile ogni dispositivo sull'host per il container
in /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 eliminare i processi containerd-shim-runc-v2
all'eliminazione di un pod, causando perdite di processo. Quando la perdita si verifica 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 la pagina relativa al problema di GitHub
Correggere lo shim trapelato 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. L'immagine dockershim
disabilita IPv6 su tutti i pod, al contrario dell'immagine containerd. Ad
esempio, localhost
viene prima risolto nell'indirizzo IPv6 ::1
. In genere questo non è un problema, ma in alcuni casi potrebbe comportare comportamenti imprevisti.
Soluzione
Per risolvere il problema, utilizza un indirizzo IPv4 come 127.0.0.1
in modo esplicito o
configura 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
Il provisioning automatico dei nodi consente di scalare automaticamente i pool di nodi con qualsiasi tipo di immagine supportato, ma può creare nuovi pool di nodi solo 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 GKE è possibile impostare il tipo di immagine predefinito per il cluster.
Conflitto con 172.17/16
intervallo di indirizzi IP
Versioni 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 che invia o proviene da questo intervallo potrebbe non essere instradato correttamente (ad esempio, un pod potrebbe non essere in grado di connettersi 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 vengono raccolte quando si utilizza containerd come runtime nelle versioni di GKE precedenti alla 1.18.18.
Soluzione
Per risolvere il 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 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 la pagina relativa al 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 fornire
compatibilità con le versioni precedenti, mentre nei container 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 file manifest, controlla config.mediaType
per capire se si
sta verificando questo problema:
"mediaType": "application/octet-stream",
Soluzione
Poiché la community containerd ha deciso di non supportare queste immagini, tutte
le versioni di containerd sono interessate e non c'è soluzione. L'immagine container
deve essere ricreata con Docker versione 1.11 o 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, un ridimensionamento o 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 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 presenta errori. Questo impedisce a GKE di creare un pod
netd
ocalico-node
. Se i podnetd
ocalico-node
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 i webhook per ignorare i pod di sistema.