Immagini dei nodi


Questa pagina descrive le immagini dei nodi disponibili per i nodi di Google Kubernetes Engine (GKE).

I nodi GKE Autopilot utilizzano sempre Container-Optimized OSr con containerd (cos_containerd), ovvero il sistema operativo dei nodi consigliato. Se utilizzi GKE Standard, puoi scegliere l'immagine del sistema operativo da eseguire su ciascun nodo durante la creazione del cluster o del pool di nodi. Puoi anche eseguire l'upgrade di un cluster Standard esistente per utilizzare un'immagine dei nodi diversa. Per istruzioni su come impostare l'immagine del nodo, consulta Specifica di un'immagine del nodo.

Immagini dei nodi disponibili

GKE offre le seguenti opzioni di immagini dei nodi per sistema operativo per il tuo cluster:

Sistema operativo Immagini dei nodi
Sistema operativo ottimizzato per i container
Ubuntu
Windows Server

Container-Optimized OS

Le immagini dei nodi Container-Optimized OS di Google sono basate su una versione recente del kernel Linux e sono ottimizzate per migliorare la sicurezza dei nodi. Le immagini di Container-Optimized OS sono supportate da un team di Google in grado di applicare rapidamente patch alle immagini per la sicurezza e l'iterazione delle funzionalità. Le immagini di Container-Optimized OS offrono supporto, sicurezza e stabilità migliori rispetto alle altre.

Per informazioni sul progetto e sulla famiglia delle immagini, consulta Progetti di origine delle immagini dei nodi.

Varianti Container-Optimized OS

Con Container-Optimized OS vengono offerti due runtime dei container. Le immagini sono le stesse, ad eccezione della scelta del runtime del container.

  • Container-Optimized OS con containerd (cos_containerd): l'immagine cos_containerd utilizza containerd come runtime del container direttamente integrato con Kubernetes. I cluster GKE Autopilot usano sempre questa immagine. Per ulteriori informazioni, consulta Immagini dei nodi containerd.
  • Container-Optimized OS con Docker (cos): l'immagine cos utilizza il runtime del container Docker.

Ubuntu

Le immagini dei nodi Ubuntu sono state convalidate in base ai requisiti delle immagini dei nodi di GKE. Utilizza le immagini dei nodi Ubuntu se i nodi richiedono il supporto per pacchetti XFS, CephFS o Debian.

Per informazioni sul progetto e sulla famiglia delle immagini, vedi Supporto delle funzionalità in base al sistema operativo.

Varianti di Ubuntu

Con Ubuntu vengono offerti due runtime dei container. Le immagini sono le stesse, ad eccezione della scelta del runtime del container.

  • Ubuntu con containerd (ubuntu_containerd): l'immagine ubuntu_containerd utilizza containerd come runtime del container. Per ulteriori informazioni, consulta Immagini dei nodi containerd.

  • Ubuntu con Docker (ubuntu): l'immagine ubuntu utilizza Docker come runtime del container.

Windows Server

Quando crei un cluster utilizzando pool di nodi Windows Server, puoi utilizzare un'immagine del nodo LTSC (Long-Term Servicing Channel) di Windows Server o un canale semestrale di Windows Server. Tutte le immagini dei nodi Windows sono immagini di Windows Server Datacenter Core. Un singolo cluster può avere più pool di nodi Windows Server che utilizzano versioni di Windows Server diverse, ma ogni singolo pool di nodi può utilizzare una sola versione di Windows Server. Per ulteriori informazioni, consulta Scegliere l'immagine del nodo Windows.

Con le immagini dei nodi LTSC e SAC di Windows Server vengono offerti due runtime container: Docker e containerd. Le immagini sono le stesse, ad eccezione della scelta del runtime del container.

  • Immagini di runtime containerd (disponibili in GKE 1.21 e versioni successive):

    • LTSC Windows Server con containerd (windows_ltsc_containerd): l'immagine windows_ltsc_containerd utilizza containerd come runtime del container. Attualmente, questo tipo di immagine è mappato a due immagini dei nodi: Windows Server 2022 e Windows Server 2019. Puoi creare pool di nodi LTSC2022 Windows tramite il comando dell'interfaccia a riga di comando con il flag windows-os-version.

      Per saperne di più sulla creazione di pool di nodi Windows Server 2022, vedi Creare pool di nodi Windows

      Per ulteriori informazioni sulle immagini dei nodi containerd, consulta Immagini dei nodi containerd.

    • SAC di Windows Server con containerd (windows_sac_containerd): l'immagine windows_sac_containerd utilizza containerd come runtime del container.

      Per ulteriori informazioni, consulta Immagini dei nodi containerd.

  • Immagini di runtime Docker (disponibili in GKE 1.16 e versioni successive):

    • LTSC Windows Server con Docker (windows_ltsc): l'immagine windows_ltsc utilizza Docker come runtime del container.
    • SAC di Windows Server con Docker (windows_sac): l'immagine windows_sac utilizza Docker come runtime del container.

