Service Mesh Overhead on Kubernetes: A Measured Benchmark of Istio versus Linkerd against a Meshless Baseline

Service meshes promise mTLS, traffic management and observability for microservices — but every request then passes through extra proxy hops, and nobody's slide deck says what those hops cost in latency, throughput and CPU. This dissertation measures it. On a pinned three-node k3s cluster, the same microservice application — Google's Online Boutique demo, eleven services talking gRPC — is load-tested in three configurations: no mesh, Istio sidecar, and Linkerd, all with mTLS enabled on the meshed runs.

The load comes from k6 in open-model arrival-rate mode at three levels — 25%, 50% and 70% of the baseline's measured capacity — with a 30-minute steady state per run, a discarded warm-up, and five repetitions per configuration. Results are reported as p50/p95/p99 latency per route, throughput, error rate, and per-proxy CPU and memory collected from Prometheus, aggregated as mean ± 95% confidence intervals and compared pairwise with the Mann–Whitney U test, because latency distributions do not owe the t-test normality. Version pinning, node pinning, disabled autoscaling, identical resource requests and a cluster restart between configurations remove the confounders that make most mesh benchmarks anecdotal.

The deliverable is a declared, reproducible protocol plus the harness — manifests, k6 scripts, metric-collection scripts and an analysis notebook — so the next student can rerun the campaign on any cluster. Written for the VTU M.Tech 2022 Project Work Phase-2 (22SXX41), leaning on the Computer Networks & IoT Lab (22SCNL17) and Research Methodology & IPR (22RMI16), it produces a paper-style results section from your own runs.

Platform teams choosing between Istio and Linkerd — or against a mesh entirely — must decide based on what the extra data-plane hop costs their workload. Vendor pages benchmark each product on its own terms, and community posts rarely pin versions, load profiles or pod resources, so their numbers cannot be compared or reproduced. Meanwhile the cost is real: two proxy processes per pod compete with the application for CPU and memory, and every hop adds queueing and TLS work that surfaces in p95 and p99 latencies — the percentiles users actually feel.

The engineering problem is: on one pinned cluster, one pinned application and one declared workload protocol, how much latency, throughput and resource overhead does the Istio sidecar data plane add relative to a meshless baseline, how much does Linkerd add, and are the observed differences statistically distinguishable rather than run-to-run noise? The answer must come from repeated runs with confidence intervals and non-parametric tests, and must be reproducible from the harness alone by any other student.

Abstract

Organisations adopt service meshes for zero-trust security, traffic control and uniform telemetry, while accepting an extra network hop per call. This dissertation quantifies that acceptance on a pinned three-node k3s cluster running the eleven-service Online Boutique application: no mesh versus Istio sidecar versus Linkerd, under identical declared workloads. Five 30-minute runs per configuration at three load levels yield latency percentiles, throughput, error rates and per-proxy resource costs, analysed with non-parametric statistics and reported with confidence intervals.

Introduction

A sidecar mesh intercepts every call between services: the proxy terminates and re-originates connections, applies mTLS, and exports metrics. The cost is architectural arithmetic — two extra loopback traversals and two proxy processes per pod — yet adoption decisions are routinely made from vendor blogs quoting different workloads, different hardware and no variance. An M.Tech-grade answer needs the opposite: one application, one protocol, many repetitions, honest intervals.

Existing System

