Chapter 1: Introducing Kubernetes

Introduction

The introduction presents Kubernetes as a way to automate running containerized applications and briefly considers when its complexity is worthwhile.

• Desired state and automation: Explain that users define the desired state of their containerized applications and Kubernetes works to achieve and maintain it, handling tasks such as placement, restarts, and accessibility.
  Why it matters: This is the basic idea behind letting Kubernetes run an application instead of managing every task yourself.
• Kubernetes suitability tradeoff: Describe why Kubernetes may be more than a small organization with simple, minimally scaling applications needs, and how a managed Kubernetes service changes the burden for a smaller team.
  Why it matters: The benefits of Kubernetes should be weighed against the work or complexity it adds in a particular setting.

Key terms: API, controllers, containerized applications, desired state, simpler tools, managed Kubernetes services

1.1 Introducing Kubernetes

This section uses the helmsman metaphor to explain Kubernetes’s role and introduces its common names and pronunciations.

• Kubernetes as application helmsman: Explain how the helmsman metaphor divides responsibility between Kubernetes and the person using it.
  Why it matters: The metaphor clarifies who sets the direction and what role Kubernetes plays.
• Kubernetes names and shorthand: State the common shortened names for Kubernetes and explain what the 8 in K8s represents.
  Why it matters: Recognizing these names helps you follow conversations about Kubernetes.

Key terms: helmsman, captain, status, Kube, K8s

1.1.1 Kubernetes in a nutshell

This section explains how Kubernetes abstracts infrastructure, turns an application description into a running system, and handles routine application management.

• Infrastructure abstraction and portability: Explain why developers deploy through Kubernetes rather than to individual computers, and how that makes deployment consistent across local infrastructure and cloud providers.
  Why it matters: You can focus on the application rather than tailoring its deployment to each set of machines.
• Declarative application deployment: Describe how Kubernetes uses an application description to create and maintain a running application, including what happens when the description changes.
  Why it matters: The description states what should run, while Kubernetes handles making the running application match it.
• Automated daily application management: Explain which routine responses Kubernetes takes over after deployment and how that changes the operators' role.
  Why it matters: Automating routine recovery lets operators concentrate on the system's bigger decisions.

Key terms: abstraction layer, underlying infrastructure, manifest, declarative model, description, running application, daily management, application fails, hardware fails, infrastructure topology

1.1.2 About the Kubernetes project

This section explains why Google’s operational needs led to Kubernetes and how it grew into an open source project and broader ecosystem.

• Google’s operational needs: Explain why Google developed systems to manage containerized applications at scale, including the need for automation, efficient infrastructure use, and consistent deployment across data centers.
  Why it matters: These pressures explain the practical problems behind Kubernetes’ origins.
• Kubernetes’ open source origins: Trace Kubernetes from Google’s experience with Borg and Omega to its introduction as an open source project, and describe how other contributors and commercial products followed.
  Why it matters: It distinguishes the shared Kubernetes project from Google’s earlier internal systems and products built on Kubernetes.
• Broader cloud-native ecosystem: Describe how Kubernetes gave rise to related open source projects and a wider community around them.
  Why it matters: Kubernetes is presented not just as one project, but as the center of a larger community.

Key terms: containers, infrastructure utilization, consistent method for deploying applications, Borg, Omega, open source project, enterprise-quality Kubernetes products, Cloud Native Computing Foundation (CNCF), KubeCon–CloudNativeCon, cloud-native eco-system

1.1.3 Understanding why Kubernetes is so popular

The section explains how microservices, closer development–operations collaboration, and cloud portability helped make Kubernetes popular.

• Microservices management at scale: Explain why moving from monoliths to many independently released microservices creates a management problem, and why Kubernetes automation is useful.
  Why it matters: It explains why containers alone are not enough for a system made up of many services.
• Development and operations collaboration: Describe how closer collaboration between developers and operations changes developers’ involvement with deployed software, and why hiding server details helps.
  Why it matters: It connects Kubernetes’ appeal to developers’ increased responsibility for running software.
• Portable cloud deployment APIs: Explain how using Kubernetes APIs rather than a cloud provider’s proprietary APIs makes moving an application between providers easier.
  Why it matters: A shared deployment API can reduce the effort of switching cloud providers.

