notebook

Components of Cilium

• Cilium Agent

  • Handles how pods communicate
  • Handles traffic distribution
  • Handles network policies
  • The cilium agent will keep track of pod state (start/stop/etc) across the cluster
  • The cilium agent loads the eBPF program in the kernel and ensures it is configured
    • When a pod sends traffic, it reaches a kernel hook point where an eBPF program is triggered. This program inspects the packet and determines whether to forward or drop it. If a layer 7 policy of rFQDN-based rule is in effect, the eBPF program may redirect the packet to the appropriate user space proxy: the DNS proxy for domain name resolution, or Envoy for HTTP and TLS traffic.

• Cluster Operator

  • The operator creates a CiliumNode object for every node in the cluster and populates it with relevant information.
  • Manages cluster-wide operations like node management, manages services, IPAM, the allocation and management of security identities used for network policies
  • CRD management
  • Installs the CNI binary on the nodes
    • Cilium is often referred to as a CNI, but it is much more than that. The CNI component of Cilium simply connects Cilium to Kubernetes through the CNI framework. The CNI framework is an interface that specifies each CNI must support four basic operations:
      • ADD
      • DELETE
      • CHECK
      • VERSION
    • When a user creates a pod, the request is sent to the API server. The pod is then scheduled on a node. The API server then notifies kubelet on that node. Kubelet delegates container creation to the container runtime (CRI). The CRI prepares the pod environment, including the container network namespace. The CRI then executes the CNI plugin defined in thek hosts configuration directory, typically /etc/cni/net.d/. The corresponding plugin binary is typically stored in /opt/cni/bin/. These paths are standard for all kubernetes nodes.
  • Handles interconnecting multiple clusters via cluster-mesh

• Envoy Proxy

  • The envoy proxy is needed for Layer 7 traffic. eBPF only operate at layer 4 of the OSI model

• Hubble

  • Hubble Server - one hubble server per node (daemonset). Observes network events locally. Enriches flow data with metadata such as pod names, namespaces, and policy verdicts
  • Hubble Relay - An optional component that adds multinode visibility. It discovers Hubble instances across the cluster, queries their gRPC APIs, and maintains connections to each peer to present a unified view of flow events.
  • Hubble CLI - A CLI tool for interacting with Hubble
  • Hubble UI - A web UI for interacting with Hubble

• Cilium CLI

• Cluster-mesh API Server

  • Shares service and endpoint metadata across clusters to enable multi-cluster load balancing and traffic distribution

• kube-proxy

  • it’s kube-proxy :)
  • cilium can work alongside kube-proxy or replace it entirely

More on eBPF

• Provide the foundation of the datapath. Programs handle connection tracking, NAT, load balancing, and policy enforcement. Maps store shared state between programs and the agent
• eBPF has gained popularity because of its safety and performance. Programs are verified before they are allowed to run in the kernel to ensure that they cannot compromise system stability and then just-in-time (JIT) compiled into native machine code for near-native execution speed.
• Two key concepts to understand:
  • eBPF Programs - User-defined, stateless, event-driven pieces of code that are triggered by specific events within the kernel.
  • eBPF Maps - Serve as internal kernel storage