The Helm chart installs OpenTelemetry Operator in Kubernetes cluster. The OpenTelemetry Operator is an implementation of a Kubernetes Operator. At this point, it has OpenTelemetry Collector as the only managed component.
In Kubernetes, in order for the API server to communicate with the webhook component, the webhook requires a TLS certificate that the API server is configured to trust. There are three ways for you to generate the required TLS certificate.
admissionWebhooks.certManager.create to true.
In this way, cert-manager will generate a self-signed certificate. See cert-manager installation for more details.admissionWebhooks.certManager.issuerRef value. You will need
to specify the kind (Issuer or ClusterIssuer) and the name. Note that this method also requires the installation of cert-manager.admissionWebhooks.certManager.enabled to false. Helm will create self-signd cert and secret for you..Values.admissionWebhooks.create and admissionWebhooks.certManager.enabled while setting your custom cert secret name in admissionWebhooks.secretName.Values.admissionWebhooks.create and setting env var to ENABLE_WEBHOOKS: "false"$ helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts
$ helm repo update
See helm repo for command documentation.
$ helm install \
my-opentelemetry-operator open-telemetry/opentelemetry-operator
If you created a custom namespace, like in the TLS Certificate Requirement section above, you will need to specify the namespace with the --namespace helm option:
$ helm install --namespace opentelemetry-operator-system \
my-opentelemetry-operator open-telemetry/opentelemetry-operator
See helm install for command documentation.
The following command uninstalls the chart whose release name is my-opentelemetry-operator.
$ helm uninstall my-opentelemetry-operator
See helm uninstall for command documentation.
This will remove all the Kubernetes components associated with the chart and deletes the release.
The OpenTelemetry Collector CRD created by this chart won’t be removed by default and should be manually deleted:
$ kubectl delete crd opentelemetrycollectors.opentelemetry.io
$ helm upgrade my-opentelemetry-operator open-telemetry/opentelemetry-operator
Please note that by default, the chart will be upgraded to the latest version. If you want to upgrade to a specific version,
use --version flag.
With Helm v3.0, CRDs created by this chart are not updated by default and should be manually updated. Consult also the Helm Documentation on CRDs.
See helm upgrade for command documentation.
The following command will show all the configurable options with detailed comments.
$ helm show values open-telemetry/opentelemetry-operator
See OpenTelemetry website for more details about the Collector
Once the opentelemetry-operator deployment is ready, you can deploy OpenTelemetry Collector in our Kubernetes cluster.
The Collector can be deployed as one of four modes: Deployment, DaemonSet, StatefulSet and Sidecar. The default mode is Deployment. We will introduce the benefits and use cases of each mode as well as giving an example for each.
If you want to get more control of the OpenTelemetry Collector and create a standalone application, Deployment would be your choice. With Deployment, you can relatively easily scale up the Collector to monitor more targets, roll back to an early version if anything unexpected happens, pause the Collector, etc. In general, you can manage your Collector instance just as an application.
The following example configuration deploys the Collector as Deployment resource. The receiver is Jaeger receiver and the exporter is logging exporter.
$ kubectl apply -f - <<EOF
apiVersion: opentelemetry.io/v1alpha1
kind: OpenTelemetryCollector
metadata:
name: my-collector
spec:
mode: deployment # This configuration is omittable.
config: |
receivers:
jaeger:
protocols:
grpc:
processors:
exporters:
logging:
service:
pipelines:
traces:
receivers: [jaeger]
processors: []
exporters: [logging]
EOF
DaemonSet should satisfy your needs if you want the Collector run as an agent in your Kubernetes nodes. In this case, every Kubernetes node will have its own Collector copy which would monitor the pods in it.
The following example configuration deploys the Collector as DaemonSet resource. The receiver is Jaeger receiver and the exporter is logging exporter.
$ kubectl apply -f - <<EOF
apiVersion: opentelemetry.io/v1alpha1
kind: OpenTelemetryCollector
metadata:
name: my-collector
spec:
mode: daemonset
config: |
receivers:
jaeger:
protocols:
grpc:
processors:
exporters:
logging:
loglevel: debug
service:
pipelines:
traces:
receivers: [jaeger]
processors: []
exporters: [logging]
EOF
There are basically three main advantages to deploy the Collector as the StatefulSet:
The following example configuration deploys the Collector as StatefulSet resource with three replicas. The receiver is Jaeger receiver and the exporter is logging exporter.
$ kubectl apply -f - <<EOF
apiVersion: opentelemetry.io/v1alpha1
kind: OpenTelemetryCollector
metadata:
name: my-collector
spec:
mode: statefulset
replicas: 3
config: |
receivers:
jaeger:
protocols:
grpc:
processors:
exporters:
logging:
service:
pipelines:
traces:
receivers: [jaeger]
processors: []
exporters: [logging]
EOF
The biggest advantage of the sidecar mode is that it allows people to offload their telemetry data as fast and reliable as possible from their applications. This Collector instance will work on the container level and no new pod will be created, which is perfect to keep your Kubernetes cluster clean and easily to be managed. Moreover, you can also use the sidecar mode when you want to use a different collect/export strategy, which just suits this application.
Once a Sidecar instance exists in a given namespace, you can have your deployments from that namespace to get a sidecar
by either adding the annotation sidecar.opentelemetry.io/inject: true to the pod spec of your application, or to the namespace.
See the OpenTelemetry Operator github repository for more detailed information.
$ kubectl apply -f - <<EOF
apiVersion: opentelemetry.io/v1alpha1
kind: OpenTelemetryCollector
metadata:
name: sidecar-for-my-app
spec:
mode: sidecar
config: |
receivers:
jaeger:
protocols:
thrift_compact:
processors:
exporters:
logging:
service:
pipelines:
traces:
receivers: [jaeger]
processors: []
exporters: [logging]
EOF
$ kubectl apply -f - <<EOF
apiVersion: v1
kind: Pod
metadata:
name: myapp
annotations:
sidecar.opentelemetry.io/inject: "true"
spec:
containers:
- name: myapp
image: jaegertracing/vertx-create-span:operator-e2e-tests
ports:
- containerPort: 8080
protocol: TCP
EOF