Service mesh in 2026: revisit Istio ambient, Linkerd and Cilium before you add sidecars

Manoj Shukla
October 8, 2026

A logistics company in Bengaluru runs a production Kubernetes cluster with 14 nodes and about 420 pods. Three requests landed in one sprint. A large customer’s security questionnaire asks for encryption between all internal services. The product team wants to send 5% of traffic to a new pricing service before a festive sale. The SRE lead wants the same success rate and latency graphs for every service. One engineer says “install Istio”, another prefers Linkerd, and the platform lead notes that the cluster already runs Cilium as its CNI.

A service mesh can answer all three. It can also add a proxy to every pod, a second certificate authority and a new upgrade calendar. This post compares the main options on history, data plane design, Gateway API support, licences, upgrades, cost and security. Facts come from repositories, release pages, licence files, official docs, CVE records and vendor pages, checked on 8 October 2026; the drill is my own offline run. If you are also moving north-south traffic to Gateway API, the earlier post on Ingress NGINX retirement and Gateway API covers that side; this post stays east-west.

The short version

Istio 1.31.1 is current. Ambient mode (no sidecars) has been GA since Istio 1.24 in November 2024, and sidecar mode remains supported. Istio 1.29 support is expected to end on 12 October 2026.
Linkerd’s code is still Apache 2.0, but since February 2024 the project publishes only edge releases. Stable builds come from Buoyant Enterprise for Linkerd, free for companies under 50 employees and paid above that.
Cilium 1.20 deprecated its original mutual authentication feature and points users to a ztunnel-based mTLS mode, still beta. ztunnel was first built for Istio ambient.
Kuma (Apache 2.0, Kong) and Consul (BSL 1.1 since 1.17, now with IBM as licensor) remain Envoy sidecar meshes with strong VM support.
Node-level designs give mTLS and L4 policy cheaply. Retries, traffic splits and HTTP metrics still need an Envoy: a waypoint in Istio ambient, the node Envoy in Cilium.
In my drill, default Istio sidecars would reserve 42 vCPU and about 52.5 GiB for 420 pods, while ambient’s node components would reserve 4.2 vCPU and about 8.4 GiB on 14 nodes. These are default requests, not measured usage.

Where things stand on 8 October 2026

Project

Latest release (IST)

Data plane

Licence

Status

Istio

1.31.1 on 21 September 2026; 1.30.5 and 1.29.8 on 22 September; 1.32.0-alpha.0 on 6 October

Envoy sidecars, or ztunnel per node plus optional Envoy waypoints

Apache 2.0

CNCF graduated

Linkerd

edge-26.10.1 on 5 October 2026; Linkerd 2.20 announced 23 June 2026

Rust micro-proxy sidecar

Apache 2.0 code; stable builds from vendors

CNCF graduated

Cilium

1.20.2, 1.19.8 and 1.18.14 on 16 September 2026; 1.21.0-pre.3 on 3 October

eBPF in the kernel plus one Envoy per node; optional ztunnel per node (beta)

Apache 2.0; BPF code GPL 2.0 or BSD 2-clause

CNCF graduated

Kuma

2.14.5 on 18 September 2026

Envoy sidecars

Apache 2.0

CNCF sandbox; Kong

Consul

2.0.4 on 10 September 2026; 2.1.0-rc1 on 29 September

Envoy sidecars

BSL 1.1

IBM (HashiCorp)

The timeline, from release pages, project blogs and CNCF pages:

Date

Event

13 January 2016

First Linkerd commit, by Buoyant

23 January 2017

Linkerd accepted into the CNCF, its fifth project

24 May 2017

Istio 0.1 from Google, IBM and Lyft, built on Envoy

18 September 2018

Linkerd 2.0 GA: a rewrite with a Rust data plane and a Go control plane

28 July 2021

Linkerd graduates, the first service mesh to do so

December 2021

Cilium service mesh beta announced

7 September 2022

Istio ambient mesh announced

30 September 2022

Istio accepted into the CNCF; graduates on 12 July 2023

11 August 2023

