Istio is een van de meest bekende Service Mesh tools. Het fungeert als een proxy tussen services. Istio Service Mesh maakt het mogelijk om communicatie tussen services makkelijk te beheren, bewaken, beveiligen en schalen, zonder dat je deze functionaliteiten in de applicatiecode hoeft te implementeren. In dit artikel laten we stap voor stap zien hoe je Istio Service Mesh installeert. We tonen ook verschillende voorbeelden van de werking van Istio Service Mesh.

In ons eerste blogartikel, "Istio Service Mesh: Wat en waarom", hebben we uitgelegd wat Istio Service Mesh is en wat de voordelen ervan zijn. In dit artikel gaan we dieper in op de details en laten we zien hoe je Istio kunt implementeren en toepassen in praktische scenario's.

Istio installeren via istioctl: Stap voor stap

Er zijn twee officieel ondersteunde methodes voor de installatie van Istio:

• Via istioctl
• Met behulp van Helm grafieken

In dit artikel zullen we ons richten op de eerste methode.

STAP 1: Voorbereiding en documentatie

Voordat u begint met het installatieproces, is het cruciaal om de officiële documentatiete raadplegen . Controleer ook de compatibiliteitsmatrix om na te gaan welke versie van Istio compatibel is met uw Kubernetes-versie.

Met behulp van het hulpprogramma istioctl passen we een configuratiebestand toe op het cluster. Dit configuratiebestand zorgt ervoor dat de nodige componenten worden geïnstalleerd:

• Een ingress gateway die inkomend verkeer zal afhandelen
• Een egress gateway die het uitgaande verkeer zal afhandelen
• Istiod control plane, verantwoordelijk voor het afhandelen van certificaten en andere taken
• Een istio-proxy sidecar container toegevoegd aan elke pod in het cluster.

STAP 2: istioctl downloaden en installeren

Je kunt istioctl installeren door de volgende one-liner uit te voeren. Dit zal de laatste versie voor jouw architectuur downloaden:

curl -L https://istio.io/downloadIstio | sh -.

Je kunt ook een specifieke versie installeren door bepaalde omgevingsvariabelen op te geven:

curl -L https://istio.io/downloadIstio | ISTIO_VERSION=1.20.1 TARGET_ARCH=x86_64 sh - ISTIO_VERSION=1.20.1 TARGET_ARCH=x86_64.

STAP 3: IstioOperator.yaml bestand aanmaken

Het vereenvoudigen van de opzet voor het maken van een IstioOperator.yaml bestand met informatie over de gewenste Service Mesh configuratie kan als volgt worden bereikt:

Dit YAML-bestand beschrijft de configuratie van de volgende componenten:

• 2x istio-ingressgateway container
• 2x istio-egressgateway container

2x istiod container (de oude naam 'pilot' wordt gebruikt in het YAML-bestand)

• Voor proxy sidecars stellen we een geheugenlimiet in van 100Mi, die zal draaien als een extra container in je applicatie pods.

STAP 4: Configuratie toepassen met upgrademogelijkheid

Om de bovenstaande configuratie toe te passen, voert u het volgende commando uit:

~/istio-1.20.1/bin/istioctl install --set revision=1-20-1 -f IstioOperator.yaml

We voegen een revisie toe aan ons installatiecommando om een nieuwere versie van Istio te installeren naast de bestaande versie. Eenmaal uitgerold en gevalideerd, kunnen we volledig overschakelen naar de nieuwe versie. Dit is een cruciale stap om upgrades mogelijk te maken zonder downtime.

Het is belangrijk om op te merken dat we het installatiecommando meerdere keren kunnen uitvoeren. Zelfs voor kleine veranderingen zullen we dit commando gebruiken omdat Istioctl de "reconciliation" methode gebruikt. De gespecificeerde configuratie in het bestand IstioOperator.yaml wordt vergeleken met de huidige status op het cluster en alleen de noodzakelijke wijzigingen om de beschreven situatie te bereiken worden uitgevoerd.

