Внедряване на Canary в Kubernetes #2: Внедряване на Argo

Ще използваме родния за k8s контролер за внедряване на Argo Rollouts и GitlabCI, за да изпълняваме внедрявания на Canary в Kubernetes

https://unsplash.com/photos/V41PulGL1z0

Статии от тази серия

• Внедряване на Canary в Kubernetes #1: Gitlab CI
• (Тази статия)
• Внедряване на Canary с помощта на Istio
• Внедряване на Canary с помощта на Jenkins-X Istio Flagger

Разгръщане на Canary

Надяваме се да прочетете първа част, където накратко обяснихме какво представляват Canary Deployments. Ние също така показахме как да го внедрим с помощта на стандартни ресурси на Kubernetes.

Argo Rollouts

Argo Rollouts е собствен контролер за внедряване на Kubernetes. Той предоставя CRD (дефиниране на потребителски ресурс) за Kubernetes. Благодарение на него можем да използваме нов обект: Rollout, който управлява синьо-зелени и канарски внедрявания с различни опции за конфигурация.

Контролерът Argo Rollouts, използван от персонализиран ресурс Rollout, Позволява допълнителни стратегии за внедряване като синьо-зелено и канарче за Kubernetes. Ресурс 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 ще го инсталира в клъстера.

Клиентска страна (кубектл плъгин)

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

Примерно приложение

Добра практика е да имате отделни хранилища за код на приложение и инфраструктура.

Хранилище за приложението

Kim Wuestkamp/k8s-deployment-example-app

Това е много прост API на Python+Flask, който връща отговор като 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).

Инфраструктура Yaml

Вътре в инфраструктурното хранилище имаме услуга:

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 работи по същия начин като Разгръщане. Ако не зададем стратегия за актуализиране (като канарче тук), тя ще се държи като внедряване на текуща актуализация по подразбиране.

Ние дефинираме две стъпки в yaml за внедряване на canary:

1. 10% от трафика към canary (изчакайте ръчно OK)
2. 50% трафик до Canary (изчакайте 2 минути, след което продължете до 100%)

Извършване на първоначално внедряване

След първоначалното внедряване нашите ресурси ще изглеждат така:

И получаваме отговор само от първата версия на приложението:

Извършване на внедряване на Canary

Стъпка 1: 10% трафик

За да започнем внедряването на canary, просто трябва да променим версията на изображението, както обикновено правим с внедряването:

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% да започне:

И резултатът от приложението:

И преглед на разпространението:

Разгръщането на Canary е завършено.

Още примери с Argo Rollouts

Тук има още примери, като например как да настроите визуализации на среда и сравнения въз основа на canary:

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?

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

• Синьо-зелено внедряване на Spring приложения с уеб сървър Nginx
• Kubernetes: защо е толкова важно да настроите управление на системните ресурси?
• Въведение в разрешението за Kubernetes на Hashicorp Consul
• Tekton Pipeline - собствени тръбопроводи на Kubernetes
• Изграждане на динамични модули за Nginx
• Telegram бот за Redmine. Как да направим живота по-лесен за себе си и другите

Източник: www.habr.com