Заўв. перав.: Гэты аглядны матэрыял ад Weaveworks знаёміць з найбольш папулярнымі стратэгіямі выкату прыкладанняў і расказвае аб магчымасці рэалізацыі найбольш прасунутых з іх з дапамогай Kubernetes-аператара Flagger. Ён напісаны простай мовай і змяшчае наглядныя схемы, якія дазваляюць разабрацца ў пытанні нават пачаткоўцам інжынерам.
Схема ўзята з стратэгій выкату, зробленага ў Container Solutions
Адной з самых вялікіх праблем пры распрацоўцы cloud native-прыкладанняў сёння з'яўляецца паскарэнне дэплою. Пры мікрасэрвісным падыходзе распрацоўшчыкі ўжо працуюць з цалкам модульнымі праграмамі і праектуюць іх, дазваляючы розным камандам адначасова пісаць код і ўносіць змены ў дадатак.
Карацейшыя і частыя разгортванні маюць наступныя перавагі:
- Скарачаецца час выхаду на рынак.
- Новыя функцыі хутчэй трапляюць да карыстальнікаў.
- Водгукі карыстальнікаў хутчэй даходзяць да каманды распрацоўшчыкаў. Гэта значыць, што каманда можа дапаўняць функцыі і выпраўляць праблемы больш аператыўна.
- Павялічваецца маральны дух распрацоўшчыкаў: з вялікай колькасцю функцый у распрацоўцы цікавей працаваць.
Але з павелічэннем частаты рэлізаў таксама павышаюцца шанцы негатыўна паўплываць на надзейнасць прыкладання або карыстацкі досвед. Менавіта таму камандам эксплуатацыі і DevOps важна будаваць працэсы і кіраваць стратэгіямі разгортвання такім чынам, каб мінімізаваць рызыку для прадукта і карыстачоў. (Даведацца больш пра аўтаматызацыі CI/CD-пайплайна можна .)
У гэтай публікацыі мы абмяркуем розныя стратэгіі дэплою ў Kubernetes, у тым ліку rolling-разгортвання і больш прасунутыя метады, такія як канарэечныя (canary) выкаты і іх разнавіднасці.
Стратэгіі дэплою
Існуе некалькі розных тыпаў стратэгій разгортвання, якімі можна карыстацца ў залежнасці ад мэты. Напрыклад, вам можа запатрабавацца занесці змены ў нейкае асяроддзе для наступнага тэставання, ці ў падмноства карыстачоў/кліентаў, ці паўстане неабходнасць правесці абмежаванае тэставанне на карыстачах, перш чым зрабіць нейкую функцыю агульнадаступнай.
Rolling (паступовы, "накатваецца" дэплой)
Гэта стандартная стратэгія разгортвання ў Kubernetes. Яна паступова, адзін за іншым, замяняе pod'ы са старой версіяй прыкладання на pod'ы з новай версіяй - без прастою кластара.
Kubernetes чакае гатоўнасці новых pod'аў да працы (правяраючы іх з дапамогай ), перш чым прыступіць да згортвання старых. Калі ўзнікае праблема, падобнае якое накатваецца абнаўленне можна перапыніць, не спыняючы ўсяго кластара. У YAML-файле з апісаннем тыпу deployment'а новая выява замяняе сабой стары вобраз:
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: 8080Параметры абнаўлення, якое накатваецца, можна ўдакладніць у файле маніфесту:
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 25%
maxUnavailable: 25%
template:
...
Recreate (паўторнае стварэнне)
У гэтым найпростым тыпе разгортвання старыя pod'ы забіваюцца ўсё зараз і замяняюцца новымі:
Адпаведны маніфест выглядае прыкладна так:
spec:
replicas: 3
strategy:
type: Recreate
template:
...Blue/Green (сіне-зялёныя разгортванні)
Стратэгія сіне-зялёнага разгортвання (часам яе яшчэ завуць red/black, т.е. чырвона-чорнай) прадугледжвае адначасовае разгортванне старой (зялёнай) і новай (сіняй) версій прыкладання. Пасля размяшчэння абедзвюх версій звычайныя карыстальнікі атрымліваюць доступ да зялёнай, у той час як сіняя даступная для QA-каманды для аўтаматызацыі тэстаў праз асобны сэрвіс або прамы пракід партоў:
apiVersion: apps/v1beta1
kind: Deployment
metadata:
name: awesomeapp-02
spec:
template:
metadata:
labels:
app: awesomeapp
version: "02"Пасля таго, як сіняя (новая) версія была пратэставаная і быў ухвалены яе рэліз, сэрвіс перамыкаецца на яе, а зялёная (старая) згортваецца:
apiVersion: v1
kind: Service
metadata:
name: awesomeapp
spec:
selector:
app: awesomeapp
version: "02"
...Canary (канарэечныя разгортванні)
Канарэечныя выкаты падобныя на сіне-зялёныя, але лепш кіруюцца і выкарыстоўваюць паэтапны падыход. Да гэтага тыпу ставяцца некалькі розных стратэгій, у тым ліку «схаваныя» запускі і А/У-тэставанне.
Гэтая стратэгія прымяняецца, калі неабходна выпрабаваць нейкую новую функцыянальнасць, як правіла, у бэкендзе прыкладання. Сутнасць падыходу ў тым, каб стварыць два практычна аднолькавых сервера: адзін абслугоўвае амаль усіх карыстачоў, а іншы, з новымі функцыямі, абслугоўвае толькі невялікую падгрупу карыстачоў, пасля чаго вынікі іх працы параўноўваюцца. Калі ўсё праходзіць без памылак, новая версія паступова выкочваецца на ўсю інфраструктуру.
Хоць дадзеную стратэгію можна рэалізаваць выключна сродкамі Kubernetes, замяняючы старыя pod'ы на новыя, значна зручней і прасцей выкарыстоўваць service mesh накшталт Istio.
Напрыклад, у вас можа быць два розных маніфесту ў Git: звычайны з тэгам 0.1.0 і «канарэечны» з тэгам 0.2.0. Змяняючы вагі ў маніфесце віртуальнага шлюза Istio, можна кіраваць размеркаваннем трафіку паміж гэтымі двума deployment'амі:
Пакрокавае кіраўніцтва па рэалізацыі канарэечных разгортванняў з дапамогай Istio можна знайсці ў матэрыяле . (Заўв. перав.: Мы таксама перакладалі матэрыял пра канарэечныя выкаты ў Istio. .)
Канарэечныя разгортванні з Weaveworks Flagger
дазваляе лёгка і эфектыўна кіраваць канарэечнымі выкатамі.
Flagger аўтаматызуе працу з імі. Ён выкарыстоўвае Istio ці AWS App Mesh для маршрутызацыі і пераключэнні трафіку, а таксама метрыкі Prometheus для аналізу вынікаў. Акрамя таго, аналіз канарэчных разгортванняў можна дапоўніць вебхуками для правядзення прыёмачных (acceptance) тэстаў, нагрузачных і любых іншых тыпаў праверак.
На аснове deployment'а Kubernetes і, пры неабходнасці, гарызантальнага маштабавання pod'аў (HPA), Flagger стварае наборы з аб'ектаў (deployment'ы Kubernetes, сэрвісы ClusterIP і віртуальныя сэрвісы Istio або App Mesh) для правядзення аналізу і рэалізацыі канарэчных разгортванняў:
Рэалізуючы контур кіравання (control loop), Flagger паступова перамыкае трафік на канарэчны сервер, паралельна вымяраючы ключавыя паказчыкі прадукцыйнасці, такія як доля паспяховых HTTP-запытаў, сярэдняя працягласць запыту і здароўе pod'аў. Грунтуючыся на аналізе KPI (ключавых паказчыкаў эфектыўнасці), канарэечная частка альбо расце, альбо згортваецца, і вынікі аналізу публікуюцца ў Slack. Апісанне і дэманстрацыю гэтага працэсу можна знайсці ў матэрыяле .
Dark (схаваная) або А/У-разгортванні
Утоенае разгортванне – яшчэ адна варыяцыя канарэечнай стратэгіі (з ёй, дарэчы, Flagger таксама можа працаваць). Розніца паміж утоеным і канарэечным разгортваннем складаецца ў тым, што ўтоеныя разгортванні маюць справу з франтэндам, а не з бэкендом, як канарэечныя.
Іншая назва гэтых разгортванняў - А/У-тэставанне. Замест таго, каб адкрыць доступ да новай функцыі ўсім карыстальнікам, яе прапануюць толькі абмежаванай іх часткі. Звычайна гэтыя карыстачы не ведаюць, што выступаюць тэстарамі-першапраходцамі (адгэтуль і тэрмін «утоенае разгортванне»).
З дапамогай перамыкачоў функцыянальнасці (feature toggles) і іншых прылад можна сачыць за тым, як карыстачы ўзаемадзейнічаюць з новай функцыяй, ці захапляе яна іх ці яны лічаць новы карыстацкі інтэрфейс заблытаным, і іншымі тыпамі метрык.
Flagger і A/B-разгортванні
Апроч маршрутызацыі з улікам шаляў, Flagger таксама можа накіроўваць на канарэчны сервер трафік у залежнасці ад параметраў HTTP. Пры А/У-тэставанні можна выкарыстоўваць загалоўкі HTTP або файлы cookie для перанакіравання вызначанага сегмента карыстачоў. Гэта асабліва эфектыўна ў выпадку frontend-прыкладанняў, якія патрабуюць прывязкі сесіі да сервера (session affinity). Дадатковую інфармацыю можна знайсці ў дакументацыі Flagger.
Аўтар выказвае падзяку , Інжынеру Weaveworks (і стваральніку Flagger), за ўсе гэтыя цудоўныя схемы дэплою.
PS ад перакладчыка
Чытайце таксама ў нашым блогу:
- «»;
- «»;
- «»;
- «.
Крыніца: habr.com