«Het gevaar is mijn tweede naam», zei Austin Powers, een internationale man van mysterie. Maar wat in de gunst staat bij superagenten en inlichtingendiensten, is totaal ongeschikt voor computerdiensten, waar verveling veel beter is dan gevaar.
Samen maken Istio, OpenShift en Kubernetes de implementatie van microservices echt saai en voorspelbaar – en dat is geweldig. Hierover en nog veel meer zullen we praten in de vierde en laatste post van de serie over Istio.
Wanneer verveling juist is
In ons geval ontstaat verveling pas in de laatste fase, wanneer je alleen maar kunt zitten en kijken naar het proces. Maar daarvoor moet alles eerst goed worden ingesteld en daar wacht veel interessants op je.
Bij het implementeren van een nieuwe versie van je software is het belangrijk om alle opties voor risico-vermijding te overwegen. Werken in parallelle modus is een zeer krachtige en beproefde testmethode, en Istio stelt je in staat om hiervoor de 'geheime dienst' (de verborgen versie van je microservice die niet zichtbaar is voor buitenstaanders) in te schakelen zonder de productieomgeving te verstoren. Hiervoor is er zelfs een speciale term – 'Dark Launch', die wordt geactiveerd door de functie met de niet minder spionageachtige naam 'traffic mirroring'.
Let op dat in de eerste zin van de vorige alinea de term 'implementatie' (deploy) wordt gebruikt in plaats van 'uitgave' (release). Je moet in staat zijn om je microservice te implementeren – en uiteraard te gebruiken – zo vaak als je wilt. Deze service moet in staat zijn om verkeer te ontvangen en te verwerken, resultaten te leveren, en ook logboeken te schrijven en gemonitord te worden. Maar je hoeft deze service nog niet in productie te nemen. Implementatie en uitgave van software zijn niet altijd hetzelfde. Implementatie kun je altijd uitvoeren wanneer je wilt, terwijl uitgave alleen kan gebeuren wanneer je volledig klaar bent.
Het organiseren van verveling is interessant
Kijk eens naar de volgende routeringsregel van Istio, die alle HTTP-aanvragen naar de microservice recommendation v1 leidt (alle voorbeelden zijn afkomstig uit ), terwijl ze tegelijkertijd worden gespiegeld naar de microservice recommendation v2:
Let op het label mirror: onderaan het scherm – dat zorgt voor het spiegelen van verkeer. Ja, zo eenvoudig!
Het resultaat van deze regel is dat jouw productie-systeem (v1) nog steeds de binnenkomende verzoeken zal verwerken, maar dat de verzoeken tegelijkertijd asynchroon worden gespiegeld naar v2, wat betekent dat daar volledige duplicaten naartoe gaan. Op deze manier kun je v2 testen in echte omstandigheden - met echte data en verkeer - zonder in te grijpen in de werking van het productie-systeem. Maakt dit de testorganisatie saai? Ja, absoluut. Maar het wordt op een interessante manier gedaan.
Laten we wat drama toevoegen
Let op dat je in de code van v2 rekening moet houden met situaties waarin de binnenkomende verzoeken tot gegevenswijzigingen kunnen leiden. De verzoeken worden eenvoudig en transparant gespiegeld, maar de keuze van de verwerkingsmethode in de test blijft aan jou - en dat maakt het al een beetje spannend.
Laten we een belangrijk punt herhalen
Een geheime lancering met verkeersspiegelen (Dark Launch/Request Mirroring) kan plaatsvinden zonder de code aan te raken.
Voedsel voor gedachte
En wat als we in plaats van de verzoeken te spiegelen, een deel ervan niet naar v1, maar naar v2 sturen? Bijvoorbeeld één procent van alle verzoeken of alleen verzoeken van een bepaalde gebruikersgroep. En dan, terwijl we kijken hoe v2 presteert, geleidelijk alle verzoeken naar de nieuwe versie verplaatsen. Of andersom, alles terugzetten naar v1 als er iets misgaat met v2. Dit lijkt op Canary Deployment ("kanarie-uitrol" - een term , en als het een Russische oorsprong had, zou het waarschijnlijk een verwijzing bevatten naar ), en nu zullen we dit verder bespreken.
Canary Deployment in Istio: vereenvoudiging van de invoering
Voorzichtig en geleidelijk
De essentie van het Canary Deployment-model is buitengewoon eenvoudig: wanneer je een nieuwe versie van je software (in ons geval - microservice) lanceert, geef je eerst toegang tot een kleine groep gebruikers. Als alles goed gaat, vergroot je langzaam deze groep totdat de nieuwe versie begint te falen, of - als dat niet gebeurt - uiteindelijk alle gebruikers naar die versie verhuist. Door de nieuwe versie doordacht en geleidelijk in gebruik te nemen en gecontroleerd gebruikers over te schakelen, kun je de risico's verlagen en de feedback maximaliseren.
Natuurlijk maakt Istio Canary Deployment eenvoudiger door verschillende goede opties voor slimme routering van verzoeken aan te bieden. En ja, dit alles kan worden gedaan zonder uw oorspronkelijke code aan te raken.
Filter browser
Een van de eenvoudigste routeringscriteria is het doorsturen op basis van de browser. Stel dat u wilt dat alleen verzoeken van de Safari-browser naar v2 gaan. Zo doet u dat:
Laten we deze routeringsregel toepassen en vervolgens met het commando curl reële verzoeken naar de microservice simuleren in een loop. Zoals te zien is op de screenshot, gaan al deze verzoeken naar v1:
En waar blijft het verkeer naar v2? Aangezien in ons voorbeeld alle verzoeken alleen uit onze eigen commandoregel kwamen, is er eenvoudigweg geen verkeer. Maar let op de onderste regels op de afbeelding hierboven: dit was de reactie toen we een verzoek vanuit de Safari-browser uitvoerden, die het volgende teruggeef:
Onbeperkte macht
We hebben al vermeld dat reguliere expressies krachtige mogelijkheden bieden voor routering van verzoeken. Kijk naar het volgende voorbeeld (we denken dat u zelf zult begrijpen wat het doet):
Nu kunt u zich waarschijnlijk al voorstellen wat reguliere expressies kunnen.
Handel slim
Slimme routering, met name het verwerken van pakketheaders met behulp van reguliere expressies, stelt u in staat om het verkeer te sturen zoals u wilt. En dit maakt het in gebruik nemen van nieuwe code aanzienlijk eenvoudiger – het is eenvoudig, vereist geen wijzigingen in de code zelf en kan zo nodig snel worden teruggedraaid.
Geïnteresseerd?
Heeft u de drang om te experimenteren met Istio, Kubernetes en OpenShift op uw computer? Het team heeft een geweldige over dit onderwerp voorbereid en alle bijbehorende bestanden openbaar gemaakt. Dus ga ervoor en schroom niet.
Istio Egress: de uitgang via een souvenirwinkel
Door Istio samen met Red Hat OpenShift en Kubernetes toe te passen, kunt u uw leven met microservices aanzienlijk vergemakkelijken. Het service mesh van Istio is ondergebracht in de Kubernetes-pods, terwijl uw code (groeiend is) in isolatie wordt uitgevoerd. Prestaties, eenvoud van wijzigingen, tracing en meer – alles is gemakkelijk te gebruiken dankzij de toepassing van sidecar-containers. Maar wat als uw microservice moet communiceren met andere services die zich buiten uw OpenShift-Kubernetes-systeem bevinden?
Hier komt Istio Egress in het spel. In het kort, het stelt je in staat toegang te krijgen tot bronnen (lees: "services") die niet binnen je Kubernetes pod-systeem vallen. Zonder extra configuratie wordt het verkeer in de Istio Egress-omgeving alleen binnen de pod-cluster en tussen dergelijke clusters gerouteerd op basis van interne IP-tabellen. En dit idee werkt prima totdat je toegang nodig hebt tot externe services.
Egress maakt het mogelijk om de bovengenoemde IP-tabellen te omzeilen, hetzij op basis van Egress-regels, hetzij voor een reeks IP-adressen.
Stel dat we een Java-programma hebben dat een GET-verzoek doet naar httpbin.org/headers.
(httpbin.org is gewoon een handige resource voor het testen van uitgaande serviceverzoeken.)
Als we in de commandolijn invoeren curl http://httpbin.org/headers, zien we het volgende:
Of we kunnen hetzelfde adres in de browser openen:
Zoals we zien, geeft de service daar gewoon de verzonden headers terug.
Importvervanging recht voor zijn raap
Laten we nu de Java-code van deze externe service in relatie tot ons systeem nemen en deze lokaal uitvoeren, waar, ter herinnering, Istio draait. (Je kunt dit zelf doen door naar .) Door het bijbehorende beeld samen te stellen en het op het OpenShift-platform te draaien, zullen we deze service aanroepen met het commando curl egresshttpbin-istioegress.$(minishift ip).nip.io, waarna we het volgende op het scherm zien:
Hè, wat is er gebeurd? Het werkte net nog. Wat betekent Not Found? We hebben toch net voor hem gemaakt? curl.
We breiden de IP-tabellen uit naar het hele internet
Je kunt Istio de schuld geven (of bedanken) voor dit probleem. Immers, Istio zijn gewoon sidecar-containers die verantwoordelijk zijn voor detectie en routering (en vele andere zaken waar we eerder over hebben gesproken). Daarom weten de IP-tabellen alleen wat zich binnen jouw cluster bevindt. Httpbin.org bevindt zich extern en is dus niet toegankelijk. En hier komt Istio Egress van pas – zonder enige wijziging in je broncode.
De onderstaande Egress-regel dwingt Istio om (indien nodig zelfs in het hele wereldwijde internet) de benodigde service te zoeken, in dit geval httpbin.org. Zoals blijkt uit dit bestand (egress_httpbin.yml), is de functionaliteit hier vrij eenvoudig:
Je hoeft dit regel alleen maar toe te passen:
istioctl create -f egress_httpbin.yml -n istioegress
Je kunt de Egress-regels bekijken met het commando istioctl get egressrules:
En uiteindelijk starten we het commando opnieuw curl – en zien we dat alles werkt:
Denk open
Zoals je ziet, stelt Istio je in staat om interactie met de externe wereld te organiseren. Met andere woorden, je kunt nog steeds OpenShift-services maken en deze beheren via Kubernetes, terwijl je alles in pods houdt die naar behoefte opschalen of afschalen. En daarbij kun je zonder problemen communiceren met externe services in relatie tot jouw omgeving. En ja, nogmaals, alles kan gedaan worden zonder je code aan te passen.
Dit was de laatste post in de reeks over Istio. Blijf bij ons – er staat nog veel interessants op de planning!
Bron: habr.com
