Open Telemetry quick start
OpenTelemetry is a Cloud Native Computing Foundation framework for observability. It enables your microservices to provide metrics, logs and traces.
Kubewarden’s components are instrumented with the OpenTelemetry SDK, reporting data to an OpenTelemetry collector — called the agent.
By following this documentation, we will integrate OpenTelemetry using the following architecture:
-
Each Pod of the Kubewarden stack will have a OpenTelemetry sidecar.
-
The sidecar receives tracing and monitoring information from the Kubewarden component via the OpenTelemetry Protocol (OTLP)
-
The OpenTelemetry collector will:
-
Send the trace events to a central Jaeger instance
-
Expose Prometheus metrics on a specific port
-
For more information about the other deployment modes, please refer to the OpenTelemetry official documentation.
Let’s first deploy OpenTelemetry in a Kubernetes cluster, so we can reuse it in the next sections that will address specifically tracing and metrics.
Setting up a Kubernetes cluster
This section gives step-by-step instructions to create a Kubernetes cluster with an ingress controller enabled.
Feel free to skip this section if you already have a Kubernetes cluster where you can define Ingress resources.
We are going to create a testing Kubernetes cluster using minikube.
minikube has many backends, in this case we will use the kvm2 driver which relies on libvirt.
Assuming libvirtd
is properly running on your machine, issue the
following command:
minikube start --driver=kvm2
The command will produce an output similar to the following one:
$ minikube start --driver=kvm2
😄 minikube v1.23.2 on Opensuse-Leap 15.3
✨ Using the kvm2 driver based on user configuration
👍 Starting control plane node minikube in cluster minikube
🔥 Creating kvm2 VM (CPUs=2, Memory=6000MB, Disk=20000MB) ...
🐳 Preparing Kubernetes v1.22.2 on Docker 20.10.8 ...
▪ Generating certificates and keys ...
▪ Booting up control plane ...
▪ Configuring RBAC rules ...
🔎 Verifying Kubernetes components...
▪ Using image gcr.io/k8s-minikube/storage-provisioner:v5
🌟 Enabled addons: storage-provisioner, default-storageclass
🏄 Done! kubectl is now configured to use "minikube" cluster and "default" namespace by default
Now we have to enable the Ingress addon:
minikube addons enable ingress
This will produce an output similar to the following one:
$ minikube addons enable ingress
▪ Using image registry.k8s.io/ingress-nginx/kube-webhook-certgen:v1.0
▪ Using image registry.k8s.io/ingress-nginx/controller:v1.0.0-beta.3
▪ Using image registry.k8s.io/ingress-nginx/kube-webhook-certgen:v1.0
🔎 Verifying ingress addon...
🌟 The 'ingress' addon is enabled
Install OpenTelemetry
We are going to use the OpenTelemetry Operator to manage the automatic injection of the OpenTelemetry Collector sidecar inside of the PolicyServer pod.
The OpenTelemetry Operator requires cert-manager to be installed inside of the cluster.
At the time of writing, only specific versions of OpenTelemetry are compatible with Cert Manager, see the compat chart.
We will install the latest cert-manager Helm chart:
At time of writing the latest cert-manager chart version is |
helm repo add jetstack https://charts.jetstack.io
helm install --wait \
--namespace cert-manager \
--create-namespace \
--set crds.enabled=true \
--version 1.15.1 \
cert-manager jetstack/cert-manager
Once cert-manager is up and running, the OpenTelemetry operator Helm chart can be installed in this way:
At time of writing (2024-11-11) the latest OpenTelemetry operator chart version is |
helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
helm install --wait \
--namespace open-telemetry \
--create-namespace \
--version 0.65.0 \
--set "manager.collectorImage.repository=otel/opentelemetry-collector-contrib" \
my-opentelemetry-operator open-telemetry/opentelemetry-operator