This page shows you how to customize a node boot disk in yourGoogle Kubernetes Engine (GKE)clusters andnode pools.

Overview

When you create a GKE cluster or node pool, you can choosethe type of Persistent Disk onto which the Kubernetes node file system isinstalled for each node. By default, GKE uses balancedPersistent Disks in version 1.24 or later. You can also specify otherPersistent Disk types, such as standard or SSD. For more information, seeStorage options.

Balanced and SSD Persistent Disks have disk quotas which are differentfrom standard Persistent Disk quotas. If you are switching from standard tobalanced Persistent Disks, you may need to request for quota increases. Formore information, seeResource quotas.

Benefits of using an SSD boot disk

Using an SSD Persistent Disk as a boot disk for your nodes offers someperformance benefits:

• Nodes have faster boot times.
• Binaries and files served from containers are available to the node faster.This can increase performance for I/O-intensiveworkloads, such asweb-serving applications that host static files or short-running,I/O-intensivebatch jobs.
• Files stored on the node's local media (exposed throughhostPath oremptyDirvolumes) can see improved I/O performance.

Specifying a node boot disk type

You can specify the boot disk type when you create a cluster or node pool.

gcloud container clusters create[CLUSTER_NAME] --disk-type[DISK_TYPE]

gcloud container node-pools create[POOL_NAME] --disk-type[DISK_TYPE]

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

Protecting node boot disks

A node boot disk stores your container image, some system process logs, Podlogs, and the writable container layer by default.

If your workloads useconfigMap,emptyDir, orhostPath volumes, your Podscould write additional data to node boot disks. You can configureemptyDir tobe backed by tmpfs to stop this. To learn how, see theKubernetes documentation.Sincesecret,downwardAPI, andprojected volumes are backed bytmpfs the Pods using them don't write data to the node boot disk.

By default, Google Cloudencrypts customer content at restincluding your node boot disks, and GKE manages encryption foryou without any action on your part.

However, when using volumes that write to the node boot disk, you may want tofurther control how your workload data is protected in GKE. Youcan do this by eitherpreventing Pods from writing to node boot disks, orusing Customer Managed Encryption Keys (CMEK) for node boot disks.

Prevent Pods from writing to boot disks

To prevent Pods from writing data directly to the node boot disk, use one of thefollowing methods.

Policy Controller

Policy Controller is a feature of GKE Enterprise that lets you declare andenforce custom policies at scale across your GKE clusters infleets.

1. Install Policy Controller.
2. Define a constraint that restricts the following volume types by using thek8sPspVolumeTypes constraint template:
   • configMap
   • emptyDir (if not backed by tmpfs)
   • hostPathFor instructions, seeUse the constraint template libraryin the Policy Controller documentation.

The following example constraint restricts these volume types in all Pods in thecluster:

apiVersion:constraints.gatekeeper.sh/v1beta1kind:K8sPSPVolumeTypesmetadata:name:deny-boot-disk-writesspec:match:kinds:-apiGroups:[""]kinds:["Pod"]parameters:volumes:-configMap-emptyDir-hostPath

PodSecurity admission controller

The built-in Kubernetes PodSecurity admission controller lets you enforcedifferent levels of the Pod Security Standards in specific namespaces or in thecluster. The Restricted policy prevents Pods from writing to the node boot disk.

To use the PodSecurity admission controller, seeApply predefined Pod-level security policies using PodSecurity.

Customer-managed encryption

If you want to control and manage encryption key rotation yourself, you can useCustomer Managed Encryption Keys (CMEK). These keys are used to encrypt the dataencryption keys that encrypt your data. To learn how to use CMEK for node bootdisks, seeUsing customer-managedencryption keys.

A limitation of CMEK for node boot disks is that it cannot be changed afternode pool creation. This means:

• If the node pool was created with customer-managed encryption, you cannotsubsequently disable encryption on the boot disks.
• If the node pool was created without customer-managed encryption, you cannotsubsequently enable encryption on the boot disks. However, you can create a newnode pool with customer-managed encryption enabled and delete the previous node pool.

Limitations

Before configuring a custom boot disk, consider the following limitations:

• TheC3,G2, andG4 machine seriesdon't support thepd-standard node boot disk type.

What's next

• Learn how to specify a minimum CPU platform.
• Learn more about customer managed encryption.
• Learn about using Customer Managed Encryption keys in GKE.