Cilium Sidecarless Service Mesh: eBPF-Powered Networking in 2026

The sidecar model has been the default service mesh architecture since Istio was released in 2017. Every pod gets its own Envoy proxy — iptables rules redirect traffic into user-space proxies, each consuming 50–100 MB of RAM and 0.1–0.5 vCPU. In a 100-pod namespace, that is 5–10 GB of memory and 10–50 vCPU cores dedicated to proxy overhead. The 2024 CNCF survey found that 62% of teams cite resource overhead as their primary service mesh frustration. Cilium eliminates the sidecar entirely by running the data plane in the Linux kernel with eBPF.

What a Service Mesh Actually Does

A service mesh provides five core capabilities transparent to application code: resilient connectivity between services (load balancing, retries, circuit breaking), L7 traffic management (HTTP routing, header manipulation, traffic splitting), identity-based security (mutual TLS, policy enforcement), observability (flow logs, metrics, service maps), and transparency — no code changes in application containers. Cilium delivers all five without a per-pod proxy.

The Sidecar Model in Context

In the classic sidecar model (Istio classic), a request from a client pod to a server pod passes through two Envoy proxies:

Client Pod           Server Pod
+--------------+    +--------------+
| App → Envoy  |    | Envoy → App  |
+------+-------+    +------+-------+
       |                   |
       +─────→Kernel───────+
             (iptables redirects)

Each request incurs two extra user-space hops. The iptables rules that redirect traffic into the sidecar add latency and operational complexity. Sidecar restarts during rollouts cause connection drops. The resource cost scales linearly with pod count.

Enter eBPF: Kernel-Level Programmability

eBPF (extended Berkeley Packet Filter) allows sandboxed programs to run inside the Linux kernel without changing kernel source or loading kernel modules. The eBPF verifier ensures programs are safe — no infinite loops, no unsafe memory access. Cilium uses eBPF for service routing and load balancing (direct server return, Maglev consistent hashing, NAT46/64), network policy enforcement at L3/L4, WireGuard-based encryption, flow metadata export to Hubble, and cryptographic pod identity management via BPF maps.

The kernel requirement matters: Cilium needs Linux 4.9+ for minimal support, 5.10+ for production, and 6.1+ for the full feature set. Older enterprise Kubernetes clusters on RHEL 8 (kernel 4.18) or equivalent cannot run Cilium natively.

Cilium’s Sidecarless Architecture

Data Plane

Cilium moves L3/L4 processing — routing, load balancing, policy enforcement, and encryption — into the Linux kernel via eBPF programs attached to XDP, TC, and cgroup hooks. There are zero extra user-space hops for these operations. Pod identity (a cryptographic hash of the pod’s label set) is attached to every packet via BPF maps, so policy decisions happen at kernel speed without context switches.

Client Pod           Server Pod
+----------+        +----------+
|   App    |        |   App    |
+----+-----+        +----^-----+
     |                    |
     +─────→eBPF in──────+
             Kernel
       (identity-based routing,
        policy enforcement,
        load balancing)

For L7 traffic (HTTP, gRPC, WebSocket), Cilium deploys a shared Envoy proxy per node — not per pod. This is the critical architectural difference from the sidecar model; when an L7 policy matches, eBPF programs transparently redirect traffic to the per-node Envoy, which handles HTTP method/header/path inspection, then returns the decision to the kernel for enforcement.

Control Plane

Cilium’s control plane has four components:

Component	Deployment	Role
Cilium Agent	DaemonSet (one per node)	Manages eBPF programs, Envoy config, identity allocation, policy computation
Cilium Operator	Deployment (1–2 replicas)	CIDR allocation, CRD management, Cluster Mesh orchestration
Hubble	DaemonSet + Deployment	Flow monitoring, Relay for cluster-wide view, UI for service dependency maps
Envoy	Embedded in Cilium Agent or standalone DaemonSet	L7 proxy for HTTP/gRPC policy, Gateway API, Ingress

The Cilium agent on each node watches the Kubernetes API server for pod, service, endpoint, and policy changes. It compiles these observations into eBPF programs and BPF maps, then loads them into the kernel. Policy updates propagate in milliseconds — not seconds.

L7 Traffic Management with Gateway API

Cilium supports Gateway API v1.6.1 with all core conformance tests passing: GatewayClass, Gateway, HTTPRoute, GRPCRoute, TLSRoute, TCPRoute, UDPRoute, BackendTLSPolicy, and ReferenceGrant. It also supports GAMMA (Gateway API for Mesh Management and Administration), which enables east-west L7 traffic management for internal service-to-service communication.

