3. 5. 2023

Istio jako AKS addon je jednoduše nainstalovatelné bez přistupování na Kubernetes API (jako addon to umíte nahodit pěkně přes Azure API při vytváření AKS třeba Terraformem a to i do privátního clusteru bez public IP), automaticky se škáluje a Microsoft v rámci AKS release testuje jeho funkčnost, kompatibilitu se službami jako je Azure Grafana (vizualizace), Azure Monitor for Prometheus (metriky) a Application Insights (tracing). Umožňuje snadný upgrade a AKS je v rámci addon také přizpůsobeno (přiškáluje se například coredns). Na addon jako takový máte podporu (až to bude v GA) - ne tedy na Istio samotné, ale na jeho integraci s AKS ano. To zní dobře, ne? Ale má mě to zajímat?

Proč Service Mesh většinou netřeba

Nejprve musím připomenout, co už na tomto blogu zaznělo několikrát - chytré trubky, tedy service mesh, většinou nepotřebujete a tak často jeho přidaná komplexita má dopad spíše negativní.

Co není nebo by neměla být role service mesh:

• Aplikační monitoring a tracing volání mezi Pody - tohle za mě patří do aplikace. Velmi doporučuji použít standardizované technologie, tedy dnes Open Telemetry, a tuto instrumentaci v aplikacích zajistit. Ideálně samozřejmě integrací open source SDK přímo do kódu, ale často existují metody, jak přidat instrumentaci bez jakékoli změny zdrojáku zejména pro jazyky jako Java nebo C# (ale v poslední době už i PHP nebo Python). Chcete totiž end-to-end pohled od frontendu až po volání do databáze a to vám service mesh nikdy nedá.
• Nenahrazuje API management - jasně, může dělat různá L7 pravidla, ale to neřeší životní cyklus, bezpečnost, dokumentaci, verzování, monetizaci ani nasazování API. S tím, jak je dnes API management běžně dostupný přímo uvnitř Kubernetes (třeba self-hosted gateway v Azure APIM, Gloo, Kong) nemá smysl se ho snažit nahrazovat service meshem.
• Neměl by dělat z vývojářů prasata - osobně jsem toho názoru, že věci typu retry logika prostě patří do SDK a vývojáři moderních aplikací musí mít odpovědnost za situace, kdy se některá ze služeb, s kterou komunikují, dostane do potíží.
• Aplikace by měly používat asynchronní principy kde to jde - zasílání zpráv přes fronty nebo event sourcing apod. jsou metody jak udělat robustní cloud-native aplikaci a s tím service mesh nepomůže vůbec. Moderně napsaná aplikace bude mít vrstvu APIM bez řetězení volání služeb mezi mezi sebou (všechny synchronní věci jdou tamtudy) a k tomu sadu eventů a zpráv, takže vlastně není moc kde by service mesh přinášel hodnotu.

Co může být jeho role, ale existují alternativy s menší komplexitou:

• Filtrování provozu mezi namespace a Pody - stará dobrá Network Policy je sice jen L4, ale na to co lidi běžně chtějí (např. izolovat namespace mezi sebou) to stačí.
• Vizibilita do síťového provozu - když nechám stranou reálný přínos něčeho takového, tak Cilium přes eBPF umí nabídnout výborná data a vizualizaci bez sidecar a přidané latence.

Kde to smysl za mě dává nebo si nejsem jist, ale dávat by mohlo:

• mTLS - na tohle prostě pecka, otázka ale je, kdo reálně potřebuje šifrovat komunikaci uvnitř Kubernetu. Pokud ano, skvělé použití service mesh.
• L7 routing mezi službami - canary release, progressive delivery, různá kouzla s routováním na verzi komponenty podle headeru, A/B testing apod. To jsou scénáře, kde service mesh opravdu exceluje. Nezapomínejme ale, že v moderní architektuře hopy mezi službami napřímo stejnak nechceme a všechno má jít přes API management nebo alespoň ingress - pokud tedy totéž můžeme dělat tam, může to stačit.
• Service Insertion - tohle považuji za nejlepší věc, kterou může service mesh přinést, tedy schopnost podle potřeby vkládat do cesty L7 služby bez nějakých složitých šíleností kolem routingu nebo ručního tunelování. Dnes to ještě úplně není ono, ale trendy typu ambient mesh jdou tím směrem, který se mi líbí.

Proč AKS nabízí Istio, když má Open Service Mesh?

Tohle je zajímavé téma. Největší potíž je, že historicky Istio bylo hodně (a to opravdu hodně) drženo Googlem a to i z pohledu governance. Takový ten styl, že je to marketingově strašně otevřené a blabla, jenže klíčky od toho má jeden nebo dva vendoři a ti řídí směřování celého projektu, přijímání změn, oprav a vylepšení. V té době Microsoft musel řešit podporu service mesh v AKS, protože kolem toho bylo hodně povídání (všichni to strašně chtěli a málokdo věděl proč). Co s tím? Použít v té době Istio v produktu byl problém - svou budoucnost dáváte do rukou klíčového konkurenta nebo si to forknete a je to obtížně udržitelné. Další varianta bylo Linkerd, které je skvělé, ale fakt, že má zgruntu napsanou vlastní reverse proxy má kromě výhod (výkon, bezpečnost) i nevýhody (podpora L7 funkcí, Wokna). Consul byl zas hodně spjatý s Hashicorpem, to by moc nepomohlo. Proto Microsoft založil projekt Open Service Mesh, který využívá Envoy proxy (= podpora L7 funkcí, telemetrie, trasování, Windows) a nad tím staví orchestraci. Ten je hned od začátku pod governance CNCF, není tedy nijak cinknutý. OSM je jednoduchý, ale využívá funkčně bohatou Envoy. Je tedy podstatně odlehčenější, než Istio (míň věcí se může pokazit, má dobrý výkon) a při tom funkčně bohatší, než Linkerd (které exceluje v lehkosti a výkonu, ale chybí mu dost L7 funkcí).

