Белешка превод: Овај преглед из Веавеворкс-а представља најпопуларније стратегије увођења апликација и показује како се најнапредније могу имплементирати помоћу Кубернетес Флаггер оператора. Написан је једноставним језиком и садржи визуелне дијаграме који чак и почетницима инжењерима омогућавају да разумеју проблем.
Дијаграм је преузет из стратегије увођења направљене у Цонтаинер Солутионс
Један од највећих изазова у развоју апликација у облаку данас је убрзавање имплементације. У приступу микросервиса, програмери већ раде и дизајнирају потпуно модуларне апликације, омогућавајући различитим тимовима да истовремено пишу код и праве промене у апликацији.
Краће и чешће постављања имају следеће предности:
- Време до тржишта је смањено.
- Нове функције брже долазе до корисника.
- Повратне информације корисника брже стижу до развојног тима. То значи да тим може брже да додаје функције и решава проблеме.
- Морал програмера се повећава: више функција у развоју је забавније за рад.
Али како се учесталост издавања повећава, повећавају се и шансе да негативно утичу на поузданост апликације или корисничко искуство. Због тога је важно за оперативне и ДевОпс тимове да изграде процесе и управљају стратегијама примене на начин који минимизира ризик за производ и кориснике. (Можете сазнати више о аутоматизацији ЦИ/ЦД цевовода .)
У овом посту ћемо разговарати о различитим стратегијама примене у Кубернетес-у, укључујући ротирајуће примене и напредније методе као што су канаринци и њихове варијације.
Стратегије примене
Постоји неколико различитих типова стратегија примене које можете користити у зависности од свог циља. На пример, можда ћете морати да унесете промене у одређено окружење ради даљег тестирања, или у подскуп корисника/клијента, или ћете можда морати да урадите ограничено тестирање корисника пре него што направите функцију јавности.
Роллинг (постепено, „ротирајуће“ распоређивање)
Ово је стандардна стратегија примене у Кубернетесу. Постепено, један по један, замењује подове са старом верзијом апликације са подовима са новом верзијом - без застоја кластера.
Кубернетес чека док нове подове не буду спремне за рад (проверава их користећи ), пре него што почнете да мотате старе. Ако дође до проблема, ово ажурирање се може прекинути без заустављања целог кластера. У ИАМЛ датотеци која описује тип примене, нова слика замењује стару:
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:
...
Рецреате
У овом најједноставнијем типу постављања, старе махуне се убијају одједном и замењују новим:
Одговарајући манифест изгледа отприлике овако:
spec:
replicas: 3
strategy:
type: Recreate
template:
...Плаво/зелено (плаво-зелено распоређивање)
Плаво-зелена стратегија примене (понекад се назива и црвено/црна) укључује истовремену примену старе (зелене) и нове (плаве) верзије апликације. Након објављивања обе верзије, редовни корисници имају приступ зеленој, док је плава доступна КА тиму да аутоматизује тестове путем посебне услуге или директног прослеђивања порта:
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"
...Канарски (канаринац)
Канари су слични плаво-зеленим, али имају бољу контролу и употребу приступ корак по корак. Овај тип укључује неколико различитих стратегија, укључујући „стелт“ лансирање и А/Б тестирање.
Ова стратегија се користи када постоји потреба да се испроба нека нова функционалност, обично у позадини апликације. Суштина приступа је креирање два готово идентична сервера: један опслужује скоро све кориснике, а други, са новим функцијама, опслужује само малу подгрупу корисника, након чега се упоређују резултати њиховог рада. Ако све прође без грешака, нова верзија се постепено уводи на целу инфраструктуру.
Иако се ова стратегија може применити искључиво користећи Кубернетес, замењујући старе подове новима, много је згодније и једноставније користити сервисну мрежу као што је Истио.
На пример, можда имате два различита манифеста у Гиту: обичан манифест са ознаком 0.1.0 и манифест канаринца са ознаком 0.2.0. Променом тежине у манифесту Истио виртуелног мрежног пролаза, можете да контролишете дистрибуцију саобраћаја између ове две примене:
За водич корак по корак за имплементацију Цанари имплементације користећи Истио, погледајте . (Белешка. трансл.: Такође смо превели материјал о лансирању канаринца на Истио .)
Цанари имплементације са Веавеворкс Флаггер-ом
омогућава вам да лако и ефикасно управљате канаринцима.
Флаггер аутоматизује рад са њима. Користи Истио или АВС Апп Месх за рутирање и пребацивање саобраћаја, и Прометхеус метрику за анализу резултата. Поред тога, анализа канаринских имплементација може бити допуњена веб-хуковима за спровођење тестова прихватања, тестова оптерећења и било које друге врсте провера.
На основу имплементације Кубернетес-а и, ако је потребно, хоризонталног скалирања подова (ХПА), Флаггер креира скупове објеката (Кубернетес примену, ЦлустерИП услуге и Истио или Апп Месх виртуелне услуге) за анализу и имплементацију канарских имплементација:
Имплементација контролне петље (контролна петља),Флаггер постепено пребацује саобраћај на Цанари сервер, док истовремено мери кључне метрике учинка као што су проценат успешних ХТТП захтева, просечно трајање захтева и здравље модула. На основу КПИ (Кеи Перформанце Индицаторс) анализе, канаринац или расте или се урушава, а резултати анализе се објављују у Слацк-у. Опис и демонстрација овог процеса могу се наћи у материјалу .
Тамне (скривене) или А/Б примене
Стеалтх примена је још једна варијација стратегије канаринца (са којом, иначе, Флаггер такође може да ради). Разлика између прикривених и канаринских имплементација је у томе што се прикривене примене баве фронтендом, а не позадином као што је канаринско постављање.
Други назив за ове примене је А/Б тестирање. Уместо да нова функција буде доступна свим корисницима, она се нуди само ограниченом делу њих. Типично, ови корисници нису свесни да су они пионирски тестери (отуда и термин „стелт примена“).
Коришћење прекидача функционалности (искључивање функција) и друге алате, можете пратити како корисници ступају у интеракцију са новом функцијом, да ли су ангажовани на њој или да ли сматрају да је нови кориснички интерфејс збуњујући, као и друге врсте показатеља.
Пријаве за означавање и А/Б
Поред рутирања заснованог на тежини, Флаггер такође може да усмерава саобраћај ка канарском серверу на основу ХТТП параметара. У А/Б тестирању можете да користите ХТТП заглавља или колачиће да бисте циљали одређени сегмент корисника. Ово је посебно ефикасно у случају фронтенд апликација које захтевају везивање сесије за сервер (афинитет сесије). Више информација можете пронаћи у документацији за означавање.
Аутор је захвалан , инжењер Веавеворкс-а (и креатор Флаггер-а), за све ове невероватне обрасце примене.
ПС од преводиоца
Прочитајте и на нашем блогу:
- «";
- «";
- «";
- «'.
Извор: ввв.хабр.цом