TL;DR: Kubernetes gives you service discovery and load balancing at layer 4 and stops there. A mesh adds commonly managed capabilities above the core Service abstraction: identity-based mTLS between workloads, per-request traffic control, and uniform telemetry without touching application code. It is worth it when you need those across many teams, and may be unnecessary when a small team can meet those requirements through existing libraries and certificate automation.
How to approach it
Name what Kubernetes already does before naming what the mesh adds, because the gap is the answer. Then make the adoption call yourself. Use an actual requirement to choose the smallest supported design.
A strong answer
Kubernetes already does service discovery through DNS and Services, and it load balances across endpoints. What it does not do is care about anything above the connection. kube-proxy picks an endpoint per connection, not per request, so a long-lived HTTP/2 or gRPC connection pins to one pod and your traffic distribution quietly becomes wrong. Kubernetes provides service-account identity, but does not automatically turn it into mutual TLS for application connections. NetworkPolicy selects pods and namespaces through labels and also supports IP blocks; it does not authenticate application peers using certificates. And there is no consistent telemetry unless every team instruments their service the same way, which they will not.
A mesh addresses exactly those three. Identity comes from a per-workload certificate rather than an IP, which is what makes mTLS meaningful: the policy says "the checkout service may call the payments service", not "10.4.2.0/24 may reach 10.4.9.0/24". Traffic management moves to layer 7, so you get per-request routing, retries with budgets, timeouts, circuit breaking, and the traffic splitting that real canary analysis needs. Telemetry becomes uniform because the proxy emits the same golden signals for every service regardless of language.
The operating cost also matters. The cost is a proxy in the request path of every call, which adds implementation- and workload-dependent latency and memory overhead, plus a control plane you now operate and upgrade. More importantly it adds a failure mode: when the mesh misbehaves the symptom is that everything is slightly broken, and debugging that requires understanding both your service and Envoy.
So my rule: for a small service estate with consistent client libraries, a shared client library gets you retries and timeouts for a fraction of the operational cost. Adopt a mesh when you have enough teams that you cannot make them all adopt a library, when you need mTLS for a compliance requirement you can name, or when progressive delivery on real traffic percentages has become a business need. Ambient mode changes the arithmetic by removing the per-pod sidecar for layer 4 work, and it is a reasonable answer to "the cost is too high" in 2026.
Adoption exercise: encrypted traffic, missing authorization
A fictional platform enables mesh mTLS and confirms that connections are encrypted. A compromised reporting workload can still call the payment administration endpoint because policy allows every authenticated workload. Encryption and peer identity have succeeded; authorization remains too broad. Define allowed service relationships and test both permitted and forbidden calls before describing the system as protected.
Pilot the mesh on one representative request path. Compare latency, connection reuse and memory with the existing path, then rehearse certificate rotation and control-plane unavailability. Establish whether existing data-plane configuration continues serving and which new changes cannot propagate. Include debugging access for responders without granting applications broad privileges.
If the requirement is only gRPC distribution, compare client-side load balancing or a focused L7 proxy as alternatives. If uniform workload identity and policy across many teams are also required, the operational investment may be justified. Record which requirement each component satisfies instead of using service count alone as the adoption threshold.
What interviewers probe next
"Why does gRPC load balance badly without one?" Because kube-proxy balances connections and gRPC multiplexes many requests over one long-lived connection. An L7-aware mesh can balance requests; client-side gRPC balancing or another L7 proxy can also solve this, depending on configuration.
"Could you get mTLS without a mesh?" Yes, with SPIFFE identities and application-level TLS. Cilium mutual authentication authenticates identities but does not itself encrypt application traffic; transparent WireGuard/IPsec encryption is a separate feature and is not identical to application mTLS. Cilium mutual authentication.
"What breaks first at scale?" The control plane's config distribution. Every proxy holds config for everything it might talk to, so memory grows with cluster size unless you scope it deliberately.
Common mistakes
Listing features (retries, timeouts, mTLS, observability) with no account of what Kubernetes already provides. The feature list is public and settles nothing; the gap between what a mesh provides and what your platform already provides is the decision.
Recommending adoption unconditionally. Include the control-plane and data-plane upgrade path, with compatibility and recovery checks.
Claiming a mesh gives you zero trust. It gives you the transport half. Authorization policy and workload identity governance are separate work.