Kubernetes 101

Kubernetes 101

.debug[
```
 M slides/Docker-1hour.yml
 M slides/containers/links.md
 M slides/intro-fullday.yml.html
 M slides/intro-selfpaced.yml.html
 M slides/intro-twodays.yml.html
 M slides/k8s/links-bridget.md
 M slides/kadm-fullday.yml.html
 M slides/kadm-twodays.yml.html
 M slides/kube-adv.yml.html
 M slides/kube-fullday.yml.html
 M slides/kube-halfday.yml.html
 M slides/kube-selfpaced.yml.html
 M slides/kube-twodays.yml.html
 M slides/slides.zip
 M slides/swarm-fullday.yml.html
 M slides/swarm-halfday.yml.html
 M slides/swarm-selfpaced.yml.html
 M slides/swarm-video.yml.html
?? slides/Docker-1hour.yml.html
?? slides/Kube-1hour.yml
?? slides/Kube-1hour.yml.html
?? slides/shared/about-slides-old.md

```

These slides have been built from commit: 55180b0

[shared/title.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/shared/title.md)]
---

Kubernetes 101

.footnote[
**Slides[:](https://www.youtube.com/watch?v=h16zyxiwDLY) https://ryaxtech.github.io/kube.training/**
]

<!--
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](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/shared/title.md)]
---

## Part 1

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

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

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

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

- [Setting up Kubernetes](#toc-setting-up-kubernetes)

## Part 2

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

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

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

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

## Part 3

- [The Kubernetes dashboard](#toc-the-kubernetes-dashboard)

- [Security implications of `kubectl apply`](#toc-security-implications-of-kubectl-apply)

- [Daemon sets](#toc-daemon-sets)

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

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

## Part 4

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

- [Namespaces](#toc-namespaces)

- [Next steps](#toc-next-steps)

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

.debug[[shared/toc.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/shared/toc.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](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/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](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/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](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/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](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/k8s/versions-k8s.md)]
---

.interstitial[![Image separating from the next part](https://gallant-turing-d0d520.netlify.com/containers/Container-Ship-Freighter-Navigation-Elbe-Romance-1782991.jpg)]

---

Kubernetes concepts

.nav[
[Previous part](#toc-)
|
[Back to table of contents](#toc-part-1)
|
[Next part](#toc-declarative-vs-imperative)
]

---
# 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](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/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](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/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](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/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)

.debug[[k8s/concepts-k8s.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/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](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/k8s/concepts-k8s.md)]
---

## Kubernetes architecture

.debug[[k8s/concepts-k8s.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/k8s/concepts-k8s.md)]
---

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

.debug[[k8s/concepts-k8s.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/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](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/tree/main/slides/k8s/concepts-k8s.md)]
---

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

.debug[[k8s/concepts-k8s.md](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/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](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/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](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/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](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/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](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/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](git@gitlab.com:ryax-tech/training/training-slides-docker-kube.git/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."*