The following example creates a Gateway and HTTPRoute for east-west traffic between two services:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: internal-gateway
spec:
  gatewayClassName: cilium
  listeners:
  - name: http
    protocol: HTTP
    port: 80
    allowedRoutes:
      namespaces:
        from: Same
---
apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: api-route
spec:
  parentRefs:
  - name: internal-gateway
  rules:
  - matches:
    - path:
        type: PathPrefix
        value: /api/v2
    backendRefs:
    - name: api-service
      port: 8080

Under the hood, the Cilium Operator watches Gateway API resources, validates them, and translates them into CiliumEnvoyConfig (CEC) resources. The Cilium Agent picks up the CEC and programs the per-node Envoy. This indirection matters when debugging — CECs have minimal validation and no conflict resolution, so misconfigured routing rules require direct Envoy config inspection.

Network Policy at L3/L4 and L7

CiliumNetworkPolicy enforces identity-based rules at the kernel level. Labels, not IPs, identify endpoints — this makes policies resilient to pod churn and rescheduling.

apiVersion: "cilium.io/v2"
kind: CiliumNetworkPolicy
metadata:
  name: api-l7-policy
spec:
  endpointSelector:
    matchLabels:
      app: my-api
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: frontend
    toPorts:
    - ports:
      - port: "8080"
        protocol: TCP
      rules:
        http:
        - method: "GET"
          path: "/public"

This policy selects pods with app: my-api, allows ingress only from app: frontend pods, and at L7 only permits GET /public requests — all other HTTP methods and paths are denied. Adding an L7 rule automatically enables default-deny for that port. To observe L7 traffic without filtering, use an empty HTTP rule: http: [{}].

Security: Mutual Authentication and Encryption

Cilium’s security model operates at two layers with different maturity levels.

WireGuard encryption (stable): Node-level wire encryption encrypts all traffic between Cilium-managed nodes. This is production-ready and independent of the service mesh mTLS feature.

Mutual Authentication / mTLS (beta as of Cilium 1.20 / July 2026): Cilium’s mTLS implementation uses SPIFFE/SPIRE for workload identity. Per-node SPIRE agents attest workloads and issue SVIDs; Cilium agents perform an out-of-band mTLS handshake using an auth cache. The mTLS roadmap is candid about what remains:

Feature	Status
SPIFFE/SPIRE integration	Beta
Authentication API	Beta
mTLS handshake between agents	Beta
Policy support	Beta
WireGuard integration	TODO
Per-connection handshake	TODO
Penetration testing	TODO
Stable maturity review	TODO

For teams requiring audited, penetration-tested mTLS in production, Istio’s sidecar or Ambient mode remains the safer choice in mid-2026. Cilium’s mTLS is usable for evaluation and less-critical paths, but the roadmap has several security-critical items still marked as TODO.

Hubble Observability

Hubble provides automatic flow visibility without instrumentation or sidecars. The eBPF data plane exports flow metadata — L3/L4 flows (who talked to whom, on which port, when) and L7 flows (HTTP method, path, status code, latency) — directly from the kernel.

# Observe all flows for a specific pod
hubble observe --pod default/my-pod

# Observe L7 HTTP flows only
hubble observe --pod default/my-pod --type l7

# Observe flows between two namespaces
hubble observe --from-namespace frontend --to-namespace backend

Hubble Relay aggregates data across nodes for cluster-wide queries. Hubble UI renders a visual service dependency graph showing real-time traffic patterns. Metrics export to Prometheus for integration with existing dashboards.

Practical Installation

Install Cilium with service mesh features via Helm:

helm upgrade cilium cilium/cilium --version 1.20.0 \
  --namespace kube-system \
  --reuse-values \
  --set kubeProxyReplacement=true \
  --set ingressController.enabled=true \
  --set ingressController.loadbalancerMode=dedicated \
  --set envoyConfig.enabled=true \
  --set loadBalancer.l7.backend=envoy

Enable Hubble Relay and UI for observability:

helm upgrade cilium cilium/cilium --version 1.20.0 \
  --namespace kube-system --reuse-values \
  --set hubble.relay.enabled=true \
  --set hubble.ui.enabled=true

For mutual authentication (beta), install SPIRE alongside Cilium:

