
Канарената кука — е много ефективен начин за тестване на нов код сред подгрупа от потребители. Това значително намалява натоварването на трафика, с което могат да възникнат проблеми в процеса на разгръщане, тъй като се извършва само в рамките на определена подгрупа. Тази бележка е посветена на това как да организираме подобно разгръщане с помощта на Kubernetes и автоматизация на разгръщането. Предполага се, че знаете нещо за Helm и ресурсите на Kubernetes..

Просто канареното разгръщане в Kubernetes включва два ключови ресурса: самата услуга и инструмента за разгръщане. Канареното разгръщане работи чрез една услуга, която взаимодействува с два различни ресурса, обслужващи трафика на обновленията. Един от тези ресурси ще работи с "канарената" версия, а вторият — с стабилната. В тази ситуация можем да регулираме количеството на канарените версии, за да намалим обема на необходимия трафик. Ако, например, предпочитате да използвате Yaml, то в Kubernetes това ще изглежда по следния начин:
kind: Deployment
metadata:
name: app-canary
labels:
app: app
spec:
replicas: 1
...
image: myapp:canary
---
kind: Deployment
metadata:
name: app
labels:
app: app
spec:
replicas: 5
...
image: myapp:stable
---
kind: Service
selector:
app: app # Селекторът ще насочва трафика към двете разгръщания.Още по-лесно можем да представим тази версия на kubectl, а в даже има пълен туториал по този сценарий. Но основният въпрос на този пост е как възнамеряваме да автоматизираме този процес, използвайки Helm.
Автоматизация на канареното разгръщане
Преди всичко ни е необходима карта на чартовете на Helm, в която вече са включени обсъжданите от нас ресурси. Тя трябва да изглежда приблизително така:
~\/charts\/app
├── Chart.yaml
├── README.md
├── templates
│ ├── NOTES.txt
│ ├── _helpers.tpl
│ ├── deployment.yaml
│ └── service.yaml
└── values.yamlОсновата на концепцията на Helm е управлението на множество версии на релизите. Стабилната версия е нашата основна стабилна клонка на проекта. Но с помощта на Helm можем да разгръщаме канарен релиз с нашия експериментален код. Основното е да запазим обмена на трафика между стабилната версия и канарения релиз. Управлението на всичко това ще бъде чрез специален селектор:
selector:
app.kubernetes.io\/name: myappНашите както "канарийски", така и стабилни ресурси за разгръщане ще посочват този етикет на модулите. Ако всичко е настроено правилно, по време на разгръщането на канарийната версия на нашата Helm карта ще видим, че трафикът ще бъде насочен към новосъздадените модули. Стабилната версия на тази команда ще изглежда така:
helm upgrade
--install myapp
--namespace default
--set app.name=myapp # Попада в app.kubernetes.io/name
--set app.version=v1 # Попада в app.kubernetes.io/version
--set image.tag=stable
--set replicaCount=5Сега нека проверим нашето канарийско издание. За да разгръщаме канарийната версия, трябва да помним две неща. Името на изданието трябва да е различно, за да не приложим ъпдейт на текущата стабилна версия. Версията и етикетът също трябва да са различни, за да можем да разгръщаме различен код и да отбелязваме разликите по етикетите на ресурсите.
helm upgrade
--install myapp-canary
--namespace default
--set app.name=myapp # Попада в app.kubernetes.io/name
--set app.version=v2 # Попада в app.kubernetes.io/version
--set image.tag=canary
--set replicaCount=1Ето, всъщност, това е всичко! Ако пингнете услугата, можете да видите, че канарийната актуализация насочва трафика само част от времето.
Ако търсите инструменти за автоматизация на разгръщането, които включват описаната логика, обърнете внимание на и на . Хелм чартовете, използвани за реализиране на описания по-горе начин, се намират в GitHub, . Всъщност, това беше теоретичен преглед на начина за реализиране на автоматизация на разгръщането на канарийски версии на практика, с конкретни концепции и примери.
Източник: habr.com
