Second batch for day 3

slides/3.yml

@@ -22,42 +22,54 @@ chapters:
    - k8s/on-desktop.md
    - k8s/namespaces.md
    - k8s/accessinternal.md
-  #- k8s/localkubeconfig.md
-  #- k8s/kubectlproxy.md
+   - k8s/localkubeconfig.md
+   - k8s/kubectlproxy.md
    - k8s/testing.md
 
 -
   - k8s/configuration.md
   - k8s/sealed-secrets.md
+  #- k8s/volumes.md
   - k8s/kustomize.md
   - k8s/helm.md
   - k8s/create-chart.md
+  #- k8s/create-more-charts.md
+
 
 -
   # - k8s/shippingimages.md  # some overlap
   - k8s/registries.md
   - k8s/stop-manual.md
   - k8s/ci-cd.md
-# -
-  #- k8s/volumes.md
-  #- k8s/create-more-charts.md
+  - k8s/exercise-ci-build.md
+  - k8s/kaniko.md
+  - k8s/exercise-ci-kaniko.md
+
 -
-  - |
-    # (Automatiser)
-  - |
-    # Fabrication d'image
-  - |
-    # Skaffold
-  - |
-    # Registries
-  - |
-    # Gitlab, CI
-  - |
-    # ROllout avancé, blue green, canary
--
-  - |
-    # Monitoring applicatif
-  - |
-    # Prometheus Grafana
-  - |
-    # Telemetry
+  - k8s/monitoring-intro.md
+  #- k8s/prometheus-intro.md
+  - k8s/prometheus-endpoint.md
+
+
+    #-
+    #  - k8s/rollout.md
+    #  - k8s/blue-green.md
+
+    #- |
+    #  # (Automatiser)
+    #- |
+    #  # Fabrication d'image
+    #- |
+    #  # Skaffold
+    #- |
+    #  # Registries
+    #- |
+    #  # Gitlab, CI
+    #- |
+    #  # ROllout avancé, blue green, canary
+    #- |
+    #  # Monitoring applicatif
+    #- |
+    #  # Prometheus Grafana
+    #- |
+    #  # Telemetry

slides/k8s/exercise-ci-build.md

@@ -0,0 +1,5 @@
+## Exercise - build in kubernetes
+
+Go to https://github.com/enix/kubecoin
+
+and follow the instructions to complete the exercise #1

slides/k8s/exercise-ci-kaniko.md

@@ -0,0 +1,3 @@
+## Exercice - build with kaniko
+
+Complete exercise #2, (again code at: https://github.com/enix/kubecoin )

slides/k8s/kaniko.md

@@ -0,0 +1,23 @@
+## Privileged container
+
+- Running privileged container could be really harmful for the node it run on.
+
+- Getting control of a node could expose other containers in the cluster and the cluster itself
+
+- It's even worse when it is docker that run in this privileged container
+
+- `docker build` doesn't allow to run privileged container for building layer
+
+- nothing forbid to run `docker run --privileged`
+
+---
+## Kaniko
+
+*kaniko doesn't depend on a Docker daemon and executes each command
+within a Dockerfile completely in userspace*
+
+- Kaniko is only a build system, there is no runtime like docker does
+
+- generates OCI compatible image, so could be run on Docker or other CRI
+
+- use a different cache system than Docker

slides/k8s/monitoring-intro.md

@@ -0,0 +1,6 @@
+# Monitoring
+
+We have shipped our application to kubernetes, now we need to tackle
+the last item of the development cycle:
+
+- monitoring

slides/k8s/prometheus-endpoint.md

@@ -0,0 +1,55 @@
+## Prometheus endpoint
+
+The goal here is to expose an HTTP endoint for prometheus. Sample response:
+
+.small[
+```
+ # HELP http_requests_total The total number of HTTP requests.
+ # TYPE http_requests_total counter
+ http_requests_total{method="post",code="200"} 1027 1395066363000
+ http_requests_total{method="post",code="400"}    3 1395066363000
+
+ # Minimalistic line:
+ metric_without_timestamp_and_labels 12.47
+```
+]
+
+
+To achieve this multiple strategies could be used:
+
+- developping in the application itself (especialy if it's already an httpserver)
+
+- using building blocks that may already expose such endpoint (puma, uwsgi)
+
+- Add sidecar exporter that leverage an already existing monitoring channel (ex: JMX)
+
+---
+## Developing prometheus endpoint
+
+- Using prometheus client libraries is often the easier
+
+- Offer multiple ways of integrations:
+
+    - from: I run already a web server, just add a monitoring route
+
+    - to: please run a full web server in a thread.
+
+Links (do you see a pattern ?):
+  - https://github.com/prometheus/client_python
+  - https://github.com/prometheus/client_ruby
+  - https://github.com/prometheus/client_golang
+
+
+---
+## Add sidecar Exporter
+
+- There is plenty of already existing "exporter":
+
+  - https://prometheus.io/docs/instrumenting/exporters/
+
+- Those are "translators" from one monitoring channel to another
+
+- Writing your own is not complicated (using previous client libraries)
+
+- Try to not expose monitoring channel more than needed. Often localhost is enough
+    (sidecars run in the same network namespace as other containers)