The Kubernetes Book 2024 Edition E-Book

Nigel Poulton

• Herausgeber: WS
• Kategorie: Fachliteratur
• Sprache: Englisch
• Veröffentlichungsjahr: 2023

Seitenzahl: 362

Beschreibung

2024 edition. Fully updated for Kubernetes v1.29. Brand new chapter covering WebAssembly on Kubernetes.

The Kubernetes Book, by Nigel Poulton, renowned author and video trainer, is up to date with the latest trends in Kubernetes and the rapidly evolving cloud-native ecosystem.

Containers transformed how we package and deploy applications, but they came with inherent challenges. Kubernetes is a platform for deploying and managing containerised applications at scale. It also abstracts underlying infrastructure, making it easier to deploy and manage applications across heterogenous clouds and on-premises environments.

The Kubernetes Book offers a beginner-friendly approach to mastering Kubernetes architecture and core concepts such as Pods, Deployments, Services, StatefulSets, Ingress, ConfigMaps, and more. It also demystifies the Kubernetes API, teaches you how to secure Kubernetes, and brings you up to speed with important cloud-native concepts such as microservices, declarative configuration, desired state, reconciliation, and more.

The book also serves as a comprehensive guide for software developers, systems administrators, cloud engineers, and architects to help them master Kubernetes. It offers the most precise explanations and is full of practical examples to help develop applications on a laptop and then deploy them to real-world Kubernetes environments.

★ The Kubernetes Book is updated annually, meaning it's always up to date with the latest and greatest in the Kubernetes and cloud-native ecosystems.

Leseprobe

The 

Kubernetes 

Book

January 2024

Weapons-grade Kubernetes learning!

Nigel Poulton @nigelpoulton

About this edition

This edition was published in January 2024.

In writing this edition, I've gone over every word in every chapter ensuring everything is up-to-date with the latest trends and patterns in the industry. I've added a brand new chapter showing you how write a WebAsembly (Wasm) app and configure Kubernetes to run it. Finally, I've tested and updated all examples and hands-on tasks to work with Kubernetes 1.29. Enjoy the book and get ready to master Kubernetes!.

Getting newer editions

If there's a newer edition of the book in the Kindle Store, contact Amazon Support and ask them to push the latest edition to your device. Simply contact Kindle Support by phone, chat, or any other means and tell them there's an updated version of "The Kubernetes Book" that you want on your device. They'll push the new edition and you'll receive it immediately.

Enjoy the book and get ready to master Kubernetes!

Nigel

(c) 2024 Nigel Poulton Ltd.

All typos are mine. Or should that be typo’s… ;-)

Education is about inspiring and creating opportunities. I hope this book, and my video training courses, inspire you and create lots of opportunities!

A huge thanks to my family for putting up with me. I’m a geek who thinks he’s software running on midrange biological hardware. I know it’s not easy living with me.

Thanks to everyone who watches my Pluralsight and A Cloud Guru training videos. I love connecting with you and appreciate all the feedback I’ve had over the years. This feedback is what inspired me to write this book. I think you’ll love it, and I hope it helps drive your career forward.

@nigelpoulton

About the authors

I’d like to thank Pushkar for his writing the security chapters. He approached me at a KubeCon and asked if he could contribute some content on real-world security. Collaborating on content isn’t something I’ve done before, and I tried to tell him “no thanks”. However, he was keen, so we made it happen. To be clear, the technical content for the security chapters is all Pushkar’s. I just tweaked the writing style so the book has a consistent feel.

Author: Nigel Poulton (@nigelpouton)

Nigel is a techoholic who spends his life creating books, training videos, and other stuff that makes learning Kubernetes less scary. He’s the author of best-selling books on Docker and Kubernetes, as well as the most popular online training videos on the same topics. He’s also a Docker Captain. Prior to all of this, Nigel held various senior infrastructure roles at large enterprises (mainly banks).

When he’s not playing with technology, he’s dreaming about it. When he’s not dreaming about it, he’s reading and watching scifi. He wishes he lived in the future so he could explore space-time, universes, and tons of other mind-blowing stuff. He likes cars, Formula One, golf, football (soccer), and food. He has a fabulous wife and three epic children.

Contributing author: Pushkar Joglekar

Pushkar is currently working as a Security Engineer @ VMware Tanzu to help make Kubernetes secure-by-default, for all. In the last few years, he’s built multiple “secure by design” production container deployments for a Fortune 500 company and is an active contributor in the CNCF security community.

When not securing containers, he spends his time exploring neighborhood bike trails and capturing beautiful sunsets through his camera while sipping home-made masala ginger chai. He lives with his wonderful wife, who happens to be the real engineer among them.

Table of Contents

0: Preface

