Прим. прев.: Този обзорен материал от 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 (канарейни разгръщания)
Канарените разгръщания са подобни на сините-зелени, но са по-добре управлявани и използват поетапен подход. Към този тип спада няколко различни стратегии, включително „скрити“ стартирания и A/B тестване.
Тази стратегия се прилага, когато е необходимо да се тества нова функционалност, обикновено в бекенда на приложението. Същността на подхода е да се създадат два почти идентични сървъра: единият обслужва почти всички потребители, а другият, с новите функции, обслужва само малка подгрупа от потребители, след което се сравняват резултатите от тяхната работа. Ако всичко минава без проблеми, новата версия постепенно се внедрява в цялата инфраструктура.
Въпреки че тази стратегия може да се реализира изцяло с помощта на Kubernetes, заменяйки старите pod'ове с нови, много по-удобно и лесно е да се използва service mesh като Istio.
Например, можете да имате два различни манифеста в Git: обичаен с етикет 0.1.0 и "канареечен" с етикет 0.2.0. Чрез променяне на тежестите в манифеста на виртуалния шлюз Istio можете да управлявате разпределението на трафика между тези два deployment'а:
Стъпка по стъпка ръководство за реализация на канареечни развертки с помощта на Istio можете да намерите в материала . (Прим. прев.: Ние също преведохме материала за канареечните развертки в Istio .)
Канареечни развертки с Weaveworks Flagger
позволява лесно и ефективно управление на канареечните развертки.
Flagger автоматизира работата с тях. Той използва Istio или AWS App Mesh за маршрутизиране и пренасочване на трафика, както и метриките на Prometheus за анализ на резултатите. Освен това, анализът на канареечните развертки може да бъде допълнен с вебхукове за провеждане на приемочни тестове, тестове за натоварване и всякакви други видове проверки.
На базата на deployment'a на Kubernetes и, при необходимост, хоризонталното мащабиране на pod'овете (HPA), Flagger създава набори от обекти (Kubernetes deployment'и, ClusterIP услуги и виртуални услуги Istio или App Mesh) за извършване на анализ и реализация на канареечни развертки:
Реализирайки контур на управление (control loop), Flagger постепенно пренасочва трафика към канареечния сървър, паралелно измервайки ключови показатели на производителността, като процента на успешни HTTP заявки, средната продължителност на заявката и здравето на pod'овете. На базата на анализа на KPI (ключовите показатели на изпълнението), канареечната част или нараства, или намалява, и резултатите от анализа се публикуват в Slack. Описание и демонстрация на този процес можете да намерите в материала .
Тъмно (скрити) или А/В разгръщания
Скритото разгръщане е още един вариант на канарейската стратегия (с която, между другото, Flagger също може да работи). Разликата между скритото и канарейското разгръщане е, че скритите разгръщания се отнасят до фронтенда, а не до бекенда, както е при канарейските.
Друго название на тези разгръщания е А/В тестване. Вместо да се предостави достъп до нова функция на всички потребители, тя се предлага само на ограничена част от тях. Обикновено тези потребители не знаят, че изпълняват ролята на тестери-пионери (оттук и терминът „скрито разгръщане“).
С помощта на функционални превключватели (feature toggles) и други инструменти може да се следи как потребителите взаимодействат с новата функция, привлекателна ли е за тях или новият потребителски интерфейс е объркващ, и други типове метрики.
Flagger и A/В разгръщания
В допълнение към маршрутизирането с тегла, Flagger може също така да насочва трафика към канарейския сървър в зависимост от HTTP параметри. При А/В тестването могат да се използват HTTP заглавия или бисквитки за пренасочване на определен сегмент от потребители. Това е особено ефективно в случая на фронтенд приложения, изискващи свързване на сесията със сървъра (session affinity). Допълнителна информация може да бъде намерена в документацията на Flagger.
Авторът изразява благодарност , инженер в Weaveworks (и създател на Flagger), за всички тези невероятни схеми на деплой.
P.S. от преводача
Прочетете също в нашия блог:
- «»;
- «»;
- «»;
- «».
Източник: habr.com
