Quick Start Kubernetes (Nigel Poulton) (z-library.sk, 1lib.sk, z-lib.sk)

Quick Start Kubernetes 2025 edition Nigel Poulton @nigelpoulton

About this edition This is the 2025 edition, published January 2025. I've updated every example to work with the latest versions of Kubernetes. I've also updated the installation chapter to use the latest Docker Desktop built-in multi-node Kubernets cluster. Enjoy the book and have fun with Kubernetes! Nigel Poulton © 2021 - 2025 Nigel Poulton Ltd All typos are mine. Or should that be typo's... ;-)

About the author Nigel is a technology geek who is passionate about learning new technologies and making them easier for others to learn. He’s the author of best-selling books on Docker and Kubernetes, and is the author of AI Explained: Facts, Fiction, and Future, an exciting read into the impacts of AI on society and the future of humanity. Nigel is a Docker Captain and has held senior technology roles at large and small enterprises. In his free time, he listens to audiobooks and watches science fiction. He wishes he lived in the future and could explore space-time, the universe, and other mind- bending phenomena. He’s passionate about learning, cars, and football (soccer). He lives in England with his fabulous wife and three children. @nigelpoulton nigelpoulton.com/books gsd@nigelpoulton.com

Contents About the book . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Chapter overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 What you’ll learn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Will the book make you a Kubernetes expert . . . . . . . . . . . . . . . . . . 2 Will you know what you’re talking about when you finish the book . . . 2 Editions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Terminology and responsible language . . . . . . . . . . . . . . . . . . . . . . 3 Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 The sample app . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1: What is Kubernetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Microservices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Cloud-native . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Orchestration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Other useful Kubernetes things to know . . . . . . . . . . . . . . . . . . . . . 13 Chapter summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2: Why Kubernetes is so important . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Why the cloud providers need Kubernetes . . . . . . . . . . . . . . . . . . . . 15 Why users need Kubernetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 Chapter Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3: Kubernetes architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Control plane nodes and worker nodes . . . . . . . . . . . . . . . . . . . . . . 20 Hosted Kubernetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 Managing Kubernetes with the kubectl command line tool . . . . . . . . 25 Chapter summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

CONTENTS 4: Getting Kubernetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 Install Docker and kubectl with Docker Desktop . . . . . . . . . . . . . . 27 Create a multi-node Kubernetes cluster with Docker Desktop . . . . . . . 28 Create a multi-node Kubernetes cluster in the Civo Cloud . . . . . . . . . 30 Get the sample app . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 Chapter summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 5: Containerizing an app . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 Pre-requisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 The sample app . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Containerize the app . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41 Share the image on a registry . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Chapter summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 6: Running an app on Kubernetes . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Pre-reqs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Deploy the app to Kubernetes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 Connect to the app . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 Clean-up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Chapter summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 7: Self-healing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 Intro to Kubernetes Deployments . . . . . . . . . . . . . . . . . . . . . . . . . 59 Self-heal from an app failure . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 Self-heal from an infrastructure failure . . . . . . . . . . . . . . . . . . . . . . 64 Chapter summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 8: Scaling the app . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 Pre-requisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 Scale an application up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 Scale an application down . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 Chapter summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75 9: Performing a rolling update . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Pre-requisites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77 Deploy the rollout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 Clean-up . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83 Chapter summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

10: What next . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Books . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 Video courses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Events . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Show some love . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86 Let’s connect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87 Appendix A: Lab code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 Chapter 5: Containerizing an app . . . . . . . . . . . . . . . . . . . . . . . . . 89 Chapter 6: Running an app on Kubernetes . . . . . . . . . . . . . . . . . . . . 90 Chapter 7: Self-healing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 Chapter 8: Scaling the app . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 Chapter 9: Performing a rolling update . . . . . . . . . . . . . . . . . . . . . . 95 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101 More from the author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

About the book This book has two goals: • Get you up-to-speed with Kubernetes fast • Explain everything as clearly as possible I’ve carefully chosen the most important topics and hand-crafted every chapter and example so the book is fun and engaging while you learn. You’ll love the book if you’re in a hands-on role and just getting started with Kubernetes. You’ll also love it if you work in technical marketing, sales, manage- ment, architecture, operations, and more. Chapter overview The book has nine main chapters packed with theory and hands-on demos. • Chapter 1: Introduces you to the concepts and clarifies important jargon • Chapter 2: Explains why Kubernetes is so important • Chapter 3: Gets you up-to-speed with the main components of Kubernetes • Chapter 4: Shows you how to get Kubernetes • Chapter 5: Walks you through containerizing a simple app • Chapter 6: Deploys the containerized app to Kubernetes • Chapter 7: Demonstrates self-healing from various application and infras- tructure failures • Chapter 8: Shows you how to scale an app up and down • Chapter 9: Rounds everything out with a zero-downtime rolling update

2 About the book What you’ll learn You’ll learn why we have Kubernetes, what it is, and where it’s going. On the theory front, you’ll learn about microservices, orchestration, why Kubernetes is the OS of the cloud, and Kubernetes architecture. On the hands- on front, you’ll build a cluster, containerize an app, deploy it, break it, see Kubernetes fix it, scale it, and perform a rolling update. And as this is a quick start guide, you’ll be up-to-speed in no time. Will the book make you a Kubernetes expert No, but it will kickstart you on your journey to becoming an expert. Will you know what you’re talking about when you finish the book Yes, you’ll knowmore than enough to start deploying and managing simple apps on Kubernetes. Editions The following English language editions are available on Amazon and all good book retailers: • Paperback • Ebook Several translations and an audio version are also available.

