System Requirements
To ensure optimal performance and compatibility when deploying Odigos, your environment must meet the following system requirements:
Kubernetes Version
Odigos requires Kubernetes version 1.23.0 or higher.
Odigos Enterprise data collection is done using eBPF, so Odigos requires, at minimum, platforms that have underlying Linux kernel versions of 5.4.0.
What to expect if some nodes don’t meet the Kernel requirement:
- eBPF Agents: If a node’s kernel version is below 5.4.0, eBPF-based data collection will not be applied to workloads on that node. An error will appear in the UI for any source running on unsupported nodes, indicating that instrumentation was not possible.
- Non-eBPF Agents: Non-eBPF-based agents are not affected by kernel version requirements and will run and instrument workloads on any Linux version.
This allows users to maintain observability on nodes that meet the requirements without needing to upgrade all cluster nodes immediately.
Kubernetes Cluster Types
- Kind
- Minikube
- K3s
- Red Hat OpenShift (see how to install on OpenShift)
- Amazon Elastic Kubernetes Service (EKS)
- Google Kubernetes Engine (GKE)
- Azure Kubernetes Service (AKS)
Resource Requirements
To achieve its functionality Odigos uses a set of Deployments and Daemonsets.
Cluster
The following components runs as Deployment and request the following resources (per pod):
| Component Name | Memory Request | Memory Limit | CPU Request | CPU Limit |
|---|---|---|---|---|
| odigos-autoscaler | 64Mi | 512Mi | 10m | 500m |
| odigos-instrumentor (2 replicas) | 64Mi | 512Mi | 10m | 500m |
| odigos-schedualer | 64Mi | 512Mi | 10m | 500m |
| odigos-ui | 64Mi | 512Mi | 10m | 500m |
In addition, Odigos deploys OpenTelemetry Collector Deployment, with auto scaling (multiple replicas) and configurable resources requests and limits. The default values (unless overridden) are:
| Component Name | Memory Request | Memory Limit | CPU Request | CPU Limit |
|---|---|---|---|---|
| odigos-gateway | 300Mi | 300Mi | 150m | 300m |
Read more here.
Per Node
2 Daemonsets are deployed on each node in the cluster and consumes resources as follows:
- odiglet - Does not set requests and limits. it will consume resources as needed depending on the number of pods running on the node and the amount of data being recorded.
- odigos-data-collection - cpu and memory limits and requests are set by default to:
| Component Name | Memory Request | Memory Limit | CPU Request | CPU Limit |
|---|---|---|---|---|
| odigos-data-collection | 150Mi | 300Mi | 150m | 300m |
You can override these values by providing a custom configuration (read more here).
Network Requirements
Ensure that any network-layer components are properly configured to allow the required connectivity between Odigos components. Improper configuration may impact the correct operation of Odigos.
To ensure proper operation of Odigos components and instrumented applications, the following network connectivity must be allowed inside the Kubernetes cluster:
Core Network Connectivity
| Source | Destination Service | Ports | Purpose |
|---|---|---|---|
| Instrumented Application Pods | odiglet-local | 4320 | Retrieve instrumentation configuration from Odiglet |
| Instrumented Application Pods | odigos-data-collection-local-traffic | 4317 (gRPC), 4318 (HTTP) | Export application telemetry data (OTLP protocol) |
| Odiglet Pods | odigos-data-collection-local-traffic | 4318 | Export eBPF-collected telemetry data |
Network Layer Considerations
In some environments, the following network components may affect traffic between these services:
- Service meshes (e.g. Istio, Linkerd, Cilium, Consul)
- HTTP proxies or egress gateways
- Transparent proxies (corporate or cluster-level)
- Network security appliances (WAFs, L7 firewalls, DPI systems)
- Kubernetes NetworkPolicies