🥇 Распоредување на Canary во Kubernetes #2: Argo Rollouts

Ќе го користиме контролорот за распоредување Argo Rollouts од k8s и GitlabCI за да извршиме распоредувања на Canary на Kubernetes

https://unsplash.com/photos/V41PulGL1z0

Статии од оваа серија

Распоредување на Canary во Kubernetes #1: Gitlab CI
(Оваа статија)
Распоредување на Канари со користење на Истио
Распоредување на Canary со помош на Jenkins-X Istio Flagger

Распоредување на канари

Се надеваме дека ќе прочитате првиот дел, каде што накратко објаснивме што се тоа Canary Deployments. Исто така, покажавме како да го имплементираме користејќи стандардни ресурси на Кубернет.

Argo Rollouts

Argo Rollouts е природен контролер за распоредување на Kubernetes. Обезбедува CRD (Custom Resource Definition) за Kubernetes. Благодарение на него, можеме да користиме нов ентитет: Rollout, кој управува со распоредувања на сино-зелени и канаринци со различни опции за конфигурација.

Контролер на Argo Rollouts што се користи од приспособен ресурс Rollout, Овозможува дополнителни стратегии за распоредување како што се сино-зелени и канари за Кубернети. Ресурс Rollout обезбедува еквивалент на функционалност Deployment, само со дополнителни стратегии за распоредување.
ресурси Deployments има две стратегии за распоредување: RollingUpdate и Recreate. Иако овие стратегии се погодни за повеќето случаи, за распоредување на сервери во многу голем обем, се користат дополнителни стратегии, како сино-зелена или канаринска боја, кои не се достапни во контролерот за распоредување. За да ги користат овие стратегии во Kubernetes, корисниците мораа да пишуваат скрипти на врвот на нивните распоредувања. Контролорот Argo Rollouts ги изложува овие стратегии како едноставни, декларативни, конфигурабилни параметри.
https://argoproj.github.io/argo-rollouts

Исто така постои и Argo CI, кој обезбедува удобен веб-интерфејс за употреба со Rollouts, ќе го разгледаме во следната статија.

Инсталирање на Argo Rollouts

Серверска страна

kubectl create namespace argo-rolloutskubectl apply -n argo-rollouts -f https://raw.githubusercontent.com/argoproj/argo-rollouts/stable/manifests/install.yaml

Во нашата инфраструктура репка (види подолу) веќе додадовме install.yaml како i/k8s/argo-rollouts/install.yaml. На овој начин GitlabCI ќе го инсталира во кластерот.

Клиентска страна (приклучок kubectl)

https://argoproj.github.io/argo-rollouts/features/kubectl-plugin

Пример за апликација

Добра практика е да има посебни складишта за кодот на апликацијата и инфраструктурата.

Репозиториум за апликацијата

Kim Wuestkamp/k8s-deployment-example-app

Ова е многу едноставно Python+Flask API што враќа одговор како JSON. Ќе го изградиме пакетот користејќи GitlabCI и ќе го туркаме резултатот во регистарот Gitlab. Во регистарот имаме две различни верзии на издавање:

wuestkamp/k8s-deployment-example-app:v1
wuestkamp/k8s-deployment-example-app:v2

Единствената разлика меѓу нив е вратената датотека JSON. Ја користиме оваа апликација за да визуализираме што е можно полесно со која верзија комуницираме.

Инфраструктурно складиште

Во ова складиште ќе користиме GitlabCI за распоредување на Kubernetes, .gitlab-ci.yml изгледа вака:

image: traherom/kustomize-dockerbefore_script:
   - printenv
   - kubectl versionstages:
 - deploydeploy test:
   stage: deploy
   before_script:
     - echo $KUBECONFIG
   script:
     - kubectl get all
     - kubectl apply -f i/k8s    only:
     - master

За да го извршите сами, ќе ви треба кластер, можете да го користите Gcloud:

gcloud container clusters create canary --num-nodes 3 --zone europe-west3-b
gcloud compute firewall-rules create incoming-80 --allow tcp:80