Editions Paperbacks, hardbacks, eBooks, audio, and translations

The sample app and GitHub repo

Windows users

Responsible language

1: Kubernetes primer

Important Kubernetes background

Kubernetes: the operating system of the cloud

Chapter summary

2: Kubernetes principles of operation

Kubernetes from 40K feet

Control plane and worker nodes

Packaging apps for Kubernetes

The declarative model and desired state

Pods

Deployments

Service objects and stable networking

Chapter summary

3: Getting Kubernetes

Create a Kubernetes cluster on your laptop

Create a hosted Kubernetes cluster in the cloud

Working with kubectl

Chapter summary

4: Working with Pods

Pod theory

Multi-container Pods

Hands-on with Pods

Clean up

Chapter Summary

5: Virtual clusters with Namespaces

Intro to Namespaces

Namespace use cases

Default Namespaces

Creating and managing Namespaces

Deploying objects to Namespaces

Clean up

Chapter Summary

6: Kubernetes Deployments

Deployment theory

Create a Deployment

Manually scale the app

Perform a rolling update

Perform a rollback

Clean up

Chapter summary

7: Kubernetes Services

Service Theory

Hands-on with Services

Clean up

Chapter Summary

8: Ingress

Setting the Scene for Ingress

Ingress architecture

Hands-on with Ingress

Clean up

Chapter summary

9: WebAssembly on Kubernetes

Wasm Primer

Understanding Wasm on Kubernetes

Hands-on with Wasm on Kubernetes

Chapter Summary

10: Service discovery deep dive

Setting the scene

The service registry

Service registration

Service discovery

Service discovery and Namespaces

Troubleshooting service discovery

Clean up

Chapter summary

11: Kubernetes storage

The big picture

Storage Providers

The Container Storage Interface (CSI)

The Kubernetes persistent volume subsystem

Dynamic provisioning with Storage Classes

Hands-on

Clean up

Chapter Summary

12: ConfigMaps and Secrets

The big picture

ConfigMap theory

Hands-on with ConfigMaps

Hands-on with Secrets

Clean up

Chapter Summary

13: StatefulSets

StatefulSet theory

Hands-on with StatefulSets

Clean up

Chapter Summary

14: API security and RBAC

API security big picture

Authentication

Authorization (RBAC)

Admission control

Chapter summary

15: The Kubernetes API

Kubernetes API big picture

The API server

The API

Clean up

Chapter summary

16: Threat modeling Kubernetes

Threat modeling

Spoofing

Tampering

Repudiation

Information Disclosure

Denial of Service

Elevation of privilege

Chapter summary

17: Real-world Kubernetes security

Security in the software delivery pipeline

Workload isolation

Identity and access management (IAM)

Auditing and security monitoring

Real-world example

Chapter summary

Terminology

Outro

About the front cover

A word on the book’s diagrams

Connect with me

Feedback and reviews

More from the author

Landmarks

Begin Reading

0: Preface

Kubernetes is developing fast, so I update the book every year. And when I say update, I mean real updates — I review every word and every concept, and test every example against the latest versions of Kubernetes. I’m 100% committed to making this the best Kubernetes book in the world.

As an author, I’d love to write a book and never touch it again for five years. Unfortunately, a two-year-old book on Kubernetes could be dangerously out of date.

Editions Paperbacks, hardbacks, eBooks, audio, and translations

The following editions of the book are available:

Paperback: English, Simplified Chinese, Spanish, PortugueseHardback: EnglisheBook: English, Russian, Spanish, Portuguese

eBook copies are available on Kindle and from Leanpub.

The following collector’s editions are available. Each has a themed front cover, but the content is exactly the same as the regular English-language edition.

Klingon paperbackBorg hardbackSterfleet paperback

The sample app and GitHub repo

There’s a GitHub repo with all the YAML and code used throughout the book.

You can clone it with the following command. You’ll need git installed. This will create a new folder in your current working directory called TheK8sBook with all the files you need to follow the examples.

$ git clone https://github.com/nigelpoulton/TheK8sBook.git

Don’t stress if you’ve never used git. The book walks you through everything you need to do.

Windows users

Almost all of the commands in the hands-on sections work on Linux, Mac, and Windows. However, a small number require slight changes to work on Windows. Whenever this is the case, I explain what you need to do to make them work on Windows.

However, to prevent myself from repeating the same thing too often, I don’t always tell Windows users to replace backslashes with backticks for linebreaks. With this in mind, Windows users should do one of the following every time the book splits a command over multiple lines using backslashes:

Remove the backslash and run the command on a single lineReplace the backslash with a backtick

All other changes are explained in full every time.

Responsible language

The book follows Inclusive Naming Initiative (inclusivenaming.org) guidelines, which attempt to avoid harmful terms and promote responsible language.

