Istio vs Linkerd för service mesh i K8s.
Service mesh är ett av de begrepp som låter mer avancerat än det är, och som ibland införs för att det är på modet snarare än för att det löser ett problem. Ett mesh lägger ett lager mellan dina tjänster som hanterar kryptering, trafikstyrning och observerbarhet - utan att du ändrar koden. Istio och Linkerd är de två dominerande valen. Här går jag igenom vad de löser, hur de skiljer sig, och den viktiga frågan om ni ens behöver ett mesh ännu.
Vad ett service mesh faktiskt löser
Tre saker återkommer som verkliga skäl. För det första ömsesidig TLS (mTLS) - all trafik mellan tjänster krypteras och autentiseras automatiskt, vilket är guld värt för en nollförtroendemodell. För det andra trafikstyrning - kanariesläpp, viktad routing och återförsök utan att röra applikationen. För det tredje observerbarhet - enhetliga mätvärden och spårning för all trafik mellan tjänster. Allt detta utan att utvecklaren behöver bygga in det i varje tjänst.
Det sista är poängen som ofta säljer in ett mesh: funktionerna ligger i infrastrukturen, inte i koden. Utan ett mesh måste varje tjänst själv hantera kryptering, återförsök och mätvärden, vilket innebär samma logik upprepad i tjänst efter tjänst, ofta på olika sätt beroende på vem som skrev den. Ett mesh lyfter ut det till ett enhetligt lager som gäller alla tjänster likadant. För en organisation med många tjänster i olika språk är det en verklig förenkling - men för en med få tjänster är det ett tungt lager för ett problem som knappt finns.
Linkerd: enkelheten som dygd
Linkerd är byggt med enkelhet och låg overhead som ledstjärna. Det är lättare att installera, lättare att förstå och förbrukar mindre resurser. För de allra flesta som vill ha mTLS och grundläggande trafikkontroll i Kubernetes är Linkerd det jag rekommenderar först. Det gör det viktigaste mycket bra utan att dra in komplexitet ni inte bett om. Begränsningen är att det inte har lika många avancerade funktioner som Istio.
Istio: kraften och priset
Istio är det mest funktionsrika meshet. Det kan i stort sett allt - avancerad trafikstyrning, finmaskiga policyer, omfattande integrationer. Priset är komplexitet. Istio har historiskt varit tungt att driva och förstå, även om det blivit bättre. För en organisation med komplexa krav och kompetens att förvalta det ger Istio en kraft Linkerd inte matchar. För andra blir den kraften en börda. Var ärlig om vilken kategori ni tillhör.
Det jag oftast ser gå fel är att ett team väljer Istio för funktionerna men aldrig använder mer än en bråkdel av dem, och i stället sitter med all komplexitet och inget av den extra nyttan. Den extra kraften är bara värd något om ni faktiskt behöver den och har någon som kan förvalta den över tid. Frågan att ställa sig är inte vilket mesh som kan mest, utan vilket mesh som löser era konkreta behov med minst möjliga komplexitet. För de flesta pekar det svaret mot Linkerd, och bara en minoritet har de krav som verkligen motiverar Istio.
Behöver ni ens ett mesh?
Det här är den viktigaste frågan, och den hoppas många över. Ett service mesh tillför ett lager komplexitet, och det ska motiveras. Har ni en handfull tjänster kan ni ofta lösa mTLS och trafikstyrning enklare utan ett fullt mesh. Meshet börjar betala sig först när antalet tjänster växer och behovet av enhetlig kryptering, styrning och observerbarhet mellan dem blir reellt. Att införa ett mesh för tre tjänster är ofta att lösa ett problem ni inte har.
Så väljer jag
- Vill ni ha mTLS och grundläggande trafikkontroll med låg friktion - Linkerd.
- Har ni komplexa krav och kompetens att förvalta - Istio.
- Har ni bara en handfull tjänster - skjut upp meshet och lös det enklare.
- Inför ett mesh när antalet tjänster gör behovet konkret, inte innan.
Vill du ha hjälp att avgöra om och hur kan du läsa om min molninfrastruktur.
Relaterat
- Terraform-moduler vi använder för varje kundsetup (open source)
- GCP för dataintensiva svenska bolag: BigQuery + Vertex + Looker
- Migrera från on-prem till Azure på 90 dagar: Spelboken
Vill du ta det vidare?
Funderar ni på ett service mesh hjälper jag er att avgöra om ni behöver det och i så fall vilket. Läs om min molninfrastruktur, se exempel i casebook, eller boka ett samtal.
“Att införa ett mesh för tre tjänster är ofta att lösa ett problem ni inte har.”
- Simon Axelsson
Vanliga frågor
- Istio eller Linkerd för de flesta?
- Linkerd. Det är enklare, lättare och förbrukar mindre resurser, och gör mTLS och grundläggande trafikkontroll mycket bra. Istio är mer funktionsrikt men tyngre att driva, och passar organisationer med komplexa krav och kompetens att förvalta det.
- Vad är den största nyttan med ett service mesh?
- Oftast automatisk mTLS - all trafik mellan tjänster krypteras och autentiseras utan kodändring, vilket stödjer en nollförtroendemodell. Därtill kommer trafikstyrning som kanariesläpp och enhetlig observerbarhet mellan tjänster.
- När är vi för små för ett service mesh?
- Med bara en handfull tjänster kan ni ofta lösa mTLS och trafikstyrning enklare utan ett fullt mesh. Meshet börjar betala sig när antalet tjänster växer och behovet av enhetlig kryptering och styrning mellan dem blir reellt.
Simon Axelsson är senior IT-konsult och grundare av SIAX Technology AB. Han hjälper nordiska företag med molninfrastruktur, dataplattformar och AI-automation.
Fler artiklar
