Jednoduchý a bezpečný způsob automatizace kanárkových nasazení pomocí Helm

Canary deployment je velmi efektivní způsob testování nového kódu na určité podskupině uživatelů. Výrazně snižuje zatížení provozu, které může vést k problémům během nasazení, protože probíhá pouze v rámci vybrané podskupiny. Tento článek je věnován tomu, jak organizovat takové nasazení pomocí Kubernetes a automatizace nasazení. Předpokládá se, že víte něco o Helmu a zdrojích Kubernetes..



Jednoduché kanárkové nasazení v Kubernetes zahrnuje dva klíčové zdroje: samotnou službu a nástroj pro nasazení. Kanárková nasazení fungují prostřednictvím jedné služby, která interaguje s dvěma různými zdroji obsluhujícími provoz aktualizace. Jeden z těchto zdrojů bude pracovat s „kanárkovou“ verzí a druhý se stabilní. V této situaci můžeme regulovat počet kanárkových verzí, abychom snížili objem potřebného provozu k obsluze. Pokud například dáváte přednost použití Yaml, vypadalo by to v Kubernetes takto:

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 nasměruje provoz na obě nasazení.

Ještě jednodušeji si takovou variantu můžeme představit na kubectl, a v dokumentaci k Kubernetes dokonce existuje úplný tutoriál k tomuto scénáři. Ale hlavní otázka tohoto příspěvku je, jak hodláme automatizovat tento proces pomocí Helmu.

Automatizace kanárkového nasazení

Nejprve budeme potřebovat Helm chart, do kterého již byly zahrnuty výše uvedené zdroje. Měl by vypadat přibližně takto:

~\/charts\/app
├── Chart.yaml
├── README.md
├── templates
│   ├── NOTES.txt
│   ├── _helpers.tpl
│   ├── deployment.yaml
│   └── service.yaml
└── values.yaml

Základní koncept Helmu spočívá v řízení vícero verzí vydání. Stabilní verze je naše hlavní stabilní větev kódu projektu. Ale pomocí Helmu můžeme nasadit kanárkovou verzi s naším experimentálním kódem. Důležité je udržet výměnu provozu mezi stabilní verzí a kanárkovou verzí. Řídit to budeme pomocí speciálního selektoru:

selector:
  app.kubernetes.io\/name: myapp

Naše jak "kanárkové", tak i stable zdroje nasazení budou označovat tuto značku na modulech. Pokud vše správně nastavíme, uvidíme během nasazení kanárkové verze naší Helm chart, že provoz bude směrován na čerstvě nasazené moduly. Stabilní verze tohoto příkazu bude vypadat takto:

helm upgrade
  --install myapp 
  --namespace default 
  --set app.name=myapp       # Přejde do app.kubernetes.io/name
  --set app.version=v1       # Přejde do app.kubernetes.io/version
  --set image.tag=stable 
  --set replicaCount=5

Nyní si zkontrolujme naše kanárkové vydání. Abychom nasadili kanárkovou verzi, musíme mít na paměti dvě věci. Název vydání musí být odlišný, abychom neaplikovali aktualizaci na aktuální stable verzi. Verze a tag také musí být různé, abychom mohli nasadit jiný kód a určit rozdíly podle značek zdrojů.

helm upgrade
  --install myapp-canary 
  --namespace default 
  --set app.name=myapp       # Přejde do app.kubernetes.io/name
  --set app.version=v2       # Přejde do app.kubernetes.io/version
  --set image.tag=canary 
  --set replicaCount=1

A to je vlastně všechno! Pokud pingneme službu, můžeme vidět, že kanárková aktualizace směruje provoz jen část času.

Pokud hledáte nástroje pro automatizaci nasazení, které zahrnují popsanou logiku, pak se podívejte na Deliverybot a na nástroje automatizace Helm na GitHubu. Helm chart, používané pro implementaci výše popsaného způsobu, leží na GitHubu, tady. Celkově šlo o teoretický přehled toho, jak implementovat automatizaci nasazení kanárkových verzí v praxi, se specifickými koncepty a příklady.

Zdroj: habr.com