Cilium Certified Associate key terms

A Linux kernel technology that runs sandboxed programs in response to events such as packet arrival or system calls, without changing kernel source or loading modules. Cilium uses it to implement networking, security, and observability.

The per-node daemon, usually run as a DaemonSet, that programs eBPF datapath state, watches Kubernetes resources, and enforces policy for local endpoints. It exposes an API and health endpoints for troubleshooting.

A cluster-wide component that handles tasks which must not run per node, such as IP address management allocation, garbage collection of resources, and syncing state to the KV store or Kubernetes API.

A local workload identity in Cilium, typically a pod network namespace, tracked by the agent with a numeric endpoint ID, security identity, and datapath configuration used for policy enforcement and visibility.

A numeric label bundle assigned to endpoints that share the same relevant labels. Policy rules select identities rather than IP addresses, so enforcement survives pod restarts and IP churn.

Kernel data structures shared between eBPF programs and user space. Cilium stores forwarding tables, policy verdicts, connection tracking entries, and metrics in maps that the agent updates.

Express Data Path, an eBPF hook that runs programs at the earliest point of packet reception in the driver, before socket buffers are allocated. Cilium can use it for fast load balancing and DDoS mitigation.

A Cilium mode where the agent implements Kubernetes Service load balancing in eBPF instead of iptables or IPVS, removing kube-proxy from the datapath and improving scale and latency.

A load-balancing mode where reply traffic from a backend bypasses the load balancer, reducing hops. Cilium supports it for NodePort and LoadBalancer services in eBPF datapath.

A consistent hashing algorithm used by Cilium for service backend selection. It gives stable distribution when backends change and is more even than simple modulo hashing.

IP address management: how pod IPs are allocated and released. Cilium offers cluster-pool, Kubernetes host-scope, and multi-pool modes, with allocation coordinated by the operator.

A custom resource representing a node's networking state, including its pod CIDR allocation, health addresses, and IPAM pool assignments. The agent and operator coordinate through it.

The block of IP addresses from which pods on a given node are assigned addresses. Correct, non-overlapping per-node blocks are essential for routing and for Cluster Mesh.

A datapath mode where pod packets are routed by the underlying network or host routing table without encapsulation. It requires the network to know how to reach pod CIDRs.

A datapath mode where Cilium encapsulates pod traffic between nodes, commonly with VXLAN or Geneve, so the underlay only needs to route node IPs. It works on networks unaware of pod CIDRs.

A native routing variant where a node forwards pod traffic directly to the node hosting the destination pod, using the underlay to deliver it, often with BGP-advertised pod routes.

A Cilium feature that advertises pod CIDRs, service virtual IPs, or node addresses to routers using BGP, integrating the cluster with existing network routing infrastructure.

Maximum transmission unit, the largest packet size a link carries. Encapsulation adds headers, so Cilium must lower pod interface MTU or traffic will fragment or drop silently.

A Cilium custom resource that extends Kubernetes NetworkPolicy with layer 3 to layer 7 rules, including DNS names, HTTP methods and paths, Kafka topics, and entity selectors.

A cluster-scoped policy resource that applies across namespaces and can select nodes as well as pods. Useful for baseline rules that no single namespace should be able to weaken.

Controls whether policy is applied always, never, or only when a policy selects an endpoint. Default mode means an endpoint without any selecting policy allows all traffic.

A posture where traffic is blocked unless explicitly allowed. In Cilium, an endpoint becomes default-deny for a direction as soon as any policy selects it for that direction.

Rules that inspect application protocol details, such as HTTP method and path or DNS query name, rather than only addresses and ports. Cilium enforces these through a per-pod proxy.

A rule that allows egress to names matching a pattern, such as a wildcard domain, by learning the resolved IPs and permitting only those addresses for a limited time.

A Cilium feature that enforces policy on node-level traffic, restricting which remote nodes or CIDRs may reach host services, complementing pod-level policy enforcement.

Cilium's observability layer, built on eBPF, that records flow events with identity, verdict, and protocol details. It exposes a CLI, a gRPC API, and a web UI.

A recorded observation of a network connection or packet decision, including source and destination identities, direction, verdict, and whether policy allowed or dropped it.

The outcome of evaluating a packet against policy: allowed, denied, or forwarded without a matching rule. Hubble surfaces verdicts to explain why traffic succeeded or failed.

Cilium agents and the operator expose counters and histograms for datapath events, policy drops, API operations, and endpoint health, scraped for alerting and dashboards.

A Cilium feature connecting multiple Kubernetes clusters so pods can reach services and pods across clusters using global services and shared identities, with optional cross-cluster policy.

A Kubernetes Service annotated to be recognized across a Cluster Mesh, so backends in every connected cluster are load balanced and failover works between clusters.

A unique numeric identifier assigned to each cluster in a mesh. It namespaces security identities so identical label sets in different clusters remain distinct.

A Cluster Mesh setting that prefers backends in the local cluster for a global service, falling back to remote clusters only when local backends are unavailable.

A Kubernetes API family for expressing HTTP and TLS routing through Gateway, HTTPRoute, and related resources. Cilium implements it to provide ingress and service routing.

A Kubernetes resource describing HTTP host and path routing to services. Cilium can satisfy Ingress resources, translating them into its proxy and load-balancing configuration.

A proxy that Cilium embeds for layer 7 processing, including HTTP-aware policy enforcement, ingress and Gateway API traffic, and service mesh features such as mutual TLS.

A service mesh mode where both sides of a connection present certificates, giving workload-to-workload encryption and identity verification. Cilium manages certificates and rotation automatically.

A Cilium capability that announces service external IPs to the network, either via ARP or NDP on the local segment or via BGP, so clients outside the cluster can reach the service.

State kept for active flows so return traffic and established connections are handled consistently. Cilium maintains it in BPF maps and exposes it through CLI commands for debugging.

Configuration inputs for installing Cilium, covering datapath mode, IPAM, kube-proxy replacement, Hubble, and policy settings. Correct values at install time determine cluster behavior.