BSL 1.1 licence change committed to the Consul repository, as HashiCorp moves future releases off MPL 2.0

11 October 2023

Cilium graduates

21 February 2024

Linkerd 2.15; the project stops publishing stable release artifacts

9 May 2024

Gateway API v1.1 moves service mesh support (GAMMA) to the standard channel

7 November 2024

Istio 1.24: ambient mode GA

31 October 2025

Linkerd 2.19: post-quantum key exchange by default

23 June 2026

Linkerd 2.20: native sidecars become the default

29 July 2026

Cilium 1.20.0: legacy mutual authentication deprecated

30 September 2026

AWS App Mesh support ends

Do you need a mesh at all?

A mesh moves four jobs out of application code: workload identity with mTLS (short-lived certificates, not IP addresses), resilience (retries, timeouts, per-request load balancing), traffic control (weighted splits, header routing, mirroring) and uniform telemetry (the same golden metrics for every service, whatever its language).

Each job has a cheaper answer if it is the only one you need.

If you only need

Option without a mesh

What you give up

Encryption between nodes

CNI transparent encryption (Cilium WireGuard or IPsec)

Per-workload identity and L7 policy

Canary for public traffic

Weighted routes at the ingress or Gateway

Canaries deep inside the call graph

Retries for two or three services

Client libraries and sensible timeouts

One consistent policy across languages

Golden metrics

OpenTelemetry in each service, or eBPF flow tools such as Hubble

Per-route HTTP metrics without code changes

My rule of thumb: if you have fewer than about 20 services, one language, and no compliance demand for service-to-service identity, a mesh is usually more cost than value. The Bengaluru team has all three needs, so the real question is which data plane.

Four data plane designs

Envoy sidecars

Istio’s original mode, Kuma and Consul put an Envoy proxy in every pod. Each pod gets full L7 features and failures stay in that pod. The costs: CPU and memory reserved per pod, a restart of every pod for each mesh upgrade, and start-up races, which Kubernetes native sidecars (an init container with restartPolicy: Always) mostly fixed. Istio 1.27 turned them on by default for eligible pods; in practice the maintainers explain that automatic enablement needs every node on Kubernetes 1.33 or newer.

Istio ambient: ztunnel plus waypoints

Ambient splits the mesh into two layers. ztunnel is a Rust proxy that runs as a DaemonSet, one per node, and handles only L4: mTLS over HBONE tunnels, L4 authorisation and TCP telemetry. Its README is blunt that terminating user HTTP traffic is out of scope. A waypoint is an Envoy proxy you deploy for a namespace or for selected services when you need L7: HTTP routing, retries, timeouts, fault injection, header-based policy, HTTP metrics and tracing. You enrol a namespace with the label istio.io/dataplane-mode=ambient, and no pod restarts.

Two caveats from the docs matter. A ztunnel upgrade affects a whole node, so the guide recommends draining nodes when apps hold long-lived TCP connections. And callers outside the mesh go straight to the destination, skipping any waypoint and its L7 policy.

Linkerd: a purpose-built Rust micro-proxy

Linkerd keeps the sidecar model but replaces Envoy with linkerd2-proxy, written in Rust and designed only for the mesh. Protocol detection, mTLS, latency-aware load balancing and metrics work with almost no configuration. Since 2.20 the proxy runs as a native sidecar by default. Version 2.19 switched the proxy’s crypto from ring to aws-lc and made the ML-KEM-768 post-quantum key exchange the default. There is no sidecarless mode; Linkerd argues that a small proxy per pod is easier to reason about than shared node proxies.

Cilium: eBPF plus a per-node Envoy

Cilium does L3 and L4 in eBPF inside the kernel, and sends L7 traffic (Gateway API, L7 network policy, protocol visibility) to one Envoy per node, by default as its own cilium-envoy DaemonSet. That gives sidecarless L7, but the Envoy is shared by every pod on the node, so its limits and upgrades affect everyone there. For identity, Cilium’s original mutual authentication kept authentication separate from encryption; the Cilium 1.20 release post notes the first packet could be dropped during the handshake and same-node traffic was not encrypted. That feature is now deprecated. Its replacement is ztunnel transparent encryption, introduced in 1.19 and still beta in 1.20, enrolled per namespace with the io.cilium/mtls-enabled=true label. The docs say it is not yet compatible with Cluster Mesh.

