"El perill és el meu segon nom", solia dir Austin Powers, un home internacional de misteri. Però allò que tenen en gran estima els superagents i els serveis d'intel·ligència no és gens adequat per als serveis informàtics, on l'avorriment és molt millor que el perill.
I Istio, juntament amb OpenShift i Kubernetes, fa que el desplegament de microserveis sigui realment avorrit i previsible, i això és genial. D'això i de molt més en parlarem a la quarta i última publicació de la sèrie Istio.
Quan l'avorriment és correcte
En el nostre cas, l'avorriment es produeix només en la fase final, quan només queda seure a veure el procés. Però per això primer cal configurar-ho tot i aquí us esperen moltes coses interessants.
Quan implementeu una nova versió del vostre programari, val la pena considerar totes les opcions per minimitzar els riscos. Executar en paral·lel és una manera molt potent i provada de provar, i Istio us permet utilitzar un "servei secret" (una versió oculta del vostre microservei) per fer-ho sense interferir amb el sistema de producció. Fins i tot hi ha un terme especial per a això: "Llançament fosc", que al seu torn s'activa per una funció amb un nom igualment espia "replica de trànsit".
Tingueu en compte que la primera frase del paràgraf anterior utilitza el terme "desplegament" en lloc de "alliberar". Realment hauríeu de poder implementar (i, per descomptat, utilitzar) el vostre microservei tantes vegades com vulgueu. Aquest servei ha de ser capaç de rebre i processar trànsit, produir resultats i també escriure als registres i supervisar. Però al mateix temps, aquest servei en si no necessàriament ha de ser llançat en producció. El desplegament i el llançament de programari no sempre són el mateix. Podeu implementar-vos quan vulgueu, però alliberar-lo només quan estigueu preparat.
Organitzar l'avorriment és interessant
Fes una ullada a la següent regla d'encaminament d'Istio, que encamina totes les sol·licituds HTTP a la recomanació de microservei v1 (tots els exemples extrets de ), alhora que els reflecteix al microservei de recomanació v2:
Fixeu-vos en l'etiqueta mirror: a la part inferior de la pantalla: això és el que estableix la duplicació del trànsit. Sí, així de senzill!
El resultat d'aquesta regla serà que el vostre sistema de producció (v1) continuarà processant les sol·licituds entrants, però les sol·licituds en si es reflectiran de manera asíncrona a la v2, és a dir, els seus duplicats complets hi aniran. D'aquesta manera, podeu provar v2 en condicions reals -en dades i trànsit reals- sense interferir de cap manera amb el funcionament del sistema de producció. Això fa que l'organització de les proves sigui avorrida? Sí, definitivament. Però es fa d'una manera interessant.
Afegim drama
Tingueu en compte que al codi v2 cal preveure situacions en què les sol·licituds entrants poden comportar canvis de dades. Les sol·licituds en si es reflecteixen de manera fàcil i transparent, però l'elecció del mètode de processament a la prova depèn de vostè, i això és una mica preocupant.
Repetim un punt important
El llançament secret amb rèplica de trànsit (Dark Launch/Request Mirroring) es pot realitzar sense afectar el codi de cap manera.
Aliment per al pensament
Què passa si el lloc on es reflecteixen les sol·licituds n'envia algunes no a la v1, sinó a la v2? Per exemple, un per cent de totes les sol·licituds o només les sol·licituds d'un determinat grup d'usuaris. I després, ja mirant com funciona la v2, transferiu gradualment totes les sol·licituds a la nova versió. O viceversa, torneu-ho tot a v1 si alguna cosa va malament amb v2. Crec que es diu Desplegament Canari. , i si fos d'origen rus, probablement contindria una referència a ), i ara ho veurem amb més detall.
Desplegament Canari a Istio: simplificant la posada en marxa
Amb cura i gradualment
L'essència del model de desplegament de Canary Deployment és extremadament simple: quan inicieu una nova versió del vostre programari (en el nostre cas, un microservei), primer hi doneu accés a un grup reduït d'usuaris. Si tot va bé, aneu augmentant lentament aquest grup fins que la nova versió comenci a actuar o, si no, finalment hi migrarà tots els usuaris. Si introduïu una versió nova de manera pensada i gradual i canvieu els usuaris a ella de manera controlada, podeu reduir els riscos i maximitzar els comentaris.
Per descomptat, Istio simplifica el desplegament de Canary oferint diverses bones opcions per a l'encaminament de sol·licituds intel·ligents. I sí, tot això es pot fer sense tocar el codi font de cap manera.
Filtrat del navegador
Un dels criteris d'encaminament més senzills és la redirecció basada en navegador. Suposem que només voleu que les sol·licituds dels navegadors Safari vagin a la v2. Així és com es fa:
Apliquem aquesta regla d'encaminament i després utilitzem l'ordre curl Simularem sol·licituds reals al microservei en un bucle. Com podeu veure a la captura de pantalla, tots van a la v1:
On és el trànsit a la v2? Com que al nostre exemple totes les sol·licituds provenien només de la nostra pròpia línia d'ordres, simplement no existeix. Però presteu atenció a les línies inferiors de la pantalla anterior: aquesta és una reacció al fet que vam executar una sol·licitud des del navegador Safari, que al seu torn va produir això:
Potència il·limitada
Ja hem escrit que les expressions regulars proporcionen capacitats molt potents per encaminar les sol·licituds. Mireu l'exemple següent (creiem que entendreu què fa):
A hores d'ara probablement ja tingueu una idea del que poden fer les expressions regulars.
Actuar amb intel·ligència
L'encaminament intel·ligent, en particular el processament de capçaleres de paquets mitjançant expressions regulars, us permet dirigir el trànsit de la manera que vulgueu. I això simplifica molt la implementació del nou codi: és senzill, no requereix canviar el codi en si i, si cal, es pot tornar ràpidament tot tal com estava.
Interessat?
Tens ganes d'experimentar amb Istio, Kubernetes i OpenShift al teu ordinador? Equip preparat un excel·lent sobre aquest tema i va posar a disposició del públic tots els fitxers que l'acompanyen. Així que endavant i no et neguis res.
Sortida d'Istio: sortida per la botiga de souvenirs
Si feu servir Istio juntament amb Red Hat OpenShift i Kubernetes, us podeu fer la vida molt més fàcil amb els microserveis. La malla de servei d'Istio s'amaga dins dels pods de Kubernetes i el vostre codi s'executa (majoritàriament) de manera aïllada. Rendiment, facilitat de canvi, traçat, etc.: tot això és fàcil d'utilitzar gràcies a l'ús de contenidors sidecar. Però, què passa si el vostre microservei ha de comunicar-se amb altres serveis que es troben fora del vostre sistema OpenShift-Kubernetes?
Aquí és on Istio Egress ve al rescat. En poques paraules, simplement us permet accedir a recursos (llegiu: "serveis") que no formen part del vostre sistema de pods de Kubernetes. Si no realitzeu una configuració addicional, a l'entorn Istio Egress el trànsit només s'encamina dins d'un clúster de pods i entre aquests clústers basats en taules IP internes. I aquesta pupació funciona molt bé sempre que no necessiteu accés als serveis des de l'exterior.
Egress us permet ometre les taules IP anteriors, ja sigui en funció de les regles de sortida o en una sèrie d'adreces IP.
Suposem que tenim un programa Java que fa una sol·licitud GET a httpbin.org/headers.
(httpbin.org és només un recurs convenient per provar les sol·licituds de servei sortints).
Si entreu a la línia d'ordres curl http://httpbin.org/headers, veurem el següent:
O podeu obrir la mateixa adreça al navegador:
Com podeu veure, el servei ubicat allà simplement retorna les capçaleres que se li han passat.
Estem substituint les importacions frontalment
Ara agafem el codi Java d'aquest servei, extern al nostre sistema, i executem-lo pel nostre compte, on, recordem, està instal·lat Istio. (Podeu fer-ho vosaltres mateixos contactant .) Després d'haver creat la imatge adequada i llançada a la plataforma OpenShift, trucarem a aquest servei amb l'ordre curl egresshttpbin-istioegress.$(minishift ip).nip.io, després de la qual cosa veurem això a la pantalla:
Vaja, què va passar? Tot va funcionar. Què significa No trobat? Ho vam fer per ell curl.
Estenent les taules IP a tot Internet
S'ha de culpar (o agrair) a Istio per això. Al cap i a la fi, Istio són només contenidors sidecar que s'encarreguen de la detecció i l'encaminament (i moltes altres coses de les quals hem parlat anteriorment). Per aquest motiu, les taules IP només saben què hi ha dins del vostre sistema de clúster. I httpbin.org es troba fora i per tant inaccessible. I aquí és on Istio Egress ve al rescat, sense el més mínim canvi al vostre codi font.
La regla de sortida a continuació obliga a Istio a cercar (si cal, després a tota Internet) el servei requerit, en aquest cas, httpbin.org. Com podeu veure en aquest fitxer (egress_httpbin.yml), la funcionalitat aquí és força senzilla:
Només queda aplicar aquesta regla:
istioctl create -f egress_httpbin.yml -n istioegress
Podeu veure les regles de sortida amb l'ordre istioctl get egressrules:
I finalment, tornem a executar l'ordre ris – i veiem que tot funciona:
Pensem obertament
Com podeu veure, Istio us permet organitzar la interacció amb el món exterior. En altres paraules, encara podeu crear serveis d'OpenShift i gestionar-los mitjançant Kubernetes, mantenint-ho tot en pods que augmenten i baixen segons sigui necessari. I al mateix temps, podeu accedir amb seguretat a serveis externs al vostre entorn. I sí, repetim una vegada més que tot això es pot fer sense tocar el vostre codi de cap manera.
Aquesta va ser l'última publicació de la sèrie a Istio. Estigueu atents: hi ha moltes coses interessants per endavant!
Font: www.habr.com