1: Kubernetes primer

This chapter gets you up-to-speed with the basics and background of Kubernetes and is divided as follows:

Important Kubernetes backgroundKubernetes: the Operating System of the cloud

Important Kubernetes background

Kubernetes is an orchestrator of containerized cloud-native microservices apps.

That’s a lot of jargon, so let’s explain things.

Orchestration

An orchestrator is a system or platform that deploys applications and dynamically responds to changes. For example, Kubernetes can:

Deploy applicationsScale them up and down based on demandSelf-heal them when things breakPerform zero-downtime rolling updates and rollbacksLots more

The best part is that it does all of this without you having to get involved. You need to configure a few things in the first place, but once you’ve done that, you sit back and let Kubernetes work its magic.

Containerization

Containerization is the process of packaging an application and dependencies as an image and then running it as a container.

It can be useful to think of containers as the next generation of virtual machines (VM). Both are ways of packaging and running applications, but containers are smaller, faster, and more portable.

Despite these advantages, containers haven’t replaced VMs, and it’s common for them to run side-by-side in most cloud-native environments. However, containers are the first-choice solution for most new applications.

Cloud native

Cloud-native applications possess cloud-like features such as auto-scaling, self-healing, automated updates, rollbacks, and more.

Simply running a regular application in the public cloud does not make it cloud-native.

Microservices

Microservices applications are built from many small, specialized, independent parts that work together to form a useful application.

Consider an e-commerce app with the following six features:

Web front-endCatalogShopping cartAuthenticationLoggingStore

To make this a microservices app, you design, develop, deploy, and manage each feature as its own small application. We call each of these small apps a microservice, meaning this app will have six microservices.

This design brings huge flexibility by allowing all six microservices to have their own small development teams and their own release cycles. It also lets you scale and update each one independently.

The most common pattern is to deploy each microservice as its own container. This means one or more web front-end containers, one or more catalog containers, one or more shopping cart containers, etc. Scaling any part of the app is as simple as adding or removing containers.

Now that we’ve explained a few things, let’s re-write that jargon-filled sentence from the start of the chapter.

The original sentence read; “Kubernetes is an orchestrator of containerized cloud-native microservices apps.” We now know this means: Kubernetes deploys and manages applications that are packaged as containers and can easily scale, self-heal, and be updated.

That should clarify some of the main industry jargon. But don’t worry if some of it still needs to be clarified; we’ll cover everything again in much more detail throughout the book.

Where did Kubernetes come from

Kubernetes was developed by a group of Google engineers partly in response to Amazon Web Services (AWS) and Docker.

AWS changed the world when it invented modern cloud computing, and everyone needed to catch up.

One of the companies catching up was Google. They’d built their own cloud but needed a way to abstract the value of AWS and make it as easy as possible for customers to get off AWS and onto their cloud. They also ran production apps, such as Search and Gmail, on billions of containers per week.

At the same time, Docker was taking the world by storm, and users needed help managing explosive container growth.

While all this was happening, a group of Google engineers took the lessons they’d learned using their internal container management tools and created a new tool called Kubernetes. In 2014, they open-sourced Kubernetes and donated it to the newly formed Cloud Native Computing Foundation (CNCF).

At the time of writing, Kubernetes is ~10 years old and has experienced incredible growth and adoption. However, at its core, it still does the two things Google and the rest of the industry need:

It abstracts infrastructure (such as AWS)It simplifies moving applications between clouds

These are two of the biggest reasons Kubernetes is important to the industry.

Kubernetes and Docker

All of the early versions of Kubernetes shipped with Docker and used it as its runtime. This means Kubernetes used Docker for low-level tasks such as creating, starting, and stopping containers. However, two things happened:

Docker got bloatedPeople created lots of Docker alternatives

As a result, the Kubernetes project created the container runtime interface (CRI) to make the runtime layer pluggable. This means you can pick and choose the best runtimes for your needs. For example, some runtimes provide better isolation, whereas others provide better performance.

Kubernetes 1.24 finally removed support for Docker as a runtime as it was bloated and overkill for what Kubernetes needed. Since then, most new Kubernetes clusters ship with containerd (pronounced “container dee”) as the default runtime. Fortunately, containerd is a stripped-down version of Docker optimized for Kubernetes, and it fully supports applications containerized by Docker. In fact, Docker, containerd, and Kubernetes all work with images and containers that implement the Open Container Initiative (OCI) standards.

Figure 1.2 shows a four-node cluster running multiple container runtimes.

Figure 1.2

Notice how some of the nodes have multiple runtimes. Configurations like this are fully supported and increasingly common. You’ll work with a configuration like this in Chapter 14 when you deploy a WebAssembly (Wasm) app to Kubernetes.

