Architecture (20%)

Notes on Cilium’s architecture: eBPF-based dataplane, control plane components (cilium-agent, cilium-operator, Envoy), CNI integration, and how Cilium replaces kube-proxy.

Directory map

• Cilium is not just a CNI, it also provides security and observability (via hubble)
• Cilium is based-on and powered-by eBPF
  • eBPF allows us to run sandboxed programs within the kernel’s address space
  • pretty much all features within Cilium utilize eBPF in some way

Service Mesh

• service meshes provide resilient connectivity
• layer 7 traffic management (load balancing, rate limiting, etc.)
• identity-based security
• observability and tracing
• transparency

Sidecar Architecutre

• the sidecar (envoy proxy) contains all of the service-mesh features and is attached to the main container in the pod
• all ingress/egress traffic goes through the proxy
• the sidecar model has higher resource usage because every application pod requires a sidecar container
• you can run into race conditions when sidecar containers are starting up or shutting down
• sidecar containers add latency

Sidecarless model

• No sidecar container!
• eBPF programs handle L3/L4 traffic and envoy proxy (one per node) handles L7 traffic

Terminology

• Endpoint: any and every pod gets an endpoint in the endpointslice
  • Every endpoint gets a unique ID from cilium
  • You can view all the endpoints on a node by exec’ing into an agent pod:
    • k exec <cilium pod name> -n kube-system -- cilium endpoint list
• Policies:
  • policies are applied to identities and identities are based on labels

Commands to know for the exam

• cilium config view - shows the cilium config
• cilium- config set debug true - enable debug logging