Istio, de software voor het inrichten en besturen van een service mesh binnen Kubernetes, wordt voortdurend verder ontwikkeld. In de 1.1 versie van de software is een begin gemaakt met multi-cluster service mesh. Daniel Berg van IBM presenteert aan de hand van een scenario bij een bestaande klant welke mogelijkheden er voor multi-cluster zijn en in welke richting Istio zich ontwikkelt. Maar eerst wordt een kort overzicht gegeven van Istio, waar het voor dient en hoe het wordt gebruikt.
Allereerst constateert IBM dat meerdere clusters eigenlijk meer regel dan uitzondering zijn. Elk productiecluster betekent vrijwel automatisch ook dat een ontwikkelcluster is. Maar ook om andere redenen zijn meerdere clusters wenselijk of noodzakelijk: bijvoorbeeld omdat het belangrijk is om compute dicht bij data te hebben, of workloads (of toegang daartoe) te kunnen isoleren.
Bij het huidige gebruik van Istio ziet IBM veel focus op beveiliging, in de vorm van het auditen van verkeer, het veilig deployen van workloads naar productie, het beperken van een attack vector op een cluster en het controleren van toegang tot een cluster. Met citadel, onderdeel van Istio, is dit goed in te regelen. Istio is daarmee niet aleen een manier om een mesh netwerk te beheren, maar ook om het verkeer in een dergelijk netwerk (en met de wereld er buiten) veilig te laten verlopen.
De koppeling tussen intern en extern verkeer en het veilig laten verlopen daarvan is bij veel klanten van IBM van groot belang. Veel van hen (ik vermoed zelfs het merendeel) is immers niet born in te cloud, waardoor er altijd een verbinding nodig is tussen applicaties die in de cloud leven en applicaties die on premise draaien. Een belangrijke use case voor Istio, in het verlengde van de al eerder genoemde beveiliging, is daarmee het veilig laten verlopen van verkeer, ook binnen het cluster en tussen pods. Het component dat hiermee belast is (TLS-encryptie tussen pods onderling) heet Citadel.
Istio bestaat uit vier onderdelen: Connect (met als doel traffic control, discovery, load balancing, resiliency), Secure (tls, authentication, authorization), Observe (metrics, log, trace), en Control (policies). Ieder onderdeel is afzonderlijk te deployen, hetgeen multi-cluster uitrol eenvoudiger en mogelijk maakt.
In een werkend prototype voor multi-cluster leest en controleert het component Galley de in YAML gedefinieerde configuratie van het cluster en draagt die vervolgens over aan Pilot, die het distribueert over de proxies binnen de clusters. Op de control plane (de besturingseenheid van Istio) draaien alle componenten, op de andere nodes in het cluster alleen de onderdelen die nodig zijn. Als er alleen pod-naar-pod TLS-encyptie nodig is, volstaat bijvoorbeeld de uitrol van Citadel op de nodes.
Er zijn echter nog wel belangrijke bezwaren die het werken van multi-cluster Istio lastig maken. Een belangrijke hiervan is Low latency tussen de clusters: bij een te hoge latency werkt multi-cluster niet behoorlijk.
Multi-cluster Istio is “Definitely not production ready”, maar biedt een goed beeld en proof-of-concept van de richting die de community inslaat. Multi-cluster is daarnaast het belangrijkste aandachtspunt voor het ontwikkelteam van IBM.
Als afsluiter vraagt IBM aan de aanwezige community om aan te geven waar ze bij de verdere ontwikkeling van Istio meer of minder aandacht aan moeten besteden. Een mooi gebaar, dat aangeeft dat er niet alleen echt wordt geluisterd naar de community, maar ook de toekomstige ontwikkelrichting te beïnvloeden en bepalen is.