Istio sidecar

Istio ambient

Linkerd

Cilium

Proxy location

Every pod

ztunnel per node; waypoint per namespace or service

Every pod

Kernel eBPF; Envoy per node

mTLS without L7

Yes

Yes, ztunnel

Yes

ztunnel mode (beta), or WireGuard/IPsec without workload identity

L7 retries and splits

Sidecar

Waypoint required

Sidecar

Per-node Envoy

What an upgrade restarts

Every meshed pod

ztunnel per node, waypoints separately

Every meshed pod

Agent per node; Envoy DaemonSet separately

Failure blast radius

One pod

One node for ztunnel; one namespace for a waypoint

One pod

One node

Istio in 2026

Istio ships a minor about once a quarter (1.29 in February 2026, 1.30 in May, 1.31 in August), and each is supported until six weeks after the N+2 minor. Expected end of life: 1.29 on 12 October 2026, 1.30 around December 2026, 1.31 around February 2027. On 1.29, your patch window closes next week.

In-place upgrades must step through every minor. Revision-based (canary) upgrades run two control planes side by side and can jump two minors, say 1.29 to 1.31. Revision tags such as stable and canary point to immutable revisions, so you move namespaces by moving a tag. Run istioctl x precheck before each upgrade.

Release 1.31 adds weighted waypoint canaries, zone-aware load balancing and a FIPS 140-3 compliance policy. It also stops publishing to gcr.io/istio-release and Google-hosted storage. Images stay on Docker Hub and charts move to blob.istio.io and ghcr.io, with scream tests that switch off the old locations for a few hours, the next one on 13 October 2026. Check your mirrors and Helm repository URLs now.

The waypoint itself is a plain Gateway API resource. This is what istioctl waypoint generate printed in my drill:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: waypoint
  namespace: payments
spec:
  gatewayClassName: istio-waypoint
  listeners:
  - name: mesh
    port: 15008
    protocol: HBONE

Linkerd in 2026: open code, vendor stable builds

The 2.15 announcement in February 2024 said stable releases, point releases and backports would come from “the vendor community”. Buoyant’s CEO then clarified that the code stays Apache 2.0 and public; what stops is backporting fixes onto older stable branches. In October 2024 Buoyant said the change had doubled its enterprise customers and recurring revenue and made it profitable. In practice today:

Free path: edge releases from main, 30 of them between January and 5 October 2026. They are not semantically versioned, so read each note for breaking changes. Until July 2026 the notes carried an “Overall status” line, and edge-26.6.2 was marked NOT RECOMMENDED; the eight edges from August to edge-26.10.1 carry no such line.
Paid path: Buoyant Enterprise for Linkerd (BEL) gives semantically versioned stable releases, CVE remediation SLAs and a lifecycle operator. It is free in production for companies under 50 employees; the pricing page shows no prices for paid plans.
Status: Linkerd stays CNCF graduated, and its releases page lists BEL as the known distribution for every major from 2.15 to 2.20.

Buoyant advisory 2026-01 (September 2026) shows the model. It grouped six Linkerd vulnerabilities, including a critical one where a namespace user could make linkerd multicluster check run a command on the administrator’s laptop. Fixes shipped in edge-26.9.1 and in enterprise-2.20.3, 2.19.11 and 2.18.14. On open source, “patched” means a newer edge, not a 2.20.x point release.

Cilium: mesh features inside your CNI

If Cilium is already your CNI, its mesh features cost little to try: identity-aware L3/L4 policy, Hubble flow visibility, Gateway API and GAMMA routing, L7 policy through the node Envoy, and WireGuard or IPsec encryption. Cilium patches the last three minors (1.20, 1.19, 1.18), and its only tested upgrade and rollback path is one minor at a time, from the latest patch, after a pre-flight check.