Per informazioni sul progetto e sulla famiglia delle immagini, vedi Supporto delle funzionalità in base al sistema operativo.

Confronto delle immagini dei nodi Linux

Le seguenti sezioni confrontano gli aspetti operativi delle immagini dei nodi di Container-Optimized OS e di Ubuntu, tra cui:

  • Gestione dei pacchetti software
  • Inizializzazione del sistema
  • Raccolta di log
  • Layout del file system
  • Assistenza per i driver di archiviazione

Gestore di pacchetti software

Le immagini dei nodi cos e cos_containerd utilizzano un file system radice minimo con supporto integrato per il runtime del container Docker (containerd), che funge anche da gestore di pacchetti software per l'installazione di software sull'host. L'immagine Ubuntu utilizza il gestore di pacchetti APT.

Gestione del software su Container-Optimized OS

L'immagine Container-Optimized OS non fornisce software di gestione dei pacchetti come apt-get. Non puoi installare software arbitrari sui nodi utilizzando meccanismi convenzionali. Crea invece un'immagine container contenente il software di cui hai bisogno.

Sui cluster standard solo a scopo di debug, Container-Optimized OS include gli Strumenti CoreOS per l'installazione e l'esecuzione di strumenti di debug comuni come ping, psmisc o pstree. Per ulteriori informazioni sul debug dei nodi Container-Optimized OS, consulta le guide illustrative di Container-Optimized OS.

Gestione del software su Ubuntu

L'immagine Ubuntu utilizza il gestore di pacchetti APT. Puoi usare il comando apt-get per installare pacchetti su queste immagini. Ad esempio, per installare i pacchetti ceph:

sudo apt-get update
sudo apt-get install ceph

Inizializzazione del sistema

Sia l'immagine del nodo Container-Optimized OS sia l'immagine del nodo Ubuntu utilizzano systemd per gestire le risorse e i servizi di sistema durante il processo di inizializzazione del sistema.

Entrambe le immagini del nodo utilizzano file di servizio systemd per definire services sul nodo e systemd.targets per raggruppare le destinazioni di avvio tramite dipendenze.

Raccolta di log

Le immagini dei nodi Container-Optimized OS e Ubuntu utilizzano systemd-journald per la raccolta dei log a livello di sistema.

Visualizzazione dei log su Container-Optimized OS e Ubuntu

Per visualizzare i log su un nodo con l'immagine del nodo Container-Optimized OS o Ubuntu, devi utilizzare il comando journalctl. Ad esempio, per visualizzare i log del daemon containerd:

sudo journalctl -u containerd

Per visualizzare i log di kubelet:

sudo journalctl -u kubelet

Layout del file system

L'immagine del nodo Ubuntu utilizza il layout standard del file system di Linux.

Il layout del file system dei nodi di Container-Optimized OS è ottimizzato per migliorare la sicurezza dei nodi. Lo spazio su disco di avvio è suddiviso in tre tipi di partizioni:

  • Partizione radice, montata come di sola lettura
  • Partizioni stateful, scrivibili e stateful
  • Partizioni stateless, che sono scrivibili ma i contenuti non vengono mantenuti tra i riavvii

Quando utilizzi Container-Optimized OS, presta attenzione al partizionamento se esegui i tuoi servizi che hanno determinate aspettative sul layout del file system al di fuori dei container.

Utilizzo del file system Container-Optimized OS

Di seguito è riportato un elenco dei percorsi nel file system di immagini dei nodi di Container-Optimized OS, insieme alle relative proprietà e all'utilizzo consigliato:

Percorso Proprietà Finalità
/
  • sola lettura
  • eseguibile
Il file system principale è montato in sola lettura per mantenere l'integrità. Il kernel verifica l'integrità del file system radice di integrità durante l'avvio e si rifiuta di avviarlo in caso di errori.
/home
/var
  • scrivibile
  • non eseguibile
  • stateful
Questi percorsi sono destinati all'archiviazione dei dati persistenti per tutta la durata del disco di avvio. Sono montati da /mnt/stateful_partition.
/var/lib/google
/var/lib/docker
/var/lib/toolbox
  • scrivibile
  • eseguibile
  • stateful
Questi percorsi sono directory di lavoro per i pacchetti di Compute Engine, ad esempio il servizio di gestione degli account, Docker e Toolbox rispettivamente.
/var/lib/cloud
  • scrivibile
  • eseguibile
  • apolide
  • tmpfs
Questo percorso è la directory di lavoro del pacchetto cloud-init.
/etc
  • scrivibile
  • non eseguibile
  • apolide
  • tmpfs
In genere memorizza la configurazione (ad esempio, i servizi systemd definiti tramite cloud-init). È una buona idea acquisire lo stato desiderato delle istanze in cloud-init, in quanto cloud-init viene applicato quando un'istanza viene appena creata e quando viene riavviata.
/tmp
  • scrivibile
  • non eseguibile
  • apolide
  • tmpfs
