Внедряване на Canary в Kubernetes #1: Gitlab CI

Ще използваме Gitlab CI и ръчни GitOps за внедряване и използване на внедряване на Canary в Kubernetes

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

• (Тази статия)
• Внедряване на Canary с помощта на ArgoCI
• Внедряване на Canary с помощта на Istio
• Внедряване на Canary с помощта на Jenkins-X Istio Flagger

Ние ще извършим внедряването на Canary ръчно чрез GitOps и създаване/модифициране на основните ресурси на Kubernetes. Тази статия е предназначена предимно за въведение с това как работи внедряването в Kubernetes Canary, тъй като има по-ефективни методи за автоматизация, които ще разгледаме в следващите статии.

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

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

Със стратегията Canary актуализациите първо се прилагат само към подгрупа потребители. Чрез наблюдение, регистрационни данни, ръчно тестване или други канали за обратна връзка, изданието се тества, преди да бъде пуснато за всички потребители.

Внедряване на Kubernetes (текуща актуализация)

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

gitops

Използваме GitOps в този пример, защото:

• използване на Git като единствен източник на истина
• използваме Git Operations за изграждане и внедряване (не са необходими команди, различни от git tag/merge)

Пример

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

Хранилище на приложения

Това е много прост 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-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) тук.

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

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

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

Имайте предвид, че app-deploy все още няма дефинирани реплики.

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

За да започнете първоначалното внедряване, можете да стартирате тръбопровода на 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“.

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

Стъпка 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) и виждаме като резултат:

Нашата услуга ще посочи и двете внедрявания, тъй като и двете имат селектор на приложения. Поради рандомизацията по подразбиране на Kubernetes, трябва да видим различни отговори за ~10% от заявките:

Текущото състояние на нашето приложение (GitOps, взето от Git като единствен източник на истина) е наличието на две внедрявания с активни реплики, по една за всяка версия.

~10% от потребителите се запознават с нова версия и неволно я тестват. Сега е моментът да проверите за грешки в регистрационните файлове и данните за наблюдение, за да откриете проблеми.

Стъпка 2: Пуснете новата версия за всички потребители

Решихме, че всичко е минало добре и сега трябва да пуснем новата версия на всички потребители. За да направим това, ние просто актуализираме deploy.yaml инсталиране на нова версия на изображението и брой реплики, равен на 10. In deploy-canary.yaml задаваме броя на репликите обратно на 0. След разполагането резултатът ще бъде както следва:

Резюмиране

За мен ръчното изпълнение на внедряването по този начин помага да разбера колко лесно може да се конфигурира с помощта на k8s. Тъй като Kubernetes ви позволява да актуализирате всичко чрез API, тези стъпки могат да бъдат автоматизирани чрез скриптове.

Друго нещо, което трябва да се внедри е входна точка на тестер (LoadBalancer или чрез Ingress), през която може да се достъпва само новата версия. Може да се използва за ръчно сърфиране.

В бъдещи статии ще разгледаме други автоматизирани решения, които прилагат повечето от това, което сме направили.

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

• До какво доведе миграцията от ClickHouse без авторизация към ClickHouse с авторизация?
• Изграждане на динамични модули за Nginx
• Актуализирайте nxs-build-tools - помощник при изграждането на deb и rpm пакети
• Въведение в разрешението за Kubernetes на Hashicorp Consul
• С какво трябваше да се сблъскаме, когато използвахме помощната програма Csync2
• Telegram бот за Redmine. Как да направим живота по-лесен за себе си и другите

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