Прим. перекл.: Цей оглядовий матеріал від 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 (канаркові розгортання)
Канаркові викати схожі на синьо-зелені, але краще управляються і використовують поетапний підхід. До цього типу належать кілька різних стратегій, включаючи «приховані» запуски та А/В-тестування.
Ця стратегія застосовується, коли необхідно випробувати якусь нову функціональність, як правило, у бекенді програми. Суть підходу в тому, щоб створити два практично однакових сервери: один обслуговує майже всіх користувачів, а інший з новими функціями обслуговує лише невелику підгрупу користувачів, після чого результати їх роботи порівнюються. Якщо все відбувається без помилок, нова версія поступово викочується на всю інфраструктуру.
Хоча цю стратегію можна реалізувати виключно засобами Kubernetes, замінюючи старі pod'и на нові, набагато зручніше та простіше використовувати service mesh на зразок Istio.
Наприклад, у вас може бути два різні маніфести в Git: звичайний з тегом 0.1.0 і «канарієчний» з тегом 0.2.0. Змінюючи ваги в маніфесті віртуального шлюзу Istio, можна керувати розподілом трафіку між цими двома deployment'ами:
Покроковий посібник з реалізації канаркових розгортань за допомогою Istio можна знайти в матеріалі . (Прим. перев.: Ми також перекладали матеріал про канаркові викати в Istio. .)
Канаркові розгортання з Weaveworks Flagger
дозволяє легко та ефективно керувати канарковими викочуваннями.
Flagger автоматизує роботу із нею. Він використовує Istio або AWS App Mesh для маршрутизації та перемикання трафіку, а також метрики Prometheus для аналізу результатів. Крім того, аналіз канаркових розгортань можна доповнити вебхуками для проведення приймальних (acceptance) тестів, навантажувальних та будь-яких інших типів перевірок.
На основі deployment'у Kubernetes і, при необхідності, горизонтального масштабування pod'ів (HPA), Flagger створює набори з об'єктів (deployment'и Kubernetes, сервіси ClusterIP і віртуальні сервіси Istio або App Mesh) для проведення аналізу та реалізації канаркових розгортань:
Реалізуючи контур керування (control loop), Flagger поступово перемикає трафік на канарковий сервер, паралельно вимірюючи ключові показники продуктивності, такі як частка успішних HTTP-запитів, середня тривалість запиту та здоров'я pod'ів. Грунтуючись на аналізі KPI (ключових показників ефективності), канаркова частина або зростає, або згортається, і результати аналізу публікуються в Slack. Опис та демонстрацію цього процесу можна знайти у матеріалі .
Dark (приховані) або А/В-розгортання
Приховане розгортання — ще одна варіація канаркової стратегії (з нею, до речі, Flagger також може працювати). Різниця між прихованим і канарковим розгортанням полягає в тому, що приховані розгортання мають справу з фронтендом, а не з бекендом, як канаркові.
Інша назва цих розгортань – А/В-тестування. Замість того, щоб відкрити доступ до нової функції всім користувачам, її пропонують лише їх обмеженій частині. Зазвичай, ці користувачі не знають, що виступають тестерами-першопрохідцями (звідси і термін «приховане розгортання»).
За допомогою перемикачів функціональності (Feature toggles) та інших інструментів можна стежити за тим, як користувачі взаємодіють з новою функцією, захоплює вона їх чи вони вважають новий інтерфейс користувача заплутаним, та іншими типами метрик.
Flagger та A/B-розгортання
Крім маршрутизації з урахуванням ваг, Flagger також може направляти на канарковий сервер трафік залежно від параметрів HTTP. При тестуванні А/В можна використовувати заголовки HTTP або файли cookie для перенаправлення певного сегмента користувачів. Це особливо ефективно у разі frontend-додатків, що вимагають прив'язки сесії до сервера (session affinity). Додаткову інформацію можна знайти у документації Flagger.
Автор висловлює подяку , інженеру Weaveworks (і творцю Flagger), за всі ці чудові схеми деплою.
PS від перекладача
Читайте також у нашому блозі:
- «»;
- «»;
- «»;
- «».
Джерело: habr.com