Questa pagina mostra come personalizzare un disco di avvio del nodo nei tuoi cluster e node pool di Google Kubernetes Engine (GKE).
Panoramica
Quando crei un cluster GKE o un pool di nodi, puoi scegliere il tipo di Persistent Disk su cui è installato il file system del nodo Kubernetes per ogni nodo. Per impostazione predefinita, GKE utilizza Persistent Disk bilanciati nella versione 1.24 o successive. Puoi anche specificare altri tipi di Persistent Disk, come standard o SSD. Per ulteriori informazioni, consulta Opzioni di archiviazione.
I Persistent Disk bilanciati e SSD hanno quote disco diverse dalle quote dei Persistent Disk standard. Se passi da Persistent Disk standard a Persistent Disk bilanciati, potresti dover richiedere aumenti di quota. Per ulteriori informazioni, consulta Quote delle risorse.
Vantaggi dell'utilizzo di un disco di avvio SSD
L'utilizzo di un Persistent Disk SSD come disco di avvio per i nodi offre alcuni vantaggi in termini di prestazioni:
- I nodi hanno tempi di avvio più rapidi.
- I file binari e i file forniti dai container sono disponibili più rapidamente per il nodo. Ciò può aumentare le prestazioni per i carichi di lavoro con uso intensivo di I/O, come le applicazioni di pubblicazione web che ospitano file statici o i job batch con uso intensivo di I/O a breve esecuzione.
- I file archiviati sul supporto locale del nodo (esposti tramite volumi
hostPathoemptyDir) possono vedere un miglioramento delle prestazioni I/O.
Specificare un tipo di disco di avvio del nodo
Puoi specificare il tipo di disco di avvio quando crei un cluster o pool di nodi.
gcloud
Per creare un cluster con un disco di avvio personalizzato, esegui il seguente comando.
[DISK-TYPE] può essere uno dei seguenti valori:
pd-balanced(il valore predefinito nella versione 1.24 o successive)pd-standard(il valore predefinito nella versione 1.23 o precedenti)pd-ssdhyperdisk-balanced
Per ulteriori informazioni, consulta Tipi di Persistent Disk.
gcloud container clusters create [CLUSTER_NAME] --disk-type [DISK_TYPE]
Per creare un pool di nodi in un cluster esistente:
gcloud container node-pools create [POOL_NAME] --disk-type [DISK_TYPE]
Ad esempio, il seguente comando crea un cluster, example-cluster, con il tipo di Persistent Disk SSD, pd-ssd:
gcloud container clusters create example-cluster --disk-type pd-ssd
Console
Per selezionare il disco di avvio durante la creazione del cluster con la Google Cloud console:
Nella Google Cloud console, vai alla pagina Crea un cluster Kubernetes.
Configura il cluster in base alle esigenze.
Nel menu di navigazione, espandi default-pool e fai clic su Nodi.
Nell'elenco a discesa Tipo di disco di avvio, seleziona un tipo di Persistent Disk.
Fai clic su Crea.
Per creare un pool di nodi con un disco di avvio personalizzato per un cluster esistente:
Vai alla pagina Google Kubernetes Engine nella Google Cloud console.
Nell'elenco dei cluster, fai clic sul nome del cluster da modificare.
Fai clic sulla scheda Nodi.
Fai clic su add_box Crea node pool gestito dall'utente.
Configura il pool di nodi in base alle esigenze.
Nel menu di navigazione, fai clic su Nodi.
Nell'elenco a discesa Tipo di disco di avvio, seleziona un tipo di Persistent Disk.
Fai clic su Crea.
Proteggere i dischi di avvio dei nodi
Per impostazione predefinita, un disco di avvio del nodo archivia l'immagine container, alcuni log dei processi di sistema, i log dei pod e il livello del container scrivibile.
Se i tuoi carichi di lavoro utilizzano volumi configMap, emptyDir o hostPath, i pod potrebbero scrivere dati aggiuntivi sui dischi di avvio dei nodi. Puoi configurare emptyDir in modo che sia supportato da tmpfs per impedire questa operazione. Per scoprire come fare, consulta la
documentazione di Kubernetes.
Poiché i volumi secret, downwardAPI e projected sono supportati da tmpfs
i pod che li utilizzano non scrivono dati sul disco di avvio del nodo.
Per impostazione predefinita, Google Cloud cripta i contenuti dei clienti a riposo inclusi i dischi di avvio dei nodi, e GKE gestisce la crittografia per te senza che tu debba eseguire alcuna azione.
Tuttavia, quando utilizzi volumi che scrivono sul disco di avvio del nodo, potresti voler controllare ulteriormente la protezione dei dati del carico di lavoro in GKE. Puoi farlo impedendo ai pod di scrivere sui dischi di avvio dei nodi o utilizzando le chiavi di crittografia gestite dal cliente (CMEK) per i dischi di avvio dei nodi.
Impedire ai pod di scrivere sui dischi di avvio
Per impedire ai pod di scrivere dati direttamente sul disco di avvio del nodo, utilizza uno dei seguenti metodi.
Policy Controller
Policy Controller è una funzionalità di GKE Enterprise che ti consente di dichiarare e applicare policy personalizzate su larga scala nei cluster GKE nelle fleet.
- Installa Policy Controller.
- Definisci un vincolo che limiti i seguenti tipi di volumi utilizzando il
k8sPspVolumeTypesmodello di vincolo:configMapemptyDir(se non supportato da tmpfs)hostPathPer le istruzioni, consulta Utilizzare la libreria dei modelli di vincolo nella documentazione di Policy Controller.
Il seguente vincolo di esempio limita questi tipi di volumi in tutti i pod del cluster:
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sPSPVolumeTypes
metadata:
name: deny-boot-disk-writes
spec:
match:
kinds:
- apiGroups: [""]
kinds: ["Pod"]
parameters:
volumes:
- configMap
- emptyDir
- hostPath
Controller di ammissione PodSecurity
Il controller di ammissione PodSecurity Kubernetes integrato ti consente di applicare diversi livelli degli standard di sicurezza dei pod in spazi dei nomi specifici o nel cluster. La policy Restricted impedisce ai pod di scrivere sul disco di avvio del nodo.
Per utilizzare il controller di ammissione PodSecurity, consulta Applicare policy di sicurezza predefinite a livello di pod utilizzando PodSecurity.
Crittografia gestita dal cliente
Se vuoi controllare e gestire autonomamente rotazione della chiave di crittografia, puoi utilizzare le chiavi di crittografia gestite dal cliente (CMEK). Queste chiavi vengono utilizzate per criptare le chiavi di crittografia dei dati che criptano i tuoi dati. Per scoprire come utilizzare CMEK per i dischi di avvio dei nodi, consulta Utilizzo delle chiavi di crittografia gestite dal cliente.
Una limitazione di CMEK per i dischi di avvio dei nodi è che non può essere modificata dopo la creazione pool di nodi. Ciò significa che:
- Se il pool di nodi è stato creato con la crittografia gestita dal cliente, non puoi disabilitare la crittografia sui dischi di avvio in un secondo momento.
- Se il pool di nodi è stato creato senza la crittografia gestita dal cliente, non puoi abilitare la crittografia sui dischi di avvio in un secondo momento. Tuttavia, puoi creare un nuovo pool di nodi con la crittografia gestita dal cliente abilitata ed eliminare il pool di nodi precedente.
Limitazioni
Prima di configurare un disco di avvio personalizzato, tieni presente le seguenti limitazioni:
Passaggi successivi
- Scopri come specificare una piattaforma CPU minima.
- Scopri di più sulla crittografia gestita dal cliente.
- Scopri come utilizzare le chiavi di crittografia gestite dal cliente in GKE.