diff --git a/slides/k8s/ci-cd.md b/slides/k8s/ci-cd.md index b5ea21f3..d62a35e0 100644 --- a/slides/k8s/ci-cd.md +++ b/slides/k8s/ci-cd.md @@ -1,22 +1,25 @@ -## Jenkins/Jenkins-X +## Jenkins / Jenkins-X -- Multi purpose CI +- Multi-purpose CI - Self-hosted CI for kubernetes -- testing in namespace, feature branch +- Testing in namespace, feature branch + + .small[ ```shell -$ curl -L "https://github.com/jenkins-x/jx/releases/download/v2.0.1103/jx-darwin-amd64.tar.gz" | tar xzv "jx" -$ ./jx boot +curl -L "https://github.com/jenkins-x/jx/releases/download/v2.0.1103/jx-darwin-amd64.tar.gz" | tar xzv jx +./jx boot ``` ] --- -## Gitlab -- repository + registry + ci/cd integrated all-in-one +## GitLab + +- Repository + registry + CI/CD integrated all-in-one ```shell helm repo add gitlab https://charts.gitlab.io/ @@ -24,13 +27,14 @@ helm install gitlab gitlab/gitlab ``` --- -## Tekton/knative +## Tekton / knative - knative is serverless project from google -- Tekton leverage knative to run pipeline +- Tekton leverages knative to run pipelines --- + ## ArgoCD .small[ @@ -38,3 +42,8 @@ helm install gitlab gitlab/gitlab kubectl apply -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml ``` ] + + diff --git a/slides/k8s/exercise-ci-build.md b/slides/k8s/exercise-ci-build.md index 1f35d9a9..acdbad21 100644 --- a/slides/k8s/exercise-ci-build.md +++ b/slides/k8s/exercise-ci-build.md @@ -1,5 +1,5 @@ -## Exercise - build in kubernetes +## Exercise - building with Kubernetes -Go to https://github.com/enix/kubecoin +- Let's go to https://github.com/enix/kubecoin -and follow the instructions to complete the exercise #1 +- Our goal is to follow the instructions and complete exercise #1 diff --git a/slides/k8s/opentelemetry.md b/slides/k8s/opentelemetry.md index 4690d582..a6229efd 100644 --- a/slides/k8s/opentelemetry.md +++ b/slides/k8s/opentelemetry.md @@ -1,72 +1,84 @@ # OpenTelemetry -*OpenTelemetry* is a "tracing" framework. It's a fusion of two other frameworks: -*opentracing* and *opencensus*. +*OpenTelemetry* is a "tracing" framework. -The goal is to have deep integration with software languages and application framework to -enable deep dive tracing of different events accross different components +It's a fusion of two other frameworks: +*OpenTracing* and *OpenCensus*. + +Its goal is to provide deep integration with programming languages and +application frameworks to enabled deep dive tracing of different events accross different components. --- + ## Span ! span ! span ! -- A unit a tracing is called a `span`. +- A unit of tracing is called a *span* -- A span has a start time and and stop time and an ID. +- A span has: a start time, a stop time, and an ID -- It represent an action that took some time to complete +- It represents an action that took some time to complete - ex: call to function `B`, DB transation, REST call to a backend... + (e.g.: function call, database transaction, REST API call ...) -- A span could have a parent and could be parent of multiple child spans. +- A span can have a parent span, and can have multiple child spans - ex: during the call to function `B`, a sub call to `C` and `D` has been issued + (e.g.: when calling function `B`, sub-calls to `C` and `D` were issued) - Think of it as a "tree" of calls --- + ## Distributed tracing -- This could be applied to multiple components +- When two components interact, their spans can be connected together - ex: If microservice `A` send REST call to microservice `B` +- Example: microservice `A` sends a REST API call to microservice `B` - `A` will have a span for the call to `B` + - `B` will have a span for the call from `A` - (that normally starts shortly after, and finishes shortly before) - - the span of `A` will be the parent of the span of `B`, - so that they join the same "tree" of call +
(that normally starts shortly after, and finishes shortly before) + + - the span of `A` will be the parent of the span of `B` + + - they join the same "tree" of calls + + details: `A` will send headers (depends of the protocol used) to tag the span ID, so that `B` can generate child span and joining the same tree of call --- + ## Centrally stored -- We do have "spans", ok. But what do we do with that ? +- What do we do with all these spans? -- We store them. +- We store them! - In the previous exemple: - - `A` will send trace to it's local agent + - `A` will send trace information to its local agent - `B` will do the same - - Every span will ends up in the same DB so that we can reconstruct the "tree" of call - later on and analyze it. + - every span will end up in the same DB + - at a later point, we can reconstruct the "tree" of call and analyze it -- there is multiple implementation of those agents + DB + WebUI. The most famous opensource ones: +- There are multiple implementations of this stack (agent + DB + web UI) - - Zipkin - - Jaeger + (the most famous open source ones are Zipkin and Jaeger) --- -## Distributed sampled -- Huh, we store all of them ? (that could be a lot of storage) +## Data sampling -- No, we could apply sampling, to reduce storage/network footprint. +- Do we store *all* the spans? -- Smart sampling is applied directly in the application to save CPU if span is not needed. + (it looks like this could need a lot of storage!) -- It also insures that if a span is mark as sampled, all child-span are sampled together +- No, we can use *sampling*, to reduce storage and network requirements + +- Smart sampling is applied directly in the application to save CPU if span is not needed + +- It also insures that if a span is marked as sampled, all child span are sampled as well (so that the tree of call is complete) diff --git a/slides/k8s/prometheus-endpoint.md b/slides/k8s/prometheus-endpoint.md index 4b398416..44bdbc94 100644 --- a/slides/k8s/prometheus-endpoint.md +++ b/slides/k8s/prometheus-endpoint.md @@ -1,15 +1,24 @@ # Prometheus -Prometheus is monitoring system with small storage io footprint. It's quite ubiquitous +Prometheus is monitoring system with small storage io footprint. -in the kubernetes world. This section is not a description +It's quite ubiquitous in the Kubernetes world. +This section is not a description -## Prometheus endpoint + -The goal here is to expose an HTTP endoint for prometheus. Sample response: +--- + +## Prometheus exporter + +We want to provide a Prometheus exporter. + +A Prometheus exporter is an HTTP endpoint serving a response like this one: -.small[ ``` # HELP http_requests_total The total number of HTTP requests. # TYPE http_requests_total counter @@ -19,68 +28,119 @@ The goal here is to expose an HTTP endoint for prometheus. Sample response: # 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 +## Implementing a Prometheus exporter -- Offer multiple ways of integrations: +Multiple strategies can be used: - - from: I run already a web server, just add a monitoring route +- Implement the exporter in the application itself - - to: please run a full web server in a thread. + (especially if it's already an HTTP server) + +- Use building blocks that may already expose such an endpoint + + (puma, uwsgi) + +- Add a sidecar exporter that leverages and adapts an existing monitoring channel + + (e.g. JMX for Java applications) + +--- + +## Implementing a Prometheus exporter + +- The Prometheus client libraries are often the easiest solution + +- They offer multiple ways of integration, including: + + - "I'm already running a web server, just add a monitoring route" + + - "I don't have a web server (or I want another one), please run one in a thread" + +- Client libraries for various languages: -Links (do you see a pattern ?): - https://github.com/prometheus/client_python + - https://github.com/prometheus/client_ruby + - https://github.com/prometheus/client_golang + (Can you see the pattern?) --- -## Add sidecar Exporter -- There is plenty of already existing "exporter": +## Adding a sidecar exporter - - https://prometheus.io/docs/instrumenting/exporters/ +- There are many exporters available already: -- Those are "translators" from one monitoring channel to another + https://prometheus.io/docs/instrumenting/exporters/ -- Writing your own is not complicated (using previous client libraries) +- These are "translators" from one monitoring channel to another -- Try to not expose monitoring channel more than needed. Often localhost is enough - (sidecars run in the same network namespace as other containers) +- Writing your own is not complicated + + (using the client libraries mentioned previously) + +- Avoid exposing the internal monitoring channel more than enough + + (the app and its sidecars run in the same network namespace, +
so they can communicate over `localhost`) --- -## Ok! and then change prometheus conf ? -- Well, not really. It achievable this way, but... +## Configuring the Prometheus server -- Prometheus has good service discovery paired with kubernetes. +- We need to tell the Prometheus server to *scrape* our exporter -- Depending on how we installed prometheus, we just need: +- Prometheus has a very flexible "service discovery" mechanism - - pods annotations: + (to discover and enumerate the targets that it should scrape) - ``` - annotations: - prometheus.io/port: 9090 - prometheus.io/path: /metrics - ``` +- Depending on how we installed Prometheus, various methods might be available - - *service monitor* custom resource object -.small[ - https://github.com/coreos/prometheus-operator/blob/master/Documentation/api.md#servicemonitor -] +--- -*Note: More on prometheus next day* +## Configuring Prometheus, option 1 + +- Edit `prometheus.conf` + +- Always possible + + (we should always have a Prometheus configuration file somewhere!) + +- Dangerous and error-prone + + (if we get it wrong, it is very easy to break Prometheus) + +- Hard to maintain + + (the file will grow over time, and might accumulate obsolete information) + +--- + +## Configuring Prometheus, option 2 + +- Add *annotations* to the pods or services to monitor + +- We can do that if Prometheus is installed with the official Helm chart + +- Prometheus will detect these annotations and automatically start scraping + +- Example: + ```yaml + annotations: + prometheus.io/port: 9090 + prometheus.io/path: /metrics + ``` + +--- + +## Configuring Prometheus, option 3 + +- Create a ServiceMonitor custom resource + +- We can do that if we are using the CoreOS Prometheus operator + +- See the [Prometheus operator documentation](https://github.com/coreos/prometheus-operator/blob/master/Documentation/api.md#servicemonitor) for more details