diff --git a/slides/k8s/concepts-k8s.md b/slides/k8s/concepts-k8s.md index c7aa2f7a..32e241bb 100644 --- a/slides/k8s/concepts-k8s.md +++ b/slides/k8s/concepts-k8s.md @@ -136,6 +136,8 @@ class: pic --- +class: extra-details + ## Running the control plane on special nodes - It is common to reserve a dedicated node for the control plane @@ -158,6 +160,8 @@ class: pic --- +class: extra-details + ## Running the control plane outside containers - The services of the control plane can run in or out of containers @@ -177,25 +181,81 @@ class: pic --- -## Kubernetes resources +class: extra-details -- The Kubernetes API defines a lot of objects called *resources* +## Do we need to run Docker at all? -- These resources are organized by type, or `Kind` (in the API) +No! + +-- + +- By default, Kubernetes uses the Docker Engine to run containers + +- We could also use `rkt` ("Rocket") from CoreOS + +- Or leverage other pluggable runtimes through the *Container Runtime Interface* + + (like CRI-O, or containerd) + +--- + +class: extra-details + +## Do we need to run Docker at all? + +Yes! + +-- + +- In this workshop, we run our app on a single node first + +- We will need to build images and ship them around + +- We can do these things without Docker +
+ (and get diagnosed with NIH¹ syndrome) + +- Docker is still the most stable container engine today +
+ (but other options are maturing very quickly) + +.footnote[¹[Not Invented Here](https://en.wikipedia.org/wiki/Not_invented_here)] + +--- + +class: extra-details + +## Do we need to run Docker at all? + +- On our development environments, CI pipelines ... : + + *Yes, almost certainly* + +- On our production servers: + + *Yes (today)* + + *Probably not (in the future)* + +.footnote[More information about CRI [on the Kubernetes blog](https://kubernetes.io/blog/2016/12/container-runtime-interface-cri-in-kubernetes)] + +--- + +## Interacting with Kubernetes + +- We will interact with our Kubernetes cluster through the Kubernetes API + +- The Kubernetes API is (mostly) RESTful + +- It allows us to create, read, update, delete *resources* - A few common resource types are: - node (a machine — physical or virtual — in our cluster) + - pod (group of containers running together on a node) + - service (stable network endpoint to connect to one or multiple containers) - - namespace (more-or-less isolated group of things) - - secret (bundle of sensitive data to be passed to a container) - - And much more! - -- We can see the full list by running `kubectl api-resources` - - (In Kubernetes 1.10 and prior, the command to list API resources was `kubectl get`) --- diff --git a/slides/k8s/declarative.md b/slides/k8s/declarative.md index de9fa995..fc4e1fb0 100644 --- a/slides/k8s/declarative.md +++ b/slides/k8s/declarative.md @@ -1,6 +1,20 @@ ## Declarative vs imperative in Kubernetes -- Virtually everything we create in Kubernetes is created from a *spec* +- With Kubernetes, we cannot say: "run this container" + +- All we can do is write a *spec* and push it to the API server + + (by creating a resource like e.g. a Pod or a Deployment) + +- The API server will validate that spec (and reject it if it's invalid) + +- Then it will store it in etcd + +- A *controller* will "notice" that spec and act upon it + +--- + +## Reconciling state - Watch for the `spec` fields in the YAML files later! diff --git a/slides/k8s/kubenet.md b/slides/k8s/kubenet.md index 92229df9..57d1ddd8 100644 --- a/slides/k8s/kubenet.md +++ b/slides/k8s/kubenet.md @@ -16,6 +16,8 @@ - each pod is aware of its IP address (no NAT) + - pod IP addresses are assigned by the network implementation + - Kubernetes doesn't mandate any particular implementation --- @@ -30,7 +32,7 @@ - No new protocol -- Pods cannot move from a node to another and keep their IP address +- The network implementation can decide how to allocate addresses - IP addresses don't have to be "portable" from a node to another @@ -82,13 +84,17 @@ --- +class: extra-details + ## The Container Network Interface (CNI) -- The CNI has a well-defined [specification](https://github.com/containernetworking/cni/blob/master/SPEC.md#network-configuration) for network plugins +- Most Kubernetes clusters use CNI "plugins" to implement networking -- When a pod is created, Kubernetes delegates the network setup to CNI plugins +- When a pod is created, Kubernetes delegates the network setup to these plugins -- Typically, a CNI plugin will: + (in can be a single plugin, or a combination of plugins, each doing one task) + +- Typically, CNI plugins will: - allocate an IP address (by calling an IPAM plugin) @@ -96,8 +102,46 @@ - configure the interface as well as required routes etc. -- Using multiple plugins can be done with "meta-plugins" like CNI-Genie or Multus +--- -- Not all CNI plugins are equal +class: extra-details - (e.g. they don't all implement network policies, which are required to isolate pods) +## Multiple moving parts + +- The "pod-to-pod network" or "pod network": + + - provides communication between pods and nodes + + - is generally implemented with CNI plugins + +- The "pod-to-service network": + + - provides internal communication and load balancing + + - is generally implemented with kube-proxy (or e.g. kube-router) + +- Network policies: + + - provide firewalling and isolation + + - can be bundled with the "pod network" or provided by another component + +--- + +class: extra-details + +## Even more moving parts + +- Inbound traffic can be handled by multiple components: + + - something like kube-proxy or kube-router (for NodePort services) + + - load balancers (ideally, connected to the pod network) + +- It is possible to use multiple pod networks in parallel + + (with "meta-plugins" like CNI-Genie or Multus) + +- Some products can fill multiple roles + + (e.g. kube-router can be set up to provide the pod network and/or network policies and/or replace kube-proxy)