What about Docker Swarm

In 2016 and 2017, Docker Swarm, Mesosphere DCOS, and Kubernetes competed to become the industry standard container orchestrator. Kubernetes won.

However, Docker Swarm remains under active development and is popular with small companies wanting a simple alternative to Kubernetes.

Kubernetes and Borg: Resistance is futile!

We already said that Google has been running containers at massive scale for a very long time. Well, orchestrating these billions of containers were two in-house tools called Borg and Omega. So, it’s easy to make the connection with Kubernetes — all three orchestrate containers at scale, and all three are related to Google.

However, Kubernetes is not an open-source version of Borg or Omega. It’s more like Kubernetes shares its DNA and family history with them.

Figure 1.3 - Shared DNA

As things stand, Kubernetes is an open-source project owned by the CNCF. It’s licensed under the Apache 2.0 license, version 1.0 shipped way back in July 2015, and at the time of writing, we’re already at version 1.29 and averaging three new releases per year.

Kubernetes — what’s in the name

Most people pronounce Kubernetes as “koo-ber-net-eez”, but the community is very friendly, and people won’t mind if you pronounce it differently.

The word Kubernetes originates from the Greek word for helmsman or the person who steers a ship. You can see this in the logo, which is a ship’s wheel.

Figure 1.4 - The Kubernetes logo

Some of the original engineers wanted to call Kubernetes Seven of Nine after the famous Borg drone from the TV series Star Trek Voyager. Copyright laws wouldn’t allow this, so they gave the logo seven spokes as a subtle reference to Seven of Nine.

One last thing about the name. You’ll often see it shortened to K8s and pronounced as “kates”. The number 8 replaces the eight characters between the “K” and the “s”.

Kubernetes: the operating system of the cloud

Kubernetes is the de facto platform for cloud-native applications, and we sometimes call it the operating system (OS) of the cloud. This is because Kubernetes abstracts the differences between cloud platforms the same way that operating systems like Linux and Windows abstract the differences between servers:

Linux and Windows abstract server resources and schedule application processesKubernetes abstracts cloud resources and schedules application microservices

As a quick example, you can schedule applications to Kubernetes without caring if it’s running on AWS, Azure, Civo Cloud, GCP, or your on-premises datacenter. This makes Kubernetes a key enabler for:

Hybrid cloudMulti-cloudCloud migrations

In summary, Kubernetes makes it easier to deploy to one cloud today and migrate to another cloud tomorrow.

Application scheduling

One of the main things an OS does is simplify the scheduling of work tasks.

Computers are complex collections of hardware resources such as CPU, memory, storage, and networking. Thankfully, modern operating systems hide most of this and make the world of application development a far friendlier place. For example, how many developers need to care which CPU core, memory DIMM, or flash chip their code uses? Most of the time, we leave it up to the OS.

Kubernetes does a similar thing with clouds and datacenters.

At a high level, a cloud or datacenter is a complex collection of resources and services. Kubernetes can abstract a lot of these and make them easier to consume. Again, how often do you need to care about which compute node, which failure zone, or which storage volume your app uses? Most of the time, we’re happy to let Kubernetes decide.

Chapter summary

Kubernetes was created by Google engineers based on lessons learned running containers at hyper-scale for many years. It was donated to the community as an open-source project and is now the industry standard platform for deploying and managing cloud-native applications. It runs on any cloud or on-premises datacenter and abstracts the underlying infrastructure. This allows you to build hybrid clouds, as well as migrate on, off, and between different clouds. It’s open-sourced under the Apache 2.0 license and is owned and managed by the Cloud Native Computing Foundation (CNCF).

Don’t be afraid of all the new terminology. I’m here to help, and you can reach me at any of the following:

Twitter: @nigelpoultonLinkedIn: linkedin.com/in/nigelpoulton/Mastodon: @[email protected]: nigelpoulton.comEmail: [email protected]

2: Kubernetes principles of operation

This chapter introduces you to major Kubernetes technologies and prepares you for upcoming chapters. You’re not expected to be an expert at the end of this chapter.

We’ll cover all of the following:

Kubernetes from 40K feetControl plane nodes and worker nodesPackaging apps for KubernetesThe declarative model and desired statePodsDeploymentsServices

Kubernetes from 40K feet

Kubernetes is both of the following:

A clusterAn orchestrator

Kubernetes: Cluster

A Kubernetes cluster is one or more nodes providing CPU, memory, and other resources for use by applications.

Kubernetes supports two node types:

Control plane nodesWorker nodes

Both types can be physical servers, virtual machines, or cloud instances, and both can run on ARM and AMD64/x86-64. Control plane nodes must be Linux, but worker nodes can be Linux or Windows.

