Распоредувањето на Canary е многу ефикасен начин за тестирање на нов код на подгрупа корисници. Тоа значително го намалува оптоварувањето на сообраќајот што може да биде проблематично за време на процесот на распоредување, бидејќи се јавува само во специфично подмножество. Оваа белешка е посветена на тоа како да се организира такво распоредување користејќи Kubernetes и автоматизација на распоредувањето. Претпоставуваме дека знаете нешто за ресурсите на Helm и Kubernetes.
Едноставно распоредување на канари во Кубернетес вклучува два клучни ресурси: самата услуга и алатката за распоредување. Распоредувањето на 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 и во
Автоматизација на распоредувањето на канаринци
Пред сè, потребна ни е мапа на дијаграмот на 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 chart ќе видиме дека сообраќајот ќе биде насочен кон новопоставените модули. Стабилната верзија на оваа команда ќе изгледа вака:
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
Сега да го провериме нашето ослободување на канари. За да ја распоредиме верзијата на канари, треба да запомниме две работи. Името на изданието мора да биде различно за да не објавиме ажурирање на тековната стабилна верзија. Верзијата и ознаката исто така мора да бидат различни за да можеме да распоредиме друг код и да ги идентификуваме разликите по ознаки за ресурси.
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
Тоа е се! Ако ја пингувате услугата, можете да видите дека ажурирањето на канаринците го насочува сообраќајот само дел од времето.
Ако барате алатки за автоматизација на распоредувањето што ја вклучуваат опишаната логика, тогаш обрнете внимание
Извор: www.habr.com