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:
Resource TypePurposeExample resource(s)
DaemonSetPer-node agent or proxycilium, cilium-envoy
DeploymentCluster operatorcilium-operator
ConfigMapRuntime configuration for agents/proxiescilium-config, cilium-envoy-config
SecretTLS certificates, Helm release infocilium-ca, hubble-server-certs, sh.helm.release.v1.cilium.v1
ServiceAccountAPI authentication for componentscilium, cilium-envoy, cilium-operator
ClusterRole / RoleRBAC permissionscilium, cilium-operator
ClusterRoleBinding / RoleBindingBind permissions to ServiceAccountscilium, cilium-operator
CRDCilium-specific resourcesciliumendpoints.cilium.io, ciliumidentities.cilium.io, …

Verify DaemonSets

List DaemonSets in the kube-system namespace:
kubectl get daemonset -n kube-system
Example output:
NAME           DESIRED  CURRENT  READY  UP-TO-DATE  AVAILABLE  NODE SELECTOR               AGE
cilium         3        3        3      3           3          kubernetes.io/os=linux     5h53m
cilium-envoy   3        3        3      3           3          kubernetes.io/os=linux     5h53m
kube-proxy     3        3        3      3           3          kubernetes.io/os=linux     6h2m

Inspect running pods

List pods in kube-system to confirm running instances:
kubectl get pod -n kube-system
Representative output (trimmed):
NAME                                                  READY   STATUS    RESTARTS   AGE
cilium-2sj75                                          1/1     Running   0          5h53m
cilium-envoy-cpsft                                    1/1     Running   0          5h53m
cilium-envoy-j9gx9                                    1/1     Running   0          5h53m
cilium-envoy-vm54m                                    1/1     Running   0          5h53m
cilium-k8bvb                                          1/1     Running   0          5h53m
cilium-mt449                                          1/1     Running   0          5h53m
cilium-operator-59944f4b8f-kwkbc                      1/1     Running   0          5h53m
cilium-operator-59944f4b8f-wqxw7                      1/1     Running   0          5h53m
coredns-668d6bf9bc-4bqmj                              1/1     Running   0          6h3m
coredns-668d6bf9bc-h8kzk                              1/1     Running   0          6h3m
...
Describe a single Cilium agent pod to view container details (image, args, mounts, etc.):
kubectl describe pod cilium-2sj75 -n kube-system
Important excerpt (trimmed for clarity):
Containers:
  cilium-agent:
    Container ID:  containerd://c05cc9963bfe284e57...
    Image:         quay.io/cilium/cilium:v1.17.2@sha256:3c4c9932b5d8368619cb922a497ff2ebc8def5f41c18e410bcc84025fcd385b1
    Command:
      cilium-agent
    Args:
      --config-dir=/tmp/cilium/config-map
    State:         Running
    Started:       Tue, 25 Mar 2025 21:26:48 +0000
    Ready:         True
    Restart Count: 0
Mounts:
  /host/opt/cni/bin from cni-path (rw)
  /var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-kgxtt (ro)
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:
kubectl get configmap -n kube-system
Example output:
NAME                                                     DATA   AGE
cilium-config                                            145    5h59m
cilium-envoy-config                                      1      5h59m
coredns                                                  1      6h9m
...
Describe (or view) the main Cilium ConfigMap to see keys and values originating from your Helm values.yaml:
kubectl describe configmap cilium-config -n kube-system
Example snippets (trimmed):
enable-l7-proxy:
----
true

enable-ipv6:
----
true

arping-refresh-period:
----
30s
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:
kubectl get deployment -n kube-system
Example:
NAME                      READY   UP-TO-DATE   AVAILABLE   AGE
cilium-operator           2/2     2            2           6h1m
coredns                   2/2     2            2           6h11m

Secrets, ServiceAccounts, and RBAC

List Secrets in kube-system:
kubectl get secret -n kube-system
Example output:
NAME                               TYPE                                DATA   AGE
bootstrap-token-abcdef             bootstrap.kubernetes.io/token       6      6h11m
cilium-ca                          Opaque                              2      6h1m
hubble-server-certs                kubernetes.io/tls                   3      6h1m
sh.helm.release.v1.cilium.v1       helm.sh/release.v1                  1      6h1m
List ServiceAccounts:
kubectl get sa -n kube-system
Look for Cilium-related accounts:
NAME            SECRETS   AGE
cilium          0         6h2m
cilium-envoy    0         6h2m
cilium-operator 0         6h2m
...
Cilium requires specific permissions to interact with cluster resources. These are defined via Roles / ClusterRoles and bound to ServiceAccounts through RoleBindings / ClusterRoleBindings. List Roles:
kubectl get roles -n kube-system
Find Cilium ClusterRoles:
kubectl get clusterroles | grep -i cilium
Example output:
cilium                                         2025-03-25T21:26:26Z
cilium-operator                                2025-03-25T21:26:26Z
Describe a ClusterRole to inspect granted verbs/resources:
kubectl describe clusterrole cilium
Representative excerpt:
PolicyRule:
  Resources                                      Non-Resource URLs  Resource Names  Verbs
  ---------                                      -----------------  --------------  -----
  endpoints                                      []                 []              [get list watch]
  namespaces                                     []                 []              [get list watch]
  nodes                                          []                 []              [get list watch]
  pods                                           []                 []              [get list watch]
  services                                       []                 []              [get list watch]
  endpointslices.discovery.k8s.io                []                 []              [get list watch]
  networkpolicies.networking.k8s.io              []                 []              [get list watch]
  ciliumnodes.cilium.io/status                   []                 []              [get update]
  ciliumendpoints.cilium.io                      []                 []              [list watch create delete get patch]
  ...
Check ClusterRoleBindings that bind ClusterRoles to ServiceAccounts:
kubectl get clusterrolebinding | grep -i cilium
Example:
cilium                                  6h5m    ClusterRole/cilium
cilium-operator                         6h5m    ClusterRole/cilium-operator
Describe a binding to confirm subjects:
kubectl describe clusterrolebinding cilium
Excerpt:
Subjects:
  Kind             Name      Namespace
  ----             ----      ---------
  ServiceAccount   cilium    kube-system

CustomResourceDefinitions (CRDs)

Cilium installs multiple CRDs used for policy, endpoints, identities, and other Cilium-specific resources:
kubectl get crd
Example output (trimmed):
NAME                                           CREATED AT
ciliumcidrgroups.cilium.io                    2025-03-25T21:26:33Z
ciliumclusterwidenetworkpolicies.cilium.io    2025-03-25T21:26:33Z
ciliumendpoints.cilium.io                     2025-03-25T21:26:33Z
ciliumexternalworkloads.cilium.io             2025-03-25T21:26:33Z
ciliumidentities.cilium.io                    2025-03-25T21:26:33Z
...

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