Control plane nodes implement the Kubernetes intelligence, and every cluster needs at least one. However, you should have three or five for high availability (HA).

Every control plane node runs every control plane service. These include the API server, the scheduler, and the controllers that implement cloud-native features such as self-healing, autoscaling, and rollouts.

Worker nodes are for running user applications.

Figure 2.1 shows a cluster with three control plane nodes and three workers.

Figure 2.1

It’s common to run user applications on control plane nodes in development and test environments. However, many production environments restrict user applications to worker nodes so that control plane nodes can focus entirely on cluster operations.

Control plane nodes can also run user applications, but you should probably force user applications to run on worker nodes in production environments. Doing this allows control plane nodes to focus on managing the cluster.

Kubernetes: Orchestrator

Orchestrator is jargon for a system that deploys and manages applications.

Kubernetes is the industry-standard orchestrator and can intelligently deploy applications across nodes and failure zones for optimal performance and availability. It can also fix them when they break, scale them when demand changes, and manage zero-downtime rolling updates.

That’s the big picture. Let’s dig a bit deeper.

Control plane and worker nodes

We already said a Kubernetes cluster is one or more control plane nodes and worker nodes.

Control plane nodes have to be Linux, but workers can be Linux or Windows.

Almost all cloud-native apps are Linux and will run on Linux worker nodes. However, you’ll need one or more worker nodes running Windows if you have cloud-native Windows apps. Fortunately, a single Kubernetes cluster can have a mix of Linux and Windows worker nodes, and Kubernetes is intelligent enough to schedule apps to the correct nodes.

The control plane

The control plane is a collection of system services that implement the brains of Kubernetes. It exposes the API, schedules tasks, implements self-healing, manages scaling operations, and more.

The simplest setups run a single control plane node and are best suited for labs and testing. However, as previously mentioned, you should run three or five control plane nodes in production environments and spread them across availability zones for high availability, as shown in Figure 2.2

Figure 2.2 Control plane high availability

As previously mentioned, it’s sometimes considered a production best practice to run all user apps on worker nodes, allowing control plane nodes to allocate all resources to cluster-related operations.

Most clusters run every control plane service on every control plane node for HA.

Let’s take a look at the services that make up the control plane.

The API server

The API server is the front end of Kubernetes, and all requests to change and query the state of the cluster go through it. Even internal control plane services communicate with each other via the API server.

It exposes a RESTful API over HTTPS, and all requests are subject to authentication and authorization. For example, deploying or updating an app follows this process:

Describe the requirements in a YAML configuration filePost the configuration file to the API serverThe request will be authenticated and authorizedThe updates will be persisted in the cluster storeThe updates will be scheduled to the cluster

The cluster store

The cluster store holds the desired state of all applications and cluster components and is the only stateful part of the control plane.

It’s based on the etcd distributed database, and most Kubernetes clusters run an etcd replica on every control plane node for HA. However, large clusters that experience a high rate of change may run a separate etcd cluster for better performance.

Be aware that a highly available cluster store is not a substitute for backup and recovery. You still need adequate ways to recover the cluster store when things go wrong.

Regarding availability, etcd prefers an odd number of replicas to help avoid split brain conditions. This is where replicas experience communication issues and cannot be sure if they have a quorum (majority).

Figure 2.3 shows two etcd configurations experiencing a network partition. The cluster on the left has four nodes and is experiencing a split brain with two nodes on either side and neither having a majority. The cluster on the right only has three nodes but is not experiencing a split-brain as Node A knows it does not have a majority, whereas Node B and Node C know they do.

Figure 2.3. HA and split brain conditions

If a split-brain occurs, etcd goes into read-only mode preventing updates to the cluster. User applications will continue working, you just won’t be able to make cluster updates, such as adding or modifying apps and services.

As with all distributed databases, consistency of writes is vital. For example, multiple writes to the same value from different sources need to be handled. etcd uses the RAFT consensus algorithm for this.

Controllers and the controller manager

Kubernetes uses controllers to implement a lot of the cluster intelligence. They all run on the control plane, and some of the more common ones include:

The Deployment controller The StatefulSet controllerThe ReplicaSet controller

Others exist, and we’ll cover some of them later in the book. However, they all run as background watch loops, reconciling observed state with desired state.

That’s a lot of jargon, and we’ll cover it in detail later in the chapter. But for now, it means controllers ensure the cluster runs what you asked it to run. For example, if you ask for three replicas of an app, a controller will ensure three healthy replicas are running and take appropriate actions if they aren’t.

Kubernetes also runs a controller manager that is responsible for spawning and managing the individual controllers.

Figure 2.4 gives a high-level overview of the controller manager and controllers.

Figure 2.4. Reconciliation

The scheduler

The scheduler watches the API server for new work tasks and assigns them to healthy worker nodes.

