Распоредување на Canary во Kubernetes #1: Gitlab CI

Ќе користиме Gitlab CI и рачно GitOps за да го имплементираме и користиме распоредувањето на Canary во Kubernetes

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

• (Оваа статија)
• Распоредување на Канари со помош на ArgoCI
• Распоредување на Канари со користење на Истио
• Распоредување на Canary со помош на Jenkins-X Istio Flagger

Распоредувањето на Canary ќе го извршиме рачно преку GitOps и ќе ги креираме/изменуваме главните ресурси на Kubernetes. Оваа статија е наменета првенствено за вовед со тоа како функционира распоредувањето во Kubernetes Canary, бидејќи има поефикасни методи на автоматизација, кои ќе ги разгледаме во следните написи.

https://www.norberteder.com/canary-deployment/

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

Со стратегијата Канарски, ажурирањата прво се применуваат само на подгрупа корисници. Преку мониторинг, податоци за евиденција, рачно тестирање или други канали за повратни информации, изданието се тестира пред да биде објавено за сите корисници.

Распоредување на Kubernetes (продолжено ажурирање)

Стандардната стратегија за Kubernetes Deployment е ажурирање на тркалање, каде што се лансираат одреден број на места со нови верзии на сликите. Ако тие се создадени без проблеми, местата со стари верзии на слики се прекинуваат, а паралелно се создаваат нови подлоги.

GitOps

Ние користиме GitOps во овој пример затоа што:

• користејќи го Git како единствен извор на вистината
• ние користиме Git Operations за изградба и распоредување (не се потребни други команди освен git tag/merge)

Пример

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

Складиште за апликации

Ова е многу едноставно 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-docker

before_script:
   - printenv
   - kubectl version

stages:
 - deploy

deploy 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: app
 name: app
spec:
 ports:
 - port: 80
   protocol: TCP
   targetPort: 5000
 selector:
   id: app
 type: LoadBalancer

И распоредување во deploy.yaml:

apiVersion: apps/v1
kind: Deployment
metadata:
 name: app
spec:
 replicas: 10
 selector:
   matchLabels:
     id: app
     type: main
 template:
   metadata:
     labels:
       id: app
       type: main
   spec:
     containers:
     - image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v1
       name: app
       resources:
         limits:
           cpu: 100m
           memory: 100Mi

И уште едно распоредување во deploy-canary.yaml:

kind: Deployment
metadata:
 name: app-canary
spec:
 replicas: 0
 selector:
   matchLabels:
     id: app
     type: canary
 template:
   metadata:
     labels:
       id: app
       type: canary
   spec:
     containers:
     - image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v2
       name: app
       resources:
         limits:
           cpu: 100m
           memory: 100Mi

Имајте предвид дека распоредувањето на апликацијата сè уште нема дефинирани реплики.

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

За да го започнете првичното распоредување, можете рачно да го стартувате гасоводот GitlabCI на главната гранка. После тоа kubectl треба да го даде следново:

Ние гледаме app распоредување со 10 реплики и app-canary со 0. Има и LoadBalancer од кој можеме да пристапиме преку curl преку надворешна IP:

while true; do curl -s 35.198.149.232 | grep label; sleep 0.1; done

Гледаме дека нашата тест апликација враќа само „v1“.

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

Чекор 1: ослободете нова верзија за некои корисници

Го поставивме бројот на реплики на 1 во датотеката deploy-canary.yaml и сликата на новата верзија:

kind: Deployment
metadata:
 name: app-canary
spec:
 replicas: 1
 selector:
   matchLabels:
     id: app
     type: canary
 template:
   metadata:
     labels:
       id: app
       type: canary
   spec:
     containers:
     - image: registry.gitlab.com/wuestkamp/k8s-deployment-example-app:v2
       name: app
       resources:
         limits:
           cpu: 100m
           memory: 100Mi

Во датотека deploy.yaml го сменивме бројот на реплики на 9:

kind: Deployment
metadata:
 name: app
spec:
 replicas: 9
 selector:
   matchLabels:
     id: app
...

Ги туркаме овие промени во складиштето од кое ќе започне распоредувањето (преку GitlabCI) и го гледаме резултатот:

Нашата услуга ќе укаже на двете распоредувања, бидејќи и двете го имаат избирачот на апликации. Поради стандардната рандомизација на Кубернетес, треба да видиме различни одговори за ~ 10% од барањата:

Тековната состојба на нашата апликација (GitOps, преземена од Git како единствен извор на вистината) е присуството на две распоредувања со активни реплики, по една за секоја верзија.

~ 10% од корисниците се запознаваат со новата верзија и ненамерно ја тестираат. Сега е време да проверите дали има грешки во дневниците и податоците за следење за да најдете проблеми.

Чекор 2: Објавете ја новата верзија на сите корисници

Решивме дека сè помина добро и сега треба да ја претставиме новата верзија на сите корисници. За да го направите ова, ние едноставно ажурираме deploy.yaml инсталирање на нова верзија на сликата и бројот на реплики еднаков на 10. Во deploy-canary.yaml го поставивме бројот на реплики назад на 0. По распоредувањето, резултатот ќе биде како што следува:

Сумирајќи

За мене, рачно извршување на распоредувањето на овој начин помага да се разбере колку лесно може да се конфигурира со помош на k8s. Бидејќи Kubernetes ви дозволува да ажурирате сè преку API, овие чекори може да се автоматизираат преку скрипти.

Друга работа што треба да се имплементира е влезна точка на тестерот (LoadBalancer или преку Ingress) преку која може да се пристапи само до новата верзија. Може да се користи за рачно прелистување.

Во идните статии, ќе ги провериме другите автоматизирани решенија кои го спроведуваат најголемиот дел од она што сме го направиле.

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

• До што доведе миграцијата од ClickHouse без овластување во ClickHouse со овластување?
• Градење динамични модули за Nginx
• Ажурирајте ги nxs-build-tools - асистент во градењето на пакети deb и rpm
• Вовед во овластувањето Kubernetes на конзулот Hashicorp
• Со што моравме да се соочиме кога ја користевме алатката Csync2
• Телеграма бот за Redmine. Како да го поедноставите животот за себе и за другите

Извор: www.habr.com