---
title: OpenTelemetry AutoInstrumentation for Kubernetes
description: Inject OpenTelemetry auto-instrumentation into Kubernetes workloads by using the Coralogix OpenTelemetry Integration Helm chart.
url: https://coralogix.com/docs/opentelemetry/kubernetes-observability/opentelemetry-autoinstrumentation/
product: infra-monitoring
feature: Kubernetes Monitoring
feature_id: k8s-infra-monitoring
feature_identifier: infra-monitoring/k8s-infra-monitoring
last_updated: '2026-08-24'
---

# OpenTelemetry AutoInstrumentation

Use OpenTelemetry AutoInstrumentation when you want to collect application traces from Kubernetes workloads without changing application code. The Coralogix OpenTelemetry Integration Helm chart can deploy a webhook that injects OpenTelemetry AutoInstrumentation into annotated pods and sends traces to the node-local `opentelemetry-agent` DaemonSet.

This mode does not require `Instrumentation` Custom Resource Definitions (CRDs). The instrumentation settings are configured once in Helm values and reused for all annotated workloads in the release.

## Prerequisites

* [Install Kubernetes Observability using OpenTelemetry](https://coralogix.com/docs/opentelemetry/kubernetes-observability/kubernetes-complete-observability-basic-configuration.md) with the OpenTelemetry Integration Helm chart v0.0.339 or later
* Linux worker nodes for the webhook and supported auto-instrumentation images

Supported languages and runtimes are Java, Python, .NET, Apache HTTPD, and nginx.

Warning

Do not enable `opentelemetry-autoinstrumentation` in a cluster that already has an OpenTelemetry Operator admission webhook installed, unless webhook names and selectors are configured to avoid collisions.

## Enable OpenTelemetry AutoInstrumentation

Add the following values to your Helm values file:

```
opentelemetry-autoinstrumentation:

  enabled: true
```

Install or upgrade the chart:

```
helm upgrade --install otel-coralogix-integration \

  coralogix-charts-virtual/otel-integration \

  -f values.yaml \

  --set global.clusterName=<cluster_name> \

  --set global.domain=eu2.coralogix.com
```

## Annotate workloads

Add one of these annotations to the pod template of the workload you want to instrument:

```
instrumentation.opentelemetry.io/inject-java: "true"

instrumentation.opentelemetry.io/inject-python: "true"

instrumentation.opentelemetry.io/inject-dotnet: "true"

instrumentation.opentelemetry.io/inject-apache-httpd: "true"

instrumentation.opentelemetry.io/inject-nginx: "true"
```

Example deployment:

```
apiVersion: apps/v1

kind: Deployment

metadata:

  name: checkout

spec:

  replicas: 1

  selector:

    matchLabels:

      app: checkout

  template:

    metadata:

      labels:

        app: checkout

      annotations:

        instrumentation.opentelemetry.io/inject-java: "true"

    spec:

      containers:

        - name: checkout

          image: "<your_app_image>"
```

Restart existing pods after adding the annotation. The webhook only mutates pods during creation.

## Default trace export path

Injected workloads export traces to the OpenTelemetry Agent running on the same Kubernetes node:

* Java, .NET, Apache HTTPD, and nginx: OTLP/gRPC to `http://$(OTEL_NODE_IP):4317`
* Python: OTLP HTTP/protobuf to `http://$(OTEL_NODE_IP):4318`

The chart sets `OTEL_NODE_IP` from the pod `status.hostIP` field, so each instrumented workload sends telemetry to its local node agent.

## Configure instrumentation settings

The chart uses a static instrumentation configuration under:

```
opentelemetry-autoinstrumentation:

  manager:

    config:

      instrumentations:

        spec:
```

Use this section to override exporter settings, propagators, sampler settings, resource attributes, or language-specific environment variables.

Example:

```
opentelemetry-autoinstrumentation:

  enabled: true

  manager:

    config:

      instrumentations:

        spec:

          propagators:

            - tracecontext

            - baggage

          sampler:

            type: parentbased_traceidratio

            argument: "1.0"

          env:

            - name: OTEL_RESOURCE_ATTRIBUTES

              value: deployment.environment=production

          java:

            env:

              - name: OTEL_SERVICE_NAME

                value: checkout

          python:

            env:

              - name: OTEL_SERVICE_NAME

                value: checkout

          dotnet:

            env:

              - name: OTEL_SERVICE_NAME

                value: checkout

          apacheHttpd:

            image: ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-apache-httpd:1.0.4

          nginx:

            image: ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-apache-httpd:1.0.4
```

## Limitations

* One static instrumentation configuration is used per Helm release.
* .NET auto-instrumentation requires x64 Linux runtime support.
* Nginx auto-instrumentation supports Nginx 1.22.0, 1.23.0, and 1.23.1.
* The webhook creates cluster-scoped RBAC and admission webhook resources.
* This chart option does not install OpenTelemetry Operator CRDs and does not support per-namespace `Instrumentation` CRs.

## Validate the setup

Check that the webhook manager is running:

```
kubectl get pods -l app.kubernetes.io/name=otel-autoinstrumentation
```

Check that an annotated pod has an injected init container:

```
kubectl get pod <pod_name> -o jsonpath='{.spec.initContainers[*].name}'
```

Expected init container names include:

* `opentelemetry-auto-instrumentation-java`
* `opentelemetry-auto-instrumentation-python`
* `opentelemetry-auto-instrumentation-dotnet`
* `otel-agent-attach-apache`
* `otel-agent-attach-nginx`

Then generate traffic to the application and verify traces in Coralogix APM.