1 Introducing Kubernetes

This chapter sets the stage for learning Kubernetes by explaining the problems it solves, where it came from, and how it changes the way you build and run applications.

Origins and motivation

Kubernetes emerged from Google’s experience operating large-scale, containerized workloads (inspired by internal systems like Borg and Omega). It addresses the operational challenges that arise once you adopt containers broadly: scheduling containers onto machines, handling failures, exposing services reliably, scaling up and down, rolling out changes safely, and keeping the actual system aligned with a declared desired state.

Why Kubernetes has seen wide adoption

• Portability and consistency across environments (laptop, on-prem, cloud) via containers and declarative APIs.
• Resilience and self-healing through automatic restarts, rescheduling, and replication.
• Scalability via horizontal scaling and efficient bin packing across a cluster.
• Operational velocity with rolling updates, rollbacks, and automation-friendly workflows.
• Rich ecosystem and extensibility (open source community, controllers, operators, add-ons).

How Kubernetes transforms your data center

• Abstracts a fleet of machines into a single, shared, multi-tenant cluster, turning infrastructure into a programmable platform.
• Shifts operations from imperative scripts to declarative configuration and reconciliation loops.
• Encourages microservices, immutable artifacts, and GitOps-style delivery, improving repeatability and auditability.
• Standardizes cross-cutting concerns (discovery, config, secrets, autoscaling) and promotes automation over ticket-driven operations.

Architecture and operation overview

Kubernetes is a control-plane-driven system with a clear separation between desired state and actual state:

• Control plane: API server (front door and state machine), a strongly consistent store (etcd), the scheduler (assigns pods to nodes), and controllers (reconcile objects to their desired state).
• Nodes: run workloads via a container runtime; kubelet ensures pods on the node match what the API declares; kube-proxy handles service-level networking.
• Core API objects: Pods (smallest deployable unit), Deployments and ReplicaSets (versioning and scaling), Services (stable networking), Namespaces (multi-tenancy), ConfigMaps and Secrets (configuration), plus Jobs, CronJobs, DaemonSets, and more.
• Operation model: you submit declarative manifests; controllers continuously compare desired state to reality and act to converge the system (scheduling, rescheduling, restarting, scaling, and updating).

Integrating Kubernetes into your organization

• Assess fit: Kubernetes shines for many services, microservices, and teams needing portability and automation; for small, simple apps, a PaaS or serverless platform may suffice.
• Start pragmatic: begin with a pilot, prefer managed Kubernetes where possible, and adopt incremental patterns (namespaces, RBAC, resource quotas).
• Evolve delivery: standardize on container images, CI/CD pipelines, declarative manifests, and progressive delivery (rolling updates, canaries).
• Prepare foundations: observability (logs/metrics/traces), policy and security (admission controls, secrets management), and cost/efficiency practices (autoscaling, requests/limits).

Key takeaways

• Kubernetes provides a consistent, declarative control plane for deploying and operating containers at scale.
• Its reconciliation-driven model, extensibility, and ecosystem underpin its broad adoption.
• Adopting Kubernetes is as much an organizational and process shift as it is a technical one—start small, automate relentlessly, and build platform capabilities over time.

1.1 Introducing Kubernetes

Kubernetes, named after the Greek word for helmsman, is designed to steer applications while you set the destination. It automates deployment, scaling, and day-to-day operations for containerized workloads so teams can focus on business logic rather than infrastructure details.

How to pronounce and shorthand

• Common pronunciations include “Koo-ber-netties” and “Koo-ber-nay-tace.”
• Often referred to as Kube or K8s (“Kates”), where 8 is the count of omitted letters.

Kubernetes in a nutshell

• Abstracts away infrastructure: Applications are deployed to Kubernetes, not to individual machines, hiding servers, networks, and other components behind a consistent interface.
• Standardizes deployment: The same manifest can target on-premises and any cloud; Kubernetes bridges environment differences so teams deploy uniformly everywhere.
• Declarative model: You describe the desired state of your application; Kubernetes realizes and continuously reconciles the running system to match that description, applying changes automatically when manifests are updated.
• Automated operations: Handles restarts, rescheduling on hardware failures, and adapts to topology changes, freeing engineers to focus on higher-level concerns.

About the Kubernetes project

• Origins at Google: Built from experience running containers at massive scale (thousands of machines, global data centers), where automation is indispensable.
• Predecessors: Internal systems Borg and Omega enabled efficient development, operation, and high infrastructure utilization—critical at large scale.
• Open source since 2014: Rapidly adopted and co-developed by many organizations and thousands of contributors; now one of the leading open-source projects.
• Enterprise offerings: Numerous commercial distributions (e.g., OpenShift, PKS, Rancher) package Kubernetes for production use.
• Cloud-native ecosystem: Sparked a wide ecosystem under the CNCF and large global conferences, reflecting broad industry impact and adoption.

Note

Estimates of Google’s energy use suggest operation of around 900,000 servers.

Why Kubernetes is so popular

• Microservices at scale: Breaking monoliths into many services increases operational complexity. Containers isolate dependencies, but multiply units to manage. Kubernetes automates deployment, scaling, communication, and resilience across hundreds of services.
• DevOps alignment: Developers and operators collaborate across the software lifecycle; Kubernetes shields teams from low-level infrastructure while enabling shared operational responsibility.
• Cloud standardization: By targeting Kubernetes APIs instead of cloud-specific ones, organizations reduce lock-in and can move workloads more easily across providers. Major clouds offer first-class Kubernetes support, making a single operational model portable.

1.2 Understanding Kubernetes

1.2.1 Understanding how Kubernetes transforms a computer cluster

Kubernetes is like an operating system for computer clusters

