We beginnen een serie berichten waarin we enkele van de vele mogelijkheden van de Istio Service Mesh demonstreren in combinatie met Red Hat OpenShift en Kubernetes.
Deel één, vandaag:
- We leggen het concept van sidecar-containers in Kubernetes uit en formuleren het leitmotiv van deze serie berichten: «je hoeft niets aan je code te veranderen».
- We introduceren de fundamentele zaak van Istio – routeregels. Hierop zijn alle andere mogelijkheden van Istio gebaseerd, omdat deze regels het mogelijk maken om verkeer naar microservices te sturen met behulp van YAML-bestanden die extern aan de code zijn. Ook behandelen we het schema voor Canary Deployment. Nieuwjaarsbonus – 10 interactieve sessies over Istio.
Deel twee, die binnenkort verschijnt, vertelt je:
- Hoe Istio Pool Ejection implementeert in combinatie met Circuit Breaker en demonstreert hoe Istio het mogelijk maakt om niet-functionele of slecht functionerende pods uit het load balancing-schema te verwijderen.
- Daarnaast bekijken we het onderwerp Circuit Breaker uit het eerste bericht om te zien hoe Istio hierbij kan worden ingezet. We laten zien hoe we verkeer kunnen routeren en netwerkfouten kunnen afhandelen zonder enige wijzigingen in de servicecode, met behulp van YAML-configuratiebestanden en terminalcommando's.
Deel drie:
- Een verhaal over tracing en monitoring, die al zijn ingebouwd of gemakkelijk kunnen worden toegevoegd aan Istio. We laten zien hoe je tools zoals Prometheus, Jaeger en Grafana kunt gebruiken in combinatie met de schaalbaarheid van OpenShift, zodat je zonder veel moeite je microservices-architectuur kunt beheren.
- We gaan van monitoring en foutafhandeling naar het opzettelijk invoeren van fouten in het systeem. Met andere woorden, we leren hoe we fault injection kunnen doen zonder de broncode te wijzigen, wat heel belangrijk is vanuit het perspectief van testen – omdat als we de code hiervoor moeten wijzigen, we het risico lopen om extra fouten in te voeren.
Ten slotte, in het laatste bericht over de Istio Service Mesh:
- Gaan we naar de Donkere Kant. Sterker nog, we leren hoe we het Dark Launch-schema kunnen gebruiken, waarbij code wordt uitgerold en getest met echte productiegegevens, zonder de werking van het systeem te beïnvloeden. Hier komt de vaardigheid van Istio om verkeer te splitsen goed van pas. De mogelijkheid om te testen met echte productiegegevens zonder invloed op de werking van het live systeem is de meest overtuigende manier om te valideren.
- Uitgaande van Dark Launch laten we zien hoe je het Canary Deployment-model kunt gebruiken om risico's te verkleinen en de implementatie van nieuwe code te vereenvoudigen. Canary Deployment zelf is niet nieuw, maar Istio maakt het mogelijk om dit schema te implementeren met slechts een paar eenvoudige YAML-bestanden.
- Tot slot laten we zien hoe je met Istio Egress toegang kunt geven tot services voor diegenen die zich buiten je clusters bevinden, zodat je de mogelijkheden van Istio kunt benutten tijdens het werken met het internet.
Dus, laten we beginnen …
De monitoring- en beheertools van Istio - alles wat je nodig hebt voor de coördinatie van microservices in een service mesh .
Wat is de service mesh Istio
De service mesh implementeert voor een groep diensten functies zoals verkeersmonitoring, toegangscontrole, ontdekking, beveiliging, fouttolerantie en andere nuttige zaken. Istio stelt je in staat om dit alles te doen zonder enige wijziging in de code van de diensten zelf. Wat is het geheim van deze magie? Istio koppelt een proxy in de vorm van een sidecar-container aan elke dienst, waarna al het verkeer naar deze dienst via de proxy gaat, die op basis van de ingestelde beleidsregels beslist hoe, wanneer en of dit verkeer de dienst überhaupt bereikt. Istio biedt ook de mogelijkheid om geavanceerde DevOps-technieken te implementeren, zoals canary deployments, circuit breakers, foutinjectie en nog veel meer.
Hoe Istio werkt met containers en Kubernetes
De service mesh Istio is een sidecar-implementatie van alles wat nodig is voor het creëren en beheren van microservices: monitoring, tracing, circuit breakers, routering, laadbalancering, foutinjectie, herhalingen, time-outs, mirroren, toegangscontrole, snelheidsbeperkingen en nog veel meer. En hoewel er tegenwoordig veel bibliotheken zijn om deze functies rechtstreeks in de code te implementeren, kun je met Istio hetzelfde krijgen zonder iets in je code te veranderen.
Volgens het sidecar-model draait Istio in een Linux-container die zich in dezelfde -pod bevindt als de gecontroleerde dienst en injecteert (inject) en haalt (extract) functionaliteit en informatie op volgens de opgegeven configuratie. We benadrukken dat dit jouw eigen configuratie is, en deze leeft buiten jouw code. Hierdoor wordt de code veel eenvoudiger en korter.
Wat ook belangrijk is, is dat de operationele component van microservices niets te maken heeft met de code zelf, wat betekent dat hun exploitatie zonder problemen aan IT-specialisten kan worden overgedragen. Inderdaad, waarom zou een ontwikkelaar verantwoordelijk moeten zijn voor circuit breakers en fault injection? Reageren – ja, maar ze behandelen en creëren? Als we dit alles uit de code verwijderen, kunnen programmeurs zich volledig concentreren op de applicatiefuncties. Bovendien zal de code zelf korter en eenvoudiger worden.
Service Mesh
Istio, dat functies voor microservicesbeheer buiten hun code implementeert – dat is het concept van de Service Mesh. Met andere woorden, het is een gecoördineerde groep van een of meerdere binaries die een netwerk van netwerkfuncties vormen.
Hoe Istio werkt met microservices
Zo ziet de samenwerking van sidecar-containers eruit met en vanuit vogelperspectief: je start een instantie van Minishift, maakt een project voor Istio aan (laten we het 'istio-system' noemen), installeert en start alle componenten die met Istio zijn verbonden. Vervolgens, terwijl je projecten en pods aanmaakt, voeg je configuratie-informatie toe aan je deployments, en beginnen je pods Istio te gebruiken. In vereenvoudigde vorm ziet het diagram eruit als volgt:
Nu kun je de instellingen van Istio aanpassen om bijvoorbeeld fault injection te organiseren, ondersteuning voor of andere mogelijkheden van Istio – en dat allemaal zonder de code van de applicaties zelf aan te raken. Stel dat je al het webverkeer van gebruikers van je grootste klant (Foo Corporation) naar de nieuwe versie van de website wilt omleiden. Het enige wat je hoeft te doen is een Istio-routeringsregel aan te maken die zoekt naar @foocorporation.com in de gebruikers-ID en de overeenkomstige omleiding uitvoert. Voor alle andere gebruikers verandert er niets. En ondertussen kun je met een gerust hart de nieuwe versie van de website testen. En merk op dat je hiervoor helemaal geen ontwikkelaars hoeft in te schakelen.
En moet je daar veel voor betalen?
Zeker niet. Istio werkt behoorlijk snel, het is geschreven in en creëert een zeer kleine overhead. Bovendien wordt eventuele afname van de online prestaties gecompenseerd door de toename van de productiviteit van ontwikkelaars. Althans in theorie: vergeet niet dat de tijd van ontwikkelaars kostbaar is. Wat betreft de kosten voor de software, Istio is open-source, dus je kunt het gratis verkrijgen en gebruiken.
Leer zelf
Het team van Red Hat Developer Experience heeft een diepgaand praktisch over Istio (in het Engels) ontwikkeld. Het werkt op Linux, MacOS en Windows, en de code is beschikbaar in versies voor Java en Node.js.
10 interactieve sessies over Istio
Blok 1 – Voor beginners
Inleiding tot Istio
30 minuten
Leren over Service Mesh, we leren Istio te installeren in een Kubernetes-cluster op OpenShift.
Microsystemen implementeren in Istio
30 minuten
We gebruiken Istio om drie microsystemen met Spring Boot en Vert.x te implementeren.
Blok 2 – Gemiddeld niveau
Monitoring en tracing in Istio
60 minuten
We verkennen de ingebouwde monitoringtools van Istio, configureerbare statistieken, en OpenTracing via Prometheus en Grafana.
Eenvoudige routing in Istio
60 minuten
We leren routing in Istio te beheren met eenvoudige regels.
Geavanceerde routingregels
60 minuten
We maken kennis met slimme routing in Istio, toegangsbeheer, load balancing en throttling.
Blok 3 – Gevorderde gebruiker
Fault Injection in Istio
60 minuten
We bestuderen foutafhandelingsscenario's in gedistribueerde applicaties door HTTP-fouten en netwerklatency te creëren en leren chaos engineering toe te passen voor herstellende omgevingen.
Circuit Breaker in Istio
30 minuten
We installeren Siege voor stress-testing van websites en leren hoe we de veerkracht van de backend kunnen waarborgen met herhalingen, circuit breaker en pool ejection.
Egress en Istio
10 minuten
We gebruiken Egress-routes om regels te creëren voor de interactie van interne services met externe API's en services.
Istio en Kiali
15 minuten
We leren Kiali gebruiken voor een algemeen overzicht van de service mesh en het bestuderen van de stromen van verzoeken en gegevens.
Mutual TLS in Istio
15 minuten
We creëren een Istio Gateway en VirtualService, en bestuderen vervolgens mutual TLS (mTLS) en de configuraties ervan.
Blok 3.1 – Diepgaande: Istio Service Mesh voor microsystemen
Waar gaat het boek over:
- Wat is een service mesh.
- Het systeem Istio en zijn rol in microservicesarchitecturen.
- Gebruik van Istio bij het aanpakken van de volgende uitdagingen:
- Veerkracht;
- Routing;
- Chaos-testing;
- Beveiliging;
- Het verzamelen van telemetrie met behulp van tracing, metrics en Grafana.
Serie artikelen over service meshes en Istio
Probeer het zelf
Deze serie berichten heeft niet als doel een diepgaande duik in de wereld van Istio te bieden. We willen je gewoon kennis laten maken met het concept en misschien inspireren om zelf met Istio aan de slag te gaan. Dit kan volledig gratis, en Red Hat biedt alle benodigde tools om OpenShift, Kubernetes, Linux-containers en Istio te leren kennen, namelijk: , en andere bronnen op onze . Stel het niet uit, begin vandaag nog!
Routing regels van Istio: we sturen service-aanvragen naar de juiste plek
en maakt uitstekend mogelijk dat verzoeken naar worden gerouteerd naar de juiste pods. Dit is een van de doelen van Kubernetes – routing en load balancing. Maar wat als je fijnere en geavanceerdere routing nodig hebt? Bijvoorbeeld, om gelijktijdig twee versies van een microservice te gebruiken. Hoe kunnen de routingregels van Istio daarin helpen?
Routingregels zijn regels die de routekeuze vaststellen. Ongeacht het niveau van systeemcomplexiteit blijft het algemene principe van deze regels eenvoudig: aanvragen worden gerouteerd op basis van bepaalde parameters en de waarden van HTTP-headers.
Laten we eens kijken naar voorbeelden:
Kubernetes standaard: triviale '50-50'
In ons voorbeeld laten we zien hoe je twee versies van een microservice tegelijkertijd in OpenShift kunt gebruiken, noemen we ze v1 en v2. Elke versie draait in zijn eigen Kubernetes-pod, en standaard is hier een gelijkmatig gebalanceerde ronde-robin routing actief. Elke pod ontvangt zijn deel van de aanvragen op basis van het aantal instanties van zijn microservice, met andere woorden, replicas. Istio maakt het mogelijk om deze balans handmatig te wijzigen.
Stel dat we twee versies van onze aanbevelingsdienst hebben uitgerold op OpenShift, recommendation-v1 en recommendation-v2.
In fig. 1, it can be seen that when each service is presented as a single instance, requests alternate evenly between them: 1-2-1-2-… This is how Kubernetes routing works by default:
Weighted distribution between versions
In fig. 2, we see what happens if we increase the number of replicas of service v2 from one to two (this is done using the command oc scale —replicas=2 deployment/recommendation-v2). As we can see, requests between v1 and v2 are now divided in a ratio of 'one to three': 1-2-2-1-2-2-…:
Ignoring version with Istio
Istio allows us to easily change the distribution of requests in the way we need. For example, we can send all traffic only to recommendation-v1 using the following Istio yaml file:
It is important to note that pods are selected according to labels. In our example, the label v1 is used. The parameter 'weight: 100' means that 100% of the traffic will be routed to all pods of the service that have the label v1.
Directive distribution between versions (Canary Deployment)
Next, using the weight parameter, we can direct traffic to both pods, ignoring the number of instances of microservices running in each. For example, here we directive route 90% of the traffic to v1 and 10% to v2:
Separate routing for mobile users
In conclusion, we will demonstrate how to forcibly route mobile user traffic to service v2 while routing all others to v1. For this, we analyze the user-agent value in the request header using regular expressions:
Now it's your turn
An example with regular expressions for analyzing headers should motivate you to search for your own ways to apply Istio routing rules. Moreover, the possibilities here are quite extensive, since header values can be formed in the source code of applications.
And remember, it's Ops, not Dev
Everything we've shown in the examples above can be done without making the slightest changes to the source code, except in cases where special request headers need to be formed. Istio will be useful for developers, who can apply it during the testing phase, as well as for IT operations specialists, who will find it very helpful in production.
So let's repeat the leitmotif of this series of posts: you don't need to change anything in your codeJe hoeft geen nieuwe afbeeldingen te verzamelen of nieuwe containers te starten. Dit wordt allemaal buiten de code gerealiseerd.
Laat je verbeelding de vrije loop
Stel je voor welke mogelijkheden de analyse van koppen met behulp van reguliere expressies opent. Wil je jouw grootste klant doorverwijzen naar een speciale versie van zijn ? Легко! Нужна отдельная версия для браузера Chrome? Не проблема! Вы можете маршрутизировать трафик практически по любой его характеристике.
Probeer het zelf
Lezen over Istio, Kubernetes en OpenShift is één ding, maar waarom zou je het niet zelf uitproberen? Het team van heeft een gedetailleerde handleiding (in het Engels) voorbereid die je helpt deze technologieën zo snel mogelijk te beheersen. De handleiding is ook 100% open source, dus deze is openbaar toegankelijk. Het bestand werkt op macOS, Linux en Windows, en de broncode is beschikbaar in Java en node.js (versies in andere talen komen binnenkort). Open simpelweg de bijbehorende git-repository in je browser .
In de volgende post: we pakken de problemen mooi aan
Vandaag heb je gezien wat de routeringsregels van Istio kunnen doen. En stel je nu hetzelfde voor, maar dan toepasbaar op foutafhandeling. Dit is waar we het in de volgende post over zullen hebben.
Bron: habr.com
