Istio vs Linkerd, in depth: sidecar, ambient and micro-proxy data planes, identity, policy, upgrades and choosing a mesh

Three data planes

Istio in sidecar mode injects an Envoy proxy into every pod. Envoy is a general-purpose L7 proxy with a very large feature set: HTTP routing, retries, fault injection, rate limiting hooks, extensibility through filters. Every pod pays its memory and CPU, and every request crosses two Envoys.

Istio in ambient mode, generally available since Istio 1.24, removes the sidecar. A per-node proxy called ztunnel, written in Rust, handles L4: mTLS, identity, L4 authorization and telemetry. It carries traffic between nodes in HBONE, an HTTP CONNECT-based tunnel. L7 features such as HTTP routing and L7 authorization need a waypoint, an Envoy deployment running outside the application pods and scoped to a namespace or service. You deploy waypoints only where you need L7, and many workloads never need one.

Linkerd injects a sidecar too, but the proxy is linkerd2-proxy, a purpose-built Rust micro-proxy. It does a deliberately narrower set of things: mTLS, load balancing, retries and timeouts, metrics, and authorization. It has no general filter or plugin system, so there is less to configure and less to get wrong. If you need something it does not do, there is no extension point.

Two control planes

Istio's control plane is a single binary, istiod. It watches Kubernetes and Istio resources, computes Envoy configuration and serves it over xDS, acts as the certificate authority for workload certificates, and runs the sidecar injection webhook. Its configuration API is large: VirtualService, DestinationRule, Gateway, PeerAuthentication, AuthorizationPolicy and more, plus the Kubernetes Gateway API, which waypoints are configured through.

Linkerd's control plane splits into a few small components. destination serves service discovery and policy to proxies, identity issues workload certificates, and the proxy injector is the admission webhook. Metrics dashboards live in an optional viz extension. Its configuration API is a handful of policy CRDs plus Gateway API HTTPRoute. The practical difference is review effort: an Istio configuration change can touch several interacting resources, while a Linkerd change usually touches one.

Both control planes sit outside the request path. If istiod or Linkerd's destination component goes down, proxies keep serving with the configuration and certificates they already hold. New pods, configuration changes and certificate renewals stall, though, so a control-plane outage becomes a data-plane outage once workload certificates expire. Run the control plane with at least two replicas and a pod disruption budget, and alert on it as on any other tier-zero service. For day-to-day checks, Istio provides istioctl analyze for configuration errors and istioctl proxy-status for proxies that are out of sync. Linkerd provides linkerd check, which validates the installation and certificates, and with --proxy also checks the data plane.

Identity and certificate lifecycles

Both meshes derive identity from the Kubernetes service account. Istio encodes it as a SPIFFE ID such as spiffe://cluster.local/ns/shop/sa/checkout, and istiod signs workload certificates with its own CA by default. Production setups usually plug in an intermediate CA from the organisation's PKI, so that several clusters share a root.

Linkerd makes the certificate hierarchy explicit, and it is the part of Linkerd that most often causes outages. There are three levels. The trust anchor is a root certificate shared by every cluster that should trust each other. The identity issuer is a per-cluster intermediate stored in the linkerd-identity-issuer Secret. Below them are short-lived workload certificates that the identity component issues to proxies. If you install with static certificates, nothing renews the issuer or the anchor. The Linkerd documentation recommends letting cert-manager rotate the issuer: when cert-manager updates the Secret, proxies pick up the new issuer automatically.

apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: linkerd-identity-issuer
  namespace: linkerd
spec:
  secretName: linkerd-identity-issuer
  duration: 48h0m0s
  renewBefore: 25h0m0s
  issuerRef:
    name: linkerd-identity-issuer     # a ClusterIssuer that signs with the trust anchor
    kind: ClusterIssuer
  commonName: identity.linkerd.cluster.local
  isCA: true
  privateKey:
    rotationPolicy: Always
    algorithm: ECDSA

Linkerd only reads a Secret that cert-manager writes if it was installed to expect one. Set identity.externalCA=true and identity.issuer.scheme=kubernetes.io/tls in Helm values or --set flags. An installation on static certificates ignores the rotated Secret.

Rotating the issuer is routine. Rotating the trust anchor is not, because every proxy must trust both the old and the new anchor during the change. Put the anchor's expiry date in your calendar and your alerting the day you install. The general mechanics of overlapping roots are in mTLS certificate rotation.

Enrolling workloads

Workloads join the mesh through a label or annotation, then a restart for sidecar modes:

# Istio sidecar mode: label the namespace (or istio.io/rev=<tag> with revisions)
kubectl label namespace shop istio-injection=enabled
kubectl rollout restart deployment -n shop

# Istio ambient mode: no restart; ztunnel starts handling the pods' traffic
kubectl label namespace shop istio.io/dataplane-mode=ambient
istioctl waypoint apply -n shop            # only if shop needs L7 features
kubectl label namespace shop istio.io/use-waypoint=waypoint

# Linkerd: annotate the namespace, then restart so the injector adds the proxy
kubectl annotate namespace shop linkerd.io/inject=enabled
kubectl rollout restart deployment -n shop

Ambient's no-restart enrolment is a real operational advantage. Adding or removing mTLS no longer requires a rollout of every application, and a proxy upgrade no longer means restarting every pod.

Authorization policy in both meshes

Both meshes can enforce that only the checkout service may call payments. In Istio, first require mTLS with PeerAuthentication in STRICT mode, then allow by principal:

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: payments-allow-checkout
  namespace: shop
