Skip to main content
This guide walks through installing Cilium (a Kubernetes CNI powered by eBPF) on a cluster using the Cilium CLI. It covers creating a local example cluster with kind (optional), installing the cilium CLI, installing Cilium into the cluster, verifying the installation, and previewing the manifests that the CLI applies. Target audience: Kubernetes users who want to replace or install a CNI with Cilium and those validating Cilium deployments in local or cloud clusters.

Prerequisites

You can use any Kubernetes distribution (kind, Minikube, EKS, GKE, etc.). The important requirement for this demonstration is that the cluster must not have a CNI installed — otherwise kubelet nodes will report NotReady until a CNI is present.

1 — Create a kind cluster (example)

If you want to follow along locally, create a kind cluster and disable the default CNI so we can install Cilium manually. Save this example as kind.config:
Create the cluster:
Switch kubectl context to the new cluster:
Verify node status. Nodes will typically show NotReady until a CNI is installed:
Example output:

2 — Install the Cilium CLI

Open the official Cilium Quick Installation page for the latest installation instructions: https://docs.cilium.io/en/stable/gettingstarted/quick-install/
A browser screenshot of the Cilium documentation page titled "Cilium Quick Installation," showing installation instructions and a left-hand navigation menu. A green mouse cursor is visible pointing at the page text.
On a Linux host you can download and install the cilium CLI with the following script. It detects CPU architecture, validates the tarball checksum, and installs the binary to /usr/local/bin:
Confirm installation:
Example output:
Note: the “cilium image (running)” field is unknown until Cilium is installed and running in the cluster.

3 — Install Cilium with the CLI

By default, the CLI installs into the current kubectl context. Install with:
If you need custom settings, prepare a Helm values file (the CLI converts these into the Helm chart values) and pass it with --values. Example values.yaml (enable IPv6):
Install with the custom values:
The CLI auto-detects cluster type and existing components (for example, whether kube-proxy is installed). If kube-proxy is already present, the default behavior is to run Cilium alongside kube-proxy. To replace kube-proxy with Cilium’s eBPF-based proxy, enable the appropriate Helm value or use CLI options to enable kube-proxy replacement. A sample installer log (abridged):

4 — Verify Cilium status

After install, verify the Cilium control plane, pods, and related components:
Example output (abridged and formatted):
This output confirms the Cilium DaemonSet and operator are running and ready across the nodes.
If you want Cilium to replace kube-proxy functionality with the eBPF-based proxy, enable the appropriate Helm values (or use the CLI options) to enable kube-proxy replacement. That is a configuration choice — by default the installer runs alongside kube-proxy when it detects kube-proxy is installed.

5 — Preview the manifests (dry run)

To inspect the raw Kubernetes manifests that the CLI will apply, run a dry run and capture the output:
Open cilium-dry-run.yaml to review the generated resources (DaemonSets, Deployments, ConfigMaps, RBAC, etc.). Example excerpt (operator pod spec):
Reviewing manifests is recommended for audits, compliance, or to tailor Cilium to production environments.

Resources and next steps

Suggested next steps:
  • Review Helm values to enable production features (Hubble observability, ClusterMesh, etc.).
  • If replacing kube-proxy, test kube-proxy replacement settings in a staging cluster first.
  • Validate networking and policy behavior with sample workloads and network policies.
Table — Common cilium CLI commands You now have Cilium installed using the CLI. Adjust Helm values and CLI options based on your environment and production requirements.

Watch Video