The Kubernetes Book (Nigel Poulton) (z-library.sk, 1lib.sk, z-lib.sk)

The Kubernetes Book February 2025 Weapons-grade Kubernetes learning Nigel Poulton @nigelpoulton

About this edition This edition was published in February 2025. 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 also tested and updated every hands-on example to work with Kubernetes v1.32. Enjoy the book and get ready to master Kubernetes! Nigel Poulton (c) 2025 Nigel Poulton Ltd. @nigelpoulton nigelpoulton.com/books tkb@nigelpoulton.com

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 want to thank Pushkar for his contributions to Chapters 16 and 17. Pushkar ap- proached me at a KubeCon and asked if he could contribute content on real-world security. Collaborating on content wasn’t something I’d done previously, and I tried to tell him “no thanks” (I’m disorganized and can be hard to work with). However, Pushkar was keen, so we made it happen. To be clear, the technical content for the security chapters is Pushkar’s. I just tweaked the writing style to ensure the book has a consistent feel. Author: Nigel Poulton Nigel is a technology geek who spends his life creating books, training videos, and on- line hands-on training. 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. Nigel is a Docker Captain and always playing with new technology – his latest interest is cloud native WebAssembly (Wasm). In the past, Nigel has held various senior infrastructure roles at large enterprises. 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, the universe, and other mind-blowing stuff. He likes cars, football (soccer), and learning. He lives in England with his fabulous wife and three children. Contributing author: Pushkar Joglekar Pushkar contributed the technical content for Chapters 16 and 17. Pushkar is a Sr. Cloud Security Engineer II, leading organization-wide security programs for a multi-billion dollar Fintech Company. He is also a Kubernetes Project Maintainer and was a Technical Security Lead for VMware Tanzu prior to his current role. Before that, he built multiple “secure by design” production container deployments for a Fortune 500 company and has been a frequent speaker at KubeCon. When not securing containers, he explores neighborhood bike trails and captures beautiful sunsets through his camera while sipping homemade masala ginger chai. He lives with his wonderful wife, who is the real engineer among them.

Contents 0: Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Paperbacks, hardbacks, eBooks, audio, and translations . . . . . . . . . . . . . . . . 1 The sample app and GitHub repo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Windows users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Terminology and responsible language . . . . . . . . . . . . . . . . . . . . . . . . . . 3 Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1: Kubernetes primer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Important Kubernetes background . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Kubernetes: the operating system of the cloud . . . . . . . . . . . . . . . . . . . . . 10 Chapter summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2: Kubernetes principles of operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Kubernetes from 40K feet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Control plane and worker nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Packaging apps for Kubernetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 The declarative model and desired state . . . . . . . . . . . . . . . . . . . . . . . . . 23 Pods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 Deployments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Service objects and stable networking . . . . . . . . . . . . . . . . . . . . . . . . . . 28 Chapter summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3: Getting Kubernetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 Install everything with Docker Desktop . . . . . . . . . . . . . . . . . . . . . . . . . 31 Build a Linode Kubernetes Engine (LKE) cluster in the Linode Cloud . . . . . . . 35 Build a Kubernetes cluster in the Linode Cloud . . . . . . . . . . . . . . . . . . . . . 35 Configure kubectl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Test your LKE cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 More about kubectl and your kubeconfig file . . . . . . . . . . . . . . . . . . . . . 39 Chapter summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 4: Working with Pods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 Pod theory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

CONTENTS Multi-container Pods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Hands-on with Pods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 Clean up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 5: Virtual clusters with Namespaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 Intro to Namespaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73 Namespace use cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 Default Namespaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 Creating and managing Namespaces . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 Deploying objects to Namespaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Clean up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 6: Kubernetes Deployments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 Deployment theory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 Create a Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 Manually scale the app . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 Perform a rolling update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 Perform a rollback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 Clean up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 Chapter summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104 7: Kubernetes Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Service Theory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 Hands-on with Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114 Clean up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121 8: Ingress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 Setting the Scene for Ingress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123 Ingress architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124 Hands-on with Ingress . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125 Clean up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 Chapter summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137 9: Wasm on Kubernetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139 Wasm Primer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140 Understanding Wasm on Kubernetes . . . . . . . . . . . . . . . . . . . . . . . . . . . 143 Hands-on with Wasm on Kubernetes . . . . . . . . . . . . . . . . . . . . . . . . . . . 146 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157 10: Service discovery deep dive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159 Setting the scene . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

