Cilium, I thought it was an L7 genius… but its real core is elsewhere? 🧐

Aug 14, 2026

—

In the world of Kubernetes networking, Cilium is gaining significant attention for its powerful performance and features based on eBPF technology. In particular, its Layer 7 (Application Layer) capabilities, which allow setting policies based on HTTP request paths (GET /api/v1) or gRPC methods, have played a major role in establishing Cilium as the ‘next-generation CNI’.

However, if you only know “Cilium is an L7 CNI,” you might be missing the most important core. Where does Cilium’s true power come from? Let’s delve into its heart. 🚀

🏛️ Cilium’s Core Datapath: L3 and L4 are the Real Stars

To get straight to the point, Cilium’s core datapath operates directly within the Linux kernel, and its main stage is Layer 3 (Network Layer) and Layer 4 (Transport Layer) of the OSI model.

1. Layer 3 (Network Layer) 🌐: The Fundamentals of All Communication

Role: Responsible for IP address-based routing, which is the most basic aspect of Pod networking.
Cilium’s Role: Cilium assigns IP addresses to each Pod and uses eBPF to efficiently handle Pod communication paths between nodes. It delivers packets directly at the kernel level, without complex iptables rules or the performance degradation of overlay networks. This is the first secret to Cilium’s high speed.

2. Layer 4 (Transport Layer) 🔌: The Heart of Services and Policies

Role: Delivers data to the correct service (process) based on TCP/UDP ports.
Cilium’s Role: Kubernetes’ core functionalities, Service Load Balancing and Network Policy, are implemented at this L4.
kube-proxy Replacement: Cilium completely replaces kube-proxy’s functionality using eBPF. It directly handles the process of converting requests coming to a Service’s ClusterIP and port to the actual Pod’s IP and port, and distributing them at the kernel level, leading to significant performance improvements.
Core Network Policies: Basic network policies such as “Pod A can only communicate with Pod B on port 80” are all handled at the L4 level.

In this way, Cilium completes a fast and efficient network foundation at L3/L4 through eBPF. Most traffic is processed quickly at this stage.

✨ So, what is the true nature of the powerful L7 features?

“Wait, then how do Cilium’s acclaimed L7 policies work?”

That’s a great question. While Cilium’s L7 capabilities are indeed powerful, they are an ‘intelligent extension’ built on top of the L3/L4 datapath. This is because inspecting all traffic at L7 would be inefficient.

Examining Cilium’s operation step-by-step makes it clear.

Packet Arrival: When a packet arrives at a node, the kernel’s eBPF program intercepts it first.
L3/L4 Inspection (eBPF): eBPF quickly checks the packet’s source/destination IP (L3) and port (L4) to determine if it matches network policies.
Decision Point:

No L7 Policy ✅: If there is no L7 policy to apply to the traffic, eBPF performs an ALLOW or DENY action directly at the kernel level and finishes. Very fast!
L7 Policy Exists ➡️: If an L7 policy exists, such as “only allow GET /public for traffic coming in on port 80,” eBPF sends that traffic to an Envoy proxy running in user space.

L7 Inspection (Envoy Proxy): The Envoy proxy analyzes the received traffic’s HTTP headers, path, method, etc., in detail to decide whether to allow or block it according to the policy.

In other words, Cilium uses an efficient hybrid model that selectively sends traffic to the L7 proxy for processing only when necessary. It captures both the speed of L3/L4 and the depth of L7!

📜 L4 and L7 Policy Relationship in Code

The CiliumNetworkPolicy example below clearly illustrates this structure.

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: api-access-policy
spec:
  endpointSelector:
    matchLabels:
      app: my-api
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: frontend
    # ⬇️ L4 Policy: First, allow TCP traffic coming in on port 80.
    toPorts:
    - ports:
      - port: "80"
        protocol: TCP
      # ⬇️ L7 Policy: For traffic matching the above L4 rule, additionally apply HTTP rules.
      rules:
        http:
        - method: "GET"
          path: "/public/.*"
        - method: "POST"
          path: "/data"

As you can see, L7 rules (rules.http) are defined within L4 rules (toPorts). This is intuitive evidence that L7 policies operate as an extension within the larger framework of L4.

❌ Why the Misconception “Cilium is an L7 CNI” is Dangerous

If Cilium is understood purely as an L7 solution, the following misunderstandings can arise:

Performance Misconception: You might mistakenly think that all traffic passes through a proxy, leading to concerns about performance degradation. However, in reality, most traffic is processed quickly in the kernel.
Inefficient Policy Design: You might create unnecessarily complex L7 policies for traffic that could be simply blocked at L4. It’s best to start with L4 as the baseline.
Difficulty in Troubleshooting: When communication issues occur, you might only look at the L7 proxy (Envoy). However, it’s easy to overlook that the root cause might be in the basic L3/L4 routing or port policies.

🎯 Conclusion: See the Whole Picture to Understand the Truth

Cilium’s true strength isn’t just in its excellent L7 capabilities.

A hybrid architecture that leverages a high-speed L3/L4 datapath powered by eBPF, intelligently integrating L7 visibility and control capabilities as needed.

This is the key to understanding Cilium. It’s like a well-designed building, with sophisticated features (L7) built upon a strong foundation (L3/L4). Now, when you look at Cilium, please remember the crucial role of its powerful underlying L3 and L4! ✨