Deploying and Scaling Microservices with Docker and Kubernetes

```

These slides have been built from commit: 3ab1907

[shared/title.md](https://github.com/jpetazzo/container.training/tree/main/slides/shared/title.md)]
---

Deploying and Scaling Microservices with Docker and Kubernetes

<!--
WiFi: **Something** 
Password: **Something**

**Be kind to the WiFi!** 
*Use the 5G network.*
*Don't use your hotspot.* 
*Don't stream videos or download big files during the workshop* 
*Thank you!*
-->

.debug[[shared/title.md](https://github.com/jpetazzo/container.training/tree/main/slides/shared/title.md)]
---
## A brief introduction

- This was initially written by [Jérôme Petazzoni](https://twitter.com/jpetazzo) to support in-person,
  instructor-led workshops and tutorials
  
- Credit is also due to [multiple contributors](https://github.com/jpetazzo/container.training/graphs/contributors) — thank you!

- You can also follow along on your own, at your own pace

- We included as much information as possible in these slides

- We recommend having a mentor to help you ...

- ... Or be comfortable spending some time reading the Kubernetes [documentation](https://kubernetes.io/docs/) ...

- ... And looking for answers on [StackOverflow](http://stackoverflow.com/questions/tagged/kubernetes) and other outlets

.debug[[k8s/intro.md](https://github.com/jpetazzo/container.training/tree/main/slides/k8s/intro.md)]
---

## Hands on, you shall practice

- Nobody ever became a Jedi by spending their lives reading Wookiepedia

- Likewise, it will take more than merely *reading* these slides
  to make you an expert

- These slides include *tons* of demos, exercises, and examples

- They assume that you have access to a Kubernetes cluster

- If you are attending a workshop or tutorial:
 you will be given specific instructions to access your cluster

- If you are doing this on your own:
 the first chapter will give you various options to get your own cluster

.debug[[k8s/intro.md](https://github.com/jpetazzo/container.training/tree/main/slides/k8s/intro.md)]
---
## Accessing these slides now

- We recommend that you open these slides in your browser:

https://container.training/

- This is a public URL, you're welcome to share it with others!

- Use arrows to move to next/previous slide

(up, down, left, right, page up, page down)

- Type a slide number + ENTER to go to that slide

- The slide number is also visible in the URL bar

(e.g. .../#123 for slide 123)

.debug[[shared/about-slides.md](https://github.com/jpetazzo/container.training/tree/main/slides/shared/about-slides.md)]
---

## These slides are open source

- The sources of these slides are available in a public GitHub repository:

https://github.com/jpetazzo/container.training

- These slides are written in Markdown

- You are welcome to share, re-use, re-mix these slides

- Typos? Mistakes? Questions? Feel free to hover over the bottom of the slide ...

.footnote[👇 Try it! The source file will be shown and you can view it on GitHub and fork and edit it.]

.debug[[shared/about-slides.md](https://github.com/jpetazzo/container.training/tree/main/slides/shared/about-slides.md)]
---

## Accessing these slides later

- Slides will remain online so you can review them later if needed

(let's say we'll keep them online at least 1 year, how about that?)

- You can download the slides using that URL:

https://container.training/slides.zip

(then open the file `kube-selfpaced.yml.html`)

- You can also generate a PDF of the slides

(by printing them to a file; but be patient with your browser!)

.debug[[shared/about-slides.md](https://github.com/jpetazzo/container.training/tree/main/slides/shared/about-slides.md)]
---

## These slides are constantly updated

- Feel free to check the GitHub repository for updates:

https://github.com/jpetazzo/container.training

- Look for branches named YYYY-MM-...

- You can also find specific decks and other resources on:

https://container.training/

.debug[[shared/about-slides.md](https://github.com/jpetazzo/container.training/tree/main/slides/shared/about-slides.md)]
---

## Extra details

- This slide has a little magnifying glass in the top left corner

- This magnifying glass indicates slides that provide extra details

- Feel free to skip them if:

- you are in a hurry

- you are new to this and want to avoid cognitive overload

- you want only the most essential information

- You can review these slides another time if you want, they'll be waiting for you ☺

.debug[[shared/about-slides.md](https://github.com/jpetazzo/container.training/tree/main/slides/shared/about-slides.md)]
---

## Part 1

- [Pre-requirements](#toc-pre-requirements)

- [Our sample application](#toc-our-sample-application)

- [Kubernetes concepts](#toc-kubernetes-concepts)

## Part 2

- [First contact with `kubectl`](#toc-first-contact-with-kubectl)

- [Running our first containers on Kubernetes](#toc-running-our-first-containers-on-kubernetes)

- [Executing batch jobs](#toc-executing-batch-jobs)

- [Labels and annotations](#toc-labels-and-annotations)

- [Revisiting `kubectl logs`](#toc-revisiting-kubectl-logs)

- [Accessing logs from the CLI](#toc-accessing-logs-from-the-cli)

- [Declarative vs imperative](#toc-declarative-vs-imperative)

## Part 3

- [Exposing containers](#toc-exposing-containers)

- [Service Types](#toc-service-types)

- [Kubernetes network model](#toc-kubernetes-network-model)

- [Shipping images with a registry](#toc-shipping-images-with-a-registry)

- [Running our application on Kubernetes](#toc-running-our-application-on-kubernetes)

- [Gentle introduction to YAML](#toc-gentle-introduction-to-yaml)

- [Deploying with YAML](#toc-deploying-with-yaml)

- [Namespaces](#toc-namespaces)

## Part 4

- [Setting up Kubernetes](#toc-setting-up-kubernetes)
- [Running a local development cluster](#toc-running-a-local-development-cluster)
- [Deploying a managed cluster](#toc-deploying-a-managed-cluster)
- [Kubernetes distributions and installers](#toc-kubernetes-distributions-and-installers)
- [The Kubernetes dashboard](#toc-the-kubernetes-dashboard)
- [Security implications of `kubectl apply`](#toc-security-implications-of-kubectl-apply)
- [k9s](#toc-ks)
- [Tilt](#toc-tilt)
- [Scaling our demo app](#toc-scaling-our-demo-app)
- [Daemon sets](#toc-daemon-sets)
- [Labels and selectors](#toc-labels-and-selectors)

## Part 5

- [Rolling updates](#toc-rolling-updates)

- [Healthchecks](#toc-healthchecks)

- [Recording deployment actions](#toc-recording-deployment-actions)

## Part 6

- [Controlling a Kubernetes cluster remotely](#toc-controlling-a-kubernetes-cluster-remotely)

- [Accessing internal services](#toc-accessing-internal-services)

- [Accessing the API with `kubectl proxy`](#toc-accessing-the-api-with-kubectl-proxy)

## Part 7

- [Exposing HTTP services with Ingress resources](#toc-exposing-http-services-with-ingress-resources)
- [Ingress and TLS certificates](#toc-ingress-and-tls-certificates)
- [cert-manager](#toc-cert-manager)
- [Kustomize](#toc-kustomize)
- [Managing stacks with Helm](#toc-managing-stacks-with-helm)
- [Helm chart format](#toc-helm-chart-format)
- [Creating a basic chart](#toc-creating-a-basic-chart)
- [Creating better Helm charts](#toc-creating-better-helm-charts)
- [Charts using other charts](#toc-charts-using-other-charts)
- [Helm and invalid values](#toc-helm-and-invalid-values)
- [Helm secrets](#toc-helm-secrets)
- [CI/CD with GitLab](#toc-cicd-with-gitlab)
- [YTT](#toc-ytt)

## Part 8

- [Network policies](#toc-network-policies)

- [Authentication and authorization](#toc-authentication-and-authorization)

- [Restricting Pod Permissions](#toc-restricting-pod-permissions)

- [Pod Security Policies](#toc-pod-security-policies)

- [Pod Security Admission](#toc-pod-security-admission)

- [Generating user certificates](#toc-generating-user-certificates)

- [The CSR API](#toc-the-csr-api)

- [OpenID Connect](#toc-openid-connect)

- [Securing the control plane](#toc-securing-the-control-plane)

## Part 9

- [Volumes](#toc-volumes)

- [Building images with the Docker Engine](#toc-building-images-with-the-docker-engine)

- [Building images with Kaniko](#toc-building-images-with-kaniko)

## Part 10

- [Managing configuration](#toc-managing-configuration)

- [Managing secrets](#toc-managing-secrets)

- [Stateful sets](#toc-stateful-sets)

- [Running a Consul cluster](#toc-running-a-consul-cluster)

- [PV, PVC, and Storage Classes](#toc-pv-pvc-and-storage-classes)

- [Portworx](#toc-portworx)

- [OpenEBS ](#toc-openebs-)

- [Stateful failover](#toc-stateful-failover)

## Part 11

- [Git-based workflows (GitOps)](#toc-git-based-workflows-gitops)

- [FluxCD](#toc-fluxcd)

- [ArgoCD](#toc-argocd)

## Part 12

- [Centralized logging](#toc-centralized-logging)
- [Collecting metrics with Prometheus](#toc-collecting-metrics-with-prometheus)
- [Prometheus and Grafana](#toc-prometheus-and-grafana)
- [Resource Limits](#toc-resource-limits)
- [Defining min, max, and default resources](#toc-defining-min-max-and-default-resources)
- [Namespace quotas](#toc-namespace-quotas)
- [Limiting resources in practice](#toc-limiting-resources-in-practice)
- [Checking Node and Pod resource usage](#toc-checking-node-and-pod-resource-usage)
- [Cluster sizing](#toc-cluster-sizing)
- [Disruptions](#toc-disruptions)
- [Cluster autoscaler](#toc-cluster-autoscaler)
- [The Horizontal Pod Autoscaler](#toc-the-horizontal-pod-autoscaler)
- [Scaling with custom metrics](#toc-scaling-with-custom-metrics)

## Part 13

- [Extending the Kubernetes API](#toc-extending-the-kubernetes-api)
- [API server internals](#toc-api-server-internals)
- [Custom Resource Definitions](#toc-custom-resource-definitions)
- [The Aggregation Layer](#toc-the-aggregation-layer)
- [Dynamic Admission Control](#toc-dynamic-admission-control)
- [Operators](#toc-operators)
- [Designing an operator](#toc-designing-an-operator)
- [Writing a tiny operator](#toc-writing-a-tiny-operator)
- [Kubebuilder](#toc-kubebuilder)
- [Sealed Secrets](#toc-sealed-secrets)
- [Policy Management with Kyverno](#toc-policy-management-with-kyverno)
- [An ElasticSearch Operator](#toc-an-elasticsearch-operator)
- [Finalizers](#toc-finalizers)
- [Owners and dependents](#toc-owners-and-dependents)
- [Events](#toc-events)

## Part 14

- [Building our own cluster (easy)](#toc-building-our-own-cluster-easy)

- [Building our own cluster (medium)](#toc-building-our-own-cluster-medium)

- [Building our own cluster (hard)](#toc-building-our-own-cluster-hard)

- [CNI internals](#toc-cni-internals)

- [API server availability](#toc-api-server-availability)

- [Static pods](#toc-static-pods)

## Part 15

- [Upgrading clusters](#toc-upgrading-clusters)

- [Backing up clusters](#toc-backing-up-clusters)

- [The Cloud Controller Manager](#toc-the-cloud-controller-manager)

## Part 16

- [Last words](#toc-last-words)

- [Links and resources](#toc-links-and-resources)

.debug[[shared/toc.md](https://github.com/jpetazzo/container.training/tree/main/slides/shared/toc.md)]
---

.interstitial[![Image separating from the next part](https://prettypictures.container.training/containers/Container-Ship-Freighter-Navigation-Elbe-Romance-1782991.jpg)]

---

Pre-requirements

.nav[
[Previous part](#toc-)
|
[Back to table of contents](#toc-part-1)
|
[Next part](#toc-our-sample-application)
]

---
# Pre-requirements

- Be comfortable with the UNIX command line

- navigating directories

- editing files

- a little bit of bash-fu (environment variables, loops)

- Some Docker knowledge

- `docker run`, `docker ps`, `docker build`

- ideally, you know how to write a Dockerfile and build it
 
 (even if it's a `FROM` line and a couple of `RUN` commands)

- It's totally OK if you are not a Docker expert!

.debug[[shared/prereqs.md](https://github.com/jpetazzo/container.training/tree/main/slides/shared/prereqs.md)]
---
class: title

*Tell me and I forget.*
 
*Teach me and I remember.*
 
*Involve me and I learn.*

Misattributed to Benjamin Franklin

[(Probably inspired by Chinese Confucian philosopher Xunzi)](https://www.barrypopik.com/index.php/new_york_city/entry/tell_me_and_i_forget_teach_me_and_i_may_remember_involve_me_and_i_will_lear/)

.debug[[shared/handson.md](https://github.com/jpetazzo/container.training/tree/main/slides/shared/handson.md)]
---

## Hands-on sections

- There will be *a lot* of examples and demos

- We are going to build, ship, and run containers (and sometimes, clusters!)

- If you want, you can run all the examples and demos in your environment

(but you don't have to; it's up to you!)

- All hands-on sections are clearly identified, like the gray rectangle below

- This is a command that we're gonna run:
  ```bash
  echo hello world
  ```

]

.debug[[shared/handson.md](https://github.com/jpetazzo/container.training/tree/main/slides/shared/handson.md)]
---

## Where are we going to run our containers?

.debug[[shared/handson.md](https://github.com/jpetazzo/container.training/tree/main/slides/shared/handson.md)]
---

![You get a cluster](images/you-get-a-cluster.jpg)

.debug[[shared/handson.md](https://github.com/jpetazzo/container.training/tree/main/slides/shared/handson.md)]
---

## If you're attending a live training or workshop

- Each person gets a private lab environment

(depending on the scenario, this will be one VM, one cluster, multiple clusters...)

- The instructor will tell you how to connect to your environment

- Your lab environments will be available for the duration of the workshop

(check with your instructor to know exactly when they'll be shutdown)

.debug[[shared/handson.md](https://github.com/jpetazzo/container.training/tree/main/slides/shared/handson.md)]
---

## Running your own lab environments

- If you are following a self-paced course...

- Or watching a replay of a recorded course...

- ...You will need to set up a local environment for the labs

- If you want to deliver your own training or workshop:

- deployment scripts are available in the [prepare-labs] directory

- you can use them to automatically deploy many lab environments

- they support many different infrastructure providers

[prepare-labs]: https://github.com/jpetazzo/container.training/tree/main/prepare-labs

.debug[[shared/handson.md](https://github.com/jpetazzo/container.training/tree/main/slides/shared/handson.md)]
---

## Why don't we run containers locally?

- Installing this stuff can be hard on some machines

(32 bits CPU or OS... Laptops without administrator access... etc.)

- *"The whole team downloaded all these container images from the WiFi!
 ... and it went great!"* (Literally no-one ever)

- All you need is a computer (or even a phone or tablet!), with:

- an Internet connection

- a web browser

- an SSH client

.debug[[shared/handson.md](https://github.com/jpetazzo/container.training/tree/main/slides/shared/handson.md)]
---

## SSH clients

- On Linux, OS X, FreeBSD... you are probably all set

- On Windows, get one of these:

- [putty](http://www.putty.org/)
  - Microsoft [Win32 OpenSSH](https://github.com/PowerShell/Win32-OpenSSH/wiki/Install-Win32-OpenSSH)
  - [Git BASH](https://git-for-windows.github.io/)
  - [MobaXterm](http://mobaxterm.mobatek.net/)

- On Android, [JuiceSSH](https://juicessh.com/)
  ([Play Store](https://play.google.com/store/apps/details?id=com.sonelli.juicessh))
  works pretty well

- Nice-to-have: [Mosh](https://mosh.org/) instead of SSH, if your Internet connection tends to lose packets

.debug[[shared/handson.md](https://github.com/jpetazzo/container.training/tree/main/slides/shared/handson.md)]
---

## What is this Mosh thing?

*You don't have to use Mosh or even know about it to follow along.
 
We're just telling you about it because some of us think it's cool!*

- Mosh is "the mobile shell"

- It is essentially SSH over UDP, with roaming features

- It retransmits packets quickly, so it works great even on lossy connections

(Like hotel or conference WiFi)

- It has intelligent local echo, so it works great even in high-latency connections

(Like hotel or conference WiFi)

- It supports transparent roaming when your client IP address changes

(Like when you hop from hotel to conference WiFi)

.debug[[shared/handson.md](https://github.com/jpetazzo/container.training/tree/main/slides/shared/handson.md)]
---

## Using Mosh

- To install it: `(apt|yum|brew) install mosh`

- It has been pre-installed on the VMs that we are using

- To connect to a remote machine: `mosh user@host`

(It is going to establish an SSH connection, then hand off to UDP)

- It requires UDP ports to be open

(By default, it uses a UDP port between 60000 and 61000)

.debug[[shared/handson.md](https://github.com/jpetazzo/container.training/tree/main/slides/shared/handson.md)]
---
class: in-person

## Testing the connection to our lab environment

- Connect to your lab environment with your SSH client:
  ```bash
  ssh `user`@`A.B.C.D`
  ssh -p `32323` `user`@`A.B.C.D`
  ```

(Make sure to replace the highlighted values with the ones provided to you!)

<!--
```bash
for N in $(awk '/\Wnode/{print $2}' /etc/hosts); do
 ssh -o StrictHostKeyChecking=no $N true
