Notă de traducere: Acest material de revizuire de la Weaveworks introduce cele mai populare strategii de desfășurare a aplicațiilor și discută despre posibilitatea implementării celor mai avansate dintre ele cu ajutorul operatorului Kubernetes Flagger. Este scris într-un limbaj simplu și conține diagrame vizuale, care ajută chiar și inginerii începători să înțeleagă subiectul.
Diagrama este preluată din a strategiilor de desfășurare realizată de Container Solutions
Una dintre cele mai mari provocări în dezvoltarea aplicațiilor cloud-native de astăzi este accelerarea desfășurării. Utilizând abordarea microservicii, dezvoltatorii lucrează deja cu aplicații complet modulare și le proiectează astfel încât diferite echipe să poată scrie cod și să facă modificări în aplicație simultan.
Desfășurările mai scurte și mai frecvente au următoarele avantaje:
- Timpul de intrare pe piață se reduce.
- Noile funcționalități ajung mai repede la utilizatori.
- Feedback-ul utilizatorilor ajunge mai repede la echipa de dezvoltare. Aceasta înseamnă că echipa poate adăuga funcții și corecta problemele mai rapid.
- Moralul dezvoltatorilor crește: cu mai multe funcționalități în dezvoltare, este mai interesant să lucrezi.
Dar, pe măsură ce frecvența lansărilor crește, de asemenea, cresc șansele de a afecta negativ fiabilitatea aplicației sau experiența utilizatorului. De aceea, echipelor de operare și DevOps le este important să construiască procese și să gestioneze strategiile de desfășurare astfel încât să minimizeze riscurile pentru produs și utilizatori. (Află mai multe despre automatizarea pipeline-ului CI/CD .)
În această publicație, vom discuta despre diferite strategii de desfășurare în Kubernetes, inclusiv desfășurările rolling și metode mai avansate, cum ar fi desfășurările canary și variantele acestora.
Strategii de deployment
Există mai multe tipuri diferite de strategii de desfășurare pe care le puteți utiliza în funcție de obiectiv. De exemplu, poate fi necesar să faceți modificări într-un anumit mediu pentru teste ulterioare, sau pentru un subset de utilizatori/clienți, sau poate fi nevoie să efectuați teste limitate pe utilizatori înainte de a face o funcționalitate publică.
Rolling (desfășurare graduală, „circulară”)
Aceasta este strategia standard de implementare în Kubernetes. Aceasta înlocuiește treptat, unul câte unul, pod-urile cu versiunea veche a aplicației cu pod-uri cu versiunea nouă — fără a provoca întreruperi în cluster.
Kubernetes așteaptă ca noile pod-uri să fie pregătite pentru lucru (verificându-le prin ), înainte de a începe să dezactiveze vechile pod-uri. Dacă apare o problemă, o actualizare rulată poate fi oprită fără a opri întregul cluster. În fișierul YAML care descrie tipul de deployment, noua imagine îl înlocuiește pe cel vechi:
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 actualizării rulante pot fi clarificați în fișierul manifest:
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
template:
...
Recreate (recreație)
În acest tip simplu de implementare, vechile pod-uri sunt terminate toate deodată și înlocuite cu altele noi:
Manifestul corespunzător arată aproximativ astfel:
spec:
replicas: 3
strategy:
type: Recreate
template:
...Blue/Green (implementări albastre/verde)
Strategia de implementare albastră-verde (uneori numită și roșie/neagră) prevede implementarea simultană a versiunii vechi (verzi) și a versiunii noi (albastre) a aplicației. După ce ambele versiuni sunt disponibile, utilizatorii obișnuiți au acces la cea verde, în timp ce versiunea albastră este disponibilă echipei QA pentru testare automată printr-un serviciu separat sau prin redirecționare directă a porturilor:
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 este comutat pe ea, iar versiunea verde (veche) este dezactivată:
apiVersion: v1
kind: Service
metadata:
name: awesomeapp
spec:
selector:
app: awesomeapp
version: "02"
...Canary (implementări canar)
Implementările canar sunt asemănătoare cu cele albastre/verzi, dar sunt gestionate mai bine și utilizează pas cu pas. Acest tip include mai multe strategii diferite, inclusiv lansări „ascunse” și teste A/B.
Această strategie se aplică atunci când este necesar să se testeze o anumită funcționalitate nouă, de obicei, în backend-ul aplicației. Esența abordării constă în a crea două servere practic identice: unul care servește aproape toți utilizatorii, iar celălalt, cu funcționalități noi, care servește doar un mic subgroup de utilizatori, după care rezultatele funcționării lor sunt comparate. Dacă totul decurge fără erori, noua versiune este implementată treptat în întreaga infrastructură.
Deși această strategie poate fi realizată exclusiv cu ajutorul Kubernetes, înlocuind pod-urile vechi cu cele noi, este mult mai convenabil și simplu să folosești un service mesh precum Istio.
De exemplu, puteți avea două manifeste diferite în Git: unul obișnuit cu eticheta 0.1.0 și unul „canar” cu eticheta 0.2.0. Prin modificarea greutăților în manifestul gateway-ului virtual Istio, se poate gestiona distribuția traficului între aceste două deployment-uri:
Un ghid pas cu pas pentru implementarea deployment-urilor canar cu Istio poate fi găsit în materialul . (Nota traducătorului.: De asemenea, am tradus materialul despre deployment-urile canar în Istio .)
Deployment-uri canar cu Weaveworks Flagger
permite gestionarea ușoară și eficientă a deployment-urilor canar.
Flagger automatizează gestionarea acestora. Folosește Istio sau AWS App Mesh pentru rutare și comutare a traficului, precum și metrici Prometheus pentru analizarea rezultatelor. În plus, analiza deployment-urilor canar poate fi completată cu webhook-uri pentru desfășurarea testelor de acceptare, teste de încărcare și orice alte tipuri de verificări.
Pe baza deployment-ului Kubernetes și, dacă este necesar, al scalării orizontale a pod-urilor (HPA), Flagger creează seturi de obiecte (deployment-uri Kubernetes, servicii ClusterIP și servicii virtuale Istio sau App Mesh) pentru analiza și implementarea deployment-urilor canar:
Implementând un ciclu de control (control loop), Flagger comută treptat traficul către serverul canar, măsurând în paralel indicatorii cheie de performanță, precum rata de succes a cererilor HTTP, durata medie a cererii și sănătatea pod-urilor. Pe baza analizei KPI (indicatori cheie de performanță), partea canar fie crește, fie se diminuează, iar rezultatele analizei sunt publicate în Slack. O descriere și o demonstrație a acestui proces pot fi găsite în materialul .
Întrebare (ascunse) sau desfășurări A/B
Desfășurarea ascunsă este o altă variație a strategiei canar și, de altfel, Flagger poate funcționa și cu aceasta. Diferența dintre desfășurările ascunse și cele canar constă în faptul că desfășurările ascunse se ocupă de front-end, nu de back-end, ca în cazul celor canar.
Un alt nume pentru aceste desfășurări este testarea A/B. În loc să facă o nouă funcție disponibilă tuturor utilizatorilor, aceasta este oferită doar unei părți restrânse dintre aceștia. De obicei, acești utilizatori nu știu că sunt testeri pionieri (de aici și termenul „desfășurare ascunsă”).
Cu ajutorul comutatoarelor de funcționalitate (feature toggles) și a altor instrumente, se poate observa cum interacționează utilizatorii cu noua funcție, dacă aceasta îi atrage sau dacă consideră că noul interfață utilizator este confuză, și alte tipuri de metrici.
Flagger și desfășurările A/B
În afară de rutarea pe baza greutății, Flagger poate îndrepta, de asemenea, traficul către serverul canar în funcție de parametrii HTTP. În cadrul testării A/B, se pot folosi anteturi HTTP sau cookie-uri pentru a redirecționa un segment specific de utilizatori. Acest lucru este deosebit de eficient în cazul aplicațiilor front-end care necesită afinitate de sesiune cu serverul (session affinity). Mai multe informații pot fi găsite în documentația Flagger.
Autorul își exprimă recunoștința , inginer la Weaveworks (și creatorul Flagger), pentru toate aceste scheme uimitoare de desfășurare.
P.S. de la traducător
Citiți și în blogul nostru:
- «»;
- «»;
- «»;
- «».
Sursa: habr.com
