Skip to main content
In this lesson we inspect the Kubernetes resources that Cilium creates when deployed. You’ll see how Cilium components (agents, Envoy proxies, operator), configuration (ConfigMaps, Secrets), RBAC (Roles / ClusterRoles / Bindings), and CRDs are laid out in the cluster and which commands to use to verify them.
A presentation slide reading "What was Installed" on the left and a teal curved shape on the right with the word "Demo." The bottom-left corner shows a small "© Copyright KodeKloud" label.

Key Cilium components

  • Cilium agent: runs as a DaemonSet (one agent per node) and provides datapath, policy enforcement, and connectivity.
  • Envoy proxies: run as a DaemonSet for L7 and load-balancing features.
  • Cilium Operator: deployed as a Deployment and manages Cilium CRs and cluster-wide tasks.
  • Hubble (optional): observability/flow-visibility components (server/relay) when enabled.
Use the following table to quickly map installed resources to their roles and typical names:

Verify DaemonSets

List DaemonSets in the kube-system namespace:
Example output:

Inspect running pods

List pods in kube-system to confirm running instances:
Representative output (trimmed):
Describe a single Cilium agent pod to view container details (image, args, mounts, etc.):
Important excerpt (trimmed for clarity):
Note: the Cilium agent reads configuration from a ConfigMap mounted into the container under the path passed to --config-dir.

Inspect ConfigMaps and runtime configuration

List ConfigMaps in kube-system:
Example output:
Describe (or view) the main Cilium ConfigMap to see keys and values originating from your Helm values.yaml:
Example snippets (trimmed):
When you change values in your Helm values.yaml and reinstall or upgrade Cilium, those values are populated into these ConfigMaps. The Cilium agent and Envoy pick up configuration from the mounted files; some settings are read at process start and may require a pod restart.

Cilium Operator (Deployment)

List deployments in kube-system:
Example:

Secrets, ServiceAccounts, and RBAC

List Secrets in kube-system:
Example output:
List ServiceAccounts:
Look for Cilium-related accounts:
Cilium requires specific permissions to interact with cluster resources. These are defined via Roles / ClusterRoles and bound to ServiceAccounts through RoleBindings / ClusterRoleBindings. List Roles:
Find Cilium ClusterRoles:
Example output:
Describe a ClusterRole to inspect granted verbs/resources:
Representative excerpt:
Check ClusterRoleBindings that bind ClusterRoles to ServiceAccounts:
Example:
Describe a binding to confirm subjects:
Excerpt:

CustomResourceDefinitions (CRDs)

Cilium installs multiple CRDs used for policy, endpoints, identities, and other Cilium-specific resources:
Example output (trimmed):

Hubble (optional)

Hubble provides observability and flow visibility. If Hubble server/relay was not enabled in Helm values during installation, you will not see Hubble pods/services. Enabling Hubble in your Helm values.yaml creates additional resources (server, relay, certificates, etc.).
ConfigMap and Secret contents are available inside running Cilium containers because the files are mounted as volumes. Updating a ConfigMap updates the file contents inside the pod, but some components only read their config at process start—so you may need to restart pods for those changes to take effect.

Watch Video