Immagini dei nodi

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

I nodi GKE Autopilot utilizzano sempre Container-Optimized OS con containerd (cos_containerd), che è il sistema operativo dei nodi consigliato. Se utilizzi GKE Standard, puoi scegliere l'immagine del sistema operativo eseguita su ogni 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 nodo diversa. Per istruzioni su come impostare l'immagine del nodo, consulta Specifica di un'immagine del nodo.

Immagini nodo disponibili

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

Sistema operativo Immagini dei nodi
Container-Optimized OS
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 sistema operativo Container-Optimized OS sono supportate da un team di Google che può applicare rapidamente patch alle immagini per la sicurezza e l'iterazione delle funzionalità. Le immagini sistema operativo Container-Optimized OS offrono un'assistenza, una sicurezza e una stabilità migliori rispetto ad altre immagini.

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

Varianti di Container-Optimized OS

Puoi utilizzare la seguente immagine sistema operativo di Container-Optimized OS:

  • 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 utilizzano sempre questa immagine. Per saperne di più, consulta Immagini dei nodi containerd.

Ubuntu

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

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

Varianti di Ubuntu

Puoi utilizzare la seguente immagine Ubuntu:

  • Ubuntu con containerd (ubuntu_containerd): l'immagine ubuntu_containerd utilizza containerd come runtime del container. Per saperne di più, consulta Immagini dei nodi containerd.

Windows Server

Quando crei un cluster utilizzando i node pool Windows Server, puoi utilizzare un'immagine del nodo Windows Server Long-Term Servicing Channel (LTSC). Questa immagine del nodo Windows è un'immagine Windows Server Datacenter Core. Un singolo cluster può avere più pool di nodi Windows Server che utilizzano versioni diverse di Windows Server, ma ogni singolo pool di nodi può utilizzare una sola versione di Windows Server. Per saperne di più, consulta Scegli l'immagine del nodo Windows.

Puoi utilizzare la seguente immagine Windows Server:

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

Per ulteriori informazioni sulla creazione di node pool Windows Server 2022, consulta Crea node pool Windows

Per saperne di più sulle immagini dei nodi containerd, consulta Immagini dei nodi containerd.

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

Confronto delle immagini dei nodi Linux

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

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

Gestore di pacchetti software

Le immagini dei nodi cos e cos_containerd utilizzano un file system root minimo con supporto integrato per il runtime dei container Docker (containerd), che funge anche da gestore di pacchetti software per l'installazione del 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 arbitrario sui nodi utilizzando meccanismi convenzionali. Crea invece un'immagine container che contenga il software di cui hai bisogno.

Sui cluster Standard, solo per scopi di debug, Container-Optimized OS include CoreOS Toolbox 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 utilizzare il comando apt-get per installare i 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 Ubuntu che quella di Container-Optimized OS utilizzano systemd per gestire le risorse e i servizi di sistema durante il processo di inizializzazione del sistema.

Entrambe le immagini dei nodi utilizzano file di servizio systemd per definire services sul nodo e systemd.targets per raggruppare i target di avvio tramite le dipendenze.

Raccolta di log

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

Visualizzazione dei log su Container-Optimized OS e Ubuntu

Per visualizzare i log su un nodo con l'immagine 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 del kubelet:

sudo journalctl -u kubelet

Layout del file system

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

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

  • Partizione root, montata in modalità di sola lettura
  • Partizioni stateful, che sono scrivibili e stateful
  • Partizioni stateless, che sono scrivibili, ma i contenuti non vengono conservati dopo i riavvii

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

Utilizzo del file system di Container-Optimized OS

Di seguito è riportato un elenco di percorsi nel file system dell'immagine del nodo di Container-Optimized OS, insieme alle relative proprietà e all'utilizzo consigliato:

Percorso Proprietà Finalità
/
  • sola lettura
  • eseguibile
Il file system principale è montato in modalità di sola lettura per mantenere l'integrità. Il kernel verifica l'integrità del file system radice durante l'avvio e rifiuta l'avvio in caso di errori.
/home
/var
  • scrivibile
  • non eseguibile
  • stateful
Questi percorsi sono destinati alla memorizzazione di dati che persistono per tutta la durata del disco di avvio. Vengono montati da /mnt/stateful_partition.
/var/lib/google
/var/lib/docker
/var/lib/toolbox
  • scrivibile
  • eseguibile
  • stateful
Questi percorsi sono directory di lavoro rispettivamente per i pacchetti Compute Engine (ad esempio, il servizio account manager), Docker e Toolbox.
/var/lib/cloud
  • scrivibile
  • eseguibile
  • stateless
  • tmpfs
Questo percorso è la directory di lavoro del pacchetto cloud-init.
/etc
  • scrivibile
  • eseguibile
  • stateless
  • tmpfs
