Забележка. превод: Това ръководство от Weaveworks представя най-популярните стратегии за внедряване на приложения и как можете да внедрите най-напредналите с оператора Flagger Kubernetes. Написан е на прост език и съдържа визуални диаграми, които позволяват дори на начинаещи инженери да разберат проблема.
Диаграма взета от стратегии за внедряване, направени в контейнерни решения
Едно от най-големите предизвикателства при разработването на облачни приложения днес е скоростта на внедряване. С подхода на микросервизите разработчиците вече работят и проектират напълно модулни приложения, което позволява на различни екипи да пишат код и да правят промени в приложението едновременно.
По-кратките и по-чести внедрявания имат следните предимства:
- Намалено време за излизане на пазара.
- Новите функции достигат до потребителите по-бързо.
- Отзивите на потребителите достигат по-бързо до екипа за разработка. Това означава, че екипът може да добавя функции и да коригира проблеми по-бързо.
- Моралът на разработчиците се повишава: повече функции в разработката са по-забавни за работа.
Но тъй като честотата на изданията се увеличава, шансовете за отрицателно въздействие върху надеждността на приложението или потребителското изживяване също се увеличават. Ето защо е важно за операциите и DevOps екипите да изграждат процеси и да управляват стратегии за внедряване по начин, който минимизира риска за продукта и потребителите. (За да научите повече за автоматизирането на CI/CD тръбопровода, вижте .)
В тази публикация ще обсъдим различни стратегии за внедряване на Kubernetes, включително непрекъснато внедряване и по-усъвършенствани методи като внедряване на Canary и техните вариации.
Стратегии за внедряване
Има няколко различни типа стратегии за внедряване, които могат да се използват в зависимост от целта. Например, може да се наложи да направите промени в някаква среда за по-нататъшно тестване или в подгрупа от потребители/клиенти, или може да се наложи да направите ограничено тестване на потребители, преди да направите функция публичен.
Подвижен (постепенно, подвижно разгръщане)
Това е стандартната стратегия за внедряване на Kubernetes. Постепенно, един по един, заменя pods със старата версия на приложението с pods с новата версия - без престой на клъстера.
Kubernetes чака новите подове да бъдат готови за работа (проверява ги с ), преди да пристъпите към навиване на старите. Ако възникне проблем, такава непрекъсната актуализация може да бъде прекъсната, без да се спира целият клъстер. В 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:
...
Пресъздаване (пресъздаване)
При този най-прост тип внедряване, старите подове се унищожават наведнъж и се заменят с нови:
Съответният манифест изглежда по следния начин:
spec:
replicas: 3
strategy:
type: Recreate
template:
...Синьо/зелено (синьо-зелени внедрявания)
Синьо-зелената стратегия за внедряване (понякога наричана също червено/черно, т.е. червено-черна) включва едновременното внедряване на старата (зелена) и новата (синя) версии на приложението. След като и двете версии бъдат хоствани, зелената е достъпна за обикновения потребител, докато синята е достъпна за 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 (канарски внедрявания)
Canary rollouts са подобни на синьо-зелените, но по-добре контролирани и използвани подход стъпка по стъпка. Няколко различни стратегии попадат в тази категория, включително тайни изстрелвания и A/B тестване.
Тази стратегия се използва, когато трябва да се тества някаква нова функционалност, обикновено в бекенда на приложението. Същността на подхода е да се създадат два почти идентични сървъра: единият обслужва почти всички потребители, а другият, с нови функции, обслужва само малка подгрупа потребители, след което се сравняват резултатите от тяхната работа. Ако всичко върви без грешки, новата версия постепенно се разпространява в цялата инфраструктура.
Въпреки че тази стратегия може да се приложи изключително с помощта на Kubernetes, като се заменят старите подове с нови, много по-удобно и по-лесно е да се използва сервизна мрежа като Istio.
Например, може да имате два различни Git манифеста: обикновен с таг 0.1.0 и канарски с таг 0.2.0. Чрез промяна на теглата в манифеста на Istio Virtual Gateway можете да контролирате разпределението на трафика между тези две внедрявания:
Ръководство стъпка по стъпка за внедряване на Canary внедрявания с Istio може да се намери в . (Забележка. превод: Преведохме и материал за канарчета в Istio .)
Внедрявания на Canary с Weaveworks Flagger
позволява лесно и ефективно управление на канарчета.
Flagger автоматизира работата с тях. Той използва Istio или AWS App Mesh за маршрутизиране и превключване на трафика и показатели на Prometheus за анализиране на резултатите. В допълнение, анализът на внедряването на canary може да бъде допълнен с уеб кукички за провеждане на тестове за приемане, тестове за натоварване и всякакви други видове проверки.
Въз основа на внедряването на Kubernetes и, ако е необходимо, scale-out pods (HPA), Flagger създава набори от обекти (внедрявания на Kubernetes, услуги на ClusterIP и виртуални услуги Istio или App Mesh), за да анализира и внедри внедрявания на canary:
Реализиране на контролен контур (контролен контур)Flagger постепенно превключва трафика към canary сървъра, като същевременно измерва ключови показатели за производителност, като процент на успех на HTTP заявката, средна продължителност на заявката и здраве на pod. Въз основа на анализа на KPI (ключови показатели за ефективност), канарческата част или расте, или се свива, а резултатите от анализа се публикуват в Slack. Описание и демонстрация на този процес можете да намерите в материала .
Тъмни (скрити) или A/V внедрявания
Стелт разгръщането е друг вариант на стратегията за канарчета (с която, между другото, Flagger също може да работи). Разликата между стелт и канарите внедрявания е, че стелт внедряванията се занимават с предния край, а не с бекенда, както правят внедряванията на канарите.
Друго име за тези внедрявания е A/B тестване. Вместо да отвори достъп до нова функция за всички потребители, тя се предлага само на ограничена част от тях. Обикновено тези потребители не знаят, че са пионерски тестери (оттук и терминът „безшумно внедряване“).
С функционални превключватели (превключва функции) и други инструменти, можете да наблюдавате как потребителите взаимодействат с нова функция, дали са пристрастени към нея или намират новия потребителски интерфейс за объркващ и други видове показатели.
Flagger и A/B внедрявания
В допълнение към претегленото маршрутизиране, Flagger може също така да маршрутизира трафик към canary сървъра въз основа на HTTP параметри. A/B тестването може да използва HTTP заглавки или бисквитки за пренасочване на определен сегмент от потребители. Това е особено ефективно в случай на предни приложения, които изискват сесията да бъде обвързана със сървъра. (афинитет на сесията). Повече информация можете да намерите в документацията на Flagger.
Авторът е благодарен , инженер на Weaveworks (и създател на Flagger), за всички тези удивителни схеми за внедряване.
PS от преводача
Прочетете също в нашия блог:
- «»;
- «»;
- «»;
- «".
Източник: www.habr.com