The service registry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161 Service registration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 Service discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 Service discovery and Namespaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167 Troubleshooting service discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173 Clean up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 Chapter summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175 11: Kubernetes storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 The big picture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177 Storage Providers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179 The Container Storage Interface (CSI) . . . . . . . . . . . . . . . . . . . . . . . . . . 180 The Kubernetes persistent volume subsystem . . . . . . . . . . . . . . . . . . . . . . 180 Dynamic provisioning with Storage Classes . . . . . . . . . . . . . . . . . . . . . . . 181 Hands-on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185 Clean up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194 12: ConfigMaps and Secrets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195 The big picture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196 ConfigMap theory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197 Hands-on with ConfigMaps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200 Hands-on with Secrets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211 Clean up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217 13: StatefulSets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 StatefulSet theory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219 Hands-on with StatefulSets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224 Clean up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238 14: API security and RBAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 API security big picture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239 Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240 Authorization (RBAC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242 Admission control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251 Chapter summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252 15: The Kubernetes API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 Kubernetes API big picture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 The API server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257 The API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 Chapter summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276

CONTENTS 16: Threat modeling Kubernetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 Threat modeling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 Spoofing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279 Tampering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282 Repudiation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284 Information Disclosure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286 Denial of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 287 Elevation of privilege . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291 Chapter summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 303 17: Real-world Kubernetes security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305 Security in the software delivery pipeline . . . . . . . . . . . . . . . . . . . . . . . . 305 Workload isolation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311 Identity and access management (IAM) . . . . . . . . . . . . . . . . . . . . . . . . . . 316 Security monitoring and auditing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317 Real-world example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321 Chapter summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 321 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323

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 ensuring this remains 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. Unfortu- nately, a two-year-old book on Kubernetes could be dangerously out of date. Paperbacks, hardbacks, eBooks, audio, and translations This 2025 edition is published in all of the following formats: • Paperback • Hardback • eBook eBook copies are available on Kindle, Leanpub, and various other sources. I recommend Leanpub, as I publish there first, and you get free lifetime updates that work. Various translations are also available but sometimes lag behind the English language editions. I’ve also created the following collector’s editions. Each has a themed front cover, but the content is exactly the same as the regular English-language edition. • Starfleet paperback • Borg hardback • Klingon paperback Kindle updates Unfortunately, Kindle readers cannot get updates — even if you delete the book and buy it again, you’ll still get the older version you originally purchased. I have no control over this and was devastated when Amazon introduced this change. Feel free to contact me at tkb@nigelpoulton.com and I’ll do my best to help.

2 0: Preface The sample app and GitHub repo There’s a GitHub repo with all the app files and YAML code used throughout the book. To follow the examples, you’ll need to install git, clone the repo, and switch to the 2025 branch. And don’t worry if that sounds confusing. You don’t need to be a GitHub expert, as I’ll always show you the commands you need to run. Install got onto your computer. The easiest way is to search the web for git installation instructions and follow them for your platform (Linux/Mac/Windows…). Once you’ve installed git, you can clone the repo and switch branches. Run the following command to clone the repo. It creates a new directory called TKB and copies all the files and folders. $ git clone https://github.com/nigelpoulton/TKB.git Change into the new TKB directory and switch to the 2025 branch. $ cd TKB $ git fetch origin $ git checkout -b 2025 origin/2025 Congratulations. You’ve cloned the book’sGitHub repo and switched to the 2025 branch. Windows users Most of the commands in the hands-on sections work on Linux, Mac, and Windows. However, a few of them require minor changes to work on Windows. Whenever this happens, I explain what you need to do. However, to prevent myself from repeating the same thing too often, I don’t always tell Windows users to replace backslashes with backticks for line breaks. 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 line • Replace the backslashes with backticks All other differences are explained in full every time.

3 Terminology and responsible language Throughout the book, I capitalize the first letter of Kubernetes objects such as Pods and Services. This helps you know when I’m talking about a Kubernetes “LoadBalancer” and not a cloud “load balancer”. The book also follows guidelines from the Inclusive Naming Initiative1, which promotes responsible language. Feedback If you like the book and it helps your career, share the love by recommending it to a friend and leaving a review on Amazon, Goodreads, or wherever you buy your books. For other feedback, you can email me at tkb@nigelpoulton.com or reach me on any of the following. 1https://inclusivenaming.org

1: Kubernetes primer This chapter gets you up-to-speed with the basics and background of Kubernetes, and I’ve divided it as follows: • Important Kubernetes background • Kubernetes: the Operating System of the cloud Important Kubernetes background Kubernetes is an orchestrator of containerized cloud-native microservices applications. That’s a lot of jargon, so let’s explain it. Orchestration An orchestrator is a system that deploys applications and dynamically responds to changes. For example, Kubernetes can: • Deploy applications • Scale them up and down based on demand • Self-heal them when things break • Perform rollouts and rollbacks • Lots more The best part is that it does all of this without you having to get involved. You need to configure a few things up front, but once you’ve done that, you sit back and let Kubernetes work its magic. Containerization Containerization is the process of packaging applications and dependencies as images and then running them as containers.

6 1: Kubernetes primer 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 entirely replaced VMs, and you’ll see them running side-by-side in most environments. But 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 notmake 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-end • Catalog • Shopping cart • Authentication • Logging • Store To make this a microservices app, you design, develop, deploy, and manage each feature as its own small application that we call a microservice. As such, this application has six microservices. Designing like this 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 revisit and rewrite that jargon-filled sentence from the start of the chapter.

7 The original sentence read; “Kubernetes is an orchestrator of containerized cloud-native microservices applications.” We now know this means: Kubernetes deploys, scales, self-heals, and updates applications where individual application features are packaged and deployed as containers. Hopefully, that’s clarified some of the jargon. But don’t worry if some of it still feels fuzzy, we’ll cover everything again in 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 the rest of the industry 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 andmake it as easy as possible for customers to get off AWS and onto their cloud. They also ran their own 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. This led a group of Google engineers to take the lessons they’d learned using their internal container management tools and create a new tool called Kubernetes. In 2014, they open-sourced Kubernetes and donated it to the newly formed Cloud Native Computing Foundation (CNCF)2. At the time of writing, Kubernetes is over 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: 1. It abstracts infrastructure (such as AWS) 2. It simplifies applications portability These are two of the biggest reasons Kubernetes is important to the industry. 2https://www.cncf.io

8 1: Kubernetes primer Kubernetes and Docker All the early versions of Kubernetes shipped with Docker as its container runtime. This means Kubernetes used Docker for low-level tasks such as creating, starting, and stopping containers. However, two things happened: 1. Docker got bloated 2. People 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 now pick and choose the best runtimes for your needs. For example, some runtimes provide better isolation, some provide better performance, some work with Wasm containers, and more. 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, that 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)3 standards. Figure 1.2 shows a four-node Kubernetes cluster running multiple container runtimes. Figure 1.2 - Single cluster with multiple runtimes 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 9 when you deploy a Wasm (WebAssembly) app to Kubernetes. 3https://opencontainers.org