cilium install --version 1.20.0 \
  --set authentication.mutual.spire.enabled=true \
  --set authentication.mutual.spire.install.enabled=true

Cilium vs Sidecar-Based Meshes

Dimension	Cilium (sidecarless)	Istio Classic (sidecar)	Istio Ambient
L3/L4 data path	In-kernel eBPF	iptables → user-space Envoy	Per-node ztunnel
Extra latency	~0–1 ms L3/L4, ~1–2 ms L7	~2–5 ms per hop	~1–3 ms L4, ~2–5 ms L7
Memory per node	~100–200 MB total	~50–100 MB × N pods	~50 MB ztunnel + waypoints
mTLS maturity	Beta (SPIFFE/SPIRE)	Stable	Stable
Kernel requirement	Linux 5.10+, 6.1+ recommended	None	None
Pod isolation	Shared Envoy per node	Per-pod Envoy (isolated)	Shared ztunnel + optional isolated Envoy

Trade-Offs and Limitations

Cilium’s sidecarless approach has genuine operational limitations that teams should evaluate before adoption.

Beta mTLS. For production environments requiring mature, penetration-tested mutual TLS, Istio remains the safer choice. Cilium’s mTLS roadmap lists penetration testing, per-connection handshake, and stable maturity review as TODO.

Shared Envoy isolation. A single per-node Envoy handles L7 traffic for all pods on that node. A misconfigured CiliumEnvoyConfig for one service can affect traffic for other services on the same node. In the sidecar model, an Envoy crash or misconfiguration affects only one pod.

CiliumEnvoyConfig fragility. The CEC CRD has minimal validation, no defined conflict resolution, and no rich error feedback. The official docs warn that CEC resources “should be treated as cluster admin resources.” Troubleshooting requires direct Envoy config and log inspection.

Kernel version dependency. Cilium requires Linux 5.10+ for production. Teams running older enterprise Kubernetes distributions (RHEL 8 with kernel 4.18) cannot adopt Cilium without upgrading nodes. Sidecar-based meshes work on any kernel.

Cluster Mesh + mTLS incompatibility. Per the Cilium 1.20 documentation, clusters connected in a Cluster Mesh cannot use Mutual Authentication. There is no single trust domain across clusters for combining Cluster Mesh and Service Mesh.

Third-party integration. Cilium’s Gateway API and Ingress implementations are Cilium-specific. Unlike Istio, which uses standard Envoy xDS APIs that work with many ecosystem tools, Cilium’s Envoy integration uses custom CiliumEnvoyConfig resources.

Migration Considerations

From bare Kubernetes (no existing mesh): Cilium can be installed alongside existing CNI setups with care. New clusters should just install Cilium with the right Helm flags. Zero code changes to applications — Cilium’s traffic interception is transparent to pod code.

From Istio sidecars: Istio and Cilium cannot run side by side as competing meshes on the same workloads. The recommended strategy is to deploy Cilium as CNI alongside Istio (they can coexist at the CNI level with proper configuration), then migrate workloads one namespace at a time. CiliumNetworkPolicy replaces Istio AuthorizationPolicy — policies must be re-created. If you rely on Istio’s stable mTLS, wait until Cilium’s mutual authentication reaches stable before migrating those workloads. Finally, disable Istio injection and restart pods to remove sidecars.

Conclusions for 2026

Cilium is the default CNI on GKE, EKS, and AKS in 2026, and its service mesh capabilities are mature enough for L3/L4 use cases and L7 traffic management in production — as long as you can work within the mTLS and isolation constraints. For new Kubernetes clusters where the kernel requirement is met and mTLS is not an immediate production requirement, Cilium’s sidecarless approach offers lower latency, lower resource consumption, and simpler operations than sidecar-based alternatives.

eBPF skills are becoming increasingly valuable as Cilium and similar projects (Falco, Pixie, Katran) build on the same foundation. The engineers who understand kernel-level networking will be the platform engineers who design the next generation of cloud infrastructure.

Cilium v1.20.0 was released on 2026-07-29. Feature maturity and kernel requirements are based on this release. For updated guidance, check the official Cilium documentation. Sources: Cilium Service Mesh Overview, Gateway API Support, L7 Traffic Management, Mutual Authentication, Hubble, CiliumNetworkPolicy, eBPF.io, GitHub: cilium/cilium, Gateway API Implementations, mTLS Design CFP, mTLS Roadmap.