Google Kubernetes Engine, or GKE, is a managed Kubernetes service that lets you run, manage, and scale containerized applications on Google Cloud infrastructure. Kubernetes itself, often written K8s, is an open-source platform that automates the deployment, scaling, and operation of containerized applications. It was originally developed inside Google to manage workloads running in containers at very large scale, and it has since become widely adopted across the industry. For the Professional Cloud Database Engineer exam, the relevant question is usually not how Kubernetes works in detail, but when running a database on GKE is the right choice and when a managed database service is the better fit.
Containers are lightweight, portable units that package an application together with its dependencies, so it runs consistently across a developer laptop, a testing environment, and production in the cloud. Kubernetes coordinates those containers across a group of machines. A cluster is a collection of nodes, where a node is a worker virtual machine that provides CPU, memory, and storage. Each node can run multiple pods, and a pod is the smallest deployable unit in Kubernetes. A pod holds one or more tightly coupled containers that share the same network and storage. When you run several identical pods, those copies are called replicas.
Kubernetes was designed to solve three recurring problems. The first is manual scaling, which it addresses through automated scaling using the Horizontal Pod Autoscaler and the Cluster Autoscaler. The second is unreliable deployments, which it addresses through declarative configuration, rolling updates, and self-healing. If a node fails, Kubernetes reschedules its pods onto healthy nodes to keep the service available. The third is lack of portability, which containerization addresses by giving applications a consistent runtime that can move between on-premises, cloud, and hybrid environments.
GKE adds a managed layer on top of all of this. It uses open-source Kubernetes, so workloads stay compatible with other platforms and remain portable across providers. It simplifies scaling, updates, and routine maintenance with minimal downtime. It integrates with the rest of Google Cloud, including Cloud Monitoring, Cloud Logging, and Identity and Access Management. And it is well suited to complex microservice architectures, where many independent services need to be deployed, scaled, and managed together.
The features that make Kubernetes attractive are aimed at applications that can be scaled and rescheduled freely. A database is a stateful workload, which means its value lives in the data it stores rather than in any single running process. Kubernetes can reschedule a pod onto another node when something fails, and for a stateless web service that is exactly what you want. For a database, the persistent data has to follow the workload and stay consistent, and the failover behavior has to be deliberate rather than incidental. Running a database in containers is possible, but it puts the responsibility for storage, backups, replication, patching, and failover on the team operating the cluster.
This is the core tension the Professional Cloud Database Engineer exam wants you to recognize. Google Cloud offers managed database services such as Cloud SQL, AlloyDB, Spanner, Bigtable, Firestore, and Memorystore, and each of these handles the operational work that you would otherwise carry yourself. They provide automated backups, managed replication, patching, and built-in high availability. When a scenario describes a team that wants a relational or NoSQL database without taking on database administration, the managed service is almost always the intended answer, not a self-managed database on GKE.
There are still situations where GKE is a reasonable home for a database. The clearest one is portability. Because GKE runs open-source Kubernetes, a database deployed there can move across multi-cloud and hybrid environments more readily than one tied to a specific managed service. If an organization has standardized on Kubernetes and wants the same operational model everywhere, keeping the database in the cluster can be consistent with that goal. Another case is a database engine that has no managed equivalent on Google Cloud, where running it yourself in containers may be the only way to get that specific technology.
When you do run a database on GKE, the work that a managed service would have absorbed becomes yours. You are responsible for provisioning durable storage that survives pod rescheduling, for configuring replication and failover, for taking and testing backups, and for applying updates to both the database and the underlying nodes. GKE will reschedule pods and keep the cluster healthy, but it does not make those data-level decisions for you. We would generally lean toward a managed database service unless there is a specific portability requirement or an engine that only exists outside the managed catalog.
Treat the choice as a tradeoff between control and operational burden. GKE gives you maximum flexibility and portability and asks you to run the database yourself. A managed service gives up some flexibility and hands the operational work to Google Cloud. On the Professional Cloud Database Engineer exam, default to the managed service when the requirements center on reliability, backups, high availability, and reduced administration, and reserve GKE for the cases where portability across environments or a specific unsupported engine is the stated driver. Read the scenario for who is expected to operate the database, because that usually points directly at the answer.
Our Professional Cloud Database Engineer course covers running databases on GKE alongside Cloud SQL high availability and choosing between managed database services, with practice questions that drill these distinctions.