Na het uitvoeren van het installatiecommando worden de volgende POD's toegevoegd aan het cluster:

NAAM GEREED STATUS HERSTARTS

istio-egressgateway-f66c5597-9t9g8 1/1 Loopt 0

istio-egressgateway-f66c5597-p4nsq 1/1 Loopt 0

istio-ingressgateway-58bcd84f68-fqxhz 1/1 Lopend 0

istio-ingressgateway-58bcd84f68-sdqjv 1/1 Lopend 0

istiod-1-20-1-5558b9b4f6-p8kw7 1/1 Lopend 0

istiod-1-20-1-5558b9b4f6-pchdv 1/1 Loopt 0

STAP 5: Zijspancontainers toevoegen aan POD's

Na het installeren van istiod, ingress-gateway en egress-gateway, is het essentieel om ervoor te zorgen dat de proxy sidecar containers worden toegevoegd aan onze applicatie PODs. Ten eerste moeten we "istio-injection" configureren door een label toe te voegen aan de namespace waar de applicatie draait.

Vervolgens kunnen we een rollende herstart van de applicatie uitvoeren. Dit zorgt ervoor dat elke container herstart met een sidecar container.

Merk op dat 2 van de 2 containers klaar zijn:

NAAM KLAAR STATUS HERSTARTS

maildev-544f69466b-lp4hg 2/2 Loopt 0

Het bovenstaande proces moet voor elke toepassing worden uitgevoerd.

De volledige installatie

De volledige installatiestroom kan als volgt worden voorgesteld:

De volledige installatiestroom volgt deze stappen:

1. Het verkeer komt de ingress gateway binnen.
2. De ingress gateway stuurt het verkeer door naar de proxy van applicatie 1.
3. Verkeer gaat door de proxy van toepassing 2.
4. Verkeer gaat naar buiten via een egress gateway.

Merk op dat zowel de ingress gateway, de proxy sidecar containers en de egress gateway een Envoy proxy gebruiken. Alle communicatie vindt plaats via wederzijdse SSL, automatisch geconfigureerd zodra de sidecar containers zijn toegevoegd. De istiod applicatie heeft een certificaatautoriteit die automatisch certificaten genereert om het verkeer tussen de verschillende Envoy proxy's te versleutelen. Het versleutelen van verkeer is een belangrijke reden om voor Istio Service Mesh te kiezen.

Verkeer naar onze applicatie krijgen

Nu we Istio Service Mesh operationeel hebben, is ons eerste doel om verkeer via de ingress gateway naar onze applicaties te leiden. In dit geval gebruiken we niet de standaard 'Ingress' resource die Kubernetes standaard levert. Istio voegt een aantal mogelijkheden in verkeersbeheer toe die niet kunnen worden bereikt met een standaard Ingress-object. Daarom levert Istio zijn eigen Custom Resources.

In dit scenario gebruiken we een Gateway en een VirtualService object. Wanneer deze bronnen worden toegevoegd aan het cluster, wordt de Envoy proxy configuratie gegenereerd op basis van de geleverde configuratie. Deze configuratie zorgt ervoor dat verkeer naar de applicatie mogelijk is. In eerste instantie maken we een Gateway object.

Vervolgens maken we een VirtualService:

Dit verwijst naar een maildev service, die dan zal verwijzen naar de respectievelijke PODs.

Het volgende diagram geeft dit visueel weer:

Voorbeelden van verkeersbeheer met Istio

Hoewel we met succes verkeer naar onze applicatie hebben geleid, biedt Istio nog geavanceerdere scenario's voor verkeersbeheer. Ik wil graag wat dieper ingaan op enkele van deze mogelijkheden. Je kunt een uitgebreide lijst vinden in de officiële documentatie: https://istio.io/latest/docs/tasks/traffic-management/

