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.
Er zijn twee officieel ondersteunde methodes voor de installatie van Istio:
In dit artikel zullen we ons richten op de eerste methode.
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:
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.
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 istiod container (de oude naam 'pilot' wordt gebruikt in het YAML-bestand)
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
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 installatiestroom kan als volgt worden voorgesteld:
De volledige installatiestroom volgt deze stappen:
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.
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:
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.
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.
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.
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'.
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/.
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.
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.
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:
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/.
Istio maakt gebruik van de gedistribueerde tracing mogelijkheden van Envoy om de verkeersstroom in kaart te brengen. Dit proces werkt als volgt:
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:
Dit voorbeeld illustreert hoe je met behulp van gedistribueerde tracing automatisch inzicht kunt krijgen in de applicaties en verbindingen binnen de Service Mesh.
Na het bespreken van de kenmerken van Istio Service Mesh, belichten we de belangrijkste voordelen:
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.