spec:
  selector:
    matchLabels: { app: payments }
  action: ALLOW
  rules:
  - from:
    - source:
        principals: ["cluster.local/ns/shop/sa/checkout"]

In ambient mode, ztunnel enforces rules like this one, which use only identities and ports. A rule that matches HTTP paths or methods needs a waypoint. If such a rule is enforced by ztunnel instead, Istio fails safe by turning it into a DENY policy, so attach L7 policies to the waypoint.

Linkerd expresses the same intent with three objects. A Server describes the port, a MeshTLSAuthentication names the allowed identities, and an AuthorizationPolicy binds them:

apiVersion: policy.linkerd.io/v1beta1
kind: Server
metadata: { name: payments-http, namespace: shop }
spec:
  podSelector: { matchLabels: { app: payments } }
  port: 8080
  proxyProtocol: HTTP/1
---
apiVersion: policy.linkerd.io/v1alpha1
kind: MeshTLSAuthentication
metadata: { name: checkout-only, namespace: shop }
spec:
  identityRefs:
  - kind: ServiceAccount
    name: checkout
---
apiVersion: policy.linkerd.io/v1alpha1
kind: AuthorizationPolicy
metadata: { name: payments-from-checkout, namespace: shop }
spec:
  targetRef: { group: policy.linkerd.io, kind: Server, name: payments-http }
  requiredAuthenticationRefs:
  - { group: policy.linkerd.io, kind: MeshTLSAuthentication, name: checkout-only }

Know your defaults. Linkerd's cluster-wide default inbound policy is all-unauthenticated: meshed pods accept any traffic until a Server selects them. Alternatives include all-authenticated, cluster-authenticated, deny and audit. You can override it per namespace or workload with the config.linkerd.io/default-inbound-policy annotation. Run in audit first to see what would be denied. Peer-authorization design in general is covered in mTLS for internal services.

Upgrades and release models

Istio supports revision-based canary upgrades. Install the new control plane next to the old one with istioctl install --set revision=..., point stable revision tags at revisions with istioctl tag set prod-stable --revision ..., and move namespaces by moving the tag and restarting workloads. When nothing uses the old revision, uninstall it. Istio's documentation notes that revision-based upgrades can skip a minor version, whereas in-place upgrades must go one minor at a time. In ambient mode, upgrading ztunnel touches every node's traffic, so read the release's ambient upgrade notes and drain carefully.

Linkerd changed its release model in February 2024. The open-source project ships edge releases, named edge-y.m.n and published roughly weekly, and no longer produces stable releases. Stable artifacts come from vendors, Buoyant Enterprise for Linkerd being the main one. You have three options: run edge releases and take on more testing, buy a vendor distribution, or build and support stable releases yourself. Factor that into the decision as cost and staffing, not just licensing. Upgrades apply CRDs first, then the control plane, then restart workloads so proxies pick up the new version.

Worked example: 900 pods on 60 nodes

Consider a platform with 60 nodes, 900 meshed pods and 40 services, where 6 services need HTTP-level routing or authorization. The resource comparison depends on per-proxy figures, which vary with traffic and configuration, so assume them, then measure yours. Assume a sidecar proxy idles at S MiB, a ztunnel at Z MiB per node and a waypoint replica at W MiB:

Memory is only one input. The ambient figure buys fewer moving parts per pod and restart-free enrolment, but it puts node-level traffic behind one shared ztunnel per node, and L7 hops through a waypoint that may sit on another node. The Linkerd figure buys the smallest configuration surface, but it requires a plan for stable releases and trust-anchor rotation. Sidecar Istio is the most flexible and the most expensive per pod. Run the same load test on a staging cluster with each option and record p99 latency, memory and CPU before committing.

Failure modes

• Expired trust anchor or issuer (Linkerd). Proxies cannot get or validate certificates and meshed traffic fails cluster-wide. Automate issuer rotation and alert on anchor expiry.
• Injection drift. Pods created before a namespace was labelled run without a proxy, and STRICT mTLS then rejects their calls. Check with istioctl proxy-status or linkerd check --proxy.
• L7 policy without a waypoint (ambient). ztunnel turns a rule with HTTP attributes into a DENY, and correct callers are blocked. Validate with istioctl analyze.
• Default-allow surprises. Linkerd's all-unauthenticated default means installing the mesh does not by itself restrict anything.
• Version skew. Leaving proxies on old versions for months after a control-plane upgrade. Track proxy versions and restart workloads on a schedule.
• Webhook outage. If the injector is unavailable, new pods start unmeshed or fail admission, depending on the failure policy. Run it with replicas and a disruption budget.

Trade-offs

Managed Kubernetes offerings bundle mesh options differently; see managed Kubernetes across clouds.

What to do next

1. Write down what you need the mesh for: mTLS only, L4 policy, L7 routing, or multi-cluster. If it is mTLS and L4 policy, start with Istio ambient or Linkerd.
2. Decide how you will get releases. For Linkerd that means edge, a vendor, or self-built stable. For Istio, choose a version and an upgrade cadence.
3. Install on a staging cluster with production-like load and record p99 latency, memory and CPU per option.
4. Set up certificate management before the first production workload: an intermediate CA for Istio, and cert-manager issuer rotation plus anchor-expiry alerts for Linkerd.
5. Enrol one namespace, verify every pod is meshed, then turn on STRICT mTLS, or run Linkerd's audit default policy, and review what would be denied.
6. Add explicit allow policies for one critical service, such as payments from checkout only, then extend namespace by namespace.
7. Rehearse an upgrade with revision tags (Istio) or CRD-first apply (Linkerd), including the workload restarts.