Learn Kubernetes & Docker - .NET Core, Java, Node.JS, PHP or Python

Learn Kubernetes & Docker - .NET Core, Java, Node.JS, PHP or Python

Be ready to create and run your containerized and orchestrated application next week.

Arnaud Weil

© 2018 - 2020 Arnaud Weil

To my parents, for teaching me freedom and making sure I can enjoy it.

To my wonderful family. Your love and support fueled this book.

To my readers who suggested improvements to this book, especially Doğan Kartaltepe for your ongoing and dedicated support.

Table of Contents

Introduction

What this book is not

Prerequisites

How to read this book

Tools you need

Source code

1. Why Docker?

1.1 A DevOps enabler tool

1.2 It solves dependency conflicts

1.3 It allows for easy scaling up

1.4 It allows for seamless upgrades

1.5 International commerce already uses containers

2. Why Kubernetes?

2.1 The need for container orchestration

2.2 What’s K8s?

3. Get Docker up and running

3.1 Various products for various needs

3.2 Community on a developer or CI machine

3.3 Enterprise on a Server

4. Basic concepts

5. Use Docker images

5.1 Do-it-yourself: run a container

5.2 Container management commands

5.3 Do-it-yourself: post-mortem inspection

5.4 More about docker run

5.5 Running a server container

5.6 Exercise - Run a server container

5.7 Exercise solution

5.8 Using volumes

5.9 Where do images come from?

6. Create Docker images

6.1 Creating a simple image

6.2 Creating an image including files

6.3 Images are created locally

6.4 Exercise - Build an image and run it

6.5 Exercise solution

6.6 Tags matter

6.7 Parameters as environment variables

6.8 Exercise - Enable an image to be parameterized

6.9 Exercise solution

6.10 Storage

6.11 Networking

6.12 Learning more

7. Publish Docker images

7.1 Rationale for publishing

7.2 Registries

7.3 Publishing an image

7.4 Docker Hub

7.5 Run an image on another machine

7.6 Exercise - Publish an image and run a container on another machine

7.7 Exercise solution

7.8 Private registries

7.9 Size matters

8. Forget SDK installs

8.1 One tool to rule them all

8.2 Building rationally: easy CI

8.3 Multi-stage dockerfiles

9. Docker with common development profiles

9.1 .NET Core

9.2 Java

9.3 Node.JS

9.4 PHP

9.5 Python

10. Kubernetes cluster

10.1 Parts of a Kubernetes cluster

10.2 Creating a cluster

10.3 Exercise - Set up your development cluster

10.4 Exercise solution

10.5 Connecting to a cluster

11. Tooling

11.1 Kubernetes Dashboard

11.2 Visual Studio Code

11.3 Helm

12. Running pods

12.1 Deployments and ReplicaSets

12.2 Imperative commands

12.3 Exercise - Use imperative commands

12.4 Exercise solution

12.5 Exercise - Observe Kubernetes handle a failing pod

12.6 Exercise solution

12.7 Declarative commands

12.8 Exercise - Create resources using declarative commands

12.9 Exercise solution

12.10 Exercise - Update a Pod created declaratively

12.11 Exercise solution

12.12 Debugging

12.13 Exercise - Debugging failing Pods

12.14 Exercise solution

12.15 Exercise - Delete created objects

12.16 Exercise solution

12.17 Resources management

13. Exposing services

13.1 The need for services

13.2 Services

13.3 Exercise - Expose a web application to the internet

13.4 Exercise solution

13.5 Exercise - Expose an API inside the cluster

13.6 Exercise solution

13.7 Ingress

14. Volumes

14.1 The need for volumes

14.2 Short-lived storage with Volumes

14.3 Exercise - Create and use a Volume

14.4 Exercise solution

14.5 Persistent storage with PersistentVolumeClaims

14.6 Exercise - Create and use a PersistentVolume

14.7 Exercise solution

15. Configuration

15.1 Similar but different

15.2 ConfigMap

15.3 Exercise - Create and use a ConfigMap

15.4 Exercise solution

15.5 Secret

15.6 Exercise - Create and use a Secret

15.7 Exercise solution

16. Updating and scaling

16.1 Horizontal scaling

16.2 Automatic horizontal scaling

16.3 Update strategies

17. Sharing a cluster

17.1 Namespaces

17.2 RBAC

18. Helm

18.1 Using Helm

18.2 Creating Helm packages (charts)

A word from the author

Image attributions

The Learn collection

Introduction

What this book is not

I made my best to keep this book small, so that you can learn both Kubernetes and Docker quickly without getting lost in petty details. If you are looking for a reference book where you’ll find answers to all the questions you may have within the next 4 years of your Kubernetes and Docker practice, you’ll find other heavy books for that.

My purpose is to swiftly provide you with the tools you need to create and run your first containerized application using Docker, make it cloud-ready using Kubernetes, then be able to look for more by yourself when needed. While some authors seem to pride themselves in having the thickest book, in this series I’m glad I achieved the thinnest possible book for my purpose. Though I tried my best to keep all of what seems necessary, based on my 16 years experience of teaching.