In genere contiene la configurazione (ad esempio, i servizi systemd definiti tramite cloud-init). È consigliabile acquisire lo stato desiderato delle istanze in cloud-init, poiché cloud-init viene applicato sia quando un'istanza viene creata sia quando viene riavviata.
/tmp
  • scrivibile
  • non eseguibile
  • stateless
  • tmpfs
In genere viene utilizzato come spazio temporaneo e non deve essere utilizzato per archiviare dati permanenti.
/mnt/disks
  • scrivibile
  • eseguibile
  • stateless
  • tmpfs
Puoi montare i dischi permanenti nelle directory in /mnt/disks.

Supporto dei driver di archiviazione

Ogni immagine nodo differisce per i tipi di plug-in di archiviazione che supporta. I seguenti termini 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 limitati: questo plug-in di archiviazione funziona con l'immagine nodo specificata, ma è stato testato solo in modo limitato; potresti riscontrare un comportamento imprevisto. Per Container-Optimized OS, questi plug-in verranno infine testati e supportati completamente.
  • Non supportato: questo plug-in di archiviazione non è stato testato o utilizzato con l'immagine nodo specificata e GKE non può fornire alcuna garanzia di funzionalità. Non sono previsti piani per testare questo plug-in 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 in che modo ogni immagine nodo GKE supporta alcuni plug-in di archiviazione comuni.

Tipo di volume Funziona su Container-Optimized OS (cos)? Funziona su Ubuntu?
Persistent Disk di Compute Engine
(EXT4 o XFS)
Sì - Testato/supportato completamente
(XFS è supportato solo in cos-85 e versioni successive). 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.)
Cinder No No
Fibre Channel No No
Flocker Non supportato Non supportato
iSCSI No No
RBD No No

Sincronizzazione dell'ora

Sia le immagini dei nodi Container-Optimized OS che quelle di Ubuntu utilizzano un server NTP (Network Time Protocol) interno come origine principale dell'ora. Questo server NTP interno è spalmato in modo identico a Google Public NTP.

Se il server NTP interno non è disponibile, le immagini dei nodi Container-Optimized OS e Ubuntu utilizzano l'orologio in tempo reale (RTC), ovvero l'orologio hardware della macchina host, come origine di backup dell'ora.

Generazione di numeri casuali

Sia nei nodi Container-Optimized OS che in quelli Ubuntu, i pod hanno accesso ai file /dev/random e /dev/urandom. Questi file forniscono numeri casuali forniti da Virtio RNG da un pool di entropia generato dall'istanza Compute Engine.

Modifiche alle VM dei nodi

Le modifiche al disco di avvio di una VM nodo non vengono mantenute tra 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 attivi una funzionalità che richiede la ricreazione dei nodi, come GKE Sandbox, visibilità intranodo e nodi schermati.

Per conservare le modifiche durante la nuova creazione dei nodi, utilizza un DaemonSet.

Non è consigliabile gestire software critico fornito da un'immagine nodo, come il kernel o il runtime del container. Le immagini dei nodi vengono testate in modo approfondito e la modifica del software critico fornito nell'immagine del nodo mette il nodo in uno stato sconosciuto e non testabile. I nodi GKE Autopilot non consentono la modifica del software dei nodi.

Mappa le versioni delle immagini dei nodi di Container-Optimized OS alle versioni delle patch di GKE

GKE pubblica una mappatura JSON delle versioni patch di GKE alle versioni delle immagini dei nodi Container-Optimized OS:

Puoi utilizzare questa mappatura per eseguire l'upgrade a una versione specifica di GKE per ottenere una versione immagine specifica. Ad esempio, se il tuo cluster ha bisogno di una determinata funzionalità o correzione da una versione immagine, puoi trovare la mappatura ed eseguire l'upgrade del cluster a una versione GKE specifica per ottenere la versione immagine Container-Optimized OS con le modifiche. Per informazioni dettagliate sulle release delle immagini di Container-Optimized OS, consulta le note di rilascio di Container-Optimized OS.

Questo elenco viene aggiornato circa una volta alla settimana. Per verificare l'aggiornamento delle informazioni, consulta il campo creation_time nel file JSON.

Note di rilascio delle immagini dei nodi

Container-Optimized OS

Google fornisce 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.

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:
    • Per le versioni di GKE precedenti alla 1.36: ubuntu-os-gke-cloud
    • Per GKE versione 1.36 e successive: gke-ubuntu-node-images
  • 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 GKE:

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

Potresti dover conoscere i nomi dei progetti di origine durante la configurazione di cluster ad alta sicurezza. I progetti di origine elencati sono soggetti a modifiche.

Passaggi successivi