stash

Add oscon2019.container.training

README.md

@@ -39,7 +39,7 @@ your own tutorials.
 All these materials have been gathered in a single repository
 because they have a few things in common:
 
-- some [common slides](slides/common/) that are re-used
+- some [shared slides](slides/shared/) that are re-used
   (and updated) identically between different decks;
 - a [build system](slides/) generating HTML slides from
   Markdown source files;

k8s/elasticsearch-cluster.yaml

@@ -0,0 +1,21 @@
+apiVersion: enterprises.upmc.com/v1
+kind: ElasticsearchCluster
+metadata:
+  name: es
+spec:
+  kibana:
+    image: docker.elastic.co/kibana/kibana-oss:6.1.3
+    image-pull-policy: Always
+  cerebro:
+    image: upmcenterprises/cerebro:0.7.2
+    image-pull-policy: Always
+  elastic-search-image: upmcenterprises/docker-elasticsearch-kubernetes:6.1.3_0
+  image-pull-policy: Always
+  client-node-replicas: 2
+  master-node-replicas: 3
+  data-node-replicas: 3
+  network-host: 0.0.0.0
+  use-ssl: false
+  data-volume-size: 10Gi
+  java-options: "-Xms512m -Xmx512m"
+

k8s/elasticsearch-operator.yaml

@@ -0,0 +1,94 @@
+# This is mirrored from https://github.com/upmc-enterprises/elasticsearch-operator/blob/master/example/controller.yaml but using the elasticsearch-operator namespace instead of operator
+---
+apiVersion: v1
+kind: Namespace
+metadata:
+  name: elasticsearch-operator
+---
+apiVersion: v1
+kind: ServiceAccount
+metadata:
+  name: elasticsearch-operator
+  namespace: elasticsearch-operator
+---
+apiVersion: rbac.authorization.k8s.io/v1beta1
+kind: ClusterRole
+metadata:
+  name: elasticsearch-operator
+rules:
+- apiGroups: ["extensions"]
+  resources: ["deployments", "replicasets", "daemonsets"]
+  verbs: ["create", "get", "update", "delete", "list"]
+- apiGroups: ["apiextensions.k8s.io"]
+  resources: ["customresourcedefinitions"]
+  verbs: ["create", "get", "update", "delete", "list"]
+- apiGroups: ["storage.k8s.io"]
+  resources: ["storageclasses"]
+  verbs: ["get", "list", "create", "delete", "deletecollection"]
+- apiGroups: [""]
+  resources: ["persistentvolumes", "persistentvolumeclaims", "services", "secrets", "configmaps"] 
+  verbs: ["create", "get", "update", "delete", "list"]
+- apiGroups: ["batch"]
+  resources: ["cronjobs", "jobs"]
+  verbs: ["create", "get", "deletecollection", "delete"]
+- apiGroups: [""]
+  resources: ["pods"]
+  verbs: ["list", "get", "watch"]
+- apiGroups: ["apps"]
+  resources: ["statefulsets", "deployments"]
+  verbs: ["*"]
+- apiGroups: ["enterprises.upmc.com"]
+  resources: ["elasticsearchclusters"]
+  verbs: ["*"]
+---
+apiVersion: rbac.authorization.k8s.io/v1beta1
+kind: ClusterRoleBinding
+metadata:
+  name: elasticsearch-operator
+  namespace: elasticsearch-operator
+roleRef:
+  apiGroup: rbac.authorization.k8s.io
+  kind: ClusterRole
+  name: elasticsearch-operator
+subjects:
+- kind: ServiceAccount
+  name: elasticsearch-operator
+  namespace: elasticsearch-operator
+---
+apiVersion: extensions/v1beta1
+kind: Deployment
+metadata:
+  name: elasticsearch-operator
+  namespace: elasticsearch-operator
+spec:
+  replicas: 1
+  template:
+    metadata:
+      labels:
+        name: elasticsearch-operator
+    spec:
+      containers:
+      - name: operator
+        image: upmcenterprises/elasticsearch-operator:0.2.0
+        imagePullPolicy: Always
+        env:
+        - name: NAMESPACE
+          valueFrom:
+            fieldRef:
+              fieldPath: metadata.namespace
+        ports:
+        - containerPort: 8000
+          name: http
+        livenessProbe:
+          httpGet:
+            path: /live
+            port: 8000
+          initialDelaySeconds: 10
+          timeoutSeconds: 10
+        readinessProbe:
+          httpGet:
+            path: /ready
+            port: 8000
+          initialDelaySeconds: 10
+          timeoutSeconds: 5
+      serviceAccount: elasticsearch-operator

k8s/filebeat.yaml

@@ -0,0 +1,167 @@
+---
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: filebeat-config
+  namespace: kube-system
+  labels:
+    k8s-app: filebeat
+data:
+  filebeat.yml: |-
+    filebeat.config:
+      inputs:
+        # Mounted `filebeat-inputs` configmap:
+        path: ${path.config}/inputs.d/*.yml
+        # Reload inputs configs as they change:
+        reload.enabled: false
+      modules:
+        path: ${path.config}/modules.d/*.yml
+        # Reload module configs as they change:
+        reload.enabled: false
+
+    # To enable hints based autodiscover, remove `filebeat.config.inputs` configuration and uncomment this:
+    #filebeat.autodiscover:
+    #  providers:
+    #    - type: kubernetes
+    #      hints.enabled: true
+
+    processors:
+      - add_cloud_metadata:
+
+    cloud.id: ${ELASTIC_CLOUD_ID}
+    cloud.auth: ${ELASTIC_CLOUD_AUTH}
+
+    output.elasticsearch:
+      hosts: ['${ELASTICSEARCH_HOST:elasticsearch}:${ELASTICSEARCH_PORT:9200}']
+      username: ${ELASTICSEARCH_USERNAME}
+      password: ${ELASTICSEARCH_PASSWORD}
+---
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: filebeat-inputs
+  namespace: kube-system
+  labels:
+    k8s-app: filebeat
+data:
+  kubernetes.yml: |-
+    - type: docker
+      containers.ids:
+      - "*"
+      processors:
+        - add_kubernetes_metadata:
+            in_cluster: true
+---
+apiVersion: extensions/v1beta1
+kind: DaemonSet
+metadata:
+  name: filebeat
+  namespace: kube-system
+  labels:
+    k8s-app: filebeat
+spec:
+  template:
+    metadata:
+      labels:
+        k8s-app: filebeat
+    spec:
+      serviceAccountName: filebeat
+      terminationGracePeriodSeconds: 30
+      containers:
+      - name: filebeat
+        image: docker.elastic.co/beats/filebeat-oss:7.0.1
+        args: [
+          "-c", "/etc/filebeat.yml",
+          "-e",
+        ]
+        env:
+        - name: ELASTICSEARCH_HOST
+          value: elasticsearch-es.default.svc.cluster.local
+        - name: ELASTICSEARCH_PORT
+          value: "9200"
+        - name: ELASTICSEARCH_USERNAME
+          value: elastic
+        - name: ELASTICSEARCH_PASSWORD
+          value: changeme
+        - name: ELASTIC_CLOUD_ID
+          value:
+        - name: ELASTIC_CLOUD_AUTH
+          value:
+        securityContext:
+          runAsUser: 0
+          # If using Red Hat OpenShift uncomment this:
+          #privileged: true
+        resources:
+          limits:
+            memory: 200Mi
+          requests:
+            cpu: 100m
+            memory: 100Mi
+        volumeMounts:
+        - name: config
+          mountPath: /etc/filebeat.yml
+          readOnly: true
+          subPath: filebeat.yml
+        - name: inputs
+          mountPath: /usr/share/filebeat/inputs.d
+          readOnly: true
+        - name: data
+          mountPath: /usr/share/filebeat/data
+        - name: varlibdockercontainers
+          mountPath: /var/lib/docker/containers
+          readOnly: true
+      volumes:
+      - name: config
+        configMap:
+          defaultMode: 0600
+          name: filebeat-config
+      - name: varlibdockercontainers
+        hostPath:
+          path: /var/lib/docker/containers
+      - name: inputs
+        configMap:
+          defaultMode: 0600
+          name: filebeat-inputs
+      # data folder stores a registry of read status for all files, so we don't send everything again on a Filebeat pod restart
+      - name: data
+        hostPath:
+          path: /var/lib/filebeat-data
+          type: DirectoryOrCreate
+---
+apiVersion: rbac.authorization.k8s.io/v1beta1
+kind: ClusterRoleBinding
+metadata:
+  name: filebeat
+subjects:
+- kind: ServiceAccount
+  name: filebeat
+  namespace: kube-system
+roleRef:
+  kind: ClusterRole
+  name: filebeat
+  apiGroup: rbac.authorization.k8s.io
+---
+apiVersion: rbac.authorization.k8s.io/v1beta1
+kind: ClusterRole
+metadata:
+  name: filebeat
+  labels:
+    k8s-app: filebeat
+rules:
+- apiGroups: [""] # "" indicates the core API group
+  resources:
+  - namespaces
+  - pods
+  verbs:
+  - get
+  - watch
+  - list
+---
+apiVersion: v1
+kind: ServiceAccount
+metadata:
+  name: filebeat
+  namespace: kube-system
+  labels:
+    k8s-app: filebeat
+---

k8s/local-path-storage.yaml

@@ -0,0 +1,110 @@
+# This is a local copy of:
+# https://github.com/rancher/local-path-provisioner/blob/master/deploy/local-path-storage.yaml
+---
+apiVersion: v1
+kind: Namespace
+metadata:
+  name: local-path-storage
+---
+apiVersion: v1
+kind: ServiceAccount
+metadata:
+  name: local-path-provisioner-service-account
+  namespace: local-path-storage
+---
+apiVersion: rbac.authorization.k8s.io/v1beta1
+kind: ClusterRole
+metadata:
+  name: local-path-provisioner-role
+  namespace: local-path-storage
+rules:
+- apiGroups: [""]
+  resources: ["nodes", "persistentvolumeclaims"]
+  verbs: ["get", "list", "watch"]
+- apiGroups: [""]
+  resources: ["endpoints", "persistentvolumes", "pods"]
+  verbs: ["*"]
+- apiGroups: [""]
+  resources: ["events"]
+  verbs: ["create", "patch"]
+- apiGroups: ["storage.k8s.io"]
+  resources: ["storageclasses"]
+  verbs: ["get", "list", "watch"]
+---
+apiVersion: rbac.authorization.k8s.io/v1beta1
+kind: ClusterRoleBinding
+metadata:
+  name: local-path-provisioner-bind
+  namespace: local-path-storage
+roleRef:
+  apiGroup: rbac.authorization.k8s.io
+  kind: ClusterRole
+  name: local-path-provisioner-role
+subjects:
+- kind: ServiceAccount
+  name: local-path-provisioner-service-account
+  namespace: local-path-storage
+---
+apiVersion: apps/v1beta2
+kind: Deployment
+metadata:
+  name: local-path-provisioner
+  namespace: local-path-storage
+spec:
+  replicas: 1
+  selector:
+    matchLabels:
+      app: local-path-provisioner
+  template:
+    metadata:
+      labels:
+        app: local-path-provisioner
+    spec:
+      serviceAccountName: local-path-provisioner-service-account
+      containers:
+      - name: local-path-provisioner
+        image: rancher/local-path-provisioner:v0.0.8
+        imagePullPolicy: Always
+        command:
+        - local-path-provisioner
+        - --debug
+        - start
+        - --config
+        - /etc/config/config.json
+        volumeMounts:
+        - name: config-volume
+          mountPath: /etc/config/
+        env:
+        - name: POD_NAMESPACE
+          valueFrom:
+            fieldRef:
+              fieldPath: metadata.namespace
+      volumes:
+        - name: config-volume
+          configMap:
+            name: local-path-config
+---
+apiVersion: storage.k8s.io/v1
+kind: StorageClass
+metadata:
+  name: local-path
+provisioner: rancher.io/local-path
+volumeBindingMode: WaitForFirstConsumer
+reclaimPolicy: Delete
+---
+kind: ConfigMap
+apiVersion: v1
+metadata:
+  name: local-path-config
+  namespace: local-path-storage
+data:
+  config.json: |-
+        {
+                "nodePathMap":[
+                {
+                        "node":"DEFAULT_PATH_FOR_NON_LISTED_NODES",
+                        "paths":["/opt/local-path-provisioner"]
+                }
+                ]
+        }
+

k8s/malicious-pod.yaml

@@ -1,21 +0,0 @@
-apiVersion: v1
-kind: Pod
-metadata:
-  name: malicious
-spec:
-  volumes:
-  - name: slash
-    hostPath:
-      path: /
-  containers:
-  - image: alpine
-    name: alpine
-    securityContext:
-      privileged: true
-    command:
-    - sleep
-    - "1000000000"
-    volumeMounts:
-    - name: slash
-      mountPath: /hostfs
-  restartPolicy: Never

prepare-vms/lib/commands.sh

@@ -229,7 +229,7 @@ EOF"
     pssh "
     if [ ! -x /usr/local/bin/stern ]; then
         ##VERSION##
-        sudo curl -L -o /usr/local/bin/stern https://github.com/wercker/stern/releases/download/1.10.0/stern_linux_amd64 &&
+        sudo curl -L -o /usr/local/bin/stern https://github.com/wercker/stern/releases/download/1.11.0/stern_linux_amd64 &&
         sudo chmod +x /usr/local/bin/stern &&
         stern --completion bash | sudo tee /etc/bash_completion.d/stern
     fi"
@@ -318,6 +318,14 @@ _cmd_listall() {
     done
 }
 
+_cmd ping "Ping VMs in a given tag, to check that they have network access"
+_cmd_ping() {
+    TAG=$1
+    need_tag
+
+    fping < tags/$TAG/ips.txt
+}
+
 _cmd netfix "Disable GRO and run a pinger job on the VMs"
 _cmd_netfix () {
     TAG=$1
@@ -528,6 +536,38 @@ _cmd_weavetest() {
     sh -c \"./weave --local status | grep Connections | grep -q ' 1 failed' || ! echo POD \""
 }
 
+_cmd webssh "Install a WEB SSH server on the machines (port 1080)"
+_cmd_webssh() {
+    TAG=$1
+    need_tag
+    pssh "
+    sudo apt-get update &&
+    sudo apt-get install python-tornado python-paramiko -y"
+    pssh "
+    [ -d webssh ] || git clone https://github.com/jpetazzo/webssh"
+    pssh "
+    for KEYFILE in /etc/ssh/*.pub; do
+      read a b c < \$KEYFILE; echo localhost \$a \$b
+    done > webssh/known_hosts"
+    pssh "cat >webssh.service <<EOF
+[Unit]
+Description=webssh
+
+[Install]
+WantedBy=multi-user.target
+
+[Service]
+WorkingDirectory=/home/ubuntu/webssh
+ExecStart=/usr/bin/env python run.py --fbidhttp=false --port=1080 --policy=reject
+User=nobody
+Group=nogroup
+Restart=always
+EOF"
+    pssh "
+    sudo systemctl enable \$PWD/webssh.service &&
+    sudo systemctl start webssh.service"
+}
+
 greet() {
     IAMUSER=$(aws iam get-user --query 'User.UserName')
     info "Hello! You seem to be UNIX user $USER, and IAM user $IAMUSER."

prepare-vms/lib/infra/aws.sh

@@ -31,6 +31,7 @@ infra_start() {
         die "I could not find which AMI to use in this region. Try another region?"
     fi
     AWS_KEY_NAME=$(make_key_name)
+    AWS_INSTANCE_TYPE=${AWS_INSTANCE_TYPE-t3a.medium}
 
     sep "Starting instances"
     info "         Count: $COUNT"
@@ -38,10 +39,11 @@ infra_start() {
     info "     Token/tag: $TAG"
     info "           AMI: $AMI"
     info "      Key name: $AWS_KEY_NAME"
+    info " Instance type: $AWS_INSTANCE_TYPE"
     result=$(aws ec2 run-instances \
         --key-name $AWS_KEY_NAME \
         --count $COUNT \
-        --instance-type ${AWS_INSTANCE_TYPE-t2.medium} \
+        --instance-type $AWS_INSTANCE_TYPE \
         --client-token $TAG \
         --block-device-mapping 'DeviceName=/dev/sda1,Ebs={VolumeSize=20}' \
         --image-id $AMI)
@@ -97,7 +99,7 @@ infra_disableaddrchecks() {
 }
 
 wait_until_tag_is_running() {
-    max_retry=50
+    max_retry=100
     i=0
     done_count=0
     while [[ $done_count -lt $COUNT ]]; do

prepare-vms/lib/ips-txt-to-html.py

@@ -1,4 +1,4 @@
-#!/usr/bin/env python
+#!/usr/bin/env python3
 import os
 import sys
 import yaml

prepare-vms/settings/admin-dmuc.yaml

@@ -0,0 +1,28 @@
+# Number of VMs per cluster
+clustersize: 1
+
+# The hostname of each node will be clusterprefix + a number
+clusterprefix: dmuc
+
+# Jinja2 template to use to generate ready-to-cut cards
+cards_template: cards.html
+
+# Use "Letter" in the US, and "A4" everywhere else
+paper_size: A4
+
+# Feel free to reduce this if your printer can handle it
+paper_margin: 0.2in
+
+# Note: paper_size and paper_margin only apply to PDF generated with pdfkit.
+# If you print (or generate a PDF) using ips.html, they will be ignored.
+# (The equivalent parameters must be set from the browser's print dialog.)
+
+# This can be "test" or "stable"
+engine_version: stable
+
+# These correspond to the version numbers visible on their respective GitHub release pages
+compose_version: 1.24.1
+machine_version: 0.14.0
+
+# Password used to connect with the "docker user"
+docker_user_password: training

prepare-vms/settings/admin-kubenet.yaml

@@ -0,0 +1,28 @@
+# Number of VMs per cluster
+clustersize: 3
+
+# The hostname of each node will be clusterprefix + a number
+clusterprefix: kubenet
+
+# Jinja2 template to use to generate ready-to-cut cards
+cards_template: cards.html
+
+# Use "Letter" in the US, and "A4" everywhere else
+paper_size: A4
+
+# Feel free to reduce this if your printer can handle it
+paper_margin: 0.2in
+
+# Note: paper_size and paper_margin only apply to PDF generated with pdfkit.
+# If you print (or generate a PDF) using ips.html, they will be ignored.
+# (The equivalent parameters must be set from the browser's print dialog.)
+
+# This can be "test" or "stable"
+engine_version: stable
+
+# These correspond to the version numbers visible on their respective GitHub release pages
+compose_version: 1.24.1
+machine_version: 0.14.0
+
+# Password used to connect with the "docker user"
+docker_user_password: training

prepare-vms/settings/admin-kuberouter.yaml

@@ -0,0 +1,28 @@
+# Number of VMs per cluster
+clustersize: 3
+
+# The hostname of each node will be clusterprefix + a number
+clusterprefix: kuberouter
+
+# Jinja2 template to use to generate ready-to-cut cards
+cards_template: cards.html
+
+# Use "Letter" in the US, and "A4" everywhere else
+paper_size: A4
+
+# Feel free to reduce this if your printer can handle it
+paper_margin: 0.2in
+
+# Note: paper_size and paper_margin only apply to PDF generated with pdfkit.
+# If you print (or generate a PDF) using ips.html, they will be ignored.
+# (The equivalent parameters must be set from the browser's print dialog.)
+
+# This can be "test" or "stable"
+engine_version: stable
+
+# These correspond to the version numbers visible on their respective GitHub release pages
+compose_version: 1.24.1
+machine_version: 0.14.0
+
+# Password used to connect with the "docker user"
+docker_user_password: training

prepare-vms/settings/admin-test.yaml

@@ -0,0 +1,28 @@
+# Number of VMs per cluster
+clustersize: 3
+
+# The hostname of each node will be clusterprefix + a number
+clusterprefix: test
+
+# Jinja2 template to use to generate ready-to-cut cards
+cards_template: cards.html
+
+# Use "Letter" in the US, and "A4" everywhere else
+paper_size: A4
+
+# Feel free to reduce this if your printer can handle it
+paper_margin: 0.2in
+
+# Note: paper_size and paper_margin only apply to PDF generated with pdfkit.
+# If you print (or generate a PDF) using ips.html, they will be ignored.
+# (The equivalent parameters must be set from the browser's print dialog.)
+
+# This can be "test" or "stable"
+engine_version: stable
+
+# These correspond to the version numbers visible on their respective GitHub release pages
+compose_version: 1.24.1
+machine_version: 0.14.0
+
+# Password used to connect with the "docker user"
+docker_user_password: training

prepare-vms/settings/example.yaml

@@ -0,0 +1,30 @@
+# customize your cluster size, your cards template, and the versions
+
+# Number of VMs per cluster
+clustersize: 5
+
+# The hostname of each node will be clusterprefix + a number
+clusterprefix: node
+
+# Jinja2 template to use to generate ready-to-cut cards
+cards_template: cards.html
+
+# Use "Letter" in the US, and "A4" everywhere else
+paper_size: Letter
+
+# Feel free to reduce this if your printer can handle it
+paper_margin: 0.2in
+
+# Note: paper_size and paper_margin only apply to PDF generated with pdfkit.
+# If you print (or generate a PDF) using ips.html, they will be ignored.
+# (The equivalent parameters must be set from the browser's print dialog.)
+
+# This can be "test" or "stable"
+engine_version: test
+
+# These correspond to the version numbers visible on their respective GitHub release pages
+compose_version: 1.24.1
+machine_version: 0.13.0
+
+# Password used to connect with the "docker user"
+docker_user_password: training

prepare-vms/settings/fundamentals.yaml

@@ -7,7 +7,7 @@ clustersize: 1
 clusterprefix: node
 
 # Jinja2 template to use to generate ready-to-cut cards
-cards_template: jerome.html
+cards_template: cards.html
 
 # Use "Letter" in the US, and "A4" everywhere else
 paper_size: Letter
@@ -23,7 +23,7 @@ paper_margin: 0.2in
 engine_version: stable
 
 # These correspond to the version numbers visible on their respective GitHub release pages
-compose_version: 1.22.0
+compose_version: 1.24.1
 machine_version: 0.15.0
 
 # Password used to connect with the "docker user"

prepare-vms/settings/jerome.yaml

@@ -5,7 +5,7 @@ clustersize: 4
 clusterprefix: node
 
 # Jinja2 template to use to generate ready-to-cut cards
-cards_template: jerome.html
+cards_template: cards.html
 
 # Use "Letter" in the US, and "A4" everywhere else
 paper_size: Letter
@@ -21,7 +21,7 @@ paper_margin: 0.2in
 engine_version: stable
 
 # These correspond to the version numbers visible on their respective GitHub release pages
-compose_version: 1.21.1
+compose_version: 1.24.1
 machine_version: 0.14.0
 
 # Password used to connect with the "docker user"

prepare-vms/settings/kube101.yaml

@@ -0,0 +1,31 @@
+# 3 nodes for k8s 101 workshops
+
+# Number of VMs per cluster
+clustersize: 3
+
+# The hostname of each node will be clusterprefix + a number
+clusterprefix: node
+
+# Jinja2 template to use to generate ready-to-cut cards
+cards_template: cards.html
+
+# Use "Letter" in the US, and "A4" everywhere else
+paper_size: Letter
+
+# Feel free to reduce this if your printer can handle it
+paper_margin: 0.2in
+
+# Note: paper_size and paper_margin only apply to PDF generated with pdfkit.
+# If you print (or generate a PDF) using ips.html, they will be ignored.
+# (The equivalent parameters must be set from the browser's print dialog.)
+
+# This can be "test" or "stable"
+engine_version: stable
+
+# These correspond to the version numbers visible on their respective GitHub release pages
+compose_version: 1.24.1
+machine_version: 0.14.0
+
+# Password used to connect with the "docker user"
+docker_user_password: training
+

prepare-vms/settings/swarm.yaml

@@ -0,0 +1,30 @@
+# This file is passed by trainer-cli to scripts/ips-txt-to-html.py
+
+# Number of VMs per cluster
+clustersize: 3
+
+# The hostname of each node will be clusterprefix + a number
+clusterprefix: node
+
+# Jinja2 template to use to generate ready-to-cut cards
+cards_template: cards.html
+
+# Use "Letter" in the US, and "A4" everywhere else
+paper_size: Letter
+
+# Feel free to reduce this if your printer can handle it
+paper_margin: 0.2in
+
+# Note: paper_size and paper_margin only apply to PDF generated with pdfkit.
+# If you print (or generate a PDF) using ips.html, they will be ignored.
+# (The equivalent parameters must be set from the browser's print dialog.)
+
+# This can be "test" or "stable"
+engine_version: stable
+
+# These correspond to the version numbers visible on their respective GitHub release pages
+compose_version: 1.24.1
+machine_version: 0.15.0
+
+# Password used to connect with the "docker user"
+docker_user_password: training

prepare-vms/setup-admin-clusters.sh

@@ -1,15 +1,20 @@
 #!/bin/sh
 set -e
 
-INFRA=infra/aws-eu-west-3
+export AWS_INSTANCE_TYPE=t3a.small
+
+INFRA=infra/aws-us-west-2
 
 STUDENTS=2
 
-TAG=admin-dmuc
+PREFIX=$(date +%Y-%m-%d-%H-%M)
+
+SETTINGS=admin-dmuc
+TAG=$PREFIX-$SETTINGS
 ./workshopctl start \
 	--tag $TAG \
 	--infra $INFRA \
-	--settings settings/$TAG.yaml \
+	--settings settings/$SETTINGS.yaml \
 	--count $STUDENTS
 
 ./workshopctl deploy $TAG
@@ -17,37 +22,45 @@ TAG=admin-dmuc
 ./workshopctl kubebins $TAG
 ./workshopctl cards $TAG
 
-TAG=admin-kubenet
+SETTINGS=admin-kubenet
+TAG=$PREFIX-$SETTINGS
 ./workshopctl start \
 	--tag $TAG \
 	--infra $INFRA \
-	--settings settings/$TAG.yaml \
+	--settings settings/$SETTINGS.yaml \
 	--count $((3*$STUDENTS))
 
+./workshopctl disableaddrchecks $TAG
 ./workshopctl deploy $TAG
 ./workshopctl kubebins $TAG
-./workshopctl disableaddrchecks $TAG
 ./workshopctl cards $TAG
 
-TAG=admin-kuberouter
+SETTINGS=admin-kuberouter
+TAG=$PREFIX-$SETTINGS
 ./workshopctl start \
 	--tag $TAG \
 	--infra $INFRA \
-	--settings settings/$TAG.yaml \
+	--settings settings/$SETTINGS.yaml \
 	--count $((3*$STUDENTS))
 
+./workshopctl disableaddrchecks $TAG
 ./workshopctl deploy $TAG
 ./workshopctl kubebins $TAG
-./workshopctl disableaddrchecks $TAG
 ./workshopctl cards $TAG
 
-TAG=admin-test
+#INFRA=infra/aws-us-west-1
+
+export AWS_INSTANCE_TYPE=t3a.medium
+
+SETTINGS=admin-test
+TAG=$PREFIX-$SETTINGS
 ./workshopctl start \
 	--tag $TAG \
 	--infra $INFRA \
-	--settings settings/$TAG.yaml \
+	--settings settings/$SETTINGS.yaml \
 	--count $((3*$STUDENTS))
 
 ./workshopctl deploy $TAG
 ./workshopctl kube $TAG 1.13.5
 ./workshopctl cards $TAG
+

prepare-vms/templates/cards.html

@@ -0,0 +1,218 @@
+{# Feel free to customize or override anything in there! #}
+
+{%- set url = "http://FIXME.container.training/" -%}
+{%- set pagesize = 9 -%}
+{%- set lang = "en" -%}
+{%- set event = "training session" -%}
+{%- set backside = False -%}
+{%- set image = "kube" -%}
+{%- set clusternumber = 100 -%}
+
+{%- set image_src = {
+	"docker": "https://s3-us-west-2.amazonaws.com/www.breadware.com/integrations/docker.png",
+	"swarm": "https://cdn.wp.nginx.com/wp-content/uploads/2016/07/docker-swarm-hero2.png",
+	"kube": "https://avatars1.githubusercontent.com/u/13629408",
+	"enix": "https://enix.io/static/img/logos/logo-domain-cropped.png",
+    }[image] -%}
+{%- if lang == "en" and clustersize == 1 -%}
+	{%- set intro -%}
+	Here is the connection information to your very own
+	machine for this {{ event }}.
+	You can connect to this VM with any SSH client.
+	{%- endset -%}
+    {%- set listhead -%}
+    Your machine is:
+	{%- endset -%}
+{%- endif -%}
+{%- if lang == "en" and clustersize != 1 -%}
+	{%- set intro -%}
+	Here is the connection information to your very own
+	cluster for this {{ event }}.
+	You can connect to each VM with any SSH client.
+	{%- endset -%}
+    {%- set listhead -%}
+    Your machines are:
+	{%- endset -%}
+{%- endif -%}
+{%- if lang == "fr" and clustersize == 1 -%}
+	{%- set intro -%}
+	Voici les informations permettant de se connecter à votre
+	machine pour cette formation.
+	Vous pouvez vous connecter à cette machine virtuelle
+	avec n'importe quel client SSH.
+	{%- endset -%}
+    {%- set listhead -%}
+    Adresse IP:
+	{%- endset -%}
+{%- endif -%}
+{%- if lang == "en" and clusterprefix != "node" -%}
+	{%- set intro -%}
+    Here is the connection information for the
+    <strong>{{ clusterprefix }}</strong> environment.
+	{%- endset -%}
+{%- endif -%}
+{%- if lang == "fr" and clustersize != 1 -%}
+	{%- set intro -%}
+	Voici les informations permettant de se connecter à votre
+	cluster pour cette formation.
+	Vous pouvez vous connecter à chaque machine virtuelle
+	avec n'importe quel client SSH.
+	{%- endset -%}
+    {%- set listhead -%}
+	Adresses IP:
+	{%- endset -%}
+{%- endif -%}
+{%- if lang == "en"  -%}
+	{%- set slides_are_at -%}
+	You can find the slides at:
+	{%- endset -%}
+{%- endif -%}
+{%- if lang == "fr" -%}
+	{%- set slides_are_at -%}
+  	Le support de formation est à l'adresse suivante :
+	{%- endset -%}
+{%- endif -%}
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+<html>
+<head><style>
+@import url('https://fonts.googleapis.com/css?family=Slabo+27px');
+
+body, table {
+    margin: 0;
+    padding: 0;
+    line-height: 1em;
+    font-size: 15px;
+    font-family: 'Slabo 27px';
+}
+
+table {
+    border-spacing: 0;
+    margin-top: 0.4em;
+    margin-bottom: 0.4em;
+    border-left: 0.8em double grey;
+    padding-left: 0.4em;
+}
+
+div {
+    float: left;
+    border: 1px dotted black;
+    {% if backside %}
+    height: 31%;
+    {% endif %}
+    padding-top: 1%;
+    padding-bottom: 1%;
+    /* columns * (width+left+right) < 100% */
+    /*
+    width: 21.5%;
+    padding-left: 1.5%;
+    padding-right: 1.5%;
+    */
+    /**/
+    width: 30%;
+    padding-left: 1.5%;
+    padding-right: 1.5%;
+    /**/    
+}
+
+p {
+    margin: 0.4em 0 0.4em 0;
+}
+
+div.back {
+	border: 1px dotted white;
+}
+
+div.back p {
+    margin: 0.5em 1em 0 1em;
+}
+
+img {
+    height: 4em;
+    float: right;
+    margin-right: -0.2em;
+}
+
+/*
+img.enix {
+    height: 4.0em;
+    margin-top: 0.4em;
+}
+
+img.kube {
+    height: 4.2em;
+    margin-top: 1.7em;
+}
+*/
+
+.logpass {
+    font-family: monospace;
+    font-weight: bold;
+}
+
+.pagebreak {
+    page-break-after: always;
+    clear: both;
+    display: block;
+    height: 8px;
+}
+</style></head>
+<body>
+{% for cluster in clusters %}
+    <div>
+        <p>{{ intro }}</p>
+        <p>
+            <img src="{{ image_src }}" />
+            <table>
+            	{% if clusternumber != None %}
+	            <tr><td>cluster:</td></tr>
+	            <tr><td class="logpass">{{ clusternumber + loop.index }}</td></tr>
+            	{% endif %}
+                <tr><td>login:</td></tr>
+                <tr><td class="logpass">docker</td></tr>
+                <tr><td>password:</td></tr>
+                <tr><td class="logpass">{{ docker_user_password }}</td></tr>
+            </table>
+
+        </p>
+        <p>
+            {{ listhead }}
+            <table>
+                {% for node in cluster %}
+                <tr>
+                	<td>{{ clusterprefix }}{{ loop.index }}:</td>
+                	<td>{{ node }}</td>
+                </tr>
+                {% endfor %}
+            </table>
+        </p>
+
+        <p>
+        	{{ slides_are_at }}
+            <center>{{ url }}</center>
+        </p>
+    </div>
+    {% if loop.index%pagesize==0 or loop.last %}
+        <span class="pagebreak"></span>
+        {% if backside %}
+			{% for x in range(pagesize) %}
+		        <div class="back">
+		        <br/>
+				<p>You got this at the workshop
+				"Getting Started With Kubernetes and Container Orchestration"
+				during QCON London (March 2019).</p>
+				<p>If you liked that workshop,
+				I can train your team or organization
+				on Docker, container, and Kubernetes,
+				with curriculums of 1 to 5 days.
+				</p>
+				<p>Interested? Contact me at:</p>
+				<p>jerome.petazzoni@gmail.com</p>
+				<p>Thank you!</p>
+		        </div>
+			{% endfor %}
+		<span class="pagebreak"></span>
+		{% endif %}
+    {% endif %}
+{% endfor %}
+</body>
+</html>