It implements the following process:

Watch the API server for new tasksIdentify capable nodesAssign tasks to nodes

Identifying capable nodes involves predicate checks, filtering, and a ranking algorithm. It checks for taints, affinity and anti-affinity rules, network port availability, and available CPU and memory. It ignores nodes incapable of running the tasks and ranks the remaining ones according to factors such as whether it already has the required image, the amount of available CPU and memory, and number of tasks it’s currently running. Each is worth points, and the nodes with the most points are selected to run the tasks.

The scheduler marks tasks as pending if it can’t find a suitable node.

If the cluster is configured for node autoscaling, the pending task kicks off a cluster autoscaling event that adds a new node and schedules the task to the new node.

The cloud controller manager

If your cluster is on a public cloud, such as AWS, Azure, GCP, or Civo Cloud, it will run a cloud controller manager that integrates the cluster with cloud services, such as instances, load balancers, and storage. For example, if you’re on a cloud and an application requests a load balancer, the cloud controller manager provisions one of the cloud’s load balancers and connects it to your app.

Control Plane summary

The control plane implements the brains of Kubernetes, including the API Server, the scheduler, and the cluster store. It also implements controllers that ensure the cluster runs what we asked it to run.

Figure 2.5 shows a high-level view of a Kubernetes control plane node.

Figure 2.5 - Control plane node

You should run three or five control plane nodes for high availability, and large busy clusters might run a separate etcd cluster for better cluster store performance.

The API server is the Kubernetes frontend, and all communication passes through it.

Worker nodes

Worker nodes are for running user applications and look like Figure 2.6.

Figure 2.6 - Worker node

Let’s look at the major worker node components.

Kubelet

The kubelet is the main Kubernetes agent and handles all communication with the cluster.

It performs the following key tasks:

Watches the API server for new tasksInstructs the appropriate runtime to execute tasksReports the status of tasks to the API server

If a task won’t run, the kubelet reports the problem to the API server and lets the control plane decide what actions to take.

Runtime

Every worker node has one or more runtimes for executing tasks.

Most new Kubernetes clusters pre-install the containerd runtime and use it to execute tasks. These tasks include:

Pulling container imagesManaging lifecycle operations such as starting and stopping containers

Older clusters shipped with the Docker runtime, but this is no longer supported. RedHat OpenShift clusters use the CRI-O runtime. Lots of others exist, and each has its pros and cons.

We’ll use some different runtimes in the Wasm chapter.

Kube-proxy

Every worker node runs a kube-proxy service that implements cluster networking and load balances traffic to tasks running on the node.

Now that you understand the fundamentals of the control plane and worker nodes, let’s switch gears and see how to package applications to run on Kubernetes.

Packaging apps for Kubernetes

Kubernetes runs containers, VMs, Wasm apps, and more. However, they all have to be wrapped in Pods to run on Kubernetes.

We’ll cover Pods shortly, but for now, think of them as a thin wrapper that abstracts different types of tasks so they can run on Kubernetes. The following courier analogy might help.

Couriers allow you to ship books, clothes, food, electrical items, and more, so long as you use their approved packaging and labels. Once you’ve packaged and labeled your goods, you hand them to the courier for delivery. The courier then handles the complex logistics of which planes and trucks to use, secure hand-offs to local delivery hubs, and eventual delivery to the customer. They also provide services for tracking packages, changing delivery details, and attesting successful delivery. All you have to do is package and label the goods.

Running apps on Kubernetes is similar. Kubernetes can run containers, VMs, Wasm apps and more, so long as you wrap them in Pods. Once wrapped in a Pod, you give the app to Kubernetes, and Kubernetes runs it. This includes the complex logistics of choosing appropriate nodes, joining networks, attaching volumes, and more. Kubernetes even lets you query apps and make changes.

Consider a quick example.

You write an app in your favorite language, containerize it, push it to a registry, and wrap it in a Pod. At this point, you can give the Pod to Kubernetes, and Kubernetes will run it. However, most of the time you’ll use a higher-level controller to deploy and manage Pods. To do this, you wrap the Pod inside a controller object such as a Deployment.

Don’t worry about the details yet, we’ll cover everything in a lot more depth and with lots of examples later in the book. Right now, you only need to know two things:

Apps need to be wrapped in Pods to run on KubernetesPods are normally wrapped in higher-level controllers for advanced features

Let’s quickly go back to the courier analogy to help explain the role of controllers.

Most couriers offer additional services such as insurance for the goods you’re shipping, signature and photographic proof of delivery, express delivery services, and more. All of these add value to the service.

Again, Kubernetes is similar. It implements controllers that add value, such as ensuring the health of apps, automatically scaling when demand increases, and more.

