Kubernetes Concepts for Non-Technical Leaders

Kubernetes (often abbreviated as K8s) is an open-source platform for automating the deployment, scaling, and management of containerized applications. Containers package an application with its dependencies, making it portable across environments. However, running containers in production at scale introduces challenges: how do you ensure high availability, load balance traffic, roll out updates without downtime, and recover from failures? Kubernetes solves these problems by providing a declarative model where you specify the desired state (e.g., 'run 3 copies of this app') and Kubernetes continuously works to maintain that state.

A Kubernetes cluster consists of two main planes: the control plane (master) and the compute plane (nodes). The control plane makes global decisions about the cluster (e.g., scheduling, responding to events) and exposes the API. It includes several components: - kube-apiserver: The front-end for the Kubernetes API. All communication, internal and external, goes through the API server. It validates and processes RESTful requests. - etcd: A consistent and highly-available key-value store used as Kubernetes' backing store for all cluster data. Only the API server talks to etcd directly. - kube-scheduler: Watches for newly created pods with no assigned node and selects a node for them to run on based on resource requirements, constraints, and policies. - kube-controller-manager: Runs controller processes that handle routine tasks such as replication (ensuring the correct number of pod replicas), node management (detecting node failures), and endpoint management.

Nodes are the worker machines (VMs or physical servers) that run your applications. Each node contains: - kubelet: An agent that ensures containers are running in a pod as expected. It communicates with the API server to receive pod specifications and reports back node and pod status. - kube-proxy: A network proxy that maintains network rules on nodes, enabling communication to pods from inside or outside the cluster. - Container runtime: The software that runs containers (e.g., Docker, containerd).

A pod is the smallest and simplest unit in the Kubernetes object model. It represents a single instance of a running process in the cluster. A pod can contain one or more containers that are tightly coupled and share the same network namespace (IP address and port space), storage volumes, and lifecycle. In practice, most pods run a single container. Pods are ephemeral: they are created, assigned to a node, run until termination or failure, and are not automatically restarted unless managed by a higher-level controller.

Pods are almost never created directly. Instead, you use workload resources that manage pods: - Deployment: The most common resource for stateless applications. It defines a desired state (e.g., 3 replicas of a pod template) and a strategy for updating pods (e.g., rolling update with max surge and max unavailable). Deployments ensure that the actual state matches the desired state, replacing failed or unhealthy pods automatically. - StatefulSet: Used for stateful applications that require stable, unique network identifiers, persistent storage, and ordered deployment/scaling. Examples include databases like MySQL or Cassandra. Each pod in a StatefulSet has a sticky identity (e.g., pod-0, pod-1) and its own persistent volume. - DaemonSet: Ensures that all (or some) nodes run a copy of a pod. Commonly used for cluster-wide services like logging agents (e.g., Fluentd), monitoring agents (e.g., Prometheus node exporter), or network plugins.

Pods are ephemeral and their IP addresses change when they are recreated. Services provide a stable endpoint to access a set of pods. A Service selects pods based on labels and load-balances traffic to them. Types of Services: - ClusterIP (default): Exposes the Service on an internal IP in the cluster. Only reachable within the cluster. - NodePort: Exposes the Service on each Node's IP at a static port (30000-32767). You can access the Service from outside the cluster by requesting <NodeIP>:<NodePort>. - LoadBalancer: Exposes the Service externally using a cloud provider's load balancer. On Google Kubernetes Engine (GKE), this provisions a Google Cloud TCP/UDP load balancer. - ExternalName: Maps a Service to a DNS name (e.g., my-service returns a CNAME record).

Containers are ephemeral—their filesystem disappears when the container restarts. Volumes provide persistent storage that survives container restarts. Kubernetes supports many volume types (e.g., emptyDir, hostPath, cloud-specific like Google Persistent Disk). For stateful workloads, you use PersistentVolumeClaim (PVC) to request storage, and the cluster binds it to a PersistentVolume (PV) that has been provisioned by an administrator or dynamically provisioned by a StorageClass.