In de volgende voorbeelden wordt verkeer gerouteerd tussen verschillende versies van een applicatie. Voordat we deze versies van de applicatie kunnen benaderen, moeten de benodigde bronnen worden aangemaakt. Er moet een deployment en de bijbehorende service worden aangemaakt, zoals beschreven in de sectie 'overzichten' op https://raw.githubusercontent.com/istio/istio/release-1.20/samples/bookinfo/platform/kube/bookinfo.yaml.

Vervolgens moeten voor elke versie DestinationRules worden aangemaakt, zoals beschreven in de sectie 'reviews' op https://raw.githubusercontent.com/istio/istio/release-1.20/samples/bookinfo/networking/destination-rule-all.yaml.

Routing van verzoeken

Met request routing leiden we een deel van het verkeer om naar een andere versie van de applicatie. In het onderstaande voorbeeld wordt het verkeer in eerste instantie standaard omgeleid naar 'reviews v1'. Dit verandert echter als de 'end-user' header de waarde 'jason' bevat; in dat geval wordt het verkeer omgeleid naar versie 2. Het concept van verzoekroutering kan waardevol zijn wanneer je een nieuwe versie van een applicatie implementeert, maar deze nog een laatste keer grondig wilt testen voordat je deze aan een breder publiek blootstelt.

Verkeer verschuiven

Bij traffic shifting passen we het principe van gewogen routering toe. We sturen een deel van de verzoeken naar versie 1 en een ander deel naar versie 2. Dit kan handig zijn voor een geleidelijke migratie naar een nieuwe versie.

Foutinjectie

Bij foutinjectie introduceren we opzettelijk fouten, zoals vertragingen of foutcodes, om te onderzoeken hoe onze configuratie reageert. Dit is handig voor het identificeren van misconfiguraties, zoals discrepanties in timeouts tussen loadbalancers, Envoy en timeouts op applicatieniveau, en ook voor het aanwijzen van knelpunten.

In het volgende voorbeeld introduceren we een vertraging van 7 seconden voor verzoeken naar versie 1 van de applicatie, maar alleen voor verzoeken met de header 'end-user' en de waarde 'jason'. Alle andere verzoeken worden niet beïnvloed door deze configuratie en worden gewoon afgehandeld.

Een andere mogelijke fout die je kunt introduceren is het genereren van een foutcode door het foutblok uit het vorige voorbeeld te vervangen. Dit zorgt ervoor dat de Envoy proxy een HTTP 500 fout terugstuurt voor verzoeken met de 'end-user' header en de waarde 'jason'.

Beveiligingsbeleid met Istio

Vanuit een beveiligingsperspectief biedt Istio verschillende configuraties. Hieronder behandelen we er enkele, maar voor meer details kunt u kijken op: https://istio.io/latest/docs/tasks/security/.

Verkeersversleuteling binnen het netwerk

Zoals eerder vermeld, bevat Istio een certificaatautoriteit. Zodra Istio sidecars zijn toegevoegd aan de applicatie PODs, wordt het verkeer tussen verschillende applicaties versleuteld. Een bijkomend voordeel is dat alles wat met versleuteling te maken heeft niet meer door de applicatie zelf afgehandeld hoeft te worden.

Authenticatiebeleid

Wanneer identiteitsverificatie vereist is voordat iemand kan inloggen, kan dit proces via Istio worden beheerd. Istio controleert of de gebruiker een geldig JWT token heeft om toegang te krijgen tot de applicatie. Dit wordt geconfigureerd met een RequestAuthentication-object en een aanpassing in de VirtualService. Het RequestAuthentication-object activeert JWT-validatie voor onze applicatie.

Vervolgens configureren we onze applicatie zo dat de gebruiker alleen toegang heeft als de claim een specifieke waarde bevat.

Merk op dat de authenticatieconfiguratie niet langer direct in de applicatie hoeft te worden ingesteld; het wordt nu afgehandeld door Istio. Dit resulteert in minder complexiteit bij het instellen van de applicatie en meer consistentie bij het afhandelen van authenticatie voor verschillende applicaties binnen het cluster.

Autorisatiebeleid