Google se hodně soustředil na aplikační platformu nad Kubernetem v podobě KNative, která měla Istio jake dependenci. Microsoft měl jiný přístup - DAPR bez dalších dependencí, aplikační platforma s 21000 hvězdičkami na GitHubu (vs. 5000 u KNative) a governance v rámci CNCF v kombinaci s KEDA projektem pro škálování (také CNCF). Podle spekulací na Internetu produkťáci v Googlu měli pocit křivdy, že Kubernetes, který vznikl tam, jim nepřinesl tolik kontroly, jak by mohl, pokud by nebyl tak otevřený a tak si Istio a KNative drželi. Nicméně v březnu 2022 Google nakonec Istio i KNative přihlásil do CNCF - což je moc dobře.

Komunita kolem Open Service Mesh, kde je samozřejmě velké množství lidí Microsoftu, oznámila, že se přesouvá k práci na projektu Istio. Ve středním horizontu to bude tedy optimální volba i pro AKS, ale pokud potřebujete něco dnes, OSM funguje výborně a je v GA.

Úžasný trend v Istio - posunutí části dataplane blíž aplikaci a naopak odsunutí jiné části dál

Sidecar je overhead - filtrovat provoz umí Network Policy, dělat vizibilitu do komunikace zvládne i Cilium přes eBPF, balancing se děje v iptables nebo ipvs nebo přes eBPF apod. Istio přišlo s konceptem ambient mesh, který posouvá celou technologii service mesh směrem, který se mi moc líbí. Základní věci jako je TCP routing, mTLS, filtrování, metriky a logy vyřeší přímo node přes eBPF a to včetně bezpečných tunelů (ztunnel) mezi Pody nebo k L7 službám. Pokud potřebujete něco pokročilého, třeba HTTP routing a balancing, circuit breaking, fault injection, HTTP metriky nebo distributed tracing, to vám zajistí L7 komponenta. Ta už není sidecar u každého kontejneru, ale je to služba vložená tam, kde chcete/potřebujete a je sdílená pro nějakou doménu (typicky budete chtít mít separátní L7 zpracovatelské nody pro různé typy aplikací, třeba namespace - z bezpečnostních důvodů). Představte si potenciální další implikace, které to může mít (a neříkám, že to je dnes k dispozici, jen, že to je možnost, která se mi líbí):

• Komunikaci Podů s okolním světem by šlo díky tunelu vytáhnout i mimo cluster a zpracovat v nějaké cloudové službě (podobně jak to dnes třeba dělá Azure GW LB, který odkloní provoz z public IP do nějaké chytré krabičky přes VXLAN). To by mělo zajímavé dopady:
  • Řešili jste někdy ten otravný legacy požadavek, že odchozí IP určité služby musí být konkrétní a unikátní? Ufff…řešitelné třeba přes proxy v cestě mimo cluster pro HTTP provoz nebo dedikovaný nodepool, kde znáte IP dopředu a můžete tak udělat příslušná NAT pravidla na firewallu. Všechno workaround. Takhle by ale provoz mohl jít tunelem přímo do firewallu a ten pak udělá SNAT předvídatelně a bez nutnosti znát konkrétní IP Podu.
  • Co kdyby WAFka uměla vytočit tunel k Podům? F5 se o něco takového pokoušela, ale s vlastním CNI, což je anti-cloudová myšlenka. A co teprve kdyby to uměla nějaká distribuovaná WAFka typu Azure FrontDoor, CloudFlare nebo Akamai?
• V případě sidecar jde komunikace mezi dvěma službami přes dvě proxy, což je dost zbytečné. U ambient mesh řeknete, že potřebujete L7 funkce a proteče to přes jednu, ne dvě krabičky.
• Pokud bychom tyto myšlenky proložili ještě dál, tak co kdybychom měli control plane, který dokáže ovládat data plane přímo v aplikaci? Představme si, že pro aplikace bude existovat SDK pro implementaci věcí jako retry nebo circuit breaker, ale jejich parametry budou řízeny centrálním control plane. Získali bychom výkon a přímočarost implementace přímo v aplikaci (což je správně), ale s centrální vizibilitou a konfigurovatelností.

Když to shrnu. Aktuálně myslím, že většina zákazníků co znám service mesh nepotřebuje a spíše si uškodí nebo jim to sebere čas, který by mohli věnovat směrování aplikací k asynchronnímu chování a API managementu. Pokud nějaký v AKS potřebujete, pořád bych preferoval Open Service Mesh kvůli jednoduchosti a podpoře. Nicméně service mesh ještě neřekl poslední slovo a schopnost být efektivnější a přitom nabízet ještě pokročilejší L7 služby v dedikovaných zpracovatelských prostředcích mi nezní špatně. O tomhle operátoři mluvili před 10 lety a různé SDN implementace typu Cisco ACI nebo VMWare NSX to zuřivě slibovaly, ale realita dnešního světa v cloudu je, že tam selhaly na celé čáře. Takže další iterace a tentokrát od hráčů co nemají na noze kouli své historie? Třebas, ale pro dnešek za mě - instrumentujte aplikace na monitoring a tracing a neřešte service mesh. Pokud potřebujete něco řešit ihned, šel bych asi stále do OSM (než bude Istio addon v GA), ale nabídka Istio v AKS je za mě super a tam kde potřebuji funkce navíc (třeba circuit breaker), bomba. Každopádně to sledujte - ambient mesh ukazuje, že se to může otočit trochu jiným a za mě užitečnějším směrem.

---