Nota. traducció: Aquesta visió general de Weaveworks presenta les estratègies de llançament d'aplicacions més populars i mostra com es poden implementar les més avançades mitjançant l'operador Kubernetes Flagger. Està escrit en llenguatge senzill i conté diagrames visuals que permeten que fins i tot els enginyers novells entenguin el problema.
El diagrama està extret de estratègies de desplegament fetes a Container Solutions
Un dels reptes més importants en el desenvolupament d'aplicacions natives del núvol avui dia és accelerar el desplegament. En un enfocament de microserveis, els desenvolupadors ja treballen i dissenyen aplicacions completament modulars, permetent que diferents equips escriguin codi i facin canvis simultàniament a l'aplicació.
Els desplegaments més curts i freqüents tenen els avantatges següents:
- El temps de sortida al mercat es redueix.
- Les noves funcions arriben als usuaris més ràpidament.
- Els comentaris dels usuaris arriben a l'equip de desenvolupament més ràpidament. Això significa que l'equip pot afegir funcions i solucionar problemes més ràpidament.
- La moral dels desenvolupadors augmenta: és més divertit treballar amb més funcions en desenvolupament.
Però a mesura que augmenta la freqüència de llançaments, també augmenten les possibilitats d'afectar negativament la fiabilitat de l'aplicació o l'experiència de l'usuari. Per això, és important que els equips d'operacions i DevOps creïn processos i gestionen estratègies de desplegament de manera que es minimitzi el risc per al producte i els usuaris. (Podeu obtenir més informació sobre l'automatització de canonades CI/CD .)
En aquesta publicació, parlarem de diverses estratègies de desplegament a Kubernetes, inclosos els desplegaments continuats i mètodes més avançats, com ara els llançaments canaris i les seves variacions.
Estratègies de desplegament
Hi ha diversos tipus d'estratègies de desplegament que podeu utilitzar en funció del vostre objectiu. Per exemple, és possible que hàgiu de fer canvis en un entorn determinat per a més proves, o en un subconjunt d'usuaris/clients, o potser haureu de fer proves limitades d'usuari abans de fer una funció. públic.
Rolling (desplegament gradual, "rolling")
Aquesta és l'estratègia de desplegament estàndard a Kubernetes. A poc a poc, un per un, substitueix els pods amb la versió antiga de l'aplicació per pods amb la nova versió, sense temps d'inactivitat del clúster.
Kubernetes espera fins que els nous pods estiguin preparats per funcionar (comprovant-los amb ), abans de començar a enrotllar els antics. Si es produeix un problema, aquesta actualització continuada es pot avortar sense aturar tot el clúster. Al fitxer YAML que descriu el tipus de desplegament, la imatge nova substitueix la imatge antiga:
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: 8080Els paràmetres d'actualització del rollover es poden especificar al fitxer de manifest:
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
template:
...
Recrear
En aquest tipus de desplegament més senzill, els pods antics s'eliminen alhora i se substitueixen per de nous:
El manifest corresponent s'assembla a això:
spec:
replicas: 3
strategy:
type: Recreate
template:
...Blau/Verd (desplegaments blau-verd)
L'estratègia de desplegament blau-verd (de vegades també anomenada vermell/negre) implica el desplegament simultània de les versions antigues (verdes) i noves (blaves) de l'aplicació. Després de publicar ambdues versions, els usuaris habituals tenen accés a la verda, mentre que la blava està disponible perquè l'equip de control de qualitat automatitzi les proves mitjançant un servei independent o un reenviament directe de ports:
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: awesomeapp-02
spec:
template:
metadata:
labels:
app: awesomeapp
version: "02"Després que la versió blava (nova) s'hagi provat i s'hagi aprovat el seu llançament, el servei hi canvia i la versió verda (vella) es plega:
apiVersion: v1
kind: Service
metadata:
name: awesomeapp
spec:
selector:
app: awesomeapp
version: "02"
...Canary (desplegaments canaris)
Els llançaments de Canary són similars als llançaments blau-verd, però tenen un millor control i ús enfocament pas a pas. Aquest tipus inclou diverses estratègies diferents, com ara llançaments "sigilos" i proves A/B.
Aquesta estratègia s'utilitza quan cal provar alguna funcionalitat nova, normalment al backend de l'aplicació. L'essència de l'enfocament és crear dos servidors gairebé idèntics: un serveix a gairebé tots els usuaris i l'altre, amb noves funcions, només serveix a un petit subgrup d'usuaris, després del qual es comparen els resultats del seu treball. Si tot va sense errors, la nova versió s'amplia gradualment a tota la infraestructura.
Encara que aquesta estratègia es pot implementar exclusivament mitjançant Kubernetes, substituint pods antics per de nous, és molt més còmode i senzill utilitzar una malla de servei com Istio.
Per exemple, podeu tenir dos manifests diferents a Git: un manifest normal amb l'etiqueta 0.1.0 i un manifest canari amb l'etiqueta 0.2.0. Si canvieu els pesos al manifest de la passarel·la virtual d'Istio, podeu controlar la distribució del trànsit entre aquests dos desplegaments:
Per obtenir una guia pas a pas per implementar desplegaments canaris amb Istio, vegeu . (Nota. transl.: També hem traduït material sobre els llançaments canaris a Istio .)
Desplegaments canaris amb Weaveworks Flagger
us permet gestionar de manera fàcil i eficaç els llançaments canaris.
Flagger automatitza el treball amb ells. Utilitza Istio o AWS App Mesh per encaminar i canviar el trànsit, i mètriques de Prometheus per analitzar els resultats. A més, l'anàlisi dels desplegaments canaris es pot complementar amb webhooks per dur a terme proves d'acceptació, proves de càrrega i qualsevol altre tipus de comprovacions.
Basant-se en el desplegament de Kubernetes i, si cal, l'escalat horitzontal de pods (HPA), Flagger crea conjunts d'objectes (desplegaments Kubernetes, serveis ClusterIP i serveis virtuals Istio o App Mesh) per analitzar i implementar desplegaments canaris:
Implementació del bucle de control (bucle de control),Flagger canvia gradualment el trànsit al servidor canari, alhora que mesura mètriques clau de rendiment, com ara el percentatge de sol·licituds HTTP reeixides, la durada mitjana de la sol·licitud i l'estat del pod. A partir de l'anàlisi KPI (Key Performance Indicators), el canari creix o s'enfonsa i els resultats de l'anàlisi es publiquen a Slack. Al material es pot trobar una descripció i demostració d'aquest procés .
Desplegaments foscos (ocults) o A/B
El desplegament furtiu és una altra variació de l'estratègia canària (que, per cert, també pot treballar en Flagger). La diferència entre els desplegaments sigils i canaris és que els desplegaments sigils tracten amb la interfície en lloc del backend com els desplegaments canaris.
Un altre nom per a aquests desplegaments és proves A/B. En lloc de posar la nova funció disponible per a tots els usuaris, només s'ofereix a una part limitada d'ells. Normalment, aquests usuaris no saben que són provadors pioners (d'aquí el terme "desplegament furtiu").
Ús d'interruptors de funcionalitat (canvi de funció) i altres eines, podeu supervisar com els usuaris interactuen amb la nova funció, si hi participen o si troben la nova interfície d'usuari confusa i altres tipus de mètriques.
Desplegaments de bandera i A/B
A més de l'encaminament basat en el pes, Flagger també pot dirigir el trànsit al servidor canari basant-se en paràmetres HTTP. A les proves A/B, podeu utilitzar capçaleres HTTP o galetes per orientar-vos a un segment específic d'usuaris. Això és especialment efectiu en el cas d'aplicacions d'interfície que requereixen l'enllaç de sessió al servidor (afinitat de sessió). Podeu trobar més informació a la documentació de Flagger.
L'autor expressa l'agraïment , enginyer de Weaveworks (i creador de Flagger), per tots aquests patrons de desplegament sorprenents.
PS del traductor
Llegeix també al nostre blog:
- «»;
- «»;
- «»;
- «».
Font: www.habr.com