• Vendor benchmarks (Istio's published performance page among them) report each vendor's own workload on their own hardware — useful as reference points, not as decisions.
• Blog-level comparisons cherry-pick load levels, run once, and rarely state pod resource settings, making results unreproducible.
• Teams therefore adopt or reject meshes on faith, then discover p99 regressions in production.

Literature Gap

• Independent studies exist but are scattered across mesh versions, ingress choices and load profiles; several predate current stable releases entirely.
• Few report resource overhead of the data plane itself (per-proxy CPU/memory) alongside latency, and fewer still state a repetition-and-testing protocol that another student could rerun.
• Gap: a fully declared benchmarking protocol — pinned versions, pinned nodes, open-model load at capacity-referenced levels, five repetitions, warm-up discard, 95% CIs and Mann–Whitney comparisons — for Istio-sidecar and Linkerd against a meshless baseline on the same pinned k3s cluster, with data-plane resource cost as a first-class result.

Proposed Work

• A harness: version-pinned cluster provisioning, application manifests, mesh installation profiles, k6 workload scripts and a metric-collection pipeline into Prometheus.
• A capacity probe to find the baseline's saturation point, fixing the 25/50/70% load levels before any comparison run.
• The campaign: 3 configurations × 3 load levels × 5 runs × 30 minutes, with warm-ups discarded and environment conditions logged.
• Analysis: percentile tables, CI plots, Mann–Whitney U pairwise tests with effect sizes, and a cost model translating measured proxy CPU into per-replica infra cost.
• A robustness section: one perturbed variant (proxy CPU limit halved) to observe throttling behaviour.

Feasibility

Three lab machines or VMs, the free Online Boutique images and open-source meshes keep cost at zero beyond hardware already available. The campaign is scriptable overnight; the real investment is protocol discipline and honest statistics. The full harness ships with this bundle, so a single student can reproduce the campaign inside the 24-week Phase-2 slot with weeks to spare for writing.

In scope

• One application (Online Boutique, eleven gRPC microservices) on one pinned k3s cluster of three nodes, in three configurations: no mesh, Istio sidecar, Linkerd.
• One declared k6 open-model workload walking the purchase path, at three capacity-referenced load levels, five 30-minute repetitions per configuration, with per-proxy CPU/memory captured via Prometheus/cAdvisor.
• Statistical analysis (CIs, Mann–Whitney U, effect sizes), a proxy-cost model, and one perturbed robustness variant (halved proxy CPU limit).

Out of scope

• Istio ambient/waypoint mode and other meshes (Consul, Cilium, Kuma) — noted as extensions.
• Control-plane CPU cost during configuration churn, multi-cluster meshes, and cross-zone topologies.
• Application-level tuning of Online Boutique itself; comparison of ingress gateways; WebAssembly plugins.
• Chaos, fault-injection and security-penetration testing; TLS handshake benchmarking in isolation.
• Production-scale clusters: three nodes bound the absolute numbers, though the protocol transfers unchanged.

The research design is a controlled repeated-measures benchmark experiment: the same application and workload are observed under three data-plane configurations, with configuration order and environment controlled and variability quantified rather than ignored. The protocol below is declared before the campaign, in the discipline of the Research Methodology & IPR course (22RMI16).

Declared protocol. (1) Environment: k3s at a pinned version on three pinned nodes (1 server, 2 agents), identical kernel and CPU-governor settings; the campaign runs overnight to limit background load. (2) Application: Online Boutique at a pinned tag, every deployment with identical resource requests/limits, HPA disabled, node-pinned, one ingress route; meshed configurations get sidecar injection namespace-wide with mTLS strict. (3) Workload: k6 open-model arrival-rate executor walking browse→add→checkout with declared request assertions; levels fixed at 25/50/70% of the baseline's capacity probe. (4) Repetitions: 5 runs × 30 minutes per configuration per level; 5-minute warm-up discarded; cluster rebooted between configurations; run order randomised. (5) Metrics: k6 emits per-route latency and error rate; Prometheus scrapes container CPU/memory (cAdvisor) for app pods and proxies; a collector script snapshots per-second series into the frozen dataset. (6) Statistics: mean ± 95% t-interval per metric; pairwise configuration comparisons by Mann–Whitney U with rank-biserial effect size; per-run, not per-request, as the unit of analysis. (7) Robustness: rerun the winning meshed configuration with proxy CPU limit halved and report throttling effects.

Threats to validity: background load on lab machines is logged and runs with anomalies are repeated; k6's own CPU budget is monitored to confirm the generator is not the bottleneck; all versions are pinned because mesh releases move fast enough to invalidate comparisons across months.

The testbed is a conventional three-tier benchmark architecture — generator, cluster under test, observability — with the mesh configurations differing only in what sits between the application pods.

flowchart TD
  K6["k6 load generator:<br/>open-model arrival-rate executor"] -->|"HTTP"| IN["Ingress"]
  IN --> FE["Frontend service"]
  FE --> C1["Cart service"]
  FE --> P1["Product catalog service"]
  C1 --> CUR["Currency service"]
  P1 --> CUR
  C1 --> CO["Checkout service"]
  CO --> SH["Shipping service"]
  subgraph MESH["Mesh data plane (configurations)"]
    SP["Istio sidecar proxy per pod"]
    LP["Linkerd proxy per pod"]
    NO["No proxy: baseline pods only"]
  end
  MESH -.->|"intercepts pod-to-pod calls"| C1
  MESH -.-> P1
  PROM["Prometheus + cAdvisor:<br/>per-pod and per-proxy CPU/mem"] --> RES[("Frozen campaign dataset")]
  K6 -->|"per-route latency, errors"| RES
  RES --> AN["Analysis notebook:<br/>CIs, Mann-Whitney U, cost model"]

Two structural decisions carry the study's fairness. First, only the data plane varies: application, resources, ingress and workload stay byte-identical across configurations, so observed differences are attributable to the mesh. Second, measurement is decoupled from the cluster under test: k6 runs from a separate machine and Prometheus scrapes out-of-band, so the observing stack cannot consume the resources being measured. The frozen dataset — one row per run per metric — is written once and never edited; the analysis notebook reads it and produces every table and figure, which is what makes the results auditable in the viva.

• Ambient mode: extend the comparison to Istio ambient/waypoint mode, where the proxy leaves the pod, and measure whether node-level proxies change the latency and resource story.
• Scale-out study: grow the cluster to six nodes and two load generators to test whether conclusions at three-node scale extrapolate, and where the generator stops being the bottleneck.
• Control-plane cost: instrument mesh control planes during configuration churn — virtual-service rollouts, traffic shifts — to price the operational as well as the data-plane overhead.
• Failure-mode behaviour: inject pod kills and network partitions under each configuration and measure how the mesh's retries and outliers policies alter user-visible latency and error recovery.
• Protocol generalisation: refactor the harness into a reusable benchmarking toolkit for any Kubernetes workload, and publish the protocol so other colleges can contribute results to a shared, comparable dataset.