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