MeshWorld India Logo MeshWorld.
ebpf cilium kubernetes networking security 3 min read

eBPF & Cilium Kubernetes Networking Cheatsheet: The Complete Reference

Jena
By Jena
eBPF & Cilium Kubernetes Networking Cheatsheet: The Complete Reference

Kubernetes default IP tables-based network configurations scale poorly in dense container workloads. By leveraging eBPF (Extended Berkeley Packet Filter), Cilium bypasses the Linux kernel’s heavy networking stack, attaching sandbox programs directly to socket layers to achieve high-performance service routing, deep L7 HTTP-aware security policies, and real-time packet visibility.

This reference sheet covers core CLI operations, Cilium network policies, Hubble network inspection, and multi-cluster routing.


- **eBPF Bypass**: Route packets directly at socket layers, eliminating slow iptables evaluation overheads. - **Network Policies**: Implement strict security isolation rules from standard IP layers up to HTTP L7 endpoints. - **Hubble Inspection**: Track flows, dependencies, and network anomalies directly using CLI commands. - **ClusterMesh**: Unify networking across physically separate Kubernetes clusters to enable cross-region calls.

Before diving into this cheatsheet, check out my previous deep-dive on Nginx Cheat Sheet: Routing, SSL & Performance Guide to see how we structured these patterns in practice.

Core Cilium CLI Operations

Inspect and verify the state of Cilium daemons and system-level packet routes using the official command line tool.

# 1. Inspect cluster status and verify all components are running
cilium status

# 2. Execute a rigorous, comprehensive connectivity diagnostic test suite
# Validates pod-to-pod, pod-to-node, and egress internet pathways
cilium connectivity test

# 3. List active endpoints and their associated security IDs
cilium endpoint list

# 4. View raw eBPF routing tables inside the active agent
cilium bpf ipcache list

Designing Cilium Network Policies

Cilium extends standard Kubernetes NetworkPolicies, supporting advanced L3 (CIDR/Labels), L4 (TCP/UDP), and L7 (HTTP/gRPC/Kafka) application-aware security rules.

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: secure-frontend-to-backend
  namespace: production
spec:
  # Apply this policy to pods matching this label
  endpointSelector:
    matchLabels:
      app: backend-service
  ingress:
    # 1. L3 Control: Only accept connections from the frontend pods
    - fromEndpoints:
        - matchLabels:
            app: frontend-gateway
      # 2. L4 Control: Restrict connections strictly to TCP port 8080
      toPorts:
        - ports:
            - port: "8080"
              protocol: TCP
          # 3. L7 Control: Allow only specific HTTP endpoints
          rules:
            http:
              - method: "GET"
                path: "/api/v1/health"
              - method: "POST"
                path: "/api/v1/orders"

Network Inspection with Hubble

Hubble is the distributed observability platform built on top of Cilium. It captures network flow data points dynamically without modifying container images.

# 1. Enable and inspect Hubble visibility status
hubble status

# 2. Stream real-time network flows in the default namespace
hubble observe

# 3. Filter flows targeting a specific destination pod
hubble observe --destination pod-name --namespace production

# 4. Observe only dropped or rejected network packets (ideal for debugging firewall rules)
hubble observe --type drop --follow

# 5. Output flows showing L7 HTTP path attributes and return codes
hubble observe --http-path /api/v1/orders -o json

Multi-Cluster Networking with ClusterMesh

ClusterMesh allows you to link separate Kubernetes clusters together. This enables cross-cluster service routing with minimal latency.

1. Enable ClusterMesh CLI

# Initialize ClusterMesh on Cluster A
cilium clustermesh enable --context context-cluster-a

# Initialize ClusterMesh on Cluster B
cilium clustermesh enable --context context-cluster-b

# Connect the clusters
cilium clustermesh connect --context context-cluster-a --destination-context context-cluster-b

2. Configure Global Services

Create a unified service across both clusters by adding the global-service annotation. This automatically load-balances requests across all active endpoints in both locations.

apiVersion: v1
kind: Service
metadata:
  name: global-db-service
  namespace: production
  annotations:
    # Instructs Cilium to load-balance across all connected clusters
    io.cilium/global-service: "true"
    # Fallback to local endpoints if the remote cluster is down
    io.cilium/shared-service: "true"
spec:
  ports:
    - port: 5432
      targetPort: 5432
  selector:
    app: postgres-database