9 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 is still being developed and is still used by small companies needing 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, they had two in-house tools called Borg and Omega orchestrating these billions of containers. 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.32 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.

10 1: Kubernetes primer The word Kubernetes originates from the Greek word for helmsman which is 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. This is because Google’s Borg project inspired Kubernetes, and a famous Borg drone from the TV series Star Trek Voyager is called Seven of Nine. Copyright laws didn’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 it 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 processes • Kubernetes abstracts cloud resources and schedules application microservices As a quick example, you can schedule applications on Kubernetes without caring if they’re running on AWS, Azure, Civo Cloud, GCP, or your on-premises data center. This makes Kubernetes a key enabler for: • Hybrid cloud • Multi-cloud • Cloud migrations In summary, Kubernetes makes it easier to deploy to one cloud today and migrate to another cloud tomorrow.

11 Application scheduling One of the main things an OS does is simplify the scheduling of work tasks. For example, computers are complex collections of hardware resources such as CPU, memory, storage, and networking. Thankfully, modern operating systems hide most of this, making 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 let the OS decide. Kubernetes does a similar thing with clouds and data centers. At a high level, a cloud or data center is a complex collection of resources and services. Kubernetes abstracts most of this, making the resources easier to consume. Again, how often do you care which compute node, which failure zone, or which storage volume your app uses? Most of the time, you’ll be happy to let Kubernetes decide. Chapter summary Kubernetes was created by Google engineers based on lessons learned running contain- ers at hyper-scale for many years. They donated it to the community as an open-source project and it is now the industry standard platform for deploying and managing cloud- native applications. It runs on any cloud or on-premises data center 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: • LinkedIn: linkedin.com/in/nigelpoulton/ • BlueSky: @nigelpoulton.com • X: @nigelpoulton • Web: nigelpoulton.com • Email: tkb@nigelpoulton.com