Key terms: monoliths, microservices, containers, automated management, Dev-Ops paradigm, development team, operations team, underlying servers, cloud provider, proprietary APIs

1.2 Understanding Kubernetes

1.2.1 Understanding how Kubernetes transforms a computer cluster

This section explains how Kubernetes turns a cluster into a unified place to deploy applications while distinguishing the control plane from worker nodes and the limits of that abstraction.

• Cluster operating system analogy: Explain how Kubernetes resembles an operating system for a cluster: it schedules application components onto computers, provides an interface to the cluster, and supplies infrastructure features so developers can focus on business logic.
  Why it matters: The analogy explains what Kubernetes handles for an application developer.
• Control and workload planes: Distinguish the control plane nodes that control the cluster from the worker nodes that run application workloads.
  Why it matters: The distinction clarifies which machines control the cluster and which run applications.
• Unified deployment area limits: Explain why worker nodes appear to be one deployment area through the Kubernetes API, while each application still has to fit on an individual worker node.
  Why it matters: It captures both the convenience of cluster-wide deployment and its physical limit.

Key terms: operating system for the cluster, service discovery, horizontal scaling, load-balancing, self-healing, leader election, control plane, worker nodes, workload plane, single space

1.2.2 The benefits of using Kubernetes

This section explains how Kubernetes benefits development and operations teams through self-service deployment, better resource use, load adjustment, self-healing, and built-in infrastructure services.

• Self-service application deployment: Explain how developers can deploy applications without choosing a worker node or asking an administrator to place the application.
  Why it matters: Developers can deploy without needing to know the cluster's individual machines.
• Better infrastructure utilization: Explain why Kubernetes can run more applications on fewer servers by placing or moving applications among nodes.
  Why it matters: More effective placement can reduce the number of servers needed.
• Adjustment to changing load: Describe how Kubernetes responds to increased application load and how a cloud-hosted cluster can gain capacity.
  Why it matters: Operations teams need not respond manually to every load peak.
• Automatic failure recovery: Describe Kubernetes' responses to application crashes and node failures, including when operations staff can defer repair.
  Why it matters: Automatic recovery reduces the immediate operational burden of software and hardware failures.
• Built-in development services: Explain how Kubernetes can simplify application development without requiring applications to depend directly on its API.
  Why it matters: Developers can avoid building some common infrastructure features into each application.

Key terms: worker nodes, single deployment surface, resource requirements, infrastructure utilization, nodes, resources, metrics, running instances, provisioning additional nodes, self-healing system

1.2.3 The architecture of a Kubernetes cluster

The section introduces the cluster’s control and workload planes and summarizes the components that control the cluster and run applications.

• Control and workload planes: Distinguish control plane nodes from worker nodes by what each contributes to a Kubernetes cluster.
  Why it matters: This distinction helps you place the cluster’s components and your applications.
• Control plane component roles: Describe the basic functions of the API Server, etcd, Scheduler, and controllers.
  Why it matters: These roles explain how the control plane holds and controls cluster state without running your applications.
• Worker node component roles: Describe how the Kubelet, container runtime, and Kubernetes Service Proxy contribute to running applications on worker nodes.
  Why it matters: These components connect cluster control to the containers and traffic on a worker node.
• Additional cluster components: State what kinds of add-on components a cluster may contain and where they typically run.
  Why it matters: It prevents treating the named core components as an exhaustive list of everything in a cluster.

Key terms: control plane, control plane nodes, worker nodes, workload plane, Kubernetes API Server, Kubernetes API, etcd, Scheduler, Controllers, Kubelet

1.2.4 How Kubernetes runs an application

This section traces how an application definition becomes running, reachable application instances and how Kubernetes keeps them running.

• Application objects and manifests: Explain that an application is defined through Kubernetes objects, usually written in YAML or JSON manifest files, rather than as a single application file.
  Why it matters: This is the starting point for understanding what you submit when deploying an application.
• API submission and storage: Trace how kubectl submits objects from a manifest to the API Server and what the API Server does with them.
  Why it matters: Submitting a manifest starts the work of the other Kubernetes components.
• Controllers and application replicas: Explain how a controller reacts to a newly created deployment object and creates objects for the requested application instances.
  Why it matters: It explains how an application definition leads to individual instances.