done
```

```bash
### FIXME find a way to reset the cluster, maybe?
```
-->

]

You should see a prompt looking like this:
```
[A.B.C.D] (...) user@machine ~
$
```
If anything goes wrong — ask for help!

.debug[[shared/connecting.md](https://github.com/jpetazzo/container.training/tree/main/slides/shared/connecting.md)]
---

## `tailhist`

- The shell history of the instructor is available online in real time

- The instructor will provide you a "magic URL"

(typically, the instructor's lab address on port 1088 or 30088)

- Open that URL in your browser and you should see the history

- The history is updated in real time

(using a WebSocket connection)

- It should be green when the WebSocket is connected

(if it turns red, reloading the page should fix it)

.debug[[shared/connecting.md](https://github.com/jpetazzo/container.training/tree/main/slides/shared/connecting.md)]
---

## Doing or re-doing the workshop on your own?

- Use something like
  [Play-With-Docker](http://play-with-docker.com/) or
  [Play-With-Kubernetes](https://training.play-with-kubernetes.com/)

Zero setup effort; but environment are short-lived and
  might have limited resources

- Create your own cluster (local or cloud VMs)

Small setup effort; small cost; flexible environments

- Create a bunch of clusters for you and your friends
    ([instructions](https://github.com/jpetazzo/container.training/tree/main/prepare-labs))

Bigger setup effort; ideal for group training

.debug[[shared/connecting.md](https://github.com/jpetazzo/container.training/tree/main/slides/shared/connecting.md)]
---

## For a consistent Kubernetes experience ...

- If you are using your own Kubernetes cluster, you can use [jpetazzo/shpod](https://github.com/jpetazzo/shpod)

- `shpod` provides a shell running in a pod on your own cluster

- It comes with many tools pre-installed (helm, stern...)

- These tools are used in many demos and exercises in these slides

- `shpod` also gives you completion and a fancy prompt

- It can also be used as an SSH server if needed

.debug[[shared/connecting.md](https://github.com/jpetazzo/container.training/tree/main/slides/shared/connecting.md)]
---

## Get your own Docker nodes

- If you already have some Docker nodes: great!

- If not: let's get some thanks to Play-With-Docker

- Go to http://www.play-with-docker.com/

- Log in

- Create your first node

]

You will need a Docker ID to use Play-With-Docker.

(Creating a Docker ID is free.)

.debug[[shared/connecting.md](https://github.com/jpetazzo/container.training/tree/main/slides/shared/connecting.md)]
---

## We don't need to connect to ALL the nodes

- If your cluster has multiple nodes (e.g. `node1`, `node2`, ...):

unless instructed, **all commands must be run from the first node**

- We don't need to check out/copy code or manifests on other nodes

- During normal operations, we do not need access to the other nodes

(but we could log into these nodes to troubleshoot or examine stuff)

.debug[[shared/connecting.md](https://github.com/jpetazzo/container.training/tree/main/slides/shared/connecting.md)]
---

## Terminals

Once in a while, the instructions will say:
 "Open a new terminal."

There are multiple ways to do this:

- create a new window or tab on your machine, and SSH into the VM;

- use screen or tmux on the VM and open a new window from there.

You are welcome to use the method that you feel the most comfortable with.

.debug[[shared/connecting.md](https://github.com/jpetazzo/container.training/tree/main/slides/shared/connecting.md)]
---

## Tmux cheat sheet (basic)

[Tmux](https://en.wikipedia.org/wiki/Tmux) is a terminal multiplexer like `screen`.

*You don't have to use it or even know about it to follow along.
 
But some of us like to use it to switch between terminals.
 
It has been preinstalled on your workshop nodes.*

- You can start a new session with `tmux`
 
 (or resume or share an existing session with `tmux attach`)

- Then use these keyboard shortcuts:

- Ctrl-b c → creates a new window
  - Ctrl-b n → go to next window
  - Ctrl-b p → go to previous window
  - Ctrl-b " → split window top/bottom
  - Ctrl-b % → split window left/right
  - Ctrl-b arrows → navigate within split windows

.debug[[shared/connecting.md](https://github.com/jpetazzo/container.training/tree/main/slides/shared/connecting.md)]
---

## Tmux cheat sheet (advanced)

- Ctrl-b d → detach session
 
 (resume it later with `tmux attach`)

- Ctrl-b Alt-1 → rearrange windows in columns

- Ctrl-b Alt-2 → rearrange windows in rows

- Ctrl-b , → rename window

- Ctrl-b Ctrl-o → cycle pane position (e.g. switch top/bottom)

- Ctrl-b PageUp → enter scrollback mode
 
 (use PageUp/PageDown to scroll; Ctrl-c or Enter to exit scrollback)

.debug[[shared/connecting.md](https://github.com/jpetazzo/container.training/tree/main/slides/shared/connecting.md)]
---
## Versions installed

- Kubernetes 1.19.2
- Docker Engine 19.03.13
- Docker Compose 1.25.4

- Check all installed versions:
  ```bash
  kubectl version
  docker version
  docker-compose -v
  ```

]

.debug[[k8s/versions-k8s.md](https://github.com/jpetazzo/container.training/tree/main/slides/k8s/versions-k8s.md)]
---

## Kubernetes and Docker compatibility

- Kubernetes 1.17 validates Docker Engine version [up to 19.03](https://github.com/kubernetes/kubernetes/pull/84476)

*however ...*

- Kubernetes 1.15 validates Docker Engine versions [up to 18.09](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.15.md#dependencies)
 
 (the latest version when Kubernetes 1.14 was released)

- Kubernetes 1.13 only validates Docker Engine versions [up to 18.06](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.13.md#external-dependencies)

- Is it a problem if I use Kubernetes with a "too recent" Docker Engine?

- No!

- "Validates" = continuous integration builds with very extensive (and expensive) testing

- The Docker API is versioned, and offers strong backward-compatibility
 
 (if a client uses e.g. API v1.25, the Docker Engine will keep behaving the same way)

.debug[[k8s/versions-k8s.md](https://github.com/jpetazzo/container.training/tree/main/slides/k8s/versions-k8s.md)]
---

## Kubernetes versioning and cadence

- Kubernetes versions are expressed using *semantic versioning*

(a Kubernetes version is expressed as MAJOR.MINOR.PATCH)

- There is a new *patch* release whenever needed

(generally, there is about [2 to 4 weeks](https://github.com/kubernetes/sig-release/blob/master/release-engineering/role-handbooks/patch-release-team.md#release-timing) between patch releases,
  except when a critical bug or vulnerability is found:
  in that case, a patch release will follow as fast as possible)

- There is a new *minor* release approximately every 3 months

- At any given time, 3 *minor* releases are maintained

(in other words, a given *minor* release is maintained about 9 months)

.debug[[k8s/versions-k8s.md](https://github.com/jpetazzo/container.training/tree/main/slides/k8s/versions-k8s.md)]
---

## Kubernetes version compatibility

*Should my version of `kubectl` match exactly my cluster version?*

- `kubectl` can be up to one minor version older or newer than the cluster

(if cluster version is 1.15.X, `kubectl` can be 1.14.Y, 1.15.Y, or 1.16.Y)

- Things *might* work with larger version differences

(but they will probably fail randomly, so be careful)

- This is an example of an error indicating version compability issues:
  ```
  error: SchemaError(io.k8s.api.autoscaling.v2beta1.ExternalMetricStatus):
  invalid object doesn't have additional properties
  ```

- Check [the documentation](https://kubernetes.io/docs/setup/release/version-skew-policy/#kubectl) for the whole story about compatibility

???

:EN:- Kubernetes versioning and compatibility
:FR:- Les versions de Kubernetes et leur compatibilité

.debug[[k8s/versions-k8s.md](https://github.com/jpetazzo/container.training/tree/main/slides/k8s/versions-k8s.md)]
---

.interstitial[![Image separating from the next part](https://prettypictures.container.training/containers/ShippingContainerSFBay.jpg)]

---

Our sample application

.nav[
[Previous part](#toc-pre-requirements)
|
[Back to table of contents](#toc-part-1)
|
[Next part](#toc-kubernetes-concepts)
]

---
# Our sample application

- We will clone the GitHub repository onto our `node1`

- The repository also contains scripts and tools that we will use through the workshop

- Clone the repository on `node1`:
  ```bash
  git clone https://github.com/jpetazzo/container.training
  ```

]

(You can also fork the repository on GitHub and clone your fork if you prefer that.)

.debug[[shared/sampleapp.md](https://github.com/jpetazzo/container.training/tree/main/slides/shared/sampleapp.md)]
---

## Downloading and running the application

Let's start this before we look around, as downloading will take a little time...

- Go to the `dockercoins` directory, in the cloned repository:
  ```bash
  cd ~/container.training/dockercoins
  ```

- Use Compose to build and run all containers:
  ```bash
  docker-compose up
  ```

]

Compose tells Docker to build all container images (pulling
the corresponding base images), then starts all containers,
and displays aggregated logs.

.debug[[shared/sampleapp.md](https://github.com/jpetazzo/container.training/tree/main/slides/shared/sampleapp.md)]
---

## What's this application?

- It is a DockerCoin miner! 💰🐳📦🚢

- No, you can't buy coffee with DockerCoin

- How dockercoins works:

- generate a few random bytes

- hash these bytes

- increment a counter (to keep track of speed)

- repeat forever!

- DockerCoin is *not* a cryptocurrency

(the only common points are "randomness," "hashing," and "coins" in the name)

.debug[[shared/sampleapp.md](https://github.com/jpetazzo/container.training/tree/main/slides/shared/sampleapp.md)]
---

## DockerCoin in the microservices era

- The dockercoins app is made of 5 services:

- `rng` = web service generating random bytes

- `hasher` = web service computing hash of POSTed data

- `worker` = background process calling `rng` and `hasher`

- `webui` = web interface to watch progress

- `redis` = data store (holds a counter updated by `worker`)

- These 5 services are visible in the application's Compose file,
  [docker-compose.yml](
  https://github.com/jpetazzo/container.training/blob/master/dockercoins/docker-compose.yml)

.debug[[shared/sampleapp.md](https://github.com/jpetazzo/container.training/tree/main/slides/shared/sampleapp.md)]
---

## How dockercoins works

- `worker` invokes web service `rng` to generate random bytes

- `worker` invokes web service `hasher` to hash these bytes

- `worker` does this in an infinite loop

- every second, `worker` updates `redis` to indicate how many loops were done

- `webui` queries `redis`, and computes and exposes "hashing speed" in our browser

*(See diagram on next slide!)*

.debug[[shared/sampleapp.md](https://github.com/jpetazzo/container.training/tree/main/slides/shared/sampleapp.md)]
---

![Diagram showing the 5 containers of the applications](images/dockercoins-diagram.png)

.debug[[shared/sampleapp.md](https://github.com/jpetazzo/container.training/tree/main/slides/shared/sampleapp.md)]
---

## Service discovery in container-land

How does each service find out the address of the other ones?

- We do not hard-code IP addresses in the code

- We do not hard-code FQDNs in the code, either

- We just connect to a service name, and container-magic does the rest

(And by container-magic, we mean "a crafty, dynamic, embedded DNS server")

.debug[[shared/sampleapp.md](https://github.com/jpetazzo/container.training/tree/main/slides/shared/sampleapp.md)]
---

## Example in `worker/worker.py`

```python
redis = Redis("`redis`")

