Learn Kubernetes in a Month of Lunches

Elton Stoneman

• Publisher: Manning Publications
• Year: 2021
• ISBN:
  9781617297984
• Topic: Informatique
• Subtopic: Programmation Web

In Learn Kubernetes in a Month of Lunches you'll go from "what's a Pod?" to automatically scaling clusters of containers and components in just 22 hands-on lessons, each short enough to fit into a lunch break. Every lesson is task-focused and covers an essential skill on the road to Kubernetes mastery. You'll learn how to smooth container management with Kubernetes, including securing your clusters, and upgrades and rollbacks with zero downtime. No development stack, platform, or background is assumed. Author Elton Stoneman describes all patterns generically, so you can easily apply them to your applications and port them to other projects!

Week 1. Fast track to Kubernetes

Welcome to Learn Kubernetes in a Month of Lunches. This first section gets you using Kubernetes straight away, focusing on the core concepts: Deployments, Pods, Services, and volumes. You’ll learn how to model your applications using the Kubernetes YAML specification and how Kubernetes provides abstractions over compute, networking, and storage. By the end of the section, you’ll have lots of experience in all the fundamentals, and you’ll have a good understanding of how to model and deploy your own applications.

1 Before you begin

Kubernetes is big. Really big. It was released as an open source project on GitHub in 2014, and now it averages 200 changes every week from a worldwide community of 2,500 contributors. The annual KubeCon conference has grown from 1,000 attendees in 2016 to more than 12,000 at the most recent event, and it’s now a global series with events in America, Europe, and Asia. All the major cloud services offer a managed Kubernetes service, and you can run Kubernetes in a data center or on your laptop—and they’re all the same Kubernetes.

Independence and standardization are the main reasons Kubernetes is so popular. Once you have your apps running nicely in Kubernetes, you can deploy them anywhere, which is attractive for organizations moving to the cloud, because it enables them to move between data centers and other clouds without a rewrite. It’s also very attractive for practitioners—once you’ve mastered Kubernetes, you can move between projects and organizations and be productive quickly.

Getting to that point is hard, though, because Kubernetes is hard. Even simple apps are deployed as multiple components, described in a custom file format that can easily span many hundreds of lines. Kubernetes brings infrastructure-level concerns like load balancing, networking, storage, and compute into app configuration, which might be new concepts, depending on your IT background. In addition, Kubernetes is always expanding-new releases come out every quarter, often bringing a ton of new functionality.

But it’s worth it. I’ve spent many years helping people learn Kubernetes, and a common pattern arises: the question “Why is this so complicated?” transforms to “You can do that? This is amazing!” Kubernetes truly is an amazing piece of technology. The more you learn about it, the more you’ll love it—and this book will accelerate you on your journey to Kubernetes mastery.

1.1 Understanding Kubernetes

This book provides a hands-on introduction to Kubernetes. Every chapter offers try-it-now exercises and labs for you to get lots of experience using Kubernetes. All except this one. :) We’ll jump into the practical work in the next chapter, but we need a little theory first. Let’s start by understanding what Kubernetes actually is and the problems it solves.

Kubernetes is a platform for running containers. It takes care of starting your containerized applications, rolling out updates, maintaining service levels, scaling to meet demand, securing access, and much more. The two core concepts in Kubernetes are the API, which you use to define your applications, and the cluster, which runs your applications. A cluster is a set of individual servers that have all been configured with a container runtime like Docker, and then joined into a single logical unit with Kubernetes. Figure 1.1 shows a high-level view of the cluster.

Figure 1.1 A Kubernetes cluster is a bunch of servers, which can run containers, joined into a group.

Cluster administrators manage the individual servers, called nodes in Kubernetes. You can add nodes to expand the capacity of the cluster, take nodes offline for servicing, or roll out an upgrade of Kubernetes across the cluster. In a managed service like Microsoft Azure Kubernetes Service (AKS) or Amazon Elastic Kubernetes Service (EKS), those functions are all wrapped in simple web interfaces or command lines. In normal usage you forget about the underlying nodes and treat the cluster as a single entity.

