Upgrading Your Service Mesh to Linkerd 2
summary
A production migration moves from Linkerd 1’s heavy node-level daemonset (JVM proxy ~1GB memory) to Linkerd 2’s lightweight sidecar per pod model by deploying a new control plane deployment alongside the old mesh, enabling concurrent meshes, and using automated admission webhook injection to add sidecars during rolling redeploys. The pipeline flips namespaces to the new webhook, migrates services one-by-one, and can roll back; outcome: zero-downtime migration over hours, no developer changes required, and unified telemetry replaces fragmented per-node monitoring.
AI-written summary · about
chapters (14)
- 0:00Intro
- 1:17Agenda
- 3:19An example
- 8:53Service mesh
- 10:46Linkerd
- 12:43Architecture - Take 1
- 17:47Problems
- 18:47What's next?
- 19:26Control plane
- 20:19Data plane
- 22:21Architecture - Take 3
- 24:39Goals
- 26:38Admission Webhooks
- 27:47The plan
related talks
35mNavigating the Service Mesh Ecosystem
34mService Mess to Service Mesh
40mDeep Dive: Linkerd
37mIntro: Linkerd
38mAsk Me Anything About Service Mesh
30mService Mesh Is Still Hard. The Things we all Did Wrong & Tales of Woe
39mGrow with Less Pains - Meshing From Monolith to Microservices
27mService Mess to Service Mesh