The limits are by design. Cilium supports only GAMMA “producer” routes (in the Service’s own namespace), not “consumer” routes set by callers, and its workload mTLS is moving from a deprecated beta to a newer beta. Teams that need audited mTLS today should test ztunnel mode carefully or run Istio ambient on top of Cilium. For the latter, Istio’s platform guide lists three Cilium settings: set cni.exclusive=false, do not enable bpf.masquerade=true, and if you use default-deny policies, allow kubelet probes from 169.254.7.127/32.

Kuma, Kong Mesh and Consul

Kuma is Kong’s Envoy-based mesh for Kubernetes and VMs, with multi-zone support; Kong Mesh is the commercial product built on it. Kuma 2.14.5 is current, and on 11 September 2026 Kong patched five older lines at once, 2.7.30 to 2.13.11. A recent multi-zone flaw let one zone impersonate another (GHSA-m58j-fjmc-h3g4).

Consul’s mesh also uses Envoy sidecars and suits estates where Consul already runs discovery across VMs and Kubernetes. Revisit the licence first. Consul 1.17.0 and later are under BSL 1.1, and the LICENSE file now names International Business Machines Corporation as licensor. Internal production use is allowed; offering a competing paid product is not, and each version converts to MPL 2.0 four years after publication. The consul-k8s repository’s LICENSE is still MPL 2.0. Consul 2.0.0 (May 2026) added Enterprise-only features such as multi-port services.

Gateway API and GAMMA: one routing API for the mesh

Since Gateway API v1.1 (May 2024), an HTTPRoute can name a Service as its parent instead of a Gateway. That is GAMMA, and it means the same API describes ingress and in-mesh routing. A canary for the Bengaluru team’s pricing service looks like this on any GAMMA implementation:

apiVersion: gateway.networking.k8s.io/v1
kind: HTTPRoute
metadata:
  name: pricing-canary
  namespace: pricing
spec:
  parentRefs:
  - group: ""
    kind: Service
    name: pricing
    port: 8080
  rules:
  - backendRefs:
    - name: pricing-v1
      port: 8080
      weight: 95
    - name: pricing-v2
      port: 8080
      weight: 5

Support differs in the details:

Istio

Linkerd

Cilium

Kuma

GAMMA routing

Yes, in sidecar and ambient (via waypoints)

HTTPRoute and GRPCRoute are core config

Producer routes only

Own policies (MeshHTTPRoute)

Gateway API v1.5 mesh conformance table

1.30.5 listed, core conformant

Not listed

1.20.0-pre.2 listed, partially conformant

Not listed

Gateway API versions in docs

Getting started installs v1.6.0 experimental

2.20: 1.2.1 to 1.5.1

Kept in step with releases

Not checked

Gateway API CRDs are cluster-wide, so if one team installs v1.6, check Linkerd’s range before adding it. Argo Rollouts and Flagger are listed Gateway API integrations, so your pipeline can drive the weights above; the earlier post on Argo CD and Flux covers the GitOps side.

Licences: read the files

Project

What the LICENSE file says

What is paid

Istio (and ztunnel)

Apache 2.0

Support and distributions from several vendors

Linkerd and linkerd2-proxy

Apache 2.0

Stable builds, CVE SLAs, lifecycle operator, FIPS and HA zone-aware load balancing in BEL plans

Cilium

Apache 2.0 for user space; BPF templates GPL 2.0 or BSD 2-clause

Enterprise distributions from vendors

Kuma

Apache 2.0

Kong Mesh

Consul

BSL 1.1 for 1.17.0 and later, licensor IBM, change to MPL 2.0 after four years

Consul Enterprise features

consul-k8s

MPL 2.0

Not applicable

For Linkerd the issue is the release channel, not the licence. For Consul it is the licence.

Upgrades and support windows

Project

Support window

Upgrade rule from the docs

Istio

Each minor until six weeks after N+2

In-place one minor at a time; revision upgrades may skip one minor; control plane may lead data plane by one minor