def get_random_bytes():
    r = requests.get("http://`rng`/32")
    return r.content

def hash_bytes(data):
    r = requests.post("http://`hasher`/",
                      data=data,
                      headers={"Content-Type": "application/octet-stream"})
```

(Full source code available [here](
https://github.com/jpetazzo/container.training/blob/8279a3bce9398f7c1a53bdd95187c53eda4e6435/dockercoins/worker/worker.py#L17
))

.debug[[shared/sampleapp.md](https://github.com/jpetazzo/container.training/tree/main/slides/shared/sampleapp.md)]
---

## Links, naming, and service discovery

- Containers can have network aliases (resolvable through DNS)

- Compose file version 2+ makes each container reachable through its service name

- Compose file version 1 required "links" sections to accomplish this

- Network aliases are automatically namespaced

- you can have multiple apps declaring and using a service named `database`

- containers in the blue app will resolve `database` to the IP of the blue database

- containers in the green app will resolve `database` to the IP of the green database

.debug[[shared/sampleapp.md](https://github.com/jpetazzo/container.training/tree/main/slides/shared/sampleapp.md)]
---

## Show me the code!

- You can check the GitHub repository with all the materials of this workshop:
 https://github.com/jpetazzo/container.training

- The application is in the [dockercoins](
  https://github.com/jpetazzo/container.training/tree/master/dockercoins)
  subdirectory

- The Compose file ([docker-compose.yml](
  https://github.com/jpetazzo/container.training/blob/master/dockercoins/docker-compose.yml))
  lists all 5 services

- `redis` is using an official image from the Docker Hub

- `hasher`, `rng`, `worker`, `webui` are each built from a Dockerfile

- Each service's Dockerfile and source code is in its own directory

(`hasher` is in the [hasher](https://github.com/jpetazzo/container.training/blob/master/dockercoins/hasher/) directory,
  `rng` is in the [rng](https://github.com/jpetazzo/container.training/blob/master/dockercoins/rng/)
  directory, etc.)

.debug[[shared/sampleapp.md](https://github.com/jpetazzo/container.training/tree/main/slides/shared/sampleapp.md)]
---

## Compose file format version

*This is relevant only if you have used Compose before 2016...*

- Compose 1.6 introduced support for a new Compose file format (aka "v2")

- Services are no longer at the top level, but under a `services` section

- There has to be a `version` key at the top level, with value `"2"` (as a string, not an integer)

- Containers are placed on a dedicated network, making links unnecessary

- There are other minor differences, but upgrade is easy and straightforward

.debug[[shared/sampleapp.md](https://github.com/jpetazzo/container.training/tree/main/slides/shared/sampleapp.md)]
---

## Our application at work

- On the left-hand side, the "rainbow strip" shows the container names

- On the right-hand side, we see the output of our containers

- We can see the `worker` service making requests to `rng` and `hasher`

- For `rng` and `hasher`, we see HTTP access logs

.debug[[shared/sampleapp.md](https://github.com/jpetazzo/container.training/tree/main/slides/shared/sampleapp.md)]
---

## Connecting to the web UI

- "Logs are exciting and fun!" (No-one, ever)

- The `webui` container exposes a web dashboard; let's view it

- With a web browser, connect to `node1` on port 8000

- Remember: the `nodeX` aliases are valid only on the nodes themselves

- In your browser, you need to enter the IP address of your node

]

A drawing area should show up, and after a few seconds, a blue
graph will appear.

.debug[[shared/sampleapp.md](https://github.com/jpetazzo/container.training/tree/main/slides/shared/sampleapp.md)]
---

## If the graph doesn't load

If you just see a `Page not found` error, it might be because your
Docker Engine is running on a different machine. This can be the case if:

- you are using the Docker Toolbox

- you are using a VM (local or remote) created with Docker Machine

- you are controlling a remote Docker Engine

When you run DockerCoins in development mode, the web UI static files
are mapped to the container using a volume. Alas, volumes can only
work on a local environment, or when using Docker Desktop for Mac or Windows.

How to fix this?

Stop the app with `^C`, edit `dockercoins.yml`, comment out the `volumes` section, and try again.

.debug[[shared/sampleapp.md](https://github.com/jpetazzo/container.training/tree/main/slides/shared/sampleapp.md)]
---

## Why does the speed seem irregular?

- It *looks like* the speed is approximately 4 hashes/second

- Or more precisely: 4 hashes/second, with regular dips down to zero

- Why?

- The app actually has a constant, steady speed: 3.33 hashes/second
 
 (which corresponds to 1 hash every 0.3 seconds, for *reasons*)

- Yes, and?

.debug[[shared/sampleapp.md](https://github.com/jpetazzo/container.training/tree/main/slides/shared/sampleapp.md)]
---

## The reason why this graph is *not awesome*

- The worker doesn't update the counter after every loop, but up to once per second

- The speed is computed by the browser, checking the counter about once per second

- Between two consecutive updates, the counter will increase either by 4, or by 0

- The perceived speed will therefore be 4 - 4 - 4 - 0 - 4 - 4 - 0 etc.

- What can we conclude from this?

- "I'm clearly incapable of writing good frontend code!" 😀 — Jérôme

.debug[[shared/sampleapp.md](https://github.com/jpetazzo/container.training/tree/main/slides/shared/sampleapp.md)]
---

## Stopping the application

- If we interrupt Compose (with `^C`), it will politely ask the Docker Engine to stop the app

- The Docker Engine will send a `TERM` signal to the containers

- If the containers do not exit in a timely manner, the Engine sends a `KILL` signal

- Stop the application by hitting `^C`

]

Some containers exit immediately, others take longer.

The containers that do not handle `SIGTERM` end up being killed after a 10s timeout. If we are very impatient, we can hit `^C` a second time!

.debug[[shared/sampleapp.md](https://github.com/jpetazzo/container.training/tree/main/slides/shared/sampleapp.md)]
---
## Clean up

- Before moving on, let's remove those containers

- Tell Compose to remove everything:
  ```bash
  docker-compose down
  ```

]

.debug[[shared/composedown.md](https://github.com/jpetazzo/container.training/tree/main/slides/shared/composedown.md)]
---

.interstitial[![Image separating from the next part](https://prettypictures.container.training/containers/aerial-view-of-containers.jpg)]

---

Kubernetes concepts

.nav[
[Previous part](#toc-our-sample-application)
|
[Back to table of contents](#toc-part-1)
|
[Next part](#toc-first-contact-with-kubectl)
]

---
# Kubernetes concepts

- Kubernetes is a container management system

- It runs and manages containerized applications on a cluster

- What does that really mean?

.debug[[k8s/concepts-k8s.md](https://github.com/jpetazzo/container.training/tree/main/slides/k8s/concepts-k8s.md)]
---

## What can we do with Kubernetes?

- Let's imagine that we have a 3-tier e-commerce app:

- web frontend

- API backend

- database (that we will keep out of Kubernetes for now)

- We have built images for our frontend and backend components

(e.g. with Dockerfiles and `docker build`)

- We are running them successfully with a local environment

(e.g. with Docker Compose)

- Let's see how we would deploy our app on Kubernetes!

.debug[[k8s/concepts-k8s.md](https://github.com/jpetazzo/container.training/tree/main/slides/k8s/concepts-k8s.md)]
---

## Basic things we can ask Kubernetes to do

- Start 5 containers using image `atseashop/api:v1.3`

- Place an internal load balancer in front of these containers

- Start 10 containers using image `atseashop/webfront:v1.3`

- Place a public load balancer in front of these containers

- It's Black Friday (or Christmas), traffic spikes, grow our cluster and add containers

- New release! Replace my containers with the new image `atseashop/webfront:v1.4`

- Keep processing requests during the upgrade; update my containers one at a time

.debug[[k8s/concepts-k8s.md](https://github.com/jpetazzo/container.training/tree/main/slides/k8s/concepts-k8s.md)]
---

## Other things that Kubernetes can do for us

- Autoscaling

(straightforward on CPU; more complex on other metrics)

- Resource management and scheduling

(reserve CPU/RAM for containers; placement constraints)

- Advanced rollout patterns

(blue/green deployment, canary deployment)

.footnote[
On the next page: canary cage with an oxygen bottle, designed to keep the canary alive.
 
(See https://post.lurk.org/@zilog/109632335293371919 for details.)
]

.debug[[k8s/concepts-k8s.md](https://github.com/jpetazzo/container.training/tree/main/slides/k8s/concepts-k8s.md)]
---

![Canary cage](images/canary-cage.jpg)

.debug[[k8s/concepts-k8s.md](https://github.com/jpetazzo/container.training/tree/main/slides/k8s/concepts-k8s.md)]
---

## More things that Kubernetes can do for us

- Batch jobs

(one-off; parallel; also cron-style periodic execution)

- Fine-grained access control

(defining *what* can be done by *whom* on *which* resources)

- Stateful services

(databases, message queues, etc.)

- Automating complex tasks with *operators*

(e.g. database replication, failover, etc.)

.debug[[k8s/concepts-k8s.md](https://github.com/jpetazzo/container.training/tree/main/slides/k8s/concepts-k8s.md)]
---

## Kubernetes architecture

.debug[[k8s/concepts-k8s.md](https://github.com/jpetazzo/container.training/tree/main/slides/k8s/concepts-k8s.md)]
---

![haha only kidding](images/k8s-arch1.png)

.debug[[k8s/concepts-k8s.md](https://github.com/jpetazzo/container.training/tree/main/slides/k8s/concepts-k8s.md)]
---

## Kubernetes architecture

- Ha ha ha ha

- OK, I was trying to scare you, it's much simpler than that ❤️

.debug[[k8s/concepts-k8s.md](https://github.com/jpetazzo/container.training/tree/main/slides/k8s/concepts-k8s.md)]
---

![that one is more like the real thing](images/k8s-arch2.png)

.debug[[k8s/concepts-k8s.md](https://github.com/jpetazzo/container.training/tree/main/slides/k8s/concepts-k8s.md)]
---

## Credits

- The first schema is a Kubernetes cluster with storage backed by multi-path iSCSI

(Courtesy of [Yongbok Kim](https://www.yongbok.net/blog/))

- The second one is a simplified representation of a Kubernetes cluster

(Courtesy of [Imesh Gunaratne](https://medium.com/containermind/a-reference-architecture-for-deploying-wso2-middleware-on-kubernetes-d4dee7601e8e))

.debug[[k8s/concepts-k8s.md](https://github.com/jpetazzo/container.training/tree/main/slides/k8s/concepts-k8s.md)]
---

## Kubernetes architecture: the nodes

- The nodes executing our containers run a collection of services:

- a container Engine (typically Docker)

- kubelet (the "node agent")

- kube-proxy (a necessary but not sufficient network component)

- Nodes were formerly called "minions"

(You might see that word in older articles or documentation)

.debug[[k8s/concepts-k8s.md](https://github.com/jpetazzo/container.training/tree/main/slides/k8s/concepts-k8s.md)]
---

## Kubernetes architecture: the control plane

- The Kubernetes logic (its "brains") is a collection of services:

- the API server (our point of entry to everything!)

- core services like the scheduler and controller manager

- `etcd` (a highly available key/value store; the "database" of Kubernetes)

- Together, these services form the control plane of our cluster

- The control plane is also called the "master"

.debug[[k8s/concepts-k8s.md](https://github.com/jpetazzo/container.training/tree/main/slides/k8s/concepts-k8s.md)]
---

![One of the best Kubernetes architecture diagrams available](images/k8s-arch4-thanks-luxas.png)

.debug[[k8s/concepts-k8s.md](https://github.com/jpetazzo/container.training/tree/main/slides/k8s/concepts-k8s.md)]
---

## Running the control plane on special nodes

- It is common to reserve a dedicated node for the control plane

(Except for single-node development clusters, like when using minikube)

- This node is then called a "master"

(Yes, this is ambiguous: is the "master" a node, or the whole control plane?)

- Normal applications are restricted from running on this node

(By using a mechanism called ["taints"](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/))

- When high availability is required, each service of the control plane must be resilient

- The control plane is then replicated on multiple nodes

(This is sometimes called a "multi-master" setup)

.debug[[k8s/concepts-k8s.md](https://github.com/jpetazzo/container.training/tree/main/slides/k8s/concepts-k8s.md)]
---

## Running the control plane outside containers

- The services of the control plane can run in or out of containers

- For instance: since `etcd` is a critical service, some people
  deploy it directly on a dedicated cluster (without containers)

(This is illustrated on the first "super complicated" schema)

- In some hosted Kubernetes offerings (e.g. AKS, GKE, EKS), the control plane is invisible

(We only "see" a Kubernetes API endpoint)

- In that case, there is no "master node"

*For this reason, it is more accurate to say "control plane" rather than "master."*