Notă traducere: Această prezentare generală de la Weaveworks prezintă cele mai populare strategii de lansare a aplicațiilor și arată cum cele mai avansate pot fi implementate folosind operatorul Kubernetes Flagger. Este scris într-un limbaj simplu și conține diagrame vizuale care permit chiar și inginerilor începători să înțeleagă problema.
Diagrama este preluată din strategii de lansare realizate în Container Solutions
Una dintre cele mai mari provocări în dezvoltarea aplicațiilor native cloud astăzi este accelerarea implementării. Într-o abordare de microservicii, dezvoltatorii lucrează deja cu și proiectează aplicații complet modulare, permițând diferitelor echipe să scrie simultan cod și să facă modificări aplicației.
Implementările mai scurte și mai frecvente au următoarele avantaje:
- Timpul de piață este redus.
- Noile funcții ajung mai repede la utilizatori.
- Feedbackul utilizatorilor ajunge mai repede la echipa de dezvoltare. Aceasta înseamnă că echipa poate adăuga funcții și poate rezolva problemele mai rapid.
- Moralul dezvoltatorilor crește: mai multe funcții în dezvoltare sunt mai distractive de lucrat.
Dar, pe măsură ce frecvența lansărilor crește, crește și șansele de a afecta negativ fiabilitatea aplicației sau experiența utilizatorului. De aceea, este important ca operațiunile și echipele DevOps să construiască procese și să gestioneze strategiile de implementare într-un mod care să minimizeze riscurile pentru produs și utilizatori. (Puteți afla mai multe despre automatizarea conductelor CI/CD .)
În această postare, vom discuta despre diverse strategii de implementare în Kubernetes, inclusiv implementări continue și metode mai avansate, cum ar fi lansările Canary și variațiile acestora.
Strategii de implementare
Există mai multe tipuri diferite de strategii de implementare pe care le puteți utiliza în funcție de obiectivul dvs. De exemplu, poate fi necesar să faceți modificări unui anumit mediu pentru testare ulterioară sau unui subset de utilizatori/clienți sau poate fi necesar să faceți teste limitate pentru utilizatori înainte de a crea o funcție public.
Rolling (treptat, implementare „în rulare”)
Aceasta este strategia standard de implementare în Kubernetes. Treptat, unul câte unul, înlocuiește pod-urile cu versiunea veche a aplicației cu pod-uri cu noua versiune - fără timp de nefuncționare a cluster-ului.
Kubernetes așteaptă până când noile poduri sunt gata să funcționeze (verificându-le folosind ), înainte de a începe să rulați pe cele vechi. Dacă apare o problemă, această actualizare continuă poate fi anulată fără a opri întregul cluster. În fișierul YAML care descrie tipul de implementare, noua imagine înlocuiește imaginea veche:
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: awesomeapp
spec:
replicas: 3
template:
metadata:
labels:
app: awesomeapp
spec:
containers:
- name: awesomeapp
image: imagerepo-user/awesomeapp:new
ports:
- containerPort: 8080Parametrii de actualizare rollover pot fi specificați în fișierul manifest:
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
template:
...
Recrea
În acest cel mai simplu tip de implementare, podurile vechi sunt ucise dintr-o dată și înlocuite cu altele noi:
Manifestul corespunzător arată cam așa:
spec:
replicas: 3
strategy:
type: Recreate
template:
...Albastru/Verde (instalări albastru-verde)
Strategia de implementare albastru-verde (uneori numită și roșu/negru) implică implementarea simultană a versiunilor vechi (verzi) și noi (albastre) ale aplicației. După postarea ambelor versiuni, utilizatorii obișnuiți au acces la cea verde, în timp ce cea albastră este disponibilă pentru echipa de QA pentru a automatiza testele printr-un serviciu separat sau direct port forwarding:
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: awesomeapp-02
spec:
template:
metadata:
labels:
app: awesomeapp
version: "02"După ce versiunea albastră (nouă) a fost testată și lansarea sa a fost aprobată, serviciul trece la ea, iar versiunea verde (veche) este pliată:
apiVersion: v1
kind: Service
metadata:
name: awesomeapp
spec:
selector:
app: awesomeapp
version: "02"
...Canary (desfăşurări Canary)
Lansările Canary sunt similare cu lansările albastru-verde, dar au un control și o utilizare mai bune abordare pas cu pas. Acest tip include mai multe strategii diferite, inclusiv lansări „stealth” și testare A/B.
Această strategie este utilizată atunci când este nevoie de a încerca unele funcționalități noi, de obicei în backend-ul aplicației. Esența abordării este de a crea două servere aproape identice: unul deservește aproape toți utilizatorii, iar celălalt, cu funcții noi, servește doar un subgrup mic de utilizatori, după care se compară rezultatele muncii lor. Dacă totul decurge fără erori, noua versiune este implementată treptat în întreaga infrastructură.
Desi aceasta strategie poate fi implementata exclusiv folosind Kubernetes, inlocuind pod-urile vechi cu altele noi, este mult mai comod si mai simplu sa folosesti o retea de servicii precum Istio.
De exemplu, este posibil să aveți două manifeste diferite în Git: un manifest obișnuit cu eticheta 0.1.0 și un manifest canar cu eticheta 0.2.0. Schimbând ponderile în manifestul gateway-ului virtual Istio, puteți controla distribuția traficului între aceste două implementări:
Pentru un ghid pas cu pas pentru implementarea implementărilor Canary folosind Istio, consultați . (Notă. transl.: Am tradus, de asemenea, materiale despre lansările canare în Istio .)
Desfăşurări Canary cu Weaveworks Flagger
vă permite să gestionați ușor și eficient lansările Canary.
Flagger automatizează lucrul cu ei. Utilizează Istio sau AWS App Mesh pentru a direcționa și comuta traficul, iar valorile Prometheus pentru a analiza rezultatele. În plus, analiza implementărilor Canary poate fi completată cu webhook-uri pentru a efectua teste de acceptare, teste de încărcare și orice alte tipuri de verificări.
Pe baza implementării Kubernetes și, dacă este necesar, scalarea orizontală a podurilor (HPA), Flagger creează seturi de obiecte (implementari Kubernetes, servicii ClusterIP și servicii virtuale Istio sau App Mesh) pentru a analiza și implementa implementări canare:
Implementarea buclei de control (buclă de control),Flagger comută treptat traficul către serverul Canary, în timp ce măsoară în același timp valorile cheie de performanță, cum ar fi procentul de solicitări HTTP reușite, durata medie a solicitărilor și sănătatea podului. Pe baza analizei KPI (Key Performance Indicators), canarul fie crește, fie se prăbușește, iar rezultatele analizei sunt publicate în Slack. O descriere și o demonstrație a acestui proces pot fi găsite în material .
Implementări întunecate (ascunse) sau A/B
Desfășurarea stealth este o altă variantă a strategiei canare (cu care, apropo, poate funcționa și Flagger). Diferența dintre implementările stealth și canary este că implementările stealth se ocupă mai degrabă de front-end decât de backend, cum ar fi implementările de canary.
Un alt nume pentru aceste implementări este testarea A/B. În loc să facă noua caracteristică disponibilă tuturor utilizatorilor, aceasta este oferită doar unei părți limitate dintre aceștia. În mod obișnuit, acești utilizatori nu știu că sunt testeri de pionierat (de unde și termenul „implementare stealth”).
Utilizarea comutatoarelor de funcționalitate (funcție comutatoare) și alte instrumente, puteți monitoriza modul în care utilizatorii interacționează cu noua caracteristică, dacă sunt implicați de aceasta sau dacă consideră noua interfață de utilizator confuză și alte tipuri de valori.
Desfășurări de semnalizare și A/B
Pe lângă rutarea bazată pe greutate, Flagger poate direcționa și traficul către serverul Canary pe baza parametrilor HTTP. În testarea A/B, puteți utiliza antete HTTP sau module cookie pentru a viza un anumit segment de utilizatori. Acest lucru este eficient în special în cazul aplicațiilor frontend care necesită legarea sesiunii la server (afinitate sesiune). Mai multe informații pot fi găsite în documentația Flagger.
Autorul este recunoscător , inginer Weaveworks (și creatorul Flagger), pentru toate aceste modele uimitoare de implementare.
PS de la traducator
Citește și pe blogul nostru:
- «»;
- «»;
- «»;
- «".
Sursa: www.habr.com