Create a kubernetes cluster using Disks is not allowed in GCP
System Design practice on Codemia
Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.
Introduction
Google Cloud Platform (GCP) offers a powerful, scalable infrastructure for deploying and managing Kubernetes clusters. However, certain configurations are either not supported or may lead to suboptimal performance. One such misconfiguration is attempting to create a Kubernetes cluster using GCP Compute Disks directly for node storage. This article will explain why this approach is not recommended, the underlying technical reasons, and alternative best practices for setting up Kubernetes clusters on GCP.
Understanding Kubernetes and Storage
Kubernetes Storage Options
Kubernetes provides various storage options to meet different use-cases:
- Persistent Volumes (PV): These are storage resources in a cluster. PVs have a lifecycle independent of any individual Pod that uses them.
- Persistent Volume Claims (PVC): A request for storage by a user, allowing dynamic provisioning of PV.
- Container Storage Interface (CSI): An open API standard allowing Kubernetes to expose arbitrary storage systems to containers.
Google Cloud Storage Services
GCP provides several options for Kubernetes storage:
- Google Persistent Disks: Block storage that can be used with GKE for your stateful applications.
- Filestore: Managed file storage for applications that require a shared file system.
- Cloud Storage: An object storage service offering scalable storage for static resources.
Why Direct Use of Disks in a Cluster is Not Recommended
Architectural Considerations
- Complexity of Management: Using individual persistent disks as part of a Kubernetes cluster adds an unnecessary layer of complexity. Kubernetes is designed to manage stateless pods where persistence is handled through PVs, abstracting the disk management complexity away from developers.
- Resource Constraints: Direct manipulation and management of disks require resource allocation that may conflict with automated scaling and resource management features offered by Kubernetes.
Technical Limitations
- Disjoint Lifecycle: A compute disk's lifecycle tied directly with a Kubernetes node may lead to data retention issues upon node termination. Google Kubernetes Engine (GKE) manages node scaling and replacement automatically, potentially causing detached or mismanaged disks.
- Lack of Stateful Sets Optimization: Kubernetes offers StatefulSets for managing stateful workloads, which rely on persistent volumes rather than raw disks to manage state across the dynamic environment of Kubernetes pods.
Performance Issues
Direct disk management could also lead to performance bottlenecks or inefficiencies, as Kubernetes and GCP have optimized interfaces for managing storage (e.g., CSI drivers).
Recommended Practices
Use of Kubernetes Abstractions
For any Kubernetes deployment on GCP:
- Persistent Volumes: Utilize Persistent Volumes and Persistent Volume Claims to dynamically provision and manage storage. This encapsulates the disk management and integrates with Kubernetes scheduling tightly.
- ReadWriteOnce
Related reading
- Create a patch to add a kubernetes annotation
- Create fake data for rest mapper running in Kubernetes
- Create kubernetes docker-registry secret from yaml file?
- Create kubernetes nginx ingress without GCP load-balancer
- Create a zip file on S3 from files on S3 using Lambda Node
- Create AWS Athena view programmatically
- Create kubernetes pod with volume using kubectl run
- Create multiple targets using external secret operator AWS

System Design Fundamentals
Build a strong foundation in designing scalable, reliable distributed systems.
View the courseTrack what you have practised
A free account saves your progress, solutions and study plan across every problem on Codemia.
System Design practice on Codemia
Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.