Prerequisites

This book is for anyone who needs to run software on Kubernetes. Whether you’re a developer, a DevOps manager or a technician, this book should help you run Docker containers then run them as Kubernetes workloads.

I assume that you have no previous knowledge about containers or containers orchestration.

How to read this book

This book’s aim is to make you productive as quickly as possible. For this we’ll use some theory, several demonstrations, plus exercises. Exercises appear like the following:

Do it yourself: Time to grab your keyboard and code away to meet the given objectives.

In code samples, a backslash is used in order to wrap long lines. Do not type theses backslashes when you copy code from the book.

Tools you need

The only tools you’ll need to work through this book are the following:

A Windows, Linux or Mac machine that meets the specifications for Docker Desktop or Minikube, or the ability to create a PaaS cluster (Azure AKS, Google GKE, Amazon EKS).

A text editor.

Source code

All of the source code for the demos and do-it-yourself solutions is available at https://bitbucket.org/epobb/kubernetesdockerbookfiles

It can be downloaded as a ZIP file, or if you installed GIT you can simply type:

git clone https://bitbucket.org/epobb/kubernetesdockerb\

ookfiles.git

1. Why Docker?

If you’re in a hurry, you can safely skip this chapter and head straight to the Get Docker up and running chapter. This Why Docker? chapter is there for those that want to know why containers should be used.

1.1 A DevOps enabler tool

Docker is an engine that runs containers, and containers as a tool allow to solve many challenges created by the growing DevOps trend.

In DevOps, the Dev and Ops teams have conflicting goals:

As an agile developer I want to frequently publish my applications so that deployment becomes a routine. The rationale behind this is that this agility makes the go to production event a normal, frequent, completely mastered event instead of a dreaded disaster that may awake monsters who will hit me one week later. On the other hand, it is the Ops team that will have to face the user if anything goes wrong in deployment - so they naturally want stability.

Containers ease deployment because deploying is as simple as running a new container, routing users to the new one, and trashing the old one. It can even be automated by orchestration tools, and since it’s dead easy we can afford to have many containers serving a single application for increased stability during updates.

If you don’t use containers, Ops need to handle your hosting environment: runtimes, libraries, OS needed by your application. On the other side, when using containers they just need one single methodology that can handle the containers you provide no matter what’s inside them. You may as well use .NET Core, Java, Node.JS, PHP, Python or another development tool: it doesn’t matter to them as long as your code is containerized. This is a huge advantage for containers when it comes to DevOps.

In the Docker with common development profiles chapter we’ll see how to create container images for specific development technologies. But your Ops don’t see how you create the images, they just see container images.

1.2 It solves dependency conflicts

A typical web application looks something like the following:

The application is made of files served by an HTTP server (Apache here, but it could be Kestrel, IIS, NGINX, …), a runtime (PHP 5.6 here) and a development framework (Wordpress 4.9 here).

Without containers, the dependencies and files are all placed together on a server. Since managing those dependencies is time-consuming, similar apps are typically grouped on the same server, sharing their dependencies:

Now suppose you want to upgrade the PHP runtime from version 5.6 to 7.2. But the version change induces breaking changes in the applications that hence need to be updated. You need to update both App 1 and App 2 when proceeding with the upgrade. On a server that may host many apps of this type, this is going to be a daunting task and you’ll need to delay the upgrade until all apps are ready.

Another similar problem is when you want to host say App 3 on the same server, but App 3 uses the Node.JS runtime together with a package that when installed changes a dependency that is used by the PHP runtime. Conflicts between runtimes are not scarce, so you probably faced that problem already.

Containers solve this problem because each app is going to run inside its own container with its own dependencies. Your typical server would look like:

Each container encapsulates its own dependencies. Which means you can migrate the PHP runtime from version 5.6 to 7.2 in a container without affecting other. Any other container that would use, e.g., Node.JS would not interfere with any of the Wordpress containers.

1.3 It allows for easy scaling up

When a server application needs to handle a higher usage than what a single server can handle, the solution is well-known: place a reverse proxy in front of it, and duplicate the server as many times as needed. In our previous Wordpress application example, this means duplicating the server together with all of its dependencies:

That is only going to make things worse when upgrading: we’ll need to upgrade each server’s dependencies, together with all of the conflicts that may induce.

Again, containers have a solution for this. As we’ll see in the Basic concepts section, containers are based on images. You simply need to run as many containers as you wish from a single image, and they will all sport the exact same dependencies.

Better yet: when using an orchestrator you simply need to state how many containers you want, the image name, and the orchestrator will create that many containers on all of your Docker servers. We’ll see this in the orchestrators part. This is how it looks:

1.4 It allows for seamless upgrades

Even in scaled-up scenarios, a container-based approach makes trivial a concept that would otherwise be tricky. Without containers, your favorite admin will not be happy with you if he has to update every server including the dependencies:

Of course, in such a case the update process will depend on the application and its dependencies. Don’t even try to tell your admins about DevOps if you want to remain alive.

By using containers, it’s a simple matter of telling the orchestrator that you want to run a new image version, and it will gradually replace every container with another one running the