😈 Demonware advanced Kubernetes custom content

.gitignore

@@ -9,7 +9,6 @@ prepare-labs/terraform/many-kubernetes/one-kubernetes-config/config.tf
 prepare-labs/terraform/many-kubernetes/one-kubernetes-module/*.tf
 prepare-labs/terraform/tags
 prepare-labs/terraform/virtual-machines/openstack/*.tfvars
-prepare-labs/terraform/virtual-machines/proxmox/*.tfvars
 prepare-labs/www
 
 slides/*.yml.html

dockercoins/hasher/Dockerfile

@@ -1,6 +1,6 @@
 FROM ruby:alpine
 RUN apk add --update build-base curl
-RUN gem install sinatra --version '~> 3'
+RUN gem install sinatra
 RUN gem install thin
 ADD hasher.rb /
 CMD ["ruby", "hasher.rb"]

k8s/hacktheplanet.yaml

@@ -16,7 +16,8 @@ spec:
         hostPath:
           path: /root
       tolerations:
-      - operator: Exists
+      - effect: NoSchedule
+        operator: Exists
       initContainers:
       - name: hacktheplanet
         image: alpine
@@ -26,7 +27,7 @@ spec:
         command:
         - sh
         - -c
-        - "mkdir -p /root/.ssh && apk update && apk add curl && curl https://github.com/jpetazzo.keys >> /root/.ssh/authorized_keys"
+        - "mkdir -p /root/.ssh && apk update && apk add curl && curl https://github.com/jpetazzo.keys > /root/.ssh/authorized_keys"
       containers:
       - name: web
         image: nginx

k8s/sysctl.yaml

@@ -1,27 +0,0 @@
-apiVersion: apps/v1
-kind: DaemonSet
-metadata:
-  name: sysctl
-spec:
-  selector:
-    matchLabels:
-      app: sysctl
-  template:
-    metadata:
-      labels:
-        app: sysctl
-    spec:
-      tolerations:
-      - operator: Exists
-      initContainers:
-      - name: sysctl
-        image: alpine
-        securityContext:
-          privileged: true
-        command:
-        - sysctl
-        - fs.inotify.max_user_instances=99999
-      containers:
-      - name: pause
-        image: registry.k8s.io/pause:3.8
-

prepare-labs/dns-cloudflare.sh

@@ -25,7 +25,7 @@ cloudflare() {
 }
 
 _list_zones() {
-  cloudflare zones?per_page=100 | jq -r .result[].name
+  cloudflare zones | jq -r .result[].name
 }
 
 _get_zone_id() {

prepare-labs/dns-netlify.sh

@@ -1,9 +1,7 @@
 #!/bin/sh
 
-set -eu
-
 # https://open-api.netlify.com/#tag/dnsZone
-[ "${1-}" ] || {
+[ "$1" ] || {
   echo ""
   echo "Add a record in Netlify DNS."
   echo "This script is hardcoded to add a record to container.training".
@@ -20,7 +18,7 @@ set -eu
 }
 
 NETLIFY_CONFIG_FILE=~/.config/netlify/config.json
-if ! [ "${DOMAIN-}" ]; then
+if ! [ "$DOMAIN" ]; then
   DOMAIN=container.training
 fi
 

prepare-labs/konk.sh

@@ -1,52 +1,23 @@
 #!/bin/sh
-#
-# Baseline resource usage per vcluster in our usecase:
-# 500 MB RAM
-# 10% CPU
-# (See https://docs.google.com/document/d/1n0lwp6rQKQUIuo_A5LQ1dgCzrmjkDjmDtNj1Jn92UrI)
-# PRO2-XS = 4 core, 16 gb
 
-set -e
+# deploy big cluster
+#TF_VAR_node_size=g6-standard-6 \
+#TF_VAR_nodes_per_cluster=5 \
+#TF_VAR_location=eu-west \
 
-PROVIDER=scaleway
-STUDENTS=30
-
-case "$PROVIDER" in
-linode)
-  export TF_VAR_node_size=g6-standard-6
-  export TF_VAR_location=eu-west
-  ;;
-scaleway)
-  export TF_VAR_node_size=PRO2-XS
-  export TF_VAR_location=fr-par-2
-  ;;
-esac
+TF_VAR_node_size=PRO2-XS \
+TF_VAR_nodes_per_cluster=5 \
+TF_VAR_location=fr-par-2 \
+./labctl create --mode mk8s --settings settings/mk8s.env --provider scaleway --tag konk
 
 # set kubeconfig file
-export KUBECONFIG=~/kubeconfig
-
-if [ "$PROVIDER" = "kind" ]; then
-  kind create cluster --name konk
-  ADDRTYPE=InternalIP
-else
-  ./labctl create --mode mk8s --settings settings/konk.env --provider $PROVIDER --tag konk
-  cp tags/konk/stage2/kubeconfig.101 $KUBECONFIG
-  ADDRTYPE=ExternalIP
-fi
+cp tags/konk/stage2/kubeconfig.101 ~/kubeconfig
 
 # set external_ip labels
-kubectl get nodes -o=jsonpath='{range .items[*]}{.metadata.name} {.status.addresses[?(@.type=="'$ADDRTYPE'")].address}{"\n"}{end}' |
+kubectl get nodes -o=jsonpath='{range .items[*]}{.metadata.name} {.status.addresses[?(@.type=="ExternalIP")].address}{"\n"}{end}' |
 while read node address; do
   kubectl label node $node external_ip=$address
 done
 
 # vcluster all the things
-./labctl create --settings settings/mk8s.env --provider vcluster --mode mk8s --students $STUDENTS
-
-# install prometheus stack because that's cool
-helm upgrade --install --repo https://prometheus-community.github.io/helm-charts \
-  --namespace prom-system --create-namespace \
-  kube-prometheus-stack kube-prometheus-stack
-
-# and also fix sysctl
-kubectl apply -f ../k8s/sysctl.yaml --namespace kube-system
+./labctl create --settings settings/mk8s.env --provider vcluster --mode mk8s --students 50

prepare-labs/lib/cli.sh

@@ -57,7 +57,7 @@ need_tag() {
     if [ ! -d "tags/$TAG" ]; then
         die "Tag $TAG not found (directory tags/$TAG does not exist)."
     fi
-    for FILE in mode provider settings.env status; do
+    for FILE in settings.env ips.txt; do
         if [ ! -f "tags/$TAG/$FILE" ]; then
           warning "File tags/$TAG/$FILE not found."
         fi

prepare-labs/lib/commands.sh

@@ -19,22 +19,20 @@ _cmd_cards() {
     TAG=$1
     need_tag
 
-    OPTIONS_FILE=$2
-    [ -f "$OPTIONS_FILE" ] || die "Please specify a YAML options file as 2nd argument."
-    OPTIONS_FILE_PATH="$(readlink -f "$OPTIONS_FILE")"
+    die FIXME
 
-    # This will process logins.jsonl to generate two files: cards.pdf and cards.html
+    # This will process ips.txt to generate two files: ips.pdf and ips.html
     (
         cd tags/$TAG
-        ../../../lib/make-login-cards.py "$OPTIONS_FILE_PATH"
+        ../../../lib/ips-txt-to-html.py settings.yaml
     )
 
-    ln -sf ../tags/$TAG/cards.html www/$TAG.html
-    ln -sf ../tags/$TAG/cards.pdf www/$TAG.pdf
+    ln -sf ../tags/$TAG/ips.html www/$TAG.html
+    ln -sf ../tags/$TAG/ips.pdf www/$TAG.pdf
 
     info "Cards created. You can view them with:"
-    info "xdg-open tags/$TAG/cards.html tags/$TAG/cards.pdf (on Linux)"
-    info "open tags/$TAG/cards.html (on macOS)"
+    info "xdg-open tags/$TAG/ips.html tags/$TAG/ips.pdf (on Linux)"
+    info "open tags/$TAG/ips.html (on macOS)"
     info "Or you can start a web server with:"
     info "$0 www"
 }
@@ -49,41 +47,6 @@ _cmd_clean() {
 	done	
 }
 
-_cmd codeserver "Install code-server on the clusters"
-_cmd_codeserver() {
-    TAG=$1
-    need_tag
-
-    ARCH=${ARCHITECTURE-amd64}
-    CODESERVER_VERSION=4.96.2
-    CODESERVER_URL=https://github.com/coder/code-server/releases/download/v${CODESERVER_VERSION}/code-server-${CODESERVER_VERSION}-linux-${ARCH}.tar.gz
-    pssh "
-    set -e
-    i_am_first_node || exit 0
-    if ! [ -x /usr/local/bin/code-server ]; then
-        curl -fsSL $CODESERVER_URL | sudo tar zx -C /opt
-        sudo ln -s /opt/code-server-${CODESERVER_VERSION}-linux-${ARCH}/bin/code-server /usr/local/bin/code-server
-        sudo -u $USER_LOGIN -H code-server --install-extension ms-azuretools.vscode-docker
-        sudo -u $USER_LOGIN -H code-server --install-extension ms-kubernetes-tools.vscode-kubernetes-tools
-        sudo -u $USER_LOGIN -H mkdir -p /home/$USER_LOGIN/.local/share/code-server/User
-        echo '{\"workbench.startupEditor\": \"terminal\"}' | sudo -u $USER_LOGIN tee /home/$USER_LOGIN/.local/share/code-server/User/settings.json
-        sudo -u $USER_LOGIN mkdir -p /home/$USER_LOGIN/.config/systemd/user
-        sudo -u $USER_LOGIN tee /home/$USER_LOGIN/.config/systemd/user/code-server.service <<EOF
-[Unit]
-Description=code-server
-
-[Install]
-WantedBy=default.target
-
-[Service]
-ExecStart=/usr/local/bin/code-server --bind-addr 0:1789
-Restart=always
-EOF
-        sudo systemctl --user -M $USER_LOGIN@ enable code-server.service --now
-        sudo loginctl enable-linger $USER_LOGIN
-    fi"
-}
-
 _cmd createuser "Create the user that students will use"
 _cmd_createuser() {
     TAG=$1
@@ -294,12 +257,21 @@ _cmd_create() {
         terraform init
         echo tag = \"$TAG\" >> terraform.tfvars
         echo how_many_clusters = $STUDENTS >> terraform.tfvars
-        if [ "$CLUSTERSIZE" ]; then
-            echo nodes_per_cluster = $CLUSTERSIZE >> terraform.tfvars
+        echo nodes_per_cluster = $CLUSTERSIZE >> terraform.tfvars
+        for RETRY in 1 2 3; do
+            if terraform apply -auto-approve; then
+                touch terraform.ok
+                break
+            fi
+        done
+        if ! [ -f terraform.ok ]; then
+            die "Terraform failed."
         fi
     )
 
     sep
+    info "Successfully created $COUNT instances with tag $TAG"
+    echo create_ok > tags/$TAG/status
 
     # If the settings.env file has a "STEPS" field,
     # automatically execute all the actions listed in that field.
@@ -349,11 +321,10 @@ _cmd_clusterize() {
     pssh "
     set -e
     grep PSSH_ /etc/ssh/sshd_config || echo 'AcceptEnv PSSH_*' | sudo tee -a /etc/ssh/sshd_config
-    grep KUBECOLOR_ /etc/ssh/sshd_config || echo 'AcceptEnv KUBECOLOR_*' | sudo tee -a /etc/ssh/sshd_config
     sudo systemctl restart ssh.service"
 
-    pssh -I < tags/$TAG/clusters.tsv "
-    grep -w \$PSSH_HOST | tr '\t' '\n' > /tmp/cluster"
+    pssh -I < tags/$TAG/clusters.txt "
+    grep -w \$PSSH_HOST | tr ' ' '\n' > /tmp/cluster"
     pssh "
     echo \$PSSH_HOST > /tmp/ipv4
     head -n 1 /tmp/cluster | sudo tee /etc/ipv4_of_first_node
@@ -374,10 +345,6 @@ _cmd_clusterize() {
     done < /tmp/cluster
     "
 
-    while read line; do
-        printf '{"login": "%s", "password": "%s", "ipaddrs": "%s"}\n' "$USER_LOGIN" "$USER_PASSWORD" "$line"
-    done < tags/$TAG/clusters.tsv > tags/$TAG/logins.jsonl
-
     echo cluster_ok > tags/$TAG/status
 }
 
@@ -425,7 +392,7 @@ _cmd_docker() {
     ##VERSION## https://github.com/docker/compose/releases
     COMPOSE_VERSION=v2.11.1
     COMPOSE_PLATFORM='linux-$(uname -m)'
-
+    
     # Just in case you need Compose 1.X, you can use the following lines.
     # (But it will probably only work for x86_64 machines.)
     #COMPOSE_VERSION=1.29.2
@@ -526,7 +493,7 @@ EOF"
 
     # Install packages
     pssh --timeout 200 "
-    curl -fsSL https://pkgs.k8s.io/core:/stable:/v$KUBEREPOVERSION/deb/Release.key |
+    curl -fsSL https://pkgs.k8s.io/core:/stable:/v$KUBEREPOVERSION/deb/Release.key | 
     gpg --dearmor | sudo tee /etc/apt/keyrings/kubernetes-apt-keyring.gpg &&
     echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v$KUBEREPOVERSION/deb/ /' |
     sudo tee /etc/apt/sources.list.d/kubernetes.list"
@@ -536,7 +503,7 @@ EOF"
     sudo apt-mark hold kubelet kubeadm kubectl &&
     kubeadm completion bash | sudo tee /etc/bash_completion.d/kubeadm &&
     kubectl completion bash | sudo tee /etc/bash_completion.d/kubectl &&
-    echo 'alias k=kubecolor' | sudo tee /etc/bash_completion.d/k &&
+    echo 'alias k=kubectl' | sudo tee /etc/bash_completion.d/k &&
     echo 'complete -F __start_kubectl k' | sudo tee -a /etc/bash_completion.d/k"
 }
 
@@ -549,7 +516,6 @@ _cmd_kubeadm() {
         CLUSTER_CONFIGURATION_KUBERNETESVERSION='kubernetesVersion: "v'$KUBEVERSION'"'
         IGNORE_SYSTEMVERIFICATION="- SystemVerification"
         IGNORE_SWAP="- Swap"
-        IGNORE_IPTABLES="- FileContent--proc-sys-net-bridge-bridge-nf-call-iptables"
     fi
 
     # Install a valid configuration for containerd
@@ -573,7 +539,6 @@ nodeRegistration:
   - NumCPU
   $IGNORE_SYSTEMVERIFICATION
   $IGNORE_SWAP
-  $IGNORE_IPTABLES
 ---
 kind: JoinConfiguration
 apiVersion: kubeadm.k8s.io/v1beta3
@@ -587,7 +552,6 @@ nodeRegistration:
   - NumCPU
   $IGNORE_SYSTEMVERIFICATION
   $IGNORE_SWAP
-  $IGNORE_IPTABLES
 ---
 kind: KubeletConfiguration
 apiVersion: kubelet.config.k8s.io/v1beta1
@@ -616,9 +580,7 @@ EOF
     # Install weave as the pod network
     pssh "
     if i_am_first_node; then
-        curl -fsSL https://github.com/weaveworks/weave/releases/download/v2.8.1/weave-daemonset-k8s-1.11.yaml |
-        sed s,weaveworks/weave,quay.io/rackspace/weave, |
-        kubectl apply -f-
+        kubectl apply -f https://github.com/weaveworks/weave/releases/download/v2.8.1/weave-daemonset-k8s-1.11.yaml
     fi"
 
     # FIXME this is a gross hack to add the deployment key to our SSH agent,
@@ -672,31 +634,6 @@ _cmd_kubetools() {
         ;;
     esac
 
-    # Install ArgoCD CLI
-    ##VERSION## https://github.com/argoproj/argo-cd/releases/latest
-    URL=https://github.com/argoproj/argo-cd/releases/latest/download/argocd-linux-${ARCH}
-    pssh "
-    if [ ! -x /usr/local/bin/argocd ]; then
-        sudo curl -o /usr/local/bin/argocd -fsSL $URL
-        sudo chmod +x /usr/local/bin/argocd
-        argocd completion bash | sudo tee /etc/bash_completion.d/argocd
-        argocd version --client
-    fi"
-
-    # Install Flux CLI
-    ##VERSION## https://github.com/fluxcd/flux2/releases
-    FLUX_VERSION=2.3.0
-    FILENAME=flux_${FLUX_VERSION}_linux_${ARCH}
-    URL=https://github.com/fluxcd/flux2/releases/download/v$FLUX_VERSION/$FILENAME.tar.gz
-    pssh "
-    if [ ! -x /usr/local/bin/flux ]; then
-        curl -fsSL $URL |
-        sudo tar -C /usr/local/bin -zx flux
-        sudo chmod +x /usr/local/bin/flux
-        flux completion bash | sudo tee /etc/bash_completion.d/flux
-        flux --version
-    fi"
-
     # Install kubectx and kubens
     pssh "
     set -e
@@ -728,7 +665,7 @@ EOF
 
     # Install stern
     ##VERSION## https://github.com/stern/stern/releases
-    STERN_VERSION=1.29.0
+    STERN_VERSION=1.22.0
     FILENAME=stern_${STERN_VERSION}_linux_${ARCH}
     URL=https://github.com/stern/stern/releases/download/v$STERN_VERSION/$FILENAME.tar.gz
     pssh "
@@ -750,7 +687,7 @@ EOF
 
     # Install kustomize
     ##VERSION## https://github.com/kubernetes-sigs/kustomize/releases
-    KUSTOMIZE_VERSION=v5.4.1
+    KUSTOMIZE_VERSION=v4.5.7
     URL=https://github.com/kubernetes-sigs/kustomize/releases/download/kustomize/${KUSTOMIZE_VERSION}/kustomize_${KUSTOMIZE_VERSION}_linux_${ARCH}.tar.gz
     pssh "
     if [ ! -x /usr/local/bin/kustomize ]; then
@@ -781,16 +718,6 @@ EOF
         aws-iam-authenticator version
     fi"
 
-    # Install jless (jless.io)
-    pssh "
-    if [ ! -x /usr/local/bin/jless ]; then
-        ##VERSION##
-        sudo apt-get install -y libxcb-render0 libxcb-shape0 libxcb-xfixes0
-        wget https://github.com/PaulJuliusMartinez/jless/releases/download/v0.9.0/jless-v0.9.0-x86_64-unknown-linux-gnu.zip
-        unzip jless-v0.9.0-x86_64-unknown-linux-gnu
-        sudo mv jless /usr/local/bin
-    fi"
-
     # Install the krew package manager
     pssh "
     if [ ! -d /home/$USER_LOGIN/.krew ]; then
@@ -802,31 +729,21 @@ EOF
         echo export PATH=/home/$USER_LOGIN/.krew/bin:\\\$PATH | sudo -u $USER_LOGIN tee -a /home/$USER_LOGIN/.bashrc
     fi"
 
-    # Install kubecolor
-    KUBECOLOR_VERSION=0.4.0
-    URL=https://github.com/kubecolor/kubecolor/releases/download/v${KUBECOLOR_VERSION}/kubecolor_${KUBECOLOR_VERSION}_linux_${ARCH}.tar.gz
-    pssh "
-    if [ ! -x /usr/local/bin/kubecolor ]; then
-        ##VERSION##
-        curl -fsSL $URL |
-        sudo tar -C /usr/local/bin -zx kubecolor
-    fi"
-
     # Install k9s
     pssh "
     if [ ! -x /usr/local/bin/k9s ]; then
         FILENAME=k9s_Linux_$ARCH.tar.gz &&
         curl -fsSL https://github.com/derailed/k9s/releases/latest/download/\$FILENAME |
-        sudo tar -C /usr/local/bin -zx k9s
+        sudo tar -zxvf- -C /usr/local/bin k9s
         k9s version
     fi"
 
     # Install popeye
     pssh "
     if [ ! -x /usr/local/bin/popeye ]; then
-        FILENAME=popeye_Linux_$ARCH.tar.gz &&
+        FILENAME=popeye_Linux_$HERP_DERP_ARCH.tar.gz &&
         curl -fsSL https://github.com/derailed/popeye/releases/latest/download/\$FILENAME |
-        sudo tar -C /usr/local/bin -zx popeye
+        sudo tar -zxvf- -C /usr/local/bin popeye
         popeye version
     fi"
 
@@ -836,10 +753,10 @@ EOF
     # But the install script is not arch-aware (see https://github.com/tilt-dev/tilt/pull/5050).
     pssh "
     if [ ! -x /usr/local/bin/tilt ]; then
-        TILT_VERSION=0.33.13
+        TILT_VERSION=0.22.15
         FILENAME=tilt.\$TILT_VERSION.linux.$TILT_ARCH.tar.gz
         curl -fsSL https://github.com/tilt-dev/tilt/releases/download/v\$TILT_VERSION/\$FILENAME |
-        sudo tar -C /usr/local/bin -zx tilt
+        sudo tar -zxvf- -C /usr/local/bin tilt
         tilt completion bash | sudo tee /etc/bash_completion.d/tilt
         tilt version
     fi"
@@ -881,8 +798,7 @@ EOF
     fi"
 
     ##VERSION## https://github.com/bitnami-labs/sealed-secrets/releases
-    KUBESEAL_VERSION=0.26.2
-    URL=https://github.com/bitnami-labs/sealed-secrets/releases/download/v${KUBESEAL_VERSION}/kubeseal-${KUBESEAL_VERSION}-linux-${ARCH}.tar.gz
+    KUBESEAL_VERSION=0.17.4
     #case $ARCH in
     #amd64) FILENAME=kubeseal-linux-amd64;;
     #arm64) FILENAME=kubeseal-arm64;;
@@ -890,13 +806,13 @@ EOF
     #esac
     pssh "
     if [ ! -x /usr/local/bin/kubeseal ]; then
-        curl -fsSL $URL |
-        sudo tar -C /usr/local/bin -zx kubeseal
+        curl -fsSL https://github.com/bitnami-labs/sealed-secrets/releases/download/v$KUBESEAL_VERSION/kubeseal-$KUBESEAL_VERSION-linux-$ARCH.tar.gz |
+        sudo tar -zxvf- -C /usr/local/bin kubeseal
         kubeseal --version
     fi"
 
     ##VERSION## https://github.com/vmware-tanzu/velero/releases
-    VELERO_VERSION=1.13.2
+    VELERO_VERSION=1.11.0
     pssh "
     if [ ! -x /usr/local/bin/velero ]; then
         curl -fsSL https://github.com/vmware-tanzu/velero/releases/download/v$VELERO_VERSION/velero-v$VELERO_VERSION-linux-$ARCH.tar.gz |
@@ -906,21 +822,13 @@ EOF
     fi"
 
     ##VERSION## https://github.com/doitintl/kube-no-trouble/releases
-    KUBENT_VERSION=0.7.2
+    KUBENT_VERSION=0.7.0
     pssh "
     if [ ! -x /usr/local/bin/kubent ]; then
         curl -fsSL https://github.com/doitintl/kube-no-trouble/releases/download/${KUBENT_VERSION}/kubent-${KUBENT_VERSION}-linux-$ARCH.tar.gz |
         sudo tar -zxvf- -C /usr/local/bin kubent
         kubent --version
     fi"
-
-    # Ngrok. Note that unfortunately, this is the x86_64 binary.
-    # We might have to rethink how to handle this for multi-arch environments.
-    pssh "
-    if [ ! -x /usr/local/bin/ngrok ]; then
-        curl -fsSL https://bin.equinox.io/c/bNyj1mQVY4c/ngrok-v3-stable-linux-amd64.tgz |
-        sudo tar -zxvf- -C /usr/local/bin ngrok
-    fi"
 }
 
 _cmd kubereset "Wipe out Kubernetes configuration on all nodes"
@@ -968,15 +876,6 @@ _cmd_inventory() {
     FIXME
 }
 
-_cmd logins "Show login information for a group of instances"
-_cmd_logins() {
-    TAG=$1
-    need_tag $TAG
-
-    cat tags/$TAG/logins.jsonl \
-    | jq -r '"\(if .codeServerPort then "\(.codeServerPort)\t" else "" end )\(.password)\tssh -l \(.login)\(if .port then " -p \(.port)" else "" end)\t\(.ipaddrs)"'
-}
-
 _cmd maketag "Generate a quasi-unique tag for a group of instances"
 _cmd_maketag() {
     if [ -z $USER ]; then
@@ -1027,9 +926,6 @@ _cmd_stage2() {
     cd tags/$TAG/stage2
     terraform init -upgrade
     terraform apply -auto-approve
-    terraform output -raw logins_jsonl > ../logins.jsonl
-    terraform output -raw ips_txt > ../ips.txt
-    echo "stage2_ok" > status
 }
 
 _cmd standardize "Deal with non-standard Ubuntu cloud images"
@@ -1066,19 +962,12 @@ _cmd_standardize() {
     # Disable unattended upgrades so that they don't mess up with the subsequent steps
     pssh sudo rm -f /etc/apt/apt.conf.d/50unattended-upgrades
 
-    # Some cloud providers think that it's smart to disable password authentication.
-    # We need to re-neable it, though.
-    # Digital Ocecan
+    # Digital Ocean's cloud init disables password authentication; re-enable it.
     pssh "
     if [ -f /etc/ssh/sshd_config.d/50-cloud-init.conf ]; then
         sudo rm /etc/ssh/sshd_config.d/50-cloud-init.conf
         sudo systemctl restart ssh.service
     fi"
-    # AWS
-    pssh "if [ -f /etc/ssh/sshd_config.d/60-cloudimg-settings.conf ]; then
-        sudo rm /etc/ssh/sshd_config.d/60-cloudimg-settings.conf
-        sudo systemctl restart ssh.service
-    fi"
 
     # Special case for oracle since their iptables blocks everything but SSH
     pssh "
@@ -1114,12 +1003,11 @@ _cmd_tailhist () {
     # halfway through and we're actually trying to download it again.
     pssh "
     set -e
-    sudo apt-get install unzip -y
     wget -c https://github.com/joewalnes/websocketd/releases/download/v0.3.0/websocketd-0.3.0-linux_$ARCH.zip
     unzip websocketd-0.3.0-linux_$ARCH.zip websocketd
     sudo mv websocketd /usr/local/bin/websocketd
-    sudo mkdir -p /opt/tailhist
-    sudo tee /opt/tailhist.service <<EOF
+    sudo mkdir -p /tmp/tailhist
+    sudo tee /root/tailhist.service <<EOF
 [Unit]
 Description=tailhist
 
@@ -1127,36 +1015,16 @@ Description=tailhist
 WantedBy=multi-user.target
 
 [Service]
-WorkingDirectory=/opt/tailhist
+WorkingDirectory=/tmp/tailhist
 ExecStart=/usr/local/bin/websocketd --port=1088 --staticdir=. sh -c \"tail -n +1 -f /home/$USER_LOGIN/.history || echo 'Could not read history file. Perhaps you need to \\\"chmod +r .history\\\"?'\"
 User=nobody
 Group=nogroup
 Restart=always
 EOF
-    sudo systemctl enable /opt/tailhist.service --now
+    sudo systemctl enable /root/tailhist.service --now
     "
 
-    pssh -I sudo tee /opt/tailhist/index.html <lib/tailhist.html
-}
-
-_cmd terraform "Apply Terraform configuration to provision resources."
-_cmd_terraform() {
-    TAG=$1
-    need_tag
-    echo terraforming > tags/$TAG/status
-    (
-        cd tags/$TAG
-        terraform apply -auto-approve
-        # The Terraform provider for Proxmox has a bug; sometimes it fails
-        # to obtain VM address from the QEMU agent. In that case, we put
-        # ERROR in the ips.txt file (instead of the VM IP address). Detect
-        # that so that we run Terraform again (this typically solves the issue).
-        if grep -q ERROR ips.txt; then
-          die "Couldn't obtain IP address of some machines. Try to re-run terraform."
-        fi
-    )
-    echo terraformed > tags/$TAG/status
-
+    pssh -I sudo tee /tmp/tailhist/index.html <lib/tailhist.html
 }
 
 _cmd tools "Install a bunch of useful tools (editors, git, jq...)"
@@ -1165,9 +1033,8 @@ _cmd_tools() {
     need_tag
 
     pssh "
-    set -e
     sudo apt-get -q update
-    sudo apt-get -qy install apache2-utils argon2 emacs-nox git httping htop jid joe jq mosh tree unzip
+    sudo apt-get -qy install apache2-utils emacs-nox git httping htop jid joe jq mosh python-setuptools tree unzip
     # This is for VMs with broken PRNG (symptom: running docker-compose randomly hangs)
     sudo apt-get -qy install haveged
     "
@@ -1230,8 +1097,8 @@ _cmd_tags() {
         cd tags
         echo "[#] [Status] [Tag] [Mode] [Provider]"
         for tag in *; do
-            if [ -f $tag/logins.jsonl ]; then
-                count="$(wc -l < $tag/logins.jsonl)"
+            if [ -f $tag/ips.txt ]; then
+                count="$(wc -l < $tag/ips.txt)"
             else
                 count="?"
             fi
@@ -1307,13 +1174,7 @@ _cmd_passwords() {
     $0 ips "$TAG" | paste "$PASSWORDS_FILE" - | while read password nodes; do
         info "Setting password for $nodes..."
         for node in $nodes; do
-            echo $USER_LOGIN $password | ssh $SSHOPTS -i tags/$TAG/id_rsa ubuntu@$node '
-                read login password
-                echo $login:$password | sudo chpasswd
-                hashedpassword=$(echo -n $password | argon2 saltysalt$RANDOM -e)
-                sudo -u $login mkdir -p /home/$login/.config/code-server
-                echo "hashed-password: \"$hashedpassword\"" | sudo -u $login tee /home/$login/.config/code-server/config.yaml >/dev/null
-                '
+            echo $USER_LOGIN:$password | ssh $SSHOPTS -i tags/$TAG/id_rsa ubuntu@$node sudo chpasswd
         done
     done
     info "Done."
@@ -1345,11 +1206,6 @@ _cmd_wait() {
     pssh -l $SSH_USER "
     if [ -d /var/lib/cloud ]; then
         cloud-init status --wait
-        case $? in
-        0) exit 0;; # all is good
-        2) exit 0;; # recoverable error (happens with proxmox deprecated cloud-init payloads)
-        *) exit 1;; # all other problems
-        esac
     fi"
 }
 
@@ -1405,7 +1261,7 @@ EOF"
 _cmd www "Run a web server to access card HTML and PDF"
 _cmd_www() {
     cd www
-    IPADDR=$(curl -fsSL canihazip.com/s || echo localhost)
+    IPADDR=$(curl -sL canihazip.com/s)
     info "The following files are available:"
     for F in *; do
         echo "http://$IPADDR:8000/$F"

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

@@ -1,22 +1,32 @@
 #!/usr/bin/env python3
-import json
 import os
 import sys
 import yaml
 import jinja2
 
+
 # Read settings from user-provided settings file
 context = yaml.safe_load(open(sys.argv[1]))
 
-context["logins"] = []
-for line in open("logins.jsonl"):
-    if line.strip():
-        context["logins"].append(json.loads(line))
+ips = list(open("ips.txt"))
+clustersize = context["clustersize"]
 
 print("---------------------------------------------")
-print("   Number of cards: {}".format(len(context["logins"])))
+print("   Number of IPs: {}".format(len(ips)))
+print(" VMs per cluster: {}".format(clustersize))
 print("---------------------------------------------")
 
+assert len(ips)%clustersize == 0
+
+clusters = []
+
+while ips:
+    cluster = ips[:clustersize]
+    ips = ips[clustersize:]
+    clusters.append(cluster)
+
+context["clusters"] = clusters
+
 template_file_name = context["cards_template"]
 template_file_path = os.path.join(
     os.path.dirname(__file__),
@@ -25,23 +35,23 @@ template_file_path = os.path.join(
     template_file_name
     )
 template = jinja2.Template(open(template_file_path).read())
-with open("cards.html", "w") as f:
-    f.write(template.render(**context))
-print("Generated cards.html")
+with open("ips.html", "w") as f:
+	f.write(template.render(**context))
+print("Generated ips.html")
 
 
 try:
     import pdfkit
     paper_size = context["paper_size"]
     margin = {"A4": "0.5cm", "Letter": "0.2in"}[paper_size]
-    with open("cards.html") as f:
-        pdfkit.from_file(f, "cards.pdf", options={
+    with open("ips.html") as f:
+        pdfkit.from_file(f, "ips.pdf", options={
             "page-size": paper_size,
             "margin-top": margin,
             "margin-bottom": margin,
             "margin-left": margin,
             "margin-right": margin,
             })
-    print("Generated cards.pdf")
+    print("Generated ips.pdf")
 except ImportError:
-    print("WARNING: could not import pdfkit; did not generate cards.pdf")
+    print("WARNING: could not import pdfkit; did not generate ips.pdf")

prepare-labs/map-dns.sh

@@ -1,16 +0,0 @@
-#!/bin/sh
-
-DOMAINS=domains.txt
-IPS=ips.txt
-
-. ./dns-cloudflare.sh
-
-paste "$DOMAINS" "$IPS" | while read domain ips; do
-  if ! [ "$domain" ]; then
-    echo "⚠️ No more domains!"
-    exit 1
-  fi
-  _clear_zone "$domain"
-  _populate_zone "$domain" $ips
-done
-echo "✅ All done."

prepare-labs/settings/admin-kubenet.env

@@ -7,7 +7,6 @@ USER_LOGIN=k8s
 USER_PASSWORD=training
 
 STEPS="
-  terraform
   wait
   standardize
   clusterize

prepare-labs/settings/admin-kuberouter.env

@@ -7,7 +7,6 @@ USER_LOGIN=k8s
 USER_PASSWORD=training
 
 STEPS="
-  terraform
   wait
   standardize
   clusterize

prepare-labs/settings/admin-monokube.env

@@ -11,7 +11,6 @@ USER_LOGIN=k8s
 USER_PASSWORD=training
 
 STEPS="
-  terraform
   wait
   standardize
   clusterize

prepare-labs/settings/admin-oldversion.env

@@ -7,10 +7,9 @@ USER_PASSWORD=training
 
 # For a list of old versions, check:
 # https://kubernetes.io/releases/patch-releases/#non-active-branch-history
-KUBEVERSION=1.28.9
+KUBEVERSION=1.24.14
 
 STEPS="
-  terraform
   wait
   standardize
   clusterize

prepare-labs/settings/admin-polykube.env

@@ -6,7 +6,6 @@ USER_LOGIN=k8s
 USER_PASSWORD=training
 
 STEPS="
-  terraform
   wait
   standardize
   clusterize

prepare-labs/settings/admin-test.env

@@ -6,7 +6,6 @@ USER_LOGIN=k8s
 USER_PASSWORD=training
 
 STEPS="
-  terraform
   wait
   standardize
   clusterize

prepare-labs/settings/docker.env

@@ -6,7 +6,6 @@ USER_LOGIN=docker
 USER_PASSWORD=training
 
 STEPS="
-  terraform
   wait
   standardize
   clusterize
@@ -15,5 +14,6 @@ STEPS="
   createuser
   webssh
   tailhist
+  cards
   ips
-"
+"

prepare-labs/settings/konk.env

@@ -1,6 +0,0 @@
-CLUSTERSIZE=5
-
-USER_LOGIN=k8s
-USER_PASSWORD=
-
-STEPS="terraform stage2"

prepare-labs/settings/kubernetes.env

@@ -6,7 +6,6 @@ USER_LOGIN=k8s
 USER_PASSWORD=training
 
 STEPS="
-  terraform
   wait
   standardize
   clusterize

prepare-labs/settings/largekube.env

@@ -7,7 +7,6 @@ USER_LOGIN=k8s
 USER_PASSWORD=training
 
 STEPS="
-  terraform
   wait
   standardize
   clusterize

prepare-labs/settings/mk8s.env

@@ -1,4 +1,6 @@
+CLUSTERSIZE=2
+
 USER_LOGIN=k8s
 USER_PASSWORD=
 
-STEPS="terraform stage2"
+STEPS="stage2"

prepare-labs/settings/portal.env

@@ -1,7 +1,5 @@
 #export TF_VAR_node_size=GP2.4
 #export TF_VAR_node_size=g6-standard-6
-#export TF_VAR_node_size=m7i.xlarge
-
 
 CLUSTERSIZE=1
 
@@ -11,7 +9,6 @@ USER_LOGIN=portal
 USER_PASSWORD=CHANGEME
 
 STEPS="
-  terraform
   wait
   standardize
   clusterize

prepare-labs/templates/cards.html

@@ -7,7 +7,7 @@
 {%- set url = url
     | default("http://FIXME.container.training/") -%}
 {%- set pagesize = pagesize
-    | default(10) -%}
+    | default(9) -%}
 {%- set lang = lang
     | default("en") -%}
 {%- set event = event
@@ -15,36 +15,79 @@
 {%- set backside = backside
     | default(False) -%}
 {%- set image = image
-    | default(False) -%}
+    | default("kube") -%}
 {%- set clusternumber = clusternumber
     | default(None) -%}
-{%- set thing = thing
-    | default("lab environment") -%}
-
-{%- if lang == "en" -%}
-    {%- set intro -%}
-    Here is the connection information to your very own
-    {{ thing }} for this {{ event }}.
-    You can connect to it with any SSH client.
-    {%- endset -%}
+{%- if qrcode == True -%}
+    {%- set qrcode = "https://container.training/q" -%}
+{%- elif qrcode -%}
+    {%- set qrcode = qrcode -%}
 {%- endif -%}
-{%- if lang == "fr" -%}
-    {%- set intro -%}
-    Voici les informations permettant de se connecter à votre
-    {{ thing }} pour cette formation.
-    Vous pouvez vous y connecter
-    avec n'importe quel client SSH.
-    {%- endset -%}
+
+{# You can also set img_bottom_src instead. #}
+{%- set img_logo_src = {
+	"docker": "https://s3-us-west-2.amazonaws.com/www.breadware.com/integrations/docker.png",
+	"swarm": "https://cdn.wp.nginx.com/wp-content/uploads/2016/07/docker-swarm-hero2.png",
+	"kube": "https://avatars1.githubusercontent.com/u/13629408",
+	"enix": "https://enix.io/static/img/logos/logo-domain-cropped.png",
+    }[image] -%}
+{%- if lang == "en" and clustersize == 1 -%}
+	{%- set intro -%}
+	Here is the connection information to your very own
+	machine for this {{ event }}.
+	You can connect to this VM with any SSH client.
+	{%- endset -%}
+    {%- set listhead -%}
+    Your machine is:
+	{%- endset -%}
+{%- endif -%}
+{%- if lang == "en" and clustersize != 1 -%}
+	{%- set intro -%}
+	Here is the connection information to your very own
+	cluster for this {{ event }}.
+	You can connect to each VM with any SSH client.
+	{%- endset -%}
+    {%- set listhead -%}
+    Your machines are:
+	{%- endset -%}
+{%- endif -%}
+{%- if lang == "fr" and clustersize == 1 -%}
+	{%- set intro -%}
+	Voici les informations permettant de se connecter à votre
+	machine pour cette formation.
+	Vous pouvez vous connecter à cette machine virtuelle
+	avec n'importe quel client SSH.
+	{%- endset -%}
+    {%- set listhead -%}
+    Adresse IP:
+	{%- endset -%}
+{%- endif -%}
+{%- if lang == "en" and clusterprefix != "node" -%}
+	{%- set intro -%}
+    Here is the connection information for the
+    <strong>{{ clusterprefix }}</strong> environment.
+	{%- endset -%}
+{%- endif -%}
+{%- if lang == "fr" and clustersize != 1 -%}
+	{%- set intro -%}
+	Voici les informations permettant de se connecter à votre
+	cluster pour cette formation.
+	Vous pouvez vous connecter à chaque machine virtuelle
+	avec n'importe quel client SSH.
+	{%- endset -%}
+    {%- set listhead -%}
+	Adresses IP:
+	{%- endset -%}
 {%- endif -%}
 {%- if lang == "en"  -%}
-    {%- set slides_are_at -%}
-    You can find the slides at:
-    {%- endset -%}
+	{%- set slides_are_at -%}
+	You can find the slides at:
+	{%- endset -%}
 {%- endif -%}
 {%- if lang == "fr" -%}
-    {%- set slides_are_at -%}
-      Le support de formation est à l'adresse suivante :
-    {%- endset -%}
+	{%- set slides_are_at -%}
+  	Le support de formation est à l'adresse suivante :
+	{%- endset -%}
 {%- endif -%}
 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
 <html>
@@ -59,21 +102,25 @@
 }
 body {
     /* this is A4 minus 0.5cm margins */
