fix-redirects.sh: adding forced redirect

New course: Kubernetes for Ops and Admins!

.gitignore

@@ -7,7 +7,6 @@ slides/*.yml.html
 slides/autopilot/state.yaml
 slides/index.html
 slides/past.html
-slides/slides.zip
 node_modules
 
 ### macOS ###

compose/frr-route-reflector/conf/bgpd.conf

@@ -0,0 +1,9 @@
+hostname frr
+router bgp 64512
+network 1.0.0.2/32
+bgp log-neighbor-changes
+neighbor kube peer-group
+neighbor kube remote-as 64512
+neighbor kube route-reflector-client
+bgp listen range 0.0.0.0/0 peer-group kube
+log stdout

compose/frr-route-reflector/conf/zebra.conf

@@ -0,0 +1,2 @@
+hostname frr
+log stdout

compose/frr-route-reflector/docker-compose.yaml

@@ -0,0 +1,34 @@
+version: "3"
+
+services:
+  bgpd:
+    image: ajones17/frr:662
+    volumes:
+    - ./conf:/etc/frr
+    - ./run:/var/run/frr
+    network_mode: host
+    entrypoint: /usr/lib/frr/bgpd -f /etc/frr/bgpd.conf --log=stdout --log-level=debug --no_kernel
+    restart: always
+
+  zebra:
+    image: ajones17/frr:662
+    volumes:
+    - ./conf:/etc/frr
+    - ./run:/var/run/frr
+    network_mode: host
+    entrypoint: /usr/lib/frr/zebra -f /etc/frr/zebra.conf --log=stdout --log-level=debug
+    restart: always
+
+  vtysh:
+    image: ajones17/frr:662
+    volumes:
+    - ./conf:/etc/frr
+    - ./run:/var/run/frr
+    network_mode: host
+    entrypoint: vtysh -c "show ip bgp"
+
+  chmod:
+    image: alpine
+    volumes:
+    - ./run:/var/run/frr
+    command: chmod 777 /var/run/frr

compose/kube-router-k8s-control-plane/docker-compose.yaml

@@ -0,0 +1,29 @@
+version: "3"
+
+services:
+
+  pause:
+    ports:
+    - 8080:8080
+    image: k8s.gcr.io/pause
+
+  etcd:
+    network_mode: "service:pause"
+    image: k8s.gcr.io/etcd:3.3.10
+    command: etcd
+
+  kube-apiserver:
+    network_mode: "service:pause"
+    image: k8s.gcr.io/hyperkube:v1.14.0
+    command: kube-apiserver --etcd-servers http://127.0.0.1:2379 --address 0.0.0.0 --disable-admission-plugins=ServiceAccount --allow-privileged
+
+  kube-controller-manager:
+    network_mode: "service:pause"
+    image: k8s.gcr.io/hyperkube:v1.14.0
+    command: kube-controller-manager --master http://localhost:8080 --allocate-node-cidrs --cluster-cidr=10.CLUSTER.0.0/16
+    "Edit the CLUSTER placeholder first. Then, remove this line.":
+    
+  kube-scheduler:
+    network_mode: "service:pause"
+    image: k8s.gcr.io/hyperkube:v1.14.0
+    command: kube-scheduler --master http://localhost:8080

compose/kube-router-k8s-control-plane/kuberouter.yaml

@@ -0,0 +1,128 @@
+---
+apiVersion: |+
+
+
+  Make sure you update the line with --master=http://X.X.X.X:8080 below.
+  Then remove this section from this YAML file and try again.
+
+---
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: kube-router-cfg
+  namespace: kube-system
+  labels:
+    tier: node
+    k8s-app: kube-router
+data:
+  cni-conf.json: |
+    {
+       "cniVersion":"0.3.0",
+       "name":"mynet",
+       "plugins":[
+          {
+             "name":"kubernetes",
+             "type":"bridge",
+             "bridge":"kube-bridge",
+             "isDefaultGateway":true,
+             "ipam":{
+                "type":"host-local"
+             }
+          }
+       ]
+    }
+---
+apiVersion: extensions/v1beta1
+kind: DaemonSet
+metadata:
+  labels:
+    k8s-app: kube-router
+    tier: node
+  name: kube-router
+  namespace: kube-system
+spec:
+  template:
+    metadata:
+      labels:
+        k8s-app: kube-router
+        tier: node
+      annotations:
+        scheduler.alpha.kubernetes.io/critical-pod: ''
+    spec:
+      serviceAccountName: kube-router
+      containers:
+      - name: kube-router
+        image: docker.io/cloudnativelabs/kube-router
+        imagePullPolicy: Always
+        args:
+        - "--run-router=true"
+        - "--run-firewall=true"
+        - "--run-service-proxy=true"
+        - "--master=http://X.X.X.X:8080"
+        env:
+        - name: NODE_NAME
+          valueFrom:
+            fieldRef:
+              fieldPath: spec.nodeName
+        - name: KUBE_ROUTER_CNI_CONF_FILE
+          value: /etc/cni/net.d/10-kuberouter.conflist
+        livenessProbe:
+          httpGet:
+            path: /healthz
+            port: 20244
+          initialDelaySeconds: 10
+          periodSeconds: 3
+        resources:
+          requests:
+            cpu: 250m
+            memory: 250Mi
+        securityContext:
+          privileged: true
+        volumeMounts:
+        - name: lib-modules
+          mountPath: /lib/modules
+          readOnly: true
+        - name: cni-conf-dir
+          mountPath: /etc/cni/net.d
+      initContainers:
+      - name: install-cni
+        image: busybox
+        imagePullPolicy: Always
+        command:
+        - /bin/sh
+        - -c
+        - set -e -x;
+          if [ ! -f /etc/cni/net.d/10-kuberouter.conflist ]; then
+            if [ -f /etc/cni/net.d/*.conf ]; then
+              rm -f /etc/cni/net.d/*.conf;
+            fi;
+            TMP=/etc/cni/net.d/.tmp-kuberouter-cfg;
+            cp /etc/kube-router/cni-conf.json ${TMP};
+            mv ${TMP} /etc/cni/net.d/10-kuberouter.conflist;
+          fi
+        volumeMounts:
+        - mountPath: /etc/cni/net.d
+          name: cni-conf-dir
+        - mountPath: /etc/kube-router
+          name: kube-router-cfg
+      hostNetwork: true
+      tolerations:
+      - key: CriticalAddonsOnly
+        operator: Exists
+      - effect: NoSchedule
+        key: node-role.kubernetes.io/master
+        operator: Exists
+      - effect: NoSchedule
+        key: node.kubernetes.io/not-ready
+        operator: Exists
+      volumes:
+      - name: lib-modules
+        hostPath:
+          path: /lib/modules
+      - name: cni-conf-dir
+        hostPath:
+          path: /etc/cni/net.d
+      - name: kube-router-cfg
+        configMap:
+          name: kube-router-cfg
+

compose/simple-k8s-control-plane/docker-compose.yaml

@@ -0,0 +1,28 @@
+version: "3"
+
+services:
+
+  pause:
+    ports:
+    - 8080:8080
+    image: k8s.gcr.io/pause
+
+  etcd:
+    network_mode: "service:pause"
+    image: k8s.gcr.io/etcd:3.3.10
+    command: etcd
+
+  kube-apiserver:
+    network_mode: "service:pause"
+    image: k8s.gcr.io/hyperkube:v1.14.0
+    command: kube-apiserver --etcd-servers http://127.0.0.1:2379 --address 0.0.0.0 --disable-admission-plugins=ServiceAccount
+
+  kube-controller-manager:
+    network_mode: "service:pause"
+    image: k8s.gcr.io/hyperkube:v1.14.0
+    command: kube-controller-manager --master http://localhost:8080
+    
+  kube-scheduler:
+    network_mode: "service:pause"
+    image: k8s.gcr.io/hyperkube:v1.14.0
+    command: kube-scheduler --master http://localhost:8080

k8s/consul.yaml

@@ -72,7 +72,7 @@ spec:
       terminationGracePeriodSeconds: 10
       containers:
         - name: consul
-          image: "consul:1.4.0"
+          image: "consul:1.4.4"
           args:
             - "agent"
             - "-bootstrap-expect=3"

k8s/efk.yaml

@@ -3,7 +3,6 @@ apiVersion: v1
 kind: ServiceAccount
 metadata:
   name: fluentd
-
 ---
 apiVersion: rbac.authorization.k8s.io/v1beta1
 kind: ClusterRole
@@ -19,7 +18,6 @@ rules:
   - get
   - list
   - watch
-
 ---
 kind: ClusterRoleBinding
 apiVersion: rbac.authorization.k8s.io/v1beta1
@@ -33,23 +31,18 @@ subjects:
 - kind: ServiceAccount
   name: fluentd
   namespace: default
-
 ---
 apiVersion: extensions/v1beta1
 kind: DaemonSet
 metadata:
   name: fluentd
   labels:
-    k8s-app: fluentd-logging
-    version: v1
-    kubernetes.io/cluster-service: "true"
+    app: fluentd
 spec:
   template:
     metadata:
       labels:
-        k8s-app: fluentd-logging
-        version: v1
-        kubernetes.io/cluster-service: "true"
+        app: fluentd
     spec:
       serviceAccount: fluentd
       serviceAccountName: fluentd
@@ -58,7 +51,7 @@ spec:
         effect: NoSchedule
       containers:
       - name: fluentd
-        image: fluent/fluentd-kubernetes-daemonset:elasticsearch
+        image: fluent/fluentd-kubernetes-daemonset:v1.3-debian-elasticsearch-1
         env:
           - name:  FLUENT_ELASTICSEARCH_HOST
             value: "elasticsearch"
@@ -66,14 +59,12 @@ spec:
             value: "9200"
           - name: FLUENT_ELASTICSEARCH_SCHEME
             value: "http"
-          # X-Pack Authentication
-          # =====================
-          - name: FLUENT_ELASTICSEARCH_USER
-            value: "elastic"
-          - name: FLUENT_ELASTICSEARCH_PASSWORD
-            value: "changeme"
           - name: FLUENT_UID
             value: "0"
+          - name: FLUENTD_SYSTEMD_CONF
+            value: "disable"
+          - name: FLUENTD_PROMETHEUS_CONF
+            value: "disable"
         resources:
           limits:
             memory: 200Mi
@@ -94,134 +85,83 @@ spec:
       - name: varlibdockercontainers
         hostPath:
           path: /var/lib/docker/containers
-
 ---
 apiVersion: extensions/v1beta1
 kind: Deployment
 metadata:
-  annotations:
-    deployment.kubernetes.io/revision: "1"
-  creationTimestamp: null
-  generation: 1
   labels:
-    run: elasticsearch
+    app: elasticsearch
   name: elasticsearch
-  selfLink: /apis/extensions/v1beta1/namespaces/default/deployments/elasticsearch
 spec:
-  progressDeadlineSeconds: 600
-  replicas: 1
-  revisionHistoryLimit: 10
   selector:
     matchLabels:
-      run: elasticsearch
-  strategy:
-    rollingUpdate:
-      maxSurge: 1
-      maxUnavailable: 1
-    type: RollingUpdate
+      app: elasticsearch
   template:
     metadata:
-      creationTimestamp: null
       labels:
-        run: elasticsearch
+        app: elasticsearch
     spec:
       containers:
-      - image: elasticsearch:5.6.8
-        imagePullPolicy: IfNotPresent
+      - image: elasticsearch:5
         name: elasticsearch
-        resources: {}
-        terminationMessagePath: /dev/termination-log
-        terminationMessagePolicy: File
+        resources:
+          limits:
+            memory: 2Gi
+          requests:
+            memory: 1Gi
         env:
         - name: ES_JAVA_OPTS
           value: "-Xms1g -Xmx1g"
-      dnsPolicy: ClusterFirst
-      restartPolicy: Always
-      schedulerName: default-scheduler
-      securityContext: {}
-      terminationGracePeriodSeconds: 30
-
 ---
 apiVersion: v1
 kind: Service
 metadata:
-  creationTimestamp: null
   labels:
-    run: elasticsearch
+    app: elasticsearch
   name: elasticsearch
-  selfLink: /api/v1/namespaces/default/services/elasticsearch
 spec:
   ports:
   - port: 9200
     protocol: TCP
     targetPort: 9200
   selector:
-    run: elasticsearch
-  sessionAffinity: None
+    app: elasticsearch
   type: ClusterIP
-
 ---
 apiVersion: extensions/v1beta1
 kind: Deployment
 metadata:
-  annotations:
-    deployment.kubernetes.io/revision: "1"
-  creationTimestamp: null
-  generation: 1
   labels:
-    run: kibana
+    app: kibana
   name: kibana
-  selfLink: /apis/extensions/v1beta1/namespaces/default/deployments/kibana
 spec:
-  progressDeadlineSeconds: 600
-  replicas: 1
-  revisionHistoryLimit: 10
   selector:
     matchLabels:
-      run: kibana
-  strategy:
-    rollingUpdate:
-      maxSurge: 1
-      maxUnavailable: 1
-    type: RollingUpdate
+      app: kibana
   template:
     metadata:
-      creationTimestamp: null
       labels:
-        run: kibana
+        app: kibana
     spec:
       containers:
       - env:
         - name: ELASTICSEARCH_URL
           value: http://elasticsearch:9200/
-        image: kibana:5.6.8
-        imagePullPolicy: Always
+        image: kibana:5
         name: kibana
         resources: {}
-        terminationMessagePath: /dev/termination-log
-        terminationMessagePolicy: File
-      dnsPolicy: ClusterFirst
-      restartPolicy: Always
-      schedulerName: default-scheduler
-      securityContext: {}
-      terminationGracePeriodSeconds: 30
-
 ---
 apiVersion: v1
 kind: Service
 metadata:
-  creationTimestamp: null
   labels:
-    run: kibana
+    app: kibana
   name: kibana
-  selfLink: /api/v1/namespaces/default/services/kibana
 spec:
-  externalTrafficPolicy: Cluster
   ports:
   - port: 5601
     protocol: TCP
     targetPort: 5601
   selector:
-    run: kibana
-  sessionAffinity: None
+    app: kibana
   type: NodePort

k8s/insecure-dashboard.yaml

@@ -0,0 +1,220 @@
+# Copyright 2017 The Kubernetes Authors.
+#
+# Licensed under the Apache License, Version 2.0 (the "License");
+# you may not use this file except in compliance with the License.
+# You may obtain a copy of the License at
+#
+#     http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS,
+# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+# See the License for the specific language governing permissions and
+# limitations under the License.
+
+# Configuration to deploy release version of the Dashboard UI compatible with
+# Kubernetes 1.8.
+#
+# Example usage: kubectl create -f <this_file>
+
+# ------------------- Dashboard Secret ------------------- #
+
+apiVersion: v1
+kind: Secret
+metadata:
+  labels:
+    k8s-app: kubernetes-dashboard
+  name: kubernetes-dashboard-certs
+  namespace: kube-system
+type: Opaque
+
+---
+# ------------------- Dashboard Service Account ------------------- #
+
+apiVersion: v1
+kind: ServiceAccount
+metadata:
+  labels:
+    k8s-app: kubernetes-dashboard
+  name: kubernetes-dashboard
+  namespace: kube-system
+
+---
+# ------------------- Dashboard Role & Role Binding ------------------- #
+
+kind: Role
+apiVersion: rbac.authorization.k8s.io/v1
+metadata:
+  name: kubernetes-dashboard-minimal
+  namespace: kube-system
+rules:
+  # Allow Dashboard to create 'kubernetes-dashboard-key-holder' secret.
+- apiGroups: [""]
+  resources: ["secrets"]
+  verbs: ["create"]
+  # Allow Dashboard to create 'kubernetes-dashboard-settings' config map.
+- apiGroups: [""]
+  resources: ["configmaps"]
+  verbs: ["create"]
+  # Allow Dashboard to get, update and delete Dashboard exclusive secrets.
+- apiGroups: [""]
+  resources: ["secrets"]
+  resourceNames: ["kubernetes-dashboard-key-holder", "kubernetes-dashboard-certs"]
+  verbs: ["get", "update", "delete"]
+  # Allow Dashboard to get and update 'kubernetes-dashboard-settings' config map.
+- apiGroups: [""]
+  resources: ["configmaps"]
+  resourceNames: ["kubernetes-dashboard-settings"]
+  verbs: ["get", "update"]
+  # Allow Dashboard to get metrics from heapster.
+- apiGroups: [""]
+  resources: ["services"]
+  resourceNames: ["heapster"]
+  verbs: ["proxy"]
+- apiGroups: [""]
+  resources: ["services/proxy"]
+  resourceNames: ["heapster", "http:heapster:", "https:heapster:"]
+  verbs: ["get"]
+
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: RoleBinding
+metadata:
+  name: kubernetes-dashboard-minimal
+  namespace: kube-system
+roleRef:
+  apiGroup: rbac.authorization.k8s.io
+  kind: Role
+  name: kubernetes-dashboard-minimal
+subjects:
+- kind: ServiceAccount
+  name: kubernetes-dashboard
+  namespace: kube-system
+
+---
+# ------------------- Dashboard Deployment ------------------- #
+
+kind: Deployment
+apiVersion: apps/v1beta2
+metadata:
+  labels:
+    k8s-app: kubernetes-dashboard
+  name: kubernetes-dashboard
+  namespace: kube-system
+spec:
+  replicas: 1
+  revisionHistoryLimit: 10
+  selector:
+    matchLabels:
+      k8s-app: kubernetes-dashboard
+  template:
+    metadata:
+      labels:
+        k8s-app: kubernetes-dashboard
+    spec:
+      containers:
+      - name: kubernetes-dashboard
+        image: k8s.gcr.io/kubernetes-dashboard-amd64:v1.8.3
+        ports:
+        - containerPort: 8443
+          protocol: TCP
+        args:
+          - --auto-generate-certificates
+          # Uncomment the following line to manually specify Kubernetes API server Host
+          # If not specified, Dashboard will attempt to auto discover the API server and connect
+          # to it. Uncomment only if the default does not work.
+          # - --apiserver-host=http://my-address:port
+        volumeMounts:
+        - name: kubernetes-dashboard-certs
+          mountPath: /certs
+          # Create on-disk volume to store exec logs
+        - mountPath: /tmp
+          name: tmp-volume
+        livenessProbe:
+          httpGet:
+            scheme: HTTPS
+            path: /
+            port: 8443
+          initialDelaySeconds: 30
+          timeoutSeconds: 30
+      volumes:
+      - name: kubernetes-dashboard-certs
+        secret:
+          secretName: kubernetes-dashboard-certs
+      - name: tmp-volume
+        emptyDir: {}
+      serviceAccountName: kubernetes-dashboard
+      # Comment the following tolerations if Dashboard must not be deployed on master
+      tolerations:
+      - key: node-role.kubernetes.io/master
+        effect: NoSchedule
+
+---
+# ------------------- Dashboard Service ------------------- #
+
+kind: Service
+apiVersion: v1
+metadata:
+  labels:
+    k8s-app: kubernetes-dashboard
+  name: kubernetes-dashboard
+  namespace: kube-system
+spec:
+  ports:
+    - port: 443
+      targetPort: 8443
+  selector:
+    k8s-app: kubernetes-dashboard
+---
+apiVersion: extensions/v1beta1
+kind: Deployment
+metadata:
+  labels:
+    app: dashboard
+  name: dashboard
+spec:
+  selector:
+    matchLabels:
+      app: dashboard
+  template:
+    metadata:
+      labels:
+        app: dashboard
+    spec:
+      containers:
+      - args:
+        - sh
+        - -c
+        - apk add --no-cache socat && socat TCP-LISTEN:80,fork,reuseaddr OPENSSL:kubernetes-dashboard.kube-system:443,verify=0
+        image: alpine
+        name: dashboard
+---
+apiVersion: v1
+kind: Service
+metadata:
+  labels:
+    app: dashboard
+  name: dashboard
+spec:
+  ports:
+  - port: 80
+    protocol: TCP
+    targetPort: 80
+  selector:
+    app: dashboard
+  type: NodePort
+---
+apiVersion: rbac.authorization.k8s.io/v1beta1
+kind: ClusterRoleBinding
+metadata:
+  name: kubernetes-dashboard
+  labels:
+    k8s-app: kubernetes-dashboard
+roleRef:
+  apiGroup: rbac.authorization.k8s.io
+  kind: ClusterRole
+  name: cluster-admin
+subjects:
+- kind: ServiceAccount
+  name: kubernetes-dashboard
+  namespace: kube-system

k8s/metrics-server.yaml

@@ -0,0 +1,138 @@
+kind: ClusterRole
+apiVersion: rbac.authorization.k8s.io/v1
+metadata:
+  name: system:aggregated-metrics-reader
+  labels:
+    rbac.authorization.k8s.io/aggregate-to-view: "true"
+    rbac.authorization.k8s.io/aggregate-to-edit: "true"
+    rbac.authorization.k8s.io/aggregate-to-admin: "true"
+rules:
+- apiGroups: ["metrics.k8s.io"]
+  resources: ["pods"]
+  verbs: ["get", "list", "watch"]
+---
+apiVersion: rbac.authorization.k8s.io/v1beta1
+kind: ClusterRoleBinding
+metadata:
+  name: metrics-server:system:auth-delegator
+roleRef:
+  apiGroup: rbac.authorization.k8s.io
+  kind: ClusterRole
+  name: system:auth-delegator
+subjects:
+- kind: ServiceAccount
+  name: metrics-server
+  namespace: kube-system
+---
+apiVersion: rbac.authorization.k8s.io/v1beta1
+kind: RoleBinding
+metadata:
+  name: metrics-server-auth-reader
+  namespace: kube-system
+roleRef:
+  apiGroup: rbac.authorization.k8s.io
+  kind: Role
+  name: extension-apiserver-authentication-reader
+subjects:
+- kind: ServiceAccount
+  name: metrics-server
+  namespace: kube-system
+---
+apiVersion: apiregistration.k8s.io/v1beta1
+kind: APIService
+metadata:
+  name: v1beta1.metrics.k8s.io
+spec:
+  service:
+    name: metrics-server
+    namespace: kube-system
+  group: metrics.k8s.io
+  version: v1beta1
+  insecureSkipTLSVerify: true
+  groupPriorityMinimum: 100
+  versionPriority: 100
+---
+apiVersion: v1
+kind: ServiceAccount
+metadata:
+  name: metrics-server
+  namespace: kube-system
+---
+apiVersion: extensions/v1beta1
+kind: Deployment
+metadata:
+  name: metrics-server
+  namespace: kube-system
+  labels:
+    k8s-app: metrics-server
+spec:
+  selector:
+    matchLabels:
+      k8s-app: metrics-server
+  template:
+    metadata:
+      name: metrics-server
+      labels:
+        k8s-app: metrics-server
+    spec:
+      serviceAccountName: metrics-server
+      volumes:
+      # mount in tmp so we can safely use from-scratch images and/or read-only containers
+      - name: tmp-dir
+        emptyDir: {}
+      containers:
+      - name: metrics-server
+        image: k8s.gcr.io/metrics-server-amd64:v0.3.1
+        imagePullPolicy: Always
+        volumeMounts:
+        - name: tmp-dir
+          mountPath: /tmp
+        args:
+        - --kubelet-preferred-address-types=InternalIP
+        - --kubelet-insecure-tls
+        - --metric-resolution=5s
+
+---
+apiVersion: v1
+kind: Service
+metadata:
+  name: metrics-server
+  namespace: kube-system
+  labels:
+    kubernetes.io/name: "Metrics-server"
+spec:
+  selector:
+    k8s-app: metrics-server
+  ports:
+  - port: 443
+    protocol: TCP
+    targetPort: 443
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRole
+metadata:
+  name: system:metrics-server
+rules:
+- apiGroups:
+  - ""
+  resources:
+  - pods
+  - nodes
+  - nodes/stats
+  verbs:
+  - get
+  - list
+  - watch
+---
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRoleBinding
+metadata:
+  name: system:metrics-server
+roleRef:
+  apiGroup: rbac.authorization.k8s.io
+  kind: ClusterRole
+  name: system:metrics-server
+subjects:
+- kind: ServiceAccount
+  name: metrics-server
+  namespace: kube-system

prepare-vms/lib/commands.sh

@@ -2,7 +2,7 @@ export AWS_DEFAULT_OUTPUT=text
 
 HELP=""
 _cmd() {
-    HELP="$(printf "%s\n%-12s %s\n" "$HELP" "$1" "$2")"
+    HELP="$(printf "%s\n%-20s %s\n" "$HELP" "$1" "$2")"
 }
 
 _cmd help "Show available commands"
@@ -74,10 +74,10 @@ _cmd_deploy() {
     pssh -I sudo tee /usr/local/bin/docker-prompt <lib/docker-prompt
     pssh sudo chmod +x /usr/local/bin/docker-prompt
 
-    # If /home/docker/.ssh/id_rsa doesn't exist, copy it from node1
+    # If /home/docker/.ssh/id_rsa doesn't exist, copy it from the first node
     pssh "
     sudo -u docker [ -f /home/docker/.ssh/id_rsa ] ||
-    ssh -o StrictHostKeyChecking=no node1 sudo -u docker tar -C /home/docker -cvf- .ssh |
+    ssh -o StrictHostKeyChecking=no \$(cat /etc/name_of_first_node) sudo -u docker tar -C /home/docker -cvf- .ssh |
     sudo -u docker tar -C /home/docker -xf-"
 
     # if 'docker@' doesn't appear in /home/docker/.ssh/authorized_keys, copy it there
@@ -86,11 +86,11 @@ _cmd_deploy() {
     cat /home/docker/.ssh/id_rsa.pub |
     sudo -u docker tee -a /home/docker/.ssh/authorized_keys"
 
-    # On node1, create and deploy TLS certs using Docker Machine
+    # On the first node, create and deploy TLS certs using Docker Machine
     # (Currently disabled.)
     true || pssh "
-    if grep -q node1 /tmp/node; then
-        grep ' node' /etc/hosts | 
+    if i_am_first_node; then
+        grep '[0-9]\$' /etc/hosts |
         xargs -n2 sudo -H -u docker \
         docker-machine create -d generic --generic-ssh-user docker --generic-ip-address
     fi"
@@ -103,11 +103,62 @@ _cmd_deploy() {
     info "$0 cards $TAG"
 }
 
+_cmd disabledocker "Stop Docker Engine and don't restart it automatically"
+_cmd_disabledocker() {
+    TAG=$1
+    need_tag
+
+    pssh "sudo systemctl disable docker.service"
+    pssh "sudo systemctl disable docker.socket"
+    pssh "sudo systemctl stop docker"
+}
+
+_cmd kubebins "Install Kubernetes and CNI binaries but don't start anything"
+_cmd_kubebins() {
+    TAG=$1
+    need_tag
+
+    pssh --timeout 300 "
+    set -e
+    cd /usr/local/bin
+    if ! [ -x etcd ]; then
+        curl -L https://github.com/etcd-io/etcd/releases/download/v3.3.10/etcd-v3.3.10-linux-amd64.tar.gz \
+        | sudo tar --strip-components=1 --wildcards -zx '*/etcd' '*/etcdctl'
+    fi
+    if ! [ -x hyperkube ]; then
+        curl -L https://dl.k8s.io/v1.14.1/kubernetes-server-linux-amd64.tar.gz \
+        | sudo tar --strip-components=3 -zx kubernetes/server/bin/hyperkube
+    fi
+    if ! [ -x kubelet ]; then
+        for BINARY in kubectl kube-apiserver kube-scheduler kube-controller-manager kubelet kube-proxy;
+        do
+            sudo ln -s hyperkube \$BINARY
+        done
+    fi
+    sudo mkdir -p /opt/cni/bin
+    cd /opt/cni/bin
+    if ! [ -x bridge ]; then
+        curl -L https://github.com/containernetworking/plugins/releases/download/v0.7.5/cni-plugins-amd64-v0.7.5.tgz \
+        | sudo tar -zx
+    fi
+    "
+}
+
 _cmd kube "Setup kubernetes clusters with kubeadm (must be run AFTER deploy)"
 _cmd_kube() {
     TAG=$1
     need_tag
 
+    # Optional version, e.g. 1.13.5
+    KUBEVERSION=$2
+    if [ "$KUBEVERSION" ]; then
+        EXTRA_KUBELET="=$KUBEVERSION-00"
+        EXTRA_KUBEADM="--kubernetes-version=v$KUBEVERSION"
+    else
+        EXTRA_KUBELET=""
+        EXTRA_KUBEADM=""
+    fi
+
     # Install packages
     pssh --timeout 200 "
     curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg |
@@ -116,19 +167,19 @@ _cmd_kube() {
     sudo tee /etc/apt/sources.list.d/kubernetes.list"
     pssh --timeout 200 "
     sudo apt-get update -q &&
-    sudo apt-get install -qy kubelet kubeadm kubectl &&
+    sudo apt-get install -qy kubelet$EXTRA_KUBELET kubeadm kubectl &&
     kubectl completion bash | sudo tee /etc/bash_completion.d/kubectl"
 
     # Initialize kube master
     pssh --timeout 200 "
-    if grep -q node1 /tmp/node && [ ! -f /etc/kubernetes/admin.conf ]; then
+    if i_am_first_node && [ ! -f /etc/kubernetes/admin.conf ]; then
         kubeadm token generate > /tmp/token &&
-	sudo kubeadm init --token \$(cat /tmp/token)
+	sudo kubeadm init $EXTRA_KUBEADM --token \$(cat /tmp/token) --apiserver-cert-extra-sans \$(cat /tmp/ipv4)
     fi"
 
     # Put kubeconfig in ubuntu's and docker's accounts
     pssh "
-    if grep -q node1 /tmp/node; then
+    if i_am_first_node; then
         sudo mkdir -p \$HOME/.kube /home/docker/.kube &&
         sudo cp /etc/kubernetes/admin.conf \$HOME/.kube/config &&
         sudo cp /etc/kubernetes/admin.conf /home/docker/.kube/config &&
@@ -138,16 +189,23 @@ _cmd_kube() {
 
     # Install weave as the pod network
     pssh "
-    if grep -q node1 /tmp/node; then
+    if i_am_first_node; then
         kubever=\$(kubectl version | base64 | tr -d '\n') &&
         kubectl apply -f https://cloud.weave.works/k8s/net?k8s-version=\$kubever
     fi"
 
     # Join the other nodes to the cluster
     pssh --timeout 200 "
-    if ! grep -q node1 /tmp/node && [ ! -f /etc/kubernetes/kubelet.conf ]; then
-        TOKEN=\$(ssh -o StrictHostKeyChecking=no node1 cat /tmp/token) &&
-        sudo kubeadm join --discovery-token-unsafe-skip-ca-verification --token \$TOKEN node1:6443
+    if ! i_am_first_node && [ ! -f /etc/kubernetes/kubelet.conf ]; then
+        FIRSTNODE=\$(cat /etc/name_of_first_node) &&
+        TOKEN=\$(ssh -o StrictHostKeyChecking=no \$FIRSTNODE cat /tmp/token) &&
+        sudo kubeadm join --discovery-token-unsafe-skip-ca-verification --token \$TOKEN \$FIRSTNODE:6443
+    fi"
+
+    # Install metrics server
+    pssh "
+    if i_am_first_node; then
+	kubectl apply -f https://raw.githubusercontent.com/jpetazzo/container.training/master/k8s/metrics-server.yaml
     fi"
 
     # Install kubectx and kubens
@@ -183,6 +241,13 @@ EOF"
         helm completion bash | sudo tee /etc/bash_completion.d/helm
     fi"
 
+    # Install ship
+    pssh "
+    if [ ! -x /usr/local/bin/ship ]; then
+        curl -L https://github.com/replicatedhq/ship/releases/download/v0.40.0/ship_0.40.0_linux_amd64.tar.gz |
+             sudo tar -C /usr/local/bin -zx ship
+    fi"
+
     sep "Done"
 }
 
@@ -203,10 +268,9 @@ _cmd_kubetest() {
     # Feel free to make that better ♥
     pssh "
     set -e
-    [ -f /tmp/node ]
-    if grep -q node1 /tmp/node; then
+    if i_am_first_node; then
       which kubectl
-      for NODE in \$(awk /\ node/\ {print\ \\\$2} /etc/hosts); do
+      for NODE in \$(awk /[0-9]\$/\ {print\ \\\$2} /etc/hosts); do
         echo \$NODE ; kubectl get nodes | grep -w \$NODE | grep -w Ready
       done
     fi"
@@ -277,6 +341,14 @@ _cmd_opensg() {
     infra_opensg
 }
 
+_cmd disableaddrchecks "Disable source/destination IP address checks"
+_cmd_disableaddrchecks() {
+    TAG=$1
+    need_tag
+
+    infra_disableaddrchecks
+}
+
 _cmd pssh "Run an arbitrary command on all nodes"
 _cmd_pssh() {
     TAG=$1
@@ -322,7 +394,7 @@ _cmd_start() {
         *) die "Unrecognized parameter: $1."
         esac
     done
-    
+
     if [ -z "$INFRA" ]; then
         die "Please add --infra flag to specify which infrastructure file to use."
     fi
@@ -333,8 +405,8 @@ _cmd_start() {
         COUNT=$(awk '/^clustersize:/ {print $2}' $SETTINGS)
         warning "No --count option was specified. Using value from settings file ($COUNT)."
     fi
-    
-    # Check that the specified settings and infrastructure are valid.        
+
+    # Check that the specified settings and infrastructure are valid.
     need_settings $SETTINGS
     need_infra $INFRA
 
@@ -406,7 +478,7 @@ _cmd_helmprom() {
     TAG=$1
     need_tag
     pssh "
-    if grep -q node1 /tmp/node; then
+    if i_am_first_node; then
         kubectl -n kube-system get serviceaccount helm ||
             kubectl -n kube-system create serviceaccount helm
         helm init --service-account helm
@@ -496,8 +568,8 @@ test_vm() {
     for cmd in "hostname" \
         "whoami" \
         "hostname -i" \
-        "cat /tmp/node" \
-        "cat /tmp/ipv4" \
+        "ls -l /usr/local/bin/i_am_first_node" \
+        "grep . /etc/name_of_first_node /etc/ipv4_of_first_node" \
         "cat /etc/hosts" \
         "hostnamectl status" \
         "docker version | grep Version -B1" \

prepare-vms/lib/infra.sh

@@ -24,3 +24,7 @@ infra_quotas() {
 infra_opensg() {
 	warning "infra_opensg is unsupported on $INFRACLASS."
 }
+
+infra_disableaddrchecks() {
+	warning "infra_disableaddrchecks is unsupported on $INFRACLASS."
+}

prepare-vms/lib/infra/aws.sh

@@ -88,6 +88,14 @@ infra_opensg() {
         --cidr 0.0.0.0/0
 }
 
+infra_disableaddrchecks() {
+    IDS=$(aws_get_instance_ids_by_tag $TAG)
+    for ID in $IDS; do
+        info "Disabling source/destination IP checks on: $ID"
+        aws ec2 modify-instance-attribute --source-dest-check "{\"Value\": false}" --instance-id $ID
+    done
+}
+
 wait_until_tag_is_running() {
     max_retry=50
     i=0

prepare-vms/lib/postprep.py

@@ -12,6 +12,7 @@ config = yaml.load(open("/tmp/settings.yaml"))
 COMPOSE_VERSION = config["compose_version"]
 MACHINE_VERSION = config["machine_version"]
 CLUSTER_SIZE = config["clustersize"]
+CLUSTER_PREFIX = config["clusterprefix"]
 ENGINE_VERSION = config["engine_version"]
 DOCKER_USER_PASSWORD = config["docker_user_password"]
 
@@ -121,7 +122,7 @@ addresses = list(l.strip() for l in sys.stdin)
 assert ipv4 in addresses
 
 def makenames(addrs):
-    return [ "node%s"%(i+1) for i in range(len(addrs)) ]
+    return [ "%s%s"%(CLUSTER_PREFIX, i+1) for i in range(len(addrs)) ]
 
 while addresses:
     cluster = addresses[:CLUSTER_SIZE]
@@ -135,15 +136,21 @@ while addresses:
     print(cluster)
 
     mynode = cluster.index(ipv4) + 1
-    system("echo node{} | sudo -u docker tee /tmp/node".format(mynode))
-    system("echo node{} | sudo tee /etc/hostname".format(mynode))
-    system("sudo hostname node{}".format(mynode))
+    system("echo {}{} | sudo tee /etc/hostname".format(CLUSTER_PREFIX, mynode))
+    system("sudo hostname {}{}".format(CLUSTER_PREFIX, mynode))
     system("sudo -u docker mkdir -p /home/docker/.ssh")
     system("sudo -u docker touch /home/docker/.ssh/authorized_keys")
 
+    # Create a convenience file to easily check if we're the first node
     if ipv4 == cluster[0]:
-        # If I'm node1 and don't have a private key, generate one (with empty passphrase)
+        system("sudo ln -sf /bin/true /usr/local/bin/i_am_first_node")
+        # On the first node, if we don't have a private key, generate one (with empty passphrase)
         system("sudo -u docker [ -f /home/docker/.ssh/id_rsa ] || sudo -u docker ssh-keygen -t rsa -f /home/docker/.ssh/id_rsa -P ''")
+    else:
+        system("sudo ln -sf /bin/false /usr/local/bin/i_am_first_node")
+    # Record the IPV4 and name of the first node
+    system("echo {} | sudo tee /etc/ipv4_of_first_node".format(cluster[0]))
+    system("echo {} | sudo tee /etc/name_of_first_node".format(names[0]))
 
 FINISH = time.time()
 duration = "Initial deployment took {}s".format(str(FINISH - START)[:5])

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: admin.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.21.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: admin.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.21.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: admin.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.21.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: admin.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.21.1
+machine_version: 0.14.0
+
+# Password used to connect with the "docker user"
+docker_user_password: training

prepare-vms/settings/csv.yaml

@@ -1,5 +1,8 @@
 # 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: clusters.csv

prepare-vms/settings/enix.yaml

@@ -1,6 +1,9 @@
 # Number of VMs per cluster
 clustersize: 1
 
+# The hostname of each node will be clusterprefix + a number
+clusterprefix: node
+
 # Jinja2 template to use to generate ready-to-cut cards
 cards_template: enix.html
 

prepare-vms/settings/example.yaml

@@ -3,6 +3,9 @@
 # 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
 

prepare-vms/settings/fundamentals.yaml

@@ -3,6 +3,9 @@
 # Number of VMs per cluster
 clustersize: 1
 
+# 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
 

prepare-vms/settings/jerome.yaml

@@ -1,11 +1,14 @@
 # Number of VMs per cluster
 clustersize: 4
 
+# The hostname of each node will be clusterprefix + a number
+clusterprefix: node
+
 # Jinja2 template to use to generate ready-to-cut cards
 cards_template: jerome.html
 
 # Use "Letter" in the US, and "A4" everywhere else
-paper_size: A4
+paper_size: Letter
 
 # Feel free to reduce this if your printer can handle it
 paper_margin: 0.2in

prepare-vms/settings/kube101.yaml

@@ -3,6 +3,9 @@
 # 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: kube101.html
 

prepare-vms/settings/swarm.yaml

@@ -3,6 +3,9 @@
 # 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
 

prepare-vms/setup-admin-clusters.sh

@@ -0,0 +1,53 @@
+#!/bin/sh
+set -e
+
+INFRA=infra/aws-eu-west-3
+
+STUDENTS=2
+
+TAG=admin-dmuc
+./workshopctl start \
+	--tag $TAG \
+	--infra $INFRA \
+	--settings settings/$TAG.yaml \
+	--count $STUDENTS
+
+./workshopctl deploy $TAG
+./workshopctl disabledocker $TAG
+./workshopctl kubebins $TAG
+./workshopctl cards $TAG
+
+TAG=admin-kubenet
+./workshopctl start \
+	--tag $TAG \
+	--infra $INFRA \
+	--settings settings/$TAG.yaml \
+	--count $((3*$STUDENTS))
+
+./workshopctl deploy $TAG
+./workshopctl kubebins $TAG
+./workshopctl disableaddrchecks $TAG
+./workshopctl cards $TAG
+
+TAG=admin-kuberouter
+./workshopctl start \
+	--tag $TAG \
+	--infra $INFRA \
+	--settings settings/$TAG.yaml \
+	--count $((3*$STUDENTS))
+
+./workshopctl deploy $TAG
+./workshopctl kubebins $TAG
+./workshopctl disableaddrchecks $TAG
+./workshopctl cards $TAG
+
+TAG=admin-test
+./workshopctl start \
+	--tag $TAG \
+	--infra $INFRA \
+	--settings settings/$TAG.yaml \
+	--count $((3*$STUDENTS))
+
+./workshopctl deploy $TAG
+./workshopctl kube $TAG 1.13.5
+./workshopctl cards $TAG

prepare-vms/templates/admin.html

@@ -0,0 +1,124 @@
+{# Feel free to customize or override anything in there! #}
+{%- set url = "http://FIXME.container.training" -%}
+{%- set pagesize = 9 -%}
+{%- if clustersize == 1 -%}
+    {%- set workshop_name = "Docker workshop" -%}
+    {%- set cluster_or_machine = "machine virtuelle" -%}
+    {%- set this_or_each = "cette" -%}
+    {%- set plural = "" -%}
+    {%- set image_src = "https://s3-us-west-2.amazonaws.com/www.breadware.com/integrations/docker.png" -%}
+{%- else -%}
+    {%- set workshop_name = "Kubernetes workshop" -%}
+    {%- set cluster_or_machine = "cluster" -%}
+    {%- set this_or_each = "chaque" -%}
+    {%- set plural = "s" -%}
+    {%- 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: 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;
+    padding-top: 1%;
+    padding-bottom: 1%;
+    /* columns * (width+left+right) < 100% */
+    width: 30%;
+    padding-left: 1.5%;
+    padding-right: 1.5%;
+}
+
+p {
+    margin: 0.4em 0 0.4em 0;
+}
+
+img {
+    height: 4em;
+    float: right;
+    margin-right: -0.3em;
+}
+
+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 %}
+    {% if loop.index0>0 and loop.index0%pagesize==0 %}
+        <span class="pagebreak"></span>
+    {% endif %}
+    <div>
+
+        <p>
+        Voici les informations permettant de se connecter à un
+        des environnements utilisés pour cette formation.
+        Vous pouvez vous connecter à {{ this_or_each }} machine
+        virtuelle avec n'importe quel client SSH.
+        </p>
+
+        <p>
+        <img class="enix" src="https://enix.io/static/img/logos/logo-domain-cropped.png" />
+        <table>
+            <tr><td>cluster:</td></tr>
+            <tr><td class="logpass">{{ clusterprefix }}</td></tr>
+            <tr><td>identifiant:</td></tr>
+            <tr><td class="logpass">docker</td></tr>
+            <tr><td>mot de passe:</td></tr>
+            <tr><td class="logpass">{{ docker_user_password }}</td></tr>
+        </table>
+        </p>
+
+        <p>
+       Adresse{{ plural }} IP :
+        <!--<img class="kube" src="{{ image_src }}" />-->
+        <table>
+            {% for node in cluster %}
+            <tr><td>{{ clusterprefix }}{{ loop.index }}:</td><td>{{ node }}</td></tr>
+            {% endfor %}
+        </table>
+        </p>
+        <p>Le support de formation est à l'adresse suivante :
+            <center>{{ url }}</center>
+        </p>
+    </div>
+{% endfor %}
+</body>
+</html>

slides/Dockerfile

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

slides/_redirects

@@ -1 +1,4 @@
+# Uncomment and/or edit one of the the following lines if necessary.
+#/ /kube-halfday.yml.html 200
 / /kube-fullday.yml.html 200!
+#/ /kube-twodays.yml.html 200

slides/build.sh

@@ -14,7 +14,6 @@ once)
       ./appendcheck.py $YAML.html
     done
   fi
-  zip -qr slides.zip . && echo "Created slides.zip archive."
   ;;
 
 forever)

slides/containers/Ambassadors.md

@@ -204,4 +204,4 @@ Some services meshes and related projects:
 
 * [Linkerd](https://linkerd.io/)
 
-* [Gloo](https://gloo.solo.io/)
+* [Gloo](https://gloo.solo.io/)

slides/containers/Installing_Docker.md

@@ -38,11 +38,7 @@ We can arbitrarily distinguish:
 
 ## Installing Docker on Linux
 
-* The recommended method is to install the packages supplied by Docker Inc.:
-
-  https://store.docker.com
-
-* The general method is:
+* The recommended method is to install the packages supplied by Docker Inc :
 
   - add Docker Inc.'s package repositories to your system configuration
 
@@ -56,6 +52,12 @@ We can arbitrarily distinguish:
 
   https://docs.docker.com/engine/installation/linux/docker-ce/binaries/
 
+* To quickly setup a dev environment, Docker provides a convenience install script:
+
+  ```bash
+  curl -fsSL get.docker.com | sh
+  ```
+
 ---
 
 class: extra-details

slides/containers/Orchestration_Overview.md

@@ -249,7 +249,7 @@ class: pic
 
 .center[![Not-so-good bin packing](images/binpacking-1d-1.gif)]
 
-## Can we do better?
+## We can't fit a job of size 6 :(
 
 ---
 
@@ -259,7 +259,7 @@ class: pic
 
 .center[![Better bin packing](images/binpacking-1d-2.gif)]
 
-## Yup!
+## ... Now we can!
 
 ---
 

slides/index.py

@@ -1,4 +1,4 @@
-#!/usr/bin/env python3
+#!/usr/bin/env python2
 # coding: utf-8
 TEMPLATE="""<html>
 <head>
@@ -12,6 +12,23 @@ TEMPLATE="""<html>
       <tr><td class="header" colspan="3">{{ title }}</td></tr>
       <tr><td class="details" colspan="3">Note: while some workshops are delivered in French, slides are always in English.</td></tr>
 
+      <tr><td class="title" colspan="3">Free video of our latest workshop</td></tr>
+
+      <tr>
+      	<td>Getting Started With Kubernetes and Container Orchestration</td>
+      	<td><a class="slides" href="https://qconuk2019.container.training" /></td>
+      	<td><a class="video" href="https://www.youtube.com/playlist?list=PLBAFXs0YjviJwCoxSUkUPhsSxDJzpZbJd" /></td>
+      </tr>
+      <tr>
+        <td class="details">This is a live recording of a 1-day workshop that took place at QCON London in March 2019.</td>
+      </tr>
+      <tr>
+        <td class="details">If you're interested, we can deliver that workshop (or longer courses) to your team or organization.</td>
+      </tr>
+      <tr>
+        <td class="details">Contact <a href="mailto:jerome.petazzoni@gmail.com">Jérôme Petazzoni</a> to make that happen!</a></td>
+      </tr>
+
       {% if coming_soon %}
         <tr><td class="title" colspan="3">Coming soon near you</td></tr>
 
@@ -106,13 +123,13 @@ TEMPLATE="""<html>
     </table>
   </div>
 </body>
-</html>"""
+</html>""".decode("utf-8")
 
 import datetime
 import jinja2
 import yaml
 
-items = yaml.safe_load(open("index.yaml"))
+items = yaml.load(open("index.yaml"))
 
 # Items with a date correspond to scheduled sessions.
 # Items without a date correspond to self-paced content.
@@ -160,10 +177,10 @@ with open("index.html", "w") as f:
     	past_workshops=past_workshops,
     	self_paced=self_paced,
     	recorded_workshops=recorded_workshops
-    	))
+    	).encode("utf-8"))
 
 with open("past.html", "w") as f:
 	f.write(template.render(
 		title="Container Training",
 		all_past_workshops=past_workshops
-		))
+		).encode("utf-8"))

slides/index.yaml

@@ -1,21 +1,3 @@
-- date: 2019-06-18
-  country: ca
-  city: Montréal
-  event: Elapse Technologies
-  title: Getting Started With Kubernetes And Orchestration
-  speaker: jpetazzo
-  status: coming soon
-  hidden: http://elapsetech.com/formation/kubernetes-101
-
-- date: 2019-06-17
-  country: ca
-  city: Montréal
-  event: Elapse Technologies
-  title: Getting Started With Docker And Containers
-  speaker: jpetazzo
-  status: coming soon
-  hidden: http://elapsetech.com/formation/docker-101
-
 - date: 2019-05-01
   country: us
   city: Cleveland, OH
@@ -31,15 +13,25 @@
   speaker: jpetazzo
   title: Getting Started With Kubernetes and Container Orchestration
   attend: https://gotochgo.com/2019/workshops/148
+  slides: https://gotochgo2019.container.training/
+
+- date: 2019-04-26
+  country: fr
+  city: Paris
+  event: ENIX SAS
+  speaker: jpetazzo
+  title: Opérer et administrer Kubernetes
+  attend: https://enix.io/fr/services/formation/operer-et-administrer-kubernetes/
 
 - date: [2019-04-23, 2019-04-24]
   country: fr
   city: Paris
   event: ENIX SAS
-  speaker: "jpetazzo, rdegez"
+  speaker: jpetazzo
   title: Déployer ses applications avec Kubernetes (in French)
   lang: fr
   attend: https://enix.io/fr/services/formation/deployer-ses-applications-avec-kubernetes/
+  slides: https://kube-2019-04.container.training
 
 - date: [2019-04-15, 2019-04-16]
   country: fr
@@ -49,6 +41,7 @@
   title: Bien démarrer avec les conteneurs (in French)
   lang: fr
   attend: https://enix.io/fr/services/formation/bien-demarrer-avec-les-conteneurs/
+  slides: http://intro-2019-04.container.training/
 
 - date: 2019-03-08
   country: uk
@@ -58,40 +51,7 @@
   title: Getting Started With Kubernetes and Container Orchestration
   attend: https://qconlondon.com/london2019/workshop/getting-started-kubernetes-and-container-orchestration
   slides: https://qconuk2019.container.training/
-
-- date: 2019-02-25
-  country: ca
-  city: Montréal
-  event: Elapse Technologies
-  speaker: jpetazzo
-  title: <strike>Getting Started With Docker And Containers</strike> (rescheduled for June 2019)
-  status: rescheduled
-
-- date: 2019-02-26
-  country: ca
-  city: Montréal
-  event: Elapse Technologies
-  speaker: jpetazzo
-  title: <strike>Getting Started With Kubernetes And Orchestration</strike> (rescheduled for June 2019)
-  status: rescheduled
-
-- date: 2019-02-28
-  country: ca
-  city: Québec
-  lang: fr
-  event: Elapse Technologies
-  speaker: jpetazzo
-  title: <strike>Bien démarrer avec Docker et les conteneurs (in French)</strike>
-  status: cancelled
-
-- date: 2019-03-01
-  country: ca
-  city: Québec
-  lang: fr
-  event: Elapse Technologies
-  speaker: jpetazzo
-  title: <strike>Bien démarrer avec Docker et l'orchestration (in French)</strike>
-  status: cancelled
+  video: https://www.youtube.com/playlist?list=PLBAFXs0YjviJwCoxSUkUPhsSxDJzpZbJd
 
 - date: [2019-01-07, 2019-01-08]
   country: fr

slides/intro-fullday.yml

@@ -19,7 +19,7 @@ chapters:
 - shared/about-slides.md
 - shared/toc.md
 - - containers/Docker_Overview.md
-  - containers/Docker_History.md
+  #- containers/Docker_History.md
   - containers/Training_Environment.md
   - containers/Installing_Docker.md
   - containers/First_Containers.md
@@ -29,13 +29,32 @@ chapters:
   - containers/Building_Images_Interactively.md
   - containers/Building_Images_With_Dockerfiles.md
   - containers/Cmd_And_Entrypoint.md
-  - containers/Copying_Files_During_Build.md
-- - containers/Multi_Stage_Builds.md
+- - containers/Copying_Files_During_Build.md
+  - |
+      # Exercise — writing Dockerfiles
+
+      Let's write Dockerfiles for an existing application!
+
+      The code is at: https://github.com/jpetazzo/wordsmith
+
+  - containers/Multi_Stage_Builds.md
   - containers/Publishing_To_Docker_Hub.md
   - containers/Dockerfile_Tips.md
+  - |
+      # Exercise — writing better Dockerfiles
+
+      Let's update our Dockerfiles to leverage multi-stage builds!
+
+      The code is at: https://github.com/jpetazzo/wordsmith
+
+      Use a different tag for these images, so that we can compare their sizes.
+
+      What's the size difference between single-stage and multi-stage builds?
+
 - - containers/Naming_And_Inspecting.md
   - containers/Labels.md
   - containers/Getting_Inside.md
+  - containers/Resource_Limits.md
 - - containers/Container_Networking_Basics.md
   - containers/Network_Drivers.md
   - containers/Container_Network_Model.md
@@ -45,16 +64,22 @@ chapters:
   - containers/Windows_Containers.md
   - containers/Working_With_Volumes.md
   - containers/Compose_For_Dev_Stacks.md
-  - containers/Docker_Machine.md
-- - containers/Advanced_Dockerfiles.md
+  - |
+      # Exercise — writing a Compose file
+
+      Let's write a Compose file for the wordsmith app!
+
+      The code is at: https://github.com/jpetazzo/wordsmith
+
+- - containers/Docker_Machine.md
+  - containers/Advanced_Dockerfiles.md
   - containers/Application_Configuration.md
   - containers/Logging.md
-  - containers/Resource_Limits.md
 - - containers/Namespaces_Cgroups.md
   - containers/Copy_On_Write.md
   #- containers/Containers_From_Scratch.md
 - - containers/Container_Engines.md
-  - containers/Ecosystem.md
+  #- containers/Ecosystem.md
   - containers/Orchestration_Overview.md
   - shared/thankyou.md
   - containers/links.md

slides/k8s/apilb.md

@@ -0,0 +1,89 @@
+# API server availability
+
+- When we set up a node, we need the address of the API server:
+
+  - for kubelet
+
+  - for kube-proxy
+
+  - sometimes for the pod network system (like kube-router)
+
+- How do we ensure the availability of that endpoint?
+
+  (what if the node running the API server goes down?)
+
+---
+
+## Option 1: external load balancer
+
+- Set up an external load balancer
+
+- Point kubelet (and other components) to that load balancer
+
+- Put the node(s) running the API server behind that load balancer
+
+- Update the load balancer if/when an API server node needs to be replaced
+
+- On cloud infrastructures, some mechanisms provide automation for this
+
+  (e.g. on AWS, an Elastic Load Balancer + Auto Scaling Group)
+
+- [Example in Kubernetes The Hard Way](https://github.com/kelseyhightower/kubernetes-the-hard-way/blob/master/docs/08-bootstrapping-kubernetes-controllers.md#the-kubernetes-frontend-load-balancer)
+
+---
+
+## Option 2: local load balancer
+
+- Set up a load balancer (like NGINX, HAProxy...) on *each* node
+
+- Configure that load balancer to send traffic to the API server node(s)
+
+- Point kubelet (and other components) to `localhost`
+
+- Update the load balancer configuration when API server nodes are updated
+
+---
+
+## Updating the local load balancer config
+
+- Distribute the updated configuration (push)
+
+- Or regularly check for updates (pull)
+
+- The latter requires an external, highly available store
+ 
+  (it could be an object store, an HTTP server, or even DNS...)
+
+- Updates can be facilitated by a DaemonSet
+
+  (but remember that it can't be used when installing a new node!)
+
+---
+
+## Option 3: DNS records
+
+- Put all the API server nodes behind a round-robin DNS
+
+- Point kubelet (and other components) to that name
+
+- Update the records when needed
+
+- Note: this option is not officially supported
+
+  (but since kubelet supports reconnection anyway, it *should* work)
+
+---
+
+## Option 4: ....................
+
+- Many managed clusters expose a high-availability API endpoint
+
+  (and you don't have to worry about it)
+
+- You can also use HA mechanisms that you're familiar with
+
+  (e.g. virtual IPs)
+
+- Tunnels are also fine
+
+  (e.g. [k3s](https://k3s.io/) uses a tunnel to allow each node to contact the API server)

slides/k8s/architecture.md

@@ -0,0 +1,383 @@
+# Kubernetes architecture
+
+We can arbitrarily split Kubernetes in two parts:
+
+- the *nodes*, a set of machines that run our containerized workloads;
+
+- the *control plane*, a set of processes implementing the Kubernetes APIs.
+
+Kubernetes also relies on underlying infrastructure:
+
+- servers, network connectivity (obviously!),
+
+- optional components like storage systems, load balancers ...
+
+---
+
+## Control plane location
+
+The control plane can run:
+
+- in containers, on the same nodes that run other application workloads
+
+  (example: Minikube; 1 node runs everything)
+
+- on a dedicated node
+
+  (example: a cluster installed with kubeadm)
+
+- on a dedicated set of nodes
+
+  (example: Kubernetes The Hard Way; kops)
+
+- outside of the cluster
+
+  (example: most managed clusters like AKS, EKS, GKE)
+
+---
+
+class: pic
+
+![Kubernetes architecture diagram: control plane and nodes](images/k8s-arch2.png)
+
+---
+
+## What runs on a node
+
+- Our containerized workloads
+
+- A container engine like Docker, CRI-O, containerd...
+
+  (in theory, the choice doesn't matter, as the engine is abstracted by Kubernetes)
+
+- kubelet: an agent connecting the node to the cluster
+
+  (it connects to the API server, registers the node, receives instructions)
+
+- kube-proxy: a component used for internal cluster communication
+
+  (note that this is *not* an overlay network or a CNI plugin!)
+
+---
+
+## What's in the control plane
+
+- Everything is stored in etcd
+
+  (it's the only stateful component)
+
+- Everyone communicates exclusively through the API server:
+
+  - we (users) interact with the cluster through the API server
+
+  - the nodes register and get their instructions through the API server
+
+  - the other control plane components also register with the API server
+
+- API server is the only component that reads/writes from/to etcd
+
+---
+
+## Communication protocols: API server
+
+- The API server exposes a REST API
+
+  (except for some calls, e.g. to attach interactively to a container)
+
+- Almost all requests and responses are JSON following a strict format
+
+- For performance, the requests and responses can also be done over protobuf
+
+  (see this [design proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md) for details)
+
+- In practice, protobuf is used for all internal communication
+
+  (between control plane components, and with kubelet)
+
+---
+
+## Communication protocols: on the nodes
+
+The kubelet agent uses a number of special-purpose protocols and interfaces, including:
+
+- CRI (Container Runtime Interface)
+
+  - used for communication with the container engine
+  - abstracts the differences between container engines
+  - based on gRPC+protobuf
+
+- [CNI (Container Network Interface)](https://github.com/containernetworking/cni/blob/master/SPEC.md)
+
+  - used for communication with network plugins
+  - network plugins are implemented as executable programs invoked by kubelet
+  - network plugins provide IPAM
+  - network plugins set up network interfaces in pods
+
+---
+
+class: pic
+
+![Kubernetes architecture diagram: communication between components](images/k8s-arch4-thanks-luxas.png)
+
+---
+
+# The Kubernetes API
+
+[
+*The Kubernetes API server is a "dumb server" which offers storage, versioning, validation, update, and watch semantics on API resources.*
+](
+https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md#proposal-and-motivation
+)
+
+([Clayton Coleman](https://twitter.com/smarterclayton), Kubernetes Architect and Maintainer)
+
+What does that mean?
+
+---
+
+## The Kubernetes API is declarative
+
+- We cannot tell the API, "run a pod"
+
+- We can tell the API, "here is the definition for pod X"
+
+- The API server will store that definition (in etcd)
+
+- *Controllers* will then wake up and create a pod matching the definition
+
+---
+
+## The core features of the Kubernetes API
+
+- We can create, read, update, and delete objects
+
+- We can also *watch* objects
+
+  (be notified when an object changes, or when an object of a given type is created)
+
+- Objects are strongly typed
+
+- Types are *validated* and *versioned*
+
+- Storage and watch operations are provided by etcd
+
+  (note: the [k3s](https://k3s.io/) project allows us to use sqlite instead of etcd)
+
+---
+
+## Let's experiment a bit!
+
+- For the exercises in this section, connect to the first node of the `test` cluster
+
+.exercise[
+
+- SSH to the first node of the test cluster
+
+- Check that the cluster is operational:
+  ```bash
+  kubectl get nodes
+  ```
+
+- All nodes should be `Ready`
+
+]
+
+---
+
+## Create
+
+- Let's create a simple object
+
+.exercise[
+
+- Create a namespace with the following command:
+  ```bash
+    kubectl create -f- <<EOF
+    apiVersion: v1
+    kind: Namespace
+    metadata:
+      name: hello
+    EOF
+  ```
+
+]
+
+This is equivalent to `kubectl create namespace hello`.
+
+---
+
+## Read
+
+- Let's retrieve the object we just created
+
+.exercise[
+
+- Read back our object:
+  ```bash
+  kubectl get namespace hello -o yaml
+  ```
+
+]
+
+We see a lot of data that wasn't here when we created the object.
+
+Some data was automatically added to the object (like `spec.finalizers`).
+
+Some data is dynamic (typically, the content of `status`.)
+
+---
+
+## API requests and responses
+
+- Almost every Kubernetes API payload (requests and responses) has the same format:
+  ```yaml
+    apiVersion: xxx
+    kind: yyy
+    metadata:
+      name: zzz
+      (more metadata fields here)
+    (more fields here)
+  ```
+
+- The fields shown above are mandatory, except for some special cases
+
+  (e.g.: in lists of resources, the list itself doesn't have a `metadata.name`)
+
+- We show YAML for convenience, but the API uses JSON
+
+  (with optional protobuf encoding)
+
+---
+
+class: extra-details
+
+## API versions
+
+- The `apiVersion` field corresponds to an *API group*
+
+- It can be either `v1` (aka "core" group or "legacy group"), or `group/versions`; e.g.:
+
+  - `apps/v1`
+  - `rbac.authorization.k8s.io/v1`
+  - `extensions/v1beta1`
+
+- It does not indicate which version of Kubernetes we're talking about
+
+- It *indirectly* indicates the version of the `kind`
+
+  (which fields exist, their format, which ones are mandatory...)
+
+- A single resource type (`kind`) is rarely versioned alone
+
+  (e.g.: the `batch` API group contains `jobs` and `cronjobs`)
+
+---
+
+## Update
+
+- Let's update our namespace object
+
+- There are many ways to do that, including:
+
+  - `kubectl apply` (and provide an updated YAML file)
+  - `kubectl edit`
+  - `kubectl patch`
+  - many helpers, like `kubectl label`, or `kubectl set`
+
+- In each case, `kubectl` will:
+
+  - get the current definition of the object
+  - compute changes
+  - submit the changes (with `PATCH` requests)
+
+---
+
+## Adding a label
+
+- For demonstration purposes, let's add a label to the namespace
+
+- The easiest way is to use `kubectl label`
+
+.exercise[
+
+- In one terminal, watch namespaces:
+  ```bash
+  kubectl get namespaces --show-labels -w
+  ```
+
+- In the other, update our namespace:
+  ```bash
+  kubectl label namespaces hello color=purple
+  ```
+
+]
+
+We demonstrated *update* and *watch* semantics.
+
+---
+
+## What's special about *watch*?
+
+- The API server itself doesn't do anything: it's just a fancy object store
+
+- All the actual logic in Kubernetes is implemented with *controllers*
+
+- A *controller* watches a set of resources, and takes action when they change
+
+- Examples:
+
+  - when a Pod object is created, it gets scheduled and started
+
+  - when a Pod belonging to a ReplicaSet terminates, it gets replaced
+
+  - when a Deployment object is updated, it can trigger a rolling update
+
+---
+
+# Other control plane components
+
+- API server ✔️
+
+- etcd ✔️
+
+- Controller manager
+
+- Scheduler
+
+---
+
+## Controller manager
+
+- This is a collection of loops watching all kinds of objects
+
+- That's where the actual logic of Kubernetes lives
+
+- When we create a Deployment (e.g. with `kubectl run web --image=nginx`),
+
+  - we create a Deployment object
+
+  - the Deployment controller notices it, creates a ReplicaSet
+
+  - the ReplicaSet controller notices it, creates a Pod
+
+---
+
+## Scheduler
+
+- When a pod is created, it is in `Pending` state
+
+- The scheduler (or rather: *a scheduler*) must bind it to a node
+
+  - Kubernetes comes with an efficient scheduler with many features
+
+  - if we have special requirements, we can add another scheduler
+    <br/>
+    (example: this [demo scheduler](https://github.com/kelseyhightower/scheduler) uses the cost of nodes, stored in node annotations)
+
+- A pod might stay in `Pending` state for a long time:
+
+  - if the cluster is full
+
+  - if the pod has special constraints that can't be met
+
+  - if the scheduler is not running (!)

slides/k8s/authn-authz.md

@@ -64,7 +64,7 @@
 
   (`401 Unauthorized` HTTP code)
 
-- If a request is neither accepted nor accepted by anyone, it's anonymous
+- If a request is neither rejected nor accepted by anyone, it's anonymous
 
   - the user name is `system:anonymous`
 
@@ -108,7 +108,7 @@ class: extra-details
           --raw \
           -o json \
           | jq -r .users[0].user[\"client-certificate-data\"] \
-          | base64 -d \
+          | openssl base64 -d -A \
           | openssl x509 -text \
           | grep Subject:
   ```
@@ -127,7 +127,7 @@ class: extra-details
 - `--raw` includes certificate information (which shows as REDACTED otherwise)
 - `-o json` outputs the information in JSON format
 - `| jq ...` extracts the field with the user certificate (in base64)
-- `| base64 -d` decodes the base64 format (now we have a PEM file)
+- `| openssl base64 -d -A` decodes the base64 format (now we have a PEM file)
 - `| openssl x509 -text` parses the certificate and outputs it as plain text
 - `| grep Subject:` shows us the line that interests us
 
@@ -260,7 +260,7 @@ class: extra-details
 - Extract the token and decode it:
   ```bash
   TOKEN=$(kubectl get secret $SECRET -o json \
-          | jq -r .data.token | base64 -d)
+          | jq -r .data.token | openssl base64 -d -A)
   ```
 
 ]
@@ -611,3 +611,26 @@ class: extra-details
   ```bash
   kubectl describe clusterrole cluster-admin
   ```
+
+---
+
+class: extra-details
+
+## Figuring out who can do what
+
+- 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:
+
+  https://github.com/aquasecurity/kubectl-who-can
+
+- This is one way to install it:
+  ```bash
+  docker run --rm -v /usr/local/bin:/go/bin golang \
+         go get -v github.com/aquasecurity/kubectl-who-can
+  ```
+
+- This is one way to use it:
+  ```bash
+  kubectl-who-can create pods
+  ```

slides/k8s/bootstrap.md

@@ -0,0 +1,259 @@
+# TLS bootstrap
+
+- kubelet needs TLS keys and certificates to communicate with the control plane
+
+- How do we generate this information?
+
+- How do we make it available to kubelet?
+
+---
+
+## Option 1: push
+
+- When we want to provision a node:
+
+  - generate its keys, certificate, and sign centrally
+
+  - push the files to the node
+
+- OK for "traditional", on-premises deployments
+
+- Not OK for cloud deployments with auto-scaling
+
+---
+
+## Option 2: poll + push
+
+- Discover nodes when they are created
+
+  (e.g. with cloud API)
+
+- When we detect a new node, push TLS material to the node
+
+  (like in option 1)
+
+- It works, but:
+
+  - discovery code is specific to each provider
+
+  - relies heavily on the cloud provider API
+
+  - doesn't work on-premises
+
+  - doesn't scale
+
+---
+
+## Option 3: bootstrap tokens + CSR API
+
+- Since Kubernetes 1.4, the Kubernetes API supports CSR
+
+  (Certificate Signing Requests)
+
+- This is similar to the protocol used to obtain e.g. HTTPS certificates:
+
+  - subject (here, kubelet) generates TLS keys and CSR
+
+  - subject submits CSR to CA
+
+  - CA validates (or not) the CSR
+
+  - CA sends back signed certificate to subject
+
+- This is combined with *bootstrap tokens*
+
+---
+
+## Bootstrap tokens
+
+- A [bootstrap token](https://kubernetes.io/docs/reference/access-authn-authz/bootstrap-tokens/) is an API access token
+
+  - it is a Secret with type `bootstrap.kubernetes.io/token`
+
+  - it is 6 public characters (ID) + 16 secret characters
+    <br/>(example: `whd3pq.d1ushuf6ccisjacu`)
+
+  - it gives access to groups `system:bootstrap:<ID>` and `system:bootstrappers`
+   
+   - additional groups can be specified in the Secret
+
+---
+
+## Bootstrap tokens with kubeadm
+
+- kubeadm automatically creates a bootstrap token
+
+  (it is shown at the end of `kubeadm init`)
+
+- That token adds the group `system:bootstrappers:kubeadm:default-node-token`
+
+- kubeadm also creates a ClusterRoleBinding `kubeadm:kubelet-bootstrap`
+  <br/>binding `...:default-node-token` to ClusterRole `system:node-bootstrapper`
+
+- That ClusterRole gives create/get/list/watch permissions on the CSR API
+
+---
+
+## Bootstrap tokens in practice
+
+- Let's list our bootstrap tokens on a cluster created with kubeadm
+
+.exercise[
+
+- Log into node `test1`
+
+- View bootstrap tokens:
+  ```bash
+  sudo kubeadm token list
+  ```
+
+]
+
+- Tokens are short-lived
+
+- We can create new tokens with `kubeadm` if necessary
+
+---
+
+class: extra-details
+
+## Retrieving bootstrap tokens with kubectl
+
+- Bootstrap tokens are Secrets with type `bootstrap.kubernetes.io/token`
+
+- Token ID and secret are in data fields `token-id` and `token-secret`
+
+- In Secrets, data fields are encoded with Base64
+
+- This "very simple" command will show us the tokens:
+
+```
+kubectl -n kube-system get secrets -o json | 
+        jq -r '.items[] 
+        | select(.type=="bootstrap.kubernetes.io/token")
+        | ( .data["token-id"] + "Lg==" + .data["token-secret"] + "Cg==")
+        ' | base64 -d
+```
+
+(On recent versions of `jq`, you can simplify by using filter `@base64d`.)
+
+---
+
+class: extra-details
+
+## Using a bootstrap token
+
+- The token we need to use has the form `abcdef.1234567890abcdef`
+
+.exercise[
+
+- Check that it is accepted by the API server:
+  ```bash
+  curl -k -H "Authorization: Bearer abcdef.1234567890abcdef"
+  ```
+
+- We should see that we are *authenticated* but not *authorized*:
+  ```
+  User \"system:bootstrap:abcdef\" cannot get path \"/\""
+  ```
+
+- Check that we can access the CSR API:
+  ```bash
+  curl -k -H "Authorization: Bearer abcdef.1234567890abcdef" \
+       https://10.96.0.1/apis/certificates.k8s.io/v1beta1/certificatesigningrequests
+  ```
+
+]
+
+---
+
+## The cluster-info ConfigMap
+
+- Before we can talk to the API, we need:
+
+  - the API server address (obviously!)
+
+  - the cluster CA certificate
+
+- That information is stored in a public ConfigMap
+
+.exercise[
+
+- Retrieve that ConfigMap:
+  ```bash
+  curl -k https://10.96.0.1/api/v1/namespaces/kube-public/configmaps/cluster-info
+  ```
+
+]
+
+*Extracting the kubeconfig file is left as an exercise for the reader.*
+
+---
+
+class: extra-details
+
+## Signature of the config-map
+
+- You might have noticed a few `jws-kubeconfig-...` fields
+
+- These are config-map signatures
+
+  (so that the client can protect against MITM attacks)
+
+- These are JWS signatures using HMAC-SHA256
+
+  (see [here](https://kubernetes.io/docs/reference/access-authn-authz/bootstrap-tokens/#configmap-signing) for more details)
+
+---
+
+## Putting it all together
+
+This is the TLS bootstrap mechanism, step by step.
+
+- The node uses the cluster-info ConfigMap to get the cluster CA certificate
+
+- The node generates its keys and CSR
+
+- Using the bootstrap token, the node creates a CertificateSigningRequest object
+
+- The node watches the CSR object
+
+- The CSR object is accepted (automatically or by an admin)
+
+- The node gets notified, and retrieves the certificate
+
+- The node can now join the cluster
+
+---
+
+## Bottom line
+
+- If you paid attention, we still need a way to:
+
+  - either safely get the bootstrap token to the nodes
+
+  - or disable auto-approval and manually approve the nodes when they join
+
+- The goal of the TLS bootstrap mechanism is *not* to solve this
+
+  (in terms of information knowledge, it's fundamentally impossible!)
+
+- But it reduces the differences between environments, infrastructures, providers ...
+
+- It gives a mechanism that is easier to use, and flexible enough, for most scenarios
+
+---
+
+## More information
+
+- As always, the Kubernetes documentation has extra details:
+
+  - [TLS management](https://kubernetes.io/docs/tasks/tls/managing-tls-in-a-cluster/)
+
+  - [Authenticating with bootstrap tokens](https://kubernetes.io/docs/reference/access-authn-authz/bootstrap-tokens/)
+
+  - [TLS bootstrapping](https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)
+
+  - [kubeadm token](https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-token/) command
+
+  - [kubeadm join](https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-join/) command (has details about [the join workflow](https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm-join/#join-workflow))

slides/k8s/buildshiprun-dockerhub.md

@@ -0,0 +1,40 @@
+## Using images from the Docker Hub
+
+- For everyone's convenience, we took care of building DockerCoins images
+
+- We pushed these images to the DockerHub, under the [dockercoins](https://hub.docker.com/u/dockercoins) user
+
+- These images are *tagged* with a version number, `v0.1`
+
+- The full image names are therefore:
+
+  - `dockercoins/hasher:v0.1`
+
+  - `dockercoins/rng:v0.1`
+
+  - `dockercoins/webui:v0.1`
+
+  - `dockercoins/worker:v0.1`
+
+---
+
+## Setting `$REGISTRY` and `$TAG`
+
+- In the upcoming exercises and labs, we use a couple of environment variables:
+
+  - `$REGISTRY` as a prefix to all image names
+
+  - `$TAG` as the image version tag
+
+- For example, the worker image is `$REGISTRY/worker:$TAG`
+
+- If you copy-paste the commands in these exercises:
+
+  **make sure that you set `$REGISTRY` and `$TAG` first!**
+
+- For example:
+  ```
+  export REGISTRY=dockercoins TAG=v0.1
+  ```
+
+  (this will expand `$REGISTRY/worker:$TAG` to `dockercoins/worker:v0.1`)

slides/k8s/buildshiprun-selfhosted.md

@@ -0,0 +1,235 @@
+## Self-hosting our registry
+
+*Note: this section shows how to run the Docker
+open source registry and use it to ship images
+on our cluster. While this method works fine,
+we recommend that you consider using one of the
+hosted, free automated build services instead.
+It will be much easier!*
+
+*If you need to run a registry on premises,
+this section gives you a starting point, but
+you will need to make a lot of changes so that
+the registry is secured, highly available, and
+so that your build pipeline is automated.*
+
+---
+
+## Using the open source registry
+
+- We need to run a `registry` container
+
+- It will store images and layers to the local filesystem
+  <br/>(but you can add a config file to use S3, Swift, etc.)
+
+- Docker *requires* TLS when communicating with the registry
+
+  - unless for registries on `127.0.0.0/8` (i.e. `localhost`)
+
+  - or with the Engine flag `--insecure-registry`
+
+- Our strategy: publish the registry container on a NodePort,
+  <br/>so that it's available through `127.0.0.1:xxxxx` on each node
+
+---
+
+## Deploying a self-hosted registry
+
+- We will deploy a registry container, and expose it with a NodePort
+
+.exercise[
+
+- Create the registry service:
+  ```bash
+  kubectl create deployment registry --image=registry
+  ```
+
+- Expose it on a NodePort:
+  ```bash
+  kubectl expose deploy/registry --port=5000 --type=NodePort
+  ```
+
+]
+
+---
+
+## Connecting to our registry
+
+- We need to find out which port has been allocated
+
+.exercise[
+
+- View the service details:
+  ```bash
+  kubectl describe svc/registry
+  ```
+
+- Get the port number programmatically:
+  ```bash
+  NODEPORT=$(kubectl get svc/registry -o json | jq .spec.ports[0].nodePort)
+  REGISTRY=127.0.0.1:$NODEPORT
+  ```
+
+]
+
+---
+
+## Testing our registry
+
+- A convenient Docker registry API route to remember is `/v2/_catalog`
+
+.exercise[
+
+<!-- ```hide kubectl wait deploy/registry --for condition=available```-->
+
+- View the repositories currently held in our registry:
+  ```bash
+  curl $REGISTRY/v2/_catalog
+  ```
+
+]
+
+--
+
+We should see:
+```json
+{"repositories":[]}
+```
+
+---
+
+## Testing our local registry
+
+- We can retag a small image, and push it to the registry
+
+.exercise[
+
+- Make sure we have the busybox image, and retag it:
+  ```bash
+  docker pull busybox
+  docker tag busybox $REGISTRY/busybox
+  ```
+
+- Push it:
+  ```bash
+  docker push $REGISTRY/busybox
+  ```
+
+]
+
+---
+
+## Checking again what's on our local registry
+
+- Let's use the same endpoint as before
+
+.exercise[
+
+- Ensure that our busybox image is now in the local registry:
+  ```bash
+  curl $REGISTRY/v2/_catalog
+  ```
+
+]
+
+The curl command should now output:
+```json
+{"repositories":["busybox"]}
+```
+
+---
+
+## Building and pushing our images
+
+- We are going to use a convenient feature of Docker Compose
+
+.exercise[
+
+- Go to the `stacks` directory:
+  ```bash
+  cd ~/container.training/stacks
+  ```
+
+- Build and push the images:
+  ```bash
+  export REGISTRY
+  export TAG=v0.1
+  docker-compose -f dockercoins.yml build
+  docker-compose -f dockercoins.yml push
+  ```
+
+]
+
+Let's have a look at the `dockercoins.yml` file while this is building and pushing.
+
+---
+
+```yaml
+version: "3"
+
+services:
+  rng:
+    build: dockercoins/rng
+    image: ${REGISTRY-127.0.0.1:5000}/rng:${TAG-latest}
+    deploy:
+      mode: global
+  ...
+  redis:
+    image: redis
+  ...
+  worker:
+    build: dockercoins/worker
+    image: ${REGISTRY-127.0.0.1:5000}/worker:${TAG-latest}
+    ...
+    deploy:
+      replicas: 10
+```
+
+.warning[Just in case you were wondering ... Docker "services" are not Kubernetes "services".]
+
+---
+
+class: extra-details
+
+## Avoiding the `latest` tag
+
+.warning[Make sure that you've set the `TAG` variable properly!]
+
+- If you don't, the tag will default to `latest`
+
+- The problem with `latest`: nobody knows what it points to!
+
+  - the latest commit in the repo?
+
+  - the latest commit in some branch? (Which one?)
+
+  - the latest tag?
+
+  - some random version pushed by a random team member?
+
+- If you keep pushing the `latest` tag, how do you roll back?
+
+- Image tags should be meaningful, i.e. correspond to code branches, tags, or hashes
+
+---
+
+## Checking the content of the registry
+
+- All our images should now be in the registry
+
+.exercise[
+
+- Re-run the same `curl` command as earlier:
+  ```bash
+  curl $REGISTRY/v2/_catalog
+  ```
+
+]
+
+*In these slides, all the commands to deploy
+DockerCoins will use a $REGISTRY environment
+variable, so that we can quickly switch from
+the self-hosted registry to pre-built images
+hosted on the Docker Hub. So make sure that
+this $REGISTRY variable is set correctly when
+running the exercises!*

slides/k8s/cloud-controller-manager.md

@@ -0,0 +1,144 @@
+# The Cloud Controller Manager
+
+- Kubernetes has many features that are cloud-specific
+
+  (e.g. providing cloud load balancers when a Service of type LoadBalancer is created)
+
+- These features were initially implemented in API server and controller manager
+
+- Since Kubernetes 1.6, these features are available through a separate process:
+
+  the *Cloud Controller Manager*
+
+- The CCM is optional, but if we run in a cloud, we probably want it!
+
+---
+
+## Cloud Controller Manager duties
+
+- Creating and updating cloud load balancers
+
+- Configuring routing tables in the cloud network (specific to GCE)
+
+- 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 ...)
+
+  (Eventually, volumes will be managed by the CSI)
+
+---
+
+## In-tree vs. out-of-tree
+
+- A number of cloud providers are supported "in-tree"
+
+  (in the main kubernetes/kubernetes repository on GitHub)
+
+- More cloud providers are supported "out-of-tree"
+
+  (with code in different repositories)
+
+- There is an [ongoing effort](https://github.com/kubernetes/kubernetes/tree/master/pkg/cloudprovider) to move everything to out-of-tree providers
+
+---
+
+## In-tree providers
+
+The following providers are actively maintained:
+
+- Amazon Web Services
+- Azure
+- Google Compute Engine
+- IBM Cloud
+- OpenStack
+- VMware vSphere
+
+These ones are less actively maintained:
+
+- Apache CloudStack
+- oVirt
+- VMware Photon
+
+---
+
+## Out-of-tree providers
+
+The list includes the following providers:
+
+- DigitalOcean
+
+- keepalived (not exactly a cloud; provides VIPs for load balancers)
+
+- Linode
+
+- Oracle Cloud Infrastructure
+
+(And possibly others; there is no central registry for these.)
+
+---
+
+## Audience questions
+
+- What kind of clouds are you using / planning to use?
+
+- What kind of details would you like to see in this section?
+
+- Would you appreciate details on clouds that you don't / won't use?
+
+---
+
+## Cloud Controller Manager in practice
+
+- Write a configuration file
+
+  (typically `/etc/kubernetes/cloud.conf`)
+
+- Run the CCM process
+
+  (on self-hosted clusters, this can be a DaemonSet selecting the control plane nodes)
+
+- Start kubelet with `--cloud-provider=external`
+
+- When using managed clusters, this is done automatically
+
+- There is very little documentation to write the configuration file
+
+  (except for OpenStack)
+
+---
+
+## Bootstrapping challenges
+
+- When a node joins the cluster, it needs to obtain a signed TLS certificate
+
+- That certificate must contain the node's addresses
+
+- These addresses are provided by the Cloud Controller Manager
+
+  (at least the external address)
+
+- To get these addresses, the node needs to communicate with the control plane
+
+- ... 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.)
+
+---
+
+## More information about CCM
+
+- CCM configuration and operation is highly specific to each cloud provider
+
+  (which is why this section remains very generic)
+
+- The Kubernetes documentation has *some* information:
+
+  - [architecture and diagrams](https://kubernetes.io/docs/concepts/architecture/cloud-controller/)
+
+  - [configuration](https://kubernetes.io/docs/concepts/cluster-administration/cloud-providers/) (mainly for OpenStack)
+
+  - [deployment](https://kubernetes.io/docs/tasks/administer-cluster/running-cloud-controller/)

slides/k8s/cluster-backup.md

@@ -0,0 +1,362 @@
+# Backing up clusters
+
+- Backups can have multiple purposes:
+
+  - disaster recovery (servers or storage are destroyed or unreachable)
+
+  - error recovery (human or process has altered or corrupted data)
+
+  - cloning environments (for testing, validation ...)
+
+- Let's see the strategies and tools available with Kubernetes!
+
+---
+
+## Important
+
+- Kubernetes helps us with disaster recovery
+
+  (it gives us replication primitives)
+
+- Kubernetes helps us to 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:
+
+  - with database backups (mysqldump, pgdump, etc.)
+
+  - and/or snapshots at the storage layer
+
+  - and/or traditional full disk backups
+
+---
+
+## In a perfect world ...
+
+- The deployment of our Kubernetes clusters is automated
+
+  (recreating a cluster takes less than a minute of human time)
+
+- All the resources (Deployments, Services...) on our clusters are under version control
+
+  (never use `kubectl run`; always apply YAML files coming from a repository)
+
+- Stateful components are either:
+
+  - stored on systems with regular snapshots
+
+  - backed up regularly to an external, durable storage
+
+  - outside of Kubernetes
+
+---
+
+## Kubernetes cluster deployment
+
+- 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 ...
+
+  - for a senior engineer?
+
+  - for a new hire?
+
+- Does it require external intervention?
+
+  (e.g. provisioning servers, signing TLS certs ...)
+
+---
+
+## Plan B
+
+- Full machine backups of the control plane can help
+
+- If the control plane is in pods (or containers), pay attention to storage drivers
+
+  (if the backup mechanism is not container-aware, the backups can take way more resources than they should, or even be unusable!)
+
+- If the previous sentence worries you:
+
+  **automate the deployment of your clusters!**
+
+---
+
+## Managing our Kubernetes resources
+
+- Ideal scenario:
+
+  - never create a resource directly on a cluster
+
+  - push to a code repository
+
+  - a special branch (`production` or even `master`) gets automatically deployed
+
+- Some folks call this "GitOps"
+
+  (it's the logical evolution of configuration management and infrastructure as code)
+
+---
+
+## GitOps in theory
+
+- What do we keep in version control?
+
+- For very simple scenarios: source code, Dockerfiles, scripts
+
+- For real applications: add resources (as YAML files)
+
+- For applications deployed multiple times: Helm, Kustomize ...
+
+  (staging and production count as "multiple times")
+
+---
+
+## GitOps tooling
+
+- Various tools exist (Weave Flux, GitKube...)
+
+- These tools are still very young
+
+- You still need to write YAML for all your resources
+
+- There is no tool to:
+
+  - list *all* resources in a namespace
+
+  - get resource YAML in a canonical form
+
+  - diff YAML descriptions with current state
+
+---
+
+## GitOps in practice
+
+- Start describing your resources with YAML
+
+- Leverage a tool like Kustomize or Helm
+
+- Make sure that you can easily deploy to a new namespace
+
+  (or even better: to a new cluster)
+
+- When tooling matures, you will be ready
+
+---
+
+## Plan B
+
+- What if we can't describe everything with YAML?
+
+- What if we manually create resources and forget to commit them to source control?
+
+- What about global resources, that don't live in a namespace?
+
+- How can we be sure that we saved *everything*?
+
+---
+
+## Backing up etcd
+
+- All objects are saved in etcd
+
+- etcd data should be relatively small
+
+  (and therefore, quick and easy to back up)
+
+- Two options to back up etcd:
+
+  - snapshot the data directory
+
+  - use `etcdctl snapshot`
+
+---
+
+## Making an etcd snapshot
+
+- The basic command is simple:
+  ```bash
+  etcdctl snapshot save <filename>
+  ```
+
+- But we also need to specify:
+
+  - an environment variable to specify that we want etcdctl v3
+
+  - the address of the server to back up
+
+  - the path to the key, certificate, and CA certificate
+    <br/>(if our etcd uses TLS certificates)
+
+---
+
+## Snapshotting etcd on kubeadm
+
+- The following command will work on clusters deployed with kubeadm
+
+  (and maybe others)
+
+- It should be executed on a master node
+
+```bash
+docker run --rm --net host -v $PWD:/vol \
+    -v /etc/kubernetes/pki/etcd:/etc/kubernetes/pki/etcd:ro \
+    -e ETCDCTL_API=3 k8s.gcr.io/etcd:3.3.10 \
+    etcdctl --endpoints=https://[127.0.0.1]:2379 \
+            --cacert=/etc/kubernetes/pki/etcd/ca.crt \
+            --cert=/etc/kubernetes/pki/etcd/healthcheck-client.crt \
+            --key=/etc/kubernetes/pki/etcd/healthcheck-client.key \
+            snapshot save /vol/snapshot
+```
+
+- It will create a file named `snapshot` in the current directory
+
+---
+
+## How can we remember all these flags?
+
+- Look at the static pod manifest for etcd
+
+  (in `/etc/kubernetes/manifests`)
+
+- The healthcheck probe is calling `etcdctl` with all the right flags 
+  😉👍✌️
+
+- Exercise: write the YAML for a batch job to perform the backup
+
+---
+
+## Restoring an etcd snapshot
+
+- ~~Execute exactly the same command, but replacing `save` with `restore`~~
+
+  (Believe it or not, doing that will *not* do anything useful!)
+
+- The `restore` command does *not* load a snapshot into a running etcd server
+
+- The `restore` command creates a new data directory from the snapshot
+
+  (it's an offline operation; it doesn't interact with an etcd server)
+
+- It will create a new data directory in a temporary container
+
+  (leaving the running etcd node untouched)
+
+---
+
+## When using kubeadm
+
+1. Create a new data directory from the snapshot:
+   ```bash
+   sudo rm -rf /var/lib/etcd
+   docker run --rm -v /var/lib:/var/lib -v $PWD:/vol \
+          -e ETCDCTL_API=3 k8s.gcr.io/etcd:3.3.10 \
+          etcdctl snapshot restore /vol/snapshot --data-dir=/var/lib/etcd
+   ```
+
+2. Provision the control plane, using that data directory:
+   ```bash
+   sudo kubeadm init \
+        --ignore-preflight-errors=DirAvailable--var-lib-etcd
+   ```
+
+3. Rejoin the other nodes
+
+---
+
+## The fine print
+
+- This only saves etcd state
+
+- It **does not** save persistent volumes and local node data
+
+- Some critical components (like the pod network) might need to be reset
+
+- As a result, our pods might have to be recreated, too
+
+- If we have proper liveness checks, this should happen automatically
+
+---
+
+## More information about etcd backups
+
+- [Kubernetes documentation](https://kubernetes.io/docs/tasks/administer-cluster/configure-upgrade-etcd/#built-in-snapshot) about etcd backups
+
+- [etcd documentation](https://coreos.com/etcd/docs/latest/op-guide/recovery.html#snapshotting-the-keyspace) about snapshots and restore
+
+- [A good blog post by elastisys](https://elastisys.com/2018/12/10/backup-kubernetes-how-and-why/) explaining how to restore a snapshot
+
+- [Another good blog post by consol labs](https://labs.consol.de/kubernetes/2018/05/25/kubeadm-backup.html) on the same topic
+
+---
+
+## Don't forget ...
+
+- Also back up the TLS information
+
+  (at the very least: CA key and cert; API server key and cert)
+
+- With clusters provisioned by kubeadm, this is in `/etc/kubernetes/pki`
+
+- If you don't:
+
+  - you will still be able to restore etcd state and bring everything back up
+
+  - you will need to redistribute user certificates
+
+.warning[**TLS information is highly sensitive! 
+<br/>Anyone who has it has full access to your cluster!**]
+
+---
+
+## Stateful services
+
+- It's totally fine to keep your production databases outside of Kubernetes
+
+  *Especially if you have only one database server!*
+
+- Feel free to put development and staging databases on Kubernetes
+
+  (as long as they don't hold important data)
+
+- Using Kubernetes for stateful services makes sense if you have *many*
+
+  (because then you can leverage Kubernetes automation)
+
+---
+
+## Snapshotting persistent volumes
+
+- Option 1: snapshot volumes out of band
+
+  (with the API/CLI/GUI of our SAN/cloud/...)
+
+- Option 2: storage system integration
+
+  (e.g. [Portworx](https://docs.portworx.com/portworx-install-with-kubernetes/storage-operations/create-snapshots/) can [create snapshots through annotations](https://docs.portworx.com/portworx-install-with-kubernetes/storage-operations/create-snapshots/snaps-annotations/#taking-periodic-snapshots-on-a-running-pod))
+
+- Option 3: [snapshots through Kubernetes API](https://kubernetes.io/blog/2018/10/09/introducing-volume-snapshot-alpha-for-kubernetes/)
+
+  (now in alpha for a few storage providers: GCE, OpenSDS, Ceph, Portworx)
+
+---
+
+## More backup tools
+
+- [Stash](https://appscode.com/products/stash/)
+
+  back up Kubernetes persistent volumes
+
+- [ReShifter](https://github.com/mhausenblas/reshifter)
+
+  cluster state management
+
+- ~~Heptio Ark~~ [Velero](https://github.com/heptio/velero)
+
+  full cluster backup
+
+- [kube-backup](https://github.com/pieterlange/kube-backup)
+
+  simple scripts to save resource YAML to a git repository

slides/k8s/cluster-sizing.md

@@ -0,0 +1,167 @@
+# Cluster sizing
+
+- What happens when the cluster gets full?
+
+- How can we scale up the cluster?
+
+- Can we do it automatically?
+
+- What are other methods to address capacity planning?
+
+---
+
+## When are we out of resources?
+
+- kubelet monitors node resources:
+
+  - memory
+
+  - node disk usage (typically the root filesystem of the node)
+
+  - image disk usage (where container images and RW layers are stored)
+
+- For each resource, we can provide two thresholds:
+
+  - a hard threshold (if it's met, it provokes immediate action)
+
+  - a soft threshold (provokes action only after a grace period)
+
+- Resource thresholds and grace periods are configurable
+
+  (by passing kubelet command-line flags)
+
+---
+
+## What happens then?
+
+- If disk usage is too high:
+
+  - kubelet will try to remove terminated pods
+
+  - then, it will try to *evict* pods
+
+- If memory usage is too high:
+
+  - it will try to evict pods
+
+- The node is marked as "under pressure"
+
+- This temporarily prevents new pods from being scheduled on the node
+
+---
+
+## Which pods get evicted?
+
+- kubelet looks at the pods' QoS and PriorityClass
+
+- First, pods with BestEffort QoS are considered
+
+- Then, pods with Burstable QoS exceeding their *requests*
+
+  (but only if the exceeding resource is the one that is low on the node)
+
+- Finally, pods with Guaranteed QoS, and Burstable pods within their requests
+
+- Within each group, pods are sorted by PriorityClass
+
+- If there are pods with the same PriorityClass, they are sorted by usage excess
+
+  (i.e. the pods whose usage exceeds their requests the most are evicted first)
+
+---
+
+class: extra-details
+
+## Eviction of Guaranteed pods
+
+- *Normally*, pods with Guaranteed QoS should not be evicted
+
+- A chunk of resources is reserved for node processes (like kubelet)
+
+- It is expected that these processes won't use more than this reservation
+
+- If they do use more resources anyway, all bets are off!
+
+- If this happens, kubelet must evict Guaranteed pods to preserve node stability
+
+  (or Burstable pods that are still within their requested usage)
+
+---
+
+## What happens to evicted pods?
+
+- The pod is terminated
+
+- It is marked as `Failed` at the API level
+
+- If the pod was created by a controller, the controller will recreate it
+
+- The pod will be recreated on another node, *if there are resources available!*
+
+- For more details about the eviction process, see:
+
+  - [this documentation page](https://kubernetes.io/docs/tasks/administer-cluster/out-of-resource/) about resource pressure and pod eviction,
+
+  - [this other documentation page](https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/) about pod priority and preemption.
+
+---
+
+## What if there are no resources available?
+
+- Sometimes, a pod cannot be scheduled anywhere:
+
+  - all the nodes are under pressure,
+
+  - or the pod requests more resources than are available
+
+- The pod then remains in `Pending` state until the situation improves
+
+---
+
+## Cluster scaling
+
+- One way to improve the situation is to add new nodes
+
+- This can be done automatically with the [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler)
+
+- The autoscaler will automatically scale up:
+
+  - if there are pods that failed to be scheduled
+
+- The autoscaler will automatically scale down:
+
+  - if nodes have a low utilization for an extended period of time
+
+---
+
+## Restrictions, gotchas ...
+
+- The Cluster Autoscaler only supports a few cloud infrastructures
+
+  (see [here](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler/cloudprovider) for a list)
+
+- The Cluster Autoscaler cannot scale down nodes that have pods using:
+
+  - local storage
+
+  - affinity/anti-affinity rules preventing them from being rescheduled
+
+  - a restrictive PodDisruptionBudget
+
+---
+
+## Other way to do capacity planning
+
+- "Running Kubernetes without nodes"
+
+- Systems like [Virtual Kubelet](https://virtual-kubelet.io/) or Kiyot can run pods using on-demand resources
+
+  - Virtual Kubelet can leverage e.g. ACI or Fargate to run pods
+
+  - Kiyot runs pods in ad-hoc EC2 instances (1 instance per pod)
+
+- Economic advantage (no wasted capacity)
+
+- Security advantage (stronger isolation between pods)
+
+Check [this blog post](http://jpetazzo.github.io/2019/02/13/running-kubernetes-without-nodes-with-kiyot/) for more details.

slides/k8s/cluster-upgrade.md

@@ -0,0 +1,309 @@
+# Upgrading clusters
+
+- It's *recommended* to run consistent versions across a cluster
+
+  (mostly to have feature parity and latest security updates)
+
+- It's not *mandatory*
+
+  (otherwise, cluster upgrades would be a nightmare!)
+
+- Components can be upgraded one at a time without problems
+
+---
+
+## Checking what we're running
+
+- It's easy to check the version for the API server
+
+.exercise[
+
+- Log into node `test1`
+
+- Check the version of kubectl and of the API server:
+  ```bash
+  kubectl version
+  ```
+
+]
+
+- In a HA setup with multiple API servers, they can have different versions
+
+- Running the command above multiple times can return different values
+
+---
+
+## Node versions
+
+- It's also easy to check the version of kubelet
+
+.exercise[
+
+- Check node versions (includes kubelet, kernel, container engine):
+  ```bash
+  kubectl get nodes -o wide
+  ```
+
+]
+
+- Different nodes can run different kubelet versions
+
+- Different nodes can run different kernel versions
+
+- Different nodes can run different container engines
+
+---
+
+## Control plane versions
+
+- If the control plane is self-hosted (running in pods), we can check it
+
+.exercise[
+
+- Show image versions for all pods in `kube-system` namespace:
+  ```bash
+    kubectl --namespace=kube-system get pods -o json \
+            | jq -r '
+              .items[]
+              | [.spec.nodeName, .metadata.name]
+                + 
+                (.spec.containers[].image | split(":"))
+              | @tsv
+              ' \
+            | column -t
+  ```
+
+]
+
+---
+
+## What version are we running anyway?
+
+- When I say, "I'm running Kubernetes 1.11", is that the version of:
+
+  - kubectl
+
+  - API server
+
+  - kubelet
+
+  - controller manager
+
+  - something else?
+
+---
+
+## Other versions that are important
+
+- etcd
+
+- kube-dns or CoreDNS
+
+- CNI plugin(s)
+
+- Network controller, network policy controller
+
+- Container engine
+
+- Linux kernel
+
+---
+
+## General guidelines
+
+- To update a component, use whatever was used to install it
+
+- If it's a distro package, update that distro package
+
+- If it's a container or pod, update that container or pod
+
+- If you used configuration management, update with that
+
+---
+
+## Know where your binaries come from
+
+- Sometimes, we need to upgrade *quickly*
+
+  (when a vulnerability is announced and patched)
+
+- If we are using an installer, we should:
+
+  - make sure it's using upstream packages
+
+  - or make sure that whatever packages it uses are current
+
+  - make sure we can tell it to pin specific component versions
+
+---
+
+## In practice
+
+- We are going to update a few cluster components
+
+- We will change the kubelet version on one node
+
+- We will change the version of the API server
+
+- We will work with cluster `test` (nodes `test1`, `test2`, `test3`)
+
+---
+
+## Updating kubelet
+
+- These nodes have been installed using the official Kubernetes packages
+
+- We can therefore use `apt` or `apt-get`
+
+.exercise[
+
+- Log into node `test3`
+
+- View available versions for package `kubelet`:
+  ```bash
+  apt show kubelet -a | grep ^Version
+  ```
+
+- Upgrade kubelet:
+  ```bash
+  apt install kubelet=1.14.1-00
+  ```
+
+]
+
+---
+
+## Checking what we've done
+
+.exercise[
+
+- Log into node `test1`
+
+- Check node versions:
+  ```bash
+  kubectl get nodes -o wide
+  ```
+
+- Create a deployment and scale it to make sure that the node still works
+
+]
+
+---
+
+## Updating the API server
+
+- This cluster has been deployed with kubeadm
+
+- The control plane runs in *static pods*
+
+- These pods are started automatically by kubelet
+
+  (even when kubelet can't contact the API server)
+
+- They are defined in YAML files in `/etc/kubernetes/manifests`
+
+  (this path is set by a kubelet command-line flag)
+
+- kubelet automatically updates the pods when the files are changed
+
+---
+
+## Changing the API server version
+
+- We will edit the YAML file to use a different image version
+
+.exercise[
+
+- Log into node `test1`
+
+- Check API server version:
+  ```bash
+  kubectl version
+  ```
+
+- Edit the API server pod manifest:
+  ```bash
+  sudo vim /etc/kubernetes/manifests/kube-apiserver.yaml
+  ```
+
+- Look for the `image:` line, and update it to e.g. `v1.14.0`
+
+]
+
+---
+
+## Checking what we've done
+
+- The API server will be briefly unavailable while kubelet restarts it
+
+.exercise[
+
+- Check the API server version:
+  ```bash
+  kubectl version
+  ```
+
+]
+
+---
+
+## Updating the whole control plane
+
+- As an example, we'll use kubeadm to upgrade the entire control plane
+
+  (note: this is possible only because the cluster was installed with kubeadm)
+
+.exercise[
+
+- Check what will be upgraded:
+  ```bash
+  sudo kubeadm upgrade plan
+  ```
+
+  (Note: kubeadm is confused by our manual upgrade of the API server.
+  <br/>It thinks the cluster is running 1.14.0!)
+
+<!-- ##VERSION## -->
+
+- Perform the upgrade:
+  ```bash
+  sudo kubeadm upgrade apply v1.14.1
+  ```
+
+]
+
+---
+
+## Updating kubelets
+
+- After updating the control plane, we need to update each kubelet
+
+- This requires to run a special command on each node, to download the config
+
+  (this config is generated by kubeadm)
+
+.exercise[
+
+- 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.1
+  	  ssh node $N sudo apt install kubelet=1.14.1-00
+    done
+  ```
+]
+
+---
+
+## Checking what we've done
+
+- All our nodes should now be updated to version 1.14.1
+
+.exercise[
+
+- Check nodes versions:
+  ```bash
+  kubectl get nodes -o wide
+  ```
+
+]

slides/k8s/cni.md

@@ -0,0 +1,684 @@
+# The Container Network Interface
+
+- Allows us to decouple network configuration from Kubernetes
+
+- Implemented by *plugins*
+
+- Plugins are executables that will be invoked by kubelet
+
+- Plugins are responsible for:
+
+  - allocating IP addresses for containers
+
+  - configuring the network for containers
+
+- Plugins can be combined and chained when it makes sense
+
+---
+
+## Combining plugins
+
+- Interface could be created by e.g. `vlan` or `bridge` plugin
+
+- IP address could be allocated by e.g. `dhcp` or `host-local` plugin
+
+- Interface parameters (MTU, sysctls) could be tweaked by the `tuning` plugin
+
+The reference plugins are available [here].
+
+Look into each plugin's directory for its documentation.
+
+[here]: https://github.com/containernetworking/plugins/tree/master/plugins
+
+---
+
+## How does kubelet know which plugins to use?
+
+- The plugin (or list of plugins) is set in the CNI configuration
+
+- The CNI configuration is a *single file* in `/etc/cni/net.d`
+
+- If there are multiple files in that directory, the first one is used
+
+  (in lexicographic order)
+
+- That path can be changed with the `--cni-conf-dir` flag of kubelet
+
+---
+
+## CNI configuration in practice
+
+- When we set up the "pod network" (like Calico, Weave...) it ships a CNI configuration
+
+  (and sometimes, custom CNI plugins)
+
+- Very often, that configuration (and plugins) is installed automatically
+
+  (by a DaemonSet featuring an initContainer with hostPath volumes)
+
+- Examples:
+
+  - Calico [CNI config](https://github.com/projectcalico/calico/blob/1372b56e3bfebe2b9c9cbf8105d6a14764f44159/v2.6/getting-started/kubernetes/installation/hosted/calico.yaml#L25)
+    and [volume](https://github.com/projectcalico/calico/blob/1372b56e3bfebe2b9c9cbf8105d6a14764f44159/v2.6/getting-started/kubernetes/installation/hosted/calico.yaml#L219)
+
+  - kube-router [CNI config](https://github.com/cloudnativelabs/kube-router/blob/c2f893f64fd60cf6d2b6d3fee7191266c0fc0fe5/daemonset/generic-kuberouter.yaml#L10)
+    and [volume](https://github.com/cloudnativelabs/kube-router/blob/c2f893f64fd60cf6d2b6d3fee7191266c0fc0fe5/daemonset/generic-kuberouter.yaml#L73)
+
+---
+
+## Conf vs conflist
+
+- There are two slightly different configuration formats
+
+- Basic configuration format:
+
+  - holds configuration for a single plugin
+  - typically has a `.conf` name suffix
+  - has a `type` string field in the top-most structure
+  - [examples](https://github.com/containernetworking/cni/blob/master/SPEC.md#example-configurations)
+
+- Configuration list format:
+
+  - can hold configuration for multiple (chained) plugins
+  - typically has a `.conflist` name suffix
+  - has a `plugins` list field in the top-most structure
+  - [examples](https://github.com/containernetworking/cni/blob/master/SPEC.md#network-configuration-lists)
+
+---
+
+class: extra-details
+
+## How plugins are invoked
+
+- Parameters are given through environment variables, including:
+
+  - CNI_COMMAND: desired operation (ADD, DEL, CHECK, or VERSION)
+
+  - CNI_CONTAINERID: container ID
+
+  - CNI_NETNS: path to network namespace file
+
+  - CNI_IFNAME: how the network interface should be named
+
+- The network configuration must be provided to the plugin on stdin
+
+  (this avoids race conditions that could happen by passing a file path)
+
+---
+
+## In practice: kube-router
+
+- We are going to set up a new cluster
+
+- For this new cluster, we will use kube-router
+
+- kube-router will provide the "pod network"
+
+  (connectivity with pods)
+
+- kube-router will also provide internal service connectivity
+
+  (replacing kube-proxy)
+
+---
+
+## How kube-router works
+
+- Very simple architecture
+
+- Does not introduce new CNI plugins
+
+  (uses the `bridge` plugin, with `host-local` for IPAM)
+
+- Pod traffic is routed between nodes
+
+  (no tunnel, no new protocol)
+
+- Internal service connectivity is implemented with IPVS
+
+- Can provide pod network and/or internal service connectivity
+
+- kube-router daemon runs on every node
+
+---
+
+## What kube-router does
+
+- Connect to the API server
+
+- Obtain the local node's `podCIDR`
+
+- Inject it into the CNI configuration file
+
+  (we'll use `/etc/cni/net.d/10-kuberouter.conflist`)
+
+- Obtain the addresses of all nodes
+
+- Establish a *full mesh* BGP peering with the other nodes
+
+- Exchange routes over BGP
+
+---
+
+## What's BGP?
+
+- BGP (Border Gateway Protocol) is the protocol used between internet routers
+
+- It [scales](https://www.cidr-report.org/as2.0/)
+  pretty [well](https://www.cidr-report.org/cgi-bin/plota?file=%2fvar%2fdata%2fbgp%2fas2.0%2fbgp-active%2etxt&descr=Active%20BGP%20entries%20%28FIB%29&ylabel=Active%20BGP%20entries%20%28FIB%29&with=step)
+  (it is used to announce the 700k CIDR prefixes of the internet)
+
+- It is spoken by many hardware routers from many vendors
+
+- It also has many software implementations (Quagga, Bird, FRR...)
+
+- Experienced network folks generally know it (and appreciate it)
+
+- It also used by Calico (another popular network system for Kubernetes)
+
+- Using BGP allows us to interconnect our "pod network" with other systems
+
+---
+
+## The plan
+
+- We'll work in a new cluster (named `kuberouter`)
+
+- We will run a simple control plane (like before)
+
+- ... But this time, the controller manager will allocate `podCIDR` subnets
+
+- We will start kube-router with a DaemonSet
+
+- This DaemonSet will start one instance of kube-router on each node
+
+---
+  
+## Logging into the new cluster
+
+.exercise[
+
+- Log into node `kuberouter1`
+
+- Clone the workshop repository:
+  ```bash
+  git clone https://@@GITREPO@@
+  ```
+
+- Move to this directory:
+  ```bash
+  cd container.training/compose/kube-router-k8s-control-plane
+  ```
+
+]
+
+---
+
+## Our control plane
+
+- We will use a Compose file to start the control plane
+
+- 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:
+
+  `--allocate-node-cidrs` and `--cluster-cidr`
+
+- We need to edit the Compose file to set the Cluster CIDR
+
+---
+
+## Starting the control plane
+
+- Our cluster CIDR will be `10.C.0.0/16`
+
+  (where `C` is our cluster number)
+
+.exercise[
+
+- Edit the Compose file to set the Cluster CIDR:
+  ```bash
+  vim docker-compose.yaml
+  ```
+
+- Start the control plane:
+  ```bash
+  docker-compose up
+  ```
+
+]
+
+---
+
+## The kube-router DaemonSet 
+
+- In the same directory, there is a `kuberouter.yaml` file
+
+- It contains the definition for a DaemonSet and a ConfigMap
+
+- Before we load it, we also need to edit it
+
+- We need to indicate the address of the API server
+
+  (because kube-router needs to connect to it to retrieve node information)
+
+---
+
+## Creating the DaemonSet
+
+- 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)
+
+.exercise[
+
+- Edit the YAML file to set the API server address:
+  ```bash
+  vim kuberouter.yaml
+  ```
+
+- Create the DaemonSet:
+  ```bash
+  kubectl create -f kuberouter.yaml
+  ```
+
+]
+
+Note: the DaemonSet won't create any pods (yet) since there are no nodes (yet).
+
+---
+
+## Generating the kubeconfig for kubelet
+
+- This is similar to what we did for the `kubenet` cluster
+
+.exercise[
+
+- 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
+  ```
+
+]
+
+---
+
+## Distributing kubeconfig
+
+- We need to copy that kubeconfig file to the other nodes
+
+.exercise[
+
+- Copy `kubeconfig` to the other nodes:
+  ```bash
+    for N in 2 3; do
+    	scp ~/kubeconfig kuberouter$N:
+    done
+  ```
+
+]
+
+---
+
+## Starting kubelet
+
+- We don't need the `--pod-cidr` option anymore
+
+  (the controller manager will allocate these automatically)
+
+- We need to pass `--network-plugin=cni`
+
+.exercise[
+
+- Join the first node:
+   ```bash
+   sudo kubelet --kubeconfig ~/kubeconfig --network-plugin=cni
+   ```
+
+- Open more terminals and join the other nodes:
+  ```bash
+  ssh kuberouter2 sudo kubelet --kubeconfig ~/kubeconfig --network-plugin=cni
+  ssh kuberouter3 sudo kubelet --kubeconfig ~/kubeconfig --network-plugin=cni
+  ```
+
+]
+
+---
+
+## Setting up a test
+
+- Let's create a Deployment and expose it with a Service
+
+.exercise[
+
+- Create a Deployment running a web server:
+  ```bash
+  kubectl create deployment web --image=jpetazzo/httpenv
+  ```
+
+- Scale it so that it spans multiple nodes:
+  ```bash
+  kubectl scale deployment web --replicas=5
+  ```
+
+- Expose it with a Service:
+  ```bash
+  kubectl expose deployment web --port=8888
+  ```
+
+]
+
+---
+
+## Checking that everything works
+
+.exercise[
+
+- Get the ClusterIP address for the service:
+  ```bash
+  kubectl get svc web
+  ```
+
+- Send a few requests there:
+  ```bash
+  curl `X.X.X.X`:8888
+  ```
+
+]
+
+Note that if you send multiple requests, they are load-balanced in a round robin manner.
+
+This shows that we are using IPVS (vs. iptables, which picked random endpoints).
+
+---
+
+## Troubleshooting
+
+- What if we need to check that everything is working properly?
+
+.exercise[
+
+- Check the IP addresses of our pods:
+  ```bash
+  kubectl get pods -o wide
+  ```
+
+- Check our routing table:
+  ```bash
+  route -n
+  ip route
+  ```
+
+]
+
+We should see the local pod CIDR connected to `kube-bridge`, and the other nodes' pod CIDRs having individual routes, with each node being the gateway.
+
+---
+
+## More troubleshooting
+
+- We can also look at the output of the kube-router pods
+
+  (with `kubectl logs`)
+
+- kube-router also comes with a special shell that gives lots of useful info
+
+  (we can access it with `kubectl exec`)
+
+- But with the current setup of the cluster, these options may not work!
+
+- Why?
+
+---
+
+## Trying `kubectl logs` / `kubectl exec`
+
+.exercise[
+
+- Try to show the logs of a kube-router pod:
+  ```bash
+  kubectl -n kube-system logs ds/kube-router
+  ```
+
+- Or try to exec into one of the kube-router pods:
+  ```bash
+  kubectl -n kube-system exec kuber-router-xxxxx bash
+  ```
+
+]
+
+These commands will give an error message that includes:
+```
+dial tcp: lookup kuberouterX on 127.0.0.11:53: no such host
+```
+
+What does that mean?
+
+---
+
+## Internal name resolution
+
+- To execute these commands, the API server needs to connect to kubelet
+
+- By default, it creates a connection using the kubelet's name
+
+  (e.g. `http://kuberouter1:...`)
+
+- This requires our nodes names to be in DNS
+
+- We can change that by setting a flag on the API server:
+
+  `--kubelet-preferred-address-types=InternalIP`
+
+---
+
+## Another way to check the logs
+
+- We can also ask the logs directly to the container engine
+
+- First, get the container ID, with `docker ps` or like this:
+  ```bash
+  CID=$(docker ps
+        --filter label=io.kubernetes.pod.namespace=kube-system
+        --filter label=io.kubernetes.container.name=kube-router)
+  ```
+
+- Then view the logs:
+  ```bash
+  docker logs $CID
+  ```
+
+---
+
+class: extra-details
+
+## Other ways to distribute routing tables
+
+- We don't need kube-router and BGP to distribute routes
+
+- The list of nodes (and associated `podCIDR` subnets) is available through the API
+
+- This shell snippet generates the commands to add all required routes on a node:
+
+```bash
+NODES=$(kubectl get nodes -o name | cut -d/ -f2)
+for DESTNODE in $NODES; do
+  if [ "$DESTNODE" != "$HOSTNAME" ]; then
+    echo $(kubectl get node $DESTNODE -o go-template="
+      route add -net {{.spec.podCIDR}} gw {{(index .status.addresses 0).address}}")
+  fi
+done
+```
+
+- This could be useful for embedded platforms with very limited resources
+
+  (or lab environments for learning purposes)
+
+---
+
+# Interconnecting clusters
+
+- We assigned different Cluster CIDRs to each cluster
+
+- This allows us to connect our clusters together
+
+- We will leverage kube-router BGP abilities for that
+
+- We will *peer* each kube-router instance with a *route reflector*
+
+- As a result, we will be able to ping each other's pods
+
+---
+
+## Disclaimers
+
+- There are many methods to interconnect clusters
+
+- Depending on your network implementation, you will use different methods
+
+- The method shown here only works for nodes with direct layer 2 connection
+
+- We will often need to use tunnels or other network techniques
+
+---
+
+## The plan
+
+- Someone will start the *route reflector*
+
+  (typically, that will be the person presenting these slides!)
+
+- We will update our kube-router configuration
+
+- We will add a *peering* with the route reflector
+
+  (instructing kube-router to connect to it and exchange route information)
+
+- We should see the routes to other clusters on our nodes
+
+  (in the output of e.g. `route -n` or `ip route show`)
+
+- We should be able to ping pods of other nodes
+
+---
+
+## Starting the route reflector
+
+- Only do this if you are doing this on your own
+
+- There is a Compose file in the `compose/frr-route-reflector` directory
+
+- Before continuing, make sure that you have the IP address of the route reflector
+
+---
+
+## Configuring kube-router
+
+- This can be done in two ways:
+
+  - with command-line flags to the `kube-router` process
+
+  - with annotations to Node objects
+
+- We will use the command-line flags
+
+  (because it will automatically propagate to all nodes)
+
+.footnote[Note: with Calico, this is achieved by creating a BGPPeer CRD.]
+
+---
+
+## Updating kube-router configuration
+
+- We need to add two command-line flags to the kube-router process
+
+.exercise[
+
+- Edit the `kuberouter.yaml` file
+
+- Add the following flags to the kube-router arguments,:
+  ```
+  - "--peer-router-ips=`X.X.X.X`"
+  - "--peer-router-asns=64512"
+  ```
+  (Replace `X.X.X.X` with the route reflector address)
+
+- Update the DaemonSet definition:
+  ```bash
+  kubectl apply -f kuberouter.yaml
+  ```
+
+]
+
+---
+
+## Restarting kube-router
+
+- The DaemonSet will not update the pods automatically
+
+  (it is using the default `updateStrategy`, which is `OnDelete`)
+
+- We will therefore delete the pods
+
+  (they will be recreated with the updated definition)
+
+.exercise[
+
+- Delete all the kube-router pods:
+  ```bash
+  kubectl delete pods -n kube-system -l k8s-app=kube-router
+  ```
+
+]
+
+Note: the other `updateStrategy` for a DaemonSet is RollingUpdate.
+<br/>
+For critical services, we might want to precisely control the update process.
+
+---
+
+## Checking peering status
+
+- We can see informative messages in the output of kube-router:
+  ```
+  time="2019-04-07T15:53:56Z" level=info msg="Peer Up"
+  Key=X.X.X.X State=BGP_FSM_OPENCONFIRM Topic=Peer
+  ```
+
+- We should see the routes of the other clusters show up
+
+- For debugging purposes, the reflector also exports a route to 1.0.0.2/32
+
+- That route will show up like this:
+  ```
+  1.0.0.2     172.31.X.Y    255.255.255.255 UGH   0      0        0 eth0
+  ```
+
+- We should be able to ping the pods of other clusters!
+
+---
+
+## If we wanted to do more ...
+
+- kube-router can also export ClusterIP addresses
+
+  (by adding the flag `--advertise-cluster-ip`)
+
+- They are exported individually (as /32)
+
+- This would allow us to easily access other clusters' services
+
+  (without having to resolve the individual addresses of pods)
+
+- Even better if it's combined with DNS integration
+
+  (to facilitate name → ClusterIP resolution)

slides/k8s/concepts-k8s.md

@@ -130,6 +130,14 @@ class: pic
 
 ---
 
+class: pic
+
+![One of the best Kubernetes architecture diagrams available](images/k8s-arch4-thanks-luxas.png)
+
+---
+
+class: extra-details
+
 ## Running the control plane on special nodes
 
 - It is common to reserve a dedicated node for the control plane
@@ -152,6 +160,8 @@ class: pic
 
 ---
 
+class: extra-details
+
 ## Running the control plane outside containers
 
 - The services of the control plane can run in or out of containers
@@ -171,6 +181,8 @@ class: pic
 
 ---
 
+class: extra-details
+
 ## Do we need to run Docker at all?
 
 No!
@@ -187,6 +199,8 @@ No!
 
 ---
 
+class: extra-details
+
 ## Do we need to run Docker at all?
 
 Yes!
@@ -209,6 +223,8 @@ Yes!
 
 ---
 
+class: extra-details
+
 ## Do we need to run Docker at all?
 
 - On our development environments, CI pipelines ... :
@@ -225,25 +241,21 @@ Yes!
 
 ---
 
-## Kubernetes resources
+## Interacting with Kubernetes
 
-- The Kubernetes API defines a lot of objects called *resources*
+- We will interact with our Kubernetes cluster through the Kubernetes API
 
-- These resources are organized by type, or `Kind` (in the API)
+- The Kubernetes API is (mostly) RESTful
+
+- It allows us to create, read, update, delete *resources*
 
 - A few common resource types are:
 
   - node (a machine — physical or virtual — in our cluster)
+
   - pod (group of containers running together on a node)
+
   - service (stable network endpoint to connect to one or multiple containers)
-  - namespace (more-or-less isolated group of things)
-  - secret (bundle of sensitive data to be passed to a container)
- 
-  And much more!
-
-- We can see the full list by running `kubectl api-resources`
-
-  (In Kubernetes 1.10 and prior, the command to list API resources was `kubectl get`)
 
 ---
 
@@ -253,22 +265,16 @@ class: pic
 
 ---
 
-class: pic
-
-![One of the best Kubernetes architecture diagrams available](images/k8s-arch4-thanks-luxas.png)
-
----
-
 ## Credits
 
-- The first diagram is courtesy of Weave Works
+- The first diagram is courtesy of Lucas Käldström, in [this presentation](https://speakerdeck.com/luxas/kubeadm-cluster-creation-internals-from-self-hosting-to-upgradability-and-ha)
+
+  - it's one of the best Kubernetes architecture diagrams available!
+
+- The second diagram is courtesy of Weave Works
 
   - a *pod* can have multiple containers working together
 
   - IP addresses are associated with *pods*, not with individual containers
 
-- The second diagram is courtesy of Lucas Käldström, in [this presentation](https://speakerdeck.com/luxas/kubeadm-cluster-creation-internals-from-self-hosting-to-upgradability-and-ha)
-
-  - it's one of the best Kubernetes architecture diagrams available!
-
 Both diagrams used with permission.

slides/k8s/daemonset.md

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

slides/k8s/dashboard.md

@@ -2,88 +2,60 @@
 
 - Kubernetes resources can also be viewed with a web dashboard
 
-- We are going to deploy that dashboard with *three commands:*
+- That dashboard is usually exposed over HTTPS
 
-  1) actually *run* the dashboard
+  (this requires obtaining a proper TLS certificate)
 
-  2) bypass SSL for the dashboard
+- Dashboard users need to authenticate
 
-  3) bypass authentication for the dashboard
+- We are going to take a *dangerous* shortcut
 
---
+---
 
-There is an additional step to make the dashboard available from outside (we'll get to that)
+## The insecure method
 
---
+- We could (and should) use [Let's Encrypt](https://letsencrypt.org/) ...
+
+- ... but we don't want to deal with TLS certificates
+
+- We could (and should) learn how authentication and authorization work ...
+
+- ... but we will use a guest account with admin access instead
 
 .footnote[.warning[Yes, this will open our cluster to all kinds of shenanigans. Don't do this at home.]]
 
 ---
 
-## 1) Running the dashboard
+## Running a very insecure dashboard
 
-- We need to create a *deployment* and a *service* for the dashboard
+- We are going to deploy that dashboard with *one single command*
 
-- But also a *secret*, a *service account*, a *role* and a *role binding*
+- This command will create all the necessary resources
 
-- All these things can be defined in a YAML file and created with `kubectl apply -f`
+  (the dashboard itself, the HTTP wrapper, the admin/guest account)
+
+- All these resources are defined in a YAML file
+
+- All we have to do is load that YAML file with with `kubectl apply -f`
 
 .exercise[
 
 - Create all the dashboard resources, with the following command:
   ```bash
-  kubectl apply -f ~/container.training/k8s/kubernetes-dashboard.yaml
+  kubectl apply -f ~/container.training/k8s/insecure-dashboard.yaml
   ```
 
 ]
 
 ---
 
-
-## 2) Bypassing SSL for the dashboard
-
-- The Kubernetes dashboard uses HTTPS, but we don't have a certificate
-
-- Recent versions of Chrome (63 and later) and Edge will refuse to connect
-
-  (You won't even get the option to ignore a security warning!)
-
-- We could (and should!) get a certificate, e.g. with [Let's Encrypt](https://letsencrypt.org/)
-
-- ... But for convenience, for this workshop, we'll forward HTTP to HTTPS
-
-.warning[Do not do this at home, or even worse, at work!]
-
----
-
-## Running the SSL unwrapper
-
-- We are going to run [`socat`](http://www.dest-unreach.org/socat/doc/socat.html), telling it to accept TCP connections and relay them over SSL
-
-- Then we will expose that `socat` instance with a `NodePort` service
-
-- For convenience, these steps are neatly encapsulated into another YAML file
-
-.exercise[
-
-- Apply the convenient YAML file, and defeat SSL protection:
-  ```bash
-  kubectl apply -f ~/container.training/k8s/socat.yaml
-  ```
-
-]
-
-.warning[All our dashboard traffic is now clear-text, including passwords!]
-
----
-
 ## Connecting to the dashboard
 
 .exercise[
 
 - Check which port the dashboard is on:
   ```bash
-  kubectl -n kube-system get svc socat
+  kubectl get svc dashboard
   ```
 
 ]
@@ -113,26 +85,7 @@ The dashboard will then ask you which authentication you want to use.
 
   - "skip" (use the dashboard "service account")
 
-- Let's use "skip": we get a bunch of warnings and don't see much
-
----
-
-## 3) Bypass authentication for the dashboard
-
-- The dashboard documentation [explains how to do this](https://github.com/kubernetes/dashboard/wiki/Access-control#admin-privileges)
-
-- We just need to load another YAML file!
-
-.exercise[
-
-- Grant admin privileges to the dashboard so we can see our resources:
-  ```bash
-  kubectl apply -f ~/container.training/k8s/grant-admin-to-dashboard.yaml
-  ```
-
-- Reload the dashboard and enjoy!
-
-]
+- Let's use "skip": we're logged in!
 
 --
 
@@ -140,73 +93,11 @@ The dashboard will then ask you which authentication you want to use.
 
 ---
 
-## Exposing the dashboard over HTTPS
-
-- We took a shortcut by forwarding HTTP to HTTPS inside the cluster
-
-- Let's expose the dashboard over HTTPS!
-
-- The dashboard is exposed through a `ClusterIP` service (internal traffic only)
-
-- We will change that into a `NodePort` service (accepting outside traffic)
-
-.exercise[
-
-- Edit the service:
-  ```
-  kubectl edit service kubernetes-dashboard
-  ```
-
-]
-
---
-
-`NotFound`?!? Y U NO WORK?!?
-
----
-
-## Editing the `kubernetes-dashboard` service
-
-- If we look at the [YAML](https://github.com/jpetazzo/container.training/blob/master/k8s/kubernetes-dashboard.yaml) that we loaded before, we'll get a hint
-
---
-
-- The dashboard was created in the `kube-system` namespace
-
---
-
-.exercise[
-
-- Edit the service:
-  ```bash
-  kubectl -n kube-system edit service kubernetes-dashboard
-  ```
-
-- Change type `type:` from `ClusterIP` to `NodePort`, save, and exit
-
-<!--
-```wait Please edit the object below```
-```keys /ClusterIP```
-```keys ^J```
-```keys cwNodePort```
-```keys ^[ ``` ]
-```keys :wq```
-```keys ^J```
--->
-
-- Check the port that was assigned with `kubectl -n kube-system get services`
-
-- Connect to https://oneofournodes:3xxxx/ (yes, https)
-
-]
-
----
-
 ## Running the Kubernetes dashboard securely
 
 - The steps that we just showed you are *for educational purposes only!*
 
-- If you do that on your production cluster, people [can and will abuse it](https://blog.redlock.io/cryptojacking-tesla)
+- If you do that on your production cluster, people [can and will abuse it](https://redlock.io/blog/cryptojacking-tesla)
 
 - For an in-depth discussion about securing the dashboard,
   <br/>

slides/k8s/declarative.md

@@ -1,6 +1,20 @@
 ## Declarative vs imperative in Kubernetes
 
-- Virtually everything we create in Kubernetes is created from a *spec*
+- With Kubernetes, we cannot say: "run this container"
+
+- All we can do is write a *spec* and push it to the API server
+
+  (by creating a resource like e.g. a Pod or a Deployment)
+
+- The API server will validate that spec (and reject it if it's invalid)
+
+- Then it will store it in etcd
+
+- A *controller* will "notice" that spec and act upon it
+
+---
+
+## Reconciling state
 
 - Watch for the `spec` fields in the YAML files later!
 

slides/k8s/dmuc.md

@@ -0,0 +1,837 @@
+# Building our own cluster
+
+- Let's build our own cluster!
+
+  *Perfection is attained not when there is nothing left to add, but when there is nothing left to take away. (Antoine de Saint-Exupery)*
+
+- Our goal is to build a minimal cluster allowing us to:
+
+  - create a Deployment (with `kubectl run` or `kubectl create deployment`)
+  - expose it with a Service
+  - connect to that service
+
+
+- "Minimal" here means:
+
+  - smaller number of components
+  - smaller number of command-line flags
+  - smaller number of configuration files
+
+---
+
+## Non-goals
+
+- For now, we don't care about security
+
+- For now, we don't care about scalability
+
+- For now, we don't care about high availability
+
+- All we care about is *simplicity*
+
+---
+
+## Our environment
+
+- We will use the machine indicated as `dmuc1`
+
+  (this stands for "Dessine Moi Un Cluster" or "Draw Me A Sheep",
+  <br/>in homage to Saint-Exupery's "The Little Prince")
+
+- This machine:
+
+  - runs Ubuntu LTS
+
+  - has Kubernetes, Docker, and etcd binaries installed
+
+  - but nothing is running
+
+---
+
+## Checking our environment
+
+- Let's make sure we have everything we need first
+
+.exercise[
+
+- Log into the `dmuc1` machine
+
+- Get root:
+  ```bash
+  sudo -i
+  ```
+
+- Check available versions:
+  ```bash
+  etcd -version
+  kube-apiserver --version
+  dockerd --version
+  ```
+
+]
+
+---
+
+## The plan
+
+1. Start API server
+
+2. Interact with it (create Deployment and Service)
+
+3. See what's broken
+
+4. Fix it and go back to step 2 until it works!
+
+---
+
+## Dealing with multiple processes
+
+- We are going to start many processes
+
+- Depending on what you're comfortable with, you can:
+
+  - open multiple windows and multiple SSH connections
+
+  - use a terminal multiplexer like screen or tmux
+
+  - put processes in the background with `&`
+    <br/>(warning: log output might get confusing to read!)
+
+---
+
+## Starting API server
+
+.exercise[
+
+- Try to start the API server:
+  ```bash
+  kube-apiserver
+  # It will fail with "--etcd-servers must be specified"
+  ```
+
+]
+
+Since the API server stores everything in etcd,
+it cannot start without it.
+
+---
+
+## Starting etcd
+
+.exercise[
+
+- Try to start etcd:
+  ```bash
+  etcd
+  ```
+
+]
+
+Success!
+
+Note the last line of output:
+```
+serving insecure client requests on 127.0.0.1:2379, this is strongly discouraged!
+```
+
+*Sure, that's discouraged. But thanks for telling us the address!*
+
+---
+
+## Starting API server (for real)
+
+- Try again, passing the `--etcd-servers` argument
+
+- That argument should be a comma-separated list of URLs
+
+.exercise[
+
+- Start API server:
+  ```bash
+  kube-apiserver --etcd-servers http://127.0.0.1:2379
+  ```
+
+]
+
+Success!
+
+---
+
+## Interacting with API server
+
+- Let's try a few "classic" commands
+
+.exercise[
+
+- List nodes:
+  ```bash
+  kubectl get nodes
+  ```
+
+- List services:
+  ```bash
+  kubectl get services
+  ```
+
+]
+
+So far, so good.
+
+Note: the API server automatically created the `kubernetes` service entry.
+
+---
+
+class: extra-details
+
+## What about `kubeconfig`?
+
+- We didn't need to create a `kubeconfig` file
+
+- By default, the API server is listening on `localhost:8080`
+
+  (without requiring authentication)
+
+- By default, `kubectl` connects to `localhost:8080`
+
+  (without providing authentication)
+
+---
+
+## Creating a Deployment
+
+- Let's run a web server!
+
+.exercise[
+
+- Create a Deployment with NGINX:
+  ```bash
+  kubectl create deployment web --image=nginx
+  ```
+
+]
+
+Success?
+
+---
+
+## Checking our Deployment status
+
+.exercise[
+
+- Look at pods, deployments, etc.:
+  ```bash
+  kubectl get all
+  ```
+
+]
+
+Our Deployment is in a bad shape:
+```
+NAME                  READY   UP-TO-DATE   AVAILABLE   AGE
+deployment.apps/web   0/1     0            0           2m26s
+```
+
+And, there is no ReplicaSet, and no Pod.
+
+---
+
+## What's going on?
+
+- We stored the definition of our Deployment in etcd
+
+  (through the API server)
+
+- But there is no *controller* to do the rest of the work
+
+- We need to start the *controller manager*
+
+---
+
+## Starting the controller manager
+
+.exercise[
+
+- Try to start the controller manager:
+  ```bash
+  kube-controller-manager
+  ```
+
+]
+
+The final error message is:
+```
+invalid configuration: no configuration has been provided
+```
+
+But the logs include another useful piece of information:
+```
+Neither --kubeconfig nor --master was specified.
+Using the inClusterConfig.  This might not work.
+```
+
+---
+
+## Reminder: everyone talks to API server
+
+- The controller manager needs to connect to the API server
+
+- It *does not* have a convenient `localhost:8080` default
+
+- We can pass the connection information in two ways:
+
+  - `--master` and a host:port combination (easy)
+
+  - `--kubeconfig` and a `kubeconfig` file
+
+- For simplicity, we'll use the first option
+
+---
+
+## Starting the controller manager (for real)
+
+.exercise[
+
+- Start the controller manager:
+  ```bash
+  kube-controller-manager --master http://localhost:8080
+  ```
+
+]
+
+Success!
+
+---
+
+## Checking our Deployment status
+
+.exercise[
+
+- Check all our resources again:
+  ```bash
+  kubectl get all
+  ```
+
+]
+
+We now have a ReplicaSet.
+
+But we still don't have a Pod.
+
+---
+
+## What's going on?
+
+In the controller manager logs, we should see something like this:
+```
+E0404 15:46:25.753376   22847 replica_set.go:450] Sync "default/web-5bc9bd5b8d"
+failed with `No API token found for service account "default"`, retry after the
+token is automatically created and added to the service account
+```
+
+- The service account `default` was automatically added to our Deployment
+
+  (and to its pods)
+
+- The service account `default` exists
+
+- But it doesn't have an associated token
+
+  (the token is a secret; creating it requires signature; therefore a CA)
+
+---
+
+## Solving the missing token issue
+
+There are many ways to solve that issue.
+
+We are going to list a few (to get an idea of what's happening behind the scenes).
+
+Of course, we don't need to perform *all* the solutions mentioned here.
+
+---
+
+## Option 1: disable service accounts
+
+- Restart the API server with
+  `--disable-admission-plugins=ServiceAccount`
+
+- The API server will no longer add a service account automatically
+
+- Our pods will be created without a service account
+
+---
+
+## Option 2: do not mount the (missing) token
+
+- Add `automountServiceAccountToken: false` to the Deployment spec
+
+  *or*
+
+- Add `automountServiceAccountToken: false` to the default ServiceAccount
+
+- The ReplicaSet controller will no longer create pods referencing the (missing) token
+
+.exercise[
+
+- Programmatically change the `default` ServiceAccount:
+  ```bash
+  kubectl patch sa default -p "automountServiceAccountToken: false"
+  ```
+
+]
+
+---
+
+## Option 3: set up service accounts properly
+
+- This is the most complex option!
+
+- Generate a key pair
+
+- Pass the private key to the controller manager
+
+  (to generate and sign tokens)
+
+- Pass the public key to the API server
+
+  (to verify these tokens)
+
+---
+
+## Continuing without service account token
+
+- Once we patch the default service account, the ReplicaSet can create a Pod
+
+.exercise[
+
+- Check that we now have a pod:
+  ```bash
+  kubectl get all
+  ```
+
+]
+
+Note: we might have to wait a bit for the ReplicaSet controller to retry.
+
+If we're impatient, we can restart the controller manager.
+
+---
+
+## What's next?
+
+- Our pod exists, but it is in `Pending` state
+
+- Remember, we don't have a node so far
+
+  (`kubectl get nodes` shows an empty list)
+
+- We need to:
+
+  - start a container engine
+
+  - start kubelet
+
+---
+
+## Starting a container engine
+
+- We're going to use Docker (because it's the default option)
+
+.exercise[
+
+- Start the Docker Engine:
+  ```bash
+  dockerd
+  ```
+
+]
+
+Success!
+
+Feel free to check that it actually works with e.g.:
+```bash
+docker run alpine echo hello world
+```
+
+---
+
+## Starting kubelet
+
+- If we start kubelet without arguments, it *will* start
+
+- But it will not join the cluster!
+
+- It will start in *standalone* mode
+
+- Just like with the controller manager, we need to tell kubelet where the API server is
+
+- Alas, kubelet doesn't have a simple `--master` option
+
+- We have to use `--kubeconfig`
+
+- We need to write a `kubeconfig` file for kubelet
+
+---
+
+## Writing a kubeconfig file
+
+- We can copy/paste a bunch of YAML
+
+- Or we can generate the file with `kubectl`
+
+.exercise[
+
+- Create the file `kubeconfig.kubelet` with `kubectl`:
+  ```bash
+    kubectl --kubeconfig kubeconfig.kubelet config \
+            set-cluster localhost --server http://localhost:8080
+    kubectl --kubeconfig kubeconfig.kubelet config \
+            set-context localhost --cluster localhost
+    kubectl --kubeconfig kubeconfig.kubelet config \
+            use-context localhost
+  ```
+
+]
+
+---
+
+## All Kubernetes clients can use `kubeconfig`
+
+- The `kubeconfig.kubelet` file has the same format as e.g. `~/.kubeconfig`
+
+- All Kubernetes clients can use a similar file
+
+- The `kubectl config` commands can be used to manipulate these files
+
+- This highlights that kubelet is a "normal" client of the API server
+
+---
+
+## Our `kubeconfig.kubelet` file
+
+The file that we generated looks like the one below.
+
+That one has been slightly simplified (removing extraneous fields), but it is still valid.
+
+```yaml
+apiVersion: v1
+kind: Config
+current-context: localhost
+contexts:
+- name: localhost
+  context:
+    cluster: localhost
+clusters:
+- name: localhost
+  cluster:
+    server: http://localhost:8080
+```
+
+---
+
+## Starting kubelet
+
+.exercise[
+
+- Start kubelet with that `kubeconfig.kubelet` file:
+  ```bash
+  kubelet --kubeconfig kubeconfig.kubelet
+  ```
+
+]
+
+Success!
+
+---
+
+## Looking at our 1-node cluster
+
+- Let's check that our node registered correctly
+
+.exercise[
+
+- List the nodes in our cluster:
+  ```bash
+  kubectl get nodes
+  ```
+
+]
+
+Our node should show up.
+
+Its name will be its hostname (it should be `dmuc1`).
+
+---
+
+## Are we there yet?
+
+- Let's check if our pod is running
+
+.exercise[
+
+- List all resources:
+  ```bash
+  kubectl get all
+  ```
+
+]
+
+--
+
+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.)
+
+---
+
+## Scheduling our pod
+
+- Why do we need a scheduling decision, since we have only one node?
+
+- The node might be full, unavailable; the pod might have constraints ...
+
+- The easiest way to schedule our pod is to start the scheduler
+
+  (we could also schedule it manually)
+
+---
+
+## Starting the scheduler
+
+- The scheduler also needs to know how to connect to the API server
+
+- Just like for controller manager, we can use `--kubeconfig` or `--master`
+
+.exercise[
+
+- Start the scheduler:
+  ```bash
+  kube-scheduler --master http://localhost:8080
+  ```
+
+]
+
+- Our pod should now start correctly
+
+---
+
+## Checking the status of our pod
+
+- Our pod will go through a short `ContainerCreating` phase
+
+- Then it will be `Running`
+
+.exercise[
+
+- Check pod status:
+  ```bash
+  kubectl get pods
+  ```
+
+]
+
+Success!
+
+---
+
+class: extra-details
+
+## Scheduling a pod manually
+
+- We can schedule a pod in `Pending` state by creating a Binding, e.g.:
+  ```bash
+    kubectl create -f- <<EOF
+    apiVersion: v1
+    kind: Binding
+    metadata:
+      name: name-of-the-pod
+    target:
+      apiVersion: v1
+      kind: Node
+      name: name-of-the-node
+    EOF
+  ```
+
+- This is actually how the scheduler works!
+
+- It watches pods, takes scheduling decisions, creates Binding objects
+
+---
+
+## Connecting to our pod
+
+- Let's check that our pod correctly runs NGINX
+
+.exercise[
+
+- Check our pod's IP address:
+  ```bash
+  kubectl get pods -o wide
+  ```
+
+- Send some HTTP request to the pod:
+  ```bash
+  curl `X.X.X.X`
+  ```
+
+]
+
+We should see the `Welcome to nginx!` page.
+
+---
+
+## Exposing our Deployment
+
+- We can now create a Service associated to this Deployment
+
+.exercise[
+
+- Expose the Deployment's port 80:
+  ```bash
+  kubectl expose deployment web --port=80
+  ```
+
+- Check the Service's ClusterIP, and try connecting:
+  ```bash
+  kubectl get service web
+  curl http://`X.X.X.X`
+  ```
+
+]
+
+--
+
+This won't work. We need kube-proxy to enable internal communication.
+
+---
+
+## Starting kube-proxy
+
+- kube-proxy also needs to connect to API server
+
+- It can work with the `--master` flag
+
+  (even though that will be deprecated in the future)
+
+.exercise[
+
+- Start kube-proxy:
+  ```bash
+  kube-proxy --master http://localhost:8080
+  ```
+
+]
+
+---
+
+## Connecting to our Service
+
+- Now that kube-proxy is running, we should be able to connect
+
+.exercise[
+
+- Check the Service's ClusterIP again, and retry connecting:
+  ```bash
+  kubectl get service web
+  curl http://`X.X.X.X`
+  ```
+
+]
+
+Success!
+
+---
+
+class: extra-details
+
+## How kube-proxy works
+
+- kube-proxy watches Service resources
+
+- When a Service is created or updated, kube-proxy creates iptables rules
+
+.exercise[
+
+- Check out the `OUTPUT` chain in the `nat` table:
+  ```bash
+  iptables -t nat -L OUTPUT
+  ```
+
+- Traffic is sent to `KUBE-SERVICES`; check that too:
+  ```bash
+  iptables -t nat -L KUBE-SERVICES
+  ```
+
+]
+
+For each Service, there is an entry in that chain.
+
+---
+
+class: extra-details
+
+## Diving into iptables
+
+- The last command showed a chain named `KUBE-SVC-...` corresponding to our service
+
+.exercise[
+
+- Check that `KUBE-SVC-...` chain:
+  ```bash
+  iptables -t nat -L `KUBE-SVC-...`
+  ```
+
+- It should show a jump to a `KUBE-SEP-...` chains; check it out too:
+  ```bash
+  iptables -t nat -L `KUBE-SEP-...`
+  ```
+
+]
+
+This is a `DNAT` rule to rewrite the destination address of the connection to our pod.
+
+This is how kube-proxy works!
+
+---
+
+class: extra-details
+
+## kube-router, IPVS
+
+- With recent versions of Kubernetes, it is possible to tell kube-proxy to use IPVS
+
+- IPVS is a more powerful load balancing framework
+
+  (remember: iptables was primarily designed for firewalling, not load balancing!)
+
+- It is also possible to replace kube-proxy with kube-router
+
+- kube-router uses IPVS by default
+
+- kube-router can also perform other functions
+
+  (e.g., we can use it as a CNI plugin to provide pod connectivity)
+
+---
+
+class: extra-details
+
+## What about the `kubernetes` service?
+
+- If we try to connect, it won't work
+
+  (by default, it should be `10.0.0.1`)
+
+- If we look at the Endpoints for this service, we will see one endpoint:
+
+  `host-address:6443`
+
+- 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)
+
+- ... And it expects to be listening on port 6443 with TLS

slides/k8s/extending-api.md

@@ -0,0 +1,216 @@
+# Extending the Kubernetes API
+
+There are multiple ways to extend the Kubernetes API.
+
+We are going to cover:
+
+- Custom Resource Definitions (CRDs)
+
+- Admission Webhooks
+
+---
+
+## Revisiting the API server
+
+- The Kubernetes API server is a central point of the control plane
+
+  (everything connects to it: controller manager, scheduler, kubelets)
+
+- Almost everything in Kubernetes is materialized by a resource
+
+- Resources have a type (or "kind")
+
+  (similar to strongly typed languages)
+
+- We can see existing types with `kubectl api-resources`
+
+- We can list resources of a given type with `kubectl get <type>`
+
+---
+
+## Creating new types
+
+- We can create new types with Custom Resource Definitions (CRDs)
+
+- CRDs are created dynamically
+
+  (without recompiling or restarting the API server)
+
+- CRDs themselves are resources:
+
+  - we can create a new type with `kubectl create` and some YAML
+
+  - we can see all our custom types with `kubectl get crds`
+
+- After we create a CRD, the new type works just like built-in types
+
+---
+
+## What can we do with CRDs?
+
+There are many possibilities!
+
+- *Operators* encapsulate complex sets of resources
+
+  (e.g.: a PostgreSQL replicated cluster; an etcd cluster...
+  <br/>
+  see [awesome operators](https://github.com/operator-framework/awesome-operators) and
+  [OperatorHub](https://operatorhub.io/) to find more)
+
+- Custom use-cases like [gitkube](https://gitkube.sh/)
+
+  - creates a new custom type, `Remote`, exposing a git+ssh server
+
+  - deploy by pushing YAML or Helm Charts to that remote
+
+- Replacing built-in types with CRDs
+
+  (see [this lightning talk by Tim Hockin](https://www.youtube.com/watch?v=ji0FWzFwNhA&index=2&list=PLj6h78yzYM2PZf9eA7bhWnIh_mK1vyOfU))
+
+---
+
+## Little details
+
+- By default, CRDs are not *validated*
+
+  (we can put anything we want in the `spec`)
+
+- When creating a CRD, we can pass an OpenAPI v3 schema (BETA!)
+
+  (which will then be used to validate resources)
+
+- Generally, when creating a CRD, we also want to run a *controller*
+
+  (otherwise nothing will happen when we create resources of that type) 
+
+- The controller will typically *watch* our custom resources
+
+  (and take action when they are created/updated)
+
+*Example: [YAML to install the gitkube CRD](https://storage.googleapis.com/gitkube/gitkube-setup-stable.yaml)*
+
+---
+
+## Service catalog
+
+- *Service catalog* is another extension mechanism
+
+- It's not extending the Kubernetes API strictly speaking
+
+  (but it still provides new features!)
+
+- It doesn't create new types; it uses:
+
+  - ClusterServiceBroker
+  - ClusterServiceClass
+  - ClusterServicePlan
+  - ServiceInstance
+  - ServiceBinding 
+
+- It uses the Open service broker API
+
+---
+
+## Admission controllers
+
+- When a Pod is created, it is associated to a ServiceAccount
+
+  (even if we did not specify one explicitly)
+
+- That ServiceAccount was added on the fly by an *admission controller*
+
+  (specifically, a *mutating admission controller*)
+
+- Admission controllers sit on the API request path
+
+  (see the cool diagram on next slide, courtesy of Banzai Cloud)
+
+---
+
+class: pic
+
+![API request lifecycle](images/api-request-lifecycle.png)
+
+---
+
+## Admission controllers
+
+- *Validating* admission controllers can accept/reject the API call
+
+- *Mutating* admission controllers can modify the API request payload
+
+- Both types can also trigger additional actions
+
+  (e.g. automatically create a Namespace if it doesn't exist)
+
+- There are a number of built-in admission controllers
+
+  (see [documentation](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/#what-does-each-admission-controller-do) for a list)
+
+- But we can also define our own!
+
+---
+
+## Admission Webhooks
+
+- We can setup *admission webhooks* to extend the behavior of the API server
+
+- The API server will submit incoming API requests to these webhooks
+
+- These webhooks can be *validating* or *mutating*
+
+- Webhooks can be setup dynamically (without restarting the API server)
+
+- To setup a dynamic admission webhook, we create a special resource:
+
+  a `ValidatingWebhookConfiguration` or a `MutatingWebhookConfiguration`
+
+- These resources are created and managed like other resources
+
+  (i.e. `kubectl create`, `kubectl get` ...)
+
+---
+
+## Webhook Configuration
+
+- A ValidatingWebhookConfiguration or MutatingWebhookConfiguration contains:
+
+  - the address of the webhook
+
+  - the authentication information to use with the webhook
+
+  - a list of rules
+
+- The rules indicate for which objects and actions the webhook is triggered
+
+  (to avoid e.g. triggering webhooks when setting up webhooks)
+
+---
+
+## (Ab)using the API server
+
+- If we need to store something "safely" (as in: in etcd), we can use CRDs
+
+- This gives us primitives to read/write/list objects (and optionally validate them)
+
+- The Kubernetes API server can run on its own
+
+  (without the scheduler, controller manager, and kubelets)
+
+- By loading CRDs, we can have it manage totally different objects
+
+  (unrelated to containers, clusters, etc.)
+
+---
+
+## Documentation
+
+- [Custom Resource Definitions: when to use them](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/)
+
+- [Custom Resources Definitions: how to use them](https://kubernetes.io/docs/tasks/access-kubernetes-api/custom-resources/custom-resource-definitions/)
+
+- [Service Catalog](https://kubernetes.io/docs/concepts/extend-kubernetes/service-catalog/)
+
+- [Built-in Admission Controllers](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/)
+
+- [Dynamic Admission Controllers](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/)

slides/k8s/gitworkflows.md

@@ -111,7 +111,7 @@
 
 - Display that key:
   ```
-  kubectl logs deployment flux | grep identity
+  kubectl logs deployment/flux | grep identity
   ```
 
 - Then add that key to the repository, giving it **write** access

slides/k8s/ingress.md

@@ -176,7 +176,7 @@
 
 - We are going to use a Daemon Set so that each node can accept connections
 
-- We will do two minor changes to the [YAML provided by Traefik](https://github.com/containous/traefik/blob/master/examples/k8s/traefik-ds.yaml):
+- We will do two minor changes to the [YAML provided by Traefik](https://github.com/containous/traefik/blob/v1.7/examples/k8s/traefik-ds.yaml):
 
   - enable `hostNetwork`
 
@@ -194,7 +194,7 @@
 
 - When deploying with `kubeadm`:
 
-  - a taint is placed on the node dedicated the control plane
+  - a taint is placed on the node dedicated to the control plane
 
   - the pods running the control plane have a matching toleration
 
@@ -306,9 +306,9 @@ This one is a special case that means "ignore all taints and run anyway."
 
 - We provide a YAML file (`k8s/traefik.yaml`) which is essentially the sum of:
 
-  - [Traefik's Daemon Set resources](https://github.com/containous/traefik/blob/master/examples/k8s/traefik-ds.yaml) (patched with `hostNetwork` and tolerations)
+  - [Traefik's Daemon Set resources](https://github.com/containous/traefik/blob/v1.7/examples/k8s/traefik-ds.yaml) (patched with `hostNetwork` and tolerations)
 
-  - [Traefik's RBAC rules](https://github.com/containous/traefik/blob/master/examples/k8s/traefik-rbac.yaml) allowing it to watch necessary API objects
+  - [Traefik's RBAC rules](https://github.com/containous/traefik/blob/v1.7/examples/k8s/traefik-rbac.yaml) allowing it to watch necessary API objects
 
 .exercise[
 
@@ -364,6 +364,8 @@ This is normal: we haven't provided any ingress rule yet.
 
 - Go to `http://node1:8080` (replacing `node1` with its IP address)
 
+<!-- ```open http://node1:8080``` -->
+
 ]
 
 ---

slides/k8s/kubectlget.md

@@ -79,26 +79,106 @@
 
 ---
 
-## What's available?
+class: extra-details
 
-- `kubectl` has pretty good introspection facilities
+## Exploring types and definitions
 
 - We can list all available resource types by running `kubectl api-resources`
   <br/>
   (In Kubernetes 1.10 and prior, this command used to be `kubectl get`)
 
-- We can view details about a resource with:
-  ```bash
-  kubectl describe type/name
-  kubectl describe type name
-  ```
-
 - We can view the definition for a resource type with:
   ```bash
   kubectl explain type
   ```
 
-Each time, `type` can be singular, plural, or abbreviated type name.
+- We can view the definition of a field in a resource, for instance:
+  ```bash
+  kubectl explain node.spec
+  ```
+
+- Or get the full definition of all fields and sub-fields:
+  ```bash
+  kubectl explain node --recursive
+  ```
+
+---
+
+class: extra-details
+
+## Introspection vs. documentation
+
+- We can access the same information by reading the [API documentation](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.14/)
+
+- The API documentation is usually easier to read, but:
+
+  - it won't show custom types (like Custom Resource Definitions)
+
+  - we need to make sure that we look at the correct version
+
+- `kubectl api-resources` and `kubectl explain` perform *introspection*
+
+  (they communicate with the API server and obtain the exact type definitions)
+
+---
+
+## Type names
+
+- The most common resource names have three forms:
+
+  - singular (e.g. `node`, `service`, `deployment`)
+
+  - plural (e.g. `nodes`, `services`, `deployments`)
+
+  - short (e.g. `no`, `svc`, `deploy`)
+
+- Some resources do not have a short names
+
+- `Endpoints` only have a plural form
+
+  (because even a single `Endpoints` resource is actually a list of endpoints)
+
+---
+
+## Viewing details
+
+- We can use `kubectl get -o yaml` to see all available details
+
+- However, YAML output is often simultaneously too much and not enough
+
+- For instance, `kubectl get node node1 -o yaml` is:
+
+  - too much information (e.g.: list of images available on this node)
+
+  - not enough information (e.g.: doesn't show pods running on this node)
+
+  - difficult to read for a human operator
+
+- For a comprehensive overview, we can use `kubectl describe` instead
+
+---
+
+## `kubectl describe`
+
+- `kubectl describe` needs a resource type and (optionally) a resource name
+
+- It is possible to provide a resource name *prefix*
+
+  (all matching objects will be displayed)
+
+- `kubectl describe` will retrieve some extra information about the resource
+
+.exercise[
+
+- Look at the information available for `node1` with one of the following commands:
+  ```bash
+  kubectl describe node/node1
+  kubectl describe node node1
+  ```
+
+]
+
+(We should notice a bunch of control plane pods.)
 
 ---
 
@@ -170,7 +250,7 @@ The error that we see is expected: the Kubernetes API requires authentication.
 
 --
 
-*These are not the pods you're looking for.* But where are they?!?
+*Where are the pods that we saw just a moment earlier?!?*
 
 ---
 
@@ -193,28 +273,33 @@ The error that we see is expected: the Kubernetes API requires authentication.
 
 *You know what ... This `kube-system` thing looks suspicious.*
 
+*In fact, I'm pretty sure it showed up earlier, when we did:*
+
+`kubectl describe node node1`
+
 ---
 
 ## Accessing namespaces
 
 - By default, `kubectl` uses the `default` namespace
 
-- We can switch to a different namespace with the `-n` option
+- We can see resources in all namespaces with `--all-namespaces`
 
 .exercise[
 
-- List the pods in the `kube-system` namespace:
+- List the pods in all namespaces:
   ```bash
-  kubectl -n kube-system get pods
+  kubectl get pods --all-namespaces
+  ```
+
+- Since Kubernetes 1.14, we can also use `-A` as a shorter version:
+  ```bash
+  kubectl get pods -A
   ```
 
 ]
 
---
-
-*Ding ding ding ding ding!*
-
-The `kube-system` namespace is used for the control plane.
+*Here are our system pods!*
 
 ---
 
@@ -224,7 +309,7 @@ The `kube-system` namespace is used for the control plane.
 
 - `kube-apiserver` is the API server
 
-- `kube-controller-manager` and `kube-scheduler` are other master components
+- `kube-controller-manager` and `kube-scheduler` are other control plane components
 
 - `coredns` provides DNS-based service discovery ([replacing kube-dns as of 1.11](https://kubernetes.io/blog/2018/07/10/coredns-ga-for-kubernetes-cluster-dns/))
 
@@ -234,12 +319,46 @@ The `kube-system` namespace is used for the control plane.
 
 - the `READY` column indicates the number of containers in each pod
 
-- the pods with a name ending with `-node1` are the master components
-  <br/>
-  (they have been specifically "pinned" to the master node)
+  (1 for most pods, but `weave` has 2, for instance)
 
 ---
 
+## Scoping another namespace
+
+- We can also look at a different namespace (other than `default`)
+
+.exercise[
+
+- List only the pods in the `kube-system` namespace:
+  ```bash
+  kubectl get pods --namespace=kube-system
+  kubectl get pods -n kube-system
+  ```
+
+]
+
+---
+
+## Namespaces and other `kubectl` commands
+
+- We can use `-n`/`--namespace` with almost every `kubectl` command
+
+- Example:
+
+  - `kubectl create --namespace=X` to create something in namespace X
+
+- We can use `-A`/`--all-namespaces` with most commands that manipulate multiple objects
+
+- Examples:
+
+  - `kubectl delete` can delete resources across multiple namespaces
+
+  - `kubectl label` can add/remove/update labels across multiple namespaces
+
+---
+
+class: extra-details
+
 ## What about `kube-public`?
 
 .exercise[
@@ -251,20 +370,100 @@ The `kube-system` namespace is used for the control plane.
 
 ]
 
---
+Nothing!
 
-- Maybe it doesn't have pods, but what secrets is `kube-public` keeping?
+`kube-public` is created by kubeadm & [used for security bootstrapping](https://kubernetes.io/blog/2017/01/stronger-foundation-for-creating-and-managing-kubernetes-clusters).
 
---
+---
+
+class: extra-details
+
+## Exploring `kube-public`
+
+- The only interesting object in `kube-public` is a ConfigMap named `cluster-info`
 
 .exercise[
 
-- List the secrets in the `kube-public` namespace:
+- List ConfigMap objects:
   ```bash
-  kubectl -n kube-public get secrets
+  kubectl -n kube-public get configmaps
+  ```
+
+- Inspect `cluster-info`:
+  ```bash
+  kubectl -n kube-public get configmap cluster-info -o yaml
   ```
 
 ]
---
 
-- `kube-public` is created by kubeadm & [used for security bootstrapping](https://kubernetes.io/blog/2017/01/stronger-foundation-for-creating-and-managing-kubernetes-clusters)
+Note the `selfLink` URI: `/api/v1/namespaces/kube-public/configmaps/cluster-info`
+
+We can use that!
+
+---
+
+class: extra-details
+
+## Accessing `cluster-info`
+
+- Earlier, when trying to access the API server, we got a `Forbidden` message
+
+- But `cluster-info` is readable by everyone (even without authentication)
+
+.exercise[
+
+- Retrieve `cluster-info`:
+  ```bash
+  curl -k https://10.96.0.1/api/v1/namespaces/kube-public/configmaps/cluster-info
+  ```
+
+]
+
+- We were able to access `cluster-info` (without auth)
+
+- It contains a `kubeconfig` file
+
+---
+
+class: extra-details
+
+## Retrieving `kubeconfig`
+
+- We can easily extract the `kubeconfig` file from this ConfigMap
+
+.exercise[
+
+- Display the content of `kubeconfig`:
+  ```bash
+    curl -sk https://10.96.0.1/api/v1/namespaces/kube-public/configmaps/cluster-info \
+         | jq -r .data.kubeconfig
+  ```
+
+]
+
+- This file holds the canonical address of the API server, and the public key of the CA
+
+- This file *does not* hold client keys or tokens
+
+- This is not sensitive information, but allows us to establish trust
+
+---
+
+class: extra-details
+
+## What about `kube-node-lease`?
+
+- Starting with Kubernetes 1.14, there is a `kube-node-lease` namespace
+
+  (or in Kubernetes 1.13 if the NodeLease feature gate is enabled)
+
+- That namespace contains one Lease object per node
+
+- *Node leases* are a new way to implement node heartbeats
+
+  (i.e. node regularly pinging the control plane to say "I'm alive!")
+
+- 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

slides/k8s/kubectlrun.md

@@ -170,12 +170,12 @@ pod/pingpong-7c8bbcd9bc-6c9qz   1/1       Running   0          10m
 
 - Scale our `pingpong` deployment:
   ```bash
-  kubectl scale deploy/pingpong --replicas 8
+  kubectl scale deploy/pingpong --replicas 3
   ```
 
 - Note that this command does exactly the same thing:
   ```bash
-  kubectl scale deployment pingpong --replicas 8
+  kubectl scale deployment pingpong --replicas 3
   ```
 
 ]
@@ -246,6 +246,9 @@ We could! But the *deployment* would notice it right away, and scale back to the
 
   - `kubectl create job` to create a job
 
+  - `kubectl create cronjob` to run a job periodically
+    <br/>(since Kubernetes 1.14)
+
 - Eventually, `kubectl run` will be used only to start one-shot pods
 
   (see https://github.com/kubernetes/kubernetes/pull/68132)
@@ -262,7 +265,7 @@ We could! But the *deployment* would notice it right away, and scale back to the
 - `kubectl create <resource>` 
 
   - explicit, but lacks some features
-  - can't create a CronJob
+  - can't create a CronJob before Kubernetes 1.14
   - can't pass command-line arguments to deployments
 
 - `kubectl create -f foo.yaml` or `kubectl apply -f foo.yaml`
@@ -291,9 +294,97 @@ We could! But the *deployment* would notice it right away, and scale back to the
 
 ]
 
-Unfortunately, `--follow` cannot (yet) be used to stream the logs from multiple containers.
-<br/>
-(But this will change in the future; see [PR #67573](https://github.com/kubernetes/kubernetes/pull/67573).)
+---
+
+### Streaming logs of multiple pods
+
+- Can we stream the logs of all our `pingpong` pods?
+
+.exercise[
+
+- Combine `-l` and `-f` flags:
+  ```bash
+  kubectl logs -l run=pingpong --tail 1 -f
+  ```
+
+<!--
+```wait seq=```
+```keys ^C```
+-->
+
+]
+
+*Note: combining `-l` and `-f` is only possible since Kubernetes 1.14!*
+
+*Let's try to understand why ...*
+
+---
+
+class: extra-details
+
+### Streaming logs of many pods
+
+- Let's see what happens if we try to stream the logs for more than 5 pods
+
+.exercise[
+
+- Scale up our deployment:
+  ```bash
+  kubectl scale deployment pingpong --replicas=8
+  ```
+
+- Stream the logs:
+  ```bash
+  kubectl logs -l run=pingpong --tail 1 -f
+  ```
+
+]
+
+We see a message like the following one:
+```
+error: you are attempting to follow 8 log streams,
+but maximum allowed concurency is 5,
+use --max-log-requests to increase the limit
+```
+
+---
+
+class: extra-details
+
+## Why can't we stream the logs of many pods?
+
+- `kubectl` opens one connection to the API server per pod
+
+- For each pod, the API server opens one extra connection to the corresponding kubelet
+
+- If there are 1000 pods in our deployment, that's 1000 inbound + 1000 outbound connections on the API server
+
+- This could easily put a lot of stress on the API server
+
+- Prior Kubernetes 1.14, it was decided to *not* allow multiple connections
+
+- From Kubernetes 1.14, it is allowed, but limited to 5 connections
+
+  (this can be changed with `--max-log-requests`)
+
+- For more details about the rationale, see
+  [PR #67573](https://github.com/kubernetes/kubernetes/pull/67573)
+
+---
+
+## Shortcomings of `kubectl logs`
+
+- We don't see which pod sent which log line
+
+- If pods are restarted / replaced, the log stream stops
+
+- If new pods are added, we don't see their logs
+
+- To stream the logs of multiple pods, we need to write a selector
+
+- There are external tools to address these shortcomings
+
+  (e.g.: [Stern](https://github.com/wercker/stern))
 
 ---
 

slides/k8s/kubenet.md

@@ -16,6 +16,8 @@
 
  - each pod is aware of its IP address (no NAT)
 
+ - pod IP addresses are assigned by the network implementation
+
 - Kubernetes doesn't mandate any particular implementation
 
 ---
@@ -30,7 +32,7 @@
 
 - No new protocol
 
-- Pods cannot move from a node to another and keep their IP address
+- The network implementation can decide how to allocate addresses
 
 - IP addresses don't have to be "portable" from a node to another
 
@@ -82,13 +84,17 @@
 
 ---
 
+class: extra-details
+
 ## The Container Network Interface (CNI)
 
-- The CNI has a well-defined [specification](https://github.com/containernetworking/cni/blob/master/SPEC.md#network-configuration) for network plugins
+- Most Kubernetes clusters use CNI "plugins" to implement networking
 
-- When a pod is created, Kubernetes delegates the network setup to CNI plugins
+- When a pod is created, Kubernetes delegates the network setup to these plugins
 
-- Typically, a CNI plugin will:
+  (in can be a single plugin, or a combination of plugins, each doing one task)
+
+- Typically, CNI plugins will:
 
   - allocate an IP address (by calling an IPAM plugin)
 
@@ -96,8 +102,46 @@
 
   - configure the interface as well as required routes etc.
 
-- Using multiple plugins can be done with "meta-plugins" like CNI-Genie or Multus
+---
 
-- Not all CNI plugins are equal
+class: extra-details
 
-  (e.g. they don't all implement network policies, which are required to isolate pods)
+## Multiple moving parts
+
+- The "pod-to-pod network" or "pod network":
+
+  - provides communication between pods and nodes
+
+  - is generally implemented with CNI plugins
+
+- The "pod-to-service network":
+
+  - provides internal communication and load balancing
+
+  - is generally implemented with kube-proxy (or e.g. kube-router)
+
+- Network policies:
+
+  - provide firewalling and isolation
+
+  - can be bundled with the "pod network" or provided by another component
+
+---
+
+class: extra-details
+
+## Even more moving parts
+
+- Inbound traffic can be handled by multiple components:
+
+  - something like kube-proxy or kube-router (for NodePort services)
+
+  - load balancers (ideally, connected to the pod network)
+
+- It is possible to use multiple pod networks in parallel
+
+  (with "meta-plugins" like CNI-Genie or Multus)
+
+- Some products can fill multiple roles
+
+  (e.g. kube-router can be set up to provide the pod network and/or network policies and/or replace kube-proxy)

slides/k8s/lastwords-admin.md

@@ -0,0 +1,210 @@
+# What's next?
+
+- Congratulations!
+
+- We learned a lot about Kubernetes, its internals, its advanced concepts
+
+--
+
+- That was just the easy part
+
+- The hard challenges will revolve around *culture* and *people*
+
+--
+
+- ... What does that mean?
+
+---
+
+## Running an app involves many steps
+
+- Write the app
+
+- Tests, QA ...
+
+- Ship *something* (more on that later)
+
+- Provision resources (e.g. VMs, clusters)
+
+- Deploy the *something* on the resources
+
+- Manage, maintain, monitor the resources
+
+- Manage, maintain, monitor the app
+
+- And much more
+
+---
+
+## Who does what?
+
+- The old "devs vs ops" division has changed
+
+- In some organizations, "ops" are now called "SRE" or "platform" teams
+
+  (and they have very different sets of skills)
+
+- Do you know which team is responsible for each item on the list on the previous page?
+
+- Acknowledge that a lot of tasks are outsourced
+
+  (e.g. if we add "buy / rack / provision machines" in that list)
+
+---
+
+## What do we ship?
+
+- Some organizations embrace "you build it, you run it"
+
+- When "build" and "run" are owned by different teams, where's the line?
+
+- What does the "build" team ship to the "run" team?
+
+- Let's see a few options, and what they imply
+
+---
+
+## Shipping code
+
+- Team "build" ships code
+
+  (hopefully in a repository, identified by a commit hash)
+
+- Team "run" containerizes that code
+
+✔️ no extra work for developers
+
+❌ very little advantage of using containers
+
+---
+
+## Shipping container images
+
+- Team "build" ships container images
+
+  (hopefully built automatically from a source repository)
+
+- Team "run" uses theses images to create e.g. Kubernetes resources
+
+✔️ universal artefact (support all languages uniformly)
+
+✔️ easy to start a single component (good for monoliths)
+
+❌ complex applications will require a lot of extra work
+
+❌ adding/removing components in the stack also requires extra work
+
+❌ complex applications will run very differently between dev and prod
+
+---
+
+## Shipping Compose files
+
+(Or another kind of dev-centric manifest)
+
+- Team "build" ships a manifest that works on a single node
+
+  (as well as images, or ways to build them)
+
+- Team "run" adapts that manifest to work on a cluster
+
+✔️ all teams can start the stack in a reliable, deterministic manner
+
+❌ adding/removing components still requires *some* work (but less than before)
+
+❌ there will be *some* differences between dev and prod
+
+---
+
+## Shipping Kubernetes manifests
+
+- Team "build" ships ready-to-run manifests
+
+  (YAML, Helm Charts, Kustomize ...)
+
+- Team "run" adjusts some parameters and monitors the application 
+
+✔️ parity between dev and prod environments
+
+✔️ "run" team can focus on SLAs, SLOs, and overall quality
+
+❌ requires *a lot* of extra work (and new skills) from the "build" team
+
+❌ Kubernetes is not a very convenient development platform (at least, not yet)
+
+---
+
+## What's the right answer?
+
+- It depends on our teams
+
+  - existing skills (do they know how to do it?)
+
+  - availability (do they have the time to do it?)
+
+  - potential skills (can they learn to do it?)
+
+- It depends on our culture
+
+  - owning "run" often implies being on call
+
+  - do we reward on-call duty without encouraging hero syndrome?
+
+  - do we give resources (time, money) to people to learn?
+
+---
+
+class: extra-details
+
+## Tools to develop on Kubernetes
+
+*If we decide to make Kubernetes the primary development platform, here
+are a few tools that can help us.*
+
+- Docker Desktop
+
+- Draft
+
+- Minikube
+
+- Skaffold
+
+- Tilt
+
+- ...
+
+---
+
+## Where do we run?
+
+- Managed vs. self-hosted
+
+- Cloud vs. on-premises
+
+- If cloud: public vs. private
+
+- Which vendor / distribution to pick?
+
+- Which versions / features to enable?
+
+---
+
+## Some guidelines
+
+- Start small
+
+- Outsource what we don't know
+
+- Start simple, and stay simple as long as possible
+
+  (try to stay away from complex features that we don't need)
+
+- Automate
+
+  (regularly check that we can successfully redeploy by following scripts)
+
+- Transfer knowledge
+
+  (make sure everyone is on the same page / same level)
+
+- Iterate!

slides/k8s/localkubeconfig.md

@@ -16,11 +16,11 @@
 
 - Download the `kubectl` binary from one of these links:
 
-  [Linux](https://storage.googleapis.com/kubernetes-release/release/v1.13.4/bin/linux/amd64/kubectl)
+  [Linux](https://storage.googleapis.com/kubernetes-release/release/v1.14.1/bin/linux/amd64/kubectl)
   |
-  [macOS](https://storage.googleapis.com/kubernetes-release/release/v1.13.4/bin/darwin/amd64/kubectl)
+  [macOS](https://storage.googleapis.com/kubernetes-release/release/v1.14.1/bin/darwin/amd64/kubectl)
   |
-  [Windows](https://storage.googleapis.com/kubernetes-release/release/v1.13.4/bin/windows/amd64/kubectl.exe)
+  [Windows](https://storage.googleapis.com/kubernetes-release/release/v1.14.1/bin/windows/amd64/kubectl.exe)
 
 - On Linux and macOS, make the binary executable with `chmod +x kubectl`
 
@@ -49,9 +49,9 @@ 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:"11", GitVersion:"v1.11.2",
-GitCommit:"bb9ffb1654d4a729bb4cec18ff088eacc153c239", GitTreeState:"clean",
-BuildDate:"2018-08-07T23:17:28Z", GoVersion:"go1.10.3", Compiler:"gc",
+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"}
 ```
 
@@ -107,7 +107,6 @@ Platform:"linux/amd64"}
 - To update the server address, run:
   ```bash
   kubectl config set-cluster kubernetes --server=https://`X.X.X.X`:6443
-  kubectl config set-cluster kubernetes --insecure-skip-tls-verify
   # Make sure to replace X.X.X.X with the IP address of node1!
   ```
 
@@ -115,7 +114,7 @@ Platform:"linux/amd64"}
 
 class: extra-details
 
-## Why do we skip TLS verification?
+## What if we get a certificate error?
 
 - Generally, the Kubernetes API uses a certificate that is valid for:
 
@@ -133,7 +132,20 @@ class: extra-details
 
 - ... And that external IP address was not used when creating the certificate!
 
-.warning[It's better to NOT skip TLS verification; this is for educational purposes only!]
+---
+
+class: extra-details
+
+## Working around the certificate error
+
+- We need to tell `kubectl` to skip TLS verification
+
+  (only do this with testing clusters, never in production!)
+
+- The following command will do the trick:
+  ```bash
+  kubectl config set-cluster kubernetes --insecure-skip-tls-verify
+  ```
 
 ---
 

slides/k8s/metrics-server.md

@@ -0,0 +1,66 @@
+# 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/)
+
+- The core metrics pipeline is:
+
+  - optional (Kubernetes can function without it)
+
+  - necessary for some features (like the Horizontal Pod Autoscaler)
+
+  - exposed through the Kubernetes API using the [aggregation layer](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)
+
+  - usually implemented by the "metrics server"
+
+---
+
+## How to know if the metrics server is running?
+
+- The easiest way to know is to run `kubectl top`
+
+.exercise[
+
+- Check if the core metrics pipeline is available:
+  ```bash
+  kubectl top nodes
+  ```
+
+]
+
+If it shows our nodes and their CPU and memory load, we're good!
+
+---
+
+## Installing metrics server
+
+- The metrics server doesn't have any particular requirements
+
+  (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])
+
+- The repository comes with [YAML files for deployment](https://github.com/kubernetes-incubator/metrics-server/tree/master/deploy/1.8%2B)
+
+- These files may not work on some clusters
+
+  (e.g. if your node names are not in DNS)
+
+- The container.training repository has a [metrics-server.yaml](https://github.com/jpetazzo/container.training/blob/master/k8s/metrics-server.yaml#L90) file to help with that
+
+  (we can `kubectl apply -f` that file if needed)
+
+---
+
+## Showing container resource usage
+
+- Once the metrics server is running, we can check container resource usage
+
+.exercise[
+
+- Show resource usage across all containers:
+  ```bash
+  kuebectl top pods --containers --all-namespaces
+  ```
+]
+
+- We can also use selectors (`-l app=...`)

slides/k8s/multinode.md

@@ -0,0 +1,513 @@
+# Adding nodes to the cluster
+
+- So far, our cluster has only 1 node
+
+- Let's see what it takes to add more nodes
+
+- We are going to use another set of machines: `kubenet`
+
+---
+
+## The environment
+
+- We have 3 identical machines: `kubenet1`, `kubenet2`, `kubenet3`
+
+- The Docker Engine is installed (and running) on these machines
+
+- The Kubernetes packages are installed, but nothing is running
+
+- We will use `kubenet1` to run the control plane
+
+---
+
+## The plan
+
+- Start the control plane on `kubenet1`
+
+- Join the 3 nodes to the cluster
+
+- Deploy and scale a simple web server
+
+.exercise[
+
+- Log into `kubenet1`
+
+]
+
+---
+
+## Running the control plane
+
+- We will use a Compose file to start the control plane components
+
+.exercise[
+
+- Clone the repository containing the workshop materials:
+  ```bash
+  git clone https://@@GITREPO@@
+  ```
+
+- Go to the `compose/simple-k8s-control-plane` directory:
+  ```bash
+  cd container.training/compose/simple-k8s-control-plane
+  ```
+
+- Start the control plane:
+  ```bash
+  docker-compose up
+  ```
+
+]
+
+---
+
+## Checking the control plane status
+
+- Before moving on, verify that the control plane works
+
+.exercise[
+
+- Show control plane component statuses:
+  ```bash
+  kubectl get componentstatuses
+  kubectl get cs
+  ```
+
+- Show the (empty) list of nodes:
+  ```bash
+  kubectl get nodes
+  ```
+
+]
+
+---
+
+class: extra-details
+
+## Differences from `dmuc`
+
+- Our new control plane listens on `0.0.0.0` instead of the default `127.0.0.1`
+
+- The ServiceAccount admission plugin is disabled
+
+---
+
+## Joining the nodes
+
+- We need to generate a `kubeconfig` file for kubelet
+
+- This time, we need to put the IP address of `kubenet1`
+
+  (instead of `localhost` or `127.0.0.1`)
+
+.exercise[
+
+- 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
+  ```
+
+]
+
+---
+
+## Distributing the `kubeconfig` file
+
+- We need that `kubeconfig` file on the other nodes, too
+
+.exercise[
+
+- Copy `kubeconfig` to the other nodes:
+  ```bash
+    for N in 2 3; do
+    	scp ~/kubeconfig kubenet$N:
+    done
+  ```
+
+]
+
+---
+
+## Starting kubelet
+
+- Reminder: kubelet needs to run as root; don't forget `sudo`!
+
+.exercise[
+
+- Join the first node:
+   ```bash
+   sudo kubelet --kubeconfig ~/kubeconfig
+   ```
+
+- Open more terminals and join the other nodes to the cluster:
+  ```bash
+  ssh kubenet2 sudo kubelet --kubeconfig ~/kubeconfig
+  ssh kubenet3 sudo kubelet --kubeconfig ~/kubeconfig
+  ```
+
+]
+
+---
+
+## Checking cluster status
+
+- We should now see all 3 nodes
+
+- At first, their `STATUS` will be `NotReady`
+
+- They will move to `Ready` state after approximately 10 seconds
+
+.exercise[
+
+- Check the list of nodes:
+  ```bash
+  kubectl get nodes
+  ```
+
+]
+
+---
+
+## Deploy a web server
+
+- Let's create a Deployment and scale it
+
+  (so that we have multiple pods on multiple nodes)
+
+.exercise[
+
+- Create a Deployment running NGINX:
+  ```bash
+  kubectl create deployment web --image=nginx
+  ```
+
+- Scale it:
+  ```bash
+  kubectl scale deployment web --replicas=5
+  ```
+
+]
+
+---
+
+## Check our pods
+
+- The pods will be scheduled to the nodes
+
+- The nodes will pull the `nginx` image, and start the pods
+
+- What are the IP addresses of our pods?
+
+.exercise[
+
+- Check the IP addresses of our pods
+  ```bash
+  kubectl get pods -o wide
+  ```
+
+]
+
+--
+
+🤔 Something's not right ... Some pods have the same IP address!
+
+---
+
+## What's going on?
+
+- On a normal cluster, kubelet is configured to set up pod networking with CNI plugins
+
+- This requires:
+
+  - installing CNI plugins
+
+  - writing CNI configuration files
+
+  - running kubelet with `--network-plugin=cni`
+
+- Without the `--network-plugin` flag, kubelet defaults to "no-op" networking
+
+- It lets the container engine use a default network
+
+  (in that case, we end up with the default Docker bridge)
+
+- Our pods are running on independent, disconnected, host-local networks
+
+---
+
+## Using network plugins
+
+- We need to set up a better network
+
+- Before diving into CNI, we will use the `kubenet` plugin
+
+- This plugin creates a `cbr0` bridge and connects the containers to that bridge
+
+- This plugin allocates IP addresses from a range:
+
+  - either specified to kubelet (e.g. with `--pod-cidr`)
+
+  - or stored in the node's `spec.podCIDR` field
+
+.footnote[See [here] for more details about this `kubenet` plugin.]
+
+[here]: https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#kubenet
+
+---
+
+## What `kubenet` does and *does not* do
+
+- It allocates IP addresses to pods *locally*
+
+  (each node has its own local subnet)
+
+- It connects the pods to a *local* bridge
+
+  (pods on the same node can communicate together; not with other nodes)
+
+- It doesn't set up routing or tunneling
+
+  (we get pods on separated networks; we need to connect them somehow)
+
+- It doesn't allocate subnets to nodes
+
+  (this can be done manually, or by the controller manager) 
+
+---
+
+## Setting up routing or tunneling
+
+- *On each node*, we will add routes to the other nodes' pod network
+
+- Of course, this is not convenient or scalable!
+
+- We will see better techniques to do this; but for now, hang on!
+
+---
+
+## Allocating subnets to nodes
+
+- There are multiple options:
+
+  - passing the subnet to kubelet with the `--pod-cidr` flag
+
+  - manually setting `spec.podCIDR` on each node
+
+  - allocating node CIDRs automatically with the controller manager
+
+- The last option would be implemented by adding these flags to controller manager:
+  ```
+  --allocate-node-cidrs=true --cluster-cidr=<cidr> 
+  ```
+
+---
+
+class: extra-details
+
+## The pod CIDR field is not mandatory
+
+- `kubenet` needs the pod CIDR, but other plugins don't need it
+
+  (e.g. because they allocate addresses in multiple pools, or a single big one)
+
+- The pod CIDR field may eventually be deprecated and replaced by an annotation
+
+  (see [kubernetes/kubernetes#57130](https://github.com/kubernetes/kubernetes/issues/57130))
+
+---
+
+## Restarting kubelet wih pod CIDR
+
+- We need to stop and restart all our kubelets
+
+- We will add the `--network-plugin` and `--pod-cidr` flags
+
+- We all have a "cluster number" (let's call that `C`)
+
+- We will use pod CIDR `10.C.N.0/24` (where `N` is the node number: 1, 2, 3)
+
+.exercise[
+
+- Stop all the kubelets (Ctrl-C is fine)
+
+- Restart them all, adding `--network-plugin=kubenet --pod-cidr 10.C.N.0/24`
+
+]
+
+---
+
+## What happens to our pods?
+
+- When we stop (or kill) kubelet, the containers keep running
+
+- When kubelet starts again, it detects the containers
+
+.exercise[
+
+- Check that our pods are still here:
+  ```bash
+  kubectl get pods -o wide
+  ```
+
+]
+
+🤔 But our pods still use local IP addresses!
+
+---
+
+## Recreating the pods
+
+- The IP address of a pod cannot change
+
+- kubelet doesn't automatically kill/restart containers with "invalid" addresses
+  <br/>
+  (in fact, from kubelet's point of view, there is no such thing as an "invalid" address)
+
+- We must delete our pods and recreate them
+
+.exercise[
+
+- Delete all the pods, and let the ReplicaSet recreate them:
+  ```bash
+  kubectl delete pods --all
+  ```
+
+- Wait for the pods to be up again:
+  ```bash
+  kubectl get pods -o wide -w
+  ```
+
+]
+
+---
+
+## Adding kube-proxy
+
+- Let's start kube-proxy to provide internal load balancing
+
+- Then see if we can create a Service and use it to contact our pods
+
+.exercise[
+
+- Start kube-proxy:
+  ```bash
+  sudo kube-proxy --kubeconfig ~/kubeconfig
+  ```
+
+- Expose our Deployment:
+  ```bash
+  kubectl expose deployment web --port=80
+  ```
+
+]
+
+---
+
+## Test internal load balancing
+
+.exercise[
+
+- Retrieve the ClusterIP address:
+  ```bash
+  kubectl get svc web
+  ```
+
+- Send a few requests to the ClusterIP address (with `curl`)
+
+]
+
+--
+
+Sometimes it works, sometimes it doesn't. Why?
+
+---
+
+## Routing traffic
+
+- Our pods have new, distinct IP addresses
+
+- But they are on host-local, isolated networks
+
+- If we try to ping a pod on a different node, it won't work
+
+- kube-proxy merely rewrites the destination IP address
+
+- But we need that IP address to be reachable in the first place
+
+- How do we fix this?
+
+  (hint: check the title of this slide!)
+
+---
+
+## Important warning
+
+- The technique that we are about to use doesn't work everywhere
+
+- It only works if:
+
+  - all the nodes are directly connected to each other (at layer 2)
+
+  - the underlying network allows the IP addresses of our pods
+
+- If we are on physical machines connected by a switch: OK
+
+- If we are on virtual machines in a public cloud: NOT OK
+
+  - on AWS, we need to disable "source and destination checks" on our instances
+
+  - on OpenStack, we need to disable "port security" on our network ports
+
+---
+
+## Routing basics
+
+- We need to tell *each* node:
+
+  "The subnet 10.C.N.0/24 is located on node N" (for all values of N)
+
+- This is how we add a route on Linux:
+  ```bash
+  ip route add 10.C.N.0/24 via W.X.Y.Z
+  ```
+
+  (where `W.X.Y.Z` is the internal IP address of node N)
+
+- We can see the internal IP addresses of our nodes with:
+  ```bash
+  kubectl get nodes -o wide
+  ```
+---
+
+## Setting up routing
+
+.exercise[
+
+- Create all the routes on all the nodes
+
+- Check that you can ping all the pods from one of the nodes
+
+- Check that you can `curl` the ClusterIP of the Service successfully
+
+]
+
+---
+
+## What's next?
+
+- We did a lot of manual operations:
+
+  - allocating subnets to nodes
+
+  - adding command-line flags to kubelet
+
+  - updating the routing tables on our nodes
+
+- We want to automate all these steps
+
+- We want something that works on all networks

slides/k8s/namespaces.md

@@ -26,13 +26,15 @@
 
 ## Pre-existing namespaces
 
-- If we deploy a cluster with `kubeadm`, we have three namespaces:
+- If we deploy a cluster with `kubeadm`, we have three or four namespaces:
 
   - `default` (for our applications)
 
   - `kube-system` (for the control plane)
 
-  - `kube-public` (contains one secret used for cluster discovery)
+  - `kube-public` (contains one ConfigMap for cluster discovery)
+
+  - `kube-node-lease` (in Kubernetes 1.14 and later; contains Lease objects)
 
 - If we deploy differently, we may have different namespaces
 

slides/k8s/ourapponkube.md

@@ -1,328 +1,3 @@
-# Shipping images with a registry
-
-- Initially, our app was running on a single node
-
-- We could *build* and *run* in the same place
-
-- Therefore, we did not need to *ship* anything
-
-- Now that we want to run on a cluster, things are different
-
-- The easiest way to ship container images is to use a registry
-
----
-
-## How Docker registries work (a reminder)
-
-- What happens when we execute `docker run alpine` ?
-
-- If the Engine needs to pull the `alpine` image, it expands it into `library/alpine`
-
-- `library/alpine` is expanded into `index.docker.io/library/alpine`
-
-- The Engine communicates with `index.docker.io` to retrieve `library/alpine:latest`
-
-- To use something else than `index.docker.io`, we specify it in the image name
-
-- Examples:
-  ```bash
-  docker pull gcr.io/google-containers/alpine-with-bash:1.0
-
-  docker build -t registry.mycompany.io:5000/myimage:awesome .
-  docker push registry.mycompany.io:5000/myimage:awesome
-  ```
-
----
-
-## The plan
-
-We are going to:
-
-- **build** images for our app,
-
-- **ship** these images with a registry,
-
-- **run** deployments using these images,
-
-- expose (with a ClusterIP) the deployments that need to communicate together,
-
-- expose (with a NodePort) the web UI so we can access it from outside.
-
----
-
-## Building and shipping our app
-
-- We will pick a registry
-
-  (let's pretend the address will be `REGISTRY:PORT`)
-
-- We will build on our control node (`node1`)
-
-  (the images will be named `REGISTRY:PORT/servicename`)
-
-- We will push the images to the registry
-
-- These images will be usable by the other nodes of the cluster
-
-  (i.e., we could do `docker run REGISTRY:PORT/servicename` from these nodes)
-
----
-
-## A shortcut opportunity
-
-- As it happens, the images that we need do already exist on the Docker Hub:
-
-  https://hub.docker.com/r/dockercoins/
-
-- We could use them instead of using our own registry and images
-
-*In the following slides, we are going to show how to run a registry
-and use it to host container images. We will also show you how to
-use the existing images from the Docker Hub, so that you can catch
-up (or skip altogether the build/push part) if needed.*
-
----
-
-## Which registry do we want to use?
-
-- We could use the Docker Hub
-
-- There are alternatives like Quay
-
-- Each major cloud provider has an option as well
-
-  (ACR on Azure, ECR on AWS, GCR on Google Cloud...)
-
-- There are also commercial products to run our own registry
-
-  (Docker EE, Quay...)
-
-- And open source options, too!
-
-*We are going to self-host an open source registry because it's the most generic solution for this workshop. We will use Docker's reference
-implementation for simplicity.*
-
----
-
-## Using the open source registry
-
-- We need to run a `registry` container
-
-- It will store images and layers to the local filesystem
-  <br/>(but you can add a config file to use S3, Swift, etc.)
-
-- Docker *requires* TLS when communicating with the registry
-
-  - unless for registries on `127.0.0.0/8` (i.e. `localhost`)
-
-  - or with the Engine flag `--insecure-registry`
-
-- Our strategy: publish the registry container on a NodePort,
-  <br/>so that it's available through `127.0.0.1:xxxxx` on each node
-
----
-
-## Deploying a self-hosted registry
-
-- We will deploy a registry container, and expose it with a NodePort
-
-.exercise[
-
-- Create the registry service:
-  ```bash
-  kubectl create deployment registry --image=registry
-  ```
-
-- Expose it on a NodePort:
-  ```bash
-  kubectl expose deploy/registry --port=5000 --type=NodePort
-  ```
-
-]
-
----
-
-## Connecting to our registry
-
-- We need to find out which port has been allocated
-
-.exercise[
-
-- View the service details:
-  ```bash
-  kubectl describe svc/registry
-  ```
-
-- Get the port number programmatically:
-  ```bash
-  NODEPORT=$(kubectl get svc/registry -o json | jq .spec.ports[0].nodePort)
-  REGISTRY=127.0.0.1:$NODEPORT
-  ```
-
-]
-
----
-
-## Testing our registry
-
-- A convenient Docker registry API route to remember is `/v2/_catalog`
-
-.exercise[
-
-<!-- ```hide kubectl wait deploy/registry --for condition=available```-->
-
-- View the repositories currently held in our registry:
-  ```bash
-  curl $REGISTRY/v2/_catalog
-  ```
-
-]
-
---
-
-We should see:
-```json
-{"repositories":[]}
-```
-
----
-
-## Testing our local registry
-
-- We can retag a small image, and push it to the registry
-
-.exercise[
-
-- Make sure we have the busybox image, and retag it:
-  ```bash
-  docker pull busybox
-  docker tag busybox $REGISTRY/busybox
-  ```
-
-- Push it:
-  ```bash
-  docker push $REGISTRY/busybox
-  ```
-
-]
-
----
-
-## Checking again what's on our local registry
-
-- Let's use the same endpoint as before
-
-.exercise[
-
-- Ensure that our busybox image is now in the local registry:
-  ```bash
-  curl $REGISTRY/v2/_catalog
-  ```
-
-]
-
-The curl command should now output:
-```json
-{"repositories":["busybox"]}
-```
-
----
-
-## Building and pushing our images
-
-- We are going to use a convenient feature of Docker Compose
-
-.exercise[
-
-- Go to the `stacks` directory:
-  ```bash
-  cd ~/container.training/stacks
-  ```
-
-- Build and push the images:
-  ```bash
-  export REGISTRY
-  export TAG=v0.1
-  docker-compose -f dockercoins.yml build
-  docker-compose -f dockercoins.yml push
-  ```
-
-]
-
-Let's have a look at the `dockercoins.yml` file while this is building and pushing.
-
----
-
-```yaml
-version: "3"
-
-services:
-  rng:
-    build: dockercoins/rng
-    image: ${REGISTRY-127.0.0.1:5000}/rng:${TAG-latest}
-    deploy:
-      mode: global
-  ...
-  redis:
-    image: redis
-  ...
-  worker:
-    build: dockercoins/worker
-    image: ${REGISTRY-127.0.0.1:5000}/worker:${TAG-latest}
-    ...
-    deploy:
-      replicas: 10
-```
-
-.warning[Just in case you were wondering ... Docker "services" are not Kubernetes "services".]
-
----
-
-class: extra-details
-
-## Avoiding the `latest` tag
-
-.warning[Make sure that you've set the `TAG` variable properly!]
-
-- If you don't, the tag will default to `latest`
-
-- The problem with `latest`: nobody knows what it points to!
-
-  - the latest commit in the repo?
-
-  - the latest commit in some branch? (Which one?)
-
-  - the latest tag?
-
-  - some random version pushed by a random team member?
-
-- If you keep pushing the `latest` tag, how do you roll back?
-
-- Image tags should be meaningful, i.e. correspond to code branches, tags, or hashes
-
----
-
-## Catching up
-
-- If you have problems deploying the registry ...
-
-- Or building or pushing the images ...
-
-- Don't worry: you can easily use pre-built images from the Docker Hub!
-
-- The images are named `dockercoins/worker:v0.1`, `dockercoins/rng:v0.1`, etc.
-
-- To use them, just set the `REGISTRY` environment variable to `dockercoins`:
-  ```bash
-  export REGISTRY=dockercoins
-  ```
-
-- Make sure to set the `TAG` to `v0.1`
-
-  (our repositories on the Docker Hub do not provide a `latest` tag)
-
----
-
 # Running our application on Kubernetes
 
 - We can now deploy our code (as well as a redis instance)
@@ -336,6 +11,7 @@ class: extra-details
 
 - Deploy everything else:
   ```bash
+    set -u
     for SERVICE in hasher rng webui worker; do
       kubectl create deployment $SERVICE --image=$REGISTRY/$SERVICE:$TAG
     done

slides/k8s/prereqs-admin.md

@@ -0,0 +1,71 @@
+# Pre-requirements
+
+- Kubernetes concepts
+
+  (pods, deployments, services, labels, selectors)
+
+- Hands-on experience working with containers
+
+  (building images, running them; doesn't matter how exactly)
+
+- Familiar with the UNIX command-line
+
+  (navigating directories, editing files, using `kubectl`)
+
+---
+
+## Labs and exercises
+
+- We are going to build and break multiple clusters
+
+- Everyone will get their own private environment(s)
+
+- You are invited to reproduce all the demos (but you don't have to)
+
+- All hands-on sections are clearly identified, like the gray rectangle below
+
+.exercise[
+
+- This is the stuff you're supposed to do!
+
+- Go to @@SLIDES@@ to view these slides
+
+- Join the chat room: @@CHAT@@
+
+<!-- ```open @@SLIDES@@``` -->
+
+]
+
+---
+
+## Private environments
+
+- Each person gets their own private set of VMs
+
+- Each person should have a printed card with connection information
+
+- We will connect to these VMs with SSH
+
+  (if you don't have an SSH client, install one **now!**)
+
+---
+
+## Doing or re-doing this on your own?
+
+- We are using basic cloud VMs with Ubuntu LTS
+
+- Kubernetes [packages] or [binaries] have been installed
+
+  (depending on what we want to accomplish in the lab)
+
+- We disabled IP address checks
+
+  - we want to route pod traffic directly between nodes
+
+  - most cloud providers will treat pod IP addresses as invalid
+
+  - ... and filter them out; so we disable that filter
+
+[packages]: https://kubernetes.io/docs/setup/independent/install-kubeadm/#installing-kubeadm-kubelet-and-kubectl
+
+[binaries]: https://kubernetes.io/docs/setup/release/notes/#server-binaries

slides/k8s/resource-limits.md

@@ -0,0 +1,517 @@
+# Resource Limits
+
+- We can attach resource indications to our pods
+
+  (or rather: to the *containers* in our pods)
+
+- We can specify *limits* and/or *requests*
+
+- We can specify quantities of CPU and/or memory
+
+---
+
+## CPU vs memory
+
+- CPU is a *compressible resource*
+
+  (it can be preempted immediately without adverse effect)
+
+- Memory is an *incompressible resource*
+
+  (it needs to be swapped out to be reclaimed; and this is costly)
+
+- As a result, exceeding limits will have different consequences for CPU and memory
+
+---
+
+## Exceeding CPU limits
+
+- CPU can be reclaimed instantaneously
+
+  (in fact, it is preempted hundreds of times per second, at each context switch)
+
+- If a container uses too much CPU, it can be throttled
+
+  (it will be scheduled less often)
+
+- The processes in that container will run slower
+
+  (or rather: they will not run faster)
+
+---
+
+## Exceeding memory limits
+
+- Memory needs to be swapped out before being reclaimed
+
+- "Swapping" means writing memory pages to disk, which is very slow
+
+- On a classic system, a process that swaps can get 1000x slower
+
+  (because disk I/O is 1000x slower than memory I/O)
+
+- Exceeding the memory limit (even by a small amount) can reduce performance *a lot*
+
+- Kubernetes *does not support swap* (more on that later!)
+
+- Exceeding the memory limit will cause the container to be killed
+
+
+
+---
+
+## Limits vs requests
+
+- Limits are "hard limits" (they can't be exceeded)
+
+  - a container exceeding its memory limit is killed
+
+  - a container exceeding its CPU limit is throttled
+
+- Requests are used for scheduling purposes
+
+  - a container using *less* than what it requested will never be killed or throttled
+
+  - the scheduler uses the requested sizes to determine placement
+
+  - the resources requested by all pods on a node will never exceed the node size
+
+---
+
+## Pod quality of service
+
+Each pod is assigned a QoS class (visible in `status.qosClass`).
+
+- If limits = requests:
+
+  - 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 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
+
+  - if at least one container has *(requests<limits)*, QoS is "Burstable"
+
+- If a pod doesn't have any request nor limit, QoS is "BestEffort"
+
+---
+
+## Quality of service impact
+
+- When a node is overloaded, BestEffort pods are killed first
+
+- Then, Burstable pods that exceed their limits
+
+- Burstable and Guaranteed pods below their limits are never killed
+
+  (except if their node fails)
+
+- If we only use Guaranteed pods, no pod should ever be killed
+
+  (as long as they stay within their limits)
+
+(Pod QoS is also explained in [this page](https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/) of the Kubernetes documentation and in [this blog post](https://medium.com/google-cloud/quality-of-service-class-qos-in-kubernetes-bb76a89eb2c6).)
+
+---
+
+## Where is my swap?
+
+- The semantics of memory and swap limits on Linux cgroups are complex
+
+- In particular, it's not possible to disable swap for a cgroup
+
+  (the closest option is to [reduce "swappiness"](https://unix.stackexchange.com/questions/77939/turning-off-swapping-for-only-one-process-with-cgroups))
+
+- The architects of Kubernetes wanted to ensure that Guaranteed pods never swap
+
+- The only solution was to disable swap entirely
+
+---
+
+## Alternative point of view
+
+- Swap enables paging¹ of anonymous² memory
+
+- Even when swap is disabled, Linux will still page memory for:
+
+  - executables, libraries
+
+  - mapped files
+
+- Disabling swap *will reduce performance and available resources*
+
+- For a good time, read [kubernetes/kubernetes#53533](https://github.com/kubernetes/kubernetes/issues/53533)
+
+- Also read this [excellent blog post about swap](https://jvns.ca/blog/2017/02/17/mystery-swap/)
+
+¹Paging: reading/writing memory pages from/to disk to reclaim physical memory
+
+²Anonymous memory: memory that is not backed by files or blocks
+
+---
+
+## Enabling swap anyway
+
+- If you don't care that pods are swapping, you can enable swap
+
+- You will need to add the flag `--fail-swap-on=false` to kubelet
+
+  (otherwise, it won't start!)
+
+---
+
+## Specifying resources
+
+- Resource requests are expressed at the *container* level
+
+- CPU is expressed in "virtual CPUs"
+
+  (corresponding to the virtual CPUs offered by some cloud providers)
+
+- CPU can be expressed with a decimal value, or even a "milli" suffix
+
+  (so 100m = 0.1)
+
+- Memory is expressed in bytes
+
+- Memory can be expressed with k, M, G, T, ki, Mi, Gi, Ti suffixes
+
+  (corresponding to 10^3, 10^6, 10^9, 10^12, 2^10, 2^20, 2^30, 2^40)
+
+---
+
+## Specifying resources in practice
+
+This is what the spec of a Pod with resources will look like:
+
+```yaml
+containers:
+- name: httpenv
+  image: jpetazzo/httpenv
+  resources:
+    limits:
+      memory: "100Mi"
+      cpu: "100m"
+    requests:
+      memory: "100Mi"
+      cpu: "10m"
+```
+
+This set of resources makes sure that this service won't be killed (as long as it stays below 100 MB of RAM), but allows its CPU usage to be throttled if necessary.
+
+---
+
+## Default values
+
+- If we specify a limit without a request: 
+
+  the request is set to the limit
+
+- If we specify a request without a limit: 
+
+  there will be no limit
+
+  (which means that the limit will be the size of the node)
+
+- If we don't specify anything:
+
+  the request is zero and the limit is the size of the node
+
+*Unless there are default values defined for our namespace!*
+
+---
+
+## We need default resource values
+
+- If we do not set resource values at all:
+
+  - the limit is "the size of the node"
+
+  - the request is zero
+
+- This is generally *not* what we want
+
+  - a container without a limit can use up all the resources of a node
+
+  - if the request is zero, the scheduler can't make a smart placement decision
+
+- To address this, we can set default values for resources
+
+- This is done with a LimitRange object
+
+---
+
+# Defining min, max, and default resources
+
+- We can create LimitRange objects to indicate any combination of:
+
+  - min and/or max resources allowed per pod
+
+  - default resource *limits*
+
+  - default resource *requests*
+
+  - maximal burst ratio (*limit/request*)
+
+- LimitRange objects are namespaced
+
+- They apply to their namespace only
+
+---
+
+## LimitRange example
+
+```yaml
+apiVersion: v1
+kind: LimitRange
+metadata:
+  name: my-very-detailed-limitrange
+spec:
+  limits:
+  - type: Container
+    min:
+      cpu: "100m"
+    max:
+      cpu: "2000m"
+      memory: "1Gi"
+    default:
+      cpu: "500m"
+      memory: "250Mi"
+    defaultRequest:
+      cpu: "500m"
+```
+
+---
+
+## Example explanation
+
+The YAML on the previous slide shows an example LimitRange object specifying very detailed limits on CPU usage,
+and providing defaults on RAM usage.
+
+Note the `type: Container` line: in the future,
+it might also be possible to specify limits
+per Pod, but it's not [officially documented yet](https://github.com/kubernetes/website/issues/9585).
+
+---
+
+## LimitRange details
+
+- LimitRange restrictions are enforced only when a Pod is created
+
+  (they don't apply retroactively)
+
+- They don't prevent creation of e.g. an invalid Deployment or DaemonSet
+
+  (but the pods will not be created as long as the LimitRange is in effect)
+
+- If there are multiple LimitRange restrictions, they all apply together
+
+  (which means that it's possible to specify conflicting LimitRanges,
+  <br/>preventing any Pod from being created)
+
+- If a LimitRange specifies a `max` for a resource but no `default`,
+  <br/>that `max` value becomes the `default` limit too
+
+---
+
+# Namespace quotas
+
+- We can also set quotas per namespace
+
+- Quotas apply to the total usage in a namespace
+
+  (e.g. total CPU limits of all pods in a given namespace)
+
+- Quotas can apply to resource limits and/or requests
+
+  (like the CPU and memory limits that we saw earlier)
+
+- Quotas can also apply to other resources:
+
+  - "extended" resources (like GPUs)
+
+  - storage size
+
+  - number of objects (number of pods, services...)
+
+---
+
+## Creating a quota for a namespace
+
+- Quotas are enforced by creating a ResourceQuota object
+
+- ResourceQuota objects are namespaced, and apply to their namespace only
+
+- We can have multiple ResourceQuota objects in the same namespace
+
+- The most restrictive values are used
+
+---
+
+## Limiting total CPU/memory usage
+
+- The following YAML specifies an upper bound for *limits* and *requests*:
+  ```yaml
+    apiVersion: v1
+    kind: ResourceQuota
+    metadata:
+      name: a-little-bit-of-compute
+    spec:
+      hard:
+        requests.cpu: "10"
+        requests.memory: 10Gi
+        limits.cpu: "20"
+        limits.memory: 20Gi
+  ```
+
+These quotas will apply to the namespace where the ResourceQuota is created.
+
+---
+
+## Limiting number of objects
+
+- The following YAML specifies how many objects of specific types can be created:
+  ```yaml
+    apiVersion: v1
+    kind: ResourceQuota
+    metadata:
+      name: quota-for-objects
+    spec:
+      hard:
+        pods: 100
+        services: 10
+        secrets: 10
+        configmaps: 10
+        persistentvolumeclaims: 20
+        services.nodeports: 0
+        services.loadbalancers: 0
+        count/roles.rbac.authorization.k8s.io: 10
+  ```
+
+(The `count/` syntax allows to limit arbitrary objects, including CRDs.)
+
+---
+
+## YAML vs CLI
+
+- Quotas can be created with a YAML definition
+
+- ... Or with the `kubectl create quota` command
+
+- Example:
+  ```bash
+  kubectl create quota sparta --hard=pods=300,limits.memory=300Gi
+  ```
+
+- With both YAML and CLI form, the values are always under the `hard` section
+
+  (there is no `soft` quota)
+
+---
+
+## Viewing current usage
+
+When a ResourceQuota is created, we can see how much of it is used:
+
+```
+kubectl describe resourcequota my-resource-quota
+
+Name:                            my-resource-quota
+Namespace:                       default
+Resource                         Used  Hard
+--------                         ----  ----
+pods                             12    100
+services                         1     5
+services.loadbalancers           0     0
+services.nodeports               0     0
+```
+
+---
+
+## Advanced quotas and PriorityClass
+
+- Since Kubernetes 1.12, it is possible to create PriorityClass objects
+
+- Pods can be assigned a PriorityClass
+
+- Quotas can be linked to a PriorityClass
+
+- This allows us to reserve resources for pods within a namespace
+
+- For more details, check [this documentation page](https://kubernetes.io/docs/concepts/policy/resource-quotas/#resource-quota-per-priorityclass)
+
+---
+
+# Limiting resources in practice
+
+- We have at least three mechanisms:
+
+  - requests and limits per Pod
+
+  - LimitRange per namespace
+
+  - ResourceQuota per namespace
+
+- Let's see a simple recommendation to get started with resource limits
+
+---
+
+## Set a LimitRange
+
+- In each namespace, create a LimitRange object
+
+- Set a small default CPU request and CPU limit
+
+  (e.g. "100m")
+
+- Set a default memory request and limit depending on your most common workload
+
+  - for Java, Ruby: start with "1G"
+
+  - for Go, Python, PHP, Node: start with "250M"
+
+- Set upper bounds slightly below your expected node size
+
+  (80-90% of your node size, with at least a 500M memory buffer)
+
+---
+
+## Set a ResourceQuota
+
+- In each namespace, create a ResourceQuota object
+
+- Set generous CPU and memory limits
+
+  (e.g. half the cluster size if the cluster hosts multiple apps)
+
+- Set generous objects limits
+
+  - these limits should not be here to constrain your users
+
+  - they should catch a runaway process creating many resources
+
+  - example: a custom controller creating many pods
+
+---
+
+## Observe, refine, iterate
+
+- Observe the resource usage of your pods
+
+  (we will see how in the next chapter)
+
+- Adjust individual pod limits
+
+- If you see trends: adjust the LimitRange
+
+  (rather than adjusting every individual set of pod limits)
+
+- Observe the resource usage of your namespaces
+
+  (with `kubectl describe resourcequota ...`)
+
+- Rinse and repeat regularly

slides/k8s/rollout.md

@@ -62,29 +62,6 @@
 
 ---
 
-## Building a new version of the `worker` service
-
-.exercise[
-
-- Go to the `stack` directory:
-  ```bash
-  cd ~/container.training/stacks
-  ```
-
-- Edit `dockercoins/worker/worker.py`; update the first `sleep` line to sleep 1 second
-
-- Build a new tag and push it to the registry:
-  ```bash
-  #export REGISTRY=localhost:3xxxx
-  export TAG=v0.2
-  docker-compose -f dockercoins.yml build
-  docker-compose -f dockercoins.yml push
-  ```
-
-]
-
----
-
 ## Rolling out the new `worker` service
 
 .exercise[
@@ -103,6 +80,8 @@
 
 - Update `worker` either with `kubectl edit`, or by running:
   ```bash
+  set -u
+  export TAG=v0.2
   kubectl set image deploy worker worker=$REGISTRY/worker:$TAG
   ```
 
@@ -144,6 +123,7 @@ That rollout should be pretty quick. What shows in the web UI?
 
 - Update `worker` by specifying a non-existent image:
   ```bash
+  set -u
   export TAG=v0.3
   kubectl set image deploy worker worker=$REGISTRY/worker:$TAG
   ```
@@ -208,35 +188,6 @@ class: extra-details
 
 ---
 
-## Checking the dashboard during the bad rollout
-
-If you haven't deployed the Kubernetes dashboard earlier, just skip this slide.
-
-.exercise[
-
-- Check which port the dashboard is on:
-  ```bash
-  kubectl -n kube-system get svc socat
-  ```
-
-]
-
-Note the `3xxxx` port.
-
-.exercise[
-
-- Connect to http://oneofournodes:3xxxx/
-
-<!-- ```open https://node1:3xxxx/``` -->
-
-]
-
---
-
-- We have failures in Deployments, Pods, and Replica Sets
-
----
-
 ## Recovering from a bad rollout
 
 - We could push some `v0.3` image

slides/k8s/scalingdockercoins.md

@@ -0,0 +1,200 @@
+# Scaling our demo app
+
+- Our ultimate goal is to get more DockerCoins
+
+  (i.e. increase the number of loops per second shown on the web UI)
+
+- Let's look at the architecture again:
+
+  ![DockerCoins architecture](images/dockercoins-diagram.svg)
+
+- The loop is done in the worker;
+  perhaps we could try adding more workers?
+
+---
+
+## Adding another worker
+
+- All we have to do is scale the `worker` Deployment
+
+.exercise[
+
+- Open two new terminals to check what's going on with pods and deployments:
+  ```bash
+  kubectl get pods -w
+  kubectl get deployments -w
+  ```
+
+<!--
+```wait RESTARTS```
+```keys ^C```
+```wait AVAILABLE```
+```keys ^C```
+-->
+
+- Now, create more `worker` replicas:
+  ```bash
+  kubectl scale deployment worker --replicas=2
+  ```
+
+]
+
+After a few seconds, the graph in the web UI should show up.
+
+---
+
+## Adding more workers
+
+- If 2 workers give us 2x speed, what about 3 workers?
+
+.exercise[
+
+- Scale the `worker` Deployment further:
+  ```bash
+  kubectl scale deployment worker --replicas=3
+  ```
+
+]
+
+The graph in the web UI should go up again.
+
+(This is looking great! We're gonna be RICH!)
+
+---
+
+## Adding even more workers
+
+- Let's see if 10 workers give us 10x speed!
+
+.exercise[
+
+- Scale the `worker` Deployment to a bigger number:
+  ```bash
+  kubectl scale deployment worker --replicas=10
+  ```
+
+]
+
+--
+
+The graph will peak at 10 hashes/second.
+
+(We can add as many workers as we want: we will never go past 10 hashes/second.)
+
+---
+
+class: extra-details
+
+## Didn't we briefly exceed 10 hashes/second?
+
+- It may *look like it*, because the web UI shows instant speed
+
+- The instant speed can briefly exceed 10 hashes/second
+
+- The average speed cannot
+
+- The instant speed can be biased because of how it's computed
+
+---
+
+class: extra-details
+
+## Why instant speed is misleading
+
+- The instant speed is computed client-side by the web UI
+
+- The web UI checks the hash counter once per second
+  <br/>
+  (and does a classic (h2-h1)/(t2-t1) speed computation)
+
+- The counter is updated once per second by the workers
+
+- These timings are not exact
+  <br/>
+  (e.g. the web UI check interval is client-side JavaScript)
+
+- Sometimes, between two web UI counter measurements,
+  <br/>
+  the workers are able to update the counter *twice*
+
+- During that cycle, the instant speed will appear to be much bigger
+  <br/>
+  (but it will be compensated by lower instant speed before and after)
+
+---
+
+## Why are we stuck at 10 hashes per second?
+
+- If this was high-quality, production code, we would have instrumentation
+
+  (Datadog, Honeycomb, New Relic, statsd, Sumologic, ...)
+
+- It's not!
+
+- Perhaps we could benchmark our web services?
+
+  (with tools like `ab`, or even simpler, `httping`)
+
+---
+
+## Benchmarking our web services
+
+- We want to check `hasher` and `rng`
+
+- We are going to use `httping`
+
+- It's just like `ping`, but using HTTP `GET` requests
+
+  (it measures how long it takes to perform one `GET` request)
+
+- It's used like this:
+  ```
+  httping [-c count] http://host:port/path
+  ```
+
+- Or even simpler:
+  ```
+  httping ip.ad.dr.ess
+  ```
+
+- We will use `httping` on the ClusterIP addresses of our services
+
+---
+
+## Obtaining ClusterIP addresses
+
+- We can simply check the output of `kubectl get services`
+
+- Or do it programmatically, as in the example below
+
+.exercise[
+
+- Retrieve the IP addresses:
+  ```bash
+  HASHER=$(kubectl get svc hasher -o go-template={{.spec.clusterIP}})
+  RNG=$(kubectl get svc rng -o go-template={{.spec.clusterIP}})
+  ```
+
+]
+
+Now we can access the IP addresses of our services through `$HASHER` and `$RNG`.
+
+---
+
+## Checking `hasher` and `rng` response times
+
+.exercise[
+
+- Check the response times for both services:
+  ```bash
+  httping -c 3 $HASHER
+  httping -c 3 $RNG
+  ```
+
+]
+
+- `hasher` is fine (it should take a few milliseconds to reply)
+
+- `rng` is not (it should take about 700 milliseconds if there are 10 workers)
+
+- Something is wrong with `rng`, but ... what?

slides/k8s/setup-k8s.md

@@ -46,26 +46,27 @@
 
 ## Other deployment options
 
-- If you are on Azure:
-  [AKS](https://azure.microsoft.com/services/kubernetes-service/)
+- [AKS](https://azure.microsoft.com/services/kubernetes-service/):
+  managed Kubernetes on Azure
 
-- If you are on Google Cloud:
-  [GKE](https://cloud.google.com/kubernetes-engine/)
+- [GKE](https://cloud.google.com/kubernetes-engine/):
+  managed Kubernetes on Google Cloud
 
-- If you are on AWS:
-  [EKS](https://aws.amazon.com/eks/),
-  [eksctl](https://eksctl.io/),
-  [kops](https://github.com/kubernetes/kops)
+- [EKS](https://aws.amazon.com/eks/),
+  [eksctl](https://eksctl.io/):
+  managed Kubernetes on AWS
 
-- On a local machine:
-  [minikube](https://kubernetes.io/docs/setup/minikube/),
+- [kops](https://github.com/kubernetes/kops):
+  customizable deployments on AWS, Digital Ocean, GCE (beta), vSphere (alpha)
+
+- [minikube](https://kubernetes.io/docs/setup/minikube/),
   [kubespawn](https://github.com/kinvolk/kube-spawn),
-  [Docker4Mac](https://docs.docker.com/docker-for-mac/kubernetes/)
+  [Docker Desktop](https://docs.docker.com/docker-for-mac/kubernetes/):
+  for local development
 
-- If you want something customizable:
-  [kubicorn](https://github.com/kubicorn/kubicorn)
-
-  Probably the closest to a multi-cloud/hybrid solution so far, but in development
+- [kubicorn](https://github.com/kubicorn/kubicorn),
+  the [Cluster API](https://blogs.vmware.com/cloudnative/2019/03/14/what-and-why-of-cluster-api/):
+  deploy your clusters declaratively, "the Kubernetes way"
 
 ---
 

slides/k8s/setup-managed.md

@@ -0,0 +1,253 @@
+# Installing a managed cluster
+
+*"The easiest way to install Kubernetes is to get someone
+else to do it for you."
+<br/>
+([Jérôme Petazzoni](https://twitter.com/jpetazzo))*
+
+- Let's see a few options to install managed clusters!
+
+- This is not an exhaustive list
+
+  (the goal is to show the actual steps to get started)
+
+- All the options mentioned here require an account
+with a cloud provider
+
+- ... And a credit card
+
+---
+
+## EKS (the hard way)
+
+- [Read the doc](https://docs.aws.amazon.com/eks/latest/userguide/getting-started.html)
+
+- Create service roles, VPCs, and a bunch of other oddities
+
+- Try to figure out why it doesn't work
+
+- Start over, following an [official AWS blog post](https://aws.amazon.com/blogs/aws/amazon-eks-now-generally-available/)
+
+- Try to find the missing Cloud Formation template
+
+--
+
+.footnote[(╯°□°)╯︵ ┻━┻]
+
+---
+
+## EKS (the easy way)
+
+- Install `eksctl`
+
+- Set the usual environment variables
+
+  ([AWS_DEFAULT_REGION](https://docs.aws.amazon.com/general/latest/gr/rande.html#eks_region), AWS_ACCESS_KEY, AWS_SECRET_ACCESS_KEY)
+
+- Create the cluster:
+  ```bash
+  eksctl create cluster
+  ```
+
+- Wait 15-20 minutes (yes, it's sloooooooooooooooooow)
+
+- Add cluster add-ons
+
+  (by default, it doesn't come with metrics-server, logging, etc.)
+
+---
+
+## EKS (cleanup)
+
+- Delete the cluster:
+  ```bash
+  eksctl delete cluster <clustername>
+  ```
+
+- If you need to find the name of the cluster:
+  ```bash
+  eksctl get clusters
+  ```
+
+---
+
+## GKE (initial setup)
+
+- Install `gcloud`
+
+- Login:
+  ```bash
+  gcloud auth init
+  ```
+
+- Create a "project":
+  ```bash
+  gcloud projects create my-gke-project
+  gcloud config set project my-gke-project
+  ```
+
+- Pick a [region](https://cloud.google.com/compute/docs/regions-zones/)
+
+  (example: `europe-west1`, `us-west1`, ...)
+
+---
+
+## GKE (create cluster)
+
+- Create the cluster:
+  ```bash
+  gcloud container clusters create my-gke-cluster --region us-west1 --num-nodes=2
+  ```
+
+  (without `--num-nodes` you might exhaust your IP address quota!)
+
+- The first time you try to create a cluster in a given project, you get an error
+
+  - you need to enable the Kubernetes Engine API
+  - the error message gives you a link
+  - follow the link and enable the API (and billing)
+    <br/>(it's just a couple of clicks and it's instantaneous)
+
+- Wait a couple of minutes (yes, it's faaaaaaaaast)
+
+- The cluster comes with many add-ons
+
+---
+
+## GKE (cleanup)
+
+- List clusters (if you forgot its name):
+  ```bash
+  gcloud container clusters list
+  ```
+
+- Delete the cluster:
+  ```bash
+  gcloud container clusters delete my-gke-cluster --region us-west1
+  ```
+
+- Delete the project (optional):
+  ```bash
+  gcloud projects delete my-gke-project
+  ```
+
+---
+
+## AKS (initial setup)
+
+- Install the Azure CLI
+
+- Login:
+  ```bash
+  az login
+  ```
+
+- Select a [region](https://azure.microsoft.com/en-us/global-infrastructure/services/?products=kubernetes-service\&regions=all
+)
+
+- Create a "resource group":
+  ```bash
+  az group create --name my-aks-group --location westeurope
+  ```
+
+---
+
+## AKS (create cluster)
+
+- Create the cluster:
+  ```bash
+  az aks create --resource-group my-aks-group --name my-aks-cluster
+  ```
+
+- Wait about 5-10 minutes
+
+- Add credentials to `kubeconfig`:
+  ```bash
+  az aks get-credentials --resource-group my-aks-group --name my-aks-cluster
+  ```
+
+- The cluster has a lot of goodies pre-installed
+
+---
+
+## AKS (cleanup)
+
+- Delete the cluster:
+  ```bash
+  az aks delete --resource-group my-aks-group --name my-aks-cluster
+  ```
+
+- Delete the resource group:
+  ```bash
+  az group delete --resource-group my-aks-group
+  ```
+
+- Note: delete actions can take a while too!
+
+  (5-10 minutes as well)
+
+---
+
+## Digital Ocean (initial setup)
+
+- Install `doctl`
+
+- Generate API token (in web console)
+
+- Set up the CLI authentication:
+  ```bash
+  doctl auth init
+  ```
+  (It will ask you for the API token)
+
+- Check the list of regions and pick one:
+  ```bash
+  doctl compute region list
+  ```
+  (If you don't specify the region later, it will use `nyc1`)
+
+---
+
+## Digital Ocean (create cluster)
+
+- Create the cluster:
+  ```bash
+  doctl kubernetes cluster create my-do-cluster [--region xxx1]
+  ```
+
+- Wait 5 minutes
+
+- Update `kubeconfig`:
+  ```bash
+  kubectl config use-context do-xxx1-my-do-cluster
+  ```
+
+- The cluster comes with some goodies (like Cilium) but no metrics server
+
+---
+
+## Digital Ocean (cleanup)
+
+- List clusters (if you forgot its name):
+  ```bash
+  doctl kubernetes cluster list
+  ```
+
+- Delete the cluster:
+  ```bash
+  doctl kubernetes cluster delete my-do-cluster
+  ```
+
+---
+
+## More options
+
+- Alibaba Cloud
+
+- [IBM Cloud](https://console.bluemix.net/docs/containers/cs_cli_install.html#cs_cli_install)
+
+- OVH
+
+- Scaleway (private beta)
+
+- ...

slides/k8s/setup-selfhosted.md

@@ -0,0 +1,108 @@
+# Kubernetes distributions and installers
+
+- There are [countless](https://kubernetes.io/docs/setup/pick-right-solution/) distributions available
+
+- We can't review them all
+
+- We're just going to explore a few options
+
+---
+
+## kops
+
+- Deploys Kubernetes using cloud infrastructure
+
+  (supports AWS, GCE, Digital Ocean ...)
+
+- Leverages special cloud features when possible
+
+  (e.g. Auto Scaling Groups ...)
+
+---
+
+## kubeadm
+
+- Provisions Kubernetes nodes on top of existing machines
+
+- `kubeadm init` to provision a single-node control plane
+
+- `kubeadm join` to join a node to the cluster
+
+- Supports HA control plane [with some extra steps](https://kubernetes.io/docs/setup/independent/high-availability/) 
+
+---
+
+## Kubespray
+
+- Based on Ansible
+
+- Works on bare metal and cloud infrastructure
+
+  (good for hybrid deployments)
+
+- The expert says: ultra flexible; slow; complex
+
+---
+
+## RKE (Rancher Kubernetes Engine)
+
+- Opinionated installer with low requirements
+
+- Requires a set of machines with Docker + SSH access
+
+- Supports highly available etcd and control plane
+
+- The expert says: fast; maintenance can be tricky
+
+---
+
+## Terraform + kubeadm
+
+- Sometimes it is necessary to build a custom solution
+
+- Example use case: 
+
+  - deploying Kubernetes on OpenStack
+
+  - ... with highly available control plane
+
+  - ... and Cloud Controller Manager integration
+
+- Solution: Terraform + kubeadm (kubeadm driven by remote-exec)
+
+  - [GitHub repository](https://github.com/enix/terraform-openstack-kubernetes)
+
+  - [Blog post (in French)](https://enix.io/fr/blog/deployer-kubernetes-1-13-sur-openstack-grace-a-terraform/)
+
+---
+
+## And many more ...
+
+- Docker Enterprise Edition
+
+- Pivotal Container Service (PKS)
+
+- Tectonic by CoreOS
+
+- etc.
+
+---
+
+## Bottom line
+
+- Each distribution / installer has pros and cons
+
+- Before picking one, we should sort out our priorities:
+
+  - cloud, on-premises, hybrid?
+
+  - integration with existing network/storage architecture or equipment?
+
+  - are we storing very sensitive data, like finance, health, military?
+
+  - how many clusters are we deploying (and maintaining): 2, 10, 50?
+
+  - which team will be responsible for deployment and maintenance?
+    <br/>(do they need training?)
+
+  - etc.

slides/k8s/shippingimages.md

@@ -0,0 +1,91 @@
+# Shipping images with a registry
+
+- Initially, our app was running on a single node
+
+- We could *build* and *run* in the same place
+
+- Therefore, we did not need to *ship* anything
+
+- Now that we want to run on a cluster, things are different
+
+- The easiest way to ship container images is to use a registry
+
+---
+
+## How Docker registries work (a reminder)
+
+- What happens when we execute `docker run alpine` ?
+
+- If the Engine needs to pull the `alpine` image, it expands it into `library/alpine`
+
+- `library/alpine` is expanded into `index.docker.io/library/alpine`
+
+- The Engine communicates with `index.docker.io` to retrieve `library/alpine:latest`
+
+- To use something else than `index.docker.io`, we specify it in the image name
+
+- Examples:
+  ```bash
+  docker pull gcr.io/google-containers/alpine-with-bash:1.0
+
+  docker build -t registry.mycompany.io:5000/myimage:awesome .
+  docker push registry.mycompany.io:5000/myimage:awesome
+  ```
+
+---
+
+## Running DockerCoins on Kubernetes
+
+- Create one deployment for each component
+
+  (hasher, redis, rng, webui, worker)
+
+- Expose deployments that need to accept connections
+
+  (hasher, redis, rng, webui)
+
+- For redis, we can use the official redis image
+
+- For the 4 others, we need to build images and push them to some registry
+
+---
+
+## Building and shipping images
+
+- There are *many* options!
+
+- Manually:
+
+  - build locally (with `docker build` or otherwise)
+
+  - push to the registry
+
+- Automatically:
+
+  - build and test locally
+
+  - when ready, commit and push a code repository
+
+  - the code repository notifies an automated build system
+
+  - that system gets the code, builds it, pushes the image to the registry
+
+---
+
+## Which registry do we want to use?
+
+- There are SAAS products like Docker Hub, Quay ...
+
+- Each major cloud provider has an option as well
+
+  (ACR on Azure, ECR on AWS, GCR on Google Cloud...)
+
+- There are also commercial products to run our own registry
+
+  (Docker EE, Quay...)
+
+- And open source options, too!
+
+- When picking a registry, pay attention to its build system
+
+  (when it has one)

slides/k8s/staticpods.md

@@ -192,6 +192,8 @@ We should see YAML files corresponding to the pods of the control plane.
 
 ---
 
+class: static-pods-exercise
+
 ## Running a static pod
 
 - We are going to add a pod manifest to the directory, and kubelet will run it
@@ -214,6 +216,8 @@ The output should include a pod named `hello-node1`.
 
 ---
 
+class: static-pods-exercise
+
 ## Remarks
 
 In the manifest, the pod was named `hello`.

slides/k8s/versions-k8s.md

@@ -1,7 +1,7 @@
 ## Versions installed
 
-- Kubernetes 1.13.4
-- Docker Engine 18.09.3
+- Kubernetes 1.14.1
+- Docker Engine 18.09.5
 - Docker Compose 1.21.1
 
 <!-- ##VERSION## -->
@@ -23,13 +23,13 @@ class: extra-details
 
 ## Kubernetes and Docker compatibility
 
-- Kubernetes 1.13.x only validates Docker Engine versions [up to 18.06](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.13.md#external-dependencies)
+- Kubernetes 1.14 validates Docker Engine versions [up to 18.09](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.14.md#external-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)
 
-class: extra-details
-
-- Are we living dangerously?
+- Is this a problem if I use Kubernetes with a "too recent" Docker Engine?
 
 --
 

slides/k8s/whatsnext.md

@@ -223,44 +223,6 @@ And *then* it is time to look at orchestration!
 
 ---
 
-## Cluster federation
-
---
-
-![Star Trek Federation](images/startrek-federation.jpg)
-
---
-
-Sorry Star Trek fans, this is not the federation you're looking for!
-
---
-
-(If I add "Your cluster is in another federation" I might get a 3rd fandom wincing!)
-
----
-
-## Cluster federation
-
-- Kubernetes master operation relies on etcd
-
-- etcd uses the [Raft](https://raft.github.io/) protocol
-
-- Raft recommends low latency between nodes
-
-- What if our cluster spreads to multiple regions?
-
---
-
-- Break it down in local clusters
-
-- Regroup them in a *cluster federation*
-
-- Synchronize resources across clusters
-
-- Discover resources across clusters
-
----
-
 ## Developer experience
 
 *We've put this last, but it's pretty important!*

slides/kube-admin-one.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
+  #FIXME: check le talk de Laurent Corbes pour voir s'il y a d'autres choses utiles à mentionner
+  #BONUS: intégration CoreDNS pour résoudre les noms des clusters des voisins
+- - 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/lastwords-admin.md
+  - k8s/links.md
+  - shared/thankyou.md

slides/kube-fullday.yml

@@ -1,15 +1,15 @@
 title: |
-  Getting Started
-  With Kubernetes and
-  Container Orchestration
+  Getting started with
+  Kubernetes and
+  container orchestration
 
 #chat: "[Slack](https://dockercommunity.slack.com/messages/C7GKACWDV)"
-chat: "[Gitter](https://gitter.im/jpetazzo/workshop-20190307-london)"
+chat: "[Gitter](https://gitter.im/jpetazzo/workshop-20190501)"
 #chat: "In person!"
 
 gitrepo: github.com/jpetazzo/container.training
 
-slides: http://qconuk2019.container.training/
+slides: http://pycon2019.container.training/
 
 exclude:
 - self-paced
@@ -21,41 +21,48 @@ chapters:
 - shared/about-slides.md
 - shared/toc.md
 - - shared/prereqs.md
-  - k8s/versions-k8s.md
+#  - k8s/versions-k8s.md
   - shared/sampleapp.md
-  - shared/composescale.md
+#  - shared/composescale.md
+#  - shared/hastyconclusions.md
   - shared/composedown.md
   - k8s/concepts-k8s.md
   - shared/declarative.md
   - k8s/declarative.md
-- - k8s/kubenet.md
+  - k8s/kubenet.md
   - k8s/kubectlget.md
-  - k8s/setup-k8s.md
+#  - k8s/setup-k8s.md
   - k8s/kubectlrun.md
-  - k8s/kubectlexpose.md
-- - k8s/ourapponkube.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/dashboard.md
+#  - k8s/kubectlscale.md
+  - k8s/scalingdockercoins.md
+  - shared/hastyconclusions.md
   - k8s/daemonset.md
-- - k8s/rollout.md
+  - k8s/rollout.md
 #  - k8s/healthchecks.md
-  - k8s/logs-cli.md
-  - k8s/logs-centralized.md
+#  - k8s/logs-cli.md
+#  - k8s/logs-centralized.md
 #- - k8s/helm.md
 #  - k8s/namespaces.md
 #  - k8s/netpol.md
 #  - k8s/authn-authz.md
 #- - k8s/ingress.md
 #  - k8s/gitworkflows.md
-  - k8s/prometheus.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/portworx.md
 - - k8s/whatsnext.md

slides/kube-halfday.yml

@@ -26,6 +26,7 @@ chapters:
   - 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
@@ -35,12 +36,17 @@ chapters:
   - k8s/setup-k8s.md
 - - k8s/kubectlrun.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/kubectlscale.md
+  - k8s/scalingdockercoins.md
+  - shared/hastyconclusions.md
   - k8s/daemonset.md
   - k8s/rollout.md
 - - k8s/logs-cli.md

slides/kube-selfpaced.yml

@@ -23,6 +23,7 @@ chapters:
   - k8s/versions-k8s.md
   - shared/sampleapp.md
   - shared/composescale.md
+  - shared/hastyconclusions.md
   - shared/composedown.md
   - k8s/concepts-k8s.md
   - shared/declarative.md
@@ -32,12 +33,17 @@ chapters:
   - k8s/setup-k8s.md
   - k8s/kubectlrun.md
   - k8s/kubectlexpose.md
-- - k8s/ourapponkube.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/healthchecks.md
@@ -55,6 +61,7 @@ chapters:
   - k8s/build-with-kaniko.md
   - k8s/configuration.md
 - - k8s/owners-and-dependents.md
+  - k8s/extending-api.md
   - k8s/statefulsets.md
   - k8s/portworx.md
   - k8s/staticpods.md

slides/kube-twodays.yml

@@ -22,7 +22,8 @@ chapters:
 - - shared/prereqs.md
   - k8s/versions-k8s.md
   - shared/sampleapp.md
-  - shared/composescale.md
+  #- shared/composescale.md
+  #- shared/hastyconclusions.md
   - shared/composedown.md
   - k8s/concepts-k8s.md
   - shared/declarative.md
@@ -32,12 +33,17 @@ chapters:
   - k8s/setup-k8s.md
   - k8s/kubectlrun.md
   - k8s/kubectlexpose.md
-- - k8s/ourapponkube.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/kubectlscale.md
+  - k8s/scalingdockercoins.md
+  - shared/hastyconclusions.md
 - - k8s/daemonset.md
   - k8s/rollout.md
   - k8s/healthchecks.md
@@ -48,14 +54,15 @@ chapters:
   - k8s/netpol.md
   - k8s/authn-authz.md
 - - k8s/ingress.md
-  - k8s/gitworkflows.md
+  #- k8s/gitworkflows.md
   - k8s/prometheus.md
 - - k8s/volumes.md
-  - k8s/build-with-docker.md
-  - k8s/build-with-kaniko.md
+  #- k8s/build-with-docker.md
+  #- k8s/build-with-kaniko.md
   - k8s/configuration.md
-- - k8s/owners-and-dependents.md
-  - k8s/statefulsets.md
+  #- k8s/owners-and-dependents.md
+  - k8s/extending-api.md
+- - k8s/statefulsets.md
   - k8s/portworx.md
   - k8s/staticpods.md
 - - k8s/whatsnext.md

slides/logistics.md

@@ -6,11 +6,9 @@
 
    - .emoji[🐳] Jérôme ([@jpetazzo](https://twitter.com/jpetazzo), Enix SAS)
 
-- The workshop will run from 9am to 4pm
+- The workshop will run from 9:00am to 12:20pm
 
-- There will be a lunch break at noon
-
-  (And coffee breaks at 10:30am and 2:30pm)
+- There will be a short coffee break at 10:30am
 
 - Feel free to interrupt for questions at any time
 

slides/markmaker.py

@@ -1,4 +1,4 @@
-#!/usr/bin/env python3
+#!/usr/bin/env python2
 # transforms a YAML manifest into a HTML workshop file
 
 import glob
@@ -14,31 +14,18 @@ import yaml
 logging.basicConfig(level=os.environ.get("LOG_LEVEL", "INFO"))
 
 
-class InvalidChapter(ValueError):
-
-    def __init__(self, chapter):
-        ValueError.__init__(self, "Invalid chapter: {!r}".format(chapter))
-
-
 def anchor(title):
     title = title.lower().replace(' ', '-')
     title = ''.join(c for c in title if c in string.ascii_letters+'-')
     return "toc-" + title
 
 
-class Interstitials(object):
-
-    def __init__(self):
-        self.index = 0
-        self.images = [url.strip() for url in open("interstitials.txt") if url.strip()]
-
-    def next(self):
-        index = self.index % len(self.images)
-        index += 1
-        return self.images[index]
-
-
-interstitials = Interstitials()
+def interstitials_generator():
+    images = [url.strip() for url in open("interstitials.txt") if url.strip()]
+    while True:
+        for image in images:
+            yield image
+interstitials = interstitials_generator()
 
 
 def insertslide(markdown, title):
@@ -166,6 +153,8 @@ def gentoc(tree, path=()):
 # Returns: (epxandedmarkdown,[list of titles])
 # The list of titles can be nested.
 def processchapter(chapter, filename):
+    if isinstance(chapter, unicode):
+        return processchapter(chapter.encode("utf-8"), filename)
     if isinstance(chapter, str):
         if "\n" in chapter:
             titles = re.findall("^# (.*)", chapter, re.MULTILINE)
@@ -180,7 +169,8 @@ def processchapter(chapter, filename):
         markdown = "\n---\n".join(c[0] for c in chapters)
         titles = [t for (m,t) in chapters if t]
         return (markdown, titles)
-    raise InvalidChapter(chapter)
+    logging.warning("Invalid chapter: {}".format(chapter))
+    return "```\nInvalid chapter: {}\n```\n".format(chapter), []
 
 # Try to figure out the URL of the repo on GitHub.
 # This is used to generate "edit me on GitHub"-style links.
@@ -188,14 +178,14 @@ try:
     if "REPOSITORY_URL" in os.environ:
         repo = os.environ["REPOSITORY_URL"]
     else:
-        repo = subprocess.check_output(["git", "config", "remote.origin.url"]).decode("ascii")
+        repo = subprocess.check_output(["git", "config", "remote.origin.url"])
     repo = repo.strip().replace("git@github.com:", "https://github.com/")
     if "BRANCH" in os.environ:
         branch = os.environ["BRANCH"]
     else:
-        branch = subprocess.check_output(["git", "rev-parse", "--abbrev-ref", "HEAD"]).decode("ascii")
+        branch = subprocess.check_output(["git", "rev-parse", "--abbrev-ref", "HEAD"])
         branch = branch.strip()
-    base = subprocess.check_output(["git", "rev-parse", "--show-prefix"]).decode("ascii")
+    base = subprocess.check_output(["git", "rev-parse", "--show-prefix"])
     base = base.strip().strip("/")
     urltemplate = ("{repo}/tree/{branch}/{base}/{filename}"
         .format(repo=repo, branch=branch, base=base, filename="{}"))
@@ -203,12 +193,12 @@ except:
     logging.exception("Could not generate repository URL; generating local URLs instead.")
     urltemplate = "file://{pwd}/{filename}".format(pwd=os.environ["PWD"], filename="{}")
 try:
-    commit = subprocess.check_output(["git", "rev-parse", "--short", "HEAD"]).decode("ascii")
+    commit = subprocess.check_output(["git", "rev-parse", "--short", "HEAD"])
 except:
     logging.exception("Could not figure out HEAD commit.")
     commit = "??????"
 try:
-    dirtyfiles = subprocess.check_output(["git", "status", "--porcelain"]).decode("ascii")
+    dirtyfiles = subprocess.check_output(["git", "status", "--porcelain"])
 except:
     logging.exception("Could not figure out repository cleanliness.")
     dirtyfiles = "?? git status --porcelain failed"

slides/runtime.txt

@@ -1 +0,0 @@
-3.7

slides/shared/composescale.md

@@ -202,19 +202,3 @@ We will use `httping`.
 ]
 
 `rng` has a much higher latency than `hasher`.
-
----
-
-## Let's draw hasty conclusions
-
-- The bottleneck seems to be `rng`
-
-- *What if* we don't have enough entropy and can't generate enough random numbers?
-
-- We need to scale out the `rng` service on multiple machines!
-
-Note: this is a fiction! We have enough entropy. But we need a pretext to scale out.
-
-(In fact, the code of `rng` uses `/dev/urandom`, which never runs out of entropy...
-<br/>
-...and is [just as good as `/dev/random`](http://www.slideshare.net/PacSecJP/filippo-plain-simple-reality-of-entropy).)

slides/shared/hastyconclusions.md

@@ -0,0 +1,13 @@
+## Let's draw hasty conclusions
+
+- The bottleneck seems to be `rng`
+
+- *What if* we don't have enough entropy and can't generate enough random numbers?
+
+- We need to scale out the `rng` service on multiple machines!
+
+Note: this is a fiction! We have enough entropy. But we need a pretext to scale out.
+
+(In fact, the code of `rng` uses `/dev/urandom`, which never runs out of entropy...
+<br/>
+...and is [just as good as `/dev/random`](http://www.slideshare.net/PacSecJP/filippo-plain-simple-reality-of-entropy).)

slides/shared/sampleapp.md

@@ -165,26 +165,6 @@ https://@@GITREPO@@/blob/8279a3bce9398f7c1a53bdd95187c53eda4e6435/dockercoins/wo
 
 ---
 
-class: extra-details
-
-## Links, naming, and service discovery
-
-- Containers can have network aliases (resolvable through DNS)
-
-- Compose file version 2+ makes each container reachable through its service name
-
-- Compose file version 1 did require "links" sections
-
-- Network aliases are automatically namespaced
-
-  - you can have multiple apps declaring and using a service named `database`
-
-  - containers in the blue app will resolve `database` to the IP of the blue database
-
-  - containers in the green app will resolve `database` to the IP of the green database
-
----
-
 ## Show me the code!
 
 - You can check the GitHub repository with all the materials of this workshop:
@@ -210,24 +190,6 @@ class: extra-details
 
 ---
 
-class: extra-details
-
-## Compose file format version
-
-*This is relevant only if you have used Compose before 2016...*
-
-- Compose 1.6 introduced support for a new Compose file format (aka "v2")
-
-- Services are no longer at the top level, but under a `services` section
-
-- There has to be a `version` key at the top level, with value `"2"` (as a string, not an integer)
-
-- Containers are placed on a dedicated network, making links unnecessary
-
-- There are other minor differences, but upgrade is easy and straightforward
-
----
-
 ## Our application at work
 
 - On the left-hand side, the "rainbow strip" shows the container names

slides/shared/thankyou.md

@@ -14,15 +14,21 @@ That's all, folks! <br/> Questions?
 
 ## Final words
 
+- Please **rate this workshop**:
+
+  https://www.surveymonkey.com/r/SDFL3PS
+
 - You can find more content on http://container.training/
 
   (More slides, videos, dates of upcoming workshops and tutorials...)
 
+- This workshop is also available as longer training sessions:
+
+  - [two-day Kubernetes bootstrap](https://tinyshellscript.com/kubernetes-bootstrap.html)
+
+  - [four-day Kubernetes administrator training](https://tinyshellscript.com/kubernetes-ops-week.html)
+
 - If you want me to train your team:
   [contact me!](https://docs.google.com/forms/d/e/1FAIpQLScm2evHMvRU8C5ZK59l8FGsLY_Kkup9P_GHgjfByUMyMpMmDA/viewform)
 
-  (This workshop is also available as longer training sessions, covering advanced topics)
-
-- The organizers of this conference would like you to rate this workshop!
-
-.footnote[*Thank you!*]
+.footnote[*Thank you!*]

slides/swarm-fullday.yml

@@ -27,6 +27,7 @@ chapters:
   - swarm/versions.md
   - shared/sampleapp.md
   - shared/composescale.md
+  - shared/hastyconclusions.md
   - shared/composedown.md
   - swarm/swarmkit.md
   - shared/declarative.md

slides/swarm-halfday.yml

@@ -27,6 +27,7 @@ chapters:
   - swarm/versions.md
   - shared/sampleapp.md
   - shared/composescale.md
+  - shared/hastyconclusions.md
   - shared/composedown.md
   - swarm/swarmkit.md
   - shared/declarative.md

slides/swarm-selfpaced.yml

@@ -28,6 +28,7 @@ chapters:
     Part 1
   - shared/sampleapp.md
   - shared/composescale.md
+  - shared/hastyconclusions.md
   - shared/composedown.md
   - swarm/swarmkit.md
   - shared/declarative.md

slides/swarm-video.yml

@@ -28,6 +28,7 @@ chapters:
     Part 1
   - shared/sampleapp.md
   - shared/composescale.md
+  - shared/hastyconclusions.md
   - shared/composedown.md
   - swarm/swarmkit.md
   - shared/declarative.md