Kubernetes acts as the cluster’s operating system: it schedules distributed application components across machines and provides a uniform interface between apps and the underlying infrastructure. Developers offload cross-cutting concerns to Kubernetes and focus on business logic.

• Service discovery
• Horizontal scaling
• Load balancing
• Self-healing (restart and reschedule on failures)
• Leader election

How Kubernetes fits into a computer cluster

Clusters are split into master (Control Plane) and worker (Workload Plane) nodes. The Control Plane manages and controls the cluster; worker nodes run application workloads. Production-grade, highly available clusters replicate Control Plane components across at least three masters.

How all cluster nodes become one large deployment area

After installation, all worker nodes form a single logical deployment surface. You deploy to the cluster via the Kubernetes API without choosing specific machines. Kubernetes may move workloads between nodes to maintain health and optimize placement. Each workload instance must still fit within a single node’s resources.

1.2.2 The benefits of using Kubernetes

Self-service deployment of applications

Developers can deploy without coordinating with administrators. Kubernetes selects suitable nodes based on resource requirements and availability.

Reducing costs via better infrastructure utilization

Kubernetes efficiently packs workloads and can relocate them to free capacity for others, improving hardware utilization and reducing costs.

Automatically adjusting to changing load

Kubernetes scales applications horizontally based on metrics and, on cloud platforms, can also scale the cluster itself by adding nodes.

Keeping applications running smoothly

Kubernetes automatically restarts failed processes and reschedules workloads off failed nodes, reducing operational toil and enabling calm incident response.

Simplifying application development

Built-in primitives replace custom infrastructure code (discovery, leader election, config, etc.). Apps can stay Kubernetes-agnostic yet optionally query or modify their environment via the API.

1.2.3 The architecture of a Kubernetes cluster

A Kubernetes cluster comprises:

• Control Plane on master nodes: the system’s brain, managing desired and current state
• Workload Plane on worker nodes: where application workloads run

Control Plane components

• API Server: exposes the Kubernetes REST API
• etcd: distributed datastore for cluster state (accessed only by the API Server)
• Scheduler: assigns workloads to worker nodes
• Controllers: reconcile objects to desired state; some interface with external systems

The Control Plane defines and maintains state; it does not run your application processes.

Worker node components

• Kubelet: node agent that manages local workloads and reports status
• Container Runtime: runs containers (Docker or any compatible runtime)
• Kube Proxy: provides in-cluster service networking and load balancing

Add-on components

• Common add-ons include DNS, network plugins, and logging agents, typically running on workers (optionally masters).

1.2.4 How Kubernetes runs an application

Defining your application

Everything is an API object. You define applications with manifests (YAML or JSON) that specify deployments, replicas, services, and more.

• YAML: human-readable serialization format
• JSON: widely used data-interchange format

End-to-end workflow

1. You submit manifests (often via kubectl) to the API Server.
2. The API Server validates and persists objects to etcd and notifies interested components.
3. Controllers create lower-level objects (e.g., per-instance objects) to realize the desired state.
4. The Scheduler assigns each instance to a suitable worker node.
5. The Kubelet on the chosen node starts containers via the Container Runtime and keeps them healthy.
6. Kube Proxy configures networking to expose services and load-balance across instances.
7. Controllers and Kubelets continuously reconcile and heal the system, rescheduling on node failures and restarting crashed processes.

Treat this as a conceptual overview; later chapters detail each object type and the controllers that reconcile them.

1.3 Introducing Kubernetes into your organization

This section outlines practical choices for adopting Kubernetes: where to run it (on-premises, in the cloud, or hybrid), whether to manage it yourself or use a managed service, which distribution to choose (vanilla vs enterprise), and how to decide if Kubernetes is appropriate for your workloads right now.

1.3.1 Running Kubernetes on-premises and in the cloud

• On-premises: Often required by regulation; can run on bare metal or local VMs. Scaling capacity is constrained by your data center resources and is less elastic than cloud-based clusters.
• Cloud: Highly elastic. Kubernetes can request more or fewer virtual machines to match workload demand, improving responsiveness and controlling costs.
• Hybrid/multi-cloud: Run primarily on-premises and burst to the cloud during peaks, or span multiple providers/locations. Offers flexibility and cost control at the expense of added complexity.

1.3.2 To manage or not to manage Kubernetes yourself

• Self-managed: Operating production-grade clusters is complex and risky without deep expertise. Suitable for learning and non-production, but consult experienced practitioners before committing to run it yourself.
• Managed services: Using Kubernetes is far easier than managing it. Major clouds provide managed offerings (e.g., GKE, AKS, EKS, IBM Cloud, OpenShift Online/Dedicated, VMware Cloud PKS, Alibaba ACK) so you focus on the Kubernetes API while the provider operates the control plane. Early exercises in the book use local development and a managed GKE cluster; later chapters build foundational ops knowledge.

1.3.3 Using vanilla or extended Kubernetes

• Vanilla (upstream): Community-driven, cutting-edge, but may be less stable and lacks strong secure defaults; requires significant tuning for production.
• Enterprise distributions: Products like OpenShift and Rancher harden defaults, add features (such as user management objects) and curated tooling for common apps. They typically trail upstream by one or two versions, but the added security, performance, and operability often justify the lag.

1.3.4 Should you even use Kubernetes?

• Need for orchestration: Monoliths don’t benefit. Very small microservice systems (≈<5 services) may not justify the overhead; larger systems (≈>20 services) usually do. In-between depends on context.
• Learning investment: Even if operators run Kubernetes, developers will spend time learning and interacting with it.
• Short-term costs: Expect higher initial spend on training, hiring, tooling, possible hardware, and cluster overhead before long-term efficiencies appear.
• Hype check: Evaluate objectively; don’t adopt solely because it’s popular.

With these trade-offs in mind, the chapter invites you to step aboard and examine containers next.

1.4 Summary