• Instance scheduling and startup: Trace the distinct roles of the scheduler, the node's Kubelet, and the container runtime in starting an application instance.
  Why it matters: It separates the decision about where an instance runs from the work of starting it.
• Single address for instances: Explain why multiple application instances need a load balancer and identify kube-proxy's role in setting it up.
  Why it matters: It explains how clients can reach an application that has more than one instance.
• Ongoing application health: Describe how the Kubelet and other controllers respond after an application starts, including termination and node failure.
  Why it matters: Kubernetes continues managing an application after its containers have started.

Key terms: object, Kubernetes API, manifest, YAML, JSON, kubectl, API Server, etcd, controller, application deployment

1.3 Introducing Kubernetes into your organization

1.3.1 Running Kubernetes on-premises and in the cloud

This section compares running Kubernetes on-premises, in the cloud, or in a hybrid setup, focusing on capacity and cost tradeoffs.

• On-premises deployment constraints: Explain why an organization might run Kubernetes on-premises and how that affects its ability to scale a cluster.
  Why it matters: Where you must run applications can limit your infrastructure choices and how readily you can add capacity.
• Cloud cluster elasticity: Explain how cloud-hosted Kubernetes can adjust cluster capacity as workloads change and why that is useful.
  Why it matters: Cloud elasticity lets cluster capacity follow demand instead of remaining fixed at peak size.
• Hybrid capacity spillover: Describe how a hybrid setup uses local and cloud resources to handle occasional peaks, and state the other location combinations the section allows.
  Why it matters: A hybrid arrangement can cover occasional demand beyond local capacity without renting cloud machines all the time.

Key terms: on-premises, bare-metal machines, virtual machines, cloud provider, worker nodes, elasticity of the cluster, hybrid cloud solution, spill over into the cloud, control plane

1.3.2 To manage or not to manage Kubernetes yourself

This section explains why an organization should weigh the difficulty of operating Kubernetes itself against using a managed cloud offering.

• Self-managed cluster risks: Explain why having on-premises hardware is not, by itself, a good reason to manage a production Kubernetes cluster yourself, and what preparation the section recommends.
  Why it matters: The decision to operate a cluster yourself carries responsibilities beyond having enough hardware.
• Managed cluster responsibilities: Distinguish using a managed Kubernetes cluster from managing Kubernetes yourself in terms of who operates the platform and what the user does.
  Why it matters: A managed offering lets a team use Kubernetes without taking on the same platform-management burden.

Key terms: production-ready Kubernetes cluster, managing Kubernetes, Kubernetes-as-a-Service, managed Kubernetes cluster, Kubernetes API

1.3.3 Using vanilla or extended Kubernetes

This section compares vanilla Kubernetes with enterprise-grade distributions for production use.

• Vanilla and enterprise tradeoffs: Explain the production tradeoff between vanilla Kubernetes and an enterprise-grade distribution: vanilla is at the cutting edge but needs production fine-tuning, while distributions provide stronger defaults and added capabilities but usually lag upstream releases.
  Why it matters: These tradeoffs help you choose a Kubernetes version suited to production needs.

Key terms: vanilla, open source version, enterprise-quality Kubernetes distribution, upstream Kubernetes API, security defaults

1.3.4 Should you even use Kubernetes?

This section gives three practical checks for deciding whether introducing Kubernetes is worth it.

• Need for automated management: Explain how the need to automate application management affects whether Kubernetes is a good fit, using the section’s monolith and microservice examples.
  Why it matters: The value of automated management should justify adding Kubernetes to your system.
• Engineer learning investment: Describe the engineer time an organization must be willing to invest when adopting Kubernetes, even if its applications do not need modification.
  Why it matters: Adoption has a time cost for the engineering team even when application code need not change.
• Interim adoption costs: Explain why an organization should expect higher costs when it first introduces Kubernetes despite the prospect of lower long-term operational costs.
  Why it matters: A long-term saving does not mean the organization can avoid near-term spending.

Key terms: automate the management, monolith, microservices, development engineers, operators, long-term operational costs, training, additional computing resources

1.4 Summary

The chapter summary recaps Kubernetes’ declarative approach, its benefits for running applications, and the basic structure and management choices of a cluster.