In genere viene utilizzato come spazio temporaneo e non deve essere utilizzato per archiviare dati permanenti.
/mnt/disks
  • scrivibile
  • eseguibile
  • apolide
  • tmpfs
Puoi montare i dischi permanenti in directory in /mnt/disks.

Assistenza per i driver di archiviazione

Ogni immagine del nodo si differenzia per i tipi di plug-in di archiviazione che supporta. I termini seguenti si applicano quando si descrive il supporto di un'immagine nodo per un determinato driver di archiviazione:

  • Sì - Completamente testato/supportato: questo plug-in di archiviazione è completamente supportato e testato con l'immagine del nodo specificata.
  • Sì - Test limitato: questo plug-in di archiviazione funziona con l'immagine del nodo specificata, ma è stato testato solo in modo limitato; potresti riscontrare comportamenti imprevisti. Per Container-Optimized OS, questi plug-in saranno infine testati e supportati.
  • Non supportato: questo plug-in di archiviazione non è stato testato o utilizzato con l'immagine del nodo specificata e GKE non può fornire alcuna garanzia in merito alla funzionalità. Non è previsto alcun test di questo plug-in per lo spazio di archiviazione.
  • No: questo plug-in di archiviazione non funziona con l'immagine del nodo specificata a causa di una limitazione intrinseca del sistema operativo del nodo o di Google Cloud.

La seguente matrice descrive il modo in cui ogni immagine del nodo GKE supporta alcuni plug-in di archiviazione comuni.

Tipo di volume Funziona su Container-Optimized OS (cos)? Funziona su Ubuntu?
Compute Engine
Disco permanente (EXT4 o XFS)
Sì - Completamente testato/supportato
(XFS è supportato solo a partire da cos-85) Consulta le note di rilascio di GKE
Sì – Completamente testato/supportato
NFSv3 Sì – Completamente testato/supportato Sì – Completamente testato/supportato
NFSv4 Sì – Completamente testato/supportato Sì – Completamente testato/supportato
CephFS No Sì - Test limitati
(il driver non è installato per impostazione predefinita Devi installare il client ceph, preferibilmente tramite DaemonSet.
Celeste No No
Canale in fibra ottica No No
Fissatore Non supportato Non supportato
iSCSI No No
RBD No No

Modifiche alle VM dei nodi

Le modifiche al disco di avvio di una VM nodo non vengono mantenute durante le ricreazioni dei nodi. I nodi vengono ricreati durante l'upgrade manuale, l'upgrade automatico, la riparazione automatica e la scalabilità automatica. Inoltre, i nodi vengono ricreati quando abiliti una funzionalità che ne richiede la creazione, ad esempio GKE Sandbox, visibilità delle integrità e nodi schermati.

Per mantenere le modifiche durante la ricreazione dei nodi, utilizza un DaemonSet.

Non è consigliabile gestire il software critico fornito da un'immagine del nodo, ad esempio il runtime del kernel o del container (containerd o docker). Le immagini dei nodi vengono testate a fondo e, modificando il software critico fornito nell'immagine del nodo, il nodo viene messo in uno stato sconosciuto e non verificabile. I nodi GKE Autopilot non consentono la modifica del software dei nodi.

Note di rilascio delle immagini dei nodi

Container-Optimized OS

Google offre una documentazione completa per Container-Optimized OS:

Ubuntu

Periodicamente, Google aggiorna le immagini Ubuntu disponibili per l'utilizzo sui nodi del cluster. Consulta le note di rilascio di GKE per informazioni su questi aggiornamenti, incluso un link a un manifest che elenca i pacchetti installati per impostazione predefinita.

Problemi noti

La connessione casuale viene reimpostata sui nodi GKE utilizzando Container-Optimized OS con runtime Docker

Il nodo GKE che utilizza Container-Optimized OS con Docker (cos) potrebbe subire ripristini casuali della connessione TCP quando due pod sullo stesso nodo comunicano utilizzando un servizio ClusterIP di Kubernetes.

Sono interessate le seguenti versioni di GKE:

  • 1.20.5-gke.100 o versioni successive

Per risolvere il problema, utilizza una delle seguenti opzioni:

Progetti di origine delle immagini dei nodi

Le immagini dei nodi disponibili per i cluster GKE sono contenute nei seguenti progetti di origine:

  • Immagini Container-Optimized OS: gke-node-images
  • Immagini Ubuntu: ubuntu-os-gke-cloud
  • Immagini Windows Server: gke-windows-node-images

Oltre ai progetti di origine elencati sopra, GKE utilizza anche i seguenti progetti di origine per l'utilizzo esclusivo da parte del team di GKE:

  • ubuntu-os-gke-cloud-private (riservato all'utilizzo esclusivo del team di GKE)
  • ubuntu-os-gke-cloud-devel (riservato all'utilizzo esclusivo del team di GKE)

Potresti aver bisogno di conoscere i nomi dei progetti di origine durante la configurazione di cluster altamente sicuri. I progetti di origine elencati sono soggetti a modifiche.

Passaggi successivi