-    width: 20cm;
-    height: 28.7cm;
+	width: 20cm;
+	height: 28.7cm;
 }
 {% elif paper_size == "Letter" %}
 @page {
-    size: Letter; /* 8.5in x 11in */
+	size: Letter;
+	margin: 0.2in;
 }
 body {
-    width: 6.75in; /* two cards wide */
-    margin-left: 0.875in; /* (8.5in - 6.75in)/2 */
-    margin-top: 0.1875in; /* (11in - 5 cards)/2 */
+	/* this is Letter minus 0.2in margins */
+	width: 8.6in;
+	heigth: 10.6in;
 }
 {% endif %}
 
+
 body, table {
+    margin: 0;
+    padding: 0;
     line-height: 1em;
     font-size: 15px;
     font-family: 'Slabo 27px';
@@ -87,45 +134,47 @@ table {
     padding-left: 0.4em;
 }
 
-td:first-child {
-    width: 10.5em;
-}
-
-div.card {
+div {
     float: left;
-    border: 0.01in dotted black;
+    border: 1px dotted black;
+    {% if backside %}
+    height: 33%;
+    {% endif %}
+    /* columns * (width+left+right) < 100% */
     /*
-      columns * (width+left+right) < 100% 
-      height: 33%;
-      width: 24.8%;
-      width: 33%;
+    width: 24.8%;
     */
-    width: 3.355in; /* 3.375in minus two 0.01in borders */
-    height: 2.105in; /* 2.125in minus two 0.01in borders */
+    /**/
+    width: 33%;
+    /**/    
 }
 
 p {
     margin: 0.8em;
 }
 
-div.front {
-    {% if image %}
-    background-image: url("{{ image }}");
-    background-repeat: no-repeat;
-    background-size: 1in;
-    background-position-x: 2.8in;
-    background-position-y: center;
-    {% endif %}
+div.back {
+	border: 1px dotted grey;
 }
 
 span.scale {
-    white-space: nowrap;
+	white-space: nowrap;
+}
+
+img.logo {
+    height: 4.5em;
+    float: right;
+ }
+
+img.bottom {
+    height: 2.5em;
+    display: block;
+    margin: 0.5em auto;
 }
 
 .qrcode img {
-    height: 5.8em;
-    padding: 1em 1em 0.5em 1em;
-    float: left;
+    width: 40%;
+    margin: 1em;
 }
 
 .logpass {
@@ -140,97 +189,101 @@ span.scale {
     height: 0;
 }
 </style>
-<script type="text/javascript" src="qrcode.min.js"></script>
+<script type="text/javascript" src="https://cdn.rawgit.com/davidshimjs/qrcodejs/gh-pages/qrcode.min.js"></script>
 <script type="text/javascript">
 function qrcodes() {
-    [].forEach.call(
-        document.getElementsByClassName("qrcode"),
-        (e, index) => {
-            new QRCode(e, {
-                text: "{{ qrcode }}",
-                correctLevel: QRCode.CorrectLevel.L
-            });
-        }
-    );
+	[].forEach.call(
+		document.getElementsByClassName("qrcode"),
+		(e, index) => {
+			new QRCode(e, {
+				text: "{{ qrcode }}",
+				correctLevel: QRCode.CorrectLevel.L
+			});
+		}
+	);
 }
 
 function scale() {
-    [].forEach.call(
-        document.getElementsByClassName("scale"),
-        (e, index) => {
-            var text_width = e.getBoundingClientRect().width;
-            var box_width = e.parentElement.getBoundingClientRect().width;
-            var percent = 100 * box_width / text_width + "%";
-            e.style.fontSize = percent;
-        }
-    );
+	[].forEach.call(
+		document.getElementsByClassName("scale"),
+		(e, index) => {
+			var text_width = e.getBoundingClientRect().width;
+			var box_width = e.parentElement.getBoundingClientRect().width;
+			var percent = 100 * box_width / text_width + "%";
+			e.style.fontSize = percent;
+		}
+	);
 }
 </script>
 </head>
 <body onload="qrcodes(); scale();">
-{% for login in logins %}
-    <div class="card front">
+{% for cluster in clusters %}
+    <div>
         <p>{{ intro }}</p>
         <p>
+            {% if img_logo_src %}
+            <img class="logo" src="{{ img_logo_src }}" />
+            {% endif %}
             <table>
-              <tr>
-                <td>login:</td>
-                <td>password:</td>
-              </tr>
-              <tr>
-                <td class="logpass">{{ login.login }}</td>
-                <td class="logpass">{{ login.password }}</td>
-              </tr>
-              <tr>
-                <td>IP address:</td>
-                {% if login.port %}
-                <td>port:</td>
-                {% endif %}
-              </tr>
-              <tr>
-                <td class="logpass">{{ login.ipaddrs.split("\t")[0] }}</td>
-                {% if login.port %}
-                <td class="logpass">{{ login.port }}</td>
-                {% endif %}
-              </tr>
+            	{% if clusternumber != None %}
+	            <tr><td>cluster:</td></tr>
+	            <tr><td class="logpass">{{ clusternumber + loop.index }}</td></tr>
+            	{% endif %}
+                <tr><td>login:</td></tr>
+                <tr><td class="logpass">{{ user_login }}</td></tr>
+                <tr><td>password:</td></tr>
+                <tr><td class="logpass">{{ user_password }}</td></tr>
             </table>
+
         </p>
+        <p>
+            {{ listhead }}
+            <table>
+                {% for node in cluster %}
+                <tr>
+                	<td>{{ clusterprefix }}{{ loop.index }}:</td>
+                	<td>{{ node }}</td>
+                </tr>
+                {% endfor %}
+            </table>
+        </p>
+
         <p>
             {% if url %}
-            {{ slides_are_at }}
+        	{{ slides_are_at }}
             <p>
                 <span class="scale">{{ url }}</span>
             </p>
             {% endif %}
+            {% if img_bottom_src %}
+            <img class="bottom" src="{{ img_bottom_src }}" />
+            {% endif %}
         </p>
     </div>
     {% if loop.index%pagesize==0 or loop.last %}
         <span class="pagebreak"></span>
         {% if backside %}
-            {% for x in range(pagesize) %}
-                <div class="card back">
-                {{ backside }}
-                {#
-                <p>Thanks for attending
-                "Getting Started With Kubernetes and Container Orchestration"
-                during CONFERENCE in Month YYYY!</p>
-                <p>If you liked that workshop,
-                I can train your team, in person or
-                online, with custom courses of
-                any length and any level.
-                </p>
-                {% if qrcode %}
-                <p>If you're interested, please scan that QR code to contact me:</p>
-                <span class="qrcode"></span>
+			{% for x in range(pagesize) %}
+		        <div class="back">
+				<p>Thanks for attending
+				"Getting Started With Kubernetes and Container Orchestration"
+				during CONFERENCE in Month YYYY!</p>
+				<p>If you liked that workshop,
+				I can train your team, in person or
+				online, with custom courses of
+				any length and any level.
+				</p>
+	            {% if qrcode %}
+	            <p>If you're interested, please scan that QR code to contact me:</p>
+				<span class="qrcode"></span>
                 {% else %}
-                <p>If you're interested, you can contact me at:</p>
-                {% endif %}
-                <p>jerome.petazzoni@gmail.com</p>
-                #}
-                </div>
-            {% endfor %}
-        <span class="pagebreak"></span>
-        {% endif %}
+				<p>If you're interested, you can contact me at:</p>
+				{% endif %}
+				<p>jerome.petazzoni@gmail.com</p>
+		        </div>
+			{% endfor %}
+		<span class="pagebreak"></span>
+		{% endif %}
     {% endif %}
 {% endfor %}
 </body>

prepare-labs/templates/cards.yaml

@@ -1,19 +0,0 @@
-cards_template: cards.html
-paper_size: Letter
-url: https://2024-11-qconsf.container.training
-event: workshop
-backside: |
-  <div class="qrcode"></div>
-  <p>
-    Thanks for attending the Asynchronous Architecture Patterns workshop at QCON!
-  </p>
-  <p>
-    <b>This QR code will give you my contact info</b> as well as a link to a feedback form.
-  </p>
-  <p>
-    If you liked this workshop, I can train your team, in person or online, with custom
-    courses of any length and any level, on Docker, Kubernetes, and MLops.
-  </p>
-qrcode: https://2024-11-qconsf.container.training/#contact
-thing: Kubernetes cluster
-image: logo-kubernetes.png

prepare-labs/terraform/many-kubernetes/locals.tf

@@ -8,8 +8,8 @@ resource "random_string" "_" {
 resource "time_static" "_" {}
 
 locals {
-  min_nodes_per_pool = var.min_nodes_per_cluster
-  max_nodes_per_pool = var.max_nodes_per_cluster
+  min_nodes_per_pool = var.nodes_per_cluster
+  max_nodes_per_pool = var.nodes_per_cluster * 2
   timestamp          = formatdate("YYYY-MM-DD-hh-mm", time_static._.rfc3339)
   tag                = random_string._.result
   # Common tags to be assigned to all resources

prepare-labs/terraform/many-kubernetes/stage2.tmpl

@@ -14,20 +14,6 @@ provider "kubernetes" {
   config_path = "./kubeconfig.${index}"
 }
 
-provider "helm" {
-  alias = "cluster_${index}"
-  kubernetes {
-    config_path = "./kubeconfig.${index}"
-  }
-}
-
-# Password used for SSH and code-server access
-resource "random_string" "shpod_${index}" {
-  length  = 6
-  special = false
-  upper   = false
-}
-
 resource "kubernetes_namespace" "shpod_${index}" {
   provider = kubernetes.cluster_${index}
   metadata {
@@ -35,57 +21,120 @@ resource "kubernetes_namespace" "shpod_${index}" {
   }
 }
 
-data "kubernetes_service" "shpod_${index}" {
-  depends_on = [ helm_release.shpod_${index} ]
+resource "kubernetes_deployment" "shpod_${index}" {
   provider = kubernetes.cluster_${index}
   metadata {
     name = "shpod"
-    namespace = "shpod"
+    namespace = kubernetes_namespace.shpod_${index}.metadata.0.name
+  }
+  spec {
+    selector {
+      match_labels = {
+        app = "shpod"
+      }
+    }
+    template {
+      metadata {
+        labels = {
+          app = "shpod"
+        }
+      }
+      spec {
+        service_account_name = "shpod"
+        container {
+          image = "jpetazzo/shpod"
+          name = "shpod"
+          env {
+            name = "PASSWORD"
+            value = random_string.shpod_${index}.result
+          }
+          lifecycle {
+            post_start {
+              exec {
+                command = [ "sh", "-c", "curl http://myip.enix.org/REMOTE_ADDR > /etc/HOSTIP || true" ]
+              }
+            }
+          }
+          resources {
+            limits = {
+              cpu    = "2"
+              memory = "500M"
+            }
+            requests = {
+              cpu    = "100m"
+              memory = "250M"
+            }
+          }
+        }
+      }
+    }
   }
 }
 
-resource "helm_release" "shpod_${index}" {
-  provider = helm.cluster_${index}
-  repository = "https://shpod.in"
-  chart = "shpod"
-  name = "shpod"
-  namespace = "shpod"
-  create_namespace = false
-  set {
-    name = "service.type"
-    value = "NodePort"
+resource "kubernetes_service" "shpod_${index}" {
+  provider = kubernetes.cluster_${index}
+  lifecycle {
+    # Folks might alter their shpod Service to expose extra ports.
+    # Don't reset their changes.
+    ignore_changes = [ spec ]
   }
-  set {
-    name = "resources.requests.cpu"
-    value = "100m"
+  metadata {
+    name = "shpod"
+    namespace = kubernetes_namespace.shpod_${index}.metadata.0.name
   }
-  set {
-    name = "resources.requests.memory"
-    value = "500M"
+  spec {
+    selector = {
+      app = "shpod"
+    }
+    port {
+      name = "ssh"
+      port = 22
+      target_port = 22
+    }
+    type = "NodePort"
   }
-  set {
-    name = "resources.limits.cpu"
-    value = "1"
+}
+
+resource "kubernetes_service_account" "shpod_${index}" {
+  provider = kubernetes.cluster_${index}
+  metadata {
+    name = "shpod"
+    namespace = kubernetes_namespace.shpod_${index}.metadata.0.name
   }
-  set {
-    name = "resources.limits.memory"
-    value = "1000M"
+}
+
+resource "kubernetes_cluster_role_binding" "shpod_${index}" {
+  provider = kubernetes.cluster_${index}
+  metadata {
+    name = "shpod"
   }
-  set {
-    name = "persistentVolume.enabled"
-    value = "true"
+  role_ref {
+    api_group = "rbac.authorization.k8s.io"
+    kind      = "ClusterRole"
+    name      = "cluster-admin"
   }
-  set {
-    name = "ssh.password"
-    value = random_string.shpod_${index}.result
+  subject {
+    kind      = "ServiceAccount"
+    name      = "shpod"
+    namespace = "shpod"
   }
-  set {
-    name = "rbac.cluster.clusterRoles"
-    value = "{cluster-admin}"
+  subject {
+    api_group = "rbac.authorization.k8s.io"
+    kind      = "Group"
+    name      = "shpod-cluster-admins"
   }
-  set {
-    name = "codeServer.enabled"
-    value = "true"
+}
+
+resource "random_string" "shpod_${index}" {
+  length  = 6
+  special = false
+  upper   = false
+}
+
+provider "helm" {
+  alias = "cluster_${index}"
+  kubernetes {
+    config_path = "./kubeconfig.${index}"
   }
 }
 
@@ -168,28 +217,16 @@ resource "kubernetes_certificate_signing_request_v1" "cluster_admin_${index}" {
 
 %{ endfor ~}
 
-output "ips_txt" {
+output "ip_addresses_of_nodes" {
   value = join("\n", [
   %{ for index, cluster in clusters ~}
-    join("\n", concat(
+    join("\t", concat(
+      [
+        random_string.shpod_${index}.result,
+        "ssh -l k8s -p $${kubernetes_service.shpod_${index}.spec[0].port[0].node_port}"
+      ],
       split(" ", file("./externalips.${index}"))
     )),
   %{ endfor ~}
-  ""
-  ])
-}
-
-output "logins_jsonl" {
-  value = join("\n", [
-  %{ for index, cluster in clusters ~}
-    jsonencode({
-      login = "k8s",
-      password = random_string.shpod_${index}.result,
-      port = data.kubernetes_service.shpod_${index}.spec[0].port[0].node_port,
-      codeServerPort = data.kubernetes_service.shpod_${index}.spec[0].port[1].node_port,
-      ipaddrs = replace(file("./externalips.${index}"), " ", "\t"),
-    }),
-  %{ endfor ~}
-  ""
   ])
 }

prepare-labs/terraform/many-kubernetes/variables.tf

@@ -7,16 +7,11 @@ variable "how_many_clusters" {
   default = 2
 }
 
-variable "min_nodes_per_cluster" {
+variable "nodes_per_cluster" {
   type    = number
   default = 2
 }
 
-variable "max_nodes_per_cluster" {
-  type    = number
-  default = 4
-}
-
 variable "node_size" {
   type    = string
   default = "M"

prepare-labs/terraform/one-kubernetes/scaleway/main.tf

@@ -1,23 +1,10 @@
-resource "scaleway_vpc_private_network" "_" {
-}
-
-# This is a kind of hack to use a custom security group with Kapsulse.
-# See https://www.scaleway.com/en/docs/containers/kubernetes/reference-content/secure-cluster-with-private-network/
-
-resource "scaleway_instance_security_group" "_" {
-  name                    = "kubernetes ${split("/", scaleway_k8s_cluster._.id)[1]}"
-  inbound_default_policy  = "accept"
-  outbound_default_policy = "accept"
-}
-
 resource "scaleway_k8s_cluster" "_" {
-  name                        = var.cluster_name
+  name = var.cluster_name
+  #region                     = var.location
   tags                        = var.common_tags
   version                     = local.k8s_version
-  type                        = "kapsule"
   cni                         = "cilium"
   delete_additional_resources = true
-  private_network_id          = scaleway_vpc_private_network._.id
 }
 
 resource "scaleway_k8s_pool" "_" {
@@ -30,7 +17,6 @@ resource "scaleway_k8s_pool" "_" {
   max_size    = var.max_nodes_per_pool
   autoscaling = var.max_nodes_per_pool > var.min_nodes_per_pool
   autohealing = true
-  depends_on = [ scaleway_instance_security_group._ ]
 }
 
 data "scaleway_k8s_version" "_" {

prepare-labs/terraform/one-kubernetes/vcluster/main.tf

@@ -4,7 +4,6 @@ resource "helm_release" "_" {
   create_namespace = true
   repository       = "https://charts.loft.sh"
   chart            = "vcluster"
-  version          = "0.19.7"
   set {
     name  = "service.type"
     value = "NodePort"

prepare-labs/terraform/providers/hetzner/variables.tf

@@ -14,9 +14,9 @@ $ hcloud server-type list | grep shared
 variable "node_sizes" {
   type = map(any)
   default = {
-    S = "cpx11"
-    M = "cpx21"
-    L = "cpx31"
+    S = "cx11"
+    M = "cx21"
+    L = "cx31"
   }
 }
 

prepare-labs/terraform/providers/proxmox/config.tf

@@ -1,25 +0,0 @@
-variable "proxmox_endpoint" {
-  type    = string
-  default = "https://localhost:8006/"
-}
-
-variable "proxmox_username" {
-  type    = string
-  default = null
-}
-
-variable "proxmox_password" {
-  type    = string
-  default = null
-}
-
-variable "proxmox_template_node_name" {
-  type    = string
-  default = null
-}
-
-variable "proxmox_template_vm_id" {
-  type    = number
-  default = null
-}
-

prepare-labs/terraform/providers/proxmox/variables.tf

@@ -1,11 +0,0 @@
-# Since node size needs to be a string...
-# To indicate number of CPUs + RAM, just pass it as a string with a space between them.
-# RAM is in megabytes.
-variable "node_sizes" {
-  type = map(any)
-  default = {
-    S = "1 2048"
-    M = "2 4096"
-    L = "3 8192"
-  }
-}

prepare-labs/terraform/virtual-machines/common.tf

@@ -56,7 +56,6 @@ locals {
       cluster_name = format("%s-%03d", var.tag, cn[0])
       node_name    = format("%s-%03d-%03d", var.tag, cn[0], cn[1])
       node_size    = lookup(var.node_sizes, var.node_size, var.node_size)
-      node_index   = cn[0] * var.nodes_per_cluster + cn[1]
     }
   }
 }
@@ -72,10 +71,10 @@ resource "local_file" "ip_addresses" {
 resource "local_file" "clusters" {
   content = join("", formatlist("%s\n", [
     for cid in range(1, 1 + var.how_many_clusters) :
-    join("\t",
+    join(" ",
       [for nid in range(1, 1 + var.nodes_per_cluster) :
         local.ip_addresses[format("c%03dn%03d", cid, nid)]
   ])]))
-  filename        = "clusters.tsv"
+  filename        = "clusters.txt"
   file_permission = "0600"
 }

prepare-labs/terraform/virtual-machines/openstack/main.tf

@@ -13,7 +13,7 @@ data "openstack_images_image_v2" "_" {
   most_recent = true
   properties = {
     os      = "ubuntu"
-    version = "24.04"
+    version = "22.04"
   }
 }
 

prepare-labs/terraform/virtual-machines/proxmox/common.tf

@@ -1 +0,0 @@
-../common.tf

prepare-labs/terraform/virtual-machines/proxmox/config.tf

@@ -1 +0,0 @@
-../../providers/proxmox/config.tf

prepare-labs/terraform/virtual-machines/proxmox/main.tf

@@ -1,77 +0,0 @@
-data "proxmox_virtual_environment_nodes" "_" {}
-
-locals {
-  pve_nodes = data.proxmox_virtual_environment_nodes._.names
-}
-
-resource "proxmox_virtual_environment_vm" "_" {
-  node_name       = local.pve_nodes[each.value.node_index % length(local.pve_nodes)]
-  for_each        = local.nodes
-  name            = each.value.node_name
-  stop_on_destroy = true
-  cpu {
-    cores = split(" ", each.value.node_size)[0]
-    type  = "x86-64-v2-AES" # recommended for modern CPUs
-  }
-  memory {
-    dedicated = split(" ", each.value.node_size)[1]
-  }
-  #disk {
-  #  datastore_id = "ceph"
-  #  file_id = proxmox_virtual_environment_file._.id
-  #  interface = "scsi0"
-  #  size = 30
-  #  discard = "on"
-  #}
-  clone {
-    vm_id     = var.proxmox_template_vm_id
-    node_name = var.proxmox_template_node_name
-  }
-  agent {
-    enabled = true
-  }
-  initialization {
-    datastore_id = "ceph"
-    user_account {
-      username = "ubuntu"
-      keys     = [trimspace(tls_private_key.ssh.public_key_openssh)]
-    }
-    ip_config {
-      ipv4 {
-        address = "dhcp"
-        #gateway =
-      }
-    }
-  }
-  network_device {
-    bridge = "vmbr0"
-  }
-  operating_system {
-    type = "l26"
-  }
-}
-
-#resource "proxmox_virtual_environment_download_file" "ubuntu_2404_20250115" {
-#  content_type = "iso"
-#  datastore_id = "cephfs"
-#  node_name    = "pve-lsd-1"
-#  url          = "https://cloud-images.ubuntu.com/releases/24.04/release-20250115/ubuntu-24.04-server-cloudimg-amd64.img"
-#  file_name    = "ubuntu_2404_20250115.img"
-#}
-#
-#resource "proxmox_virtual_environment_file" "_" {
-#  datastore_id = "cephfs"
-#  node_name = "pve-lsd-1"
-#  source_file {
-#    path = "/root/noble-server-cloudimg-amd64.img"
-#  }
-#}
-
-locals {
-  ip_addresses = {
-    for key, value in local.nodes :
-    key => [for addr in flatten(concat(proxmox_virtual_environment_vm._[key].ipv4_addresses, ["ERROR"])) :
-    addr if addr != "127.0.0.1"][0]
-  }
-}
-

prepare-labs/terraform/virtual-machines/proxmox/provider.tf

@@ -1,15 +0,0 @@
-terraform {
-  required_providers {
-    proxmox = {
-      source  = "bpg/proxmox"
-      version = "~> 0.70.1"
-    }
-  }
-}
-
-provider "proxmox" {
-  endpoint = var.proxmox_endpoint
-  username = var.proxmox_username
-  password = var.proxmox_password
-  insecure = true
-}

prepare-labs/terraform/virtual-machines/proxmox/tfvars.example

@@ -1,14 +0,0 @@
-# If you want to deploy to Proxmox, you need to:
-# 1) copy that file to e.g. myproxmoxcluster.tfvars
-# 2) make sure you have a VM template with QEMU agent pre-installed
-# 3) customize the copy (you need to replace all the CHANGEME values)
-# 4) deploy with "labctl create --provider proxmox/myproxmoxcluster  ..."
-
-proxmox_endpoint = "https://localhost:8006/"
-proxmox_username = "terraform@pve"
-proxmox_password = "CHANGEME"
-
-proxmox_template_node_name = "CHANGEME"
-proxmox_template_vm_id = CHANGEME
-
-

prepare-labs/terraform/virtual-machines/proxmox/variables.tf

@@ -1 +0,0 @@
-../../providers/proxmox/variables.tf

slides/1.yml

@@ -1,68 +0,0 @@
-title: |
-  Docker Intensif
-
-chat: "[Mattermost](https://training.enix.io/mattermost)"
-
-gitrepo: github.com/jpetazzo/container.training
-
-slides: https://2025-01-enix.container.training/
-
-#slidenumberprefix: "#SomeHashTag — "
-
-exclude:
-- self-paced
-
-content:
-- shared/title.md
-- logistics.md
-- containers/intro.md
-- shared/about-slides.md
-- shared/chat-room-im.md
-#- shared/chat-room-zoom-meeting.md
-#- shared/chat-room-zoom-webinar.md
-- shared/toc.md
-- # DAY 1
-  #- 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/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/Exercise_Dockerfile_Basic.md
-- # DAY 2
-  - containers/Container_Networking_Basics.md
-  - containers/Local_Development_Workflow.md
-  - containers/Container_Network_Model.md
-  - containers/Compose_For_Dev_Stacks.md
-  - containers/Exercise_Composefile.md
-- # DAY 3
-  - containers/Start_And_Attach.md
-  - containers/Naming_And_Inspecting.md
-  - containers/Labels.md
-  - containers/Getting_Inside.md
-  - containers/Dockerfile_Tips.md
-  - containers/Advanced_Dockerfiles.md
-  - containers/Multi_Stage_Builds.md
-  - containers/Publishing_To_Docker_Hub.md
-  - containers/Exercise_Dockerfile_Advanced.md
-- # DAY 4
-  - containers/Buildkit.md
-  - containers/Network_Drivers.md
-  - containers/Namespaces_Cgroups.md
-  #- containers/Copy_On_Write.md
-  - containers/Orchestration_Overview.md
-  #- containers/Docker_Machine.md
-  #- containers/Init_Systems.md
-  #- containers/Application_Configuration.md
-  #- containers/Logging.md
-  #- containers/Containers_From_Scratch.md
-  #- containers/Container_Engines.md
-  #- containers/Pods_Anatomy.md
-  #- containers/Ecosystem.md
-  - shared/thankyou.md
-  #- containers/links.md

slides/2.yml

@@ -1,92 +0,0 @@
-title: |
-  Fondamentaux Kubernetes
-
-chat: "[Mattermost](https://training.enix.io/mattermost)"
-
-gitrepo: github.com/jpetazzo/container.training
-
-slides: https://2025-01-enix.container.training/
-
-#slidenumberprefix: "#SomeHashTag — "
-
-exclude:
-- self-paced
-
-content:
-- shared/title.md
-- logistics.md
-- k8s/intro.md
-- shared/about-slides.md
-- shared/chat-room-im.md
-#- shared/chat-room-zoom-meeting.md
-#- shared/chat-room-zoom-webinar.md
-- shared/prereqs.md
-- shared/handson.md
-#- shared/webssh.md
-- shared/connecting.md
-- exercises/k8sfundamentals-brief.md
-- exercises/yaml-brief.md
-- exercises/localcluster-brief.md
-- exercises/healthchecks-brief.md
-- shared/toc.md
-- # 1
-  #- k8s/versions-k8s.md
-  - shared/sampleapp.md
-  #- shared/composescale.md
-  #- shared/hastyconclusions.md
-  - shared/composedown.md
-  - k8s/concepts-k8s.md
-  - k8s/kubectlget.md
-  - k8s/kubectl-run.md
-  - k8s/kubectlexpose.md
-  - k8s/service-types.md
-  - k8s/kubenet.md
-  - k8s/shippingimages.md
-  #- k8s/buildshiprun-selfhosted.md
-  - k8s/buildshiprun-dockerhub.md
-  - exercises/k8sfundamentals-details.md
-  - k8s/ourapponkube.md
-  #- k8s/exercise-wordsmith.md
-- # 2
-  - shared/yaml.md
-  - k8s/labels-annotations.md
-  - k8s/kubectl-logs.md
-  - k8s/logs-cli.md
-  - k8s/yamldeploy.md
-  - k8s/namespaces.md
-  - shared/declarative.md
-  - k8s/declarative.md
-  - k8s/deploymentslideshow.md
-  - k8s/setup-overview.md
-  - k8s/setup-devel.md
-  #- k8s/setup-managed.md
-  #- k8s/setup-selfhosted.md
-  - k8s/localkubeconfig.md
-  - k8s/accessinternal.md
-  - k8s/kubectlproxy.md
-  - exercises/yaml-details.md
-  - exercises/localcluster-details.md
-- # 3
-  #- k8s/kubectlscale.md
-  - k8s/scalingdockercoins.md
-  - shared/hastyconclusions.md
-  - k8s/daemonset.md
-  - k8s/rollout.md
-  - k8s/healthchecks.md
-  #- k8s/healthchecks-more.md
-  - k8s/dashboard.md
-  - k8s/k9s.md
-  - k8s/tilt.md
-  - exercises/healthchecks-details.md
-- # 4
-  - k8s/ingress.md
-  #- k8s/ingress-tls.md
-  #- k8s/ingress-advanced.md
-  - k8s/volumes.md
-  #- k8s/exercise-configmap.md
-  #- k8s/build-with-docker.md
-  #- k8s/build-with-kaniko.md
-  - k8s/configuration.md
-  - k8s/secrets.md
-  - k8s/batch-jobs.md
-  - shared/thankyou.md

slides/3.yml

@@ -1,47 +0,0 @@
-title: |
-  Packaging d'applications
-  pour Kubernetes
-
-chat: "[Mattermost](https://training.enix.io/mattermost)"
-
-gitrepo: github.com/jpetazzo/container.training
-
-slides: https://2025-01-enix.container.training/
-
-#slidenumberprefix: "#SomeHashTag — "
-
-exclude:
-- self-paced
-
-content:
-- shared/title.md
-- logistics.md
-- k8s/intro.md
-- shared/about-slides.md
-- k8s/prereqs-advanced.md
-- shared/handson.md
-- shared/webssh.md
-- shared/connecting.md
-#- shared/chat-room-im.md
-#- shared/chat-room-zoom.md
-- shared/toc.md
--
-  - k8s/demo-apps.md
-  - k8s/kustomize.md
-  - k8s/helm-intro.md
-  - k8s/helm-chart-format.md
-  - k8s/helm-create-basic-chart.md
-  - exercises/helm-generic-chart-details.md
--
-  - k8s/helm-create-better-chart.md
-  - k8s/helm-dependencies.md
-  - k8s/helm-values-schema-validation.md
-  - k8s/helm-secrets.md
-  - exercises/helm-umbrella-chart-details.md
--
-  - k8s/helmfile.md
-  - k8s/ytt.md
-  - k8s/gitworkflows.md
-  - k8s/flux.md
-  - k8s/argocd.md
-  - shared/thankyou.md

slides/4.yml

@@ -1,74 +0,0 @@
-title: |
-  Kubernetes Avancé
-
-chat: "[Mattermost](https://training.enix.io/mattermost)"
-
-gitrepo: github.com/jpetazzo/container.training
-
-slides: https://2025-01-enix.container.training/
-
-#slidenumberprefix: "#SomeHashTag — "
-
-exclude:
-- self-paced
-
-content:
-- shared/title.md
-- logistics.md
-- k8s/intro.md
-- shared/about-slides.md
-- shared/chat-room-im.md
-#- shared/chat-room-zoom.md
-- k8s/prereqs-advanced.md
-- shared/handson.md
-- shared/webssh.md
-- shared/connecting.md
-- shared/toc.md
-- exercises/netpol-brief.md
-- exercises/sealed-secrets-brief.md
-- exercices/rbac-brief.md
-- exercises/kyverno-ingress-domain-name-brief.md
-- exercises/reqlim-brief.md
-- #1
-  - k8s/demo-apps.md
-  - k8s/netpol.md
-  - k8s/authn-authz.md
-  - k8s/sealed-secrets.md
-  - k8s/cert-manager.md
-  - k8s/cainjector.md
-  - k8s/ingress-tls.md
-  - exercises/netpol-details.md
-  - exercises/sealed-secrets-details.md
-  - exercises/rbac-details.md
-- #2
-  - k8s/extending-api.md
-  - k8s/crd.md
-  - k8s/operators.md
-  - k8s/admission.md
-  - k8s/cainjector.md
-  - k8s/kyverno.md
-  - exercises/kyverno-ingress-domain-name-details.md
-- #3
-  - k8s/resource-limits.md
-  - k8s/metrics-server.md
-  - k8s/cluster-sizing.md
-  - k8s/horizontal-pod-autoscaler.md
-  - k8s/apiserver-deepdive.md
-  - k8s/aggregation-layer.md
-  - k8s/hpa-v2.md
-  - exercises/reqlim-details.md
-- #4
-  - k8s/statefulsets.md
-  - k8s/consul.md
-  - k8s/pv-pvc-sc.md
-  - k8s/volume-claim-templates.md
-  #- k8s/eck.md
-  #- k8s/portworx.md
-  - k8s/openebs.md
-  - k8s/stateful-failover.md
-  - k8s/operators-design.md
-  - k8s/operators-example.md
-  - k8s/owners-and-dependents.md
-  - k8s/events.md
-  - k8s/finalizers.md
-  - shared/thankyou.md

slides/5.yml

@@ -1,59 +0,0 @@
-title: |
-  Opérer Kubernetes
-
-chat: "[Mattermost](https://training.enix.io/mattermost)"
-
-gitrepo: github.com/jpetazzo/container.training
-
-slides: https://2025-01-enix.container.training/
-
-#slidenumberprefix: "#SomeHashTag — "
-
-exclude:
-- self-paced
-
-content:
-- shared/title.md
-- logistics-ludovic.md
-- k8s/intro.md
-- shared/about-slides.md
-- shared/chat-room-im.md
-#- shared/chat-room-zoom-meeting.md
-#- shared/chat-room-zoom-webinar.md
-- shared/toc.md
-# DAY 1
--
-  - k8s/prereqs-advanced.md
-  - shared/handson.md
-  - k8s/architecture.md
-  - k8s/deploymentslideshow.md
-  - k8s/dmuc-easy.md
--
-  - k8s/dmuc-medium.md
-  - k8s/dmuc-hard.md
-  - k8s/cni-internals.md
-  #- k8s/interco.md
-  - k8s/apilb.md
--
-  - k8s/internal-apis.md
-  - k8s/staticpods.md
-  - k8s/cluster-upgrade.md
-  - k8s/cluster-backup.md
-  #- k8s/cloud-controller-manager.md
--
-  - k8s/control-plane-auth.md
-  - k8s/user-cert.md
-  - k8s/csr-api.md
-  - k8s/openid-connect.md
-  - k8s/pod-security-intro.md
-  - k8s/pod-security-policies.md
-  - k8s/pod-security-admission.md
-  - shared/thankyou.md
-#-
-#  |
-#  # (Extra content)
-#  - k8s/apiserver-deepdive.md
-#  - k8s/setup-overview.md
-#  - k8s/setup-devel.md
-#  - k8s/setup-managed.md
-#  - k8s/setup-selfhosted.md

slides/_redirects

@@ -2,6 +2,7 @@
 #/ /kube-halfday.yml.html 200!
 #/ /kube-fullday.yml.html 200!
 #/ /kube-twodays.yml.html 200!
+/ /kube.yml.html 200!
 
 # And this allows to do "git clone https://container.training".
 /info/refs service=git-upload-pack https://github.com/jpetazzo/container.training/info/refs?service=git-upload-pack
@@ -16,12 +17,10 @@
 
 # Shortlinks for next training in English and French
 #/next https://www.eventbrite.com/e/livestream-intensive-kubernetes-bootcamp-tickets-103262336428
-/next https://qconsf.com/training/nov2024/asynchronous-architecture-patterns-scale-ml-and-other-high-latency-workloads
+/next https://skillsmatter.com/courses/700-advanced-kubernetes-concepts-workshop-jerome-petazzoni
 /hi5 https://enix.io/fr/services/formation/online/
 /us https://www.ardanlabs.com/live-training-events/deploying-microservices-and-traditional-applications-with-kubernetes-march-28-2022.html
 /uk https://skillsmatter.com/workshops/827-deploying-microservices-and-traditional-applications-with-kubernetes-with-jerome-petazzoni
 
 # Survey form
 /please https://docs.google.com/forms/d/e/1FAIpQLSfIYSgrV7tpfBNm1hOaprjnBHgWKn5n-k5vtNXYJkOX1sRxng/viewform
-
-/ /highfive.html 200!

slides/autopilot/package.json

@@ -2,8 +2,8 @@
   "name": "container-training-pub-sub-server",
   "version": "0.0.1",
   "dependencies": {
-    "express": "^4.21.1",
-    "socket.io": "^4.8.0",
-    "socket.io-client": "^4.7.5"
+    "express": "^4.16.2",
+    "socket.io": "^4.6.1",
+    "socket.io-client": "^4.5.1"
   }
 }

slides/containers/Buildkit.md

@@ -40,7 +40,7 @@
 
 - In multi-stage builds, all stages can be built in parallel
 
-  (example: https://github.com/jpetazzo/shpod; [before][shpod-before-parallel] and [after][shpod-after-parallel])
+  (example: https://github.com/jpetazzo/shpod; [before] and [after])
 
 - Stages are built only when they are necessary
 
@@ -50,8 +50,8 @@
 
 - Files are cached in the builder
 
-[shpod-before-parallel]: https://github.com/jpetazzo/shpod/blob/c6efedad6d6c3dc3120dbc0ae0a6915f85862474/Dockerfile
-[shpod-after-parallel]: https://github.com/jpetazzo/shpod/blob/d20887bbd56b5fcae2d5d9b0ce06cae8887caabf/Dockerfile
+[before]: https://github.com/jpetazzo/shpod/blob/c6efedad6d6c3dc3120dbc0ae0a6915f85862474/Dockerfile
+[after]: https://github.com/jpetazzo/shpod/blob/d20887bbd56b5fcae2d5d9b0ce06cae8887caabf/Dockerfile
 
 ---
 
@@ -121,10 +121,10 @@ docker buildx build … \
 
 - Must not use binary downloads with hard-coded architectures!
 
-  (streamlining a Dockerfile for multi-arch: [before][shpod-before-multiarch], [after][shpod-after-multiarch])
+  (streamlining a Dockerfile for multi-arch: [before], [after])
 
-[shpod-before-multiarch]: https://github.com/jpetazzo/shpod/blob/d20887bbd56b5fcae2d5d9b0ce06cae8887caabf/Dockerfile
-[shpod-after-multiarch]: https://github.com/jpetazzo/shpod/blob/c50789e662417b34fea6f5e1d893721d66d265b7/Dockerfile
+[before]: https://github.com/jpetazzo/shpod/blob/d20887bbd56b5fcae2d5d9b0ce06cae8887caabf/Dockerfile
+[after]: https://github.com/jpetazzo/shpod/blob/c50789e662417b34fea6f5e1d893721d66d265b7/Dockerfile
 
 ---
 

slides/containers/Compose_For_Dev_Stacks.md

@@ -32,7 +32,7 @@ Compose enables a simple, powerful onboarding workflow:
 
 1. Checkout our code.
 
-2. Run `docker compose up`.
+2. Run `docker-compose up`.
 
 3. Our app is up and running!
 
@@ -66,19 +66,19 @@ class: pic
 
 1. Write Dockerfiles
 
-2. Describe our stack of containers in a YAML file (the "Compose file")
+2. Describe our stack of containers in a YAML file called `docker-compose.yml`
 
-3. `docker compose up` (or `docker compose up -d` to run in the background)
+3. `docker-compose up` (or `docker-compose up -d` to run in the background)
 
 4. Compose pulls and builds the required images, and starts the containers
 
 5. Compose shows the combined logs of all the containers
 
-   (if running in the background, use `docker compose logs`)
+   (if running in the background, use `docker-compose logs`)
 
 6. Hit Ctrl-C to stop the whole stack
 
-   (if running in the background, use `docker compose stop`)
+   (if running in the background, use `docker-compose stop`)
 
 ---
 
@@ -86,11 +86,11 @@ class: pic
 
 After making changes to our source code, we can:
 
-1. `docker compose build` to rebuild container images
+1. `docker-compose build` to rebuild container images
 
-2. `docker compose up` to restart the stack with the new images
+2. `docker-compose up` to restart the stack with the new images
 
-We can also combine both with `docker compose up --build`
+We can also combine both with `docker-compose up --build`
 
 Compose will be smart, and only recreate the containers that have changed.
 
@@ -114,7 +114,7 @@ cd trainingwheels
 Second step: start the app.
 
 ```bash
-docker compose up
+docker-compose up
 ```
 
 Watch Compose build and run the app.
@@ -141,17 +141,7 @@ After ten seconds (or if we press `^C` again) it will forcibly kill them.
 
 ---
 
-## The Compose file
-
-* Historically: docker-compose.yml or .yaml
-
-* Recently (kind of): can also be named compose.yml or .yaml
-
-(Since [version 1.28.6, March 2021](https://docs.docker.com/compose/releases/release-notes/#1286))
-
----
-
-## Example
+## The `docker-compose.yml` file
 
 Here is the file used in the demo:
 
@@ -182,9 +172,9 @@ services:
 
 A Compose file has multiple sections:
 
-* `services` is mandatory. Each service corresponds to a container.
+* `version` is mandatory. (Typically use "3".)
 
-* `version` is optional (it used to be mandatory). It can be ignored.
+* `services` is mandatory. Each service corresponds to a container.
 
 * `networks` is optional and indicates to which networks containers should be connected.
   <br/>(By default, containers will be connected on a private, per-compose-file network.)
@@ -193,24 +183,24 @@ A Compose file has multiple sections:
 
 ---
 
-class: extra-details
-
 ## Compose file versions
 
 * Version 1 is legacy and shouldn't be used.
 
-  (If you see a Compose file without a `services` block, it's a legacy v1 file.)
+  (If you see a Compose file without `version` and `services`, it's a legacy v1 file.)
 
 * Version 2 added support for networks and volumes.
 
 * Version 3 added support for deployment options (scaling, rolling updates, etc).
 
+* Typically use `version: "3"`.
+
 The [Docker documentation](https://docs.docker.com/compose/compose-file/)
 has excellent information about the Compose file format if you need to know more about versions.
 
 ---
 
-## Containers in Compose file
+## Containers in `docker-compose.yml`
 
 Each service in the YAML file must contain either `build`, or `image`.
 
@@ -288,7 +278,7 @@ For the full list, check: https://docs.docker.com/compose/compose-file/
 
   `frontcopy_www`, `frontcopy_www_1`, `frontcopy_db_1`
 
-- Alternatively, use `docker compose -p frontcopy` 
+- Alternatively, use `docker-compose -p frontcopy` 
 
   (to set the `--project-name` of a stack, which default to the dir name)
 
@@ -298,10 +288,10 @@ For the full list, check: https://docs.docker.com/compose/compose-file/
 
 ## Checking stack status
 
-We have `ps`, `docker ps`, and similarly, `docker compose ps`:
+We have `ps`, `docker ps`, and similarly, `docker-compose ps`:
 
 ```bash
-$ docker compose ps
+$ docker-compose ps
 Name                      Command             State           Ports          
 ----------------------------------------------------------------------------
 trainingwheels_redis_1   /entrypoint.sh red   Up      6379/tcp               
@@ -320,13 +310,13 @@ If you have started your application in the background with Compose and
 want to stop it easily, you can use the `kill` command:
 
 ```bash
-$ docker compose kill
+$ docker-compose kill
 ```
 
-Likewise, `docker compose rm` will let you remove containers (after confirmation):
+Likewise, `docker-compose rm` will let you remove containers (after confirmation):
 
 ```bash
-$ docker compose rm
+$ docker-compose rm
 Going to remove trainingwheels_redis_1, trainingwheels_www_1
 Are you sure? [yN] y
 Removing trainingwheels_redis_1...
@@ -337,19 +327,19 @@ Removing trainingwheels_www_1...
 
 ## Cleaning up (2)
 
-Alternatively, `docker compose down` will stop and remove containers.
+Alternatively, `docker-compose down` will stop and remove containers.
 
 It will also remove other resources, like networks that were created for the application.
 
 ```bash
-$ docker compose down
+$ docker-compose down
 Stopping trainingwheels_www_1 ... done
 Stopping trainingwheels_redis_1 ... done
 Removing trainingwheels_www_1 ... done
 Removing trainingwheels_redis_1 ... done
 ```
 
-Use `docker compose down -v` to remove everything including volumes.
+Use `docker-compose down -v` to remove everything including volumes.
 
 ---
 
@@ -379,15 +369,15 @@ Use `docker compose down -v` to remove everything including volumes.
 
 - If the container is deleted, the volume gets orphaned
 
-- Example: `docker compose down && docker compose up`
+- Example: `docker-compose down && docker-compose up`
 
   - the old volume still exists, detached from its container
 
   - a new volume gets created
 
-- `docker compose down -v`/`--volumes` deletes volumes
+- `docker-compose down -v`/`--volumes` deletes volumes
 
-  (but **not** `docker compose down && docker compose down -v`!)
+  (but **not** `docker-compose down && docker-compose down -v`!)
  
 ---
 
@@ -406,9 +396,9 @@ volumes:
 
 - Volume will be named `<project>_data`
 
-- It won't be orphaned with `docker compose down`
+- It won't be orphaned with `docker-compose down`
 
-- It will correctly be removed with `docker compose down -v`
+- It will correctly be removed with `docker-compose down -v`
 
 ---
 
@@ -427,7 +417,7 @@ services:
 
   (for migration, backups, disk usage accounting...)
 
-- Won't be removed by `docker compose down -v`
+- Won't be removed by `docker-compose down -v`
 
 ---
 
@@ -461,7 +451,7 @@ services:
 
 - This is used when bringing up individual services
 
-  (e.g. `docker compose up blah` or `docker compose run foo`)
+  (e.g. `docker-compose up blah` or `docker-compose run foo`)
 
 ⚠️ It doesn't make a service "wait" for another one to be up!
 
@@ -481,9 +471,7 @@ class: extra-details
 
   - `docker compose` command to deploy Compose stacks to some clouds
 
-  - in Go instead of Python
-
-  - progressively getting feature parity with `docker compose`
+  - progressively getting feature parity with `docker-compose`
 
   - also provides numerous improvements (e.g. leverages BuildKit by default)
 

slides/containers/Copying_Files_During_Build.md

@@ -120,11 +120,11 @@ class: extra-details
 
   (and won't end up in the resulting image)
 
-- See the [documentation][dockerignore] for the little details
+- See the [documentation] for the little details
 
   (exceptions can be made with `!`, multiple directory levels with `**`...)
 
-[dockerignore]: https://docs.docker.com/engine/reference/builder/#dockerignore-file
+[documentation]: https://docs.docker.com/engine/reference/builder/#dockerignore-file
 
 ???
 

slides/docker-compose.yaml

@@ -1,3 +1,5 @@
+version: "2"
+
 services:
   www:
     image: nginx

slides/exercises/ingress-brief.md

@@ -1,4 +1,4 @@
-## Exercise — Ingress Controller
+## Exercise — Ingress
 
 - Add an ingress controller to a Kubernetes cluster
 

slides/exercises/ingress-details.md

@@ -1,4 +1,4 @@
-# Exercise — Ingress Controller
+# Exercise — Ingress
 
 - We want to expose a couple of web apps through an ingress controller
 
@@ -128,4 +128,4 @@ This is similar to the previous scenario, but with two significant changes:
 
 1. We only want to run the ingress controller on nodes that have the role `ingress`.
 
-2. We want to either use `hostPort`, or a list of `externalIPs` (not `hostNetwork`).
+2. We don't want to use `hostNetwork`, but a list of `externalIPs` instead.

slides/exercises/netpol-details.md

@@ -1,6 +1,6 @@
 # Exercise — Network Policies
 
-We want to implement a generic network security mechanism.
+We want to to implement a generic network security mechanism.
 
 Instead of creating one policy per service, we want to
 create a fixed number of policies, and use a single label

slides/exercises/polykuberbac-brief.md

@@ -1,4 +1,4 @@
-## Exercise — Enable RBAC
+## Exercise — Enable RBAC on our custom cluster
 
 - Enable RBAC on a manually-deployed control plane
 

slides/exercises/polykuberbac-details.md

@@ -1,4 +1,4 @@
-# Exercise — Enable RBAC
+# Exercise — Enable RBAC on our custom cluster
 
 - We want to enable RBAC on the "polykube" cluster
 

slides/exercises/reqlim-brief.md

@@ -1,7 +0,0 @@
-## Exercise — Requests and Limits
-
-- Check current resource allocation and utilization
-
-- Make sure that all workloads have requests (and perhaps limits)
-
-- Make sure that all *future* workloads too!

slides/exercises/reqlim-details.md

@@ -1,55 +0,0 @@
-# Exercise — Requests and Limits
-
-By default, if we don't specify *resource requests*,
-our workloads will run in `BestEffort` quality of service.
-
-`BestEffort` is very bad for production workloads,
-because the scheduler has no idea of the actual resource
-requirements of our apps, and won't be able to make
-smart decisions about workload placement.
-
-As a result, when the cluster gets overloaded, 
-containers will be killed, pods will be evicted,
-and service disruptions will happen.
-
-Let's solve this!
-
----
-
-## Check current state
-
-- Check *allocations*
-
-  (i.e. which pods have requests and limits for CPU and memory)
-
-- Then check *utilization*
-
-  (i.e. actual resource usage)
-
-- Possible tools: `kubectl`, plugins like `view-allocations`, Prometheus...
-
----
-
-## Follow best practices
-
-- We want to make sure that *all* workloads have requests
-
-  (and perhaps limits, too!)
-
-- Depending on the workload:
-
-  - edit its YAML manifest
-
-  - adjust its Helm values
-
-  - add LimitRange in its Namespace
-
-- Then check again to confirm that the job has been done properly!
-
----
-
-## Be future-proof!
-
-- We want to make sure that *future* workloads will have requests, too
-
-- How can that be implemented?

slides/exercises/sealed-secrets-details.md

@@ -1,4 +1,4 @@
-# Exercise — Sealed Secrets
+# Exercise — Sealed Secrets (and more RBAC!)
 
 This is a "combo exercise" to practice the following concepts:
 

slides/find-duplicate-markdown-links.sh

@@ -1,5 +0,0 @@
-#!/bin/sh
-for LINK in $(cat */*.md | sed -n 's/^\[\(.*\)\]:.*/\1/p' | sort | uniq -d); do
-  grep '^\['"$LINK"'\]:' */*.md
-done
-

slides/highfive.html

@@ -1,129 +0,0 @@
-<?xml version="1.0"?>
-<html>
-  <head>
-    <style>
-      td { 
-        background: #ccc; 
-        padding: 1em;
-      }
-</style>
-  </head>
-  <body>
-    <table>
-
-      <tr>
-        <td>Mardi 21 janvier 2025</td>
-        <td>
-          <a href="1.yml.html">Docker Intensif</a>
-        </td>
-      </tr>
-      <tr>
-        <td>Mercredi 22 janvier 2025</td>
-        <td>
-          <a href="1.yml.html">Docker Intensif</a>
-        </td>
-      </tr>
-      <tr>
-        <td>Jeudi 23 janvier 2025</td>
-        <td>
-          <a href="1.yml.html">Docker Intensif</a>
-        </td>
-      </tr>
-      <tr>
-        <td>Vendredi 24 janvier 2025</td>
-        <td>
-          <a href="1.yml.html">Docker Intensif</a>
-        </td>
-      </tr>
-
-      <tr>
-        <td>Mardi 28 janvier 2025</td>
-        <td>
-          <a href="2.yml.html">Fondamentaux Kubernetes</a>
-        </td>
-      </tr>
-      <tr>
-        <td>Mercredi 29 janvier 2025</td>
-        <td>
-          <a href="2.yml.html">Fondamentaux Kubernetes</a>
-        </td>
-      </tr>
-      <tr>
-        <td>Jeudi 30 janvier 2025</td>
-        <td>
-          <a href="2.yml.html">Fondamentaux Kubernetes</a>
-        </td>
-      </tr>
-      <tr>
-        <td>Vendredi 31 janvier 2025</td>
-        <td>
-          <a href="2.yml.html">Fondamentaux Kubernetes</a>
-        </td>
-      </tr>
-
-      <tr>
-        <td>Lundi 3 février 2025</td>
-        <td>
-          <a href="3.yml.html">Packaging d'applications pour Kubernetes</a>
-        </td>
-      </tr>
-      <tr>
-        <td>Mardi 4 février 2025</td>
-        <td>
-          <a href="3.yml.html">Packaging d'applications pour Kubernetes</a>
-        </td>
-      </tr>
-      <tr>
-        <td>Mercredi 5 février 2025</td>
-        <td>
-          <a href="3.yml.html">Packaging d'applications pour Kubernetes</a>
-        </td>
-      </tr>
-
-      <tr>
-        <td>Jeudi 7 février 2025</td>
-        <td>
-          <a href="4.yml.html">Kubernetes Avancé</a>
-        </td>
-      </tr>
-      <tr>
-        <td>Vendredi 7 février 2025</td>
-        <td>
-          <a href="4.yml.html">Kubernetes Avancé</a>
-        </td>
-      </tr>
-      <tr>
-        <td>Lundi 10 février 2025</td>
-        <td>
-          <a href="4.yml.html">Kubernetes Avancé</a>
-        </td>
-      </tr>
-      <tr>
-        <td>Mardi 11 février 2025</td>
-        <td>
-          <a href="4.yml.html">Kubernetes Avancé</a>
-        </td>
-      </tr>
-
-      <tr>
-        <td>Mercredi 12 février 2025</td>
-        <td>
-          <a href="5.yml.html">Opérer Kubernetes</a>
-        </td>
-      </tr>
-      <tr>
-        <td>Jeudi 13 février 2025</td>
-        <td>
-          <a href="5.yml.html">Opérer Kubernetes</a>
-        </td>
-      </tr>
-      <tr>
-        <td>Vendredi 14 février 2025</td>
-        <td>
-          <a href="5.yml.html">Opérer Kubernetes</a>
-        </td>
-      </tr>
-
-    </table>
-  </body>
-</html>

slides/interstitials.txt

@@ -1,16 +1,16 @@
-https://prettypictures.container.training/containers/Container-Ship-Freighter-Navigation-Elbe-Romance-1782991.jpg
-https://prettypictures.container.training/containers/ShippingContainerSFBay.jpg
-https://prettypictures.container.training/containers/aerial-view-of-containers.jpg
-https://prettypictures.container.training/containers/blue-containers.jpg
-https://prettypictures.container.training/containers/chinook-helicopter-container.jpg
-https://prettypictures.container.training/containers/container-cranes.jpg
-https://prettypictures.container.training/containers/container-housing.jpg
-https://prettypictures.container.training/containers/containers-by-the-water.jpg
-https://prettypictures.container.training/containers/distillery-containers.jpg
-https://prettypictures.container.training/containers/lots-of-containers.jpg
-https://prettypictures.container.training/containers/plastic-containers.JPG
-https://prettypictures.container.training/containers/train-of-containers-1.jpg
-https://prettypictures.container.training/containers/train-of-containers-2.jpg
-https://prettypictures.container.training/containers/two-containers-on-a-truck.jpg
-https://prettypictures.container.training/containers/wall-of-containers.jpeg
-https://prettypictures.container.training/containers/catene-de-conteneurs.jpg
+https://gallant-turing-d0d520.netlify.com/containers/Container-Ship-Freighter-Navigation-Elbe-Romance-1782991.jpg
+https://gallant-turing-d0d520.netlify.com/containers/ShippingContainerSFBay.jpg
+https://gallant-turing-d0d520.netlify.com/containers/aerial-view-of-containers.jpg
+https://gallant-turing-d0d520.netlify.com/containers/blue-containers.jpg
+https://gallant-turing-d0d520.netlify.com/containers/chinook-helicopter-container.jpg
+https://gallant-turing-d0d520.netlify.com/containers/container-cranes.jpg
+https://gallant-turing-d0d520.netlify.com/containers/container-housing.jpg
+https://gallant-turing-d0d520.netlify.com/containers/containers-by-the-water.jpg
+https://gallant-turing-d0d520.netlify.com/containers/distillery-containers.jpg
+https://gallant-turing-d0d520.netlify.com/containers/lots-of-containers.jpg
+https://gallant-turing-d0d520.netlify.com/containers/plastic-containers.JPG
+https://gallant-turing-d0d520.netlify.com/containers/train-of-containers-1.jpg
+https://gallant-turing-d0d520.netlify.com/containers/train-of-containers-2.jpg
+https://gallant-turing-d0d520.netlify.com/containers/two-containers-on-a-truck.jpg
+https://gallant-turing-d0d520.netlify.com/containers/wall-of-containers.jpeg
+https://gallant-turing-d0d520.netlify.com/containers/catene-de-conteneurs.jpg

slides/intro-fullday.yml

@@ -1,72 +0,0 @@
-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: https://container.training/
-
-#slidenumberprefix: "#SomeHashTag — "
-
-exclude:
-- self-paced
-
-content:
-- shared/title.md
-- logistics.md
-- containers/intro.md
-- shared/about-slides.md
-- shared/chat-room-im.md
-#- shared/chat-room-slack.md
-#- shared/chat-room-zoom-meeting.md
-#- shared/chat-room-zoom-webinar.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/Naming_And_Inspecting.md
-  #- containers/Labels.md
-  - containers/Getting_Inside.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/Exercise_Dockerfile_Basic.md
--
-  - containers/Container_Networking_Basics.md
-  #- containers/Network_Drivers.md
-  - containers/Local_Development_Workflow.md
-  - containers/Container_Network_Model.md
-  - shared/yaml.md
-  - containers/Compose_For_Dev_Stacks.md
-  - containers/Exercise_Composefile.md
--
-  - containers/Multi_Stage_Builds.md
-  #- containers/Publishing_To_Docker_Hub.md
-  - containers/Dockerfile_Tips.md
-  - containers/Exercise_Dockerfile_Advanced.md
-  #- containers/Docker_Machine.md
-  #- containers/Advanced_Dockerfiles.md
-  #- containers/Buildkit.md
-  #- containers/Init_Systems.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/Pods_Anatomy.md
-  #- containers/Ecosystem.md
-  #- containers/Orchestration_Overview.md
-  - shared/thankyou.md
-  - containers/links.md

slides/intro-selfpaced.yml

@@ -1,73 +0,0 @@
-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: https://container.training/
-
-#slidenumberprefix: "#SomeHashTag — "
-
-exclude:
-- in-person
-
-content:
-- shared/title.md
-# - shared/logistics.md
-- containers/intro.md
-- shared/about-slides.md
-#- shared/chat-room-im.md
-#- shared/chat-room-slack.md
-#- shared/chat-room-zoom-meeting.md
-#- shared/chat-room-zoom-webinar.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/Exercise_Dockerfile_Basic.md
-- - containers/Multi_Stage_Builds.md
-  - containers/Publishing_To_Docker_Hub.md
-  - containers/Dockerfile_Tips.md
-  - containers/Exercise_Dockerfile_Advanced.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
-  - shared/yaml.md
-  - containers/Compose_For_Dev_Stacks.md
-  - containers/Exercise_Composefile.md
-  - containers/Docker_Machine.md
-- - containers/Advanced_Dockerfiles.md
-  - containers/Buildkit.md
-  - containers/Init_Systems.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/Pods_Anatomy.md
-  - containers/Ecosystem.md
-  - containers/Orchestration_Overview.md
-  - shared/thankyou.md
-  - containers/links.md

slides/intro-twodays.yml

@@ -1,81 +0,0 @@
-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: https://container.training/
-
-#slidenumberprefix: "#SomeHashTag — "
-
-exclude:
-- self-paced
-
-content:
-- shared/title.md
-- logistics.md
-- containers/intro.md
-- shared/about-slides.md
-- shared/chat-room-im.md
-#- shared/chat-room-slack.md
-#- shared/chat-room-zoom-meeting.md
-#- shared/chat-room-zoom-webinar.md
-- shared/toc.md
-- # DAY 1
-  - containers/Docker_Overview.md
-  #- containers/Docker_History.md
-  - containers/Training_Environment.md
-  - containers/First_Containers.md
-  - containers/Background_Containers.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/Exercise_Dockerfile_Basic.md
--
-  - containers/Dockerfile_Tips.md
-  - containers/Multi_Stage_Builds.md
-  - containers/Publishing_To_Docker_Hub.md
-  - containers/Exercise_Dockerfile_Advanced.md
--
-  - containers/Naming_And_Inspecting.md
-  - containers/Labels.md
-  - containers/Start_And_Attach.md
-  - containers/Getting_Inside.md
-  - containers/Resource_Limits.md
-- # DAY 2
-  - containers/Container_Networking_Basics.md
-  - containers/Network_Drivers.md
-  - containers/Container_Network_Model.md
--
-  - containers/Local_Development_Workflow.md
-  - containers/Working_With_Volumes.md
-  - shared/yaml.md
-  - containers/Compose_For_Dev_Stacks.md
-  - containers/Exercise_Composefile.md
--
-  - containers/Installing_Docker.md
-  - containers/Container_Engines.md
-  - containers/Init_Systems.md
-  - containers/Advanced_Dockerfiles.md
-  - containers/Buildkit.md
--
-  - containers/Application_Configuration.md
-  - containers/Logging.md
-  - containers/Orchestration_Overview.md
--
-  - shared/thankyou.md
-  - containers/links.md
-#-
-  #- containers/Docker_Machine.md
-  #- containers/Ambassadors.md
-  #- containers/Namespaces_Cgroups.md
-  #- containers/Copy_On_Write.md
-  #- containers/Containers_From_Scratch.md
-  #- containers/Pods_Anatomy.md
-  #- containers/Ecosystem.md

slides/k8s/admission.md

@@ -20,21 +20,19 @@
 
 ## Use cases
 
-- Defaulting
+Some examples ...
 
-  *injecting image pull secrets, sidecars, environment variables...*
+- Stand-alone admission controllers
 
-- Policy enforcement and best practices
+  *validating:* policy enforcement (e.g. quotas, naming conventions ...)
 
-  *prevent: `latest` images, deprecated APIs...*
+  *mutating:* inject or provide default values (e.g. pod presets)
 
-  *require: PDBs, resource requests/limits, labels/annotations, local registry...*
+- Admission controllers part of a greater system
 
-- Problem mitigation
+  *validating:* advanced typing for operators
 
-  *block nodes with vulnerable kernels, inject log4j mitigations...*
-
-- Extended validation for operators
+  *mutating:* inject sidecars for service meshes
 
 ---
 
@@ -200,64 +198,6 @@
 
   (the Node "echo" app, the Flask app, and one ngrok tunnel for each of them)
 
-- We will need an ngrok account for the tunnels
-
-  (a free account is fine)
-
----
-
-class: extra-details
-
-## What's ngrok?
-
-- Ngrok provides secure tunnels to access local services
-
-- Example: run `ngrok http 1234`
-
-- `ngrok` will display a publicly-available URL (e.g. https://xxxxyyyyzzzz.ngrok.app)
-
-- Connections to https://xxxxyyyyzzzz.ngrok.app will terminate at `localhost:1234`
-
-- Basic product is free; extra features (vanity domains, end-to-end TLS...) for $$$
-
-- Perfect to develop our webhook!
-
----
-
-class: extra-details
-
-## Ngrok in production
-
-- Ngrok was initially known for its local webhook development features
-
-- It now supports production scenarios as well
-
-  (load balancing, WAF, authentication, circuit-breaking...)
-
-- Including some that are very relevant to Kubernetes
-
-  (e.g. [ngrok Ingress Controller](https://github.com/ngrok/kubernetes-ingress-controller)
-
----
-
-## Ngrok tokens
-
-- If you're attending a live training, you might have an ngrok token
-
-- Look in `~/ngrok.env` and if that file exists, copy it to the stack:
-
-.lab[
-
-```bash
-cp ~/ngrok.env ~/container.training/webhooks/admission/.env
-```
-
-]
-
----
-
-## Starting the whole stack
-
 .lab[
 
 - Go to the webhook directory:
@@ -276,6 +216,28 @@ cp ~/ngrok.env ~/container.training/webhooks/admission/.env
 
 ---
 
+class: extra-details
+
+## What's ngrok?
+
+- Ngrok provides secure tunnels to access local services
+
+- Example: run `ngrok http 1234`
+
+- `ngrok` will display a publicly-available URL (e.g. https://xxxxyyyyzzzz.ngrok.io)
+
+- Connections to https://xxxxyyyyzzzz.ngrok.io will terminate at `localhost:1234`
+
+- Basic product is free; extra features (vanity domains, end-to-end TLS...) for $$$
+
+- Perfect to develop our webhook!
+
+- Probably not for production, though
+
+  (webhook requests and responses now pass through the ngrok platform)
+
+---
+
 ## Update the webhook configuration
 
 - We have a webhook configuration in `k8s/webhook-configuration.yaml`

slides/k8s/architecture.md

@@ -141,6 +141,12 @@ class: pic
 
 class: pic
 
+![](images/control-planes/non-dedicated-stacked-nodes.svg)
+
+---
+
+class: pic
+
 ![](images/control-planes/advanced-control-plane.svg)
 
 ---
@@ -151,12 +157,6 @@ class: pic
 
 ---
 
-class: pic
-
-![](images/control-planes/non-dedicated-stacked-nodes.svg)
-
----
-
 # The Kubernetes API
 
 [

slides/k8s/argocd.md

@@ -1,592 +0,0 @@
-# ArgoCD
-
-- We're going to implement a basic GitOps workflow with ArgoCD
-
-- Pushing to the default branch will automatically deploy to our clusters
-
-- There will be two clusters (`dev` and `prod`)
-
-- The two clusters will have similar (but slightly different) workloads
-
-![ArgoCD Logo](images/argocdlogo.png)
-
----
-
-## ArgoCD concepts
-
-ArgoCD manages **applications** by **syncing** their **live state** with their **target state**.
-
-- **Application**: a group of Kubernetes resources managed by ArgoCD.
-  <br/>
-  Also a custom resource (`kind: Application`) managing that group of resources.
-
-- **Application source type**: the **Tool** used to build the application (Kustomize, Helm...)
-
-- **Target state**: the desired state of an **application**, as represented by the git repository.
-
-- **Live state**: the current state of the application on the cluster.
-
-- **Sync status**: whether or not the live state matches the target state.
-
-- **Sync**: the process of making an application move to its target state.
-  <br/>
-  (e.g. by applying changes to a Kubernetes cluster)
-
-(Check [ArgoCD core concepts](https://argo-cd.readthedocs.io/en/stable/core_concepts/) for more definitions!)
-
----
-
-## Getting ready
-
-- Let's make sure we have two clusters
-
-- It's OK to use local clusters (kind, minikube...)
-
-- We need to install the ArgoCD CLI ([argocd-packages], [argocd-binaries])
-
-- **Highly recommended:** set up CLI completion!
-
-- Of course we'll need a Git service, too
-
----
-
-## Setting up ArgoCD
-
-- The easiest way is to use upstream YAML manifests
-
-- There is also a [Helm chart][argocd-helmchart] if we need more customization
-
-.lab[
-
-- Create a namespace for ArgoCD and install it there:
-  ```bash
-  kubectl create namespace argocd
-  kubectl apply --namespace argocd -f \
-      https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml
-  ```
-
-]
-
----
-
-## Logging in with the ArgoCD CLI
-
-- The CLI can talk to the ArgoCD API server or to the Kubernetes API server
-
-- For simplicity, we're going to authenticate and communicate with the Kubernetes API
-
-.lab[
-
-- Authenticate with the ArgoCD API (that's what the `--core` flag does):
-  ```bash
-  argocd login --core
-  ```
-
-- Check that everything is fine:
-  ```bash
-  argocd version
-  ```
-]
-
---
-
-🤔 `FATA[0000] error retrieving argocd-cm: configmap "argocd-cm" not found`
-
----
-
-## ArgoCD CLI shortcomings
-
-- When using "core" authentication, the ArgoCD CLI uses our current Kubernetes context
-
-  (as defined in our kubeconfig file)
-
-- That context need to point to the correct namespace
-
-  (the namespace where we installed ArgoCD)
-
-- In fact, `argocd login --core` doesn't communicate at all with ArgoCD!
-
-  (it only updates a local ArgoCD configuration file)
-
----
-
-## Trying again in the right namespace
-
-- We will need to run all `argocd` commands in the `argocd` namespace
-
-  (this limitation only applies to "core" authentication; see [issue 14167][issue14167])
-
-.lab[
-
-- Switch to the `argocd` namespace:
-  ```bash
-  kubectl config set-context --current --namespace argocd
-  ```
-
-- Check that we can communicate with the ArgoCD API now:
-  ```bash
-  argocd version
-  ```
-
-]
-
-- Let's have a look at ArgoCD architecture!
-
----
-
-class: pic
-
-![ArgoCD Architecture](images/argocd_architecture.png)
-
----
-
-## ArgoCD API Server
-
-The API server is a gRPC/REST server which exposes the API consumed by the Web UI, CLI, and CI/CD systems. It has the following responsibilities:
-
-- application management and status reporting
-
-- invoking of application operations (e.g. sync, rollback, user-defined actions)
-
-- repository and cluster credential management (stored as K8s secrets)
-
-- authentication and auth delegation to external identity providers
-
-- RBAC enforcement
-
-- listener/forwarder for Git webhook events
-
----
-
-## ArgoCD Repository Server
-
-The repository server is an internal service which maintains a local cache of the Git repositories holding the application manifests. It is responsible for generating and returning the Kubernetes manifests when provided the following inputs:
-
-- repository URL
-
-- revision (commit, tag, branch)
-
-- application path
-
-- template specific settings: parameters, helm values...
-
----
-
-## ArgoCD Application Controller
-
-The application controller is a Kubernetes controller which continuously monitors running applications and compares the current, live state against the desired target state (as specified in the repo). 
-
-It detects *OutOfSync* application state and optionally takes corrective action. 
-
-It is responsible for invoking any user-defined hooks for lifecycle events (*PreSync, Sync, PostSync*).
-
----
-
-## Preparing a repository for ArgoCD
-
-- We need a repository with Kubernetes YAML manifests
-
-- You can fork [kubercoins] or create a new, empty repository
-
-- If you create a new, empty repository, add some manifests to it
-
----
-
-## Add an Application
-
-- An Application can be added to ArgoCD via the web UI or the CLI
-
-  (either way, this will create a custom resource of `kind: Application`)
-
-- The Application should then automatically be deployed to our cluster
-
-  (the application manifests will be "applied" to the cluster)
-
-.lab[
-
-- Let's use the CLI to add an Application:
-  ```bash
-    argocd app create kubercoins \ 
-           --repo https://github.com/`<your_user>/<your_repo>`.git \
-           --path . --revision `<branch>` \
-           --dest-server https://kubernetes.default.svc \
-           --dest-namespace kubercoins-prod
-  ```
-
-]
-
----
-
-## Checking progress
-
-- We can see sync status in the web UI or with the CLI
-
-.lab[
-
-- Let's check app status with the CLI:
-  ```bash
-  argocd app list
-  ```
-
-- We can also check directly with the Kubernetes CLI:
-  ```bash
-  kubectl get applications
-  ```
-
-]
-
-- The app is there and it is `OutOfSync`!
-
----
-
-## Manual sync with the CLI
-
-- By default the "sync policy" is `manual`
-
-- It can also be set to `auto`, which would check the git repository every 3 minutes
-
-  (this interval can be [configured globally][pollinginterval])
-
-- Manual sync can be triggered with the CLI
-
-.lab[
-
-- Let's force an immediate sync of our app:
-  ```bash
-    argocd app sync kubercoins
-  ```
-]
-
-🤔 We're getting errors!
-
----
-
-## Sync failed
-
-We should receive a failure:
-
-`FATA[0000] Operation has completed with phase: Failed`
-
-And in the output, we see more details:
-
-`Message: one or more objects failed to apply,`
-<br/>
-`reason: namespaces "kubercoins-prod" not found`
-
----
-
-## Creating the namespace
-
-- There are multiple ways to achieve that
-
-- We could generate a YAML manifest for the namespace and add it to the git repository
-
-- Or we could use "Sync Options" so that ArgoCD creates it automatically!
-
-- ArgoCD provides many "Sync Options" to handle various edge cases
-
-- Some [others](https://argo-cd.readthedocs.io/en/stable/user-guide/sync-options/) are: `FailOnSharedResource`, `PruneLast`, `PrunePropagationPolicy`...
-
----
-
-## Editing the app's sync options
-
-- This can be done through the web UI or the CLI
-
-.lab[
-
-- Let's use the CLI once again:
-  ```bash
-  argocd app edit kubercoins
-  ```
-
-- Add the following to the YAML manifest, at the root level:
-  ```yaml
-    syncPolicy:
-      syncOptions:
-        - CreateNamespace=true
-  ```
-
-]
-
----
-
-## Sync again
-
-.lab[
-
-- Let's retry the sync operation:
-  ```bash
-  argocd app sync kubercoins
-  ```
-
-- And check the application status:
-  ```bash
-  argocd app list
-  kubectl get applications
-  ```
-
-]
-
-- It should show `Synced` and `Progressing`
-
-- After a while (when all pods are running correctly) it should be `Healthy`
-
----
-
-## Managing Applications via the Web UI
-
-- ArgoCD is popular in large part due to its browser-based UI
-
-- Let's see how to manage Applications in the web UI
-
-.lab[
-
-- Expose the web dashboard on a local port:
-  ```bash
-  argocd admin dashboard
-  ```
-
-- This command will show the dashboard URL; open it in a browser
-
-- Authentication should be automatic
-
-]
-
-Note: `argocd admin dashboard` is similar to `kubectl port-forward` or `kubectl-proxy`.
-
-(The dashboard remains available as long as `argocd admin dashboard` is running.)
-
----
-
-## Adding a staging Application
-
-- Let's add another Application for a staging environment
-
-- First, create a new branch (e.g. `staging`) in our kubercoins fork
-
-- Then, in the ArgoCD web UI, click on the "+ NEW APP" button
-
-  (on a narrow display, it might just be "+", right next to buttons looking like 🔄 and ↩️)
-
-- See next slides for details about that form!
-
----
-
-## Defining the Application
-
-| Field            | Value                                      |
-|------------------|--------------------------------------------|
-| Application Name | `kubercoins-stg`                           |
-| Project Name     | `default`                                  |
-| Sync policy      | `Manual`                                   |
-| Sync options     | check `auto-create namespace`              |
-| Repository URL   | `https://github.com/<username>/<reponame>` |
-| Revision         | `<branchname>`                             |
-| Path             | `.`                                        |
-| Cluster URL      | `https://kubernetes.default.svc`           |
-| Namespace        | `kubercoins-stg`                           |
-
-Then click on the "CREATE" button (top left).
-
----
-
-## Synchronizing the Application
-
-- After creating the app, it should now show up in the app tiles
-
-  (with a yellow outline to indicate that it's out of sync)
-
-- Click on the "SYNC" button on the app tile to show the sync panel
-
-- In the sync panel, click on "SYNCHRONIZE"
-
-- The app will start to synchronize, and should become healthy after a little while
-
----
-
-## Making changes
-
-- Let's make changes to our application manifests and see what happens
-
-.lab[
-
-- Make a change to a manifest
-
-  (for instance, change the number of replicas of a Deployment)
-
-- Commit that change and push it to the staging branch
-
-- Check the application sync status:
-  ```bash
-  argocd app list
-  ```
-
-]
-
-- After a short period of time (a few minutes max) the app should show up "out of sync"
-
----
-
-## Automated synchronization
-
-- We don't want to manually sync after every change
-
-  (that wouldn't be true continuous deployment!)
-
-- We're going to enable "auto sync"
-
-- Note that this requires much more rigorous testing and observability!
-
-  (we need to be sure that our changes won't crash our app or even our cluster)
-
-- Argo project also provides [Argo Rollouts][rollouts]
-
-  (a controller and CRDs to provide blue-green, canary deployments...)
-
-- Today we'll just turn on automated sync for the staging namespace
-
----
-
-## Enabling auto-sync
-
-- In the web UI, go to *Applications* and click on *kubercoins-stg*
-
-- Click on the "DETAILS" button (top left, might be just a "i" sign on narrow displays)
-
-- Click on "ENABLE AUTO-SYNC" (under "SYNC POLICY")
-
-- After a few minutes the changes should show up!
-
----
-
-## Rolling back
-
-- If we deploy a broken version, how do we recover?
-
-- "The GitOps way": revert the changes in source control
-
-  (see next slide)
-
-- Emergency rollback:
-
-  - disable auto-sync (if it was enabled)
-
-  - on the app page, click on "HISTORY AND ROLLBACK"
-    <br/>
-    (with the clock-with-backward-arrow icon)
-
-  - click on the "..." button next to the button we want to roll back to
-
-  - click "Rollback" and confirm
-
----
-
-## Rolling back with GitOps
-
-- The correct way to roll back is rolling back the code in source control
-
-```bash
-git checkout staging
-git revert HEAD
-git push origin staging
-```
-
----
-
-## Working with Helm
-
-- ArgoCD supports different tools to process Kubernetes manifests:
-
-  Kustomize, Helm, Jsonnet, and [Config Management Plugins][cmp]
-
-- Let's how to deploy Helm charts with ArgoCD!
-
-- In the [kubercoins] repository, there is a branch called [helm-branch]
-
-- It provides a generic Helm chart, in the [generic-service] directory
-
-- There are service-specific values YAML files in the [values] directory
-
-- Let's create one application for each of the 5 components of our app!
-
----
-
-## Creating a Helm Application
-
-- The example below uses "upstream" kubercoins
-
-- Feel free to use your own fork instead!
-
-.lab[
-
-- Create an Application for `hasher`:
-  ```bash
-    argocd app create hasher \
-           --repo https://github.com/jpetazzo/kubercoins.git \
-           --path generic-service --revision helm \
-           --dest-server https://kubernetes.default.svc \
-           --dest-namespace kubercoins-helm \
-           --sync-option CreateNamespace=true \
-           --values ../values/hasher.yaml \
-           --sync-policy=auto
-  ```
-
-]
-
----
-
-## Deploying the rest of the application
-
-- Option 1: repeat the previous command (updating app name and values)
-
-- Option 2: author YAML manifests and apply them
-
----
-
-## Additional considerations
-
-- When running in production, ArgoCD can be integrated with an [SSO provider][sso]
-
-  - ArgoCD embeds and bundles [Dex] to delegate authentication
-
-  - it can also use an existing OIDC provider (Okta, Keycloak...)
-
-- A single ArgoCD instance can manage multiple clusters 
-
-  (but it's also fine to have one ArgoCD per cluster)
-
-- ArgoCD can be complemented with [Argo Rollouts][rollouts] for advanced rollout control
-
-  (blue/green, canary...)
-
----
-
-## Acknowledgements
-
-Many thanks to
-Anton (Ant) Weiss ([antweiss.com](https://antweiss.com), [@antweiss](https://twitter.com/antweiss))
-and
-Guilhem Lettron
-for contributing an initial version and suggestions to this ArgoCD chapter.
-
-All remaining typos, mistakes, or approximations are mine (Jérôme Petazzoni). 
-
-[argocd-binaries]: https://github.com/argoproj/argo-cd/releases/latest
-[argocd-helmchart]: https://artifacthub.io/packages/helm/argo/argocd-apps
-[argocd-packages]: https://argo-cd.readthedocs.io/en/stable/cli_installation/
-[cmp]: https://argo-cd.readthedocs.io/en/stable/operator-manual/config-management-plugins/
-[Dex]: https://github.com/dexidp/dex
-[generic-service]: https://github.com/jpetazzo/kubercoins/tree/helm/generic-service
-[helm-branch]: https://github.com/jpetazzo/kubercoins/tree/helm
-[issue14167]: https://github.com/argoproj/argo-cd/issues/14167
-[kubercoins]: https://github.com/jpetazzo/kubercoins
-[pollinginterval]: https://argo-cd.readthedocs.io/en/stable/faq/#how-often-does-argo-cd-check-for-changes-to-my-git-or-helm-repository
-[rollouts]: https://argoproj.github.io/rollouts/
-[sso]: https://argo-cd.readthedocs.io/en/stable/operator-manual/user-management/#sso
-[values]: https://github.com/jpetazzo/kubercoins/tree/helm/values
-
-???
-
-:EN:- Implementing gitops with ArgoCD
-:FR:- Workflow gitops avec ArgoCD

slides/k8s/bento-cnpg.md

@@ -1,173 +0,0 @@
-# Bento & PostgreSQL
-
-- Bento can also use SQL databases for input/output
-
-- We're going to demonstrate that by writing to a PostgreSQL database
-
-- That database will be deployed with the Cloud Native PostGres operator
-
-  (https://cloudnative-pg.io/)
-
----
-
-## CNPG in a nutshell
-
-- Free, open source
-
-- Originally created by [EDB] (EnterpriseDB, well-known PgSQL experts)
-
-- Non-exhaustive list of features:
-
-  - provisioning of Postgres servers, replicas, bouncers
-
-  - automatic failover
-
-  - backups (full backups and WAL shipping)
-
-  - provisioning from scratch, from backups, PITR
-
-  - manual and automated switchover (e.g. for node maintenance)
-
-  - and many more!
-
-[EDB]: https://www.enterprisedb.com/workload/kubernetes
-
----
-
-## What we're going to do
-
-1. Install CNPG.
-
-2. Provision a Postgres cluster.
-
-3. Configure Bento to write to that cluster.
-
-4. Set up a Grafana dashboard to see the data.
-
----
-
-## 1️⃣ Installing CNPG
-
-Many options available, see the [documentation][cnpg-install]:
-
-- raw YAML manifests
-
-- kubectl CNPG plugin (`kubectl cnpg install generate`)
-
-- Helm chart
-
-- OLM
-
-[cnpg-install]: https://cloudnative-pg.io/documentation/1.24/installation_upgrade/
-
----
-
-## 2️⃣ Provisioning a Postgres cluster
-
-Minimal manifest:
-
-```yaml
-apiVersion: postgresql.cnpg.io/v1
-kind: Cluster
-metadata:
-  name: db
-spec:
-  storage:
-    size: 1Gi
-```
-
----
-
-class: extra-details
-
-## For production...
-
-We might also add:
-
-- `spec.monitoring.enablePodMonitor: true`
-
-- `spec.instances: 2`
-
-- `resources.{requests,limits}.{cpu,memory}`
-
-- `walStorage.size`
-
-- `backup`
-
-- `postgresql.parameters`
-
-See [this manifest][cluster-maximal] for a detailed example.
-
-[cluster-maximal]: https://github.com/jpetazzo/pozok/blob/main/cluster-maximal.yaml
-
----
-
-## 3️⃣ Configuring Bento to write to SQL
-
-- We'll use the [`sql_insert`][sql-insert] output
-
-- If our cluster is named `mydb`, there will be a Secret `mydb-app`
-
-- This Secret will contain a `uri` field
-
-- That field can be used as the `dns` in the Bento configuration
-
-- We will also need to create the table that we want to use
-
-  (see next slide for instructions)
-
-[sql-insert]: https://warpstreamlabs.github.io/bento/docs/components/outputs/sql_insert
-
----
-
-## Creating a table
-
-- If we just want to store the city name and its population:
-  ```sql
-      CREATE TABLE IF NOT EXISTS cities (
-        city varchar(100) NOT NULL,
-        population integer
-      );
-  ```
-
-- This statement can be executed:
-
-  - manually, by getting a `psql` shell with `kubectl cnpg psql mydb app`
-
-  - automatically, with Bento's `init_statatement`
-
----
-
-## 4️⃣ Viewing the table in Grafana
-
-- In Grafana, in the home menu on the lift, click "connections"
-
-- Add a PostgreSQL data source
-
-- Enter the host:port, database, user, password
-
-- Then add a visualization using that data source
-
-  (it should be relatively self-explanatory!)
-
----
-
-class: extra-details
-
-## Automating it all
-
-- Expose PostgreSQL credentials through environment variables
-
-  (in the Bento container)
-
-- Use the `${...}` syntax in Bento to use these environment variables
-
-- Export the Grafana dashboard to a JSON file
-
-- Store the JSON file in a ConfigMap, with label `grafana_dashboard=1`
-
-- Create that ConfigMap in the namespace where Grafana is running
-
-- Similarly, data sources (like the Redis and the PostgreSQL one) can be defined in YAML
-
-- And that YAML can be put in a ConfigMap with label `grafana_datasource=1`

slides/k8s/bento-hpa.md

@@ -1,450 +0,0 @@
-# Autoscaling with KEDA
-
-- Cluster autoscaling = automatically add nodes *when needed*
-
-- *When needed* = when Pods are `Pending`
-
-- How do these pods get created?
-
-- When the Ollama Deployment is scaled up
-
-  - ... manually (e.g. `kubectl scale`)
-
-  - ... automatically (that's what we want to investigate now!)
-
----
-
-## Ways to implement autoscaling
-
-- Custom code
-
-  (e.g. crontab checking some value every few minutes and scaling accordingly)
-
-- Kubernetes Horizontal Pod Autoscaler v1
-
-  (aka `kubectl autoscale`)
-
-- Kubernetes Horizontal Pod Autoscaler v2 with custom metrics
-
-  (e.g. with Prometheus Adapter)
-
-- Kubernetes Horizontal Pod Autoscaler v2 with external metrics
-
-  (e.g. with KEDA)
-
----
-
-## Custom code
-
-- No, we're not going to do that!
-
-- But this would be an interesting exercise in RBAC
-
-  (setting minimal amount of permissions for the pod running our custom code)
-
----
-
-## HPAv1
-
-Pros: very straightforward
-
-Cons: can only scale on CPU utilization
-
-How it works:
-
-- periodically measures average CPU *utilization* across pods
-
-- if utilization is above/below a target (default: 80%), scale up/down
-
----
-
-## HPAv1 in practice
-
-- Create the autoscaling policy:
-  ```bash
-  kubectl autoscale deployment ollama --max=1000
-  ```
-  (The `--max` is required; it's a safety limit.)
-
-- Check it:
-  ```bash
-  kubectl describe hpa
-  ```
-
-- Send traffic, wait a bit: pods should be created automatically
-
----
-
-## HPAv2 custom vs external
-
-- Custom metrics = arbitrary metrics attached to Kubernetes objects
-
-- External metrics = arbitrary metrics not related to Kubernetes objects
-
---
-
-🤔
-
----
-
-## HPAv2 custom metrics
-
-- Examples:
-
-  - on Pods: CPU, RAM, network traffic...
-
-  - on Ingress: requests per second, HTTP status codes, request duration...
-
-  - on some worker Deployment: number of tasks processed, task duration...
-
-- Requires an *adapter* to:
-
-  - expose the metrics through the Kubernetes *aggregation layer*
-
-  - map the actual metrics source to Kubernetes objects
-
-Example: the [Prometheus adapter][prometheus-adapter]
-
-[prometheus-adapter]: https://github.com/kubernetes-sigs/prometheus-adapter
-
----
-
-## HPAv2 custom metrics in practice
-
-- We're not going to cover this here
-
-  (too complex / not enough time!)
-
-- If you want more details, check [my other course material][hpav2slides]
-
-[hpav2slides]: https://2024-10-enix.container.training/4.yml.html#toc-scaling-with-custom-metrics
-
----
-
-## HPAv2 external metrics
-
-- Examples:
-
-  - arbitrary Prometheus query
-
-  - arbitrary SQL query
-
-  - number of messages in a queue
-
-  - and [many, many more][keda-scalers]
-
-- Also requires an extra components to expose the metrics
-
-Example: [KEDA (https://keda.sh/)](https://keda.sh)
-
-[keda-scalers]: https://keda.sh/docs/latest/scalers/
-
----
-
-## HPAv2 external metrics in practice
-
-- We're going to install KEDA
-
-- And set it up to autoscale depending on the number of messages in Redis
-
----
-
-## Installing KEDA
-
-Multiple options (details in the [documentation][keda-deploy]):
-
-- YAML
-
-- Operator Hub
-
-- Helm chart 💡
-
-```bash
-helm upgrade --install --repo https://kedacore.github.io/charts \
- --namespace keda-system --create-namespace keda keda
-```
-
-[keda-deploy]: https://keda.sh/docs/latest/deploy/
-
----
-
-## Scaling according to Redis
-
-- We need to create a KEDA Scaler
-
-- This is done with a "ScaledObject" manifest
-
-- [Here is the documentation][keda-redis-lists] for the Redis Lists Scaler
-
-- Let's write that manifest!
-
-[keda-redis-lists]: https://keda.sh/docs/latest/scalers/redis-lists/
-
----
-
-## `keda-redis-scaler.yaml`
-
-```yaml
-apiVersion: keda.sh/v1alpha1
-kind: ScaledObject
-metadata:
-  name: ollama
-spec:
-  scaleTargetRef:
-    name: ollama
-  triggers:
-  - type: redis
-    metadata:
-      address: redis.`default`.svc:6379
-      listName: cities
-      listLength: "10"
-```
-
----
-
-## Notes
-
-- We need to update the `address` field with our namespace
-
-  (unless we are running in the `default` namespace)
-
-- Alternative: use `addressFromEnv` and set an env var in the Ollama pods
-
-- `listLength` gives the target ratio of `messages / replicas`
-
-- In our example, KEDA will scale the Deployment to `messages / 100`
-
-  (rounded up!)
-
----
-
-## Trying it out
-
-- Apply the ScaledObject manifest
-
-- Start a Bento pipeline loading e.g. 100-1000 cities in Redis
-
-  (100 on smaller clusters / slower CPUs, 1000 on bigger / faster ones)
-
-- Check pod and nod resource usage
-
-- What do we see?
-
---
-
-🤩 The Deployment scaled up automatically!
-
---
-
-🤔 But Pod resource usage remains very low (A few busy pods, many idle)
-
---
-
-💡 Bento doesn't submit enough requests in parallel!
-
----
-
-## Improving throughput
-
-We're going to review multiple techniques:
-
-1. Increase parallelism inside the Bento pipeline.
-
-2. Run multiple Bento consumers.
-
-3. Couple consumers and processors more tightly.
-
----
-
-## 1️⃣ Increase pipeline parallelism
-
-- Set `parallel` to `true` in the `http` processor
-
-- Wrap the input around a `batched` input
-
-  (otherwise, we don't have enough messages in flight)
-
-- Increase `http` timeout significantly (e.g. to 5 minutes)
-
----
-
-## Results
-
-🎉 More messages flow through the pipeline
-
-🎉 Many requests happen in parallel
-
-🤔 Average Pod and Node CPU utilization is higher, but not maxed out
-
-🤔 HTTP queue size (measured with HAProxy metrics) is relatively high
-
-🤔 Latency is higher too
-
-Why?
-
----
-
-## Too many requests in parallel
-
-- Ealier, we didn't have enough...
-
-- ...Now, we have too much!
-
-- However, for a very big request queue, it still wouldn't be enough
-
-💡 We currently have a fixed parallelism. We need to make it dynamic!
-
----
-
-## 2️⃣ Run multiple Bento consumers
-
-- Restore the original Bento configuration
-
-  (flip `parallel` back to `false`; remove the `batched` input)
-
-- Run Bento in a Deployment
-
-  (e.g. with the [Bento Helm chart][bento-helm-chart])
-
-- Autoscale that Deployment like we autoscaled the Ollama Deployment
-
-[bento-helm-chart]: https://github.com/warpstreamlabs/bento-helm-chart
-
----
-
-## Results
-
-🤔🤔🤔 Pretty much the same as before!
-
-(High throughput, high utilization but not maxed out, high latency...)
-
---
-
-🤔🤔🤔 Why?
-
----
-
-## Unbalanced load balancing
-
-- All our requests go through the `ollama` Service
-
-- We're still using the default Kubernetes service proxy!
-
-- It doesn't spread the requests properly across all the backends
-
----
-
-## 3️⃣ Couple consumers and processors
-
-What if:
-
---
-
-instead of sending requests to a load balancer,
-
---
-
-each queue consumer had its own Ollama instance?
-
----
-
-## Current architecture
-
-<pre class="mermaid">
-flowchart LR
-  subgraph P1["Pod"]
-    H1["HAProxy"] --> O1["Ollama"]
-  end
-  subgraph P2["Pod"]
-    H2["HAProxy"] --> O2["Ollama"]
-  end
-  subgraph P3["Pod"]
-    H3["HAProxy"] --> O3["Ollama"]
-  end
-  Q["Queue<br/>(Redis)"] <--> C["Consumer<br/>(Bento)"] --> LB["Load Balancer<br/>(kube-proxy)"]
-  LB --> H1 & H2 & H3
-</pre>
-
----
-
-## Proposed architecture
-
-<pre class="mermaid">
-flowchart LR
-  subgraph P1["Consumer Pod"]
-    C1["Bento"] --> H1["HAProxy"] --> O1["Ollama"]
-  end
-  subgraph P2["Consumer Pod"]
-    C2["Bento"] --> H2["HAProxy"] --> O2["Ollama"]
-  end
-  subgraph P3["Consumer Pod"]
-    C3["Bento"] --> H3["HAProxy"] --> O3["Ollama"]
-  end
-  Queue["Queue"] <--> C1 & C2 & C3
-</pre>
-
----
-
-## 🏗️ Let's build something!
-
-- Let's implement that architecture!
-
-- See next slides for hints / getting started
-
----
-
-## Hints
-
-We need to:
-
-- Update the Bento consumer configuration to talk to localhost
-
-- Store that configuration in a ConfigMap
-
-- Add a Bento container to the Ollama Deployment
-
-- Profit!
-
----
-
-## Results
-
-🎉 Node and Pod utilization is maximized
-
-🎉 HTTP queue size is bounded
-
-🎉 Deployment autoscales up and down
-
----
-
-## ⚠️ Scaling down
-
-- Eventually, there are less messages in the queue
-
-- The HPA scales down the Ollama Deployment
-
-- This terminates some Ollama Pods
-
-🤔 What happens if these Pods were processing requests?
-
---
-
-- The requests might be lost!
-
----
-
-## Avoiding lost messages
-
-Option 1:
-
-- cleanly shutdown the consumer
-
-- make sure that Ollama can complete in-flight requests
-
-  (by extending its grace period)
-
-- find a way to terminate Ollama when no more requests are in flight
-
-Option 2:
-  
-- use *message acknowledgement*

slides/k8s/bento-intro.md

@@ -1,623 +0,0 @@
-# Getting started with Bento
-
-How can we move to a message queue architecture...
-
-*...without rewriting a bunch of code?*
-
-🤔
-
----
-
-## Bento
-
-https://bento.dev/
-
-"Fancy stream processing made operationally mundane"
-
-"Written in Go, deployed as a static binary, declarative configuration. Open source and cloud native as utter heck."
-
-With ✨ amazing ✨ documentation 😍
-
----
-
-class: extra-details
-
-## Tiny bit of history
-
-- Original project: Benthos
-
-- May 30, 2024: [Redpanda acquires Benthos][redpanda-acquires-benthos]
-
-  - Benthos is now Redpanda Connect
-
-  - some parts have been relicensed as commercial products
-
-- May 31, 2024: [Warpstream forks Benthos][warpstream-forks-benthos]
-
-  - that fork is named "Bento"
-
-  - it's fully open source
-
-- We're going to use Bento here, but Redpanda Connect should work fine too!
-
----
-
-## Bento concepts
-
-- Message stream processor
-
-- Each pipeline is configured by a YAML configuration that defines:
-
-  - input (where do we get the messages?)
-
-  - pipeline (optional: how do we transform the messages?)
-
-  - output (where do we put the messages afterwards?)
-
-- Once Bento is started, it runs the pipelines forever
-
-  (except for pipelines that have a logical end, e.g. reading from a file)
-
-- Embedded language (Bloblang) to manipulate/transform messages
-
----
-
-## Messages
-
-- Typically JSON objects
-
-  (but raw strings are also possible)
-
-- Nesting, arrays, etc. are OK
-
----
-
-## Getting started with Bento
-
-We're going to:
-
-1. Import a bunch of cities from a CSV file into a Redis queue.
-
-2. Read back these cities using a web server.
-
-3. Use an "enrichment workflow" to query our LLM for each city.
-
----
-
-## 1️⃣ Importing cities
-
-Let's break down the work:
-
-- download the data set
-
-- create the Bento configuration
-
-- deploy Redis
-
-- start Bento
-
----
-
-## Downloading the data set
-
-- Example database:
-
-  https://www.kaggle.com/datasets/juanmah/world-cities
-
-- Let's download and uncompress the data set:
-  ```bash
-  curl -fsSL https://www.kaggle.com/api/v1/datasets/download/juanmah/world-cities |
-    funzip > cities.csv
-  ```
-
-  (Ignore the "length error", it's harmless!)
-
-- Check the structure of the data set:
-  ```bash
-  head cities.csv
-  ```
-
----
-
-## Creating the Bento configuration
-
-- We need to find which `input` and `output` to use
-
-- Check the list with `bento list` or the [documentation][bento-inputs]
-
-- Then run `bento create INPUTNAME/PIPELINENAME/OUTPUTNAME`
-
-- Generate a configuration file:
-  ```bash
-  bento create csv//redis_list > csv2redis.yaml
-  ```
-
-- Edit that configuration file; look for the `(required)` parameters
-
-  (Everything else can go away!)
-
----
-
-## Resulting configuration
-
-If we trim all the default values, here is the result:
-
-```yaml
-input:
-  csv:
-    paths: ["cities.csv"]
-output:
-  redis_list:
-    url: redis://redis:6379 # No default (required)
-    key: cities
-```
-
-We'll call that value `csv2redis.yaml`.
-
----
-
-## Deploying Redis
-
-- Create a Deployment:
-  ```bash
-  kubectl create deployment redis --image redis
-  ```
-
-- Expose it:
-  ```bash
-  kubectl expose deployment redis --port 6379
-  ```
-
----
-
-## Starting Bento
-
-Option 1: run it manually in a pod, to see what's going on.
-
-```bash
-bento --config csv2redis.yaml
-```
-
-Option 2: run it with e.g. the Bento Helm chart.
-
-*We're not going to do that yet, since this particular pipeline has a logical end.*
-
-*(The Helm chart is best suited to pipelines that run forever.)*
-
----
-
-## Expected output
-
-.small[
-```
-INFO Running main config from specified file       @service=bento bento_version="" path=csv2redis.yaml
-INFO Launching a Bento instance, use CTRL+C to close  @service=bento
-INFO Listening for HTTP requests at: http://0.0.0.0:4195  @service=bento
-INFO Input type csv is now active                  @service=bento label="" path=root.input
-INFO Output type redis_list is now active          @service=bento label="" path=root.output
-INFO Pipeline has terminated. Shutting down the service  @service=bento
-```
-]
-
-The pipeline should complete in just a few seconds.
-
----
-
-## Checking what's in Redis
-
-- Connect to our Redis instance:
-  ```bash
-  redis-cli -h redis
-  ```
-
-- List keys:
-  ```redis
-  KEYS *
-  ```
-
-- Check that the `cities` list has approx. 47000 elements:
-  ```redis
-  LLEN cities
-  ```
-
-- Get the first element of the list:
-  ```redis
-  LINDEX cities 0
-  ```
-
----
-
-## Fun with Bloblang
-
-- Let's add a filter to keep only cities with a population above 10,000,000
-
-- Add the following block to the Bento configuration:
-
-```yaml
-pipeline:
-  processors:
-    - switch:
-        - check: this.population == ""
-          processors:
-            - mapping: root = deleted()
-        - check: this.population.int64() < 10000000
-          processors:
-            - mapping: root = deleted()
-```
-
-(See the [docs][bento-switch] for details about the `switch` processor.)
-
----
-
-## Testing our processor
-
-- First, delete the existing `cities` list:
-  ```bash
-  redis-cli -h redis DEL cities
-  ```
-
-- Then, run the Bento pipeline again:
-  ```bash
-  bento --config csv2redis.yaml
-  ```
-  (It should complain about a few cities where the population has a decimal point.)
-
-- Check how many cities were loaded:
-  ```bash
-  redis-cli -h redis LLEN cities
-  ```
-  (There should be 47.)
-
----
-
-## 2️⃣ Consume the queue over HTTP
-
-- We want to "get the next city" in the queue with a simple `curl`
-
-- Our input will be `redis_list`
-
-- Our output will be `http_server`
-
----
-
-## Generate the Bento configuration
-
-Option 1: `bento create redis_list//http_server`
-
-Option 2: [read the docs][output-http-server]
-
----
-
-## 🙋 Choose your own adventure
-
-Do you want to try to write that configuration?
-
-Or shall we see it right away?
-
---
-
-⚠️ Spoilers on next slide!
-
----
-
-## `redis2http.yaml`
-
-```yaml
-input:
-  redis_list:
-    url: redis://redis:`6379`
-    key: cities
-output:
-  http_server:
-    path: /nextcity
-```
-
-This will set up an HTTP route to fetch *one* city.
-
-It's also possible to batch, stream...
-
-⚠️ As of November 2024, `bento create` uses port 6397 instead of 6379 for Redis!
-
----
-
-## Trying it out
-
-- Run Bento with this configuration:
-  ```bash
-  bento --config redis2http.yaml &
-  ```
-
-- Retrieve one city:
-  ```bash
-  curl http://localhost:4195/nextcity
-  ```
-
-- Check what happens after we retrive *all* the cities!
-
----
-
-## 3️⃣ Query our LLM for each city
-
-- We want to ask our LLM who's the mayor of each of these cities
-
-- We'll use a prompt that will usually ensure a short answer
-
-  (so that it's faster; we don't want to wait 30 seconds per city!)
-
-- We'll test the prompt with the Ollama CLI
-
-- Then we'll craft a proper HTTP API query
-
-- Finally, we'll configure an [enrichment workflow][enrichment] in Bento
-
----
-
-## Test our prompt
-
-Assuming that our earlier Ollama Deployment is still running:
-
-```bash
-kubectl exec deployment/ollama -- \
-ollama run qwen2:1.5b "
-Who is the mayor of San Francisco?
-Just give the name by itself on a single line.
-If you don't know, don't say anything.
-"
-```
-
----
-
-## Turn the prompt into an HTTP API query
-
-Note: to install `http` in an Alpine container, run `apk add httpie`.
-
-```bash
-http http://ollama.default:11434/api/generate \
-model=qwen2:1.5b stream:=false prompt="
-Who is the mayor of Paris?
-Just give the name by itself on a single line.
-If you don't know, don't say anything.
-"
-```
-
-We get a JSON payload, and we want to use the `response` field.
-
----
-
-## Configure an enrichment workflow
-
-The [Bento documentation][enrichment] is really good!
-
-We need to set up:
-
-- a `branch` processor
-
-- a `request_map` to transform the city into an Ollama request
-
-- an `http` processor to submit the request to Ollama
-
-- a `result_map` to transform the Ollama response
-
----
-
-## Without the `branch` processor
-
-<pre class="mermaid">
-flowchart LR
-
-  CITY["
-    city: Paris
-    country: France
-    population: 1106000
-    iso2: FR
-    ...
-    "]
-
-  REQ["
-    model: qwen2:1.5b
-    stream: false
-    prompt: Who is the mayor of Paris?
-    "]
-
-  REP["
-    response: Anne Hidalgo
-    eval_count: ...
-    prompt_eval_count: ...
-    (other ollama fields)
-    "]
-
-  CITY@{ shape: card}
-  REQ@{ shape: card}
-  REP@{ shape: card}
-
-  style CITY text-align: left
-  style REQ text-align: left
-  style REP text-align: left
-
-  mapping@{ shape: diam }
-  http["http processor"]@{ shape: diam }
-
-  CITY --> mapping --> REQ --> http --> REP
-</pre>
-
-- We transform the `city` into an Ollama request
-
-- The `http` processor submits the request to Ollama
-
-- The final output is the Ollama response
-
----
-
-## With the `branch` processor
-
-<pre class="mermaid">
-flowchart LR
-
-  CITY["
-    city: Paris
-    country: France
-    population: 1106000
-    iso2: FR
-    ...
-    "]
-
-  REQ["
-    model: qwen2:1.5b
-    stream: false
-    prompt: Who is the mayor of Paris?
-    "]
-
-  REP["
-    response: Anne Hidalgo
-    eval_count: ...
-    prompt_eval_count: ...
-    (other ollama fields)
-    "]
-
-  OUT["
-    city: Paris
-    country: France
-    population: 1106000
-    iso2: FR
-    ...
-    mayor: Anne Hidalgo
-    "]
-
-  CITY@{ shape: card}
-  REQ@{ shape: card}
-  REP@{ shape: card}
-  OUT@{ shape: card}
-
-  style CITY text-align: left
-  style REQ text-align: left
-  style REP text-align: left
-  style OUT text-align: left
-
-  branch@{ shape: diam }
-  request_map@{ shape: diam }
-  result_map@{ shape: diam }
-  http["http processor"]@{ shape: diam }
-
-  CITY --> branch
-  branch --> result_map
-  branch --> request_map
-  request_map --> REQ
-  REQ --> http
-  http --> REP
-  REP --> result_map
-  result_map --> OUT
-</pre>
-
-- The `branch` processor allows doing the processing "on the side"
-
-- `request_map` and `result_map` transform the message before/after processing
-
-- Then, the result is combined with the original message (the `city`)
-
----
-
-```yaml
-input:
-  csv:
-    paths: ["cities.csv"]
-pipeline:
-  processors:
-    - branch:
-        request_map: |
-          root.model = "qwen2:1.5b"
-          root.stream = false
-          root.prompt = (
-            "Who is the mayor of %s? ".format(this.city) +
-            "Just give the name by itself on a single line. " +
-            "If you don't know, don't say anything."
-            )
-        processors:
-          - http:
-              url: http://ollama:11434/api/generate
-              verb: POST
-        result_map: |
-          root.mayor = this.response
-```
-
----
-
-## Trying it out
-
-- Save the YAML on the previous page into a configuration file
-
-- Run Bento with that configuration file
-
-- What happens?
-
---
-
-🤔 We're seeing errors due to timeouts
-
-```
-ERRO HTTP request to 'http://ollama...' failed: http://ollama...:
-Post "http://ollama...": context deadline exceeded
-(Client.Timeout exceeded while awaiting headers)
-```
-
----
-
-## 🙋 Choose your own adventure
-
-How should we address errors?
-
-- Option 1: increase the timeout in the [http][bento-http] processor
-
-- Option 2: use a [retry][bento-retry] processor in the pipeline
-
-- Option 3: use a [reject_errored][bento-reject] output
-
----
-
-## 🏗️ Let's build something!
-
-- We want to process 1000 cities with our LLM
-
-  (guessing who the mayor is, or something similar)
-
-- Store the output wherever we want
-
-  (Redis, CSV file, JSONL files...)
-
-- Deal correctly with errors
-
-  (we'll check that there are, indeed, 1000 cities in the output)
-
-- Scale out to process faster
-
-  (scale ollama to e.g. 10 replicas, enable parallelism in Bento)
-
----
-
-class: title
-
-🍱 Lunch time! 🍱
-
----
-
-## What happened?
-
-- If your Ollama pods have *resource requests*:
-
-  → your cluster may have auto-scaled
-
-- If your Ollama pods don't have *resource requests*:
-
-  → you probably have a bunch of container restarts, due to out-of-memory errors
-
-🤔 What's that about?
-
-[bento-http]: https://warpstreamlabs.github.io/bento/docs/components/processors/http/
-[bento-inputs]: https://warpstreamlabs.github.io/bento/docs/components/inputs/about/
-[bento-reject]: https://warpstreamlabs.github.io/bento/docs/components/outputs/reject_errored
-[bento-retry]: https://warpstreamlabs.github.io/bento/docs/components/processors/retry
-[bento-switch]: https://warpstreamlabs.github.io/bento/docs/components/processors/switch/
-[enrichment]: https://warpstreamlabs.github.io/bento/cookbooks/enrichments/
-[output-http-server]: https://warpstreamlabs.github.io/bento/docs/components/outputs/http_server
-[redpanda-acquires-benthos]: https://www.redpanda.com/press/redpanda-acquires-benthos
-[warpstream-forks-benthos]: https://www.warpstream.com/blog/announcing-bento-the-open-source-fork-of-the-project-formerly-known-as-benthos
-

slides/k8s/bento-rmq.md

@@ -1,250 +0,0 @@
-# Bento & RabbitMQ
-
-- In some of the previous runs, messages were dropped
-
-  (we start with 1000 messages in `cities` and have e.g. 955 in `mayors`)
-
-- This is caused by various errors during processing
-
-  (e.g. too many timeouts; Bento being shutdown halfway through...)
-
-- ...And by the fact that we are using a Redis queue
-
-  (which doesn't offer delivery guarantees or acknowledgements)
-
-- Can we get something better?
-
----
-
-## The problem
-
-- Some inputs (like `redis_list`) don't support *acknowledgements*
-
-- When a message is pulled from the queue, it is deleted immediately
-
-- If the message is lost for any reason, it is lost permanently
-
----
-
-## The solution
-
-- Some inputs (like `amqp_0_9`) support acknowledgements
-
-- When a message is pulled from the queue:
-
-  - it is not visible anymore to other consumers
-
-  - it needs to be explicitly acknowledged
-
-- The acknowledgement is done by Bento when the message reaches the output
-
-- The acknowledgement deletes the message
-
-- No acknowledgement after a while? Consumer crashes/disconnects?
-
-  Message gets requeued automatically!
-
----
-
-## `amqp_0_9`
-
-- Protocol used by RabbitMQ
-
-- Very simplified behavior:
-
-  - messages are published to an [*exchange*][amqp-exchanges]
-
-  - messages have a *routing key*
-
-  - the exchange routes the message to one (or zero or more) queues
-    </br>(possibly using the routing key or message headers to decide which queue(s))
-
-  - [*consumers*][amqp-consumers] subscribe to queues to receive messages
-
-[amqp-exchanges]: https://www.rabbitmq.com/tutorials/amqp-concepts#exchanges
-[amqp-consumers]: https://www.rabbitmq.com/tutorials/amqp-concepts#consumers
-
----
-
-## Using the default exchange
-
-- There is a default exchange (called `""` - empty string)
-
-- The routing key indicates the name of the queue to deliver to
-
-- The queue needs to exist (we need to create it beforehand)
-
----
-
-class: extra-details
-
-## Defining custom exchanges
-
-- Create an exchange
-
-  - exchange types: direct, fanout, topic, headers
-
-  - durability: persisted to disk to survive server restart or not?
-
-- Create a binding
-
-  - which exchange?
-
-  - which routing key? (for direct exchanges)
-
-  - which queue?
-
----
-
-## RabbitMQ on Kubernetes
-
-- RabbitMQ can be deployed on Kubernetes:
-
-  - directly (creating e.g. a StatefulSet)
-
-  - with the RabbitMQ operator
-
-- We're going to do the latter!
-
-- The operator includes the "topology operator"
-
-  (to configure queues, exchanges, and bindings through custom resources)
-
----
-
-## Installing the RabbitMQ operator
-
-- Let's install it with this Helm chart:
-
-  ```bash
-  helm upgrade --install --repo https://charts.bitnami.com/bitnami \
-      --namespace rabbitmq-system --create-namespace \
-      rabbitmq-cluster-operator rabbitmq-cluster-operator
-  ```
-
----
-
-## Deploying a simple RabbitMQ cluster
-
-- Let's use the YAML manifests in that directory:
-
-  https://github.com/jpetazzo/beyond-load-balancers/tree/main/rabbitmq
-
-- This creates:
-
-  - a `RabbitmqCluster` called `mq`
-
-  - a `Secret` called `mq-default-user` containing access credentials
-
-  - a durable `Queue` named `q1` 
-
-(We can ignore the `Exchange` and the `Binding`, we won't use them.)
-
----
-
-## 🏗️ Let's build something!
-
-Let's replace the `cities` Redis list with our RabbitMQ queue.
-
-(See next slide for steps and hints!)
-
----
-
-## Steps
-
-1. Edit the Bento configuration for our "CSV importer".
-
-   (replace the `redis_list` output with `amqp_0_9`)
-
-2. Run that pipeline and confirm that messages show up in RabbitMQ.
-
-3. Edit the Bento configuration for the Ollama consumer.
-
-   (replace the `redis_list` input with `amqp_0_9`)
-
-4. Trigger a scale up of the Ollama consumer.
-
-5. Update the KEDA Scaler to use RabbitMQ instead of Redis.
-
----
-
-## 1️⃣ Sending messages to RabbitMQ
-
-- Edit our Bento configuration (the one feeding the CSV file to Redis)
-
-- We want the following `output` section:
-  ```yaml
-    output:
-      amqp_0_9:
-        exchange: ""
-        key: q1
-        mandatory: true
-        urls:
-         - "${AMQP_URL}"
-  ```
-
-- Then export the AMQP_URL environment variable using `connection_string` from Secret `mq-default-user`
-
-💡 Yes, we can directly use environment variables in Bento configuration!
-
----
-
-## 2️⃣ Testing our AMQP output
-
-- Run the Bento pipeline
-
-- To check that our messages made it:
-  ```bash
-  kubectl exec mq-server-0 -- rabbitmqctl list_queues
-  ```
-
-- We can also use Prometheus metrics, e.g. `rabbitmq_queue_messages`
-
----
-
-## 3️⃣ Receiving messages from RabbitMQ
-
-- Edit our other Bento configuration (the one in the Ollama consumer Pod)
-
-- We want the following `input` section:
-  ```yaml
-    input:
-      amqp_0_9:
-        urls:
-          - `amqp://...:5672/`
-        queue: q1
-  ```
-
----
-
-## 4️⃣ Triggering Ollama scale up
-
-- If the autoscaler is configured to scale to zero, disable it
-
-  (easiest solution: delete the ScaledObject)
-
-- Then manually scale the Deployment to e.g. 4 Pods
-
-- Check that messages are processed and show up in the output
- 
-  (it should still be a Redis list at this point)
-
----
-
-## 5️⃣ Autoscaling on RabbitMQ
-
-- We need to update our ScaledObject
-
-- Check the [RabbitMQ Queue Scaler][keda-rabbitmq]
-
-- Multiple ways to pass the AMQP URL:
-
-  - hardcode it (easier solution for testing!)
-
-  - use `...fromEnv` and set environment variables in target pod
-
-  - create and use a TriggerAuthentication
-
-💡 Since we have the AMQP URL in a Secret, TriggerAuthentication works great!
-
-[keda-rabbitmq]: https://keda.sh/docs/latest/scalers/rabbitmq-queue/

slides/k8s/cainjector.md

@@ -55,7 +55,6 @@
 
   `cert-manager.io/allow-direct-injection: "true"`
 
-- See [cert-manager documentation] for details
-
-[cert-manager documentation]: https://cert-manager.io/docs/concepts/ca-injector/
+- See [cert-manager documentation][docs] for details
 
+[docs]: https://cert-manager.io/docs/concepts/ca-injector/

slides/k8s/cluster-autoscaler.md

@@ -272,9 +272,9 @@ This can be overridden by setting the annotation:
 
 - Can express `minAvailable` or `maxUnavailable`
 
-- See [documentation][doc-pdb] for details and examples
+- See [documentation] for details and examples
 
-[doc-pdb]: https://kubernetes.io/docs/tasks/run-application/configure-pdb/
+[documentation]: https://kubernetes.io/docs/tasks/run-application/configure-pdb/
 
 ---
 

slides/k8s/cluster-upgrade.md

@@ -81,7 +81,7 @@
 
 ## What version are we running anyway?
 
-- When I say, "I'm running Kubernetes 1.28", is that the version of:
+- When I say, "I'm running Kubernetes 1.22", is that the version of:
 
   - kubectl
 
@@ -129,15 +129,15 @@
 
 ## Kubernetes uses semantic versioning
 
-- Kubernetes versions look like MAJOR.MINOR.PATCH; e.g. in 1.28.9:
+- Kubernetes versions look like MAJOR.MINOR.PATCH; e.g. in 1.22.17:
 
   - MAJOR = 1
-  - MINOR = 28
-  - PATCH = 9
+  - MINOR = 22
+  - PATCH = 17
 
 - It's always possible to mix and match different PATCH releases
 
-  (e.g. 1.28.9 and 1.28.13 are compatible)
+  (e.g. 1.22.17 and 1.22.5 are compatible)
 
 - It is recommended to run the latest PATCH release
 
@@ -153,9 +153,9 @@
 
 - All components support a difference of one¹ MINOR version
 
-- This allows live upgrades (since we can mix e.g. 1.28 and 1.29)
+- This allows live upgrades (since we can mix e.g. 1.22 and 1.23)
 
-- It also means that going from 1.28 to 1.30 requires going through 1.29
+- It also means that going from 1.22 to 1.24 requires going through 1.23
 
 .footnote[¹Except kubelet, which can be up to two MINOR behind API server,
 and kubectl, which can be one MINOR ahead or behind API server.]
@@ -254,7 +254,7 @@ and kubectl, which can be one MINOR ahead or behind API server.]
   sudo vim /etc/kubernetes/manifests/kube-apiserver.yaml
   ```
 
-- Look for the `image:` line, and update it to e.g. `v1.30.1`
+- Look for the `image:` line, and update it to e.g. `v1.24.1`
 
 ]
 
@@ -320,29 +320,53 @@ Note 2: kubeadm itself is still version 1.22.1..
 
 - First things first: we need to upgrade kubeadm
 
-- The Kubernetes package repositories are now split by minor versions
+.lab[
 
-  (i.e. there is one repository for 1.28, another for 1.29, etc.)
+- Upgrade kubeadm:
+  ```
+  sudo apt install kubeadm=1.27.0-00
+  ```
 
-- This avoids accidentally upgrading from one minor version to another
+- Check what kubeadm tells us:
+  ```
+  sudo kubeadm upgrade plan
+  ```
 
-  (e.g. with unattended upgrades or if packages haven't been held/pinned)
+]
 
-- We'll need to add the new package repository and unpin packages!
+Problem: kubeadm doesn't know know how to handle
+upgrades from version 1.22.
+
+This is because we installed version 1.27.
+
+We need to install kubeadm version 1.23.X.
 
 ---
 
-## Installing the new packages
+## Downgrading kubeadm
 
-- Edit `/etc/apt/sources.list.d/kubernetes.list`
+- We need to go back to kubeadm version 1.23.X.
 
-  (or copy it to e.g. `kubernetes-1.29.list` and edit that)
+.lab[
 
-- `apt-get update`
+- View available versions for package `kubeadm`:
+  ```bash
+  apt show kubeadm -a | grep ^Version | grep 1.23
+  ```
 
-- Now edit (or remove) `/etc/apt/preferences.d/kubernetes`
+- Downgrade kubeadm:
+  ```
+  sudo apt install kubeadm=1.23.0-00
+  ```
 
-- `apt-get install kubeadm` should now upgrade `kubeadm` correctly! 🎉
+- Check what kubeadm tells us:
+  ```
+  sudo kubeadm upgrade plan
+  ```
+
+]
+
+kubeadm should now agree to upgrade to 1.23.X.
 
 ---
 
@@ -361,7 +385,7 @@ Note 2: kubeadm itself is still version 1.22.1..
 
 - Look for the `image:` line, and restore it to the original value
 
-  (e.g. `v1.28.9`)
+  (e.g. `v1.22.17`)
 
 - Wait for the control plane to come back up
 
@@ -375,14 +399,9 @@ Note 2: kubeadm itself is still version 1.22.1..
 
 .lab[
 
-- Check the upgrade plan:
-  ```bash
-  sudo kubeadm upgrade plan
-  ```
-
 - Perform the upgrade:
   ```bash
-  sudo kubeadm upgrade apply v1.29.0
+  sudo kubeadm upgrade apply v1.23.0
   ```
 
 ]
@@ -399,9 +418,15 @@ Note 2: kubeadm itself is still version 1.22.1..
 
 - Log into node `oldversion2`
 
-- Update package lists and APT pins like we did before
+- View available versions for package `kubelet`:
+  ```bash
+  apt show kubelet -a | grep ^Version
+  ```
 
-- Then upgrade kubelet
+- Upgrade kubelet:
+  ```bash
+  sudo apt install kubelet=1.23.0-00
+  ```
 
 ]
 
@@ -454,16 +479,13 @@ Note 2: kubeadm itself is still version 1.22.1..
 
 .lab[
 
-- Execute the whole upgrade procedure on each node:
+- Download the configuration on each node, and upgrade kubelet:
   ```bash
     for N in 1 2 3; do
       ssh oldversion$N "
-        sudo sed -i s/1.28/1.29/ /etc/apt/sources.list.d/kubernetes.list &&
-        sudo rm /etc/apt/preferences.d/kubernetes &&
-        sudo apt update &&
-        sudo apt install kubeadm -y &&
+        sudo apt install kubeadm=1.23.0-00 &&
         sudo kubeadm upgrade node &&
-        sudo apt install kubelet -y"
+        sudo apt install kubelet=1.23.0-00"
     done
   ```
 ]
@@ -472,7 +494,7 @@ Note 2: kubeadm itself is still version 1.22.1..
 
 ## Checking what we've done
 
-- All our nodes should now be updated to version 1.29
+- All our nodes should now be updated to version 1.23.0
 
 .lab[
 
@@ -565,35 +587,17 @@ Note 2: kubeadm itself is still version 1.22.1..
 
 ---
 
-## Database operators to the rescue
-
-- Moving stateful pods (e.g.: database server) can cause downtime
-
-- Database replication can help:
-
-  - if a node contains database servers, we make sure these servers aren't primaries
-
-  - if they are primaries, we execute a *switch over*
-
-- Some database operators (e.g. [CNPG]) will do that switch over automatically
-
-  (when they detect that a node has been *cordoned*)
-
-[CNPG]: https://cloudnative-pg.io/
-
----
-
 class: extra-details
 
 ## Skipping versions
 
-- This example worked because we went from 1.28 to 1.29
+- This example worked because we went from 1.22 to 1.23
 
-- If you are upgrading from e.g. 1.26, you will have to go through 1.27 first
+- If you are upgrading from e.g. 1.21, you will have to go through 1.22 first
 
-- This means upgrading kubeadm to 1.27.X, then using it to upgrade the cluster
+- This means upgrading kubeadm to 1.22.X, then using it to upgrade the cluster
 
-- Then upgrading kubeadm to 1.28.X, etc.
+- Then upgrading kubeadm to 1.23.X, etc.
 
 - **Make sure to read the release notes before upgrading!**
 

slides/k8s/consul.md

@@ -225,4 +225,4 @@ consul agent -data-dir=/consul/data -client=0.0.0.0 -server -ui \
 :EN:- Scheduling pods together or separately
 :EN:- Example: deploying a Consul cluster
 :FR:- Lancer des pods ensemble ou séparément
-:FR:- Exemple : lancer un cluster Consul
+:FR:- Example : lancer un cluster Consul

slides/k8s/crd.md

@@ -24,32 +24,6 @@
 
 ---
 
-## A bit of history
-
-Things related to Custom Resource Definitions:
-
-- Kubernetes 1.??: `apiextensions.k8s.io/v1beta1` introduced
-
-- Kubernetes 1.16: `apiextensions.k8s.io/v1` introduced
-
-- Kubernetes 1.22: `apiextensions.k8s.io/v1beta1` [removed][changes-in-122]
-
-- Kubernetes 1.25: [CEL validation rules available in beta][crd-validation-rules-beta]
-
-- Kubernetes 1.28: [validation ratcheting][validation-ratcheting] in [alpha][feature-gates]
-
-- Kubernetes 1.29: [CEL validation rules available in GA][cel-validation-rules]
-
-- Kubernetes 1.30: [validation ratcheting][validation-ratcheting] in [beta][feature-gates]; enabled by default
-
-[crd-validation-rules-beta]: https://kubernetes.io/blog/2022/09/23/crd-validation-rules-beta/
-[cel-validation-rules]: https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation-rules
-[validation-ratcheting]: https://github.com/kubernetes/enhancements/tree/master/keps/sig-api-machinery/4008-crd-ratcheting
-[feature-gates]: https://kubernetes.io/docs/reference/command-line-tools-reference/feature-gates/#feature-gates-for-alpha-or-beta-features
-[changes-in-122]: https://kubernetes.io/blog/2021/07/14/upcoming-changes-in-kubernetes-1-22/
-
----
-
 ## First slice of pizza
 
 ```yaml
@@ -68,6 +42,8 @@ Things related to Custom Resource Definitions:
 
   (a few optional things become mandatory, see [this guide](https://kubernetes.io/docs/reference/using-api/deprecation-guide/#customresourcedefinition-v122) for details)
 
+- `apiextensions.k8s.io/v1beta1` is available since Kubernetes 1.16
+
 ---
 
 ## Second slice of pizza
@@ -120,9 +96,9 @@ The YAML below defines a resource using the CRD that we just created:
 kind: Pizza
 apiVersion: container.training/v1alpha1
 metadata:
-  name: hawaiian
+  name: napolitana
 spec:
-  toppings: [ cheese, ham, pineapple ]
+  toppings: [ mozzarella ]
 ```
 
 .lab[
@@ -138,7 +114,11 @@ spec:
 
 ## Type validation
 
-- Recent versions of Kubernetes will issue errors about unknown fields
+- Older versions of Kubernetes will accept our pizza definition as is
+
+- Newer versions, however, will issue warnings about unknown fields
+
+  (and if we use `--validate=false`, these fields will simply be dropped)
 
 - We need to improve our OpenAPI schema
 
@@ -146,28 +126,6 @@ spec:
 
 ---
 
-## Creating a bland pizza
-
-- Let's try to create a pizza anyway!
-
-.lab[
-
-- Only provide the most basic YAML manifest:
-  ```bash
-    kubectl create -f- <<EOF
-    kind: Pizza
-    apiVersion: container.training/v1alpha1
-    metadata:
-      name: hawaiian
-    EOF
-  ```
-
-]
-
-- That should work! (As long as we don't try to add pineapple😁)
-
----
-
 ## Third slice of pizza
 
 - Let's add a full OpenAPI v3 schema to our Pizza CRD
@@ -250,42 +208,24 @@ Note: we can update a CRD without having to re-create the corresponding resource
 
 ---
 
-## Validation woes
+## Better data validation
 
-- Let's check what happens if we try to update our pizzas
+- Let's change the data schema so that the sauce can only be `red` or `white`
+
+- This will be implemented by @@LINK[k8s/pizza-5.yaml]
 
 .lab[
 
-- Try to add a label:
+- Update the Pizza CRD:
   ```bash
-  kubectl label pizza --all deliciousness=9001
+  kubectl apply -f ~/container.training/k8s/pizza-5.yaml
   ```
 
 ]
 
---
-
-- It works for the pizzas that have `sauce` and `toppings`, but not the other one!
-
-- The other one doesn't pass validation, and *can't be modified*
-
 ---
 
-## First, let's fix this!
-
-- Option 1: delete the pizza
-
-  *(deletion isn't subject to validation)*
-
-- Option 2: update the pizza to add `sauce` and `toppings`
-
-  *(writing a pizza that passes validation is fine)*
-
-- Option 3: relax the validation rules
-
----
-
-## Next, explain what's happening
+## Validation *a posteriori*
 
 - Some of the pizzas that we defined earlier *do not* pass validation
 
@@ -341,8 +281,6 @@ Note: we can update a CRD without having to re-create the corresponding resource
 
 ---
 
-class: extra-details
-
 ## Migrating database content
 
 - We need to *serve* a version as long as we *store* objects in that version
@@ -357,58 +295,6 @@ class: extra-details
 
 ---
 
-## Validation ratcheting
-
-- Good news: it's not always necessary to introduce new versions
-
-  (and to write the associated conversion webhooks)
-
-- *Validation ratcheting allows updates to custom resources that fail validation to succeed if the validation errors were on unchanged keypaths*
-
-- In other words: allow changes that don't introduce further validation errors
-
-- This was introduced in Kubernetes 1.28 (alpha), enabled by default in 1.30 (beta)
-
-- The rules are actually a bit more complex
-
-- Another (maybe more accurate) explanation: allow to tighten or loosen some field definitions
-
----
-
-## Validation ratcheting example
-
-- Let's change the data schema so that the sauce can only be `red` or `white`
-
-- This will be implemented by @@LINK[k8s/pizza-5.yaml]
-
-.lab[
-
-- Update the Pizza CRD:
-  ```bash
-  kubectl apply -f ~/container.training/k8s/pizza-5.yaml
-  ```
-
-]
-
----
-
-## Testing validation ratcheting
-
-- This should work with Kubernetes 1.30 and above
-
-  (but give an error for the `brownie` pizza with previous versions of K8S)
-
-.lab[
-
-- Add another label:
-  ```bash
-  kubectl label pizzas --all food=definitely
-  ```
-
-]
-
----
-
 ## Even better data validation
 
 - If we need more complex data validation, we can use a validating webhook

slides/k8s/disruptions.md

@@ -46,11 +46,11 @@ In the real world...
 
 - In Kubernetes, a "disruption" is something that stops the execution of a Pod
 
-- There are **voluntary** and **involuntary** disruptions
+- There are **voluntary** and **unvoluntary** disruptions
 
   - voluntary = directly initiated by humans (including by mistake!)
 
-  - involuntary = everything else
+  - unvoluntary = everything else
 
 - In this section, we're going to see what they are and how to prevent them
 
@@ -64,7 +64,7 @@ In the real world...
 
   (includes kernel bugs, issues affecting underlying hypervisors or infrastructure...)
 
-- **Involuntary** disruption (even if it results from human error!)
+- **Unvoluntary** disruption (even if it results from human error!)
 
 - Consequence: all workloads on that node become unresponsive
 
@@ -116,7 +116,7 @@ In the real world...
 
   (because a pod is using too much memory and no limit was set)
 
-- **Involuntary** disruption
+- **Unvoluntary** disruption
 
 - Consequence: kubelet starts to *evict* some pods
 
@@ -507,7 +507,7 @@ spec:
 
 ???
 
-:EN:- Voluntary and involuntary disruptions
+:EN:- Voluntary and unvoluntary disruptions
 :EN:- Pod Disruption Budgets
 :FR:- "Disruptions" volontaires et involontaires
 :FR:- Pod Disruption Budgets

slides/k8s/dmuc-hard.md

@@ -368,30 +368,6 @@ class: extra-details
 
 [ciliumwithoutkubeproxy]: https://docs.cilium.io/en/stable/network/kubernetes/kubeproxy-free/#kubeproxy-free
 
----
-
-class: extra-details
-
-## About the API server certificate...
-
-- In the previous sections, we've skipped API server certificate verification
-
-- To generate a proper certificate, we need to include a `subjectAltName` extension
-
-- And make sure that the CA includes the extension in the certificate
-
-```bash
-openssl genrsa -out apiserver.key 4096
-
-openssl req -new -key apiserver.key -subj /CN=kubernetes/ \
-        -addext "subjectAltName = DNS:kubernetes.default.svc, \
-        DNS:kubernetes.default, DNS:kubernetes, \
-        DNS:localhost, DNS:polykube1" -out apiserver.csr
-
-openssl x509 -req -in apiserver.csr -CAkey ca.key -CA ca.cert \
-        -out apiserver.crt -copy_extensions copy
-```
-
 ???
 
 :EN:- Connecting nodes and pods

slides/k8s/flux.md

@@ -1,551 +0,0 @@
-# FluxCD
-
-- We're going to implement a basic GitOps workflow with Flux
-
-- Pushing to `main` will automatically deploy to the clusters
-
-- There will be two clusters (`dev` and `prod`)
-
-- The two clusters will have similar (but slightly different) workloads
-
----
-
-## Repository structure
-
-This is (approximately) what we're going to do:
-
-```
-@@INCLUDE[slides/k8s/gitopstree.txt]
-```
-
----
-
-## Resource graph
-
-<pre class="mermaid">
-flowchart TD
-H/D["charts/dockercoins<br/>(Helm chart)"]
-H/C["charts/color<br/>(Helm chart)"]
-
-A/D["apps/dockercoins/flux.yaml<br/>(HelmRelease)"]
-A/B["apps/blue/flux.yaml<br/>(HelmRelease)"]
-A/G["apps/green/flux.yaml<br/>(HelmRelease)"]
-A/CM["apps/cert-manager/flux.yaml<br/>(HelmRelease)"]
-A/P["apps/kube-prometheus-stack/flux.yaml<br/>(HelmRelease + Kustomization)"]
-A/T["traefik/flux.yaml<br/>(HelmRelease)"]
-
-C/D["clusters/dev/kustomization.yaml<br/>(Kustomization)"]
-C/P["clusters/prod/kustomization.yaml<br/>(Kustomization)"]
-
-C/D --> A/B
-C/D --> A/D
-C/D --> A/G
-
-C/P --> A/D
-C/P --> A/G
-C/P --> A/T
-C/P --> A/CM
-C/P --> A/P
-
-A/D --> H/D
-A/B --> H/C
-A/G --> H/C
-A/P --> CHARTS & PV["apps/kube-prometheus-stack/manifests/configmap.yaml<br/>(Helm values)"]
-A/CM --> CHARTS
-A/T --> CHARTS
-
-CHARTS["Charts on external repos"]
-</pre>
-
----
-
-## Getting ready
-
-- Let's make sure we have two clusters
-
-- It's OK to use local clusters (kind, minikube...)
-
-- We might run into resource limits, though
-
-  (pay attention to `Pending` pods!)
-
-- We need to install the Flux CLI ([packages], [binaries])
-
-- **Highly recommended:** set up CLI completion!
-
-- Of course we'll need a Git service, too
-
-  (we're going to use GitHub here)
-
-[packages]: https://fluxcd.io/flux/get-started/
-[binaries]: https://github.com/fluxcd/flux2/releases
-
----
-
-## GitHub setup
-
-- Generate a GitHub token:
-
-  https://github.com/settings/tokens/new
-
-- Give it "repo" access
-
-- This token will be used by the `flux bootstrap github` command later
-
-- It will create a repository and configure it (SSH key...)
-
-- The token can be revoked afterwards
-
----
-
-## Flux bootstrap
-
-.lab[
-
-- Let's set a few variables for convenience, and create our repository:
-  ```bash
-    export GITHUB_TOKEN=...
-    export GITHUB_USER=changeme
-    export GITHUB_REPO=alsochangeme
-    export FLUX_CLUSTER=dev
-
-    flux bootstrap github \
-      --owner=$GITHUB_USER \
-      --repository=$GITHUB_REPO \
-      --branch=main \
-      --path=./clusters/$FLUX_CLUSTER \
-      --personal --private=false
-  ```
-
-]
-
-Problems? check next slide!
-
----
-
-## What could go wrong?
-
-- `flux bootstrap` will create or update the repository on GitHub
-
-- Then it will install Flux controllers to our cluster
-
-- Then it waits for these controllers to be up and running and ready
-
-- Check pod status in `flux-system`
-
-- If pods are `Pending`, check that you have enough resources on your cluster
-
-- For testing purposes, it should be fine to lower or remove Flux `requests`!
-
-  (but don't do that in production!)
-
-- If anything goes wrong, don't worry, we can just re-run the bootstrap
-
----
-
-class: extra-details
-
-## Idempotence
-
-- It's OK to run that same `flux bootstrap` command multiple times!
-
-- If the repository already exists, it will re-use it
-
-  (it won't destroy or empty it)
-
-- If the path `./clusters/$FLUX_CLUSTER` already exists, it will update it
-
-- It's totally fine to re-run `flux bootstrap` if something fails
-
-- It's totally fine to run it multiple times on different clusters
-
-- Or even to run it multiple times for the *same* cluster
-
-  (to reinstall Flux on that cluster after a cluster wipe / reinstall)
-
----
-
-## What do we get?
-
-- Let's look at what `flux bootstrap` installed on the cluster
-
-.lab[
-
-- Look inside the `flux-system` namespace:
-  ```bash
-  kubectl get all --namespace flux-system
-  ```
-
-- Look at `kustomizations` custom resources:
-  ```bash
-  kubectl get kustomizations --all-namespaces
-  ```
-
-- See what the `flux` CLI tells us:
-  ```bash
-  flux get all
-  ```
-
-]
-
----
-
-## Deploying with GitOps
-
-- We'll need to add/edit files on the repository
-
-- We can do it by using `git clone`, local edits, `git commit`, `git push`
-
-- Or by editing online on the GitHub website
-
-.lab[
-
-- Create a manifest; for instance `clusters/dev/flux-system/blue.yaml`
-
-- Add that manifest to `clusters/dev/kustomization.yaml`
-
-- Commit and push both changes to the repository
-
-]
-
----
-
-## Waiting for reconciliation
-
-- Compare the git hash that we pushed and the one shown with `kubectl get `
-
-- Option 1: wait for Flux to pick up the changes in the repository
-
-  (the default interval for git repositories is 1 minute, so that's fast)
-
-- Option 2: use `flux reconcile source git flux-system`
-
-  (this puts an annotation on the appropriate resource, triggering an immediate check)
-
-- Option 3: set up receiver webhooks
-
-  (so that git updates trigger immediate reconciliation)
-
----
-
-## Checking progress
-
-- `flux logs`
-
-- `kubectl get gitrepositories --all-namespaces`
-
-- `kubectl get kustomizations --all-namespaces`
-
----
-
-## Did it work?
-
---
-
-- No!
-
---
-
-- Why?
-
---
-
-- We need to indicate the namespace where the app should be deployed
-
-- Either in the YAML manifests
-
-- Or in the `kustomization` custom resource
-
-  (using field `spec.targetNamespace`)
-
-- Add the namespace to the manifest and try again!
-
----
-
-## Adding an app in a reusable way
-
-- Let's see a technique to add a whole app
-
-  (with multiple resource manifets)
-
-- We want to minimize code repetition
-
-  (i.e. easy to add on multiple clusters with minimal changes)
-
----
-
-## The plan
-
-- Add the app manifests in a directory
-
-  (e.g.: `apps/myappname/manifests`)
-
-- Create a kustomization manifest for the app and its namespace
-
-  (e.g.: `apps/myappname/flux.yaml`)
-
-- The kustomization manifest will refer to the app manifest
-
-- Add the kustomization manifest to the top-level `flux-system` kustomization
-
----
-
-## Creating the manifests
-
-- All commands below should be executed at the root of the repository
-
-.lab[
-
-- Put application manifests in their directory:
-  ```bash
-  mkdir -p apps/dockercoins/manifests
-  cp ~/container.training/k8s/dockercoins.yaml apps/dockercoins/manifests
-  ```
-
-- Create kustomization manifest:
-  ```bash
-    flux create kustomization dockercoins \
-      --source=GitRepository/flux-system \
-      --path=./apps/dockercoins/manifests/ \
-      --target-namespace=dockercoins \
-      --prune=true --export > apps/dockercoins/flux.yaml
-  ```
-
-]
-
----
-
-## Creating the target namespace
-
-- When deploying *helm releases*, it is possible to automatically create the namespace
-
-- When deploying *kustomizations*, we need to create it explicitly
-
-- Let's put the namespace with the kustomization manifest
-
-  (so that the whole app can be mediated through a single manifest)
-
-.lab[
-
-- Add the target namespace to the kustomization manifest:
-  ```bash
-    echo "---
-    kind: Namespace
-    apiVersion: v1
-    metadata:
-      name: dockercoins" >> apps/dockercoins/flux.yaml
-  ```
-
-]
-
----
-
-## Linking the kustomization manifest
-
-- Edit `clusters/dev/flux-system/kustomization.yaml`
-
-- Add a line to reference the kustomization manifest that we created:
-  ```yaml
-  - ../../../apps/dockercoins/flux.yaml
-  ```
-
-- `git add` our manifests, `git commit`, `git push`
-
-  (check with `git status` that we haven't forgotten anything!)
-
-- `flux reconcile` or wait for the changes to be picked up
-
----
-
-## Installing with Helm
-
-- We're going to see two different workflows:
-
-  - installing a third-party chart
-    <br/>
-    (e.g. something we found on the Artifact Hub)
-
-  - installing one of our own charts
-    <br/>
-    (e.g. a chart we authored ourselves)
-
-- The procedures are very similar
-
----
-
-## Installing from a public Helm repository
-
-- Let's install [kube-prometheus-stack][kps]
-
-.lab[
-
-- Create the Flux manifests:
-  ```bash
-  mkdir -p apps/kube-prometheus-stack
-  flux create source helm kube-prometheus-stack \
-       --url=https://prometheus-community.github.io/helm-charts \
-       --export >> apps/kube-prometheus-stack/flux.yaml
-  flux create helmrelease kube-prometheus-stack \
-       --source=HelmRepository/kube-prometheus-stack \
-       --chart=kube-prometheus-stack --release-name=kube-prometheus-stack \
-       --target-namespace=kube-prometheus-stack --create-target-namespace \
-       --export >> apps/kube-prometheus-stack/flux.yaml
-  ```
-
-]
-
-[kps]: https://artifacthub.io/packages/helm/prometheus-community/kube-prometheus-stack
-
----
-
-## Enable the app
-
-- Just like before, link the manifest from the top-level kustomization
-
-  (`flux-system` in namespace `flux-system`)
-
-- `git add` / `git commit` / `git push`
-
-- We should now have a Prometheus+Grafana observability stack!
-
----
-
-## Installing from a Helm chart in a git repo
-
-- In this example, the chart will be in the same repo
-
-- In the real world, it will typically be in a different repo!
-
-.lab[
-
-- Generate a basic Helm chart:
-  ```bash
-  mkdir -p charts
-  helm create charts/myapp
-  ```
-
-]
-
-(This generates a chart which installs NGINX. A lot of things can be customized, though.)
-
----
-
-## Creating the Flux manifests
-
-- The invocation is very similar to our first example
-
-.lab[
-
-- Generate the Flux manifest for the Helm release:
-  ```bash
-  mkdir apps/myapp
-  flux create helmrelease myapp \
-       --source=GitRepository/flux-system \
-       --chart=charts/myapp \
-       --target-namespace=myapp --create-target-namespace \
-       --export > apps/myapp/flux.yaml
-  ```
-
-- Add a reference to that manifest to the top-level kustomization
-
-- `git add` / `git commit` / `git push` the chart, manifest, and kustomization
-
-]
-
----
-
-## Passing values
-
-- We can also configure our Helm releases with values
-
-- Using an existing `myvalues.yaml` file:
-
-  `flux create helmrelease ... --values=myvalues.yaml`
-
-- Referencing an existing ConfigMap or Secret with a `values.yaml` key:
-
-  `flux create helmrelease ... --values-from=ConfigMap/myapp`
-
-- The ConfigMap or Secret must be in the same Namespace as the HelmRelease
-
-  (not the target namespace of that HelmRelease!)
-
----
-
-## Gotchas
-
-- When creating a HelmRelease using a chart stored in a git repository, you must:
-
-  - either bump the chart version (in `Chart.yaml`) after each change,
-
-  - or set `spec.chart.spec.reconcileStrategy` to `Revision`
-
-- Why?
-
-- Flux installs helm releases using packaged artifacts
-
-- Artifacts are updated only when the Helm chart version changes
-
-- Unless `reconcileStrategy` is set to `Revision` (instead of the default `ChartVersion`)
-
----
-
-## More gotchas
-
-- There is a bug in Flux that prevents using identical subcharts with aliases
-
-- See [fluxcd/flux2#2505][flux2505] for details
-
-[flux2505]: https://github.com/fluxcd/flux2/discussions/2505
-
----
-
-## Things that we didn't talk about...
-
-- Bucket sources
-
-- Image automation controller
-
-- Image reflector controller
-
-- And more!
-
-???
-
-:EN:- Implementing gitops with Flux
-:FR:- Workflow gitops avec Flux
-
-<!--
-
-helm upgrade --install --repo https://dl.gitea.io/charts --namespace gitea --create-namespace gitea gitea \
-  --set persistence.enabled=false \
-  --set redis-cluster.enabled=false \
-  --set postgresql-ha.enabled=false \
-  --set postgresql.enabled=true \
-  --set gitea.config.session.PROVIDER=db \
-  --set gitea.config.cache.ADAPTER=memory \
-  #
-
-### Boostrap Flux controllers
-
-```bash
-mkdir -p flux/flux-system/gotk-components.yaml
-flux install --export > flux/flux-system/gotk-components.yaml
-kubectl apply -f flux/flux-system/gotk-components.yaml
-```
-
-### Bootstrap GitRepository/Kustomization
-
-```bash
-export REPO_URL="<gitlab_url>" DEPLOY_USERNAME="<username>"
-read -s DEPLOY_TOKEN
-flux create secret git flux-system --url="${REPO_URL}" --username="${DEPLOY_USERNAME}" --password="${DEPLOY_TOKEN}"
-flux create source git flux-system --url=$REPO_URL --branch=main --secret-ref flux-system --ignore-paths='/*,!/flux' --export > flux/flux-system/gotk-sync.yaml
-flux create kustomization flux-system --source=GitRepository/flux-system --path="./flux" --prune=true --export >> flux/flux-system/gotk-sync.yaml
-
-git add flux/ && git commit -m 'feat: Setup Flux' flux/ && git push
-kubectl apply -f flux/flux-system/gotk-sync.yaml
-```
-
--->
-

slides/k8s/gitopstree.txt

@@ -1,13 +0,0 @@
-├── charts/                     <--- could also be in separate app repos
-│   ├── dockercoins/
-│   └── color/
-├── apps/                       <--- YAML manifests for GitOps resources
-│   ├── dockercoins/                 (might reference the "charts" above,
-│   ├── blue/                         and/or include environment-specific
-│   ├── green/                        manifests to create e.g. namespaces,
-│   ├── kube-prometheus-stack/        configmaps, secrets...)
-│   ├── cert-manager/
-│   └── traefik/
-└── clusters/                   <--- per-cluster; will typically reference
-    ├── prod/                        the "apps" above, possibly extending 
-    └── dev/                         or adding configuration resources too

slides/k8s/gitworkflows.md

@@ -1,4 +1,4 @@
-# Git-based workflows (GitOps)
+# Git-based workflows
 
 - Deploying with `kubectl` has downsides:
 
@@ -22,7 +22,7 @@
 
 - These resources have a perfect YAML representation
 
-- All we do is manipulate these YAML representations
+- All we do is manipulating these YAML representations
 
   (`kubectl run` generates a YAML file that gets applied)
 
@@ -34,232 +34,229 @@
 
   - control who can push to which branches
 
-  - have formal review processes, pull requests, test gates...
+  - have formal review processes, pull requests ...
 
 ---
 
 ## Enabling git-based workflows
 
-- There are a many tools out there to help us do that; with different approaches
+- There are a few tools out there to help us do that
 
-- "Git host centric" approach: GitHub Actions, GitLab...
+- We'll see demos of two of them: [Flux] and [Gitkube]
 
-  *the workflows/action are directly initiated by the git platform*
+- There are *many* other tools, some of them with even more features
 
-- "Kubernetes cluster centric" approach: [ArgoCD], [FluxCD]..
+- There are also *many* integrations with popular CI/CD systems
 
-  *controllers run on our clusters and trigger on repo updates*
+  (e.g.: GitLab, Jenkins, ...)
 
-- This is not an exhaustive list (see also: Jenkins)
-
-- We're going to talk mostly about "Kubernetes cluster centric" approaches here
-
-[ArgoCD]: https://argoproj.github.io/cd/
-[Flux]: https://fluxcd.io/
+[Flux]: https://www.weave.works/oss/flux/
+[Gitkube]: https://gitkube.sh/
 
 ---
 
-## The road to production
+## Flux overview
 
-In no specific order, we need to at least:
+- We put our Kubernetes resources as YAML files in a git repository
 
-- Choose a tool
+- Flux polls that repository regularly (every 5 minutes by default)
 
-- Choose a cluster / app / namespace layout
-  <br/>
-  (one cluster per app, different clusters for prod/staging...)
+- The resources described by the YAML files are created/updated automatically
 
-- Choose a repository layout
-  <br/>
-  (different repositories, directories, branches per app, env, cluster...)
-
-- Choose an installation / bootstrap method
-
-- Choose how new apps / environments / versions will be deployed
-
-- Choose how new images will be built
+- Changes are made by updating the code in the repository
 
 ---
 
-## Flux vs ArgoCD (1/2)
+## Preparing a repository for Flux
 
-- Flux:
+- We need a repository with Kubernetes YAML files
 
-  - fancy setup with an (optional) dedicated `flux bootstrap` command
-    <br/>
-    (with support for specific git providers, repo creation...)
+- I have one: https://github.com/jpetazzo/kubercoins
 
-  - deploying an app requires multiple CRDs
-    <br/>
-    (Kustomization, HelmRelease, GitRepository...)
+- Fork it to your GitHub account
 
-  - supports Helm charts, Kustomize, raw YAML
+- Create a new branch in your fork; e.g. `prod`
 
-- ArgoCD:
+  (e.g. with "branch" dropdown through the GitHub web UI)
 
-  - simple setup (just apply YAMLs / install Helm chart)
-
-  - fewer CRDs (basic workflow can be implement with a single "Application" resource)
-
-  - supports Helm charts, Jsonnet, Kustomize, raw YAML, and arbitrary plugins
+- This is the branch that we are going to use for deployment
 
 ---
 
-## Flux vs ArgoCD (2/2)
+## Setting up Flux with kustomize
 
-- Flux:
+- Clone the Flux repository:
+  ```bash
+  git clone https://github.com/fluxcd/flux
+  cd flux
+  ```
 
-  - sync interval is configurable per app
-  - no web UI out of the box
-  - CLI relies on Kubernetes API access
-  - CLI can easily generate custom resource manifests (with `--export`)
-  - self-hosted (flux controllers are managed by flux itself by default)
-  - one flux instance manages a single cluster
+- Edit `deploy/flux-deployment.yaml`
 
-- ArgoCD:
+- Change the `--git-url` and `--git-branch` parameters:
+  ```yaml
+  - --git-url=git@github.com:your-git-username/kubercoins
+  - --git-branch=prod
+  ```
 
-  - sync interval is configured globally
-  - comes with a web UI
-  - CLI can use Kubernetes API or separate API and authentication system
-  - one ArgoCD instance can manage multiple clusters
+- Apply all the YAML:
+  ```bash
+  kubectl apply -k deploy/
+  ```
 
 ---
 
-## Cluster, app, namespace layout
+## Setting up Flux with Helm
 
-- One cluster per app, different namespaces for environments?
+- Add Flux helm repo:
+  ```bash
+  helm repo add fluxcd https://charts.fluxcd.io
+  ```
 
-- One cluster per environment, different namespaces for apps?
-
-- Everything on a single cluster? One cluster per combination?
-
-- Something in between:
-
-  - prod cluster, database cluster, dev/staging/etc cluster
-
-  - prod+db cluster per app, shared dev/staging/etc cluster
-
-- And more!
-
-Note: this decision isn't really tied to GitOps!
+- Install Flux:
+  ```bash
+  kubectl create namespace flux
+  helm upgrade --install flux \
+    --set git.url=git@github.com:your-git-username/kubercoins \
+    --set git.branch=prod \
+    --namespace flux \
+    fluxcd/flux
+  ```
 
 ---
 
-## Repository layout
+## Allowing Flux to access the repository
 
-So many different possibilities!
+- When it starts, Flux generates an SSH key
 
-- Source repos
+- Display that key:
+  ```bash
+  kubectl -n flux logs deployment/flux | grep identity.pub | cut -d '"' -f2
+  ```
 
-- Cluster/infra repos/branches/directories
+- Then add that key to the repository, giving it **write** access
 
-- "Deployment" repos (with manifests, charts)
+  (some Flux features require write access)
 
-- Different repos/branches/directories for environments
-
-🤔 How to decide?
+- After a minute or so, DockerCoins will be deployed to the current namespace
 
 ---
 
-## Permissions
+## Making changes
 
-- Different teams/companies = different repos
+- Make changes (on the `prod` branch), e.g. change `replicas` in `worker`
 
-  - separate platform team → separate "infra" vs "apps" repos
-
-  - teams working on different apps → different repos per app
-
-- Branches can be "protected" (`production`, `main`...)
-
-  (don't need separate repos for separate environments)
-
-- Directories will typically have the same permissions
-
-- Managing directories is easier than branches
-
-- But branches are more "powerful" (cherrypicking, rebasing...)
+- After a few minutes, the changes will be picked up by Flux and applied
 
 ---
 
-## Resource hierarchy
+## Other features
 
-- Git-based deployments are managed by Kubernetes resources
+- Flux can keep a list of all the tags of all the images we're running
 
-  (e.g. Kustomization, HelmRelease with Flux; Application with ArgoCD)
+- The `fluxctl` tool can show us if we're running the latest images
 
-- We will call these resources "GitOps resources"
+- We can also "automate" a resource (i.e. automatically deploy new images)
 
-- These resources need to be managed like any other Kubernetes resource
-
-  (YAML manifests, Kustomizations, Helm charts)
-
-- They can be managed with Git workflows too!
+- And much more!
 
 ---
 
-## Cluster / infra management
+## Gitkube overview
 
-- How do we provision clusters?
+- We put our Kubernetes resources as YAML files in a git repository
 
-- Manual "one-shot" provisioning (CLI, web UI...)
+- Gitkube is a git server (or "git remote")
 
-- Automation with Terraform, Ansible...
+- After making changes to the repository, we push to Gitkube
 
-- Kubernetes-driven systems (Crossplane, CAPI)
-
-- Infrastructure can also be managed with GitOps
+- Gitkube applies the resources to the cluster
 
 ---
 
-## Example 1
+## Setting up Gitkube
 
-- Managed with YAML/Charts:
+- Install the CLI:
+  ```bash
+  sudo curl -L -o /usr/local/bin/gitkube \
+       https://github.com/hasura/gitkube/releases/download/v0.2.1/gitkube_linux_amd64
+  sudo chmod +x /usr/local/bin/gitkube
+  ```
 
-  - core components (CNI, CSI, Ingress, logging, monitoring...)
-
-  - GitOps controllers
-
-  - critical application foundations (database operator, databases)
-
-  - GitOps manifests
-
-- Managed with GitOps:
-
-  - applications
-
-  - staging databases
+- Install Gitkube on the cluster:
+  ```bash
+  gitkube install --expose ClusterIP
+  ```
 
 ---
 
-## Example 2
+## Creating a Remote
 
-- Managed with YAML/Charts:
+- Gitkube provides a new type of API resource: *Remote*
 
-  - essential components (CNI, CoreDNS)
+  (this is using a mechanism called Custom Resource Definitions or CRD)
 
-  - initial installation of GitOps controllers
+- Create and apply a YAML file containing the following manifest:
+  ```yaml
+	apiVersion: gitkube.sh/v1alpha1
+	kind: Remote
+	metadata:
+	  name: example
+	spec:
+	  authorizedKeys:
+	  - `ssh-rsa AAA...`
+	  manifests:
+	    path: "."
+  ```
 
-- Managed with GitOps:
-
-  - upgrades of GitOps controllers
-
-  - core components (CSI, Ingress, logging, monitoring...)
-
-  - operators, databases
-
-  - more GitOps manifests for applications!
+  (replace the `ssh-rsa AAA...` section with the content of `~/.ssh/id_rsa.pub`)
 
 ---
 
-## Concrete example
+## Pushing to our remote
 
-- Source code repository (not shown here)
+- Get the `gitkubed` IP address:
+  ```bash
+  kubectl -n kube-system get svc gitkubed
+  IP=$(kubectl -n kube-system get svc gitkubed -o json | 
+  	   jq -r .spec.clusterIP)
+  ```
 
-- Infrastructure repository (shown below), single branch
+- Get ourselves a sample repository with resource YAML files:
+  ```bash
+  git clone git://github.com/jpetazzo/kubercoins
+  cd kubercoins
+  ```
 
-```
-@@INCLUDE[slides/k8s/gitopstree.txt]
-```
+- Add the remote and push to it:
+  ```bash
+  git remote add k8s ssh://default-example@$IP/~/git/default-example
+  git push k8s master
+  ```
+
+---
+
+## Making changes
+
+- Edit a local file
+
+- Commit
+
+- Push!
+
+- Make sure that you push to the `k8s` remote
+
+---
+
+## Other features
+
+- Gitkube can also build container images for us
+
+  (see the [documentation](https://github.com/hasura/gitkube/blob/master/docs/remote.md) for more details)
+
+- Gitkube can also deploy Helm charts
+
+  (instead of raw YAML files)
 
 ???
 

slides/k8s/handson-mlops.md

@@ -1,132 +0,0 @@
-class: title
-
-*Tell me and I forget.*
-<br/>
-*Teach me and I remember.*
-<br/>
-*Involve me and I learn.*
-
-Misattributed to Benjamin Franklin
-
-[(Probably inspired by Chinese Confucian philosopher Xunzi)](https://www.barrypopik.com/index.php/new_york_city/entry/tell_me_and_i_forget_teach_me_and_i_may_remember_involve_me_and_i_will_lear/)
-
----
-
-## Hands-on sections
-
-- There will be *a lot* of examples and demos
-
-- If you are attending a live workshop:
-
-  - follow along with the demos, ask questions at any time
-
-  - if you can, try to run some of the examples and demos in your environment
-
-  - if things are going too fast, ask the trainer to slow down :)
-
-- If you are watching a recording or only reading the slides:
-
-  - it is **strongly** recommended to run **all** the examples and demos
-
-  - take advantage of the fact that you can pause at any time
-
----
-
-class: in-person
-
-## Where are we going to run our containers?
-
----
-
-class: in-person, pic
-
-![You get a cluster](images/you-get-a-cluster.jpg)
-
----
-
-## If you're attending a live training or workshop
-
-- Each person gets a private lab environment
-
-- Your lab environments will be available for the duration of the workshop
-
-  (check with your instructor to know exactly when they'll be shut down)
-
-- Note that for budget reasons¹, your environment will be fairly modest
-
-  - scenario 1: 4 nodes with 2 cores and 4 GB RAM ; no cluster autoscaling
-
-  - scenario 2: 1 node with 4 cores and 8 GB RAM ; cluster autoscaling
-
-.footnote[¹That cloud thing is mighty expensive, yo]
-
----
-
-## Running your own lab environment
-
-- If you are following a self-paced course...
-
-- Or watching a replay of a recorded course...
-
-- ...You will need to set up a local environment for the labs
-
-  *or*
-
-- If you want to use a specific cloud provider...
-
-- Or want to see these concepts "at scale"...
-
-- ...You can set up your own clusters with whatever capacity suits you
-
----
-
-## Deploying your own Kubernetes cluster
-
-- You need cloud provider credentials for this
-
-- Option 1: use the cloud provider CLI, web UI, ...
-
-- Option 2: use [one of these Terraform configurations][one-kubernetes]
-
-  (set `cluster_name`, `node_size`, `max_nodes_per_pool`, `location`, and GO!)
-
-[one-kubernetes]: https://github.com/jpetazzo/container.training/tree/main/prepare-labs/terraform/one-kubernetes
-
----
-
-## Deploying your own Kubernetes cluster.red[**s**]
-
-- If you want to deliver your own training or workshop:
-
-  - deployment scripts are available in the [prepare-labs] directory
-
-  - you can use them to automatically deploy many lab environments
-
-  - they support many different infrastructure providers
-
-  - they can deploy dozens (even hundreds) of clusters at a time
-
-[prepare-labs]: https://github.com/jpetazzo/container.training/tree/main/prepare-labs
-
----
-
-class: in-person
-
-## Why don't we run containers locally?
-
-- Installing this stuff can be hard on some machines
-
-  (32 bits CPU or OS... Laptops without administrator access... etc.)
-
-- *"The whole team downloaded all these container images from the WiFi!
-  <br/>... and it went great!"* (Literally no-one ever)
-
-- All you need is a computer (or even a phone or tablet!), with:
-
-  - an Internet connection
-
-  - a web browser
-
-  - an SSH client
-
-- Some of the demos require multiple nodes to demonstrate scaling

slides/k8s/healthchecks.md

@@ -158,6 +158,8 @@
 
 - Let's see the specific details for each of them!
 
+[grpc]: https://grpc.github.io/grpc/core/md_doc_health-checking.html
+
 ---
 
 ## `httpGet`
@@ -294,6 +296,8 @@ class: extra-details
 
 - Leverages standard [GRPC Health Checking Protocol][grpc]
 
+[grpc]: https://grpc.github.io/grpc/core/md_doc_health-checking.html
+
 ---
 
 ## Timing and thresholds
@@ -509,10 +513,7 @@ class: extra-details
 
 - Sometimes it can also make sense to embed a web server in the worker
 
-[grpc]: https://grpc.github.io/grpc/core/md_doc_health-checking.html
-
 ???
 
 :EN:- Using healthchecks to improve availability
 :FR:- Utiliser des *healthchecks* pour améliorer la disponibilité
-

slides/k8s/helm-intro.md

@@ -51,7 +51,7 @@
   - instructions indicating to users "please tweak this and that in the YAML"
 
 - That's where using something like
-  [CUE](https://github.com/cue-labs/cue-by-example/tree/main/003_kubernetes_tutorial),
+  [CUE](https://github.com/cuelang/cue/blob/v0.3.2/doc/tutorial/kubernetes/README.md),
   [Kustomize](https://kustomize.io/),
   or [Helm](https://helm.sh/) can help!
 
@@ -86,6 +86,8 @@
 
 - On April 30th 2020, Helm was the 10th project to *graduate* within the CNCF
 
+  🎉
+
   (alongside Containerd, Prometheus, and Kubernetes itself)
 
 - This is an acknowledgement by the CNCF for projects that
@@ -97,8 +99,6 @@
 - See [CNCF announcement](https://www.cncf.io/announcement/2020/04/30/cloud-native-computing-foundation-announces-helm-graduation/)
   and [Helm announcement](https://helm.sh/blog/celebrating-helms-cncf-graduation/)
 
-- In other words: Helm is here to stay
-
 ---
 
 ## Helm concepts
@@ -173,13 +173,11 @@ or `apt` tools).
 
 - Helm 3 doesn't use `tiller` at all, making it simpler (yay!)
 
-- If you see references to `tiller` in a tutorial, documentation... that doc is obsolete!
-
 ---
 
 class: extra-details
 
-## What was the problem with `tiller`?
+## With or without `tiller`
 
 - With Helm 3:
 
@@ -195,7 +193,9 @@ class: extra-details
 
 - This indirect model caused significant permissions headaches
 
-- It also made it more complicated to embed Helm in other tools
+  (`tiller` required very broad permissions to function)
+
+- `tiller` was removed in Helm 3 to simplify the security aspects
 
 ---
 
@@ -222,6 +222,59 @@ class: extra-details
 
 ---
 
+class: extra-details
+
+## Only if using Helm 2 ...
+
+- We need to install Tiller and give it some permissions
+
+- Tiller is composed of a *service* and a *deployment* in the `kube-system` namespace
+
+- They can be managed (installed, upgraded...) with the `helm` CLI
+
+.lab[
+
+- Deploy Tiller:
+  ```bash
+  helm init
+  ```
+
+]
+
+At the end of the install process, you will see:
+
+```
+Happy Helming!
+```
+
+---
+
+class: extra-details
+
+## Only if using Helm 2 ...
+
+- Tiller needs permissions to create Kubernetes resources
+
+- In a more realistic deployment, you might create per-user or per-team
+  service accounts, roles, and role bindings
+
+.lab[
+
+- Grant `cluster-admin` role to `kube-system:default` service account:
+  ```bash
+  kubectl create clusterrolebinding add-on-cluster-admin \
+      --clusterrole=cluster-admin --serviceaccount=kube-system:default
+  ```
+
+
+]
+
+(Defining the exact roles and permissions on your cluster requires
+a deeper knowledge of Kubernetes' RBAC model. The command above is
+fine for personal and development clusters.)
+
+---
+
 ## Charts and repositories
 
 - A *repository* (or repo in short) is a collection of charts
@@ -240,7 +293,27 @@ class: extra-details
 
 ---
 
-## How to find charts
+class: extra-details
+
+## How to find charts, the old way
+
+- Helm 2 came with one pre-configured repo, the "stable" repo
+
+  (located at https://charts.helm.sh/stable)
+
+- Helm 3 doesn't have any pre-configured repo
+
+- The "stable" repo mentioned above is now being deprecated
+
+- The new approach is to have fully decentralized repos
+
+- Repos can be indexed in the Artifact Hub
+
+  (which supersedes the Helm Hub)
+
+---
+
+## How to find charts, the new way
 
 - Go to the [Artifact Hub](https://artifacthub.io/packages/search?kind=0) (https://artifacthub.io)
 
@@ -336,6 +409,24 @@ Note: it is also possible to install directly a chart, with `--repo https://...`
 
 ---
 
+class: extra-details
+
+## Searching and installing with Helm 2
+
+- Helm 2 doesn't have support for the Helm Hub
+
+- The `helm search` command only takes a search string argument
+
+  (e.g. `helm search juice-shop`)
+
+- With Helm 2, the name is optional:
+
+  `helm install juice/juice-shop` will automatically generate a name
+
+  `helm install --name my-juice-shop juice/juice-shop` will specify a name
+
+---
+
 ## Viewing resources of a release
 
 - This specific chart labels all its resources with a `release` label
@@ -451,11 +542,11 @@ All unspecified values will take the default values defined in the chart.
 
 :EN:- Helm concepts
 :EN:- Installing software with Helm
-:EN:- Finding charts on the Artifact Hub
+:EN:- Helm 2, Helm 3, and the Helm Hub
 
 :FR:- Fonctionnement général de Helm
 :FR:- Installer des composants via Helm
-:FR:- Trouver des *charts* sur *Artifact Hub*
+:FR:- Helm 2, Helm 3, et le *Helm Hub*
 
 :T: Getting started with Helm and its concepts
 

slides/k8s/helmfile.md

@@ -1,166 +0,0 @@
-# Managing our stack with `helmfile`
-
-- We've installed a few things with Helm
-
-- And others with raw YAML manifests
-
-- Perhaps you've used Kustomize sometimes
-
-- How can we automate all this? Make it reproducible?
-
----
-
-## Requirements
-
-- We want something that is *idempotent*
-
-  = running it 1, 2, 3 times, should only install the stack once
-
-- We want something that handles udpates
-
-  = modifying / reconfiguring without restarting from scratch
-
-- We want something that is configurable
-
-  = with e.g. configuration files, environment variables...
-
-- We want something that can handle *partial removals*
-
-  = ability to remove one element without affecting the rest
-
-- Inspiration: Terraform, Docker Compose...
-
----
-
-## Shell scripts?
-
-✅ Idempotent, thanks to `kubectl apply -f`, `helm upgrade --install`
-
-✅ Handles updates (edit script, re-run)
-
-✅ Configurable
-
-❌ Partial removals
-
-If we remove an element from our script, it won't be uninstalled automatically.
-
----
-
-## Umbrella chart?
-
-Helm chart with dependencies on other charts.
-
-✅ Idempotent
-
-✅ Handles updates
-
-✅ Configurable (with Helm values: YAML files and `--set`)
-
-✅ Partial removals
-
-❌ Complex (requires to learn advanced Helm features)
-
-❌ Requires everything to be a Helm chart (adds (lots of) boilerplate)
-
----
-
-## Helmfile
-
-https://github.com/helmfile/helmfile
-
-✅ Idempotent
-
-✅ Handles updates
-
-✅ Configurable (with values files, environment variables, and more)
-
-✅ Partial removals
-
-✅ Fairly easy to get started
-
-🐙 Sometimes feels like summoning unspeakable powers / staring down the abyss
-
----
-
-## What `helmfile` can install
-
-- Helm charts from remote Helm repositories
-
-- Helm charts from remote git repositories
-
-- Helm charts from local directories
-
-- Kustomizations
-
-- Directories with raw YAML manifests
-
----
-
-## How `helmfile` works
-
-- Everything is defined in a main `helmfile.yaml`
-
-- That file defines:
-
-  - `repositories` (remote Helm repositories)
-
-  - `releases` (things to install: Charts, YAML...)
-
-  - `environments` (optional: to specialize prod vs staging vs ...)
-
-- Helm-style values file can be loaded in `enviroments`
-
-- These values can then be used in the rest of the Helmfile
-
-- Examples: [install essentials on a cluster][helmfile-ex-1], [run a Bento stack][helmfile-ex-2]
-
-[helmfile-ex-1]: https://github.com/jpetazzo/beyond-load-balancers/blob/main/helmfile.yaml
-[helmfile-ex-2]: https://github.com/jpetazzo/beyond-load-balancers/blob/main/bento/helmfile.yaml
-
----
-
-## `helmfile` commands
-
-- `helmfile init` (optional; downloads plugins if needed)
-
-- `helmfile apply` (updates all releases that have changed)
-
-- `helmfile sync` (updates all releases even if they haven't changed)
-
-- `helmfile destroy` (guess!)
-
----
-
-## Helmfile tips
-
-As seen in [this example](https://github.com/jpetazzo/beyond-load-balancers/blob/main/bento/helmfile.yaml#L21):
-
-- variables can be used to simplify the file
-
-- configuration values and secrets can be loaded from external sources
-
-  (Kubernetes Secrets, Vault... See [vals] for details)
-
-- current namespace isn't exposed by default
-
-- there's often more than one way to do it!
-
-  (this particular section could be improved by using Bento `${...}`)
-
-[vals]: https://github.com/helmfile/vals
-
-???
-
-## 🏗️ Let's build something!
-
-- Write a helmfile (or two) to set up today's entire stack on a brand new cluster!
-
-- Suggestion:
-
-  - one helmfile for singleton, cluster components
-    <br/>
-    (All our operators: Prometheus, Grafana, KEDA, CNPG, RabbitMQ Operator)
-
-  - one helmfile for the application stack
-    <br/>
-    (Bento, PostgreSQL cluster, RabbitMQ)

slides/k8s/hpa-v2-keda.md

@@ -0,0 +1,314 @@
+# Scaling with custom metrics
+
+- The HorizontalPodAutoscaler v1 can only scale on Pod CPU usage
+
+- Sometimes, we need to scale using other metrics:
+
+  - memory
+
+  - requests per second
+
+  - latency
+
+  - active sessions
+
+  - items in a work queue
+
+  - ...
+
+- The HorizontalPodAutoscaler v2 can do it!
+
+---
+
+## Requirements
+
+⚠️ Autoscaling on custom metrics is fairly complex!
+
+- We need some metrics system
+
+  (Prometheus is a popular option, but others are possible too)
+
+- We need our metrics (latency, traffic...) to be fed in the system
+
+  (with Prometheus, this might require a custom exporter)
+
+- We need to expose these metrics to Kubernetes
+
+  (Kubernetes doesn't "speak" the Prometheus API)
+
+- Then we can set up autoscaling!
+
+---
+
+## The plan
+
+- We will deploy the DockerCoins demo app
+
+  (one of its components has a bottleneck; its latency will increase under load)
+
+- We will use Prometheus to collect and store metrics
+
+- We will deploy a tiny HTTP latency monitor (a Prometheus *exporter*)
+
+- We will then use KEDA with a "Prometheus Scaler"
+
+---
+
+## Deploying DockerCoins
+
+- That's the easy part!
+
+.lab[
+
+- Create a new namespace and switch to it:
+  ```bash
+  kubectl create namespace customscaling
+  kns customscaling
+  ```
+
+- Deploy DockerCoins, and scale up the `worker` Deployment:
+  ```bash
+  kubectl apply -f ~/container.training/k8s/dockercoins.yaml
+  kubectl scale deployment worker --replicas=10
+  ```
+
+]
+
+---
+
+## Current state of affairs
+
+- The `rng` service is a bottleneck
+
+  (it cannot handle more than 10 requests/second)
+
+- With enough traffic, its latency increases
+
+  (by about 100ms per `worker` Pod after the 3rd worker)
+
+.lab[
+
+- Check the `webui` port and open it in your browser:
+  ```bash
+  kubectl get service webui
+  ```
+
+- Check the `rng` ClusterIP and test it with e.g. `httping`:
+  ```bash
+  kubectl get service rng
+  ```
+
+]
+
+---
+
+## Measuring latency
+
+- We will use a tiny custom Prometheus exporter, [httplat](https://github.com/jpetazzo/httplat)
+
+- `httplat` exposes Prometheus metrics on port 9080 (by default)
+
+- It monitors exactly one URL, that must be passed as a command-line argument
+
+.lab[
+
+- Deploy `httplat`:
+  ```bash
+  kubectl create deployment httplat --image=jpetazzo/httplat -- httplat http://rng/
+  ```
+
+- Expose it:
+  ```bash
+  kubectl expose deployment httplat --port=9080
+  ```
+
+]
+
+---
+
+class: extra-details
+
+## Measuring latency in the real world
+
+- We are using this tiny custom exporter for simplicity
+
+- A more common method to collect latency is to use a service mesh
+
+- A service mesh can usually collect latency for *all* services automatically
+
+---
+
+## Install Prometheus
+
+- We will use the Prometheus community Helm chart
+
+  (because we can configure it dynamically with annotations)
+
+.lab[
+
+- If it's not installed yet on the cluster, install Prometheus:
+  ```bash
+    helm upgrade --install prometheus prometheus \
+         --repo https://prometheus-community.github.io/helm-charts \
+         --namespace prometheus --create-namespace \
+         --set server.service.type=NodePort \
+         --set server.service.nodePort=30090 \
+         --set server.persistentVolume.enabled=false \
+         --set alertmanager.enabled=false
+  ```
+
+]
+
+---
+
+## Configure Prometheus
+
+- We can use annotations to tell Prometheus to collect the metrics
+
+.lab[
+
+- Tell Prometheus to "scrape" our latency exporter:
+  ```bash
+    kubectl annotate service httplat \
+            prometheus.io/scrape=true \
+            prometheus.io/port=9080 \
+            prometheus.io/path=/metrics
+  ```
+
+]
+
+If you deployed Prometheus differently, you might have to configure it manually.
+
+You'll need to instruct it to scrape http://httplat.customscaling.svc:9080/metrics.
+
+---
+
+## Make sure that metrics get collected
+
+- Before moving on, confirm that Prometheus has our metrics
+
+.lab[
+
+- Connect to Prometheus
+
+  (if you installed it like instructed above, it is exposed as a NodePort on port 30090)
+
+- Check that `httplat` metrics are available
+
+- You can try to graph the following PromQL expression:
+  ```
+  rate(httplat_latency_seconds_sum[2m])/rate(httplat_latency_seconds_count[2m])
+  ```
+
+]
+
+---
+
+## Troubleshooting
+
+- Make sure that the exporter works:
+
+  - get the ClusterIP of the exporter with `kubectl get svc httplat`
+
+  - `curl http://<ClusterIP>:9080/metrics`
+
+  - check that the result includes the `httplat` histogram
+
+- Make sure that Prometheus is scraping the exporter:
+
+  - go to `Status` / `Targets` in Prometheus
+
+  - make sure that `httplat` shows up in there
+
+---
+
+## Installing KEDA
+
+- Multiple possibilities, as explained in the [documentation](https://keda.sh/docs/2.12/deploy/)
+
+- For simplicity we can use the YAML version with admission webhooks
+
+---
+
+## Creating a "Scaler"
+
+- With KEDA, instead of creating an HPA policy directly, we create a "Scaled Object"
+
+- The "Scaled Object" will take care of:
+
+  - registering and exposing our custom metric in KEDA'a aggregation layer
+
+  - creating the HPA policy that consumes that metric
+
+- See the [Prometheus Scaler documentation](https://keda.sh/docs/2.12/scalers/prometheus/)
+
+---
+
+## Witness the marvel of custom autoscaling
+
+(Sort of)
+
+- After a short while, the `rng` Deployment will scale up
+
+- It should scale up until the latency drops below 100ms
+
+  (and continue to scale up a little bit more after that)
+
+- Then, since the latency will be well below 100ms, it will scale down
+
+- ... and back up again, etc.
+
+(See pictures on next slides!)
+
+---
+
+class: pic
+
+![Latency over time](images/hpa-v2-pa-latency.png)
+
+---
+
+class: pic
+
+![Number of pods over time](images/hpa-v2-pa-pods.png)
+
+---
+
+## What's going on?
+
+- The autoscaler's information is slightly out of date
+
+  (not by much; probably between 1 and 2 minute)
+
+- It's enough to cause the oscillations to happen
+
+- One possible fix is to tell the autoscaler to wait a bit after each action
+
+- It will reduce oscillations, but will also slow down its reaction time
+
+  (and therefore, how fast it reacts to a peak of traffic)
+
+---
+
+## What's going on? Take 2
+
+- As soon as the measured latency is *significantly* below our target (100ms) ...
+
+  the autoscaler tries to scale down
+
+- If the latency is measured at 20ms ...
+
+  the autoscaler will try to *divide the number of pods by five!*
+
+- One possible solution: apply a formula to the measured latency,
+  so that values between e.g. 10 and 100ms get very close to 100ms.
+
+- Another solution: instead of targetting for a specific latency,
+  target a 95th percentile latency or something similar, using
+  a more advanced PromQL expression (and leveraging the fact that
+  we have histograms instead of raw values).
+
+???
+
+:EN:- Autoscaling with custom metrics
+:FR:- Suivi de charge avancé (HPAv2)

slides/k8s/ingress-tls.md

@@ -96,7 +96,7 @@ class: extra-details
 
 ---
 
-## Choose your own adventure!
+## Choose your adventure!
 
 - We present 3 methods to obtain a certificate
 

slides/k8s/ingress.md

@@ -572,7 +572,7 @@ This is normal: we haven't provided any ingress rule yet.
 
 - Create a prefix match rule for the `blue` service:
   ```bash
-  kubectl create ingress bluestar --rule=/blue*=blue:80
+  kubectl create ingress bluestar --rule=/blue*:blue:80
   ```
 
 - Check that it works:

slides/k8s/kustomize.md

@@ -128,9 +128,7 @@ configMapGenerator:
 
 - A *variant* is the final outcome of applying bases + overlays
 
-(See the [kustomize glossary][glossary] for more definitions!)
-
-[glossary]: https://kubectl.docs.kubernetes.io/references/kustomize/glossary/
+(See the [kustomize glossary](https://github.com/kubernetes-sigs/kustomize/blob/master/docs/glossary.md) for more definitions!)
 
 ---
 
@@ -339,7 +337,7 @@ kustomize edit add label app.kubernetes.io/name:dockercoins
 
 - Assuming that `commonLabels` have been set as shown on the previous slide:
   ```bash
-    kubectl apply -k . --prune --selector app.kubernetes.io/name=dockercoins
+    kubectl apply -k . --prune --selector app.kubernetes.io.name=dockercoins
   ```
 
 - ... This command removes resources that have been removed from the kustomization

slides/k8s/kyverno.md

@@ -536,12 +536,12 @@ Note: the `apiVersion` field appears to be optional.
 - Excerpt:
   ```yaml
       generate: 
-        kind: LimitRange
-        name: default-limitrange
-        namespace: "{{request.object.metadata.name}}" 
-        data:
-          spec:
-            limits:
+      kind: LimitRange
+      name: default-limitrange
+      namespace: "{{request.object.metadata.name}}" 
+      data:
+        spec:
+          limits:
   ```
 
 - Note that we have to specify the `namespace`

slides/k8s/metrics-server.md

@@ -195,4 +195,4 @@ class: extra-details
 :EN:- Installing metrics-server
 
 :EN:- Le *resource metrics pipeline*
-:FR:- Installation de metrics-server
+:FR:- Installtion de metrics-server