Figure 2.7 shows a container wrapped in a Pod, which, in turn, is wrapped in a Deployment. Don’t worry about the YAML configuration yet, it’s just there to seed the idea.

Figure 2.7 - Object nesting

The important thing to understand is that each layer of wrapping adds something:

The container wraps the app and provides dependenciesThe Pod wraps the container so it can run on KubernetesThe Deployment wraps the Pod and adds self-healing, scaling, and more

You post the Deployment (YAML file) to the API server as the desired state of the application, and Kubernetes implements it.

Speaking of desired state…

The declarative model and desired state

The declarative model and desired state are at the core of how Kubernetes operates. They operate on three basic principles:

Observed stateDesired stateReconciliation

Observed state is what you have, desired state is what you want, and reconciliation is the process of keeping observed state in sync with desired state.

Terminology: We use the terms actual state, current state, and observed state to mean the same thing — the most up-to-date view of the cluster.

In Kubernetes, the declarative model works like this:

You describe the desired state of an application in a YAML manifest fileYou post the YAML file to the API serverIt gets recorded in the cluster store as a record of intentA controller notices the observed state of the cluster doesn’t match the new desired stateThe controller makes the necessary changes to reconcile the differencesThe controller keeps running in the background, ensuring observed state matches desired state

Let’s have a closer look.

You write manifest files in YAML that tell Kubernetes what an application should look like. We call this desired state, and it usually includes things such as which images to use, how many replicas, and which network ports.

Once you’ve created the manifest, you post it to the API server where it’s authenticated and authorized. The most common way of posting YAML files to Kubernetes is with the kubectl command-line utility.

Once authenticated and authorized, the configuration is persisted to the cluster store as a record of intent.

At this point, the observed state of the cluster doesn’t match your new desired state. A controller will notice this and begin the process of reconciliation. This will involve making all the changes described in the YAML file and is likely to include scheduling new Pods, pulling images, starting containers, attaching them to networks, and starting application processes.

Once reconciliation is completed, observed state will match desired state, and everything will be OK. However, the controllers keep running in the background, ready to reconcile any future differences.

It’s important to understand that what we’ve described is very different from the traditional imperative model:

The imperative model requires complex scripts of platform-specific commands to achieve an end-stateThe declarative model is a simple platform-agnostic way of describing an end state

Kubernetes supports both but prefers the declarative model. This is because the declarative model integrates with version control systems and enables self-healing, autoscaling, and rolling updates.

Consider a couple of simple declarative examples.

Assume you’ve deployed an app from a YAML file requesting ten replicas. If a node running two of the replicas fails, the observed state will drop to 8 replicas and no longer match the desired state of 10. That’s OK, a controller will see the difference and schedule 2 new replicas to bring the total back up to 10.

The same will happen for an app update. For example, if you update the YAML, telling the app to use an updated image and post the change to Kubernetes, the relevant controller will notice the difference and replace the replicas running the old version with new replicas running the new version.

If you try to perform an update like this imperatively, you’ll need to write complex scripts to manage, monitor, and heath-check the entire update process. To do it declaratively, you only need to change a single line of YAML and Kubernetes does everything else.

This is extremely powerful and fundamental to the way Kubernetes works.

Pods

The atomic unit of scheduling in the VMware world is the virtual machine (VM). In the Docker world, it’s the container. In Kubernetes, it’s the Pod.

Yes, Kubernetes runs containers, VMs, Wasm apps, and more. But they all need to be wrapped in Pods.

Pods and containers

The simplest configurations run a single container per Pod, which is why we sometimes use the terms Pod and container interchangeably. However, there are powerful use cases for multi-container Pods, including:

Service meshesHelper services that initialize app environmentsApps with tightly coupled helper functions such as log scrapers

Figure 2.8 shows a multi-container Pod with a main application container and a service mesh sidecar. Sidecar is jargon for a helper container that runs in the same Pod as the main app container and provides services to it. In Figure 2.8, the service mesh sidecar encrypts network traffic coming in and out of the main app container and provides telemetry.

Figure 2.8 - Multi-container service mesh Pod

Multi-container Pods also help us implement the single responsibility principle where every container performs a single simple task. In Figure 2.8, the main app container might be serving a message queue or some other core application feature. Instead of adding the encryption and telemetry logic into the main app, we keep the app simple and implement it in the service mesh container running alongside it in the same Pod.

Pod anatomy

Each Pod is a shared execution environment for one or more containers. The execution environment includes a network stack, volumes, shared memory, and more.

Containers in a single-container Pod have the execution environment to themselves, whereas containers in a multi-container Pod share it.