The Kubernetes cluster is there to run your applications. You define your apps in YAML files and send those files to the Kubernetes API. Kubernetes looks at what you’re asking for in the YAML and compares it to what’s already running in the cluster. It makes any changes it needs to get to the desired state, which could be updating a configuration, removing containers, or creating new containers. Containers are distributed around the cluster for high availability, and they can all communicate over virtual networks managed by Kubernetes. Figure 1.2 shows the deployment process, but without the nodes because we don’t really care about them at this level.

Figure 1.2 When you deploy apps to a Kubernetes cluster, you can usually ignore the actual nodes.

Defining the structure of the application is your job, but running and managing everything is down to Kubernetes. If a node in the cluster goes offline and takes some containers with it, Kubernetes sees that and starts replacement containers on other nodes. If an application container becomes unhealthy, Kubernetes can restart it. If a component is under stress because of a high load, Kubernetes can start extra copies of the component in new containers. If you put the work into your Docker images and Kubernetes YAML files, you’ll get a self-healing app that runs in the same way on any Kubernetes cluster.

Kubernetes manages more than just containers, which is what makes it a complete application platform. The cluster has a distributed database, and you can use that to store both configuration files for your applications and secrets like API keys and connection credentials. Kubernetes delivers these seamlessly to your containers, which lets you use the same container images in every environment and apply the correct configuration from the cluster. Kubernetes also provides storage, so your applications can maintain data outside of containers, giving you high availability for stateful apps. Kubernetes also manages network traffic coming into the cluster by sending it to the right containers for processing. Figure 1.3 shows those other resources, which are the main features of Kubernetes.

Figure 1.3 There’s more to Kubernetes than just containers—the cluster manages other resources, too.

I haven’t talked about what those applications in the containers look like; that’s because Kubernetes doesn’t really care. You can run a new application built with cloud-native design across microservices in multiple containers. You can run a legacy application built as a monolith in one big container. They could be Linux apps or Windows apps. You define all types of applications in YAML files using the same API, and you can run them all on a single cluster. The joy of working with Kubernetes is that it adds a layer of consistency on top of all your apps—old .NET and Java monoliths and new Node.js and Go microservices are all described, deployed, and managed in the same way.

That’s just about all the theory we need to get started with Kubernetes, but before we go any further, I want to put some proper names on the concepts I’ve been talking about. Those YAML files are properly called application manifests, because they’re a list of all the components that go into shipping the app. Those components are Kubernetes resources; they have proper names, too. Figure 1.4 takes the concepts from figure 1.3 and applies the correct Kubernetes resource names.

Figure 1.4 The true picture: these are the most basic Kubernetes resources you need to master.

I told you Kubernetes was hard. :) But we will cover all of these resources one at a time over the next few chapters, layering on the understanding. By the time you’ve finished chapter 6, that diagram will make complete sense, and you’ll have had lots of experience in defining those resources in YAML files and running them in your own Kubernetes cluster.

1.2 Is this book for you?

The goal of this book is to fast-track your Kubernetes learning to the point where you have confidence defining and running your own apps in Kubernetes, and you understand what the path to production looks like. The best way to learn Kubernetes is to practice, and if you follow all the examples in the chapters and work through the labs, then you’ll have a solid understanding of all the most important pieces of Kubernetes by the time you finish the book.

But Kubernetes is a huge topic, and I won’t be covering everything. The biggest gaps are in administration. I won’t cover cluster setup and management in any depth, because they vary across different infrastructures. If you’re planning on running Kubernetes in the cloud as your production environment, then a lot of those concerns are taken care of in a managed service anyway. If you want to get a Kubernetes certification, this book is a great place to start, but it won’t get you all the way. There are two main Kubernetes certifications: Certified Kubernetes Application Deve...