Configurazione di un disco di avvio personalizzato

Standard

Questa pagina mostra come personalizzare un disco di avvio del nodo nei cluster e nei pool di nodi 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 viene installato il file system del nodo Kubernetes per ogni nodo. Per impostazione predefinita, GKE utilizza dischi permanenti bilanciati nella versione 1.24 o successive. Puoi anche specificare altri tipi di Persistent Disk, ad esempio standard o SSD. Per saperne di più, vedi Opzioni di archiviazione.

Nota :questa funzionalità è diversa dall'SSD locale, che non può essere utilizzato come disco di avvio.

I dischi permanenti bilanciati e SSD hanno quote del disco diverse da quelle deiPersistent Diski standard. Se passi dai dischi permanenti standard ai Balanced Persistent Disk, potresti dover richiedere aumenti della quota. Per saperne di più, consulta Quote delle risorse.

Vantaggi dell'utilizzo di un disco di avvio SSD

L'utilizzo di un disco permanente SSD come disco di avvio per i nodi offre alcuni vantaggi in termini di prestazioni:

• I nodi hanno tempi di Avvio rapido 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 I/O intensivo, ad esempio le applicazioni di web serving che ospitano file statici o job batch con I/O intensivo e di breve durata.
• I file archiviati sui media locali del nodo (esposti tramite volumi hostPath o emptyDir) possono registrare un miglioramento delle prestazioni di I/O.

Specifica di 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 questo comando.

[DISK-TYPE] può essere uno dei seguenti valori:

• pd-balanced (impostazione predefinita nella versione 1.24 o successive)
• pd-standard (impostazione predefinita nella versione 1.23 o precedente)
• pd-ssd
• hyperdisk-balanced

Nota: i tipi di dischi disponibili dipendono dalla serie di macchine dei nodi. Ad esempio, la serie di macchine N4 supporta solo hyperdisk-balanced come disco di avvio. Per informazioni aggiornate sulla compatibilità di tipo di macchina e dischi, consulta la documentazione sul supporto dei tipi di macchina.

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 disco permanente SSD, pd-ssd:

gcloud container clusters create example-cluster --disk-type pd-ssd

Console

Per selezionare il disco di avvio quando crei il cluster con la console Google Cloud :

1. Nella console Google Cloud , vai alla pagina Crea un cluster Kubernetes.

   Vai a Crea un cluster Kubernetes

2. Configura il cluster in base alle esigenze.

3. Nel menu di navigazione, espandi default-pool e fai clic su Nodi.

4. Nell'elenco a discesa Tipo di disco di avvio, seleziona un tipo di Persistent Disk.

5. Fai clic su Crea.

Per creare un pool di nodi con un disco di avvio personalizzato per un cluster esistente:

1. Vai alla pagina Google Kubernetes Engine nella console Google Cloud .

   Vai a Google Kubernetes Engine

2. Nell'elenco dei cluster, fai clic sul nome del cluster da modificare.

3. Fai clic sulla scheda Nodi.

4. Fai clic su Crea node pool gestito dall'utente.

5. Configura il pool di nodi in base alle esigenze.

6. Nel menu di navigazione, fai clic su Nodi.

7. Nell'elenco a discesa Tipo di disco di avvio, seleziona un tipo di Persistent Disk.

8. Fai clic su Crea.

Protezione dei 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 container scrivibile.

Se i tuoi carichi di lavoro utilizzano volumi configMap, emptyDir o hostPath, i tuoi pod potrebbero scrivere dati aggiuntivi sui dischi di avvio dei nodi. Per evitare che ciò accada, puoi configurare emptyDir in modo che sia supportato da tmpfs. 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 inattivi dei clienti, inclusi i dischi di avvio dei nodi, e GKE gestisce la crittografia per te senza che tu debba fare nulla.

Tuttavia, quando utilizzi volumi che scrivono sul disco di avvio del nodo, potresti voler controllare ulteriormente il modo in cui i dati del workload sono protetti 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.

Impedisci 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 consente di dichiarare e applicare criteri personalizzati su larga scala nei cluster GKE nei parchi risorse.

1. Installa Policy Controller.
2. Definisci un vincolo che limita i seguenti tipi di volume utilizzando il template di vincolo k8sPspVolumeTypes:
   • configMap
   • emptyDir (se non supportato da tmpfs)
   • hostPath Per istruzioni, consulta Utilizza 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. Il criterio Restricted impedisce ai pod di scrivere sul disco di avvio del nodo.

Per utilizzare il controller di ammissione PodSecurity, consulta Applicare criteri di sicurezza predefiniti a livello di pod utilizzando PodSecurity.

Crittografia gestita dal cliente

Se vuoi controllare e gestire personalmente 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 del pool di nodi. Ciò significa che:

• Se il pool di nodi è stato creato con la crittografia gestita dal cliente, non puoi disattivare successivamente la crittografia sui dischi di avvio.
• Se il pool di nodi è stato creato senza crittografia gestita dal cliente, non puoi abilitare successivamente la crittografia sui dischi di avvio. Tuttavia, puoi creare un nuovo pool di nodil con la crittografia gestita dal cliente abilitata ed eliminare ilpool di nodil precedente.

Limitazioni

Prima di configurare un disco di avvio personalizzato, tieni presente le seguenti limitazioni:

• Le serie di macchine C3, G2 e G4 non supportano il tipo di disco di avvio del nodo pd-standard.

Passaggi successivi

• Scopri come specificare una piattaforma CPU minima.
• Scopri di più sulla crittografia gestita dal cliente.
• Scopri di più sull'utilizzo delle chiavi di crittografia gestite dal cliente in GKE.