As we mentioned before, GKE is based on Kubernetes itself. We will briefly explain the core Kubernetes components and how they relate to GKE.
Because this book is aimed toward helping you ace the Associate Cloud Engineer (ACE) exam, we won’t explain how to build a CI/CD pipeline and deploy it to GKE. If you wish to learn about Kubernetes in much more detail, there are many fantastic books on the market.
The central concept of Kubernetes is a cluster. As Kubernetes consists of multiple components, a diagram of Kubernetes architecture will allow us to understand its components and dependencies:
Figure 5.2 – Kubernetes architecture
A cluster consists of a few elements, as outlined here:
- Nodes—Worker machines where we deploy containerized applications. A node has multiple components that interact with each other, as follows:
- kubelet—This is an agent that runs on each node and makes sure that containers are running in a Pod.
- kube-proxy—This is a network proxy that runs on each node in the cluster. It maintains network rules on nodes that allow network communication to Pods.
- Container runtime—Kubernetes supports multiple runtimes such as containers, CRI-O, or any other Kubernetes Container Runtime Interface (CRI).
- Pods—Pods are hosted on worker nodes. They are the smallest deployable units of computing that can be created and managed in Kubernetes. A Pod can be a single container or a group of containers with shared storage and network resources. The control plane has multiple components that interact with each other, as follows:
- kube-apiserver—This is an API server that is the frontend for the Kubernetes control plane.
- etcd—A highly available, strongly consistent, distributed key-value store where all configuration, data, or state is stored.
- kube-scheduler—This is a component used to schedule containers to run on a node.
- kube-controller-manager—This is a control plane component that runs controller processes. It has several controllers included: a node controller (responsible for node unavailability), job controller (creates Pods), endpoint controller (populates endpoint objects), service account and token controllers (create default accounts and API access tokens for new namespaces).
- cloud-controller-manager—The cloud controller manager component allows us to link clusters into the cloud provider API and separate the components that interact with the cloud platform from those that only interact with your cluster. On-premises Kubernetes doesn’t have this component.
To learn more about the Kubernetes concepts, please visit the following URL: https://kubernetes.io/docs/concepts/overview/components/.
Google Kubernetes components are based on Kubernetes, but Google Cloud fully manages the control plane for us. Essentially, GKE consumers must deploy applications and configure GKE according to their needs.
GKE offers several storage options for containerized applications running on GKE. On-disk files in containers are the simplest place for an application to write data, but it doesn’t solve the main problem. When the container stops or crashes, the files and data are lost. Besides that, some applications might require shared storage or even need to access the data from different containers running in the same Pod.
Kubernetes abstract block-based storage to Pods by introducing volumes, persistent volumes (PVs), and storage classes.
Before we dive into different storage components, we need to understand dependencies and how they construct GKE storage:
Figure 5.3 – Kubernetes storage architecture
On the right side of the diagram, we have persistent disks, which we know from Google Compute Engine (GCE), and they are used as block storage for instances. Filestore, a managed Google Cloud Network File System (NFS) service, can be used as well as a storage option in GKE.