The world of Kubernetes networking can sometimes be confusing. What’s a CNI? A service mesh? Do I need one? Both? And how do they interact in my cluster? The questions can go on and on.

Even for seasoned platform engineers, making sense of where these two components overlap and where the boundaries of responsibility end can be challenging. Seemingly bewildering obstacles can stand in the way of getting the most out of their complementary features.

One way to cut through the confusion is to start by defining what each of them is, then look at their respective capabilities, and finally clarify where they intersect and how they can work together.

This post will clarify:

• What a CNI is responsible for
• What a service mesh adds on top
• When you need one, the other, or both

What a CNI Actually Does

Container Network Interface (CNI) is a standard way to connect and manage networking for containers in Kubernetes. It is a set of standards defined by Kubernetes for configuring container network interfaces and maintaining connectivity between pods in a dynamic environment where network peers are constantly being created and destroyed.

Those standards are implemented by CNI plugins. A CNI plugin is the concrete networking component that runs in your cluster and performs the actual networking tasks defined by the CNI specification. Calico is an example of a CNI plugin, implementing the CNI specification to deliver connectivity and policy enforcement for Kubernetes clusters.

At a high level, a CNI plugin:

• Connects pods to the network
• Assigns IP addresses
• Routes traffic between pods and nodes
• Enforces Kubernetes NetworkPolicy

All of this happens at the network and transport layers (L3/L4). The CNI doesn’t understand applications, it just ensures packets get from point A to point B efficiently and securely.

Think of the CNI as the foundation of cluster networking. Without it, nothing else works.

The CNI’s Core Responsibilities (and Their Limits)

Because the CNI operates at the network layer, its responsibilities are intentionally limited to infrastructure-level connectivity and security. A CNI plugin like Calico ensures reliable pod-to-pod communication, IP address management, and enforcement of Kubernetes NetworkPolicy across nodes.

This focus on L3/L4 networking is deliberate: it allows the CNI to provide high-performance, kernel-level enforcement without needing awareness of application behaviour or request context.

What a CNI Does Not Do

A CNI’s job is not to manage application behaviour or inspect traffic contents. Because a CNI operates below the application layer, there are things it deliberately doesn’t handle:

• Encrypting traffic based on application identity
• Inspecting HTTP requests or gRPC calls
• Making routing decisions based on headers or paths
• Providing distributed tracing or request-level metrics

When you need visibility or control inside the request itself, you’ve moved beyond the CNI’s scope. It is here where a service mesh’s capabilities might be of use.

What is a Service Mesh

A Service Mesh manages how services communicate within a Kubernetes cluster at the application layer (L4/L7). It’s an infrastructure layer that simplifies service-to-service communication by handling traffic management, security, and observability outside the application code. It does this through intelligent proxies alongside each service, creating a secure, controllable network fabric across the cluster.

What a Service Mesh Adds

A service mesh focuses on how applications talk to each other, not just whether they can. Since it operates at L4/L7, it introduces application-aware capabilities such as:

• Mutual TLS (mTLS) and workload identity
• Fine-grained authorization based on request attributes
• Advanced traffic management (canaries, retries, circuit breakers)
• Deep observability, including request latency and tracing

A service mesh does this by inserting intelligent proxies into the traffic path, creating a controlled, secure communication layer between services.

Where CNI and Service Mesh Overlap

A CNI and a service mesh both influence how traffic moves through a Kubernetes cluster, which is why their responsibilities can sometimes appear to overlap. Both play a role in traffic handling, security enforcement, and observability, but they operate at different layers of the stack and with different levels of context.

Overlapping responsibilities can cause confusion and conflict

The CNI is a mandatory component of cluster networking and operates at the network and transport layers (L3/L4). It is responsible for establishing connectivity, routing packets, and enforcing infrastructure-level network policy across pods and nodes.

A service mesh builds on top of this foundation and operates at the transport and application layers (L4/L7). At this level, it can understand service identity and request context, enabling application-aware security controls, traffic management, and detailed visibility into service-to-service communication.

The service mesh takes over where the CNI’s domain ends

Rather than competing, the two complement each other. The CNI provides reliable, high-performance connectivity at the infrastructure layer, while the service mesh takes over where application-level control, security, and observability are required.

In short:

• CNI provides connectivity and policy enforcement at the infrastructure layer.
• Service mesh provides control, security, and insight at the application layer.

So When Do You Need a Service Mesh?

A Kubernetes cluster will run just fine without a service mesh, and introducing one is not always the right answer. A service mesh becomes worth considering when you need stronger, application-aware security or the operational stability that comes from advanced traffic control and error handling.

The table below outlines common requirements and whether a service mesh is typically the right fit.

Requirement	When Needed	Deploy a service mesh?
Security	You require mandatory, cluster-wide zero-trust mTLS and identity-based L7 authorization between every service.	YES
Traffic Control	You require fine-grained L7 control over traffic: weighted splits (Canary deployments), request header matching, circuit breakers, or fault injection.	YES
Observability	You need deep, standardized distributed tracing across your microservice calls and require service-level request latency metrics.	YES
Connectivity/Policy	You only need basic pod-to-pod communication and L3/L4 NetworkPolicy enforcement (e.g., blocking traffic from namespace A to port 80 in namespace B). Calico handles this.	NO
Service discovery and communication	If your goal is simply to connect services across clusters, basic CNI networking provides connectivity and observability with minimal overhead.	NO

A Layered Model: Outer Perimeter and Inner Core

A useful way to think about this is layering:

• The CNI secures the outer perimeter of the cluster using kernel-level enforcement
• The service mesh secures the inner core, validating application identity and intent

Together, this layered approach ensures that security principles are enforced at every level of the stack, maximizing security integrity.

Calico and Istio: A Combined Approach

Calico’s unified platform includes Istio service mesh, supporting both traditional sidecar mode and ambient mode. With Istio ambient mode on top of Calico:

• All pod-to-pod traffic is encrypted with mTLS
• Selected services gain advanced L7 traffic control via waypoint proxies
• Metrics, logs, and traces are collected without requiring sidecars everywhere

This approach delivers service mesh benefits while reducing operational complexity and resource overhead.

Istio service mesh in ambient mode running on top of Calico CNI

One Last Thing: Complexity and Tradeoffs

A key factor in deciding whether to deploy a service mesh is determining if there is added complexity and any resource overhead it brings. Service meshes like Istio can be powerful, but they also introduce new configuration, operational effort, and a learning curve that can slow adoption. If you determine that a service mesh is the right choice, using Calico to install and configure Istio in ambient mode by default helps reduce that complexity and lowers the barrier to getting started.

Get Started with Calico and Istio Today

If you’re evaluating whether a service mesh is the right fit for your environment, deeper context can make the decision easier. Calico’s unified platform integrates Istio in ambient mode to reduce operational overhead and simplify adoption.

• For real-world use-cases and outcomes you can expect, check out How Istio Ambient Mode Delivers Real World Solutions — it shows how ambient mode solves common challenges teams face today.
• To understand the technical foundations and architectural choices behind ambient mode with Calico, explore An In-Depth Look at Istio Ambient Mode with Calico.

If you’d like personalized guidance, your team can also reach out for a demo to see how these capabilities apply directly to your stack.