As an example, Figure 2.9 shows a multi-container Pod with both containers sharing the Pods IP address. The main application container is accessible outside the Pod on 10.0.10.15:8080, and the sidecar is accessible on 10.0.10.15:5005. If they need to communicate with each other, container-to-container within the Pod, they can use the Pod’s localhost interface.

Figure 2.9

You should choose a multi-container Pod when your application has tightly coupled components needing to share resources such as memory or storage. In most other cases, you should use single-container Pods and loosely couple them over the network.

Pod scheduling

All containers in a Pod are always scheduled to the same node. This is because Pods are a shared execution environment, and you can’t easily share memory, networking, and volumes across nodes.

Starting a Pod is also an atomic operation. This means Kubernetes only ever marks a Pod as running when all its containers are started. For example, if a Pod has two containers and only one is started, the Pod is not ready.

Pods as the unit of scaling

Pods are the minimum unit of scheduling in Kubernetes. As such, scaling an application up adds more Pods and scaling it down deletes Pods. You do not scale by adding more containers to existing Pods. Figure 2.10 shows how to scale the web-fe microservice using Pods as the unit of scaling.

Figure 2.10 - Scaling with Pods

Pod lifecycle

Pods are mortal — they’re created, they live, and they die. Anytime one dies, Kubernetes replaces it with a new one. Even though the new one looks, smells, and feels the same as the old one, it’s always a shiny new one with a new ID and new IP.

This forces you to design applications to be loosely coupled and immune to individual Pod failures.

Pod immutability

Pods are immutable. This means you never change them once they’re running.

For example, if you need to change or update a Pod, you should always replace it with a new one running the updates. You should never log on to a Pod and change it. This means any time we talk about “updating Pods”, we always mean deleting the old one and replacing it with a new one. This can be a huge mindset change for some of us, but it fits nicely with modern tools and GitOps-style workflows.

Deployments

Even though Kubernetes works with Pods, you’ll almost always deploy them via higher-level controllers such as Deployments, StatefulSets, and DaemonSets. These all run on the control plane and operate as background watch loops, reconciling observed state with desired state.

Deployments add self-healing, scaling, rolling updates, and versioned rollbacks to stateless apps.

Refer back to Figure 2.7 to see how Deployments wrap Pods.

Service objects and stable networking

Earlier in the chapter, we said that Pods are mortal and can die. However, if they’re managed by a controller, they get replaced by new Pods with new IDs and new IP addresses. The same thing happens with rollouts and scaling operations:

Rollouts replace old Pods with new ones with new IPs Scaling up adds new Pods with new IPsScaling down deletes existing Pods.

Events like these generate IP churn and make Pods unreliable. For example, clients cannot make reliable connections to individual Pods as the Pods are not guaranteed to be there.

This is where Kubernetes Services come into play by providing reliable networking for groups of Pods.

Figure 2.11 shows internal and external clients connecting to a group of Pods via a Kubernetes Service. The Service (capital “S” because it’s a Kubernetes API object) provides a reliable name and IP and load balances requests to the Pods behind it.

Figure 2.11

You should think of Services as having a front end and a back end. The front end has a DNS name, IP address, and network port. The back end uses labels to load balance traffic across a dynamic set of Pods.

Services keep a list of healthy Pods as scaling events, rollouts, and failures cause Pods to come and go. This means they’ll always load balance traffic across active healthy Pods. The Service also guarantees the name, IP, and port on the front end will never change.

Chapter summary

This chapter introduced you to some of the major Kubernetes features.

Control plane nodes host the control plane services that implement the intelligence of Kubernetes. They can be physical servers, VMs, cloud instances, and more. Production clusters usually run three or five control plane nodes for high availability.

Control plane services include the API server, the scheduler, the cluster store, and controllers.

Worker nodes are for running user applications and can also be physical servers, VMs, cloud instances, and more.

Every worker node runs the kubelet service that watches the API server for new work tasks and reports back on task status.

Worker nodes also have one or more runtimes and the kube-proxy service. Runtimes perform low-level operations such as starting and stopping containers and Wasm apps. The kube-proxy handles all networking tasks on the node.

You learned that Kubernetes supports declarative and imperative methods of deploying and managing apps but prefers the declarative method. This is where you describe your desired state in a YAML configuration file that you give to Kubernetes and leave Kubernetes to deploy and manage it. Controllers run on the control plane and reconcile observed state with desired state.

You also learned about Pods, Deployments, and Services. Pods allow containers and other workloads to run on Kubernetes. Deployments add self-healing, scaling, and rollouts. Services add reliable networking and basic load-balancing.

3: Getting Kubernetes

This chapter shows a couple of ways to get a Kubernetes cluster you can use to follow the hands-on examples throughout the book.

You’ll learn how to:

Create a Kubernetes cluster on your laptop (free)Create a hosted Kubernetes cluster in the cloud (costs money)