What a service mesh solves
the purpose of a mesh.
it adds traffic management, security via mTLS, and observability at the network layer through sidecars, beyond what plain Kubernetes offers.
What's really being asked
A clear mental model of why teams add a mesh on top of Kubernetes. The interviewer wants the three problem areas and an understanding that Kubernetes itself stops at basic connectivity.
The full answer
A service mesh is a dedicated infrastructure layer for managing communication between services. It is typically implemented as lightweight proxies deployed beside each workload, coordinated by a central control plane. The three problem areas are: traffic management, meaning fine-grained routing, weighted splits, retries, timeouts and canary releases; security, meaning automatic mutual TLS so traffic between pods is encrypted and authenticated plus identity-based authorization; and observability, meaning consistent golden-signal metrics, distributed tracing context propagation, and access logging across every call. Crucially these are applied without changing application code. Plain Kubernetes provides Services, kube-proxy load balancing and DNS, which solve discovery and basic L4 routing but leave L7 routing, encryption and telemetry to you.
The mistakes people make
Confusing a mesh with an Ingress controller or API gateway, which handle north-south edge traffic rather than east-west service traffic. Claiming Kubernetes already encrypts pod-to-pod traffic; it does not by default. Saying NetworkPolicies provide mTLS; they only allow or deny connections at L3 or L4 and do not encrypt or verify identity.
What usually comes next
What is the cost of a mesh? Added latency per hop, resource overhead from sidecars, and operational complexity. How does the sidecar intercept traffic? Via iptables or eBPF redirection. When is a mesh overkill for a small cluster?
A concrete example
Without a mesh, enabling encryption and per-route retries between a checkout service and a payments service means editing both codebases and managing certificates yourself. With Istio or Linkerd, you deploy sidecars, turn on strict mTLS once, and declare a retry policy in a manifest; both services gain encryption, retries and traces with no code changes.
Interview question
A teammate argues you do not need a service mesh because Kubernetes Services and NetworkPolicies already cover everything. Which capability is genuinely missing without a mesh?
- a.Allowing or denying connections between namespaces
- b.Service discovery and DNS resolution between pods
- c.Basic load balancing across pod replicas
- d.Automatic encrypted, identity-verified service-to-service trafficCorrect
Why? this is the answer
Kubernetes Services give discovery and L4 load balancing, and NetworkPolicies allow or deny connections, but neither encrypts or authenticates traffic. Automatic mutual TLS is a core mesh feature absent from vanilla Kubernetes.
Just read this? Test yourself on what you have been reading.
Read the original → kubernetes.io
- #kubernetes
- #service-mesh
- #istio
- #observability
- #networking
You just looked this up. Could you explain it out loud?
That is the part interviews actually test. Tezvyn takes questions like this one and gives you what the interviewer is really checking, the answer that lands, and the mistake that ends the conversation, in the four minutes before your next meeting.
The iPhone app is on the way
We are building it. Until it lands, nothing here is held back from you: every interview card, your saved cards, streaks and the job board all work in Safari, plus hundreds of free practice quizzes of thirty questions each. Sign in and it all carries over to the app the day it arrives.
Want it as an icon? Tap Share at the bottom of Safari, then Add to Home Screen. It opens full screen and the cards you have read stay available offline.
We are hiring for this. Open roles that interview on kubernetes — each one lists the topics its interview covers.
See open roles