Внедряването на Canary е много ефективен начин за тестване на нов код върху подгрупа от потребители. Това значително намалява натоварването на трафика, което може да бъде проблематично по време на процеса на внедряване, тъй като се случва само в рамките на конкретно подмножество. Тази бележка е посветена на това как да се организира такова внедряване с помощта на Kubernetes и автоматизация на внедряването. Предполагаме, че знаете нещо за ресурсите на Helm и Kubernetes.
Едно просто внедряване на Canary в Kubernetes включва два ключови ресурса: самата услуга и инструмента за внедряване. Внедряването на Canary работи чрез една услуга, която взаимодейства с два различни ресурса, обслужващи трафик за актуализиране. Един от тези ресурси ще работи с версията „canary“, а вторият ще работи със стабилната версия. В тази ситуация можем да регулираме броя на канарските версии, за да намалим обема на трафика, необходим за обслужване. Ако например предпочитате да използвате 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 # Selector will route traffic to both deployments.
Още по-лесно е да си представите тази опция с помощта на kubectl и in
Автоматизация на разгръщането на Canary
На първо място, имаме нужда от карта с диаграма на Helm, която вече включва ресурсите, които обсъдихме по-горе. Трябва да изглежда нещо подобно:
~/charts/app
├── Chart.yaml
├── README.md
├── templates
│ ├── NOTES.txt
│ ├── _helpers.tpl
│ ├── deployment.yaml
│ └── service.yaml
└── values.yaml
Основата на концепцията Helm е управлението на многоверсионни версии. Стабилната версия е основният ни стабилен клон на кода на проекта. Но с Helm можем да внедрим версия на Canary с нашия експериментален код. Основното нещо е да се поддържа обмен на трафик между стабилната версия и изданието Canary. Ще управляваме всичко това с помощта на специален селектор:
selector:
app.kubernetes.io/name: myapp
Нашите ресурси за „канарче“ и стабилно внедряване ще показват този етикет върху модулите. Ако всичко е конфигурирано правилно, тогава по време на внедряването на канарската версия на нашата карта с диаграма на Helm ще видим, че трафикът ще бъде насочен към новоразгърнатите модули. Стабилната версия на тази команда ще изглежда така:
helm upgrade
--install myapp
--namespace default
--set app.name=myapp # Goes into app.kubernetes.io/name
--set app.version=v1 # Goes into app.kubernetes.io/version
--set image.tag=stable
--set replicaCount=5
Сега нека проверим нашето канарче. За да внедрим версията canary, трябва да запомним две неща. Името на версията трябва да е различно, за да не пуснем актуализация до текущата стабилна версия. Версията и етикетът също трябва да са различни, за да можем да внедрим друг код и да идентифицираме разликите чрез ресурсни тагове.
helm upgrade
--install myapp-canary
--namespace default
--set app.name=myapp # Goes into app.kubernetes.io/name
--set app.version=v2 # Goes into app.kubernetes.io/version
--set image.tag=canary
--set replicaCount=1
Това е всичко! Ако пингвате услугата, можете да видите, че актуализацията на Canary маршрутизира трафика само през част от времето.
Ако търсите инструменти за автоматизация на внедряване, които включват описаната логика, тогава обърнете внимание на
Източник: www.habr.com