prepare-vms/templates/jerome.html

@@ -1,113 +0,0 @@
-{# Feel free to customize or override anything in there! #}
-{%- set url = "http://wwrk-2019-05.container.training/" -%}
-{%- set pagesize = 9 -%}
-{%- set workshop_name = "training session" -%}
-{%- if clustersize == 1 -%}
-    {%- set cluster_or_machine = "Docker machine" -%}
-    {%- set this_or_each = "this" -%}
-    {%- set machine_is_or_machines_are = "machine is" -%}
-    {%- set image_src = "https://s3-us-west-2.amazonaws.com/www.breadware.com/integrations/docker.png" -%}
-{%- else -%}
-    {%- set cluster_or_machine = "Kubernetes cluster" -%}
-    {%- set this_or_each = "each" -%}
-    {%- set machine_is_or_machines_are = "machines are" -%}
-    {%- set image_src_swarm = "https://cdn.wp.nginx.com/wp-content/uploads/2016/07/docker-swarm-hero2.png" -%}
-    {%- set image_src_kube = "https://avatars1.githubusercontent.com/u/13629408" -%}
-    {%- set image_src = image_src_kube -%}
-{%- endif -%}
-<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
-<html>
-<head><style>
-@import url('https://fonts.googleapis.com/css?family=Slabo+27px');
-body, table {
-    margin: 0;
-    padding: 0;
-    line-height: 1.0em;
-    font-size: 15px;
-    font-family: 'Slabo 27px';
-}
-
-table {
-    border-spacing: 0;
-    margin-top: 0.4em;
-    margin-bottom: 0.4em;
-    border-left: 0.8em double grey;
-    padding-left: 0.4em;
-}
-
-div {
-    float: left;
-    border: 1px dotted black;
-    height: 31%;
-    padding-top: 1%;
-    padding-bottom: 1%;
-    /* columns * (width+left+right) < 100% */
-    width: 30%;
-    padding-left: 1.5%;
-    padding-right: 1.5%;
-}
-
-div.back {
-	border: 1px dotted white;
-}
-
-div.back p {
-    margin: 0.5em 1em 0 1em;
-}
-
-p {
-    margin: 0.4em 0 0.8em 0;
-}
-
-img {
-    height: 5em;
-    float: right;
-    margin-right: 1em;
-}
-
-.logpass {
-    font-family: monospace;
-    font-weight: bold;
-}
-
-.pagebreak {
-    page-break-after: always;
-    clear: both;
-    display: block;
-    height: 8px;
-}
-</style></head>
-<body>
-{% for cluster in clusters %}
-    <div>
-
-        <p>
-            Here is the connection information to your very own
-            {{ cluster_or_machine }} for this {{ workshop_name }}.
-            You can connect to {{ this_or_each }} VM with any SSH client.
-        </p>
-        <p>
-            <img src="{{ image_src }}" />
-            <table>
-                <tr><td>login:</td></tr>
-                <tr><td class="logpass">docker</td></tr>
-                <tr><td>password:</td></tr>
-                <tr><td class="logpass">{{ docker_user_password }}</td></tr>
-            </table>
-
-        </p>
-        <p>
-            Your {{ machine_is_or_machines_are }}:
-            <table>
-                {% for node in cluster %}
-                <tr><td>node{{ loop.index }}:</td><td>{{ node }}</td></tr>
-                {% endfor %}
-            </table>
-        </p>
-        <p>You can find the slides at:
-            <center>{{ url }}</center>
-        </p>
-    </div>
-{% endfor %}
-</body>
-</html>

slides/Dockerfile

@@ -1,7 +1,4 @@
-FROM alpine
-RUN apk update
-RUN apk add entr
-RUN apk add py-pip
-RUN apk add git
+FROM alpine:3.9
+RUN apk add --no-cache entr py-pip git
 COPY requirements.txt .
 RUN pip install -r requirements.txt

slides/_redirects

@@ -2,4 +2,6 @@
 #/ /kube-halfday.yml.html 200
 #/ /kube-fullday.yml.html 200
 #/ /kube-twodays.yml.html 200
-/ /wwrk.yml.html 200!
+
+# And this allows to do "git clone https://container.training".
+/info/refs service=git-upload-pack https://github.com/jpetazzo/container.training/info/refs?service=git-upload-pack

slides/assignments/TODO.txt

@@ -0,0 +1,34 @@
+# Our sample application
+
+No assignment
+
+# Kubernetes concepts
+
+Do we want some kind of multiple-choice quiz?
+
+# First contact with kubectl
+
+Start some pre-defined image and check its logs
+(Do we want to make a custom "mystery image" that shows a message
+and then sleeps forever?)
+
+Start another one (to make sure they understand that they need
+to specify a unique name each time)
+
+Provide as many ways as you can to figure out on which node
+these pods are running (even if you only have one node).
+
+# Exposing containers
+
+Start a container running the official tomcat image.
+Expose it.
+Connect to it.
+
+# Shipping apps
+
+(We need a few images for a demo app other than DockerCoins?)
+
+Start the components of the app.
+Expose what needs to be exposed.
+Connect to the app and check that it works.
+

slides/assignments/setup.md

@@ -0,0 +1,105 @@
+## Assignment: get Kubernetes
+
+- In order to do the other assignments, we need a Kubernetes cluster
+
+- Here are some *free* options:
+
+  - Docker Desktop
+
+  - Minikube
+
+  - Online sandbox like Katacoda
+
+- You can also get a managed cluster (but this costs some money)
+
+---
+
+## Recommendation 1: Docker Desktop
+
+- If you are already using Docker Desktop, use it for Kubernetes
+
+- If you are running MacOS, [install Docker Desktop](https://docs.docker.com/docker-for-mac/install/)
+
+  - you will need a post-2010 Mac
+
+  - you will need macOS Sierra 10.12 or later
+
+- If you are running Windows 10, [install Docker Desktop](https://docs.docker.com/docker-for-windows/install/)
+
+  - you will need Windows 10 64 bits Pro, Enterprise, or Education
+
+  - virtualization needs to be enabled in your BIOS
+
+- Then [enable Kubernetes](https://blog.docker.com/2018/07/kubernetes-is-now-available-in-docker-desktop-stable-channel/) if it's not already on
+
+---
+
+## Recommendation 2: Minikube
+
+- In some scenarios, you can't use Docker Desktop:
+
+  - if you run Linux
+
+  - if you are running an unsupported version of Windows
+
+- You might also want to install Minikube for other reasons
+
+  (there are more tutorials and instructions out there for Minikube)
+
+- Minikube installation is a bit more complex
+
+  (depending on which hypervisor and OS you are using)
+
+---
+
+## Minikube installation details
+
+- Minikube typically runs in a local virtual machine
+
+- It supports multiple hypervisors:
+
+  - VirtualBox (Linux, Mac, Windows)
+
+  - HyperV (Windows)
+
+  - HyperKit, VMware (Mac)
+
+  - KVM (Linux)
+
+- Check the [documentation](https://kubernetes.io/docs/tasks/tools/install-minikube/) for details relevant to your setup
+
+---
+
+## Recommendation 3: learning platform
+
+- Sometimes, you can't even install Minikube
+
+  (computer locked by IT policies; insufficient resources...)
+
+- In that case, you can use a platform like:
+
+  - Katacoda
+
+  - Play-with-Kubernetes
+
+---
+
+## Recommendation 4: hosted cluster
+
+- You can also get your own hosted cluster
+
+- This will cost a little bit of money
+
+  (unless you have free hosting credits)
+
+- Setup will vary depending on the provider, platform, etc.
+
+---
+
+class: assignment
+
+- Make sure that you have a Kubernetes cluster
+
+- You should be able to run `kubectl get nodes` and see a list of nodes
+
+- These nodes should be in `Ready` state

slides/containers/Ambassadors.md

@@ -150,7 +150,7 @@ Different deployments will use different underlying technologies.
 * Ad-hoc deployments can use a master-less discovery protocol
   like avahi to register and discover services.
 * It is also possible to do one-shot reconfiguration of the
-  ambassadors. It is slightly less dynamic but has much less
+  ambassadors. It is slightly less dynamic but has far fewer
   requirements.
 * Ambassadors can be used in addition to, or instead of, overlay networks.
 

slides/containers/Application_Configuration.md

@@ -98,13 +98,13 @@ COPY prometheus.conf /etc
 
 * Allows arbitrary customization and complex configuration files.
 
-* Requires to write a configuration file. (Obviously!)
+* Requires writing a configuration file. (Obviously!)
 
-* Requires to build an image to start the service.
+* Requires building an image to start the service.
 
-* Requires to rebuild the image to reconfigure the service.
+* Requires rebuilding the image to reconfigure the service.
 
-* Requires to rebuild the image to upgrade the service.
+* Requires rebuilding the image to upgrade the service.
 
 * Configured images can be stored in registries.
 
@@ -132,11 +132,11 @@ docker run -v appconfig:/etc/appconfig myapp
 
 * Allows arbitrary customization and complex configuration files.
 
-* Requires to create a volume for each different configuration.
+* Requires creating a volume for each different configuration.
 
 * Services with identical configurations can use the same volume.
 
-* Doesn't require to build / rebuild an image when upgrading / reconfiguring.
+* Doesn't require building / rebuilding an image when upgrading / reconfiguring.
 
 * Configuration can be generated or edited through another container.
 
@@ -198,4 +198,4 @@ E.g.:
 
 - read the secret on stdin when the service starts,
 
-- pass the secret using an API endpoint.
+- pass the secret using an API endpoint.

slides/containers/Background_Containers.md

@@ -257,7 +257,7 @@ $ docker kill 068 57ad
 The `stop` and `kill` commands can take multiple container IDs.
 
 Those containers will be terminated immediately (without
-the 10 seconds delay).
+the 10-second delay).
 
 Let's check that our containers don't show up anymore:
 

slides/containers/Cmd_And_Entrypoint.md

@@ -222,16 +222,16 @@ CMD ["hello world"]
 Let's build it:
 
 ```bash
-$ docker build -t figlet .
+$ docker build -t myfiglet .
 ...
 Successfully built 6e0b6a048a07
-Successfully tagged figlet:latest
+Successfully tagged myfiglet:latest
 ```
 
 Run it without parameters:
 
 ```bash
-$ docker run figlet
+$ docker run myfiglet
  _          _   _                             _        
 | |        | | | |                           | |    |  
 | |     _  | | | |  __             __   ,_   | |  __|  
@@ -246,7 +246,7 @@ $ docker run figlet
 Now let's pass extra arguments to the image.
 
 ```bash
-$ docker run figlet hola mundo
+$ docker run myfiglet hola mundo
  _           _                                               
 | |         | |                                      |       
 | |     __  | |  __,     _  _  _           _  _    __|   __  
@@ -262,13 +262,13 @@ We overrode `CMD` but still used `ENTRYPOINT`.
 
 What if we want to run a shell in our container?
 
-We cannot just do `docker run figlet bash` because
+We cannot just do `docker run myfiglet bash` because
 that would just tell figlet to display the word "bash."
 
 We use the `--entrypoint` parameter:
 
 ```bash
-$ docker run -it --entrypoint bash figlet
+$ docker run -it --entrypoint bash myfiglet
 root@6027e44e2955:/# 
 ```
 

slides/containers/Container_Engines.md

@@ -86,7 +86,7 @@ like Windows, macOS, Solaris, FreeBSD ...
 
 * No notion of image (container filesystems have to be managed manually).
 
-* Networking has to be setup manually.
+* Networking has to be set up manually.
 
 ---
 
@@ -112,7 +112,7 @@ like Windows, macOS, Solaris, FreeBSD ...
 
 * Strong emphasis on security (through privilege separation).
 
-* Networking has to be setup separately (e.g. through CNI plugins).
+* Networking has to be set up separately (e.g. through CNI plugins).
 
 * Partial image management (pull, but no push).
 
@@ -152,7 +152,7 @@ We're not aware of anyone using it directly (i.e. outside of Kubernetes).
 
 * Basic image support (tar archives and raw disk images).
 
-* Network has to be setup manually.
+* Network has to be set up manually.
 
 ---
 
@@ -164,7 +164,7 @@ We're not aware of anyone using it directly (i.e. outside of Kubernetes).
 
 * Run each container in a lightweight virtual machine.
 
-* Requires to run on bare metal *or* with nested virtualization.
+* Requires running on bare metal *or* with nested virtualization.
 
 ---
 

slides/containers/Container_Network_Model.md

@@ -474,7 +474,7 @@ When creating a network, extra options can be provided.
 
 * `--ip-range` (in CIDR notation) indicates the subnet to allocate from.
 
-* `--aux-address` allows to specify a list of reserved addresses (which won't be allocated to containers).
+* `--aux-address` allows specifying a list of reserved addresses (which won't be allocated to containers).
 
 ---
 
@@ -556,7 +556,7 @@ General idea:
 
 * So far, we have specified which network to use when starting the container.
 
-* The Docker Engine also allows to connect and disconnect while the container runs.
+* The Docker Engine also allows connecting and disconnecting while the container is running.
 
 * This feature is exposed through the Docker API, and through two Docker CLI commands:
 

slides/containers/Dockerfile_Tips.md

@@ -76,6 +76,78 @@ CMD ["python", "app.py"]
 
 ---
 
+## Be careful with `chown`, `chmod`, `mv`
+
+* Layers cannot store efficiently changes in permissions or ownership.
+
+* Layers cannot represent efficiently when a file is moved either.
+
+* As a result, operations like `chown`, `chown`, `mv` can be expensive.
+
+* For instance, in the Dockerfile snippet below, each `RUN` line
+  creates a layer with an entire copy of `some-file`.
+
+  ```dockerfile
+  COPY some-file .
+  RUN chown www-data:www-data some-file
+  RUN chmod 644 some-file
+  RUN mv some-file /var/www
+  ```
+
+* How can we avoid that?
+
+---
+
+## Put files on the right place
+
+* Instead of using `mv`, directly put files at the right place.
+
+* When extracting archives (tar, zip...), merge operations in a single layer.
+
+  Example:
+
+  ```dockerfile
+    ...
+    RUN wget http://.../foo.tar.gz \
+     && tar -zxf foo.tar.gz \
+     && mv foo/fooctl /usr/local/bin \
+     && rm -rf foo
+  ...
+  ```
+
+---
+
+## Use `COPY --chown`
+
+* The Dockerfile instruction `COPY` can take a `--chown` parameter.
+
+  Examples:
+
+  ```dockerfile
+  ...
+  COPY --chown=1000 some-file .
+  COPY --chown=1000:1000 some-file .
+  COPY --chown=www-data:www-data some-file .
+  ```
+
+* The `--chown` flag can specify a user, or a user:group pair.
+
+* The user and group can be specified as names or numbers.
+
+* When using names, the names must exist in `/etc/passwd` or `/etc/group`.
+
+  *(In the container, not on the host!)*
+
+---
+
+## Set correct permissions locally
+
+* Instead of using `chmod`, set the right file permissions locally.
+
+* When files are copied with `COPY`, permissions are preserved.
+
+---
+
 ## Embedding unit tests in the build process
 
 ```dockerfile

slides/containers/First_Containers.md

@@ -259,7 +259,7 @@ bash: figlet: command not found
 
   * work on project
 
-  * when done, shutdown VM
+  * when done, shut down VM
 
   * next time we need to work on project, restart VM as we left it
 
@@ -281,7 +281,7 @@ bash: figlet: command not found
 
   * work on project
 
-  * when done, shutdown container
+  * when done, shut down container
 
   * next time we need to work on project, start a new container
 

slides/containers/Local_Development_Workflow.md

@@ -156,7 +156,7 @@ Option 3:
 
 * Use a *volume* to mount local files into the container
 * Make changes locally
-* Changes are reflected into the container
+* Changes are reflected in the container
 
 ---
 
@@ -176,7 +176,7 @@ $ docker run -d -v $(pwd):/src -P namer
 
 * `namer` is the name of the image we will run.
 
-* We don't specify a command to run because it is already set in the Dockerfile.
+* We don't specify a command to run because it is already set in the Dockerfile via `CMD`.
 
 Note: on Windows, replace `$(pwd)` with `%cd%` (or `${pwd}` if you use PowerShell).
 
@@ -192,7 +192,7 @@ The flag structure is:
 [host-path]:[container-path]:[rw|ro]
 ```
 
-* If `[host-path]` or `[container-path]` doesn't exist it is created.
+* `[host-path]` and `[container-path]` are created if they don't exist.
 
 * You can control the write status of the volume with the `ro` and
   `rw` options.
@@ -255,13 +255,13 @@ color: red;
 
 * Volumes are *not* copying or synchronizing files between the host and the container.
 
-* Volumes are *bind mounts*: a kernel mechanism associating a path to another.
+* Volumes are *bind mounts*: a kernel mechanism associating one path with another.
 
 * Bind mounts are *kind of* similar to symbolic links, but at a very different level.
 
 * Changes made on the host or on the container will be visible on the other side.
 
-  (Since under the hood, it's the same file on both anyway.)
+  (Under the hood, it's the same file anyway.)
 
 ---
 
@@ -273,7 +273,7 @@ by Chad Fowler, where he explains the concept of immutable infrastructure.)*
 
 --
 
-* Let's mess up majorly with our container.
+* Let's majorly mess up our container.
 
   (Remove files or whatever.)
 
@@ -319,7 +319,7 @@ and *canary deployments*.
    <br/>
    Use the `-v` flag to mount our source code inside the container.
 
-3. Edit the source code outside the containers, using regular tools.
+3. Edit the source code outside the container, using familiar tools.
    <br/>
    (vim, emacs, textmate...)
 

slides/containers/Namespaces_Cgroups.md

@@ -86,13 +86,13 @@ class: extra-details, deep-dive
 
   - the `unshare()` system call.
 
-- The Linux tool `unshare` allows to do that from a shell.
+- The Linux tool `unshare` allows doing that from a shell.
 
 - A new process can re-use none / all / some of the namespaces of its parent.
 
 - It is possible to "enter" a namespace with the `setns()` system call.
 
-- The Linux tool `nsenter` allows to do that from a shell.
+- The Linux tool `nsenter` allows doing that from a shell.
 
 ---
 
@@ -138,11 +138,11 @@ class: extra-details, deep-dive
 
 - gethostname / sethostname
 
-- Allows to set a custom hostname for a container.
+- Allows setting a custom hostname for a container.
 
 - That's (mostly) it!
 
-- Also allows to set the NIS domain.
+- Also allows setting the NIS domain.
 
   (If you don't know what a NIS domain is, you don't have to worry about it!)
 
@@ -392,13 +392,13 @@ class: extra-details
 
 - Processes can have their own root fs (à la chroot).
 
-- Processes can also have "private" mounts. This allows to:
+- Processes can also have "private" mounts. This allows:
 
-  - isolate `/tmp` (per user, per service...)
+  - isolating `/tmp` (per user, per service...)
 
-  - mask `/proc`, `/sys` (for processes that don't need them)
+  - masking `/proc`, `/sys` (for processes that don't need them)
 
-  - mount remote filesystems or sensitive data,
+  - mounting remote filesystems or sensitive data,
     <br/>but make it visible only for allowed processes
 
 - Mounts can be totally private, or shared.
@@ -570,7 +570,7 @@ Check `man 2 unshare` and `man pid_namespaces` if you want more details.
 
 ## User namespace
 
-- Allows to map UID/GID; e.g.:
+- Allows mapping UID/GID; e.g.:
 
   - UID 0→1999 in container C1 is mapped to UID 10000→11999 on host
   - UID 0→1999 in container C2 is mapped to UID 12000→13999 on host
@@ -947,7 +947,7 @@ Killed
 
   (i.e., "this group of process used X seconds of CPU0 and Y seconds of CPU1".)
 
-- Allows to set relative weights used by the scheduler.
+- Allows setting relative weights used by the scheduler.
 
 ---
 
@@ -1101,9 +1101,9 @@ See `man capabilities` for the full list and details.
 
 - Original seccomp only allows `read()`, `write()`, `exit()`, `sigreturn()`.
 
-- The seccomp-bpf extension allows to specify custom filters with BPF rules.
+- The seccomp-bpf extension allows specifying custom filters with BPF rules.
 
-- This allows to filter by syscall, and by parameter.
+- This allows filtering by syscall, and by parameter.
 
 - BPF code can perform arbitrarily complex checks, quickly, and safely.
 

slides/containers/Orchestration_Overview.md

@@ -119,7 +119,7 @@ Now, how are things for our IAAS provider?
 - Solution: *migrate* VMs and shutdown empty servers
   
   (e.g. combine two hypervisors with 40% load into 80%+0%,
-  <br/>and shutdown the one at 0%)
+  <br/>and shut down the one at 0%)
 
 ---
 
@@ -127,7 +127,7 @@ Now, how are things for our IAAS provider?
 
 How do we implement this?
 
-- Shutdown empty hosts (but keep some spare capacity)
+- Shut down empty hosts (but keep some spare capacity)
 
 - Start hosts again when capacity gets low
 
@@ -175,7 +175,7 @@ In practice, these goals often conflict.
 
   - 16 GB RAM, 8 cores, 1 TB disk
 
-- Each week, your team asks:
+- Each week, your team requests:
 
   - one VM with X RAM, Y CPU, Z disk
 

slides/containers/Resource_Limits.md

@@ -72,7 +72,7 @@
 
 - For memory usage, the mechanism is part of the *cgroup* subsystem.
 
-- This subsystem allows to limit the memory for a process or a group of processes.
+- This subsystem allows limiting the memory for a process or a group of processes.
 
 - A container engine leverages these mechanisms to limit memory for a container.
 

slides/containers/Training_Environment.md

@@ -45,13 +45,13 @@ individual Docker VM.*
 
 - The Docker Engine is a daemon (a service running in the background).
 
-- This daemon manages containers, the same way that an hypervisor manages VMs.
+- This daemon manages containers, the same way that a hypervisor manages VMs.
 
 - We interact with the Docker Engine by using the Docker CLI.
 
 - The Docker CLI and the Docker Engine communicate through an API.
 
-- There are many other programs, and many client libraries, to use that API.
+- There are many other programs and client libraries which use that API.
 
 ---
 

slides/containers/Working_With_Volumes.md

@@ -33,13 +33,13 @@ Docker volumes can be used to achieve many things, including:
 
 * Sharing a *single file* between the host and a container.
 
-* Using remote storage and custom storage with "volume drivers".
+* Using remote storage and custom storage with *volume drivers*.
 
 ---
 
 ## Volumes are special directories in a container
 
-Volumes can be declared in two different ways.
+Volumes can be declared in two different ways:
 
 * Within a `Dockerfile`, with a `VOLUME` instruction.
 
@@ -163,7 +163,7 @@ Volumes are not anchored to a specific path.
 
 * Volumes are used with the `-v` option.
 
-* When a host path does not contain a /, it is considered to be a volume name.
+* When a host path does not contain a `/`, it is considered a volume name.
 
 Let's start a web server using the two previous volumes.
 
@@ -189,7 +189,7 @@ $ curl localhost:1234
 
 * In this example, we will run a text editor in the other container.
 
-  (But this could be a FTP server, a WebDAV server, a Git receiver...)
+  (But this could be an FTP server, a WebDAV server, a Git receiver...)
 
 Let's start another container using the `webapps` volume.
 

slides/index.yaml

@@ -1,3 +1,11 @@
+- date: [2019-11-04, 2019-11-05]
+  country: de
+  city: Berlin
+  event: Velocity
+  speaker: jpetazzo
+  title: Deploying and scaling applications with Kubernetes
+  attend: https://conferences.oreilly.com/velocity/vl-eu/public/schedule/detail/79109
+
 - date: 2019-11-13
   country: fr
   city: Marseille
@@ -16,6 +24,15 @@
   lang: fr
   attend: https://enix.io/fr/services/formation/deployer-ses-applications-avec-kubernetes/
 
+- date: 2019-07-16
+  country: us
+  city: Portland, OR
+  event: OSCON
+  speaker: bridgetkromhout
+  title: "Kubernetes 201: Production tooling"
+  attend: https://conferences.oreilly.com/oscon/oscon-or/public/schedule/detail/76390
+  slides: https://oscon2019.container.training
+
 - date: 2019-06-17
   country: ca
   city: Montréal
@@ -31,6 +48,7 @@
   title: Kubernetes for administrators and operators
   speaker: jpetazzo
   attend: https://conferences.oreilly.com/velocity/vl-ca/public/schedule/detail/75313
+  slides: https://kadm-2019-06.container.training/
 
 - date: 2019-05-01
   country: us

slides/k8s/architecture.md

@@ -356,9 +356,9 @@ We demonstrated *update* and *watch* semantics.
 
   - we create a Deployment object
 
-  - the Deployment controller notices it, creates a ReplicaSet
+  - the Deployment controller notices it, and creates a ReplicaSet
 
-  - the ReplicaSet controller notices it, creates a Pod
+  - the ReplicaSet controller notices the ReplicaSet, and creates a Pod
 
 ---
 

slides/k8s/authn-authz.md

@@ -22,7 +22,7 @@
 
 - When the API server receives a request, it tries to authenticate it
 
-  (it examines headers, certificates ... anything available)
+  (it examines headers, certificates... anything available)
 
 - Many authentication methods are available and can be used simultaneously
 
@@ -34,7 +34,7 @@
   - the user ID
   - a list of groups
 
-- The API server doesn't interpret these; it'll be the job of *authorizers*
+- The API server doesn't interpret these; that'll be the job of *authorizers*
 
 ---
 
@@ -50,7 +50,7 @@
 
 - [HTTP basic auth](https://en.wikipedia.org/wiki/Basic_access_authentication)
 
-  (carrying user and password in a HTTP header)
+  (carrying user and password in an HTTP header)
 
 - Authentication proxy
 
@@ -88,7 +88,7 @@
 
   (i.e. they are not stored in etcd or anywhere else)
 
-- Users can be created (and given membership to groups) independently of the API
+- Users can be created (and added to groups) independently of the API
 
 - The Kubernetes API can be set up to use your custom CA to validate client certs
 
@@ -193,7 +193,7 @@ class: extra-details
 
   (the kind that you can view with `kubectl get secrets`)
 
-- Service accounts are generally used to grant permissions to applications, services ...
+- Service accounts are generally used to grant permissions to applications, services...
 
   (as opposed to humans)
 
@@ -217,7 +217,7 @@ class: extra-details
 
 .exercise[
 
-- The resource name is `serviceaccount` or `sa` in short:
+- The resource name is `serviceaccount` or `sa` for short:
   ```bash
   kubectl get sa
   ```
@@ -309,7 +309,7 @@ class: extra-details
 
 - The API "sees" us as a different user
 
-- But neither user has any right, so we can't do nothin'
+- But neither user has any rights, so we can't do nothin'
 
 - Let's change that!
 
@@ -339,9 +339,9 @@ class: extra-details
 
 - A rule is a combination of:
 
-  - [verbs](https://kubernetes.io/docs/reference/access-authn-authz/authorization/#determine-the-request-verb) like create, get, list, update, delete ...
+  - [verbs](https://kubernetes.io/docs/reference/access-authn-authz/authorization/#determine-the-request-verb) like create, get, list, update, delete...
 
-  - resources (as in "API resource", like pods, nodes, services ...)
+  - resources (as in "API resource," like pods, nodes, services...)
 
   - resource names (to specify e.g. one specific pod instead of all pods)
 
@@ -375,13 +375,13 @@ class: extra-details
 
 - We can also define API resources ClusterRole and ClusterRoleBinding
 
-- These are a superset, allowing to:
+- These are a superset, allowing us to:
 
   - specify actions on cluster-wide objects (like nodes)
 
   - operate across all namespaces
 
-- We can create Role and RoleBinding resources within a namespaces
+- We can create Role and RoleBinding resources within a namespace
 
 - ClusterRole and ClusterRoleBinding resources are global
 
@@ -389,13 +389,13 @@ class: extra-details
 
 ## Pods and service accounts
 
-- A pod can be associated to a service account
+- A pod can be associated with a service account
 
-  - by default, it is associated to the `default` service account
+  - by default, it is associated with the `default` service account
 
-  - as we've seen earlier, this service account has no permission anyway
+  - as we saw earlier, this service account has no permissions anyway
 
-- The associated token is exposed into the pod's filesystem
+- The associated token is exposed to the pod's filesystem
 
   (in `/var/run/secrets/kubernetes.io/serviceaccount/token`)
 
@@ -460,7 +460,7 @@ class: extra-details
 
 ]
 
-It's important to note a couple of details in these flags ...
+It's important to note a couple of details in these flags...
 
 ---
 
@@ -493,13 +493,13 @@ It's important to note a couple of details in these flags ...
 
   - again, the command would have worked fine (no error)
 
-  - ... but our API requests would have been denied later
+  - ...but our API requests would have been denied later
 
 - What's about the `default:` prefix?
 
   - that's the namespace of the service account
 
-  - yes, it could be inferred from context, but ... `kubectl` requires it
+  - yes, it could be inferred from context, but... `kubectl` requires it
 
 ---
 
@@ -590,7 +590,7 @@ class: extra-details
 
 *In many situations, these roles will be all you need.*
 
-*You can also customize them if needed!*
+*You can also customize them!*
 
 ---
 
@@ -652,7 +652,7 @@ class: extra-details
   kubectl describe clusterrolebinding cluster-admin
   ```
 
-- This binding associates `system:masters` to the cluster role `cluster-admin`
+- This binding associates `system:masters` with the cluster role `cluster-admin`
 
 - And the `cluster-admin` is, basically, `root`:
   ```bash
@@ -667,7 +667,7 @@ class: extra-details
 
 - For auditing purposes, sometimes we want to know who can perform an action
 
-- Here is a proof-of-concept tool by Aqua Security, doing exactly that:
+- There is a proof-of-concept tool by Aqua Security which does exactly that:
 
   https://github.com/aquasecurity/kubectl-who-can
 

slides/k8s/cloud-controller-manager.md

@@ -20,15 +20,15 @@
 
 - Configuring routing tables in the cloud network (specific to GCE)
 
-- Updating node labels to indicate region, zone, instance type ...
+- Updating node labels to indicate region, zone, instance type...
 
 - Obtain node name, internal and external addresses from cloud metadata service
 
 - Deleting nodes from Kubernetes when they're deleted in the cloud
 
-- Managing *some* volumes (e.g. ELBs, AzureDisks ...)
+- Managing *some* volumes (e.g. ELBs, AzureDisks...)
 
-  (Eventually, volumes will be managed by the CSI)
+  (Eventually, volumes will be managed by the Container Storage Interface)
 
 ---
 
@@ -83,7 +83,7 @@ The list includes the following providers:
 
 ## Audience questions
 
-- What kind of clouds are you using / planning to use?
+- What kind of clouds are you using/planning to use?
 
 - What kind of details would you like to see in this section?
 
@@ -105,7 +105,7 @@ The list includes the following providers:
 
 - When using managed clusters, this is done automatically
 
-- There is very little documentation to write the configuration file
+- There is very little documentation on writing the configuration file
 
   (except for OpenStack)
 
@@ -123,7 +123,7 @@ The list includes the following providers:
 
 - To get these addresses, the node needs to communicate with the control plane
 
-- ... Which means joining the cluster
+- ...Which means joining the cluster
 
 (The problem didn't occur when cloud-specific code was running in kubelet: kubelet could obtain the required information directly from the cloud provider's metadata service.)
 

slides/k8s/cluster-backup.md

@@ -6,7 +6,7 @@
 
   - error recovery (human or process has altered or corrupted data)
 
-  - cloning environments (for testing, validation ...)
+  - cloning environments (for testing, validation...)
 
 - Let's see the strategies and tools available with Kubernetes!
 
@@ -18,13 +18,13 @@
 
   (it gives us replication primitives)
 
-- Kubernetes helps us to clone / replicate environments
+- Kubernetes helps us clone / replicate environments
 
   (all resources can be described with manifests)
 
 - Kubernetes *does not* help us with error recovery
 
-- We still need to backup / snapshot our data:
+- We still need to back up/snapshot our data:
 
   - with database backups (mysqldump, pgdump, etc.)
 
@@ -58,7 +58,7 @@
 
 - If our deployment system isn't fully automated, it should at least be documented
 
-- Litmus test: how long does it take to deploy a cluster ...
+- Litmus test: how long does it take to deploy a cluster...
 
   - for a senior engineer?
 
@@ -66,7 +66,7 @@
 
 - Does it require external intervention?
 
-  (e.g. provisioning servers, signing TLS certs ...)
+  (e.g. provisioning servers, signing TLS certs...)
 
 ---
 
@@ -108,7 +108,7 @@
 
 - For real applications: add resources (as YAML files)
 
-- For applications deployed multiple times: Helm, Kustomize ...
+- For applications deployed multiple times: Helm, Kustomize...
 
   (staging and production count as "multiple times")
 

slides/k8s/cluster-upgrade.md

@@ -287,8 +287,8 @@
 - Download the configuration on each node, and upgrade kubelet:
   ```bash
     for N in 1 2 3; do
-    	ssh node$N sudo kubeadm upgrade node config --kubelet-version v1.14.2
-  	  ssh node $N sudo apt install kubelet=1.14.2-00
+      ssh test$N sudo kubeadm upgrade node config --kubelet-version v1.14.2
+      ssh test$N sudo apt install kubelet=1.14.2-00
     done
   ```
 ]

slides/k8s/cni.md

@@ -26,7 +26,7 @@
 
 The reference plugins are available [here].
 
-Look into each plugin's directory for its documentation.
+Look in each plugin's directory for its documentation.
 
 [here]: https://github.com/containernetworking/plugins/tree/master/plugins
 
@@ -66,6 +66,8 @@ Look into each plugin's directory for its documentation.
 
 ---
 
+class: extra-details
+
 ## Conf vs conflist
 
 - There are two slightly different configuration formats
@@ -98,7 +100,7 @@ class: extra-details
 
   - CNI_NETNS: path to network namespace file
 
-  - CNI_IFNAME: how the network interface should be named
+  - CNI_IFNAME: what the network interface should be named
 
 - The network configuration must be provided to the plugin on stdin
 
@@ -188,12 +190,16 @@ class: extra-details
 
 - ... But this time, the controller manager will allocate `podCIDR` subnets
 
-- We will start kube-router with a DaemonSet
+  (so that we don't have to manually assign subnets to individual nodes)
 
-- This DaemonSet will start one instance of kube-router on each node
+- We will create a DaemonSet for kube-router
+
+- We will join nodes to the cluster
+
+- The DaemonSet will automatically start a kube-router pod on each node
 
 ---
-  
+
 ## Logging into the new cluster
 
 .exercise[
@@ -221,7 +227,7 @@ class: extra-details
 - It is similar to the one we used with the `kubenet` cluster
 
 - The API server is started with `--allow-privileged`
-  
+
   (because we will start kube-router in privileged pods)
 
 - The controller manager is started with extra flags too:
@@ -254,7 +260,7 @@ class: extra-details
 
 ---
 
-## The kube-router DaemonSet 
+## The kube-router DaemonSet
 
 - In the same directory, there is a `kuberouter.yaml` file
 
@@ -272,7 +278,7 @@ class: extra-details
 
 - The address of the API server will be `http://A.B.C.D:8080`
 
-  (where `A.B.C.D` is the address of `kuberouter1`, running the control plane)
+  (where `A.B.C.D` is the public address of `kuberouter1`, running the control plane)
 
 .exercise[
 
@@ -300,12 +306,10 @@ Note: the DaemonSet won't create any pods (yet) since there are no nodes (yet).
 
 - Generate the kubeconfig file (replacing `X.X.X.X` with the address of `kuberouter1`):
   ```bash
-    kubectl --kubeconfig ~/kubeconfig config \
-            set-cluster kubenet --server http://`X.X.X.X`:8080
-    kubectl --kubeconfig ~/kubeconfig config \
-            set-context kubenet --cluster kubenet
-    kubectl --kubeconfig ~/kubeconfig config\
-            use-context kubenet
+    kubectl config set-cluster cni --server http://`X.X.X.X`:8080
+    kubectl config set-context cni --cluster cni
+    kubectl config use-context cni
+    cp ~/.kube/config ~/kubeconfig
   ```
 
 ]
@@ -451,7 +455,7 @@ We should see the local pod CIDR connected to `kube-bridge`, and the other nodes
 
 - Or try to exec into one of the kube-router pods:
   ```bash
-  kubectl -n kube-system exec kuber-router-xxxxx bash
+  kubectl -n kube-system exec kube-router-xxxxx bash
   ```
 
 ]
@@ -487,8 +491,8 @@ What does that mean?
 
 - First, get the container ID, with `docker ps` or like this:
   ```bash
-  CID=$(docker ps
-        --filter label=io.kubernetes.pod.namespace=kube-system
+  CID=$(docker ps -q \
+        --filter label=io.kubernetes.pod.namespace=kube-system \
         --filter label=io.kubernetes.container.name=kube-router)
   ```
 
@@ -573,7 +577,7 @@ done
 
 ## Starting the route reflector
 
-- Only do this if you are doing this on your own
+- Only do this slide if you are doing this on your own
 
 - There is a Compose file in the `compose/frr-route-reflector` directory
 
@@ -599,13 +603,13 @@ done
 
 ## Updating kube-router configuration
 
-- We need to add two command-line flags to the kube-router process
+- We need to pass two command-line flags to the kube-router process
 
 .exercise[
 
 - Edit the `kuberouter.yaml` file
 
-- Add the following flags to the kube-router arguments,:
+- Add the following flags to the kube-router arguments:
   ```
   - "--peer-router-ips=`X.X.X.X`"
   - "--peer-router-asns=64512"

slides/k8s/concepts-k8s.md

@@ -177,7 +177,7 @@ class: extra-details
 
 - In that case, there is no "master node"
 
-*For this reason, it is more accurate to say "control plane" rather than "master".*
+*For this reason, it is more accurate to say "control plane" rather than "master."*
 
 ---
 

slides/k8s/configuration.md

@@ -22,7 +22,7 @@
 
 - There are many ways to pass configuration to code running in a container:
 
-  - baking it in a custom image
+  - baking it into a custom image
 
   - command-line arguments
 
@@ -125,7 +125,7 @@
 
 - We can also use a mechanism called the *downward API*
 
-- The downward API allows to expose pod or container information
+- The downward API allows exposing pod or container information
 
   - either through special files (we won't show that for now)
 
@@ -436,7 +436,7 @@ We should see connections served by Google, and others served by IBM.
 
 - We are going to store the port number in a configmap
 
-- Then we will expose that configmap to a container environment variable
+- Then we will expose that configmap as a container environment variable
 
 ---
 

slides/k8s/control-plane-auth.md

@@ -0,0 +1,265 @@
+# Securing the control plane
+
+- Many components accept connections (and requests) from others:
+
+  - API server
+
+  - etcd
+
+  - kubelet
+
+- We must secure these connections:
+
+  - to deny unauthorized requests
+
+  - to prevent eavesdropping secrets, tokens, and other sensitive information
+
+- Disabling authentication and/or authorization is **strongly discouraged**
+
+  (but it's possible to do it, e.g. for learning / troubleshooting purposes)
+
+---
+
+## Authentication and authorization
+
+- Authentication (checking "who you are") is done with mutual TLS
+
+ (both the client and the server need to hold a valid certificate)
+
+- Authorization (checking "what you can do") is done in different ways
+
+  - the API server implements a sophisticated permission logic (with RBAC)
+  
+  - some services will defer authorization to the API server (through webhooks)
+
+  - some services require a certificate signed by a particular CA / sub-CA
+
+---
+
+## In practice
+
+- We will review the various communication channels in the control plane
+
+- We will describe how they are secured
+
+- When TLS certificates are used, we will indicate:
+
+  - which CA signs them
+
+  - what their subject (CN) should be, when applicable
+
+- We will indicate how to configure security (client- and server-side)
+
+---
+
+## etcd peers
+
+- Replication and coordination of etcd happens on a dedicated port
+
+  (typically port 2380; the default port for normal client connections is 2379)
+
+- Authentication uses TLS certificates with a separate sub-CA
+
+  (otherwise, anyone with a Kubernetes client certificate could access etcd!)
+
+- The etcd command line flags involved are:
+
+   `--peer-client-cert-auth=true` to activate it
+
+   `--peer-cert-file`, `--peer-key-file`, `--peer-trusted-ca-file`
+
+---
+
+## etcd clients
+
+- The only¹ thing that connects to etcd is the API server
+
+- Authentication uses TLS certificates with a separate sub-CA
+
+  (for the same reasons as for etcd inter-peer authentication)
+
+- The etcd command line flags involved are:
+
+  `--client-cert-auth=true` to activate it
+
+  `--trusted-ca-file`, `--cert-file`, `--key-file`
+
+- The API server command line flags involved are:
+
+  `--etcd-cafile`, `--etcd-certfile`, `--etcd-keyfile`
+
+.footnote[¹Technically, there is also the etcd healthcheck. Let's ignore it for now.]
+
+---
+
+## API server clients
+
+- The API server has a sophisticated authentication and authorization system
+
+- For connections coming from other components of the control plane:
+
+  - authentication uses certificates (trusting the certificates' subject or CN)
+
+  - authorization uses whatever mechanism is enabled (most oftentimes, RBAC)
+
+- The relevant API server flags are:
+
+  `--client-ca-file`, `--tls-cert-file`, `--tls-private-key-file`
+
+- Each component connecting to the API server takes a `--kubeconfig` flag
+
+  (to specify a kubeconfig file containing the CA cert, client key, and client cert)
+
+- Yes, that kubeconfig file follows the same format as our `~/.kube/config` file!
+
+---
+
+## Kubelet and API server
+
+- Communication between kubelet and API server can be established both ways
+
+- Kubelet → API server:
+
+  - kubelet registers itself ("hi, I'm node42, do you have work for me?")
+
+  - connection is kept open and re-established if it breaks
+
+  - that's how the kubelet knows which pods to start/stop
+
+- API server → kubelet:
+
+  - used to retrieve logs, exec, attach to containers
+
+---
+
+## Kubelet → API server
+
+- Kubelet is started with `--kubeconfig` with API server information
+
+- The client certificate of the kubelet will typically have:
+
+  `CN=system:node:<nodename>` and groups `O=system:nodes`
+
+- Nothing special on the API server side
+
+  (it will authenticate like any other client)
+
+---
+
+## API server → kubelet
+
+- Kubelet is started with the flag `--client-ca-file`
+
+  (typically using the same CA as the API server)
+
+- API server will use a dedicated key pair when contacting kubelet
+
+  (specified with `--kubelet-client-certificate` and `--kubelet-client-key`)
+
+- Authorization uses webhooks
+
+  (enabled with `--authorization-mode=Webhook` on kubelet)
+
+- The webhook server is the API server itself
+
+  (the kubelet sends back a request to the API server to ask, "can this person do that?")
+
+---
+
+## Scheduler
+
+- The scheduler connects to the API server like an ordinary client
+
+- The certificate of the scheduler will have `CN=system:kube-scheduler`
+
+---
+
+## Controller manager
+
+- The controller manager is also a normal client to the API server
+
+- Its certificate will have `CN=system:kube-controller-manager`
+
+- If we use the CSR API, the controller manager needs the CA cert and key
+
+  (passed with flags `--cluster-signing-cert-file` and `--cluster-signing-key-file`)
+
+- We usually want the controller manager to generate tokens for service accounts
+
+- These tokens deserve some details (on the next slide!)
+
+---
+
+## Service account tokens
+
+- Each time we create a service account, the controller manager generates a token
+
+- These tokens are JWT tokens, signed with a particular key
+
+- These tokens are used for authentication with the API server
+
+  (and therefore, the API server needs to be able to verify their integrity)
+
+- This uses another keypair:
+
+  - the private key (used for signature) is passed to the controller manager
+    <br/>(using flags `--service-account-private-key-file` and `--root-ca-file`)
+
+  - the public key (used for verification) is passed to the API server
+    <br/>(using flag `--service-account-key-file`)
+
+---
+
+## kube-proxy
+
+- kube-proxy is "yet another API server client"
+
+- In many clusters, it runs as a Daemon Set
+
+- In that case, it will have its own Service Account and associated permissions
+
+- It will authenticate using the token of that Service Account
+
+---
+
+## Webhooks
+
+- We mentioned webhooks earlier; how does that really work?
+
+- The Kubernetes API has special resource types to check permissions
+
+- One of them is SubjectAccessReview
+
+- To check if a particular user can do a particular action on a particular resource:
+
+  - we prepare a SubjectAccessReview object
+
+  - we send that object to the API server
+
+  - the API server responds with allow/deny (and optional explanations)
+
+- Using webhooks for authorization = sending SAR to authorize each request
+
+---
+
+## Subject Access Review
+
+Here is an example showing how to check if `jean.doe` can `get` some `pods` in `kube-system`:
+
+```bash
+kubectl -v9 create -f- <<EOF
+apiVersion: authorization.k8s.io/v1beta1
+kind: SubjectAccessReview
+spec:
+  user: jean.doe
+  group:
+  - foo
+  - bar
+  resourceAttributes:
+    #group: blah.k8s.io
+    namespace: kube-system
+    resource: pods
+    verb: get
+    #name: web-xyz1234567-pqr89
+EOF
+```

slides/k8s/create-chart.md

@@ -34,7 +34,7 @@
   ```bash
 
 	while read kind name; do
-	  kubectl get -o yaml --export $kind $name > dockercoins/templates/$name-$kind.yaml
+	  kubectl get -o yaml $kind $name > dockercoins/templates/$name-$kind.yaml
 	done <<EOF
 	deployment worker
 	deployment hasher

slides/k8s/create-more-charts.md

@@ -0,0 +1,367 @@
+# Creating Helm charts
+
+- We are going to create a generic Helm chart
+
+- We will use that Helm chart to deploy DockerCoins
+
+- Each component of DockerCoins will have its own *release*
+
+- In other words, we will "install" that Helm chart multiple times
+
+  (one time per component of DockerCoins)
+
+---
+
+## Creating a generic chart
+
+- Rather than starting from scratch, we will use `helm create`
+
+- This will give us a basic chart that we will customize
+
+.exercise[
+
+- Create a basic chart:
+  ```bash
+  cd ~
+  helm create helmcoins
+  ```
+
+]
+
+This creates a basic chart in the directory `helmcoins`.
+
+---
+
+## What's in the basic chart?
+
+- The basic chart will create a Deployment and a Service
+
+- Optionally, it will also include an Ingress
+
+- If we don't pass any values, it will deploy the `nginx` image
+
+- We can override many things in that chart
+
+- Let's try to deploy DockerCoins components with that chart!
+
+---
+
+## Writing `values.yaml` for our components
+
+- We need to write one `values.yaml` file for each component
+
+  (hasher, redis, rng, webui, worker)
+
+- We will start with the `values.yaml` of the chart, and remove what we don't need
+
+- We will create 5 files:
+
+  hasher.yaml, redis.yaml, rng.yaml, webui.yaml, worker.yaml
+
+---
+
+## Getting started
+
+- For component X, we want to use the image dockercoins/X:v0.1
+
+  (for instance, for rng, we want to use the image dockercoins/rng:v0.1)
+
+- Exception: for redis, we want to use the official image redis:latest
+
+.exercise[
+
+- Write minimal YAML files for the 5 components, specifying only the image
+
+]
+
+--
+
+*Hint: our YAML files should look like this.*
+
+```yaml
+### rng.yaml
+image:
+  repository: dockercoins/`rng`
+  tag: v0.1
+```
+
+---
+
+## Deploying DockerCoins components
+
+- For convenience, let's work in a separate namespace
+
+.exercise[
+
+- Create a new namespace:
+  ```bash
+  kubectl create namespace helmcoins
+  ```
+
+- Switch to that namespace:
+  ```bash
+  kns helmcoins
+  ```
+
+]
+
+---
+
+## Deploying the chart
+
+- To install a chart, we can use the following command:
+  ```bash
+  helm install [--name `X`] <chart>
+  ```
+
+- We can also use the following command, which is idempotent:
+  ```bash
+  helm upgrade --install `X` chart
+  ```
+
+.exercise[
+
+- Install the 5 components of DockerCoins:
+  ```bash
+    for COMPONENT in hasher redis rng webui worker; do
+      helm upgrade --install $COMPONENT helmcoins/ --values=$COMPONENT.yaml
+    done
+  ```
+
+]
+
+---
+
+## Checking what we've done
+
+- Let's see if DockerCoins is working!
+
+.exercise[
+
+- Check the logs of the worker:
+  ```bash
+  stern worker
+  ```
+
+- Look at the resources that were created:
+  ```bash
+  kubectl get all
+  ```
+
+]
+
+There are *many* issues to fix!
+
+---
+
+## Service names
+
+- Our services should be named `rng`, `hasher`, etc., but they are named differently
+
+- Look at the YAML template used for the services
+
+- Does it look like we can override the name of the services?
+
+--
+
+- *Yes*, we can use `.Values.nameOverride`
+
+- This means setting `nameOverride` in the values YAML file
+
+---
+
+## Setting service names
+
+- Let's add `nameOverride: X` in each values YAML file!
+
+  (where X is hasher, redis, rng, etc.)
+
+.exercise[
+
+- Edit the 5 YAML files to add `nameOverride: X`
+
+- Deploy the updated Chart:
+  ```bash
+    for COMPONENT in hasher redis rng webui worker; do
+      helm upgrade --install $COMPONENT helmcoins/ --values=$COMPONENT.yaml
+    done
+  ```
+  (Yes, this is exactly the same command as before!)
+
+]
+
+---
+
+## Checking what we've done
+
+.exercise[
+
+- Check the service names:
+  ```bash
+  kubectl get services
+  ```
+  Great! (We have a useless service for `worker`, but let's ignore it for now.)
+
+- Check the state of the pods:
+  ```bash
+  kubectl get pods
+  ```
+  Not so great... Some pods are *not ready.*
+
+]
+
+---
+
+## Troubleshooting pods
+
+- The easiest way to troubleshoot pods is to look at *events*
+
+- We can look at all the events on the cluster (with `kubectl get events`)
+
+- Or we can use `kubectl describe` on the objects that have problems
+
+  (`kubectl describe` will retrieve the events related to the object)
+
+.exercise[
+
+- Check the events for the redis pods:
+  ```bash
+  kubectl describe pod -l app.kubernetes.io/name=redis
+  ```
+
+]
+
+What's going on?
+
+---
+
+## Healthchecks
+
+- The default chart defines healthchecks doing HTTP requests on port 80
+
+- That won't work for redis and worker
+
+  (redis is not HTTP, and not on port 80; worker doesn't even listen)
+
+--
+
+- We could comment out the healthchecks
+
+- We could also make them conditional
+
+- This sounds more interesting, let's do that!
+
+---
+
+## Conditionals
+
+- We need to enclose the healthcheck block with:
+
+  `{{ if CONDITION }}` at the beginning
+
+  `{{ end }}` at the end
+
+- For the condition, we will use `.Values.healthcheck`
+
+---
+
+## Updating the deployment template
+
+.exercise[
+
+- Edit `helmcoins/templates/deployment.yaml`
+
+- Before the healthchecks section (it starts with `livenessProbe:`), add:
+
+  `{{ if .Values.healthcheck }}`
+
+- After the healthchecks section (just before `resources:`), add:
+
+  `{{ end }}`
+
+- Edit `hasher.yaml`, `rng.yaml`, `webui.yaml` to add:
+
+  `healthcheck: true`
+
+]
+
+---
+
+## Update the deployed charts
+
+- We can now apply the new templates (and the new values)
+
+.exercise[
+
+- Use the same command as earlier to upgrade all five components
+
+- Use `kubectl describe` to confirm that `redis` starts correctly
+
+- Use `kubectl describe` to confirm that `hasher` still has healthchecks
+
+]
+
+---
+
+## Is it working now?
+
+- If we look at the worker logs, it appears that the worker is still stuck
+
+- What could be happening?
+
+--
+
+- The redis service is not on port 80!
+
+- We need to update the port number in redis.yaml
+
+- We also need to update the port number in deployment.yaml
+
+  (it is hard-coded to 80 there)
+
+---
+
+## Setting the redis port
+
+.exercise[
+
+- Edit `redis.yaml` to add:
+  ```yaml
+    service:
+      port: 6379
+  ```
+
+- Edit `helmcoins/templates/deployment.yaml`
+
+- The line with `containerPort` should be:
+  ```yaml
+  containerPort: {{ .Values.service.port }}
+  ```
+
+]
+
+---
+
+## Apply changes
+
+- Re-run the for loop to execute `helm upgrade` one more time
+
+- Check the worker logs
+
+- This time, it should be working!
+
+---
+
+## Extra steps
+
+- We don't need to create a service for the worker
+
+- We can put the whole service block in a conditional
+
+  (this will require additional changes in other files referencing the service)
+
+- We can set the webui to be a NodePort service
+
+- We can change the number of workers with `replicaCount`
+
+- And much more!

slides/k8s/csr-api.md

@@ -46,7 +46,7 @@
 
   (and vice versa)
 
-- If I use someone's public key to encrypt / decrypt their messages,
+- If I use someone's public key to encrypt/decrypt their messages,
   <br/>
   I can be certain that I am talking to them / they are talking to me
 
@@ -58,11 +58,11 @@
 
 This is what I do if I want to obtain a certificate.
 
-1. Create public and private key.
+1. Create public and private keys.
 
 2. Create a Certificate Signing Request (CSR).
 
-   (The CSR contains the identity that I claim and an expiration date.)
+   (The CSR contains the identity that I claim and a public key.)
 
 3. Send that CSR to the Certificate Authority (CA).
 
@@ -84,7 +84,7 @@ The CA (or anyone else) never needs to know my private key.
 
   (= upload a CSR to the Kubernetes API)
 
-- Then, using the Kubernetes API, we can approve / deny the request
+- Then, using the Kubernetes API, we can approve/deny the request
 
 - If we approve the request, the Kubernetes API generates a certificate
 
@@ -122,7 +122,7 @@ The CA (or anyone else) never needs to know my private key.
 
 - Users can then retrieve their certificate from their CSR object
 
-- ... And use that certificate for subsequent interactions
+- ...And use that certificate for subsequent interactions
 
 ---
 
@@ -231,7 +231,7 @@ For a user named `jean.doe`, we will have:
 - Let's use OpenSSL; it's not the best one, but it's installed everywhere
 
   (many people prefer cfssl, easyrsa, or other tools; that's fine too!)
- 
+
 .exercise[
 
 - Generate the key and certificate signing request:
@@ -244,7 +244,7 @@ For a user named `jean.doe`, we will have:
 
 The command above generates:
 
-- a 2048-bit RSA key, without DES encryption, stored in key.pem
+- a 2048-bit RSA key, without encryption, stored in key.pem
 - a CSR for the name `jean.doe` in group `devs`
 
 ---
@@ -345,7 +345,7 @@ The command above generates:
   kctx -
   ```
 
-- Retrieve the certificate from the CSR:
+- Retrieve the updated CSR object and extract the certificate:
   ```bash
   kubectl get csr users:jean.doe \
           -o jsonpath={.status.certificate} \
@@ -387,7 +387,7 @@ The command above generates:
 
 ## What's missing?
 
-We shown, step by step, a method to issue short-lived certificates for users.
+We have just shown, step by step, a method to issue short-lived certificates for users.
 
 To be usable in real environments, we would need to add:
 
@@ -417,7 +417,7 @@ To be usable in real environments, we would need to add:
 
 - This provides enhanced security:
 
-  - the long-term credentials can use long passphrases, 2FA, HSM ...
+  - the long-term credentials can use long passphrases, 2FA, HSM...
 
   - the short-term credentials are more convenient to use
 

slides/k8s/daemonset.md

@@ -4,15 +4,29 @@
 
 - We want one (and exactly one) instance of `rng` per node
 
-- What if we just scale up `deploy/rng` to the number of nodes?
+- We *do not want* two instances of `rng` on the same node
 
-  - nothing guarantees that the `rng` containers will be distributed evenly
+- We will do that with a *daemon set*
 
-  - if we add nodes later, they will not automatically run a copy of `rng`
+---
 
-  - if we remove (or reboot) a node, one `rng` container will restart elsewhere
+## Why not a deployment?
 
-- Instead of a `deployment`, we will use a `daemonset`
+- Can't we just do `kubectl scale deployment rng --replicas=...`?
+
+--
+
+- Nothing guarantees that the `rng` containers will be distributed evenly
+
+- If we add nodes later, they will not automatically run a copy of `rng`
+
+- If we remove (or reboot) a node, one `rng` container will restart elsewhere
+
+  (and we will end up with two instances `rng` on the same node)
+
+- By contrast, a daemon set will start one pod per node and keep it that way
+
+  (as nodes are added or removed)
 
 ---
 
@@ -38,7 +52,7 @@
 
 <!-- ##VERSION## -->
 
-- Unfortunately, as of Kubernetes 1.14, the CLI cannot create daemon sets
+- Unfortunately, as of Kubernetes 1.15, the CLI cannot create daemon sets
 
 --
 
@@ -371,7 +385,7 @@ But ... why do these pods (in particular, the *new* ones) have this `app=rng` la
 
 - Bottom line: if we remove our `app=rng` label ...
 
- ... The pod "diseappears" for its parent, which re-creates another pod to replace it
+ ... The pod "disappears" for its parent, which re-creates another pod to replace it
 
 ---
 

slides/k8s/dashboard.md

@@ -153,5 +153,7 @@ The dashboard will then ask you which authentication you want to use.
 
 --
 
-- It introduces new failure modes (like if you try to apply yaml from a link that's no longer valid)
+- It introduces new failure modes
+
+  (for instance, if you try to apply YAML from a link that's no longer valid)
 

slides/k8s/dmuc.md

@@ -175,7 +175,7 @@ Success!
 
 ]
 
-So far, so good.
+We should get `No resources found.` and the `kubernetes` service, respectively.
 
 Note: the API server automatically created the `kubernetes` service entry.
 
@@ -225,7 +225,7 @@ Success?
 
 ]
 
-Our Deployment is in a bad shape:
+Our Deployment is in bad shape:
 ```
 NAME                  READY   UP-TO-DATE   AVAILABLE   AGE
 deployment.apps/web   0/1     0            0           2m26s
@@ -584,7 +584,7 @@ Our pod is still `Pending`. 🤔
 
 Which is normal: it needs to be *scheduled*.
 
-(i.e., something needs to decide on which node it should go.)
+(i.e., something needs to decide which node it should go on.)
 
 ---
 
@@ -658,7 +658,7 @@ class: extra-details
 
 - This is actually how the scheduler works!
 
-- It watches pods, takes scheduling decisions, creates Binding objects
+- It watches pods, makes scheduling decisions, and creates Binding objects
 
 ---
 
@@ -686,7 +686,7 @@ We should see the `Welcome to nginx!` page.
 
 ## Exposing our Deployment
 
-- We can now create a Service associated to this Deployment
+- We can now create a Service associated with this Deployment
 
 .exercise[
 
@@ -711,11 +711,11 @@ This won't work. We need kube-proxy to enable internal communication.
 
 ## Starting kube-proxy
 
-- kube-proxy also needs to connect to API server
+- kube-proxy also needs to connect to the API server
 
 - It can work with the `--master` flag
 
-  (even though that will be deprecated in the future)
+  (although that will be deprecated in the future)
 
 .exercise[
 
@@ -832,6 +832,6 @@ class: extra-details
 
 - By default, the API server expects to be running directly on the nodes
 
-  (it could be as a bare process, or in a container/pod using host network)
+  (it could be as a bare process, or in a container/pod using the host network)
 
 - ... And it expects to be listening on port 6443 with TLS

slides/k8s/extending-api.md

@@ -117,7 +117,7 @@ Examples:
 
 ## Admission controllers
 
-- When a Pod is created, it is associated to a ServiceAccount
+- When a Pod is created, it is associated with a ServiceAccount
 
   (even if we did not specify one explicitly)
 
@@ -163,7 +163,7 @@ class: pic
 
 - These webhooks can be *validating* or *mutating*
 
-- Webhooks can be setup dynamically (without restarting the API server)
+- Webhooks can be set up dynamically (without restarting the API server)
 
 - To setup a dynamic admission webhook, we create a special resource:
 
@@ -171,7 +171,7 @@ class: pic
 
 - These resources are created and managed like other resources
 
-  (i.e. `kubectl create`, `kubectl get` ...)
+  (i.e. `kubectl create`, `kubectl get`...)
 
 ---
 

slides/k8s/healthchecks-more.md

@@ -0,0 +1,393 @@
+## Questions to ask before adding healthchecks
+
+- Do we want liveness, readiness, both?
+
+  (sometimes, we can use the same check, but with different failure thresholds)
+
+- Do we have existing HTTP endpoints that we can use?
+
+- Do we need to add new endpoints, or perhaps use something else?
+
+- Are our healthchecks likely to use resources and/or slow down the app?
+
+- Do they depend on additional services?
+
+  (this can be particularly tricky, see next slide)
+
+---
+
+## Healthchecks and dependencies
+
+- A good healthcheck should always indicate the health of the service itself
+
+- It should not be affected by the state of the service's dependencies
+
+- Example: a web server requiring a database connection to operate
+
+  (make sure that the healthcheck can report "OK" even if the database is down;
+  <br/>
+  because it won't help us to restart the web server if the issue is with the DB!)
+
+- Example: a microservice calling other microservices
+
+- Example: a worker process
+
+  (these will generally require minor code changes to report health)
+
+---
+
+## Adding healthchecks to an app
+
+- Let's add healthchecks to DockerCoins!
+
+- We will examine the questions of the previous slide
+
+- Then we will review each component individually to add healthchecks
+
+---
+
+## Liveness, readiness, or both?
+
+- To answer that question, we need to see the app run for a while
+
+- Do we get temporary, recoverable glitches?
+
+  → then use readiness
+
+- Or do we get hard lock-ups requiring a restart?
+
+  → then use liveness
+
+- In the case of DockerCoins, we don't know yet!
+
+- Let's pick liveness
+
+---
+
+## Do we have HTTP endpoints that we can use?
+
+- Each of the 3 web services (hasher, rng, webui) has a trivial route on `/`
+
+- These routes:
+
+  - don't seem to perform anything complex or expensive
+
+  - don't seem to call other services
+
+- Perfect!
+
+  (See next slides for individual details)
+
+---
+
+- [hasher.rb](https://github.com/jpetazzo/container.training/blob/master/dockercoins/hasher/hasher.rb)
+  ```ruby
+    get '/' do
+      "HASHER running on #{Socket.gethostname}\n"
+    end
+  ```
+
+- [rng.py](https://github.com/jpetazzo/container.training/blob/master/dockercoins/rng/rng.py)
+  ```python
+    @app.route("/")
+    def index():
+      return "RNG running on {}\n".format(hostname)
+  ```
+
+- [webui.js](https://github.com/jpetazzo/container.training/blob/master/dockercoins/webui/webui.js)
+  ```javascript
+    app.get('/', function (req, res) {
+      res.redirect('/index.html');
+    });
+  ```
+
+---
+
+## Running DockerCoins
+
+- We will run DockerCoins in a new, separate namespace
+
+- We will use a set of YAML manifests and pre-built images
+
+- We will add our new liveness probe to the YAML of the `rng` DaemonSet
+
+- Then, we will deploy the application
+
+---
+
+## Creating a new namespace
+
+- This will make sure that we don't collide / conflict with previous exercises
+
+.exercise[
+
+- Create the yellow namespace:
+  ```bash
+  kubectl create namespace yellow
+  ```
+
+- Switch to that namespace:
+  ```bash
+  kns yellow
+  ```
+
+]
+
+---
+
+## Retrieving DockerCoins manifests
+
+- All the manifests that we need are on a convenient repository:
+
+  https://github.com/jpetazzo/kubercoins
+
+.exercise[
+
+- Clone that repository:
+  ```bash
+  cd ~
+  git clone https://github.com/jpetazzo/kubercoins
+  ```
+
+- Change directory to the repository:
+  ```bash
+  cd kubercoins
+  ```
+
+]
+
+---
+
+## A simple HTTP liveness probe
+
+This is what our liveness probe should look like:
+
+```yaml
+containers:
+- name: ...
+image: ...
+livenessProbe:
+  httpGet:
+    path: /
+    port: 80
+  initialDelaySeconds: 30
+  periodSeconds: 5
+```
+
+This will give 30 seconds to the service to start. (Way more than necessary!)
+<br/>
+It will run the probe every 5 seconds.
+<br/>
+It will use the default timeout (1 second).
+<br/>
+It will use the default failure threshold (3 failed attempts = dead).
+<br/>
+It will use the default success threshold (1 successful attempt = alive).
+
+---
+
+## Adding the liveness probe
+
+- Let's add the liveness probe, then deploy DockerCoins
+
+.exercise[
+
+- Edit `rng-daemonset.yaml` and add the liveness probe
+  ```bash
+  vim rng-daemonset.yaml
+  ```
+
+- Load the YAML for all the resources of DockerCoins:
+  ```bash
+  kubectl apply -f .
+  ```
+
+]
+
+---
+
+## Testing the liveness probe
+
+- The rng service needs 100ms to process a request
+
+  (because it is single-threaded and sleeps 0.1s in each request)
+
+- The probe timeout is set to 1 second
+
+- If we send more than 10 requests per second per backend, it will break
+
+- Let's generate traffic and see what happens!
+
+.exercise[
+
+- Get the ClusterIP address of the rng service:
+  ```bash
+  kubectl get svc rng
+  ```
+
+]
+
+---
+
+## Monitoring the rng service
+
+- Each command below will show us what's happening on a different level
+
+.exercise[
+
+- In one window, monitor cluster events:
+  ```bash
+  kubectl get events -w
+  ```
+
+- In another window, monitor the response time of rng:
+  ```bash
+  httping `<ClusterIP>`
+  ```
+
+- In another window, monitor pods status:
+  ```bash
+  kubectl get pods -w
+  ```
+
+]
+
+---
+
+## Generating traffic
+
+- Let's use `ab` to send concurrent requests to rng
+
+.exercise[
+
+- In yet another window, generate traffic:
+  ```bash
+  ab -c 10 -n 1000 http://`<ClusterIP>`/1
+  ```
+
+- Experiment with higher values of `-c` and see what happens
+
+]
+
+- The `-c` parameter indicates the number of concurrent requests
+
+- The final `/1` is important to generate actual traffic
+
+  (otherwise we would use the ping endpoint, which doesn't sleep 0.1s per request)
+
+---
+
+## Discussion
+
+- Above a given threshold, the liveness probe starts failing
+
+  (about 10 concurrent requests per backend should be plenty enough)
+
+- When the liveness probe fails 3 times in a row, the container is restarted
+
+- During the restart, there is *less* capacity available
+
+- ... Meaning that the other backends are likely to timeout as well
+
+- ... Eventually causing all backends to be restarted
+
+- ... And each fresh backend gets restarted, too
+
+- This goes on until the load goes down, or we add capacity
+
+*This wouldn't be a good healthcheck in a real application!*
+
+---
+
+## Better healthchecks
+
+- We need to make sure that the healthcheck doesn't trip when
+  performance degrades due to external pressure
+
+- Using a readiness check would have fewer effects
+
+  (but it would still be an imperfect solution)
+
+- A possible combination:
+
+  - readiness check with a short timeout / low failure threshold
+
+  - liveness check with a longer timeout / higher failure threshold
+
+---
+
+## Healthchecks for redis
+
+- A liveness probe is enough
+
+  (it's not useful to remove a backend from rotation when it's the only one)
+
+- We could use an exec probe running `redis-cli ping`
+
+---
+
+class: extra-details
+
+## Exec probes and zombies
+
+- When using exec probes, we should make sure that we have a *zombie reaper*
+
+  🤔🧐🧟 Wait, what?
+
+- When a process terminates, its parent must call `wait()`/`waitpid()`
+
+  (this is how the parent process retrieves the child's exit status)
+
+- In the meantime, the process is in *zombie* state
+
+  (the process state will show as `Z` in `ps`, `top` ...)
+
+- When a process is killed, its children are *orphaned* and attached to PID 1
+
+- PID 1 has the responsibility of *reaping* these processes when they terminate
+
+- OK, but how does that affect us?
+
+---
+
+class: extra-details
+
+## PID 1 in containers
+
+- On ordinary systems, PID 1 (`/sbin/init`) has logic to reap processes
+
+- In containers, PID 1 is typically our application process
+
+  (e.g. Apache, the JVM, NGINX, Redis ...)
+
+- These *do not* take care of reaping orphans
+
+- If we use exec probes, we need to add a process reaper
+
+- We can add [tini](https://github.com/krallin/tini) to our images
+
+- Or [share the PID namespace between containers of a pod](https://kubernetes.io/docs/tasks/configure-pod-container/share-process-namespace/)
+
+  (and have gcr.io/pause take care of the reaping)
+
+---
+
+## Healthchecks for worker
+
+- Readiness isn't useful
+
+  (because worker isn't a backend for a service)
+
+- Liveness may help us restart a broken worker, but how can we check it?
+
+- Embedding an HTTP server is an option
+
+  (but it has a high potential for unwanted side effects and false positives)
+
+- Using a "lease" file can be relatively easy:
+
+  - touch a file during each iteration of the main loop
+
+  - check the timestamp of that file from an exec probe
+
+- Writing logs (and checking them from the probe) also works

slides/k8s/healthchecks.md

@@ -1,4 +1,4 @@
-# Healthchecks (extra material)
+# Healthchecks
 
 - Kubernetes provides two kinds of healthchecks: liveness and readiness
 
@@ -108,7 +108,7 @@
 
   (as opposed to merely started)
 
-- Containers in a broken state gets killed and restarted
+- Containers in a broken state get killed and restarted
 
   (instead of serving errors or timeouts)
 

slides/k8s/helm.md

@@ -158,7 +158,7 @@ Where do these `--set` options come from?
 
 ]
 
-The chart's metadata includes an URL to the project's home page.
+The chart's metadata includes a URL to the project's home page.
 
 (Sometimes it conveniently points to the documentation for the chart.)
 

slides/k8s/horizontal-pod-autoscaler.md

@@ -6,15 +6,15 @@
 
 - Horizontal scaling = changing the number of replicas
 
-  (adding / removing pods)
+  (adding/removing pods)
 
 - Vertical scaling = changing the size of individual replicas
 
-  (increasing / reducing CPU and RAM per pod)
+  (increasing/reducing CPU and RAM per pod)
 
 - Cluster scaling = changing the size of the cluster
 
-  (adding / removing nodes)
+  (adding/removing nodes)
 
 ---
 
@@ -34,7 +34,7 @@
 
   `TargetNumOfPods = ceil(sum(CurrentPodsCPUUtilization) / Target)`
 
-- It scales up/down the related object to this target number of pods
+- It scales the related object up/down to this target number of pods
 
 ---
 
@@ -50,9 +50,9 @@
 
 - The latter actually makes a lot of sense:
 
-  - if a Pod doesn't have a CPU request, it might be using 10% of CPU ...
+  - if a Pod doesn't have a CPU request, it might be using 10% of CPU...
 
-  - ... but only because there is no CPU time available!
+  - ...but only because there is no CPU time available!
 
   - this makes sure that we won't add pods to nodes that are already resource-starved
 
@@ -238,7 +238,7 @@ This can also be set with `--cpu-percent=`.
 
 - Kubernetes doesn't implement any of these API groups
 
-- Using these metrics requires to [register additional APIs](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-metrics-apis)
+- Using these metrics requires [registering additional APIs](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-metrics-apis)
 
 - The metrics provided by metrics server are standard; everything else is custom
 

slides/k8s/ingress.md

@@ -88,7 +88,7 @@
 
   - the control loop watches over ingress resources, and configures the LB accordingly
 
-- Step 2: setup DNS
+- Step 2: set up DNS
 
   - associate DNS entries with the load balancer address
 
@@ -126,7 +126,7 @@
 
 - We could use pods specifying `hostPort: 80` 
 
-  ... but with most CNI plugins, this [doesn't work or require additional setup](https://github.com/kubernetes/kubernetes/issues/23920)
+  ... but with most CNI plugins, this [doesn't work or requires additional setup](https://github.com/kubernetes/kubernetes/issues/23920)
 
 - We could use a `NodePort` service
 
@@ -142,7 +142,7 @@
 
   (sometimes called sandbox or network sandbox)
 
-- An IP address is associated to the pod
+- An IP address is assigned to the pod
 
 - This IP address is routed/connected to the cluster network
 
@@ -239,7 +239,7 @@ class: extra-details
 
   - an error condition on the node
     <br/>
-    (for instance: "disk full", do not start new pods here!)
+    (for instance: "disk full," do not start new pods here!)
 
 - The `effect` can be:
 
@@ -501,11 +501,11 @@ spec:
 
   (as long as it has access to the cluster subnet)
 
-- This allows to use external (hardware, physical machines...) load balancers
+- This allows the use of external (hardware, physical machines...) load balancers
 
 - Annotations can encode special features
 
-  (rate-limiting, A/B testing, session stickiness, etc.) 
+  (rate-limiting, A/B testing, session stickiness, etc.)
 
 ---
 

slides/k8s/kubectlexpose.md

@@ -81,7 +81,7 @@ Under the hood: `kube-proxy` is using a userland proxy and a bunch of `iptables`
 
 .exercise[
 
-- In another window, watch the pods (to see when they will be created):
+- In another window, watch the pods (to see when they are created):
   ```bash
   kubectl get pods -w
   ```

slides/k8s/kubectlget.md

@@ -132,7 +132,7 @@ class: extra-details
 
   - short (e.g. `no`, `svc`, `deploy`)
 
-- Some resources do not have a short names
+- Some resources do not have a short name
 
 - `Endpoints` only have a plural form
 
@@ -466,4 +466,4 @@ class: extra-details
 - For more details, see [KEP-0009] or the [node controller documentation]
 
 [KEP-0009]: https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/0009-node-heartbeat.md
-[node controller documentation]: https://kubernetes.io/docs/concepts/architecture/nodes/#node-controller
+[node controller documentation]: https://kubernetes.io/docs/concepts/architecture/nodes/#node-controller

slides/k8s/kubectlproxy.md

@@ -77,9 +77,9 @@ If we wanted to talk to the API, we would need to:
 
 - This is a great tool to learn and experiment with the Kubernetes API
 
-- ... And for serious usages as well (suitable for one-shot scripts)
+- ... And for serious uses as well (suitable for one-shot scripts)
 
-- For unattended use, it is better to create a [service account](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/)
+- For unattended use, it's better to create a [service account](https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/)
 
 ---
 

slides/k8s/kubenet.md

@@ -54,7 +54,7 @@
 
   (15 are listed in the Kubernetes documentation)
 
-- Pods have level 3 (IP) connectivity, but *services* are level 4
+- Pods have level 3 (IP) connectivity, but *services* are level 4 (TCP or UDP)
 
   (Services map to a single UDP or TCP port; no port ranges or arbitrary IP packets)
 

slides/k8s/kubercoins.md

@@ -0,0 +1,244 @@
+# Deploying a sample application
+
+- We will connect to our new Kubernetes cluster
+
+- We will deploy a sample application, "DockerCoins"
+
+- That app features multiple micro-services and a web UI
+
+---
+
+## Connecting to our Kubernetes cluster
+
+- Our cluster has multiple nodes named `node1`, `node2`, etc.
+
+- We will do everything from `node1`
+
+- We have SSH access to the other nodes, but won't need it
+
+  (but we can use it for debugging, troubleshooting, etc.)
+
+.exercise[
+
+- Log into `node1`
+
+- Check that all nodes are `Ready`:
+  ```bash
+  kubectl get nodes
+  ```
+
+]
+
+---
+
+## Cloning some repos
+
+- We will need two repositories:
+
+  - the first one has the "DockerCoins" demo app
+
+  - the second one has these slides, some scripts, more manifests ...
+
+.exercise[
+
+- Clone the kubercoins repository on `node1`:
+  ```bash
+  git clone https://github.com/jpetazzo/kubercoins
+  ```
+
+
+- Clone the container.training repository as well:
+  ```bash
+  git clone https://@@GITREPO@@
+  ```
+
+]
+
+---
+
+## Running the application
+
+Without further ado, let's start this application!
+
+.exercise[
+
+- Apply all the manifests from the kubercoins repository:
+  ```bash
+  kubectl apply -f kubercoins/
+  ```
+
+]
+
+---
+
+## What's this application?
+
+--
+
+- It is a DockerCoin miner! .emoji[💰🐳📦🚢]
+
+--
+
+- No, you can't buy coffee with DockerCoins
+
+--
+
+- How DockerCoins works:
+
+  - generate a few random bytes
+
+  - hash these bytes
+
+  - increment a counter (to keep track of speed)
+
+  - repeat forever!
+
+--
+
+- DockerCoins is *not* a cryptocurrency
+
+  (the only common points are "randomness", "hashing", and "coins" in the name)
+
+---
+
+## DockerCoins in the microservices era
+
+- DockerCoins 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://@@GITREPO@@/blob/master/dockercoins/docker-compose.yml)
+
+---
+
+## 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!)*
+
+---
+
+class: pic
+
+![Diagram showing the 5 containers of the applications](images/dockercoins-diagram.svg)
+
+---
+
+## 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")
+
+---
+
+## 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://@@GITREPO@@/blob/8279a3bce9398f7c1a53bdd95187c53eda4e6435/dockercoins/worker/worker.py#L17
+))
+
+---
+
+## Show me the code!
+
+- You can check the GitHub repository with all the materials of this workshop:
+  <br/>https://@@GITREPO@@
+
+- The application is in the [dockercoins](
+  https://@@GITREPO@@/tree/master/dockercoins)
+  subdirectory
+
+- The Compose file ([docker-compose.yml](
+  https://@@GITREPO@@/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://@@GITREPO@@/blob/master/dockercoins/hasher/) directory,
+  `rng` is in the [rng](https://@@GITREPO@@/blob/master/dockercoins/rng/)
+  directory, etc.)
+
+---
+
+## Our application at work
+
+- We can check the logs of our application's pods
+
+.exercise[
+
+- Check the logs of the various components:
+  ```bash
+  kubectl logs deploy/worker
+  kubectl logs deploy/hasher
+  ```
+
+]
+
+---
+
+## Connecting to the web UI
+
+- "Logs are exciting and fun!" (No-one, ever)
+
+- The `webui` container exposes a web dashboard; let's view it
+
+.exercise[
+
+- Check the NodePort allocated to the web UI:
+  ```bash
+  kubectl get svc webui
+  ```
+
+- Open that in a web browser
+
+]
+
+A drawing area should show up, and after a few seconds, a blue
+graph will appear.

slides/k8s/kustomize.md

@@ -70,7 +70,7 @@
 
 - We need to run `ship init` in a new directory
 
-- `ship init` requires an URL to a remote repository containing Kubernetes YAML
+- `ship init` requires a URL to a remote repository containing Kubernetes YAML
 
 - It will clone that repository and start a web UI
 

slides/k8s/lastwords-admin.md

@@ -48,7 +48,7 @@
 
 - Acknowledge that a lot of tasks are outsourced
 
-  (e.g. if we add "buy / rack / provision machines" in that list)
+  (e.g. if we add "buy/rack/provision machines" in that list)
 
 ---
 
@@ -122,7 +122,7 @@
 
   (YAML, Helm charts, Kustomize ...)
 
-- Team "run" adjusts some parameters and monitors the application 
+- Team "run" adjusts some parameters and monitors the application
 
 ✔️ parity between dev and prod environments
 
@@ -150,7 +150,7 @@
 
   - do we reward on-call duty without encouraging hero syndrome?
 
-  - do we give resources (time, money) to people to learn?
+  - do we give people resources (time, money) to learn?
 
 ---
 
@@ -183,9 +183,9 @@ are a few tools that can help us.*
 
 - If cloud: public vs. private
 
-- Which vendor / distribution to pick?
+- Which vendor/distribution to pick?
 
-- Which versions / features to enable?
+- Which versions/features to enable?
 
 ---
 
@@ -205,6 +205,6 @@ are a few tools that can help us.*
 
 - Transfer knowledge
 
-  (make sure everyone is on the same page / same level)
+  (make sure everyone is on the same page/level)
 
 - Iterate!

slides/k8s/local-persistent-volumes.md

@@ -32,6 +32,30 @@
 
 ---
 
+## If we have a dynamic provisioner ...
+
+- The labs in this section assume that we *do not* have a dynamic provisioner
+
+- If we do have one, we need to disable it
+
+.exercise[
+
+- Check if we have a dynamic provisioner:
+  ```bash
+  kubectl get storageclass
+  ```
+
+- If the output contains a line with `(default)`, run this command:
+  ```bash
+  kubectl annotate sc storageclass.kubernetes.io/is-default-class- --all
+  ```
+
+- Check again that it is no longer marked as `(default)`
+
+]
+
+---
+
 ## Work in a separate namespace
 
 - To avoid conflicts with existing resources, let's create and use a new namespace
@@ -50,7 +74,7 @@
 
 ]
 
-.warning[Make sure to call that namespace `orange`, because that name is hardcoded in the YAML files.]
+.warning[Make sure to call that namespace `orange`: it is hardcoded in the YAML files.]
 
 ---
 

slides/k8s/localkubeconfig.md

@@ -1,8 +1,8 @@
-# Controlling the cluster remotely
+# Controlling a Kubernetes cluster remotely
 
-- All the operations that we do with `kubectl` can be done remotely
+- `kubectl` can be used either on cluster instances or outside the cluster
 
-- In this section, we are going to use `kubectl` from our local machine
+- Here, we are going to use `kubectl` from our local machine
 
 ---
 
@@ -34,11 +34,11 @@
 
 - Download the `kubectl` binary from one of these links:
 
-  [Linux](https://storage.googleapis.com/kubernetes-release/release/v1.14.2/bin/linux/amd64/kubectl)
+  [Linux](https://storage.googleapis.com/kubernetes-release/release/v1.15.0/bin/linux/amd64/kubectl)
   |
-  [macOS](https://storage.googleapis.com/kubernetes-release/release/v1.14.2/bin/darwin/amd64/kubectl)
+  [macOS](https://storage.googleapis.com/kubernetes-release/release/v1.15.0/bin/darwin/amd64/kubectl)
   |
-  [Windows](https://storage.googleapis.com/kubernetes-release/release/v1.14.2/bin/windows/amd64/kubectl.exe)
+  [Windows](https://storage.googleapis.com/kubernetes-release/release/v1.15.0/bin/windows/amd64/kubectl.exe)
 
 - On Linux and macOS, make the binary executable with `chmod +x kubectl`
 
@@ -67,17 +67,17 @@ Note: if you are following along with a different platform (e.g. Linux on an arc
 
 The output should look like this:
 ```
-Client Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.0",
-GitCommit:"641856db18352033a0d96dbc99153fa3b27298e5", GitTreeState:"clean",
-BuildDate:"2019-03-25T15:53:57Z", GoVersion:"go1.12.1", Compiler:"gc",
-Platform:"linux/amd64"}
+Client Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.0",
+GitCommit:"e8462b5b5dc2584fdcd18e6bcfe9f1e4d970a529", GitTreeState:"clean",
+BuildDate:"2019-06-19T16:40:16Z", GoVersion:"go1.12.5", Compiler:"gc",
+Platform:"darwin/amd64"}
 ```
 
 ---
 
-## Moving away the existing `~/.kube/config`
+## Preserving the existing `~/.kube/config`
 
-- If you already have a `~/.kube/config` file, move it away
+- If you already have a `~/.kube/config` file, rename it
 
   (we are going to overwrite it in the following slides!)
 
@@ -192,4 +192,4 @@ class: extra-details
 
 ]
 
-We can now utilize the cluster exactly as we did before, ignoring that it's remote.
+We can now utilize the cluster exactly as if we're logged into a node, except that it's remote.

slides/k8s/logs-centralized.md

@@ -73,12 +73,12 @@ and a few roles and role bindings (to give fluentd the required permissions).
 
 - Fluentd runs on each node (thanks to a daemon set)
 
-- It binds-mounts `/var/log/containers` from the host (to access these files)
+- It bind-mounts `/var/log/containers` from the host (to access these files)
 
 - It continuously scans this directory for new files; reads them; parses them
 
 - Each log line becomes a JSON object, fully annotated with extra information:
-  <br/>container id, pod name, Kubernetes labels ...
+  <br/>container id, pod name, Kubernetes labels...
 
 - These JSON objects are stored in ElasticSearch
 

slides/k8s/logs-cli.md

@@ -1,6 +1,6 @@
 # Accessing logs from the CLI
 
-- The `kubectl logs` commands has limitations:
+- The `kubectl logs` command has limitations:
 
   - it cannot stream logs from multiple pods at a time
 
@@ -12,7 +12,7 @@
 
 ## Doing it manually
 
-- We *could* (if we were so inclined), write a program or script that would:
+- We *could* (if we were so inclined) write a program or script that would:
 
   - take a selector as an argument
 
@@ -62,7 +62,7 @@ Exactly what we need!
 - The following commands will install Stern on a Linux Intel 64 bit machine:
   ```bash
   sudo curl -L -o /usr/local/bin/stern \
-       https://github.com/wercker/stern/releases/download/1.10.0/stern_linux_amd64
+       https://github.com/wercker/stern/releases/download/1.11.0/stern_linux_amd64
   sudo chmod +x /usr/local/bin/stern
   ```
 
@@ -72,11 +72,11 @@ Exactly what we need!
 
 ## Using Stern
 
-- There are two ways to specify the pods for which we want to see the logs:
+- There are two ways to specify the pods whose logs we want to see:
 
   - `-l` followed by a selector expression (like with many `kubectl` commands)
 
-  - with a "pod query", i.e. a regex used to match pod names
+  - with a "pod query," i.e. a regex used to match pod names
 
 - These two ways can be combined if necessary
 

slides/k8s/metrics-server.md

@@ -1,8 +1,8 @@
 # Checking pod and node resource usage
 
-- Since Kubernetes 1.8, metrics are collected by the [core metrics pipeline](https://v1-13.docs.kubernetes.io/docs/tasks/debug-application-cluster/core-metrics-pipeline/)
+- Since Kubernetes 1.8, metrics are collected by the [resource metrics pipeline](https://kubernetes.io/docs/tasks/debug-application-cluster/resource-metrics-pipeline/)
 
-- The core metrics pipeline is:
+- The resource metrics pipeline is:
 
   - optional (Kubernetes can function without it)
 
@@ -37,7 +37,7 @@ If it shows our nodes and their CPU and memory load, we're good!
 
   (it doesn't need persistence, as it doesn't *store* metrics)
 
-- It has its own repository, [kubernetes-incubator/metrics-server](https://github.com/kubernetes-incubator/metrics-server])
+- It has its own repository, [kubernetes-incubator/metrics-server](https://github.com/kubernetes-incubator/metrics-server)
 
 - The repository comes with [YAML files for deployment](https://github.com/kubernetes-incubator/metrics-server/tree/master/deploy/1.8%2B)
 
@@ -59,7 +59,7 @@ If it shows our nodes and their CPU and memory load, we're good!
 
 - Show resource usage across all containers:
   ```bash
-  kuebectl top pods --containers --all-namespaces
+  kubectl top pods --containers --all-namespaces
   ```
 ]
 

slides/k8s/multinode.md

@@ -96,7 +96,7 @@ class: extra-details
 
 - We need to generate a `kubeconfig` file for kubelet
 
-- This time, we need to put the IP address of `kubenet1`
+- This time, we need to put the public IP address of `kubenet1`
 
   (instead of `localhost` or `127.0.0.1`)
 
@@ -104,12 +104,10 @@ class: extra-details
 
 - Generate the `kubeconfig` file:
   ```bash
-    kubectl --kubeconfig ~/kubeconfig config \
-            set-cluster kubenet --server http://`X.X.X.X`:8080
-    kubectl --kubeconfig ~/kubeconfig config \
-            set-context kubenet --cluster kubenet
-    kubectl --kubeconfig ~/kubeconfig config\
-            use-context kubenet
+    kubectl config set-cluster kubenet --server http://`X.X.X.X`:8080
+    kubectl config set-context kubenet --cluster kubenet
+    kubectl config use-context kubenet
+    cp ~/.kube/config ~/kubeconfig
   ```
 
 ]
@@ -197,7 +195,7 @@ class: extra-details
 
 ## Check our pods
 
-- The pods will be scheduled to the nodes
+- The pods will be scheduled on the nodes
 
 - The nodes will pull the `nginx` image, and start the pods
 
@@ -327,7 +325,7 @@ class: extra-details
 
 - We will add the `--network-plugin` and `--pod-cidr` flags
 
-- We all have a "cluster number" (let's call that `C`)
+- We all have a "cluster number" (let's call that `C`) printed on your VM info card
 
 - We will use pod CIDR `10.C.N.0/24` (where `N` is the node number: 1, 2, 3)
 
@@ -482,6 +480,23 @@ Sometimes it works, sometimes it doesn't. Why?
   ```bash
   kubectl get nodes -o wide
   ```
+
+---
+
+## Firewalling
+
+- By default, Docker prevents containers from using arbitrary IP addresses
+
+  (by setting up iptables rules)
+
+- We need to allow our containers to use our pod CIDR
+
+- For simplicity, we will insert a blanket iptables rule allowing all traffic:
+
+  `iptables -I FORWARD -j ACCEPT`
+
+- This has to be done on every node
+
 ---
 
 ## Setting up routing
@@ -490,6 +505,8 @@ Sometimes it works, sometimes it doesn't. Why?
 
 - Create all the routes on all the nodes
 
+- Insert the iptables rule allowing traffic
+
 - Check that you can ping all the pods from one of the nodes
 
 - Check that you can `curl` the ClusterIP of the Service successfully

slides/k8s/namespaces.md

@@ -8,7 +8,7 @@
 
 - That would require updating the code
 
-- There as to be a better way!
+- There has to be a better way!
 
 --
 
@@ -26,7 +26,7 @@
 
 - We cannot have two resources *of the same kind* with the same name
 
-  (but it's OK to have a `rng` service, a `rng` deployment, and a `rng` daemon set)
+  (but it's OK to have an `rng` service, an `rng` deployment, and an `rng` daemon set)
 
 --
 

slides/k8s/netpol.md

@@ -307,7 +307,7 @@ This policy selects all pods in the current namespace.
 
 It allows traffic only from pods in the current namespace.
 
-(An empty `podSelector` means "all pods".)
+(An empty `podSelector` means "all pods.")
 
 ```yaml
 kind: NetworkPolicy
@@ -329,7 +329,7 @@ This policy selects all pods with label `app=webui`.
 
 It allows traffic from any source.
 
-(An empty `from` fields means "all sources".)
+(An empty `from` field means "all sources.")
 
 ```yaml
 kind: NetworkPolicy
@@ -412,7 +412,7 @@ troubleshoot easily, without having to poke holes in our firewall.
 
 - If we block access to the control plane, we might disrupt legitimate code
 
-- ... Without necessarily improving security
+- ...Without necessarily improving security
 
 ---
 

slides/k8s/openid-connect.md

@@ -0,0 +1,379 @@
+# OpenID Connect
+
+- The Kubernetes API server can perform authentication with OpenID connect
+
+- This requires an *OpenID provider*
+
+  (external authorization server using the OAuth 2.0 protocol)
+
+- We can use a third-party provider (e.g. Google) or run our own (e.g. Dex)
+
+- We are going to give an overview of the protocol
+
+- We will show it in action (in a simplified scenario)
+
+---
+
+## Workflow overview
+
+- We want to access our resources (a Kubernetes cluster)
+
+- We authenticate with the OpenID provider
+
+  - we can do this directly (e.g. by going to https://accounts.google.com)
+
+  - or maybe a kubectl plugin can open a browser page on our behalf
+
+- After authenticating us, the OpenID provider gives us:
+
+  - an *id token* (a short-lived signed JSON Web Token, see next slide)
+
+  - a *refresh token* (to renew the *id token* when needed)
+
+- We can now issue requests to the Kubernetes API with the *id token*
+
+- The API server will verify that token's content to authenticate us
+
+---
+
+## JSON Web Tokens
+
+- A JSON Web Token (JWT) has three parts:
+
+  - a header specifying algorithms and token type
+
+  - a payload (indicating who issued the token, for whom, which purposes...)
+
+  - a signature generated by the issuer (the issuer = the OpenID provider)
+
+- Anyone can verify a JWT without contacting the issuer
+
+  (except to obtain the issuer's public key)
+
+- Pro tip: we can inspect a JWT with https://jwt.io/
+
+---
+
+## How the Kubernetes API uses JWT
+
+- Server side
+
+  - enable OIDC authentication
+
+  - indicate which issuer (provider) should be allowed
+
+  - indicate which audience (or "client id") should be allowed
+
+  - optionally, map or prefix user and group names
+
+- Client side
+
+  - obtain JWT as described earlier
+
+  - pass JWT as authentication token
+
+  - renew JWT when needed (using the refresh token)
+
+---
+
+## Demo time!
+
+- We will use [Google Accounts](https://accounts.google.com) as our OpenID provider
+
+- We will use the [Google OAuth Playground](https://developers.google.com/oauthplayground) as the "audience" or "client id"
+
+- We will obtain a JWT through Google Accounts and the OAuth Playground
+
+- We will enable OIDC in the Kubernetes API server
+
+- We will use the JWT to authenticate
+
+.footnote[If you can't or won't use a Google account, you can try to adapt this to another provider.]
+
+---
+
+## Checking the API server logs
+
+- The API server logs will be particularly useful in this section
+
+  (they will indicate e.g. why a specific token is rejected)
+
+- Let's keep an eye on the API server output!
+
+.exercise[
+
+- Tail the logs of the API server:
+  ```bash
+  kubectl logs kube-apiserver-node1 --follow --namespace=kube-system
+  ```
+
+]
+
+---
+
+## Authenticate with the OpenID provider
+
+- We will use the Google OAuth Playground for convenience
+
+- In a real scenario, we would need our own OAuth client instead of the playground
+
+  (even if we were still using Google as the OpenID provider)
+
+.exercise[
+
+- Open the Google OAuth Playground:
+  ```
+  https://developers.google.com/oauthplayground/
+  ```
+
+- Enter our own custom scope in the text field:
+  ```
+  https://www.googleapis.com/auth/userinfo.email
+  ```
+
+- Click on "Authorize APIs" and allow the playground to access our email address
+
+]
+
+---
+
+## Obtain our JSON Web Token
+
+- The previous step gave us an "authorization code"
+
+- We will use it to obtain tokens
+
+.exercise[
+
+- Click on "Exchange authorization code for tokens"
+
+]
+
+- The JWT is the very long `id_token` that shows up on the right hand side
+
+  (it is a base64-encoded JSON object, and should therefore start with `eyJ`)
+
+---
+
+## Using our JSON Web Token
+
+- We need to create a context (in kubeconfig) for our token
+
+  (if we just add the token or use `kubectl --token`, our certificate will still be used)
+
+.exercise[
+
+- Create a new authentication section in kubeconfig:
+  ```bash
+  kubectl config set-credentials myjwt --token=eyJ...
+  ```
+
+- Try to use it:
+  ```bash
+  kubectl --user=myjwt get nodes
+  ```
+
+]
+
+We should get an `Unauthorized` response, since we haven't enabled OpenID Connect in the API server yet. We should also see `invalid bearer token` in the API server log output.
+
+---
+
+## Enabling OpenID Connect
+
+- We need to add a few flags to the API server configuration
+
+- These two are mandatory:
+
+  `--oidc-issuer-url` → URL of the OpenID provider
+
+  `--oidc-client-id` → app requesting the authentication
+  <br/>(in our case, that's the ID for the Google OAuth Playground)
+
+- This one is optional:
+
+  `--oidc-username-claim` → which field should be used as user name
+  <br/>(we will use the user's email address instead of an opaque ID)
+
+- See the [API server documentation](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#configuring-the-api-server
+) for more details about all available flags
+
+---
+
+## Updating the API server configuration
+
+- The instructions below will work for clusters deployed with kubeadm
+
+  (or where the control plane is deployed in static pods)
+
+- If your cluster is deployed differently, you will need to adapt them
+
+.exercise[
+
+- Edit `/etc/kubernetes/manifests/kube-apiserver.yaml`
+
+- Add the following lines to the list of command-line flags:
+  ```yaml
+  - --oidc-issuer-url=https://accounts.google.com
+  - --oidc-client-id=407408718192.apps.googleusercontent.com
+  - --oidc-username-claim=email
+  ```
+]
+
+---
+
+## Restarting the API server
+
+- The kubelet monitors the files in `/etc/kubernetes/manifests`
+
+- When we save the pod manifest, kubelet will restart the corresponding pod
+
+  (using the updated command line flags)
+
+.exercise[
+
+- After making the changes described on the previous slide, save the file
+
+- Issue a simple command (like `kubectl version`) until the API server is back up
+
+  (it might take between a few seconds and one minute for the API server to restart)
+
+- Restart the `kubectl logs` command to view the logs of the API server
+
+]
+
+---
+
+## Using our JSON Web Token
+
+- Now that the API server is set up to recognize our token, try again!
+
+.exercise[
+
+- Try an API command with our token:
+  ```bash
+  kubectl --user=myjwt get nodes
+  kubectl --user=myjwt get pods
+  ```
+
+]
+
+We should see a message like:
+```
+Error from server (Forbidden): nodes is forbidden: User "jean.doe@gmail.com"
+cannot list resource "nodes" in API group "" at the cluster scope
+```
+
+→ We were successfully *authenticated*, but not *authorized*.
+
+---
+
+## Authorizing our user
+
+- As an extra step, let's grant read access to our user
+
+- We will use the pre-defined ClusterRole `view`
+
+.exercise[
+
+- Create a ClusterRoleBinding allowing us to view resources:
+  ```bash
+    kubectl create clusterrolebinding i-can-view \
+            --user=`jean.doe@gmail.com` --clusterrole=view
+  ```
+
+  (make sure to put *your* Google email address there)
+
+- Confirm that we can now list pods with our token:
+   ```bash
+  kubectl --user=myjwt get pods
+  ```
+
+]
+
+---
+
+## From demo to production
+
+.warning[This was a very simplified demo! In a real deployment...]
+
+- We wouldn't use the Google OAuth Playground
+
+- We *probably* wouldn't even use Google at all
+
+  (it doesn't seem to provide a way to include groups!)
+
+- Some popular alternatives:
+
+  - [Dex](https://github.com/dexidp/dex),
+    [Keycloak](https://www.keycloak.org/)
+    (self-hosted)
+
+  - [Okta](https://developer.okta.com/docs/how-to/creating-token-with-groups-claim/#step-five-decode-the-jwt-to-verify)
+    (SaaS)
+
+- We would use a helper (like the [kubelogin](https://github.com/int128/kubelogin) plugin) to automatically obtain tokens
+
+---
+
+class: extra-details
+
+## Service Account tokens
+
+- The tokens used by Service Accounts are JWT tokens as well
+
+- They are signed and verified using a special service account key pair
+
+.exercise[
+
+- Extract the token of a service account in the current namespace:
+  ```bash
+  kubectl get secrets -o jsonpath={..token} | base64 -d
+  ```
+
+- Copy-paste the token to a verification service like https://jwt.io 
+
+- Notice that it says "Invalid Signature"
+
+]
+
+---
+
+class: extra-details
+
+## Verifying Service Account tokens
+
+- JSON Web Tokens embed the URL of the "issuer" (=OpenID provider)
+
+- The issuer provides its public key through a well-known discovery endpoint
+
+  (similar to https://accounts.google.com/.well-known/openid-configuration)
+
+- There is no such endpoint for the Service Account key pair
+
+- But we can provide the public key ourselves for verification
+
+---
+
+class: extra-details
+
+## Verifying a Service Account token
+
+- On clusters provisioned with kubeadm, the Service Account key pair is:
+
+  `/etc/kubernetes/pki/sa.key` (used by the controller manager to generate tokens)
+
+  `/etc/kubernetes/pki/sa.pub` (used by the API server to validate the same tokens)
+
+.exercise[
+
+- Display the public key used to sign Service Account tokens:
+  ```bash
+  sudo cat /etc/kubernetes/pki/sa.pub
+  ```
+
+- Copy-paste the key in the "verify signature" area on https://jwt.io
+
+- It should now say "Signature Verified"
+
+]

slides/k8s/operators-design.md

@@ -0,0 +1,356 @@
+## What does it take to write an operator?
+
+- Writing a quick-and-dirty operator, or a POC/MVP, is easy
+
+- Writing a robust operator is hard
+
+- We will describe the general idea
+
+- We will identify some of the associated challenges
+
+- We will list a few tools that can help us
+
+---
+
+## Top-down vs. bottom-up
+
+- Both approaches are possible
+
+- Let's see what they entail, and their respective pros and cons
+
+---
+
+## Top-down approach
+
+- Start with high-level design (see next slide)
+
+- Pros:
+
+  - can yield cleaner design that will be more robust
+
+- Cons:
+
+  - must be able to anticipate all the events that might happen
+
+  - design will be better only to the extend of what we anticipated
+
+  - hard to anticipate if we don't have production experience
+
+---
+
+## High-level design
+
+- What are we solving?
+
+  (e.g.: geographic databases backed by PostGIS with Redis caches)
+
+- What are our use-cases, stories?
+
+  (e.g.: adding/resizing caches and read replicas; load balancing queries)
+
+- What kind of outage do we want to address?
+
+  (e.g.: loss of individual node, pod, volume)
+
+- What are our *non-features*, the things we don't want to address?
+
+  (e.g.: loss of datacenter/zone; differentiating between read and write queries;
+  <br/>
+  cache invalidation; upgrading to newer major versions of Redis, PostGIS, PostgreSQL)
+
+---
+
+## Low-level design
+
+- What Custom Resource Definitions do we need?
+
+  (one, many?)
+
+- How will we store configuration information?
+
+  (part of the CRD spec fields, annotations, other?)
+
+- Do we need to store state? If so, where?
+
+  - state that is small and doesn't change much can be stored via the Kubernetes API
+    <br/>
+    (e.g.: leader information, configuration, credentials)
+
+  - things that are big and/or change a lot should go elsewhere
+    <br/>
+    (e.g.: metrics, bigger configuration file like GeoIP)
+
+---
+
+class: extra-details
+
+## What can we store via the Kubernetes API?
+
+- The API server stores most Kubernetes resources in etcd
+
+- Etcd is designed for reliability, not for performance
+
+- If our storage needs exceed what etcd can offer, we need to use something else:
+
+  - either directly
+
+  - or by extending the API server
+    <br/>(for instance by using the agregation layer, like [metrics server](https://github.com/kubernetes-incubator/metrics-server) does)
+
+---
+
+## Bottom-up approach
+
+- Start with existing Kubernetes resources (Deployment, Stateful Set...)
+
+- Run the system in production
+
+- Add scripts, automation, to facilitate day-to-day operations
+
+- Turn the scripts into an operator
+
+- Pros: simpler to get started; reflects actual use-cases
+
+- Cons: can result in convoluted designs requiring extensive refactor
+
+---
+
+## General idea
+
+- Our operator will watch its CRDs *and associated resources*
+
+- Drawing state diagrams and finite state automata helps a lot
+
+- It's OK if some transitions lead to a big catch-all "human intervention"
+
+- Over time, we will learn about new failure modes and add to these diagrams
+
+- It's OK to start with CRD creation / deletion and prevent any modification
+
+  (that's the easy POC/MVP we were talking about)
+
+- *Presentation* and *validation* will help our users
+
+  (more on that later)
+
+---
+
+## Challenges
+
+- Reacting to infrastructure disruption can seem hard at first
+
+- Kubernetes gives us a lot of primitives to help:
+
+  - Pods and Persistent Volumes will *eventually* recover
+
+  - Stateful Sets give us easy ways to "add N copies" of a thing
+
+- The real challenges come with configuration changes
+
+  (i.e., what to do when our users update our CRDs)
+
+- Keep in mind that [some] of the [largest] cloud [outages] haven't been caused by [natural catastrophes], or even code bugs, but by configuration changes
+
+[some]: https://www.datacenterdynamics.com/news/gcp-outage-mainone-leaked-google-cloudflare-ip-addresses-china-telecom/
+[largest]: https://aws.amazon.com/message/41926/
+[outages]: https://aws.amazon.com/message/65648/
+[natural catastrophes]: https://www.datacenterknowledge.com/amazon/aws-says-it-s-never-seen-whole-data-center-go-down
+
+---
+
+## Configuration changes
+
+- It is helpful to analyze and understand how Kubernetes controllers work:
+
+  - watch resource for modifications
+
+  - compare desired state (CRD) and current state
+
+  - issue actions to converge state
+
+- Configuration changes will probably require *another* state diagram or FSA
+
+- Again, it's OK to have transitions labeled as "unsupported"
+
+  (i.e. reject some modifications because we can't execute them)
+
+---
+
+## Tools
+
+- CoreOS / RedHat Operator Framework
+
+  [GitHub](https://github.com/operator-framework)
+  |
+  [Blog](https://developers.redhat.com/blog/2018/12/18/introduction-to-the-kubernetes-operator-framework/)
+  |
+  [Intro talk](https://www.youtube.com/watch?v=8k_ayO1VRXE)
+  |
+  [Deep dive talk](https://www.youtube.com/watch?v=fu7ecA2rXmc)
+
+- Zalando Kubernetes Operator Pythonic Framework (KOPF)
+
+  [GitHub](https://github.com/zalando-incubator/kopf)
+  |
+  [Docs](https://kopf.readthedocs.io/)
+  |
+  [Step-by-step tutorial](https://kopf.readthedocs.io/en/stable/walkthrough/problem/)
+
+- Mesosphere Kubernetes Universal Declarative Operator (KUDO)
+
+  [GitHub](https://github.com/kudobuilder/kudo)
+  |
+  [Blog](https://mesosphere.com/blog/announcing-maestro-a-declarative-no-code-approach-to-kubernetes-day-2-operators/)
+  |
+  [Docs](https://kudo.dev/)
+  |
+  [Zookeeper example](https://github.com/kudobuilder/frameworks/tree/master/repo/stable/zookeeper)
+
+---
+
+## Validation
+
+- By default, a CRD is "free form"
+
+  (we can put pretty much anything we want in it)
+
+- When creating a CRD, we can provide an OpenAPI v3 schema
+  ([Example](https://github.com/amaizfinance/redis-operator/blob/master/deploy/crds/k8s_v1alpha1_redis_crd.yaml#L34))
+
+- The API server will then validate resources created/edited with this schema
+
+- If we need a stronger validation, we can use a Validating Admission Webhook:
+
+  - run an [admission webhook server](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#write-an-admission-webhook-server) to receive validation requests
+
+  - register the webhook by creating a [ValidatingWebhookConfiguration](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/#configure-admission-webhooks-on-the-fly)
+
+  - each time the API server receives a request matching the configuration,
+    <br/>the request is sent to our server for validation
+
+---
+
+## Presentation
+
+- By default, `kubectl get mycustomresource` won't display much information
+
+  (just the name and age of each resource)
+
+- When creating a CRD, we can specify additional columns to print
+  ([Example](https://github.com/amaizfinance/redis-operator/blob/master/deploy/crds/k8s_v1alpha1_redis_crd.yaml#L6),
+  [Docs](https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/#additional-printer-columns))
+
+- By default, `kubectl describe mycustomresource` will also be generic
+
+- `kubectl describe` can show events related to our custom resources
+
+  (for that, we need to create Event resources, and fill the `involvedObject` field)
+
+- For scalable resources, we can define a `scale` sub-resource
+
+- This will enable the use of `kubectl scale` and other scaling-related operations
+
+---
+
+## About scaling
+
+- It is possible to use the HPA (Horizontal Pod Autoscaler) with CRDs
+
+- But it is not always desirable
+
+- The HPA works very well for homogenous, stateless workloads
+
+- For other workloads, your mileage may vary
+
+- Some systems can scale across multiple dimensions
+
+  (for instance: increase number of replicas, or number of shards?)
+
+- If autoscaling is desired, the operator will have to take complex decisions
+
+  (example: Zalando's Elasticsearch Operator ([Video](https://www.youtube.com/watch?v=lprE0J0kAq0)))
+
+---
+
+## Versioning
+
+- As our operator evolves over time, we may have to change the CRD
+
+  (add, remove, change fields)
+
+- Like every other resource in Kubernetes, [custom resources are versioned](https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning/
+)
+
+- When creating a CRD, we need to specify a *list* of versions
+
+- Versions can be marked as `stored` and/or `served`
+
+---
+
+## Stored version
+
+- Exactly one version has to be marked as the `stored` version
+
+- As the name implies, it is the one that will be stored in etcd
+
+- Resources in storage are never converted automatically
+
+  (we need to read and re-write them ourselves)
+
+- Yes, this means that we can have different versions in etcd at any time
+
+- Our code needs to handle all the versions that still exist in storage
+
+---
+
+## Served versions
+
+- By default, the Kubernetes API will serve resources "as-is"
+
+  (using their stored version)
+
+- It will assume that all versions are compatible storage-wise
+
+  (i.e. that the spec and fields are compatible between versions)
+
+- We can provide [conversion webhooks](https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definition-versioning/#webhook-conversion) to "translate" requests
+
+  (the alternative is to upgrade all stored resources and stop serving old versions)
+
+---
+
+## Operator reliability
+
+- Remember that the operator itself must be resilient
+
+  (e.g.: the node running it can fail)
+
+- Our operator must be able to restart and recover gracefully
+
+- Do not store state locally
+
+  (unless we can reconstruct that state when we restart)
+
+- As indicated earlier, we can use the Kubernetes API to store data:
+
+  - in the custom resources themselves
+
+  - in other resources' annotations
+
+---
+
+## Beyond CRDs
+
+- CRDs cannot use custom storage (e.g. for time series data)
+
+- CRDs cannot support arbitrary subresources (like logs or exec for Pods)
+
+- CRDs cannot support protobuf (for faster, more efficient communication)
+
+- If we need these things, we can use the [aggregation layer](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) instead
+
+- The aggregation layer proxies all requests below a specific path to another server
+
+  (this is used e.g. by the metrics server)
+
+- [This documentation page](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/#choosing-a-method-for-adding-custom-resources) compares the features of CRDs and API aggregation

slides/k8s/operators.md

@@ -0,0 +1,389 @@
+# Operators
+
+- Operators are one of the many ways to extend Kubernetes
+
+- We will define operators
+
+- We will see how they work
+
+- We will install a specific operator (for ElasticSearch)
+
+- We will use it to provision an ElasticSearch cluster
+
+---
+
+## What are operators?
+
+*An operator represents **human operational knowledge in software,**
+<br/>
+to reliably manage an application.
+— [CoreOS](https://coreos.com/blog/introducing-operators.html)*
+
+Examples:
+
+- Deploying and configuring replication with MySQL, PostgreSQL ...
+
+- Setting up Elasticsearch, Kafka, RabbitMQ, Zookeeper ...
+
+- Reacting to failures when intervention is needed
+
+- Scaling up and down these systems
+
+---
+
+## What are they made from?
+
+- Operators combine two things:
+
+  - Custom Resource Definitions
+
+  - controller code watching the corresponding resources and acting upon them
+
+- A given operator can define one or multiple CRDs
+
+- The controller code (control loop) typically runs within the cluster
+
+  (running as a Deployment with 1 replica is a common scenario)
+
+- But it could also run elsewhere
+
+  (nothing mandates that the code run on the cluster, as long as it has API access)
+
+---
+
+## Why use operators?
+
+- Kubernetes gives us Deployments, StatefulSets, Services ...
+
+- These mechanisms give us building blocks to deploy applications
+
+- They work great for services that are made of *N* identical containers
+
+  (like stateless ones)
+
+- They also work great for some stateful applications like Consul, etcd ...
+
+  (with the help of highly persistent volumes)
+
+- They're not enough for complex services:
+
+  - where different containers have different roles
+
+  - where extra steps have to be taken when scaling or replacing containers
+
+---
+
+## Use-cases for operators
+
+- Systems with primary/secondary replication
+
+  Examples: MariaDB, MySQL, PostgreSQL, Redis ...
+
+- Systems where different groups of nodes have different roles
+
+  Examples: ElasticSearch, MongoDB ...
+
+- Systems with complex dependencies (that are themselves managed with operators)
+
+  Examples: Flink or Kafka, which both depend on Zookeeper
+
+---
+
+## More use-cases
+
+- Representing and managing external resources
+
+  (Example: [AWS Service Operator](https://operatorhub.io/operator/alpha/aws-service-operator.v0.0.1))
+
+- Managing complex cluster add-ons
+
+  (Example: [Istio operator](https://operatorhub.io/operator/beta/istio-operator.0.1.6))
+
+- Deploying and managing our applications' lifecycles
+
+  (more on that later)
+
+---
+
+## How operators work
+
+- An operator creates one or more CRDs
+
+  (i.e., it creates new "Kinds" of resources on our cluster)
+
+- The operator also runs a *controller* that will watch its resources
+
+- Each time we create/update/delete a resource, the controller is notified
+
+  (we could write our own cheap controller with `kubectl get --watch`)
+
+---
+
+## One operator in action
+
+- We will install the UPMC Enterprises ElasticSearch operator
+
+- This operator requires PersistentVolumes
+
+- We will install Rancher's [local path storage provisioner](https://github.com/rancher/local-path-provisioner) to automatically create these
+
+- Then, we will create an ElasticSearch resource
+
+- The operator will detect that resource and provision the cluster
+
+---
+
+## Installing a Persistent Volume provisioner
+
+(This step can be skipped if you already have a dynamic volume provisioner.)
+
+- This provisioner creates Persistent Volumes backed by `hostPath`
+
+  (local directories on our nodes)
+
+- It doesn't require anything special ...
+
+- ... But losing a node = losing the volumes on that node!
+
+.exercise[
+
+- Install the local path storage provisioner:
+  ```bash
+  kubectl apply -f ~/container.training/k8s/local-path-storage.yaml
+  ```
+
+]
+
+---
+
+## Making sure we have a default StorageClass
+
+- The ElasticSearch operator will create StatefulSets
+
+- These StatefulSets will instantiate PersistentVolumeClaims
+
+- These PVCs need to be explicitly associated with a StorageClass
+
+- Or we need to tag a StorageClass to be used as the default one
+
+.exercise[
+
+- List StorageClasses:
+  ```bash
+  kubectl get storageclasses
+  ```
+
+]
+
+We should see the `local-path` StorageClass.
+
+---
+
+## Setting a default StorageClass
+
+- This is done by adding an annotation to the StorageClass:
+
+  `storageclass.kubernetes.io/is-default-class: true`
+
+.exercise[
+
+- Tag the StorageClass so that it's the default one:
+  ```bash
+  kubectl annotate storageclass local-path \
+            storageclass.kubernetes.io/is-default-class=true
+  ```
+
+- Check the result:
+  ```bash
+  kubectl get storageclasses
+  ```
+
+]
+
+Now, the StorageClass should have `(default)` next to its name.
+
+---
+
+## Install the ElasticSearch operator
+
+- The operator needs:
+
+  - a Deployment for its controller
+  - a ServiceAccount, ClusterRole, ClusterRoleBinding for permissions
+  - a Namespace
+
+- We have grouped all the definitions for these resources in a YAML file
+
+.exercise[
+
+- Install the operator:
+  ```bash
+  kubectl apply -f ~/container.training/k8s/elasticsearch-operator.yaml
+  ```
+
+]
+
+---
+
+## Wait for the operator to be ready
+
+- Some operators require to create their CRDs separately
+
+- This operator will create its CRD itself
+
+  (i.e. the CRD is not listed in the YAML that we applied earlier)
+
+.exercise[
+
+- Wait until the `elasticsearchclusters` CRD shows up:
+  ```bash
+  kubectl get crds
+  ```
+
+]
+
+---
+
+## Create an ElasticSearch resource
+
+- We can now create a resource with `kind: ElasticsearchCluster`
+
+- The YAML for that resource will specify all the desired parameters:
+
+  - how many nodes do we want of each type (client, master, data)
+  - image to use
+  - add-ons (kibana, cerebro, ...)
+  - whether to use TLS or not
+  - etc.
+
+.exercise[
+
+- Create our ElasticSearch cluster:
+  ```bash
+  kubectl apply -f ~/container.training/k8s/elasticsearch-cluster.yaml
+  ```
+
+]
+
+---
+
+## Operator in action
+
+- Over the next minutes, the operator will create:
+
+  - StatefulSets (one for master nodes, one for data nodes)
+
+  - Deployments (for client nodes; and for add-ons like cerebro and kibana)
+
+  - Services (for all these pods)
+
+.exercise[
+
+- Wait for all the StatefulSets to be fully up and running:
+  ```bash
+  kubectl get statefulsets -w
+  ```
+
+]
+
+---
+
+## Connecting to our cluster
+
+- Since connecting directly to the ElasticSearch API is a bit raw,
+  <br/>we'll connect to the cerebro frontend instead
+
+.exercise[
+
+- Edit the cerebro service to change its type from ClusterIP to NodePort:
+  ```bash
+  kubectl patch svc cerebro-es -p "spec: { type: NodePort }"
+  ```
+
+- Retrieve the NodePort that was allocated:
+  ```bash
+  kubectl get svc cerebro-es
+  ```
+
+- Connect to that port with a browser
+
+]
+
+---
+
+## (Bonus) Setup filebeat
+
+- Let's send some data to our brand new ElasticSearch cluster!
+
+- We'll deploy a filebeat DaemonSet to collect node logs
+
+.exercise[
+
+- Deploy filebeat:
+  ```bash
+  kubectl apply -f ~/container.training/k8s/filebeat.yaml
+  ```
+
+]
+
+We should see at least one index being created in cerebro.
+
+---
+
+## (Bonus) Access log data with kibana
+
+- Let's expose kibana (by making kibana-es a NodePort too)
+
+- Then access kibana
+
+- We'll need to configure kibana indexes
+
+---
+
+## Deploying our apps with operators
+
+- It is very simple to deploy with `kubectl run` / `kubectl expose`
+
+- We can unlock more features by writing YAML and using `kubectl apply`
+
+- Kustomize or Helm let us deploy in multiple environments
+
+  (and adjust/tweak parameters in each environment)
+
+- We can also use an operator to deploy our application
+
+---
+
+## Pros and cons of deploying with operators
+
+- The app definition and configuration is persisted in the Kubernetes API
+
+- Multiple instances of the app can be manipulated with `kubectl get`
+
+- We can add labels, annotations to the app instances
+
+- Our controller can execute custom code for any lifecycle event
+
+- However, we need to write this controller
+
+- We need to be careful about changes
+
+  (what happens when the resource `spec` is updated?)
+
+---
+
+## Operators are not magic
+
+- Look at the ElasticSearch resource definition
+
+  (`~/container.training/k8s/elasticsearch-cluster.yaml`)
+
+- What should happen if we flip the `use-tls` flag? Twice?
+
+- What should happen if we remove / re-add the kibana or cerebro sections?
+
+- What should happen if we change the number of nodes?
+
+- What if we want different images or parameters for the different nodes?
+
+*Operators can be very powerful, iff we know exactly the scenarios that they can handle.*

slides/k8s/podsecuritypolicy.md

@@ -8,12 +8,18 @@
 
 - Then we will explain how to avoid this with PodSecurityPolicies
 
-- We will illustrate this by creating a non-privileged user limited to a namespace
+- We will enable PodSecurityPolicies on our cluster
+
+- We will create a couple of policies (restricted and permissive)
+
+- Finally we will see how to use them to improve security on our cluster
 
 ---
 
 ## Setting up a namespace
 
+- For simplicity, let's work in a separate namespace
+
 - Let's create a new namespace called "green"
 
 .exercise[
@@ -32,168 +38,9 @@
 
 ---
 
-## Using limited credentials
-
-- When a namespace is created, a `default` ServiceAccount is added
-
-- By default, this ServiceAccount doesn't have any access rights
-
-- We will use this ServiceAccount as our non-privileged user
-
-- We will obtain this ServiceAccount's token and add it to a context
-
-- Then we will give basic access rights to this ServiceAccount
-
----
-
-## Obtaining the ServiceAccount's token
-
-- The token is stored in a Secret
-
-- The Secret is listed in the ServiceAccount
-
-.exercise[
-
-- Obtain the name of the Secret from the ServiceAccount::
-  ```bash
-  SECRET=$(kubectl get sa default -o jsonpath={.secrets[0].name})
-  ```
-
-- Extract the token from the Secret object:
-  ```bash
-  TOKEN=$(kubectl get secrets $SECRET -o jsonpath={.data.token}
-          | base64 -d)
-  ```
-
-]
-
----
-
-class: extra-details
-
-## Inspecting a Kubernetes token
-
-- Kubernetes tokens are JSON Web Tokens
-
-  (as defined by [RFC 7519](https://tools.ietf.org/html/rfc7519))
-
-- We can view their content (and even verify them) easily
-
-.exercise[
-
-- Display the token that we obtained:
-  ```bash
-  echo $TOKEN
-  ```
-
-- Copy paste the token in the verification form on https://jwt.io
-
-]
-
----
-
-## Authenticating using the ServiceAccount token
-
-- Let's create a new *context* accessing our cluster with that token
-
-.exercise[
-
-- First, add the token credentials to our kubeconfig file:
-  ```bash
-  kubectl config set-credentials green --token=$TOKEN
-  ```
-
-- Then, create a new context using these credentials:
-  ```bash
-  kubectl config set-context green --user=green --cluster=kubernetes
-  ```
-
-- Check the results:
-  ```bash
-  kubectl config get-contexts
-  ```
-
-]
-
----
-
-## Using the new context
-
-- Normally, this context doesn't let us access *anything* (yet)
-
-.exercise[
-
-- Change to the new context with one of these two commands:
-  ```bash
-  kctx green
-  kubectl config use-context green
-  ```
-
-- Also change to the green namespace in that context:
-  ```bash
-  kns green
-  ```
-
-- Confirm that we don't have access to anything:
-  ```bash
-  kubectl get all
-  ```
-
-]
-
----
-
-## Giving basic access rights
-
-- Let's bind the ClusterRole `edit` to our ServiceAccount
-
-- To allow access only to the namespace, we use a RoleBinding
-
-  (instead of a ClusterRoleBinding, which would give global access)
-
-.exercise[
-
-- Switch back to `cluster-admin`:
-  ```bash
-  kctx -
-  ```
-
-- Create the Role Binding:
-  ```bash
-  kubectl create rolebinding green --clusterrole=edit --serviceaccount=green:default
-  ```
-
-]
-
----
-
-## Verifying access rights
-
-- Let's switch back to the `green` context and check that we have rights
-
-.exercise[
-
-- Switch back to `green`:
-  ```bash
-  kctx green
-  ```
-
-- Check our permissions:
-  ```bash
-  kubectl get all
-  ```
-
-]
-
-We should see an empty list.
-
-(Better than a series of permission errors!)
-
----
-
 ## Creating a basic Deployment
 
-- Just to demonstrate that everything works correctly, deploy NGINX
+- Just to check that everything works correctly, deploy NGINX
 
 .exercise[
 
@@ -202,7 +49,7 @@ We should see an empty list.
   kubectl create deployment web --image=nginx
   ```
 
-- Confirm that the Deployment, ReplicaSet, and Pod exist, and Pod is running:
+- Confirm that the Deployment, ReplicaSet, and Pod exist, and that the Pod is running:
   ```bash
   kubectl get all
   ```
@@ -316,7 +163,7 @@ We should see an empty list.
 - If we create a Pod directly, it can use a PSP to which *we* have access
 
 - If the Pod is created by e.g. a ReplicaSet or DaemonSet, it's different:
- 
+
   - the ReplicaSet / DaemonSet controllers don't have access to *our* policies
 
   - therefore, we need to give access to the PSP to the Pod's ServiceAccount
@@ -331,7 +178,7 @@ We should see an empty list.
 
 - Then we will create a couple of PodSecurityPolicies
 
-- ... And associated ClusterRoles (giving `use` access to the policies)
+- ...And associated ClusterRoles (giving `use` access to the policies)
 
 - Then we will create RoleBindings to grant these roles to ServiceAccounts
 
@@ -365,7 +212,7 @@ We should see an empty list.
 
 - Have a look at the static pods:
   ```bash
-  ls -l /etc/kubernetes/manifest
+  ls -l /etc/kubernetes/manifests
   ```
 
 - Edit the one corresponding to the API server:
@@ -389,7 +236,7 @@ We should see an empty list.
 
 - Add `PodSecurityPolicy`
 
-  (It should read `--enable-admission-plugins=NodeRestriction,PodSecurityPolicy`)
+  It should read: `--enable-admission-plugins=NodeRestriction,PodSecurityPolicy`
 
 - Save, quit
 
@@ -474,12 +321,65 @@ We can get hints at what's happening by looking at the ReplicaSet and Events.
 
 ---
 
+## Check that we can create Pods again
+
+- We haven't bound the policy to any user yet
+
+- But `cluster-admin` can implicitly `use` all policies
+
+.exercise[
+
+- Check that we can now create a Pod directly:
+  ```bash
+  kubectl run testpsp3 --image=nginx --restart=Never
+  ```
+
+- Create a Deployment as well:
+  ```bash
+  kubectl run testpsp4 --image=nginx
+  ```
+
+- Confirm that the Deployment is *not* creating any Pods:
+  ```bash
+  kubectl get all
+  ```
+
+]
+
+---
+
+## What's going on?
+
+- We can create Pods directly (thanks to our root-like permissions)
+
+- The Pods corresponding to a Deployment are created by the ReplicaSet controller
+
+- The ReplicaSet controller does *not* have root-like permissions
+
+- We need to either:
+
+  - grant permissions to the ReplicaSet controller
+
+  *or*
+
+  - grant permissions to our Pods' ServiceAccount
+
+- The first option would allow *anyone* to create pods
+
+- The second option will allow us to scope the permissions better
+
+---
+
 ## Binding the restricted policy
 
 - Let's bind the role `psp:restricted` to ServiceAccount `green:default`
 
   (aka the default ServiceAccount in the green Namespace)
 
+- This will allow Pod creation in the green Namespace
+
+  (because these Pods will be using that ServiceAccount automatically)
+
 .exercise[
 
 - Create the following RoleBinding:
@@ -495,18 +395,17 @@ We can get hints at what's happening by looking at the ReplicaSet and Events.
 
 ## Trying it out
 
-- Let's switch to the `green` context, and try to create resources
+- The Deployments that we created earlier will *eventually* recover
+
+  (the ReplicaSet controller will retry to create Pods once in a while)
+
+- If we create a new Deployment now, it should work immediately
 
 .exercise[
 
-- Switch to the `green` context:
-  ```bash
-  kctx green
-  ```
-
 - Create a simple Deployment:
   ```bash
-  kubectl create deployment web --image=nginx
+  kubectl create deployment testpsp5 --image=nginx
   ```
 
 - Look at the Pods that have been created:
@@ -586,7 +485,7 @@ class: extra-details
 
 - Our cluster is currently broken
 
-  (we can't create pods in kube-system, default, ...)
+  (we can't create pods in namespaces kube-system, default, ...)
 
 - We need to either:
 

slides/k8s/prometheus.md

@@ -20,7 +20,7 @@
 
 - We don't endorse Prometheus more or less than any other system
 
-- It's relatively well integrated within the Cloud Native ecosystem
+- It's relatively well integrated within the cloud-native ecosystem
 
 - It can be self-hosted (this is useful for tutorials like this)
 
@@ -182,7 +182,7 @@ We need to:
 
 - Run the *node exporter* on each node (with a Daemon Set)
 
-- Setup a Service Account so that Prometheus can query the Kubernetes API
+- Set up a Service Account so that Prometheus can query the Kubernetes API
 
 - Configure the Prometheus server
 
@@ -250,7 +250,7 @@ class: extra-details
 
 ## Explaining all the Helm flags
 
-- `helm upgrade prometheus` → upgrade release "prometheus" to the latest version ...
+- `helm upgrade prometheus` → upgrade release "prometheus" to the latest version...
 
   (a "release" is a unique name given to an app deployed with Helm)
 
@@ -288,7 +288,7 @@ class: extra-details
 
 ## Querying some metrics
 
-- This is easy ... if you are familiar with PromQL
+- This is easy... if you are familiar with PromQL
 
 .exercise[
 
@@ -340,7 +340,7 @@ container_cpu_usage_seconds_total
 
   - that it's the total used since the container creation
 
-- Since it's a "total", it is an increasing quantity
+- Since it's a "total," it is an increasing quantity
 
   (we need to compute the derivative if we want e.g. CPU % over time)
 
@@ -433,9 +433,9 @@ class: extra-details
 
 - I/O activity (disk, network), per operation or volume
 
-- Physical/hardware (when applicable): temperature, fan speed ...
+- Physical/hardware (when applicable): temperature, fan speed...
 
-- ... and much more!
+- ...and much more!
 
 ---
 
@@ -448,7 +448,7 @@ class: extra-details
 - RAM breakdown will be different
 
   - active vs inactive memory
-  - some memory is *shared* between containers, and accounted specially
+  - some memory is *shared* between containers, and specially accounted for
 
 - I/O activity is also harder to track
 
@@ -467,11 +467,11 @@ class: extra-details
 
 - Arbitrary metrics related to your application and business
 
-- System performance: request latency, error rate ...
+- System performance: request latency, error rate...
 
-- Volume information: number of rows in database, message queue size ...
+- Volume information: number of rows in database, message queue size...
 
-- Business data: inventory, items sold, revenue ...
+- Business data: inventory, items sold, revenue...
 
 ---
 
@@ -495,7 +495,7 @@ class: extra-details
 
 ## Querying labels
 
-- What if we want to get metrics for containers belong to pod tagged `worker`?
+- What if we want to get metrics for containers belonging to a pod tagged `worker`?
 
 - The cAdvisor exporter does not give us Kubernetes labels
 
@@ -541,8 +541,8 @@ class: extra-details
 
 - That person can set up queries and dashboards for the rest of the team
 
-- It's a little bit likeknowing how to optimize SQL queries, Dockerfiles ...
+- It's a little bit like knowing how to optimize SQL queries, Dockerfiles...
 
   Don't panic if you don't know these tools!
 
-  ... But make sure at least one person in your team is on it 💯
+  ...But make sure at least one person in your team is on it 💯

slides/k8s/record.md

@@ -0,0 +1,169 @@
+# Recording deployment actions
+
+- Some commands that modify a Deployment accept an optional `--record` flag
+
+  (Example: `kubectl set image deployment worker worker=alpine --record`)
+
+- That flag will store the command line in the Deployment
+
+  (Technically, using the annotation `kubernetes.io/change-cause`)
+
+- It gets copied to the corresponding ReplicaSet
+
+  (Allowing to keep track of which command created or promoted this ReplicaSet)
+
+- We can view this information with `kubectl rollout history`
+
+---
+
+## Using `--record`
+
+- Let's make a couple of changes to a Deployment and record them
+
+.exercise[
+
+- Roll back `worker` to image version 0.1:
+  ```bash
+  kubectl set image deployment worker worker=dockercoins/worker:v0.1 --record
+  ```
+
+- Promote it to version 0.2 again:
+  ```bash
+  kubectl set image deployment worker worker=dockercoins/worker:v0.2 --record
+  ```
+
+- View the change history:
+  ```bash
+  kubectl rollout history deployment worker
+  ```
+
+]
+
+---
+
+## Pitfall #1: forgetting `--record`
+
+- What happens if we don't specify `--record`?
+
+.exercise[
+
+- Promote `worker` to image version 0.3:
+  ```bash
+  kubectl set image deployment worker worker=dockercoins/worker:v0.3
+  ```
+
+- View the change history:
+  ```bash
+  kubectl rollout history deployment worker
+  ```
+
+]
+
+--
+
+It recorded version 0.2 instead of 0.3! Why?
+
+---
+
+## How `--record` really works
+
+- `kubectl` adds the annotation `kubernetes.io/change-cause` to the Deployment
+
+- The Deployment controller copies that annotation to the ReplicaSet
+
+- `kubectl rollout history` shows the ReplicaSets' annotations
+
+- If we don't specify `--record`, the annotation is not updated
+
+- The previous value of that annotation is copied to the new ReplicaSet
+
+- In that case, the ReplicaSet annotation does not reflect reality!
+
+---
+
+## Pitfall #2: recording `scale` commands
+
+- What happens if we use `kubectl scale --record`?
+
+.exercise[
+
+- Check the current history:
+  ```bash
+  kubectl rollout history deployment worker
+  ```
+
+- Scale the deployment:
+  ```bash
+  kubectl scale deployment worker --replicas=3 --record
+  ```
+
+- Check the change history again:
+  ```bash
+  kubectl rollout history deployment worker
+  ```
+
+]
+
+--
+
+The last entry in the history was overwritten by the `scale` command! Why?
+
+---
+
+## Actions that don't create a new ReplicaSet
+
+- The `scale` command updates the Deployment definition
+
+- But it doesn't create a new ReplicaSet
+
+- Using the `--record` flag sets the annotation like before
+
+- The annotation gets copied to the existing ReplicaSet
+
+- This overwrites the previous annotation that was there
+
+- In that case, we lose the previous change cause!
+
+---
+
+## Updating the annotation directly
+
+- Let's see what happens if we set the annotation manually
+
+.exercise[
+
+- Annotate the Deployment:
+  ```bash
+  kubectl annotate deployment worker kubernetes.io/change-cause="Just for fun"
+  ```
+
+- Check that our annotation shows up in the change history:
+  ```bash
+  kubectl rollout history deployment worker
+  ```
+
+]
+
+--
+
+Our annotation shows up (and overwrote whatever was there before).
+
+---
+
+## Using change cause
+
+- It sounds like a good idea to use `--record`, but:
+
+  *"Incorrect documentation is often worse than no documentation."*
+  <br/>
+  (Bertrand Meyer)
+
+- If we use `--record` once, we need to either:
+
+  - use it every single time after that
+
+  - or clear the Deployment annotation after using `--record`
+    <br/>
+    (subsequent changes will show up with a `<none>` change cause)
+
+- A safer way is to set it through our tooling

slides/k8s/resource-limits.md

@@ -86,17 +86,17 @@ Each pod is assigned a QoS class (visible in `status.qosClass`).
 
   - as long as the container uses less than the limit, it won't be affected
 
-  - if all containers in a pod have *(limits=requests)*, QoS is "Guaranteed"
+  - if all containers in a pod have *(limits=requests)*, QoS is considered "Guaranteed"
 
 - If requests < limits:
 
   - as long as the container uses less than the request, it won't be affected
 
-  - otherwise, it might be killed / evicted if the node gets overloaded
+  - otherwise, it might be killed/evicted if the node gets overloaded
 
-  - if at least one container has *(requests<limits)*, QoS is "Burstable"
+  - if at least one container has *(requests<limits)*, QoS is considered "Burstable"
 
-- If a pod doesn't have any request nor limit, QoS is "BestEffort"
+- If a pod doesn't have any request nor limit, QoS is considered "BestEffort"
 
 ---
 
@@ -392,7 +392,7 @@ These quotas will apply to the namespace where the ResourceQuota is created.
         count/roles.rbac.authorization.k8s.io: 10
   ```
 
-(The `count/` syntax allows to limit arbitrary objects, including CRDs.)
+(The `count/` syntax allows limiting arbitrary objects, including CRDs.)
 
 ---
 
@@ -400,11 +400,11 @@ These quotas will apply to the namespace where the ResourceQuota is created.
 
 - Quotas can be created with a YAML definition
 
-- ... Or with the `kubectl create quota` command
+- ...Or with the `kubectl create quota` command
 
 - Example:
   ```bash
-  kubectl create quota sparta --hard=pods=300,limits.memory=300Gi
+  kubectl create quota my-resource-quota --hard=pods=300,limits.memory=300Gi
   ```
 
 - With both YAML and CLI form, the values are always under the `hard` section

slides/k8s/rollout.md

@@ -5,9 +5,9 @@
   - new pods are created
 
   - old pods are terminated
-  
+
   - ... all at the same time
-  
+
   - if something goes wrong, ¯\\\_(ツ)\_/¯
 
 ---
@@ -28,7 +28,7 @@
 
   - there will therefore be up to `maxUnavailable`+`maxSurge` pods being updated
 
-- We have the possibility to rollback to the previous version
+- We have the possibility of rolling back to the previous version
   <br/>(if the update fails or is unsatisfactory in any way)
 
 ---
@@ -212,7 +212,7 @@ class: extra-details
 
 ## Checking the dashboard during the bad rollout
 
-If you haven't deployed the Kubernetes dashboard earlier, just skip this slide.
+If you didn't deploy the Kubernetes dashboard earlier, just skip this slide.
 
 .exercise[
 
@@ -255,7 +255,7 @@ Note the `3xxxx` port.
 ```
 -->
 
-- Cancel the deployment and wait for the dust to settle down:
+- Cancel the deployment and wait for the dust to settle:
   ```bash
   kubectl rollout undo deploy worker
   kubectl rollout status deploy worker
@@ -265,6 +265,8 @@ Note the `3xxxx` port.
 
 ---
 
+class: extra-details
+
 ## Changing rollout parameters
 
 - We want to:
@@ -294,6 +296,8 @@ spec:
 
 ---
 
+class: extra-details
+
 ## Applying changes through a YAML patch
 
 - We could use `kubectl edit deployment worker`

slides/k8s/setup-k8s.md

@@ -90,4 +90,4 @@
 
 - For a longer list, check the Kubernetes documentation:
   <br/>
-  it has a great guide to [pick the right solution](https://kubernetes.io/docs/setup/pick-right-solution/) to set up Kubernetes.
+  it has a great guide to [pick the right solution](https://kubernetes.io/docs/setup/#production-environment) to set up Kubernetes.

slides/k8s/setup-managed.md

@@ -20,7 +20,7 @@ with a cloud provider
 
 ## EKS (the hard way)
 
-- [Read the doc](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html)
+- [Read the doc](https://docs.aws.amazon.com/eks/latest/userguide/getting-started-console.html)
 
 - Create service roles, VPCs, and a bunch of other oddities
 
@@ -69,6 +69,8 @@ with a cloud provider
   eksctl get clusters
   ```
 
+.footnote[Note: the AWS documentation has been updated and now includes [eksctl instructions](https://docs.aws.amazon.com/eks/latest/userguide/getting-started-eksctl.html).]
+
 ---
 
 ## GKE (initial setup)
@@ -142,7 +144,7 @@ with a cloud provider
   az login
   ```
 
-- Select a [region](https://azure.microsoft.com/en-us/global-infrastructure/services/?products=kubernetes-service\&regions=all
+- Select a [region](https://azure.microsoft.com/en-us/global-infrastructure/services/?products=kubernetes-service&regions=all
 )
 
 - Create a "resource group":
@@ -166,7 +168,7 @@ with a cloud provider
   az aks get-credentials --resource-group my-aks-group --name my-aks-cluster
   ```
 
-- The cluster has a lot of goodies pre-installed
+- The cluster has useful components pre-installed, such as the metrics server
 
 ---
 
@@ -222,7 +224,7 @@ with a cloud provider
   kubectl config use-context do-xxx1-my-do-cluster
   ```
 
-- The cluster comes with some goodies (like Cilium) but no metrics server
+- The cluster comes with some components (like Cilium) but no metrics server
 
 ---
 

slides/k8s/setup-selfhosted.md

@@ -80,6 +80,8 @@
 
 - Docker Enterprise Edition
 
+- [AKS Engine](https://github.com/Azure/aks-engine)
+
 - Pivotal Container Service (PKS)
 
 - Tectonic by CoreOS

slides/k8s/staticpods.md

@@ -18,7 +18,7 @@
 
 ## A possible approach
 
-- Since each component of the control plane can be replicated ...
+- Since each component of the control plane can be replicated...
 
 - We could set up the control plane outside of the cluster
 
@@ -39,9 +39,9 @@
 - Worst case scenario, we might need to:
 
   - set up a new control plane (outside of the cluster)
-  
+
   - restore a backup from the old control plane
-  
+
   - move the new control plane to the cluster (again)
 
 - This doesn't sound like a great experience
@@ -57,12 +57,12 @@
 - The kubelet can also get a list of *static pods* from:
 
   - a directory containing one (or multiple) *manifests*, and/or
-  
+
   - a URL (serving a *manifest*)
 
 - These "manifests" are basically YAML definitions
 
-  (As produced by `kubectl get pod my-little-pod -o yaml --export`)
+  (As produced by `kubectl get pod my-little-pod -o yaml`)
 
 ---
 
@@ -100,11 +100,11 @@
 
 ## Static pods vs normal pods
 
-- The API only gives us a read-only access to static pods
+- The API only gives us read-only access to static pods
 
-- We can `kubectl delete` a static pod ...
+- We can `kubectl delete` a static pod...
 
-  ... But the kubelet will restart it immediately
+  ...But the kubelet will re-mirror it immediately
 
 - Static pods can be selected just like other pods
 

slides/k8s/versions-k8s.md

@@ -1,8 +1,8 @@
 ## Versions installed
 
-- Kubernetes 1.14.2
-- Docker Engine 18.09.6
-- Docker Compose 1.21.1
+- Kubernetes 1.15.0
+- Docker Engine 18.09.7
+- Docker Compose 1.24.1
 
 <!-- ##VERSION## -->
 
@@ -23,13 +23,13 @@ class: extra-details
 
 ## Kubernetes and Docker compatibility
 
-- Kubernetes 1.14 validates Docker Engine versions [up to 18.09](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.14.md#external-dependencies)
+- Kubernetes 1.15 validates Docker Engine versions [up to 18.09](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.15.md#dependencies)
   <br/>
   (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-1.13.md#external-dependencies)
 
-- Is this a problem if I use Kubernetes with a "too recent" Docker Engine?
+- Is it a problem if I use Kubernetes with a "too recent" Docker Engine?
 
 --
 

slides/k8s/volumes.md

@@ -28,11 +28,11 @@ class: extra-details
   <br/>
   but it refers to Docker 1.7, which was released in 2015!)
 
-- Docker volumes allow to share data between containers running on the same host
+- Docker volumes allow us to share data between containers running on the same host
 
 - Kubernetes volumes allow us to share data between containers in the same pod
 
-- Both Docker and Kubernetes volumes allow us access to storage systems
+- Both Docker and Kubernetes volumes enable access to storage systems
 
 - Kubernetes volumes are also used to expose configuration and secrets
 
@@ -60,7 +60,7 @@ class: extra-details
 
   - correspond to concrete volumes (e.g. on a SAN, EBS, etc.)
 
-  - cannot be associated to a Pod directly; but through a Persistent Volume Claim
+  - cannot be associated with a Pod directly; but through a Persistent Volume Claim
 
   - won't be discussed further in this section
 

slides/kadm-fullday.yml

@@ -0,0 +1,43 @@
+title: |
+  Kubernetes
+  for Admins and Ops
+
+#chat: "[Slack](https://dockercommunity.slack.com/messages/C7GKACWDV)"
+#chat: "[Gitter](https://gitter.im/jpetazzo/workshop-yyyymmdd-city)"
+chat: "In person!"
+
+gitrepo: github.com/jpetazzo/container.training
+
+slides: http://container.training/
+
+exclude:
+- self-paced
+- static-pods-exercise
+
+chapters:
+- shared/title.md
+- logistics.md
+- k8s/intro.md
+- shared/about-slides.md
+- shared/toc.md
+- - k8s/prereqs-admin.md
+  - k8s/architecture.md
+  - k8s/dmuc.md
+- - k8s/multinode.md
+  - k8s/cni.md
+  - k8s/apilb.md
+  - k8s/control-plane-auth.md
+- - k8s/setup-managed.md
+  - k8s/setup-selfhosted.md
+  - k8s/cluster-upgrade.md
+  - k8s/staticpods.md
+  - k8s/cluster-backup.md
+  - k8s/cloud-controller-manager.md
+  - k8s/bootstrap.md  
+- - k8s/resource-limits.md
+  - k8s/metrics-server.md
+  - k8s/cluster-sizing.md
+  - k8s/horizontal-pod-autoscaler.md
+- - k8s/lastwords-admin.md
+  - k8s/links.md
+  - shared/thankyou.md

slides/kadm-twodays.yml

@@ -0,0 +1,69 @@
+title: |
+  Kubernetes
+  for administrators
+  and operators
+
+#chat: "[Slack](https://dockercommunity.slack.com/messages/C7GKACWDV)"
+#chat: "[Gitter](https://gitter.im/jpetazzo/workshop-yyyymmdd-city)"
+chat: "In person!"
+
+gitrepo: github.com/jpetazzo/container.training
+
+slides: http://container.training/
+
+exclude:
+- self-paced
+
+chapters:
+- shared/title.md
+- logistics.md
+- k8s/intro.md
+- shared/about-slides.md
+- shared/toc.md
+# DAY 1
+- - k8s/prereqs-admin.md
+  - k8s/architecture.md
+  - k8s/deploymentslideshow.md
+  - k8s/dmuc.md
+- - k8s/multinode.md
+  - k8s/cni.md
+- - k8s/apilb.md
+  - k8s/setup-managed.md
+  - k8s/setup-selfhosted.md
+  - k8s/cluster-upgrade.md
+  - k8s/staticpods.md
+- - k8s/cluster-backup.md
+  - k8s/cloud-controller-manager.md
+  - k8s/healthchecks.md
+  - k8s/healthchecks-more.md
+# DAY 2
+- - k8s/kubercoins.md
+  - k8s/logs-cli.md
+  - k8s/logs-centralized.md
+  - k8s/authn-authz.md
+  - k8s/csr-api.md
+- - k8s/openid-connect.md
+  - k8s/control-plane-auth.md
+  ###- k8s/bootstrap.md
+  - k8s/netpol.md
+  - k8s/podsecuritypolicy.md
+- - k8s/resource-limits.md
+  - k8s/metrics-server.md
+  - k8s/cluster-sizing.md
+  - k8s/horizontal-pod-autoscaler.md
+- - k8s/prometheus.md
+  - k8s/extending-api.md
+  - k8s/operators.md
+  ###- k8s/operators-design.md
+# CONCLUSION
+- - k8s/lastwords-admin.md
+  - k8s/links.md
+  - shared/thankyou.md
+  - |
+    # (All content after this slide is bonus material)
+# EXTRA
+- - k8s/volumes.md
+  - k8s/configuration.md
+  - k8s/statefulsets.md
+  - k8s/local-persistent-volumes.md
+  - k8s/portworx.md

slides/kube-fullday.yml

@@ -48,30 +48,35 @@ chapters:
   - shared/hastyconclusions.md
   - k8s/daemonset.md
 - - k8s/rollout.md
+  #- k8s/record.md
   - k8s/namespaces.md
   #- k8s/kustomize.md
   #- k8s/helm.md
   #- k8s/create-chart.md
-  #- k8s/healthchecks.md
+#  - k8s/healthchecks.md
+#  - k8s/healthchecks-more.md
   - k8s/logs-cli.md
   - k8s/logs-centralized.md
   #- k8s/netpol.md
   #- k8s/authn-authz.md
   #- k8s/csr-api.md
+  #- k8s/openid-connect.md
   #- k8s/podsecuritypolicy.md
   #- k8s/ingress.md
   #- k8s/gitworkflows.md
   - k8s/prometheus.md
-  #- k8s/volumes.md
-  #- k8s/build-with-docker.md
-  #- k8s/build-with-kaniko.md
-  #- k8s/configuration.md
-  #- k8s/owners-and-dependents.md
-  #- k8s/extending-api.md
-  #- k8s/statefulsets.md
+#- - k8s/volumes.md
+#  - k8s/build-with-docker.md
+#  - k8s/build-with-kaniko.md
+#  - k8s/configuration.md
+#- - k8s/owners-and-dependents.md
+#  - k8s/extending-api.md
+#  - k8s/operators.md
+#  - k8s/operators-design.md
+#  - k8s/statefulsets.md
   #- k8s/local-persistent-volumes.md
-  #- k8s/portworx.md
   #- k8s/staticpods.md
+#  - k8s/portworx.md
 - - k8s/whatsnext.md
   - k8s/links.md
   - shared/thankyou.md

slides/kube-halfday.yml

@@ -0,0 +1,67 @@
+title: |
+  Kubernetes 101
+
+
+#chat: "[Slack](https://dockercommunity.slack.com/messages/C7GKACWDV)"
+#chat: "[Gitter](https://gitter.im/jpetazzo/training-20180413-paris)"
+chat: "In person!"
+
+gitrepo: github.com/jpetazzo/container.training
+
+slides: http://container.training/
+
+exclude:
+- self-paced
+
+chapters:
+- shared/title.md
+#- logistics.md
+# Bridget-specific; others use logistics.md
+- logistics-bridget.md
+- k8s/intro.md
+- shared/about-slides.md
+- shared/toc.md
+- - shared/prereqs.md
+  - shared/connecting.md
+  - k8s/versions-k8s.md
+  - shared/sampleapp.md
+# Bridget doesn't go into as much depth with compose
+  #- shared/composescale.md
+  #- shared/hastyconclusions.md
+  - shared/composedown.md
+  - k8s/concepts-k8s.md
+  - shared/declarative.md
+  - k8s/declarative.md
+  - k8s/kubenet.md
+  - k8s/kubectlget.md
+  - k8s/setup-k8s.md
+- - k8s/kubectlrun.md
+  - k8s/deploymentslideshow.md
+  - k8s/kubectlexpose.md
+  - k8s/shippingimages.md
+  #- k8s/buildshiprun-selfhosted.md
+  - k8s/buildshiprun-dockerhub.md
+  - k8s/ourapponkube.md
+  #- k8s/kubectlproxy.md
+  #- k8s/localkubeconfig.md
+  #- k8s/accessinternal.md
+- - k8s/dashboard.md
+  #- k8s/kubectlscale.md
+  - k8s/scalingdockercoins.md
+  - shared/hastyconclusions.md
+  - k8s/daemonset.md
+  - k8s/rollout.md
+  #- k8s/record.md
+- - k8s/logs-cli.md
+# Bridget hasn't added EFK yet
+  #- k8s/logs-centralized.md
+  - k8s/namespaces.md
+  - k8s/helm.md
+  - k8s/create-chart.md
+  #- k8s/kustomize.md
+  #- k8s/netpol.md
+  - k8s/whatsnext.md
+#  - k8s/links.md
+# Bridget-specific
+  - k8s/links-bridget.md
+  - shared/thankyou.md

slides/kube-selfpaced.yml

@@ -22,6 +22,7 @@ chapters:
 - - shared/prereqs.md
   - shared/connecting.md
   - k8s/versions-k8s.md
+  - assignments/setup.md
   - shared/sampleapp.md
   - shared/composescale.md
   - shared/hastyconclusions.md
@@ -48,16 +49,19 @@ chapters:
 #  - shared/hastyconclusions.md
   - k8s/daemonset.md
   - k8s/rollout.md
+  - k8s/record.md
   - k8s/namespaces.md
 - - k8s/kustomize.md
   - k8s/helm.md
   - k8s/create-chart.md
   - k8s/healthchecks.md
+  - k8s/healthchecks-more.md
   - k8s/logs-cli.md
   - k8s/logs-centralized.md
 - - k8s/netpol.md
   - k8s/authn-authz.md
   - k8s/csr-api.md
+  - k8s/openid-connect.md
   - k8s/podsecuritypolicy.md
 - - k8s/ingress.md
   - k8s/gitworkflows.md
@@ -68,6 +72,8 @@ chapters:
   - k8s/configuration.md
 - - k8s/owners-and-dependents.md
   - k8s/extending-api.md
+  - k8s/operators.md
+  - k8s/operators-design.md
 - - k8s/statefulsets.md
   - k8s/local-persistent-volumes.md
   - k8s/portworx.md

slides/kube-twodays.yml

@@ -47,17 +47,20 @@ chapters:
   - k8s/scalingdockercoins.md
   - shared/hastyconclusions.md
 - - k8s/daemonset.md
-  - k8s/rollout.md
+  - k8s/rollout.md 
+  - k8s/record.md
   - k8s/namespaces.md
   - k8s/kustomize.md
   #- k8s/helm.md
   #- k8s/create-chart.md
-- - k8s/healthchecks.md
+  - k8s/healthchecks.md
+  - k8s/healthchecks-more.md
   - k8s/logs-cli.md
   - k8s/logs-centralized.md
   #- k8s/netpol.md
   - k8s/authn-authz.md
   - k8s/csr-api.md
+  - k8s/openid-connect.md
   - k8s/podsecuritypolicy.md
 - - k8s/ingress.md
   #- k8s/gitworkflows.md
@@ -67,7 +70,9 @@ chapters:
   #- k8s/build-with-kaniko.md
   - k8s/configuration.md
   #- k8s/owners-and-dependents.md
-  #- k8s/extending-api.md
+  - k8s/extending-api.md
+  - k8s/operators.md
+  - k8s/operators-design.md
 - - k8s/statefulsets.md
   - k8s/local-persistent-volumes.md
   - k8s/portworx.md

slides/logistics.md

@@ -1,35 +1,35 @@
 ## Intros
 
+- This slide should be customized by the tutorial instructor(s).
+
 - Hello! We are:
 
+   - .emoji[👩🏻‍🏫] Ann O'Nymous ([@...](https://twitter.com/...), Megacorp Inc)
+
+   - .emoji[👨🏾‍🎓] Stu Dent ([@...](https://twitter.com/...), University of Wakanda)
+
+ <!-- .dummy[
+
    - .emoji[👷🏻‍♀️] AJ ([@s0ulshake](https://twitter.com/s0ulshake), Travis CI)
 
-   - .emoji[🐳] Jérôme ([@jpetazzo](https://twitter.com/jpetazzo), Tiny Shell Script LLC)
+   - .emoji[🚁] Alexandre ([@alexbuisine](https://twitter.com/alexbuisine), Enix SAS)
+
+   - .emoji[🐳] Jérôme ([@jpetazzo](https://twitter.com/jpetazzo), Enix SAS)
+
+   - .emoji[⛵] Jérémy ([@jeremygarrouste](twitter.com/jeremygarrouste), Inpiwee)
+
+   - .emoji[🎧] Romain ([@rdegez](https://twitter.com/rdegez), Enix SAS)
+
+] -->
+
+- The workshop will run from ...
+
+- There will be a lunch break at ...
+
+  (And coffee breaks!)
 
 - Feel free to interrupt for questions at any time
 
 - *Especially when you see full screen container pictures!*
 
 - Live feedback, questions, help: @@CHAT@@
-
-  (Let's make sure right now that we all are on that channel!)
-
----
-
-## Logistics
-
-Training schedule for the 3 days:
-
-|||
-|-------------------|--------------------|
-|  9:00am           | Start of training
-| 10:30am → 11:00am | Break
-| 12:30pm → 1:30pm  | Lunch
-| 3:00pm → 3:30pm   | Break
-| 5:00pm            | End of training
-
-- Lunch will be catered
-
-- During the breaks, the instructors will be available for Q&A
-
-- Make sure to hydrate / caffeinate / stretch out your limbs :)

slides/shared/connecting.md

@@ -14,7 +14,7 @@ done
 ```
 
 ```bash
-## FIXME find a way to reset the cluster, maybe?
+### FIXME find a way to reset the cluster, maybe?
 ```
 -->
 
@@ -84,14 +84,14 @@ You will need a Docker ID to use Play-With-Docker.
 
 - Unless instructed, **all commands must be run from the first VM, `node1`**
 
-- We will only checkout/copy the code on `node1`
+- We will only check out/copy the code on `node1`
 
 - During normal operations, we do not need access to the other nodes
 
 - If we had to troubleshoot issues, we would use a combination of:
 
   - SSH (to access system logs, daemon status...)
-  
+
   - Docker API (to check running containers and container engine status)
 
 ---

slides/shared/prereqs.md

@@ -90,7 +90,7 @@ class: in-person
 
 ## Why don't we run containers locally?
 
-- Installing that stuff can be hard on some machines
+- Installing this stuff can be hard on some machines
 
   (32 bits CPU or OS... Laptops without administrator access... etc.)
 

slides/shared/sampleapp.md

@@ -80,7 +80,7 @@ and displays aggregated logs.
 
 - DockerCoins is *not* a cryptocurrency
 
-  (the only common points are "randomness", "hashing", and "coins" in the name)
+  (the only common points are "randomness," "hashing," and "coins" in the name)
 
 ---
 
@@ -134,7 +134,7 @@ 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 FQDN in the code, either
+- We do not hard-code FQDNs in the code, either
 
 - We just connect to a service name, and container-magic does the rest
 
@@ -173,7 +173,7 @@ class: extra-details
 
 - Compose file version 2+ makes each container reachable through its service name
 
-- Compose file version 1 did require "links" sections
+- Compose file version 1 required "links" sections to accomplish this
 
 - Network aliases are automatically namespaced