Quick Start Kubernetes (Nigel Poulton)(Z-Library)
code
No Description
192
Views
0
Downloads
0.00
Total Donations
Registered users can read the full content for free
Register as a Gaohf Library member to read the complete e-book online for free and enjoy a better reading experience.
Page
1
(This page has no text content)
Page
2
Quick Start Kubernetes 2025 edition Nigel Poulton @nigelpoulton
Page
3
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... ;-)
Page
4
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
Page
5
(This page has no text content)
Page
6
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
Page
7
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
Page
8
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
Page
9
(This page has no text content)
Page
10
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
Page
11
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.
Page
12
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
Page
13
(This page has no text content)
Page
14
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.
Page
15
(This page has no text content)
Page
16
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.
Page
17
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.
Page
18
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
Page
19
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.
Page
20
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.
The above is a preview of the first 20 pages. Register to read the complete e-book.
AI Reading Assistant
Whole-book reading guide from stratified index samples; jump to passages in the text
AI guide
【One-Line Pitch】
A hands-on, no-nonsense introduction to Kubernetes for beginners who want to get a cluster running, deploy a containerized app, and learn the core concepts of orchestration—self-healing, scaling, and rolling updates—without getting lost in theory.
【Book Arc】
- **Opening (~0%–4%)**: Sets expectations for the 2025 edition, outlines what you'll learn (microservices, orchestration, Kubernetes as the "OS of the cloud"), and maps the hands-on journey: build a cluster, containerize an app, deploy it, break it, fix it, scale it, and update it.
- **Early (~4%–14%)**: Introduces the "why" of Kubernetes—cloud-native microservices need an orchestrator. Uses the football team analogy to explain how Kubernetes organizes independent microservices into a coherent app, and covers key concepts like self-healing, scaling on demand, and rolling updates.
- **Early (~14%–25%)**: Explains Kubernetes' origins (Google's Borg/Omega) and its architecture: control plane nodes (API server, scheduler, store, cloud controller) vs. worker nodes. Covers hosted Kubernetes services (EKS, AKS, GKE, etc.) and the division of responsibility between you and the cloud provider.
- **Early (~25%–36%)**: Gets you up and running. Covers installing Docker Desktop (with built-in multi-node Kubernetes) or creating a cluster on Civo Cloud, verifying nodes with `kubectl get nodes`, and downloading the sample app from GitHub.
- **Middle (~36%–50%)**: Walks through containerizing the sample Node.js app with a Dockerfile, building and pushing the image to Docker Hub, then deploying it to Kubernetes as a Pod using `kubectl apply`. Explains how to inspect Pods with `kubectl get` and `kubectl describe`.
- **Middle (~50%–end)**: Connects the app to the outside world with a LoadBalancer Service, then moves into operational topics: self-healing with Deployments (recovering from app and infrastructure failures), scaling up/down, and performing rolling updates without downtime.
【Key Takeaways】
- **Kubernetes is an orchestrator for cloud-native microservices** (Early): It runs and manages apps made of small, specialized parts that can self-heal, scale, and be updated independently. Think of it as the "OS of the cloud" that organizes messy microservices into useful applications.
- **Cloud-native apps must self-heal, scale on demand, and support rolling updates** (Early): These are the three core capabilities Kubernetes provides. Self-healing means Kubernetes constantly compares actual state to your desired state and fixes drift; scaling means growing/shrinking resources automatically based on demand; rolling updates let you change parts of an app without downtime.
- **A cluster has two node types: control plane and worker** (Early): Control plane nodes run Kubernetes system services (API server, scheduler, cluster store, cloud controller), while worker nodes run your user applications. Best practice: keep apps off control plane nodes. You're usually responsible for worker nodes, user apps, and the bill on hosted platforms.
- **Docker Desktop is the fastest way to get a multi-node cluster locally** (Early): Version 4.38+ includes a built-in multi-node Kubernetes cluster (enable the "kind" option, not the older single-node one). Verify with `kubectl get nodes`—you should see one control-plane and two worker nodes.
- **Containerizing an app is straightforward with a Dockerfile** (Middle): The sample app uses a simple Dockerfile: pull a Node base image, copy app files, set working directory, run `npm install`, expose port 8080, and define the start command. Build with `docker build`, then push to a registry like Docker Hub with `docker push`.
- **Deploying to Kubernetes is declarative, not imperative** (Middle): You write YAML files (e.g., `pod.yml`) that describe the desired state, then run `kubectl apply -f`. The API server authenticates/authorizes the request, stores the definition, and the scheduler places the Pod on a worker node. Inspect with `kubectl get pods` and `kubectl describe pod`.
- **Services connect Pods to the network** (Middle): A LoadBalancer Service (like `svc-lb`) accepts traffic on an external port (e.g., 5555) and forwards it to Pods matching a label selector (e.g., `project=qsk-book`) on their container port (8080). On cloud clusters, this provisions an internet-facing load balancer; on Docker Desktop, it's accessible via localhost.
【Reading Tips】
- **Skim the theory chapters (1–3) if you're in a hurry**: The football team analogy and architecture overview are useful context, but the real value is in the hands-on chapters. If you already know what microservices are, jump to Chapter 4.
- **Follow along with the sample app**: Don't just read—clone the `qsk-book` repo, build the image, and deploy it. The book is designed for active learning, and the examples are updated for 2025 Kubernetes versions.
- **Use Docker Desktop for local practice, Civo for cloud experience**: Docker Desktop's built-in multi-node cluster is free and fast for local experimentation. If you want to see how a real cloud load balancer works, use Civo (the book includes a $500 credit link).
- **Pay attention to the YAML files**: The Pod and Service definitions are the core artifacts. Understand the structure: `apiVersion`, `kind`, `metadata`, and `spec`. The Service's `selector` is the glue that connects traffic to your Pods—this is a common source of confusion.
- **Don't skip the "break it" exercises**: The self-healing chapter has you intentionally kill a Pod or fail a node to watch Kubernetes recover. This is the best way to internalize the desired-state model.
【Coverage Limits】
This guide covers the book's opening through the Service deployment (~50% of the book). The later chapters on self-healing, scaling, and rolling updates are summarized conceptually but not detailed step-by-step, as the excerpts do not include their full content.
Passage locations
Page 7
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 Chapter summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 7: Se...
View in text
Excerpt 2
, Kubernetes is not an open-source version of Borg or Omega. It’s a new project, built from scratch. Its only connection to Borg and Omega is that its origin...
View in text
Excerpt 3
cluster is ready, but you still need to configure kubectl. Configure kubectl to talk to your Civo Cloud Kubernetes cluster kubectl uses a config file to know...
View in text
Excerpt 4
cation. The metadata block gives the Pod a name and a label. We’ll use the name later to help us identify the Pod when it’s running, and we’ll use the label...
View in text
Recommended for You
{{#thumbnailUrl}}
{{/thumbnailUrl}}
{{^thumbnailUrl}}
{{/thumbnailUrl}}
Loading recommended books...
Failed to load, please try again later
Tip the Site
Scan the WeChat Pay or Alipay code to tip. No login required.
WeChat Pay
Alipay