Merge pull request #457 from jpetazzo/improve-core-apr-2019

Improve core April 2019

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,6 +181,8 @@ class: pic
 
 ---
 
+class: extra-details
+
 ## Do we need to run Docker at all?
 
 No!
@@ -193,6 +199,8 @@ No!
 
 ---
 
+class: extra-details
+
 ## Do we need to run Docker at all?
 
 Yes!
@@ -215,6 +223,8 @@ Yes!
 
 ---
 
+class: extra-details
+
 ## Do we need to run Docker at all?
 
 - On our development environments, CI pipelines ... :
@@ -231,25 +241,21 @@ Yes!
 
 ---
 
-## Kubernetes resources
+## Interacting with Kubernetes
 
-- The Kubernetes API defines a lot of objects called *resources*
+- We will interact with our Kubernetes cluster through the Kubernetes API
 
-- These resources are organized by type, or `Kind` (in the 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`)
 
 ---
 

slides/k8s/daemonset.md

@@ -73,18 +73,13 @@
 
 - Dump the `rng` resource in YAML:
   ```bash
-  kubectl get deploy/rng -o yaml --export >rng.yml 
+  kubectl get deploy/rng -o yaml >rng.yml
   ```
 
 - Edit `rng.yml`
 
 ]
 
-Note: `--export` will remove "cluster-specific" information, i.e.:
-- namespace (so that the resource is not tied to a specific namespace)
-- status and creation timestamp (useless when creating a new resource)
-- resourceVersion and uid (these would cause... *interesting* problems)
-
 ---
 
 ## "Casting" a resource to another

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!
 

slides/k8s/kubectlget.md

@@ -79,6 +79,8 @@
 
 ---
 
+class: extra-details
+
 ## Exploring types and definitions
 
 - We can list all available resource types by running `kubectl api-resources`
@@ -102,6 +104,8 @@
 
 ---
 
+class: extra-details
+
 ## Introspection vs. documentation
 
 - We can access the same information by reading the [API documentation](https://kubernetes.io/docs/reference/#api-reference)

slides/k8s/kubectlrun.md

@@ -320,6 +320,8 @@ We could! But the *deployment* would notice it right away, and scale back to the
 
 ---
 
+class: extra-details
+
 ### Streaming logs of many pods
 
 - Let's see what happens if we try to stream the logs for more than 5 pods
@@ -347,6 +349,8 @@ use --max-log-requests to increase the limit
 
 ---
 
+class: extra-details
+
 ## Why can't we stream the logs of many pods?
 
 - `kubectl` opens one connection to the API server per pod

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:
+  (it 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 solutions 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)

slides/k8s/ourapponkube.md

@@ -11,6 +11,7 @@
 
 - Deploy everything else:
   ```bash
+    set -u
     for SERVICE in hasher rng webui worker; do
       kubectl create deployment $SERVICE --image=$REGISTRY/$SERVICE:$TAG
     done