Linkerd (open source)

None stated for edge; read each release note

CRDs first, then control plane, then linkerd prune, then roll the data plane; control plane may lead the data plane by up to a full version

Cilium

Last three minors

One minor at a time, latest patch first, pre-flight check required

Resource cost: separate vendor numbers from your own

Treat published numbers as each project’s own run on its own hardware:

Istio’s performance page (Istio 1.24, 1,000 requests per second of 1 KB, 2 proxy worker threads) reports about 0.20 vCPU and 60 MB for one sidecar, 0.25 vCPU and 60 MB for one waypoint, and 0.06 vCPU and 12 MB for one ztunnel.
The ambient GA post says savings “can exceed 90%” in some use cases.
Linkerd’s 2.0 announcement (2018) said proxies used about 10 MB of RSS with p99 latency under 1 ms. The 2.20 post says a destination controller refactor cut control plane memory “in some cases by almost 85%”.

What you can check is what the default manifests ask the scheduler to reserve. From my drill, for 14 nodes and 420 meshed pods:

Default install

Per unit

Units

Reserved CPU

Reserved memory

Istio sidecar

100m, 128Mi per pod

420 pods

42 vCPU

52.5 GiB

Istio ambient, L4 only

ztunnel 200m, 512Mi plus istio-cni 100m, 100Mi per node

14 nodes

4.2 vCPU

about 8.4 GiB

Cilium ztunnel mode

ztunnel-cilium 200m, 512Mi per node

14 nodes

2.8 vCPU on top of Cilium

7 GiB on top of Cilium

Linkerd

No requests on proxies by default

420 pods

0 reserved

istiod’s own request (500m and 2Gi) is the same in both Istio modes, and waypoints are extra. The Linkerd row is the trap: zero requests does not mean zero use. The proxies still consume CPU and memory; the scheduler just cannot see it, which leads to noisy-neighbour surprises. Set proxy requests in Linkerd based on what you measure.

Security advisories

Project

Advisory

Issue

Fixed in

Istio

CVE-2026-39350

AuthorizationPolicy serviceAccounts with dots matched as regex, allowing bypass

1.28.6, 1.29.2

Istio

ISTIO-SECURITY-2026-006, GHSA-qm8v-g4f9-qhjx

13 Envoy CVEs, including CVE-2026-73553 (RBAC bypass via path parameters); BackendTLSPolicy fail-open on sidecars

1.29.7, 1.30.4

Istio

ISTIO-SECURITY-2026-002

VirtualService in one namespace can redirect mesh traffic; Istio calls it expected behaviour and recommends Gateway API for multi-tenant meshes

Design guidance, no patch

Linkerd

GHSA-7hx9-xmmq-23f3 (critical, no CVE)

Command execution on the admin workstation via multicluster Link secrets

edge-26.9.1; enterprise-2.20.3, 2.19.11, 2.18.14

Linkerd

GHSA-8wg2-5jpc-v68h (high, no CVE)

Cross-namespace EndpointSlice injection through ExternalWorkload resources

edge-26.6.2; enterprise-2.20.0, 2.19.11, 2.18.14

Cilium

CVE-2026-49445 (critical)

World-accessible Envoy admin socket on nodes

1.17.14, 1.18.8, 1.19.2

Cilium

CVE-2026-56742

Namespaced HTTPRoutes can mirror traffic to other namespaces

1.17.17, 1.18.11, 1.19.5

Cilium

GHSA-33qq-jq9c-6gcc (high)

Identity spoofing in mutual authentication via certificate substitution

1.17.18, 1.18.12, 1.19.6

Kuma

GHSA-744g-c785-x65q

A dataplane token without workload binding can claim another workload’s SPIFFE identity

2.13.10, 2.14.2

Consul

CVE-2024-10005

L7 intentions bypass via non-normalised URL paths

Path normalisation extended to gateways in 2.0.0

