Quickly Set Up OpenTelemetry on Kubernetes: Installation, Modes & Config

Background

OpenTelemetry is a standard implementation for observability, especially for distributed tracing. In production it is typically deployed on a Kubernetes platform to provide services.

Introduction

The OpenTelemetry Collector is a vendor‑agnostic component that receives, processes, and exports telemetry data. This article guides users on how to set up an OpenTelemetry environment and highlights key configuration points.

Installation of OpenTelemetry

Multiple installation methods are available, such as direct manifest deployment or Helm‑based customized installation.

Manifest Installation

The following command deploys an otel-agent as a DaemonSet and an otel-collector as a Deployment in a Kubernetes cluster:

kubectl apply -f https://raw.githubusercontent.com/open-telemetry/opentelemetry-collector/main/examples/k8s/otel-config.yaml

Helm Installation

Steps for Helm installation:

Add the Helm repository:

helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts

Search for available charts: helm search repo open-telemetry Install the collector with default parameters:

helm install my-opentelemetry-collector open-telemetry/opentelemetry-collector --set mode=deployment

For customized installation, view all configurable options:

helm show values open-telemetry/opentelemetry-collector

Then apply a custom values file:

helm install -f xxx.yaml my-opentelemetry-collector open-telemetry/opentelemetry-collector

Deployment Modes

The installation methods support three deployment patterns: No‑Collector, Agent, and Gateway.

No Collector

Applications use the OpenTelemetry SDK to send telemetry directly to back‑ends without an intermediate collector.

Advantages: simple, no extra components.

Disadvantages: code changes required for telemetry updates, strong coupling with back‑ends, language‑specific limitations.

Agent Mode

Each host runs an otel-collector alongside the application (sidecar or DaemonSet). The SDK sends data to the local collector, which then forwards it to the back‑end.

Advantages: easy to start, clear 1:1 relationship between app and collector.

Disadvantages: limited flexibility, less extensible.

Gateway Mode

A load balancer (e.g., Nginx) distributes traffic among multiple collector instances. SDKs send data to the load balancer, which forwards it to a selected collector.

Advantages: centralized credential and policy management, ability to filter or sample data.

Disadvantages: added operational complexity, increased latency and resource usage.

Running the otel‑demo

The OpenTelemetry community provides a demo of distributed micro‑services. Deploy it with Helm:

helm install my-otel-demo open-telemetry/opentelemetry-demo

After deployment, you can access Grafana and Jaeger UI to view metrics and trace data.

otel‑collector Configuration Structure

The collector configuration consists of four main components: receivers, processors, exporters, and connectors, plus optional extensions and the service definition.

Example Configuration

receivers:
  otlp:
    protocols:
      grpc:
      http:

processors:
  batch:

exporters:
  otlp:
    endpoint: otelcol:4317

extensions:
  health_check:
  pprof:
  zpages:

service:
  extensions: [health_check, pprof, zpages]
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp]
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp]
    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp]

Extensions such as health_check, pprof, and zpages add optional functionality like health monitoring and profiling. The service section enables the configured components; components not listed here remain inactive.

Extensions Example

extensions:
  health_check:
  pprof:
  zpages:
  memory_ballast:
    size_mib: 512

Service Section Details

extensions: specifies which extensions are enabled.

pipelines: defines which receivers, processors, and exporters are active for traces, metrics, and logs.

telemetry: configures the collector’s own telemetry (logs, metrics) for self‑monitoring.

For more information, refer to the official OpenTelemetry documentation.