Met Autorisatiebeleid hebben we de mogelijkheid om de toegang tot de applicatie te beheren. Een eenvoudig voorbeeld is iedereen de toegang tot een bepaald pad ontzeggen. Je zou bijvoorbeeld een bepaald eindpunt kunnen hebben dat niet toegankelijk mag zijn van buitenaf, maar wel intern toegankelijk moet zijn voor specifieke acties.

Andere voorbeelden zijn:

• Toegang weigeren wanneer een specifieke header ontbreekt.
• Toegang weigeren op basis van de inhoud van het verkregen JWT token, bijvoorbeeld geen lid zijn van de 'admin' groep.
• Alleen bepaalde HTTP-methodes toestaan op een eindpunt, bijvoorbeeld alleen GET toestaan en geen POST.

Waarneembaarheid met Istio

De laatste belangrijke functie die we zullen bespreken is observeerbaarheid. Hierbij gaat het om het verzamelen van metrics en logs en het toepassen van gedistribueerde tracing. Hier richten we ons specifiek op tracing; voor informatie over andere aspecten kunt u de documentatie raadplegen: https://istio.io/latest/docs/tasks/observability/.

Gedistribueerde tracering

Istio maakt gebruik van de gedistribueerde tracing mogelijkheden van Envoy om de verkeersstroom in kaart te brengen. Dit proces werkt als volgt:

• Verkeer komt binnen via de ingress gateway, die een specifieke tracing header toewijst.
• Wanneer het verkeer wordt doorgestuurd naar de applicatie POD, wordt de tracing header meegenomen.
• Als het verkeer opnieuw wordt doorgestuurd (bijvoorbeeld naar Kafka), wordt dezelfde header meegestuurd.

Hierdoor is dezelfde header bekend tussen de ingress gateway, de applicatie en Kafka. De traceringsinformatie tussen twee objecten, zoals de ingress gateway en de applicatie, wordt een 'span' genoemd. Meerdere spans, als ze dezelfde informatie in de header bevatten, kunnen gecombineerd worden tot een 'trace'.

In dit voorbeeld is er een spoor dat loopt van de ingress gateway via de applicatie naar Kafka. De spans en traces kunnen visueel worden weergegeven in tools zoals Kiali en Jaeger. De schermafbeelding hieronder toont de visualisatie van tracing in Kiali.

Op basis van de tracinginformatie werd de volgende stroom automatisch in kaart gebracht:

• Er is een applicatie met de naam CRM.
• Er is verkeer tussen de ingress gateway en de CRM-toepassing.
• Er is verkeer tussen de CRM-applicatie en Kafka.
• Kafka gebruikt Zookeeper voor clustering.
• De meerdere Zookeeper nodes in het cluster communiceren ook met elkaar.

Dit voorbeeld illustreert hoe je met behulp van gedistribueerde tracing automatisch inzicht kunt krijgen in de applicaties en verbindingen binnen de Service Mesh.

De voordelen van Istio Service Mesh

Na het bespreken van de kenmerken van Istio Service Mesh, belichten we de belangrijkste voordelen:

• Encryptie van verkeer: Verkeer binnen het cluster wordt versleuteld en de benodigde certificaten worden automatisch beheerd door Istio.
• Uniformiteit en vereenvoudiging: Verantwoordelijkheden zoals login, authenticatie en encryptie worden weggehaald bij de applicatie, wat resulteert in een uniforme en sterk vereenvoudigde setup.
• Versiebeheer: Routing regels maken het mogelijk om nieuwe versies van applicaties uit te rollen voor een beperkt publiek.
• Robuust testen: Testmogelijkheden zoals traffic shifting en foutinjectie dragen bij aan robuustheid.
• Dynamisch overzicht: Gedistribueerde tracing biedt een automatisch en actueel overzicht van de hele stack.

Meer informatie over Istio

Als je meer wilt weten over Istio, raadpleeg dan de officiële documentatie van Istio of lees het boek 'Istio in Action', een technisch diepgaande maar heldere presentatie van Istio.