Three lessons. Most Istio bulletins are Envoy CVEs, so an Envoy-based mesh inherits Envoy’s patch rhythm. Several advisories are about one namespace affecting another, so in a shared cluster, who can create mesh resources matters as much as the mesh. And Cilium’s mutual authentication flaw sat in a beta feature now deprecated; check maturity labels before you rely on a feature for compliance.

A decision guide

Your situation

Reasonable first choice

Need mTLS and L4 policy everywhere, L7 for a few services, many pods per node

Istio ambient, adding waypoints only where needed

Need rich L7 everywhere, mature tooling, VM workloads

Istio sidecar mode, or Kuma

Small platform team, want simple defaults and per-pod isolation, can pay for or accept edge releases

Linkerd (BEL, or edge with a disciplined upgrade habit)

Already on Cilium, need encryption and L7 policy, not strict workload mTLS today

Cilium features first; test ztunnel mode

Consul already runs discovery across VMs and Kubernetes

Consul mesh, after a BSL review

Fewer than 20 services, no identity requirement

No mesh yet; use ingress canaries, timeouts and OpenTelemetry

For the Bengaluru team, I would test Istio ambient on top of the existing Cilium CNI: ztunnel covers the security questionnaire, one waypoint in the pricing namespace covers the canary, and waypoints in the busiest namespaces cover golden metrics. Linkerd is the alternative if they prefer per-pod isolation and accept the release model.

A practical checklist

Write down the requirement: mTLS, L7 policy, canaries or metrics.
Count pods per node. Per-pod sidecars and per-node proxies scale differently.
Check the release channel you will run: Istio minor, Linkerd edge or BEL, Cilium minor.
Read the licence files of the exact version, especially for Consul.
Put end-of-life dates in the calendar. Istio 1.29 ends around 12 October 2026.
Install Gateway API CRDs deliberately and check every mesh and gateway’s supported range.
Restrict who can create mesh resources such as VirtualService, EnvoyFilter, HTTPRoute and Link.
Set resource requests for proxies from measurements, not defaults or zero.
Plan certificate rotation. Linkerd’s CLI-generated trust anchor in my drill was valid for exactly one year.
Rehearse an upgrade and a rollback on staging, including node drains for ztunnel.

Common mistakes

Assuming ambient gives L7 for free. Without a waypoint you get mTLS and L4 only.
Trusting waypoint policy for callers outside the mesh. They skip the waypoint.
Running Linkerd edge like a stable channel. Edge numbers carry no compatibility promise; read every note.
Letting the mesh install Gateway API CRDs. In my drill, Linkerd’s optional installGatewayAPI=true rendered v1.1.1 experimental CRDs, older than the 1.2.1 to 1.5.1 range its docs list for 2.20.
Ignoring the old Istio artifact locations. Pipelines that pull from gcr.io/istio-release will fail during the scream tests.
Treating Cilium mutual authentication as a long-term base. It is deprecated.

Drill: three CLIs and their default manifests, offline

No root, no containers, no cluster. On 8 October 2026, from about 2:22 AM to 2:29 AM IST, on a shared Linux VM with 8 vCPUs and 15 GB of RAM, I downloaded official release artifacts, checked them and rendered default installs.

Downloads and checksums

Artifact

Size

Check

istio-1.31.1-linux-amd64.tar.gz

29,786,135 bytes

SHA-256 matched the published .sha256 file

cilium-cli v0.20.1 linux-amd64 tarball

76,845,833 bytes

SHA-256 matched the published .sha256sum file

linkerd2-cli-edge-26.10.1-linux-amd64

91,160,738 bytes

No checksum file in the release; SHA-256 matched the digest GitHub’s API reports for the asset

Linkerd’s install script does not verify a checksum either, so check it yourself. Unpacked, istioctl is 105,619,618 bytes and the cilium CLI 161,357,984 bytes. cilium-cli v0.20.1 reported a default image of v1.20.1 and a stable image of v1.20.2.

What the default installs contain

Render

Objects

Workloads

CRDs

Notable defaults

istioctl manifest generate, default profile

istiod, ingress gateway

15 Istio

istiod requests 500m, 2048Mi; sidecar injector webhooks fail closed

