> ## Documentation Index
> Fetch the complete documentation index at: https://docs.odigos.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Installation Options

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**:

```shell theme={null}
odigos install --ignore-namespace <namespace1> --ignore-namespace <namespace2>
```

List all namespaces to be ignored with **helm chart**:

```shell theme={null}
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`

<Tabs>
  <Tab title="Odigos CLI">
    ```shell theme={null}
    odigos install --ignore-container <container1> --ignore-container <container2>
    ```
  </Tab>

  <Tab title="Helm Chart">
    ```shell theme={null}
    helm install odigos odigos/odigos --set ignoreContainer=<container1>,<container2>
    ```
  </Tab>
</Tabs>

## 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

<Tabs>
  <Tab title="Odigos CLI">
    1. During and Post installation using set flag for the install command:

    ```shell theme={null}
    odigos install --set odiglet.customContainerRuntimeSocketPath=<unix socket path>
    ```
  </Tab>

  <Tab title="Helm Chart">
    1. During installation:

    ```shell theme={null}
    helm install odigos odigos/odigos --set odiglet.customContainerRuntimeSocketPath=<unix socket path>
    ```
  </Tab>
</Tabs>

## OpenShift Installation

Installing on OpenShift requires additional settings that can be
configured based on your installation mode:

<Tabs>
  <Tab title="Odigos CLI">
    Run the Odigos CLI with the `--openshift` flag:

    ```shell theme={null}
    odigos install --openshift
    ```
  </Tab>

  <Tab title="Helm Chart">
    Set `openshift.enabled=true` in `Values.yaml`:

    ```yaml theme={null}
    openshift
      enabled: true
    ```
  </Tab>

  <Tab title="Operator">
    In the OpenShift console, navigate to **Operators** > **OperatorHub** and search for **Odigos**:

    <Frame>
      <img src="https://mintcdn.com/odigos/q83sjmvkbDHigqAk/images/operator/operator-2.png?fit=max&auto=format&n=q83sjmvkbDHigqAk&q=85&s=0b2238fee5cdadcd3be83db9fd304204" width="2376" height="1644" data-path="images/operator/operator-2.png" />
    </Frame>

    Click **Install**:

    <Frame>
      <img src="https://mintcdn.com/odigos/q83sjmvkbDHigqAk/images/operator/operator-3.png?fit=max&auto=format&n=q83sjmvkbDHigqAk&q=85&s=6c0311adaf5191c43c4054eaddc42d91" width="2376" height="1644" data-path="images/operator/operator-3.png" />
    </Frame>

    Choose a namespace to install the Operator in (this will be the same namespace that Odigos is installed in) and click **Install**:

    <Frame>
      <img src="https://mintcdn.com/odigos/q83sjmvkbDHigqAk/images/operator/operator-4.png?fit=max&auto=format&n=q83sjmvkbDHigqAk&q=85&s=98c89e169348fc88301148d351d4751e" width="2376" height="1644" data-path="images/operator/operator-4.png" />
    </Frame>

    When installation is complete, click **View Operator**:

    <Frame>
      <img src="https://mintcdn.com/odigos/q83sjmvkbDHigqAk/images/operator/operator-5.png?fit=max&auto=format&n=q83sjmvkbDHigqAk&q=85&s=72e90cbaa7bb630f1efcbe1aaf5a7187" width="2376" height="1644" data-path="images/operator/operator-5.png" />
    </Frame>

    Click **Create Instance** to create an `Odigos` custom resource:

    <Frame>
      <img src="https://mintcdn.com/odigos/q83sjmvkbDHigqAk/images/operator/operator-6.png?fit=max&auto=format&n=q83sjmvkbDHigqAk&q=85&s=c2bec9274033f6e850c336d50651fe41" width="2376" height="1644" data-path="images/operator/operator-6.png" />
    </Frame>

    If you have an Enterprise Token, fill in the **On Prem Token** field with your Enterprise Token.  Otherwise leave it blank to use Odigos OpenSource.

    <Frame>
      <img src="https://mintcdn.com/odigos/q83sjmvkbDHigqAk/images/operator/operator-7.png?fit=max&auto=format&n=q83sjmvkbDHigqAk&q=85&s=569391cd0146df727538b74b1b6ba6f7" width="2376" height="1644" data-path="images/operator/operator-7.png" />
    </Frame>

    Scroll down and click **Create**:

    <Frame>
      <img src="https://mintcdn.com/odigos/q83sjmvkbDHigqAk/images/operator/operator-8.png?fit=max&auto=format&n=q83sjmvkbDHigqAk&q=85&s=db6b4869e4a22358525fd4f29fed57a7" width="2376" height="1644" data-path="images/operator/operator-8.png" />
    </Frame>

    Confirm that the Custom Resource has reached state `OdigosInstalled`:

    <Frame>
      <img src="https://mintcdn.com/odigos/q83sjmvkbDHigqAk/images/operator/operator-9.png?fit=max&auto=format&n=q83sjmvkbDHigqAk&q=85&s=f35484a82b81ace0914ba3536a301aa2" width="2376" height="1644" data-path="images/operator/operator-9.png" />
    </Frame>
  </Tab>
</Tabs>

OpenShift installation does the following:

* Uses [Red Hat certified component container images](https://odigos.io/blog/openshift-certified)
* 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](https://catalog.redhat.com/software/base-images) 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:

<Tabs>
  <Tab title="Odigos CLI">
    For GKE Standard clusters:

    ```shell theme={null}
    odigos install --set gke.enabled=true
    ```

    For GKE Autopilot clusters:

    ```shell theme={null}
    odigos install --set gke.enabled=true --set gke.autopilot=true
    ```
  </Tab>

  <Tab title="Helm Chart">
    For GKE Standard clusters, set `gke.enabled=true` in `values.yaml`:

    ```yaml theme={null}
    gke:
      enabled: true
    ```

    Or pass it as a flag during installation:

    ```shell theme={null}
    helm install odigos odigos/odigos --set gke.enabled=true
    ```

    For GKE Autopilot clusters, also set `gke.autopilot=true`:

    ```yaml theme={null}
    gke:
      enabled: true
      autopilot: true
    ```

    Or pass both flags during installation:

    ```shell theme={null}
    helm install odigos odigos/odigos --set gke.enabled=true --set gke.autopilot=true
    ```
  </Tab>
</Tabs>

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](https://cloud.google.com/kubernetes-engine/docs/how-to/run-autopilot-partner-workloads)
* 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](https://cloud.google.com/kubernetes-engine/docs/how-to/run-autopilot-partner-workloads)
for more details.

Apply the following manifest to install all Odigos allowlists from the partner
repository:

```yaml theme={null}
apiVersion: auto.gke.io/v1
kind: AllowlistSynchronizer
metadata:
  name: odigos-allowlist-synchronizer
spec:
  allowlistPaths:
    - "Odigos/Odigos/*"
```

```shell theme={null}
kubectl apply -f allowlist-synchronizer.yaml
```

After the allowlist is installed, verify that it is ready before odiglet pods start:

```shell theme={null}
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](https://cloud.google.com/kubernetes-engine/docs/how-to/run-autopilot-partner-workloads).