3 Terminology and responsible language Throughout the book, I capitalize Kubernetes API objects. Wow, we haven’t even started, and I’m throwing jargon around! Put more simply, I spell Kubernetes features, such as Pods and Services, with a capital letter. This helps you know when I’m talking about a Kubernetes “Pod” and not a “pod” of whales. 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 reach me at qskbook@nigelpoulton.com. 1https://inclusivenaming.org

The sample app This is a hands-on book with a sample web app. You can find the app and all supporting files on GitHub at: https://github.com/nigelpoulton/qsk-book/ Don’t stress about the app and GitHub if you’re not a developer. The focus of the book is Kubernetes, and we explain everything as we go. You also don’t need to be a GitHub expert. The code for the app is in the App folder and comprises the following files. • app.js: The main application file • bootstrap.css: Design template for the application’s web page • package.json: List of application dependencies • views: Folder with the contents of the application’s web page • Dockerfile: Tells Docker how to containerize the app If you want to download the app now, run the following command. You’ll need git installed on your machine. Later in the book we’ll show you how to get git and download the app. $ git clone https://github.com/nigelpoulton/qsk-book.git $ cd qsk-book Finally, I update the application and dependencies every year to keep it clean and hopefully free from vulnerabilities.

1: What is Kubernetes Kubernetes is an orchestrator of cloud-native microservices applications. That’s a lot of jargon, so let’s explain the following terms: • Microservices • Cloud-native • Orchestration Microservices In the past, we built and deployed monolithic applications. That’s jargon for complex applications where every feature is developed, deployed, and managed as a single large object. Figure 1.1 shows a monolithic app with six features — web front end, authenti- cation, middleware, logging, data store, and reporting. These are built, deployed, and managed as a single large application, meaning if you need to change any part, you need to change it all.

8 1: What is Kubernetes Figure 1.1 As a quick example, if you need to update the reporting feature, you need to take the entire app down and update the whole thing. This leads to high-risk updates requiring months of advanced planning and implementation over long weekends. However, the pain of monolithic applications doesn’t stop there. If you want to scale a single feature, you have to scale the whole thing. On the flip side, microservices applications take the same set of features and treats each as its own small application. Another word for “small” is “micro”, and another word for “application” is “service”. Hence, the term microservice. If you look closely at Figure 1.2, you’ll see it’s the same application as Figure 1.1. The only difference is that each feature is developed independently, each is deployed independently, and each can be updated and scaled independently. But they work together to create the same application experience. The most common pattern is developing and deploying each microservice as its own container. This way, if you need to scale the reporting service, you just add more reporting containers. If you need to update the reporting service, deploy a new reporting container and delete the old one.

9 Figure 1.2 We loosely couple each microservice over the network, and each one exposes an API that others can consume. These two principles allow us to change individual microservices without affecting others. The following car analogy might help if you’re new to the concept of APIs. Cars come in all shapes and sizes — sports cars, SUVs, trucks, petrol, diesel, electric, hybrid, hydrogen fuel cell, etc. However, these differences are hidden from drivers behind a standard set of controls, including a steering wheel and foot pedals. In this model, the steering wheel and foot pedals are the car’s API — how we consume its capabilities. This means a driver can get into any car in the world and be able to drive it. For example, I learned to drive in a front-wheel-drive petrol-engine car with the steering wheel on the right and a manual gearbox. However, I can step into an all-wheel drive electric car with the steering wheel on the left and be able to drive it without having to learn any new skills. Well, it’s the same with microservices applications. As long as you don’t change a microservice’s API, you can patch or update it without impacting other mi- croservices that consume it. As well as the ability to update and scale individual features, microservices applications lend themselves to smaller and more agile development teams that can deliver faster. It’s common to apply the two-pizza team rule that states that if you can’t feed a development team on two pizzas, the team is too big. However, microservices introduce their own challenges. For example, they can become very complex, with lots of moving parts owned and managed by

10 1: What is Kubernetes different teams. This needs good processes and good communication. Finally, both of these — monolithic and microservices — are called design patterns. The microservices design pattern is the most common pattern in the current cloud era. Cloud-native This is easy, as we’ve covered some of it already. A cloud-native app must: • Self-heal • Scale on demand • Support rolling updates Let’s unpick some of that jargon. Scaling on demand is the ability for applications and associated infrastructure to automatically grow and shrink to meet requirements. For example, an online retail app might need to scale up infrastructure and application resources during holidays. If you configure it correctly, Kubernetes can automatically scale applications and infrastructure according to demand. Not only does this help businesses react more quickly to unexpected changes, it also reduces infrastructure costs by automatically scaling down. Kubernetes can also self-heal applications. You tell Kubernetes what an app should look like, such as how many instances of each microservice. Kubernetes records this as your desired state and watches the app to make sure it always matches desired state. When things change, such as a failed microservice, Kuber- netes observes the failure and spins up a replacement. We call this self-healing or resiliency. Rolling updates is the ability to update parts of an application without taking it offline and impacting consumers. These consumers can be users, external apps, or other microservices that are part of the same app. It’s a game-changer in today’s always-on world, and we’ll see it in action later.

11 One final point. Cloud-native has almost nothing to do with the public cloud. For example, deploying a monolithic application to the cloud does notmake it cloud-native. Whereas deploying an application that self-heals, automatically scales, and does rolling updates to your on-premises datacenter is cloud native. In summary, we call applications cloud-native because they possess the attributes we associate with public clouds — resiliency, elasticity, always on, etc. Orchestration Orchestration can be a difficult concept to understand, but the following sports analogy should help. A football (soccer) team is a group of individual players. Each has a different set of skills and attributes, and each has a different role to play when the game starts. Figure 1.3 shows an unorganized football team without a game plan. Figure 1.3 The coach comes along with the game plan and assigns each player a position and a job. She also dictates how they play the game, such as when to press, how high to press, and how quickly to get the ball forward.