Забелешка превод: Овој преглед од Weaveworks ги воведува најпопуларните стратегии за пуштање апликации и покажува како најнапредните може да се имплементираат со помош на операторот Kubernetes Flagger. Напишано е на едноставен јазик и содржи визуелни дијаграми кои им овозможуваат дури и на инженерите почетници да го разберат проблемот.
Дијаграмот е земен од стратегии за воведување направени во Container Solutions
Еден од најголемите предизвици во развивањето на природни апликации во облакот денес е забрзувањето на распоредувањето. Во пристапот на микросервис, програмерите веќе работат и дизајнираат целосно модуларни апликации, дозволувајќи им на различни тимови истовремено да пишуваат код и да прават промени во апликацијата.
Пократките и почести распоредувања ги имаат следните предности:
- Времето за пазар е намалено.
- Новите функции побрзо допираат до корисниците.
- Повратните информации од корисниците побрзо стигнуваат до тимот за развој. Ова значи дека тимот може побрзо да додава функции и да ги решава проблемите.
- Моралот на програмерите се зголемува: со повеќе функции во развојот е позабавно да се работи.
Но, како што се зголемува фреквенцијата на изданија, се зголемуваат и шансите за негативно влијание врз доверливоста на апликацијата или на корисничкото искуство. Затоа е важно операциите и тимовите на DevOps да градат процеси и да управуваат со стратегиите за распоредување на начин што го минимизира ризикот за производот и корисниците. (Можете да дознаете повеќе за автоматизацијата на гасоводот CI/CD .)
Во овој пост, ќе разговараме за различни стратегии за распоредување во Kubernetes, вклучително и распоредување на тркалање и понапредни методи како што се пуштање на канари и нивните варијации.
Стратегии за распоредување
Постојат неколку различни видови на стратегии за распоредување кои можете да ги користите во зависност од вашата цел. На пример, можеби ќе треба да направите промени во одредена средина за понатамошно тестирање, или на подгрупа корисници/клиенти, или можеби ќе треба да направите ограничено тестирање на корисниците пред да направите функција јавен.
Тркалање (постепено, „тркалање“ распоредување)
Ова е стандардна стратегија за распоредување во Кубернетес. Постепено, еден по еден, ги заменува мешунките со старата верзија на апликацијата со мешунките со новата верзија - без прекин на кластерот.
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"
...Канари (распоредување на канари)
Распоредувањето на канаринците се слични на сино-зелените, но имаат подобра контрола и употреба чекор-по-чекор пристап. Овој тип вклучува неколку различни стратегии, вклучувајќи лансирање „скришум“ и A/B тестирање.
Оваа стратегија се користи кога има потреба да се испроба некоја нова функционалност, обично во задниот дел на апликацијата. Суштината на пристапот е да се создадат два речиси идентични сервери: едниот им служи на речиси сите корисници, а другиот, со нови функции, опслужува само мала подгрупа на корисници, по што се споредуваат резултатите од нивната работа. Ако сè оди без грешки, новата верзија постепено се шири на целата инфраструктура.
Иако оваа стратегија може да се имплементира исклучиво со користење на Kubernetes, заменувајќи ги старите мешунки со нови, многу е поудобно и поедноставно да се користи сервисна мрежа како Istio.
На пример, може да имате два различни манифестата во Git: редовен манифест со ознака 0.1.0 и манифест канари со ознака 0.2.0. Со менување на тежините во манифестот на виртуелната порта Istio, можете да ја контролирате распределбата на сообраќајот помеѓу овие две распоредувања:
За чекор-по-чекор водич за имплементација на распоредувања на канари со помош на Istio, видете . (Забелешка. превод.: Исто така, преведовме материјал за пуштањето на канари на Истио .)
Канарски распоредувања со Weaveworks Flagger
ви овозможува лесно и ефикасно да управувате со пуштањето канари.
Flagger ја автоматизира работата со нив. Користи Istio или AWS App Mesh за насочување и менување сообраќај, а метрика на Prometheus за анализа на резултатите. Покрај тоа, анализата на распоредувањата на канари може да се дополни со веб-куки за да се спроведат тестови за прифаќање, тестови за оптоварување и какви било други видови проверки.
Врз основа на распоредувањето на Kubernetes и, доколку е потребно, хоризонталното скалирање на pods (HPA), Flagger создава множества на објекти (распоредувања на Kubernetes, услуги ClusterIP и виртуелни услуги Istio или App Mesh) за да ги анализира и имплементира распоредите на канари:
Спроведување на контролната јамка (контролна јамка),Flagger постепено го префрла сообраќајот на серверот Canary, додека истовремено ги мери клучните индикатори за перформанси, како што се процентот на успешни HTTP барања, просечното времетраење на барањето и здравјето на подлогата. Врз основа на анализата KPI (Key Performance Indicators), канаринецот или расте или колабира, а резултатите од анализата се објавени во Slack. Опис и демонстрација на овој процес може да се најдат во материјалот .
Темни (скриени) или A/B распоредувања
Распоредувањето на Stealth е уште една варијација на стратегијата за канаринци (со која, патем, може да работи и Flagger). Разликата помеѓу скришум и канаринските распоредувања е во тоа што скришум распоредувањата се занимаваат со предниот дел, а не со задниот дел како распоредувања на канари.
Друго име за овие распоредувања е A/B тестирање. Наместо новата функција да биде достапна за сите корисници, таа им се нуди само на ограничен дел од нив. Вообичаено, овие корисници не се свесни дека се пионерски тестери (оттука и терминот „стелт распоредување“).
Користење на прекинувачи за функционалност (префрлање на функцијата) и други алатки, можете да следите како корисниците комуницираат со новата функција, дали се ангажирани од неа или дали им е збунувачки новиот кориснички интерфејс и други видови метрика.
Распоредување на Flagger и A/B
Покрај рутирањето засновано на тежина, Flagger може да го насочи сообраќајот до серверот Canary врз основа на параметрите на HTTP. Во тестирањето A/B, можете да користите HTTP заглавија или колачиња за да насочите одреден сегмент на корисници. Ова е особено ефикасно во случај на апликации за преден дел кои бараат врзување на сесијата за серверот (афинитет за сесија). Повеќе информации може да најдете во документацијата на Flagger.
Авторот изразува благодарност , инженер на Weaveworks (и креатор на Flagger), за сите овие неверојатни шеми на распоредување.
PS од преведувач
Прочитајте и на нашиот блог:
- «";
- «";
- «";
- «".
Извор: www.habr.com