To decouple configuration from application code, Kubernetes provides ConfigMaps and Secrets: - ConfigMap: Stores non-sensitive configuration data as key-value pairs. Pods can consume ConfigMaps as environment variables, command-line arguments, or mounted as files. - Secret: Similar to ConfigMap but designed for sensitive data (e.g., passwords, API keys). Secrets are base64-encoded and can be encrypted at rest. Pods access Secrets similarly to ConfigMaps.

Kubernetes supports manual scaling (updating replica count) and autoscaling: - Horizontal Pod Autoscaler (HPA): Automatically scales the number of pod replicas based on observed CPU/memory utilization or custom metrics. The HPA periodically queries metrics (via Metrics Server) and adjusts the desired replica count of a Deployment or StatefulSet. - Vertical Pod Autoscaler (VPA): Adjusts resource requests and limits for containers based on usage, but requires pod restart. - Cluster Autoscaler: Automatically adjusts the number of nodes in the cluster when pods fail to schedule due to resource shortages or when nodes are underutilized.

Google Kubernetes Engine (GKE) is a managed Kubernetes service on Google Cloud. GKE automates cluster creation, upgrades, node management, and integrates with other Google Cloud services (Cloud Logging, Cloud Monitoring, Cloud Build, etc.). Key GKE features: - Autopilot: A mode where Google manages the entire cluster infrastructure, including node provisioning, scaling, and maintenance. You only pay for pods, not nodes. - Standard: You manage the node pools and have more control over the underlying VMs. - Workload Identity: Allows pods to authenticate to Google Cloud APIs using IAM service accounts. - GKE Ingress: Provides HTTP(S) load balancing using Google Cloud Load Balancer.

For the GCDL, you do not need to know how to write a Deployment YAML or run kubectl commands. Instead, focus on:

Common exam scenarios include identifying when to use Kubernetes vs. other compute options (Compute Engine, App Engine, Cloud Run), understanding how Kubernetes enables rolling updates and self-healing, and recognizing the role of etcd in cluster state management.

A large financial services company with a monolith application running on VMs wants to migrate to microservices on GKE. They have 50+ microservices, each requiring independent scaling, deployment, and health management. Using Kubernetes, they define each microservice as a Deployment with 3 replicas. They use a Service of type LoadBalancer for external-facing APIs and ClusterIP for internal communication. They set up HPA based on CPU utilization (target: 70%) to handle traffic spikes during market hours. They use ConfigMaps for configuration and Secrets for database credentials (encrypted at rest). In production, they run a cluster with 20 nodes (n1-standard-4) and observe 99.95% uptime. Misconfiguration: initially, they set resource requests too low, causing CPU throttling and latency; after adjusting requests to match actual usage, performance stabilized.

A SaaS startup uses GitLab CI to build container images and push them to Artifact Registry. On every merge to main, GitLab triggers a deployment to a staging GKE cluster. The deployment uses a rolling update strategy with maxSurge=1 and maxUnavailable=0 (zero downtime). They use readiness probes to ensure new pods accept traffic before old pods are terminated. In production, they have a multi-cluster setup: one cluster per region (US, EU, Asia) behind a global HTTP(S) load balancer. They use GKE Autopilot to avoid managing nodes. Common issue: readiness probe timeout too short (e.g., 1 second) causes pods to be marked unhealthy prematurely, leading to deployment failures; they increased initialDelaySeconds to 30 seconds.

A media company runs a Cassandra cluster on GKE using StatefulSets. Each pod has a persistent volume (SSD persistent disk) with ReadWriteOnce access mode. They use headless Service for DNS-based pod discovery (each pod gets a stable hostname like cassandra-0.cassandra.default.svc.cluster.local). They scale by adding pods manually (Cassandra handles rebalancing). Performance: with 10 nodes, each with 4 vCPUs and 15GB memory, they handle 50k writes/sec. Misconfiguration: setting podManagementPolicy to Parallel instead of OrderedReady caused race conditions during cluster bootstrap; they switched to OrderedReady to ensure pods start sequentially.