Same, ambient profile

istiod; ztunnel and istio-cni DaemonSets

15 Istio

ztunnel 200m, 512Mi with NET_ADMIN, SYS_ADMIN, NET_RAW; no Gateway API CRDs

linkerd install --ignore-cluster

identity, destination, proxy-injector

10 in a separate --crds render

No resource requests; webhooks fail open; heartbeat CronJob

Same with --ha

Same, 3 replicas each, 3 PDBs

Same

Requests set (for example 100m, 50Mi for destination); webhooks fail closed

cilium install --dry-run, 1.20.2

cilium and cilium-envoy DaemonSets, operator

Created at runtime

No requests on agent or Envoy

Cilium chart with encryption.type=ztunnel

Adds ztunnel-cilium DaemonSet

Same

Image quay.io/cilium/ztunnel:v1.0.0, 200m, 512Mi

Neither Istio profile installs the Gateway API CRDs that waypoints need. Linkerd’s CLI generated a self-signed trust anchor valid for exactly one year (7 October 2026 to 7 October 2027, GMT); production should bring its own. istioctl waypoint generate worked offline, istioctl x precheck needs a cluster, istioctl kube-inject with local config files printed nothing for 60 seconds before I stopped it, and linkerd inject without a cluster asked for trust anchors.

Image weights

Compressed linux/amd64 sizes from registry manifests at about 2:25 AM IST:

Image

Compressed

Istio pilot / proxyv2 / ztunnel 1.31.1

78.9 / 95.6 / 53.4 MB

Same, distroless tags

34.1 / 55.1 / 13.0 MB

Linkerd proxy / controller edge-26.10.1

22.1 / 31.7 MB

Cilium agent v1.20.2 / cilium-envoy v1.37.6 / ztunnel v1.0.0

257.8 / 76.7 / 17.7 MB

Honest limits: with no cluster I measured no latency, throughput, CPU or memory; the cost table uses default requests, not usage. I did not test Kuma, Consul, waypoint behaviour, multi-cluster or upgrades. Image sizes are download weight only. Nothing was blocked; the failures above are normal tool behaviour without a cluster.

What to unlearn and re-learn

Unlearn “service mesh means a sidecar in every pod”. Re-learn that Istio ambient and Cilium put L4 on the node and L7 where you ask for it.
Unlearn “open source means free stable releases”. Re-learn that Linkerd’s code is open but its stable builds are a vendor product, and Consul’s code is source-available.
Unlearn “each mesh has its own routing API”. Re-learn GAMMA: HTTPRoute with a Service parent works across Istio, Linkerd and Cilium, with gaps.
Unlearn “no resource requests means no cost”. Re-learn to measure proxies and reserve what they use.

Revisit your service mesh before you add sidecars

The Bengaluru team does not have to choose between “Istio everywhere” and “no mesh”. Learn what each design really is: per-pod proxies, node proxies with optional waypoints, or kernel datapath with a shared Envoy. Unlearn the idea that a mesh is one product with one cost. Re-learn release channels, licences and Gateway API versions before they surprise you. Practise on a staging cluster with real traffic, measured requests and a rehearsed upgrade. Then apply it one namespace at a time, starting with the security requirement, and add L7 only where a team can show it needs it.

Sources

comments powered by Disqus

Releted Posts

Keycloak and its alternatives: revisit your identity provider before you standardise SSO

Manoj Shukla
October 7, 2026

A SaaS company in Hyderabad runs Keycloak 24 on two virtual machines. It was set up in 2024 for about 60 internal tools and has worked quietly since.

Manoj Shukla
October 7, 2026

A platform team runs a three-node Vault Community cluster for about sixty services. In one week, a product group asks for its own isolated tenant, which in Vault means namespaces, an Enterprise feature, and finance asks whether the Enterprise quote is really needed.

Manoj Shukla
October 6, 2026

A platform team plans its Kubernetes 1.37 upgrade for the next sprint. The cluster checklist is green, except one line nobody owns: the ingress-nginx Helm chart, pinned at 4.