Треба да вилушка https://gitlab.com/wuestkamp/k8s-deployment-example-canary-infrastructure и креирајте променлива KUBECONFIG во GitlabCI, кој ќе ја содржи конфигурацијата за пристап kubectl до вашиот кластер.

Тука Можете да прочитате како да добиете акредитиви за кластер (Gcloud).

Инфраструктура Јамл

Внатре во складиштето за инфраструктура имаме услуга:

apiVersion: v1
kind: Service
metadata:
 labels:
   id: rollout-canary
 name: app
spec:
 ports:
 - port: 80
   protocol: TCP
   targetPort: 5000
 selector:
   id: app
 type: LoadBalancer

и rollout.yaml :

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
 name: rollout-canary
spec:
 replicas: 10
 revisionHistoryLimit: 2
 selector:
   matchLabels:
     id: rollout-canary
 template:
   metadata:
     labels:
       id: rollout-canary
   spec:
     containers:
     - name: rollouts-demo
       image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v1
       imagePullPolicy: Always
 strategy:
   canary:
     steps:
     - setWeight: 10
     # Rollouts can be manually resumed by running `kubectl argo rollouts promote ROLLOUT`
     - pause: {}
     - setWeight: 50
     - pause: { duration: 120 } # two minutes

Rollout работи исто како и Deployment. Ако не поставиме стратегија за ажурирање (како што е Canary овде), таа ќе се однесува како стандардното распоредување на ажурирање.

Ние дефинираме два чекори во јамл за распоредување на канари:

10% од сообраќајот до канаринците (почекајте рачно ОК)
50% сообраќај до канаринци (почекајте 2 минути па продолжи до 100%)

Изведување на првично распоредување

По првичното распоредување, нашите ресурси ќе изгледаат вака:

И добиваме одговор само од првата верзија на апликацијата:

Изведување на распоредување на Канари

Чекор 1: 10% сообраќај

За да започнеме распоредување на канари, само треба да ја смениме верзијата на сликата како што обично правиме со распоредувањата:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
 name: rollout-canary
spec:
...
 template:
   metadata:
     labels:
       id: rollout-canary
   spec:
     containers:
     - name: rollouts-demo
       image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v2
...

И ги притискаме промените, така што Gitlab CI се распоредува и ги гледаме промените:

Сега, ако пристапиме до услугата:

Одлично! Ние сме во средината на нашето распоредување на канаринци. Можеме да го видиме напредокот со трчање:

kubectl argo rollouts get rollout rollout-canary

Чекор 2: 50% сообраќај:

Сега да преминеме на следниот чекор: пренасочување на 50% од сообраќајот. Го конфигуриравме овој чекор да се извршува рачно:

kubectl argo rollouts promote rollout-canary # continue to step 2

И нашата апликација врати 50% од одговорите од новите верзии:

И преглед за воведување:

Прекрасно.

Чекор 3: 100% сообраќај:

Го поставивме така што по 2 минути чекорот од 50% завршува автоматски и чекорот 100% започнува:

И излезот од апликацијата:

И преглед за воведување:

Распоредувањето на канаринците е завршено.

Повеќе примери со Argo Rollouts

Овде има повеќе примери, како на пример како да поставите прегледи и споредби на животната средина врз основа на канари:

https://github.com/argoproj/argo-rollouts/tree/master/examples

Видео за Argo Rollouts и Argo CI

Навистина го препорачувам ова видео, покажува како Argo Rollouts и Argo CI работат заедно:

Вкупно

Навистина ми се допаѓа идејата за користење на CRD кои управуваат со создавање на дополнителни видови распоредувања или репликасети, пренасочување на сообраќајот итн. Работата со нив оди без проблеми. Следно, би сакал да ја тестирам интеграцијата со Argo CI.

Сепак, се чини дека доаѓа големо спојување на Argo CI и Flux CI, па можеби ќе почекам додека не излезе новото издание: Арго флукс.

Дали сте имале искуство со Argo Rollouts или Argo CI?

Прочитајте и други написи на нашиот блог:

Извор: www.habr.com

Распоредување на Canary во Kubernetes #2: Argo Rollouts