Skip to main content
You can configure odigos installation using the following options:

​
Ignore Namespaces

Don’t show specific uninteresting namespaces in the Odigos UI. Default values: kube-system, local-path-storage, istio-system, linkerd, kube-node-lease Add additional namespaces to ignore with cli: 
odigos install --ignore-namespace <namespace1> --ignore-namespace <namespace2>
List all namespaces to be ignored with helm chart: 
helm install odigos odigos/odigos --set ignoreNamespace=<namespace1>,<namespace2>
Any Source objects for the namespace and workloads in the namespace will still be honored.

​
Ignore Containers

This option is useful for excluding specific sidecar containers from being instrumentated by odigos. Default values: istio-proxy 
odigos install --ignore-container <container1> --ignore-container <container2>

​
Custom Container Runtime Socket Path

Odigos uses the container runtime socket to query for application environment variables info, and distinguish between those injected by the runtime (via Dockerfile for example) and those defined in Kubernetes manifests. To perform this analysis, Odiglet requires access to the container runtime’s Unix socket (e.g., containerd.sock). However, in certain environments—such as Rancher—the socket may not be located in a default path. To address this, Odigos provides a configuration option to mount a custom container runtime socket path into the Odiglet. This path can be specified either during installation or afterwards.

​
Usage

  1. During and Post installation using set flag for the install command:
odigos install --set odiglet.customContainerRuntimeSocketPath=<unix socket path>

​
OpenShift Installation

Installing on OpenShift requires additional settings that can be configured based on your installation mode:
Run the Odigos CLI with the --openshift flag:
odigos install --openshift
OpenShift installation does the following:
  • Uses Red Hat certified component container images
  • Configures required SELinux permissions for pods to access auto-instrumentation agents on RHEL nodes
  • Configures RBAC permissions for Odigos components required by default in OpenShift clusters
By default, the --openshift flag will pull Odigos component images from registry.connect.redhat.com/odigos. These images are based on Red Hat’s Universal Base Image 9 and denoted with the -rhel-certified suffix. These images are also hosted on the Odigos DockerHub registry, which you can deploy by setting --openshift with --image-prefix docker.io/keyval.

​
Exposing the Odigos UI via OpenShift Routes

To access the Odigos UI in OpenShift, use either the standard odigos ui command or create a Route that exposes the ui service on your cluster’s external address. For example: 
oc expose service ui -n odigos-system
Then get the external address for the Route with oc get routes ui -n odigos-system. Note: If you’re deploying Odigos on OpenShift, you may need to set the route’s TLS termination to Edge to load it in your browser. you will need to modify the YAML of the oc route with spec.tls.termination: edge Check the OpenShift documentation or run oc expose -h for more information on configuring OpenShift routes according to your cluster’s requirements.

​
GKE Installation

Installing on Google Kubernetes Engine (GKE) requires additional settings that can be configured based on your cluster type:
For GKE Standard clusters:
odigos install --set gke.enabled=true
For GKE Autopilot clusters:
odigos install --set gke.enabled=true --set gke.autopilot=true
GKE installation with gke.enabled=true does the following:
  • Configures a ResourceQuota for system-node-critical pods, which is required for odiglet on GKE

​
GKE Autopilot

GKE Autopilot restricts privileged workloads by default. Odiglet requires elevated permissions for eBPF-based instrumentation, so it must be allowlisted before it can run on Autopilot clusters. Allowlist synchronization requires GKE version 1.32.2-gke.1652000 or later. When gke.autopilot=true, the Helm chart:
  • Creates an AllowlistSynchronizer that syncs the Odigos odiglet allowlist from the Google-managed partner repository
  • Skips node label setup in the odiglet init phase, where Autopilot nodes cannot be modified. Autopilot is auto-detected by the gk3- node name prefix; set gke.autopilot=true to force this behavior

​
Node label limitations

On standard clusters, odiglet sets odigos.io/odiglet-oss-installed=true (or odigos.io/odiglet-enterprise-installed=true for enterprise) on each node after preparing it for instrumentation. Autopilot does not allow modifying node labels, so odiglet skips this step. Without the label:
  • Instrumented pod scheduling with hostPath or CSI mount methods — For k8s-host-path and k8s-csi-driver mount methods, the instrumentor webhook adds required node affinity matching the odiglet installed label so pods only schedule on nodes where odiglet has prepared /var/odigos. Without the label on Autopilot nodes, newly instrumented pods may remain Pending and fail to schedule. The default k8s-virtual-device mount method does not rely on this label and is recommended on Autopilot.
  • Karpenter integration — Odiglet normally removes the odigos.io/needs-init startup taint when it sets the node label. This step is also skipped on Autopilot, so the Karpenter integration workflow is not supported.

​
Manually create the AllowlistSynchronizer

If you do not set gke.autopilot=true, create the AllowlistSynchronizer yourself before odiglet pods are scheduled. See the GKE documentation for running Autopilot partner workloads for more details. Apply the following manifest to install all Odigos allowlists from the partner repository: 
apiVersion: auto.gke.io/v1
kind: AllowlistSynchronizer
metadata:
  name: odigos-allowlist-synchronizer
spec:
  allowlistPaths:
    - "Odigos/Odigos/*"

kubectl apply -f allowlist-synchronizer.yaml
After the allowlist is installed, verify that it is ready before odiglet pods start: 
kubectl wait --for=condition=Ready allowlistsynchronizer/odigos-allowlist-synchronizer --timeout=60s
kubectl get workloadallowlist
For more information on privileged workload allowlisting in Autopilot, see the GKE documentation on running Autopilot partner workloads.