Istio of Linkerd: welke service mesh voor jouw cluster
Een service mesh regelt communicatie tussen services in je cluster: mTLS, observability, traffic management, retries, timeouts. Je hoeft dat niet in elke service te implementeren; de mesh doet het transparant op netwerkniveau.
De twee meest gebruikte meshes zijn Istio en Linkerd. Ze lossen hetzelfde probleem op, maar de complexiteit en de operationele last zijn niet vergelijkbaar.
Linkerd: eenvoud als ontwerpkeuze
Linkerd is gebouwd met een expliciete focus op eenvoud. De data plane bestaat uit een Rust-geschreven proxy (linkerd2-proxy) die klein is, weinig geheugen gebruikt en snel is. De installatie is een paar commando’s. De configuratie is beperkt, en dat is bewust.
Wat Linkerd goed doet:
- mTLS tussen alle services, zonder configuratie
- Golden metrics per route (succes-rate, latency, requests per seconde)
- Traffic splitting voor canary deploys via
TrafficSplit - Retries en timeouts op service-niveau
Wat Linkerd niet biedt: geavanceerd traffic management zoals header-gebaseerde routing, fault injection, of gedetailleerde JWT-validatie op mesh-niveau. Als je die features nodig hebt, moet je ze in je applicatie of in een API gateway oplossen.
De Rust-proxy is een concreet voordeel: minder resource-gebruik per sidecar, snellere startup, en een kleinere attack surface vergeleken met de JVM of Go-gebaseerde alternatieven.
Istio: krachtig, maar zwaar
Istio gebruikt Envoy als proxy, een C++-gebaseerde proxy die ook buiten Istio wijdverbreid wordt gebruikt. Envoy is flexibeler dan linkerd2-proxy, maar ook aanzienlijk zwaarder.
Wat Istio extra biedt boven Linkerd:
- Header-gebaseerde routing (handig voor A/B-tests en canary releases per gebruikerssegment)
- Fault injection voor chaos engineering in de mesh
- JWT-validatie en RBAC op mesh-niveau via
AuthorizationPolicy - Fijnmazige traffic management via
VirtualServiceenDestinationRule - Integratie met externe CA’s voor certificaatbeheer
De keerzijde is de operationele last. Istio heeft een control plane met meerdere componenten. De configuratie via CRD’s is uitgebreid en gevoelig voor fouten. Upgrades zijn niet triviaal. Teams zonder een dedicated SRE of platform-engineer hebben moeite Istio stabiel te houden.
Welke kies je?
De meeste teams hebben Linkerd nodig. Als je mTLS, basis traffic splitting en goede observability wilt zonder een voltijds platform-engineer voor de mesh, is Linkerd de juiste keuze. De installatie duurt 15 minuten en je ziet meteen waarde.
Istio is zinvol als je een SRE-team hebt dat de mesh beheert, en als je specifiek de Istio-features nodig hebt die Linkerd niet biedt. Teams bij grote financiële instellingen, telecomproviders of platforms met complexe routing-vereisten kunnen Istio rechtvaardigen. Een startup of een middelgroot bedrijf bijna nooit.
Cilium als derde optie
Cilium is primair een CNI, maar heeft via Cilium Service Mesh ook mesh-functionaliteit. Het voordeel: als je al Cilium als CNI gebruikt, voeg je geen extra sidecar-proxy toe. Cilium doet het op kernel-niveau via eBPF. Dat levert lagere latency en minder overhead op.
De functionaliteit is beperkter dan Istio, vergelijkbaar met Linkerd op de basis-features. Als je Cilium al draait, is het de moeite waard te evalueren of je Linkerd of Istio überhaupt nodig hebt.
De installatie-test
Een goede manier om een mesh te evalueren: installeer hem in een staging-cluster en kijk hoe snel je van nul naar werkende mTLS en metrics gaat. Met Linkerd is dat een uur. Met Istio een dag, als alles meevalt. Dat tijdsverschil is een signaal over de operationele last die je daarna ook draagt.
Als je service meshes in de praktijk wilt leren, bekijk dan de Kubernetes-trainingen op ict-trainingen.com die hands-on clusterwerk meenemen.
Kies de mesh die je team zelfstandig kan beheren. Een mesh die niemand begrijpt, lost niets op.