‘Gevaar is mijn tweede naam’, zei Austin Powers, een internationale man van mysterie, altijd. Maar wat hoog gewaardeerd wordt door superagenten en inlichtingendiensten is helemaal niet geschikt voor computerdiensten, waar verveling veel beter is dan gevaar.
En Istio maakt, samen met OpenShift en Kubernetes, het inzetten van microservices echt saai en voorspelbaar - en dat is geweldig. We zullen hierover en nog veel meer praten in het vierde en laatste bericht in de Istio-serie.
Wanneer verveling terecht is
In ons geval ontstaat verveling pas in de laatste fase, wanneer je alleen nog maar hoeft te zitten en naar het proces te kijken. Maar hiervoor moet je eerst alles configureren, en hier wachten je veel interessante dingen.
Wanneer u een nieuwe versie van uw software implementeert, is het de moeite waard om alle opties voor het minimaliseren van risico's te overwegen. Parallel draaien is een zeer krachtige en beproefde manier om te testen, en met Istio kunt u een “geheime service” (een verborgen versie van uw microservice) gebruiken om dit te doen zonder het productiesysteem te verstoren. Er is zelfs een speciale term hiervoor: "Dark Launch", die op zijn beurt wordt geactiveerd door een functie met een even spionagenaam "traffic mirroring".
Houd er rekening mee dat in de eerste zin van de vorige paragraaf de term “implementeren” wordt gebruikt in plaats van “vrijgeven”. Je zou je microservice echt zo vaak moeten kunnen inzetten (en natuurlijk gebruiken) als je wilt. Deze service moet verkeer kunnen ontvangen en verwerken, resultaten kunnen produceren en ook naar logboeken kunnen schrijven en monitoren. Maar tegelijkertijd hoeft deze dienst zelf niet noodzakelijkerwijs in productie te worden genomen. Het implementeren en vrijgeven van software is niet altijd hetzelfde. U kunt implementeren wanneer u maar wilt, maar pas vrijgeven als u er klaar voor bent.
Het organiseren van verveling is interessant
Kijk eens naar de volgende Istio-routeringsregel, die alle HTTP-verzoeken doorstuurt naar de microservice-aanbeveling v1 (alle voorbeelden afkomstig uit ), terwijl ze tegelijkertijd worden gespiegeld naar de aanbeveling v2-microservice:
Let op het etiket mirror: onderaan het scherm - hiermee wordt de verkeersspiegeling ingesteld. Ja, zo simpel is het!
Het resultaat van deze regel zal zijn dat uw productiesysteem (v1) binnenkomende verzoeken zal blijven verwerken, maar de verzoeken zelf zullen asynchroon worden gespiegeld naar v2, dat wil zeggen dat hun volledige duplicaten daarheen zullen gaan. Op deze manier kunt u v2 in reële omstandigheden testen - op echte data en verkeer - zonder op enige manier de werking van het productiesysteem te verstoren. Maakt dit het organiseren van testen saai? Ja absoluut. Maar het gebeurt op een interessante manier.
Laten we drama toevoegen
Houd er rekening mee dat het in de v2-code noodzakelijk is om te voorzien in situaties waarin inkomende verzoeken tot gegevenswijzigingen kunnen leiden. De verzoeken zelf worden eenvoudig en transparant gespiegeld, maar de keuze van de verwerkingsmethode in de test is aan jou – en dit is een beetje zorgwekkend.
Laten we een belangrijk punt herhalen
Geheime lancering met verkeersspiegeling (Dark Launch/Request Mirroring) kan worden uitgevoerd zonder de code op enigerlei wijze te beïnvloeden.
Stof tot nadenken
Wat als de plaats waar verzoeken worden gespiegeld sommige ervan niet naar v1, maar naar v2 stuurt? Bijvoorbeeld één procent van alle verzoeken of alleen verzoeken van een bepaalde groep gebruikers. En dan, al kijkend naar hoe v2 werkt, breng geleidelijk alle verzoeken over naar de nieuwe versie. Of andersom, zet alles terug naar v1 als er iets misgaat met v2. Ik denk dat het Canary Deployment heet. , en als het van Russische oorsprong zou zijn, zou het waarschijnlijk een verwijzing naar bevatten ), en nu zullen we dit in meer detail bekijken.
Canary-implementatie in Istio: vereenvoudiging van de inbedrijfstelling
Voorzichtig en geleidelijk
De essentie van het Canary Deployment-implementatiemodel is uiterst eenvoudig: wanneer u een nieuwe versie van uw software lanceert (in ons geval een microservice), geeft u er eerst toegang toe aan een kleine groep gebruikers. Als alles goed gaat, breid je deze groep langzaam uit totdat de nieuwe versie begint te werken, of - als dat niet het geval is - migreer je uiteindelijk alle gebruikers ernaar. Door bedachtzaam en geleidelijk een nieuwe versie te introduceren en gebruikers er gecontroleerd naar over te zetten, verkleint u de risico’s en maximaliseert u de feedback.
Uiteraard vereenvoudigt Istio de Canary-implementatie door verschillende goede opties aan te bieden voor intelligente verzoekroutering. En ja, dit alles kan worden gedaan zonder op enigerlei wijze uw broncode aan te raken.
De browser filteren
Een van de eenvoudigste routeringscriteria is browsergebaseerde omleiding. Stel dat u alleen verzoeken van Safari-browsers naar v2 wilt laten gaan. Zo werkt het:
Laten we deze routeringsregel toepassen en vervolgens de opdracht gebruiken curl We zullen echte verzoeken aan de microservice in een lus simuleren. Zoals je in de schermafbeelding kunt zien, gaan ze allemaal naar v1:
Waar is het verkeer op v2? Omdat in ons voorbeeld alle verzoeken alleen afkomstig waren van onze eigen opdrachtregel, bestaat deze eenvoudigweg niet. Maar let op de onderste regels in bovenstaand scherm: dit is een reactie op het feit dat we een verzoek uitvoerden vanuit de Safari-browser, die op zijn beurt dit produceerde:
Oneindige kracht
We hebben al geschreven dat reguliere expressies zeer krachtige mogelijkheden bieden voor het routeren van verzoeken. Kijk eens naar het volgende voorbeeld (we denken dat je begrijpt wat het doet):
Je hebt inmiddels waarschijnlijk een idee van wat reguliere expressies kunnen doen.
Handel slim
Slimme routering, met name het verwerken van pakketheaders met behulp van reguliere expressies, stelt u in staat het verkeer te sturen zoals u dat wilt. En dit vereenvoudigt de implementatie van nieuwe code aanzienlijk - het is eenvoudig, het vereist geen verandering van de code zelf, en indien nodig kan alles snel worden teruggegeven zoals het was.
Geïnteresseerd?
Wil jij experimenteren met Istio, Kubernetes en OpenShift op je computer? Team uitstekend bereid over dit onderwerp en heeft alle bijbehorende bestanden openbaar gemaakt. Dus ga je gang en ontzeg jezelf niets.
Istio Egress: uitgang via de souvenirwinkel
Door Istio samen met Red Hat OpenShift en Kubernetes te gebruiken, kunt u uw leven met microservices veel eenvoudiger maken. De service mesh van Istio is verborgen in Kubernetes-pods en uw code wordt (grotendeels) geïsoleerd uitgevoerd. Prestaties, verwisselgemak, tracering, enz. – dit alles is eenvoudig te gebruiken dankzij het gebruik van zijspancontainers. Maar wat als uw microservice moet communiceren met andere services die zich buiten uw OpenShift-Kubernetes-systeem bevinden?
Dit is waar Istio Egress te hulp schiet. Kort gezegd geeft het u eenvoudigweg toegang tot bronnen (lees: “services”) die geen deel uitmaken van uw systeem met Kubernetes-pods. Als u geen aanvullende configuratie uitvoert, wordt verkeer in de Istio Egress-omgeving alleen gerouteerd binnen een cluster van pods en tussen dergelijke clusters op basis van interne IP-tabellen. En zo'n verpopping werkt prima zolang je geen toegang nodig hebt tot diensten van buitenaf.
Met Egress kunt u de bovenstaande IP-tabellen omzeilen, op basis van Egress-regels of op basis van een reeks IP-adressen.
Laten we zeggen dat we een Java-programma hebben dat een GET-verzoek doet aan httpbin.org/headers.
(httpbin.org is slechts een handige bron voor het testen van uitgaande serviceverzoeken.)
Als u op de opdrachtregel invoert curl http://httpbin.org/headers, zullen we het volgende zien:
Of u kunt hetzelfde adres in de browser openen:
Zoals u kunt zien, retourneert de dienst die zich daar bevindt eenvoudigweg de headers die eraan zijn doorgegeven.
Wij vervangen de import frontaal
Laten we nu de Java-code van deze service nemen, extern aan ons systeem, en deze zelf uitvoeren, waar, zoals u zich zult herinneren, Istio is geïnstalleerd. (Dit kunt u zelf doen door contact op te nemen .) Nadat we de juiste afbeelding hebben gebouwd en deze op het OpenShift-platform hebben gelanceerd, zullen we deze service aanroepen met de opdracht curl egresshttpbin-istioegress.$(minishift ip).nip.io, waarna we dit op het scherm zien:
Oeps, wat is er gebeurd? Alles werkte gewoon. Wat betekent Niet gevonden? Wij hebben het gewoon voor hem gedaan curl.
IP-tabellen uitbreiden naar het hele internet
Istio moet hiervoor de schuld krijgen (of bedankt). Istio is tenslotte slechts zijspancontainers die verantwoordelijk zijn voor detectie en routering (en een heleboel andere dingen waar we het eerder over hadden). Om deze reden weten IP-tabellen alleen wat zich in uw clustersysteem bevindt. En httpbin.org bevindt zich buiten en is daarom ontoegankelijk. En dit is waar Istio Egress te hulp schiet - zonder de minste wijziging in uw broncode.
De onderstaande Egress-regel dwingt Istio om (indien nodig, dan het hele internet door) te zoeken naar de vereiste dienst, in dit geval httpbin.org. Zoals je kunt zien in dit bestand (egress_httpbin.yml), is de functionaliteit hier vrij eenvoudig:
Het enige dat overblijft is deze regel toepassen:
istioctl create -f egress_httpbin.yml -n istioegress
U kunt Egress-regels bekijken met de opdracht istioctl get egressrules:
En ten slotte voeren we de opdracht opnieuw uit krullen – en we zien dat alles werkt:
Wij denken openlijk
Zoals je kunt zien, kun je met Istio de interactie met de buitenwereld organiseren. Met andere woorden: u kunt nog steeds OpenShift-services maken en deze beheren via Kubernetes, waarbij u alles in pods bewaart die naar behoefte op- en afschalen. En tegelijkertijd heeft u veilig toegang tot diensten buiten uw omgeving. En ja, we herhalen nogmaals dat dit allemaal kan worden gedaan zonder uw code op enigerlei wijze aan te raken.
Dit was het laatste bericht in de serie over Istio. Houd ons in de gaten: er staan veel interessante dingen in het verschiet!
Bron: www.habr.com