"Il pericolo è il mio secondo nome", diceva Austin Powers, un uomo misterioso internazionale. Ma ciò che è tenuto in grande considerazione dai superagenti e dai servizi segreti non è affatto adatto ai servizi informatici, dove la noia è molto meglio del pericolo.
E Istio, insieme a OpenShift e Kubernetes, rende l'implementazione dei microservizi davvero noiosa e prevedibile, e questo è fantastico. Di questo e molto altro parleremo nel quarto ed ultimo post della serie Istio.
Quando la noia è giusta
Nel nostro caso, la noia si manifesta solo nella fase finale, quando non resta che sedersi e osservare il processo. Ma per questo devi prima configurare tutto e qui ti aspettano molte cose interessanti.
Quando si distribuisce una nuova versione del software, vale la pena considerare tutte le opzioni per ridurre al minimo i rischi. L'esecuzione in parallelo è un modo molto potente e collaudato per testare e Istio ti consente di utilizzare un "servizio segreto" (una versione nascosta del tuo microservizio) per farlo senza interferire con il sistema di produzione. Esiste anche un termine speciale per questo: "Dark Launch", che a sua volta viene attivato da una funzione con un nome altrettanto spia "traffic mirroring".
Si prega di notare che la prima frase del paragrafo precedente utilizza il termine “distribuzione” anziché “rilascio”. Dovresti davvero essere in grado di distribuire e, ovviamente, utilizzare il tuo microservizio tutte le volte che vuoi. Questo servizio deve essere in grado di ricevere ed elaborare il traffico, produrre risultati e anche scrivere nei log e monitorare. Ma allo stesso tempo, questo servizio in sé non deve necessariamente essere messo in produzione. Distribuire e rilasciare software non sono sempre la stessa cosa. Puoi effettuare il deploy quando vuoi, ma rilasciare solo quando sei pronto.
Organizzare la noia è interessante
Dai un'occhiata alla seguente regola di routing Istio, che instrada tutte le richieste HTTP alla raccomandazione del microservizio v1 (tutti gli esempi presi da ), eseguendo contemporaneamente il mirroring sul microservizio Recommendation v2:
Prestare attenzione all'etichetta mirror: nella parte inferiore dello schermo: è questo che imposta il mirroring del traffico. Sì, è così semplice!
Il risultato di questa regola sarà che il tuo sistema di produzione (v1) continuerà a elaborare le richieste in arrivo, ma le richieste stesse verranno rispecchiate in modo asincrono su v2, ovvero i loro duplicati completi andranno lì. In questo modo potrai testare v2 in condizioni reali - su dati e traffico reali - senza interferire in alcun modo con il funzionamento del sistema di produzione. Questo rende noioso organizzare i test? Sì, sicuramente. Ma è fatto in un modo interessante.
Aggiungiamo drammaticità
Si prega di notare che nel codice v2 è necessario prevedere situazioni in cui le richieste in arrivo possono portare a modifiche dei dati. Le richieste stesse vengono rispecchiate in modo semplice e trasparente, ma la scelta del metodo di elaborazione nel test spetta a te – e questo è un po’ preoccupante.
Ripetiamo un punto importante
Il lancio segreto con il mirroring del traffico (Dark Launch/Request Mirroring) può essere eseguito senza influenzare in alcun modo il codice.
Cibo per la mente
Cosa succede se il luogo in cui viene eseguito il mirroring delle richieste ne invia alcune non alla v1, ma alla v2? Ad esempio, l'2% di tutte le richieste o solo le richieste di un determinato gruppo di utenti. E poi, già guardando come funziona la v1, trasferisci gradualmente tutte le richieste alla nuova versione. O viceversa, riporta tutto alla v2 se qualcosa va storto con la vXNUMX. Penso che si chiami Canary Deployment. , e se fosse di origine russa, probabilmente conterrebbe un riferimento a ), e ora lo vedremo più nel dettaglio.
Canary Deployment in Istio: semplificazione della messa in servizio
Con attenzione e gradualmente
L'essenza del modello di distribuzione Canary Deployment è estremamente semplice: quando lanci una nuova versione del tuo software (nel nostro caso, un microservizio), per prima cosa ne dai l'accesso a un piccolo gruppo di utenti. Se tutto va bene, aumenti lentamente questo gruppo fino a quando la nuova versione non inizia a funzionare o, in caso contrario, alla fine esegui la migrazione di tutti gli utenti ad esso. Introducendo in modo attento e graduale una nuova versione e facendola passare agli utenti in modo controllato, puoi ridurre i rischi e massimizzare il feedback.
Naturalmente, Istio semplifica Canary Deployment offrendo diverse buone opzioni per l'instradamento intelligente delle richieste. E sì, tutto questo può essere fatto senza toccare in alcun modo il codice sorgente.
Filtraggio del browser
Uno dei criteri di routing più semplici è il reindirizzamento basato su browser. Supponiamo che tu voglia che solo le richieste dei browser Safari passino alla versione v2. Ecco come è fatto:
Applichiamo questa regola di routing e quindi utilizziamo il comando curl Simuleremo richieste reali al microservizio in un loop. Come puoi vedere nello screenshot, vanno tutti alla v1:
Dov'è il traffico sulla v2? Poiché nel nostro esempio tutte le richieste provengono solo dalla nostra riga di comando, semplicemente non esiste. Ma attenzione alle righe di fondo nella schermata qui sopra: questa è una reazione al fatto che abbiamo eseguito una richiesta dal browser Safari, che a sua volta ha prodotto questo:
Potere illimitato
Abbiamo già scritto che le espressioni regolari forniscono funzionalità molto potenti per l'instradamento delle richieste. Dai un'occhiata al seguente esempio (pensiamo che capirai cosa fa):
A questo punto probabilmente avrai un'idea di cosa possono fare le espressioni regolari.
Agisci in modo intelligente
Il routing intelligente, in particolare l'elaborazione delle intestazioni dei pacchetti utilizzando le espressioni regolari, ti consente di indirizzare il traffico nel modo desiderato. E questo semplifica notevolmente l'implementazione del nuovo codice: è semplice, non richiede la modifica del codice stesso e, se necessario, tutto può essere rapidamente restituito com'era.
Interessato?
Non vedi l'ora di sperimentare Istio, Kubernetes e OpenShift sul tuo computer? Squadra preparato un eccellente su questo argomento e ha reso pubblicamente disponibili tutti i file allegati. Quindi vai avanti e non negarti nulla.
Istio Egress: uscire attraverso il negozio di souvenir
Utilizzando Istio insieme a Red Hat OpenShift e Kubernetes, puoi rendere la tua vita con i microservizi molto più semplice. La rete di servizi di Istio è nascosta all'interno dei pod Kubernetes e il tuo codice viene eseguito (per lo più) in isolamento. Prestazioni, facilità di cambio, tracciabilità, ecc. – tutto questo è facile da usare grazie all'utilizzo dei contenitori sidecar. Ma cosa succede se il tuo microservizio deve comunicare con altri servizi che si trovano all'esterno del tuo sistema OpenShift-Kubernetes?
È qui che Istio Egress viene in soccorso. In poche parole, ti consente semplicemente di accedere a risorse (leggi: “servizi”) che non fanno parte del tuo sistema di pod Kubernetes. Se non esegui una configurazione aggiuntiva, nell'ambiente Istio Egress il traffico viene instradato solo all'interno di un cluster di pod e tra tali cluster in base a tabelle IP interne. E tale pupa funziona benissimo finché non è necessario l'accesso ai servizi dall'esterno.
L'uscita consente di ignorare le tabelle IP di cui sopra, in base alle regole di uscita o a un intervallo di indirizzi IP.
Supponiamo di avere un programma Java che effettua una richiesta GET a httpbin.org/headers.
(httpbin.org è solo una risorsa utile per testare le richieste di servizio in uscita.)
Se inserisci dalla riga di comando curl http://httpbin.org/headers, vedremo quanto segue:
Oppure puoi aprire lo stesso indirizzo nel browser:
Come puoi vedere, il servizio situato lì restituisce semplicemente le intestazioni che gli sono state passate.
Stiamo sostituendo le importazioni a testa alta
Ora prendiamo il codice Java di questo servizio, esterno al nostro sistema, ed eseguiamolo sul nostro, dove, ricordiamo, è installato Istio. (Puoi farlo tu stesso contattando .) Dopo aver creato l'immagine appropriata e averla lanciata sulla piattaforma OpenShift, chiameremo questo servizio con il comando curl egresshttpbin-istioegress.$(minishift ip).nip.io, dopodiché vedremo questo sullo schermo:
Ops, cosa è successo? Tutto ha funzionato. Cosa significa Non trovato? L'abbiamo fatto solo per lui curl.
Estendere le tabelle IP all'intera Internet
Istio dovrebbe essere incolpato (o ringraziato) per questo. Dopotutto, Istio sono solo contenitori sidecar responsabili del rilevamento e del routing (e di molte altre cose di cui abbiamo parlato prima). Per questo motivo, le tabelle IP sanno solo cosa c'è all'interno del tuo sistema cluster. E httpbin.org si trova all'esterno e quindi inaccessibile. Ed è qui che Istio Egress viene in soccorso, senza la minima modifica al codice sorgente.
La regola Egress riportata di seguito obbliga Istio a cercare (se necessario, quindi in tutta Internet) il servizio richiesto, in questo caso httpbin.org. Come puoi vedere da questo file (egress_httpbin.yml), la funzionalità qui è abbastanza semplice:
Non resta che applicare questa regola:
istioctl create -f egress_httpbin.yml -n istioegress
È possibile visualizzare le regole di uscita con il comando istioctl get egressrules:
E infine, eseguiamo nuovamente il comando arricciare – e vediamo che tutto funziona:
Pensiamo apertamente
Come puoi vedere, Istio ti consente di organizzare l'interazione con il mondo esterno. In altre parole, puoi comunque creare servizi OpenShift e gestirli tramite Kubernetes, mantenendo tutto in pod che scalano su e giù secondo necessità. E allo stesso tempo puoi accedere in sicurezza ai servizi esterni al tuo ambiente. E sì, ripetiamo ancora una volta che tutto questo può essere fatto senza toccare in alcun modo il tuo codice.
Questo è stato l'ultimo post della serie su Istio. Restate sintonizzati: ci sono molte cose interessanti in vista!
Fonte: habr.com