Оффлайн
- Регистрация
- 21.07.20
- Сообщения
- 40.408
- Реакции
- 1
- Репутация
- 0
Мы будем использовать Gitlab CI и ручной GitOps для внедрения и использования Canary-деплоя в Kubernetes
Статьи из этого цикла:
Выполнять Canary-деплой мы будем руками через GitOps и создание/изменение основных ресурсов Kubernetes. Эта статья предназначена в первую очередь для знакомства с тем, как работает в Kubernetes Canary деплой, так как есть более эффективные способы автоматизации, которые мы рассмотрим в следующих статьях.
Canary Deployment
При Canary-стратегии обновления сначала применяются только для части пользователей. Через мониторинг, данные с логов, ручное тестирование или другие каналы обратной связи релиз тестируется перед его применением для всех пользователей.
Kubernetes Deployment (rolling update)
Стратегия по умолчанию для Kubernetes Deployment — это rolling-update, где запускается определенное количество подов с новыми версиями образов. Если они создались без проблем, поды со старыми версиями образов завершаются, а новые поды создаются параллельно.
GitOps
Мы используем GitOps в этом примере, так как мы:
Пример
Возьмем хорошую практику — иметь один репозиторий для кода приложений и один для инфраструктуры.
Репозиторий для приложений
Это очень простая API на Python+Flask, возвращающая ответ в виде JSON. Мы соберем пакет через GitlabCI и запушим результат в Gitlab Registry. В регистри у нас есть две разные версии релизов:
Единственная разница между ними это изменение возвращаемого 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
Вам нужно сделать форк
О том, как получить учетные данные для кластера (Gcloud) можно почитать
Инфраструктурный Yaml
В инфраструктурном репозитории у нас есть service:
apiVersion: v1
kind: Service
metadata:
labels:
id: app
name: app
spec:
ports:
- port: 80
protocol: TCP
targetPort: 5000
selector:
id: app
type: LoadBalancer
И deployment в 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
И другой deployment в 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 пока не имеет определенных реплик.
Выполнение начального деплоя
Для запуска начального deployment вы можете запустить пайплайн GitlabCI вручную в мастер-ветке. После этого kubectl дожен вывести следующее:
Мы видим app deployment c 10 репликами и app-canary с 0. Так же есть LoadBalancer с которого мы можем обращаться через curl по External 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) и видим в итоге:
Наш Service будет указывать на оба деплоя, так как у обоих есть селектор app. Из-за случайного распределения по умолчанию в Kubernetes мы должны увидеть разные ответы на ~ 10% запросов:
Текущее состояние нашего приложения (GitOps, взятый с Git как с Single Source Of Truth) это наличие двух deployments c активными репликами, по одному для каждой версии.
~10% пользователей знакомятся с новой версией и ненамеренно тестируют ее. Теперь настало время проверить наличие ошибок в логах и данных мониторинга для поиска проблем.
Шаг 2: выпустить новую версию для всех пользователей
Мы решили, что все прошло хорошо и теперь нам нужно развернуть новую версию на всех пользователей. Для этого мы просто обновляем deploy.yaml устанавливая новую версию образа и количество реплик, равное 10. В deploy-canary.yaml мы устанавливаем количество реплик равное обратно 0. После деплоя результат будет следующим:
Подводя итог
Для меня запуск деплоя вручную таким образом помогает понять как легко он может быть настроен при помощи k8s. Так как Kubernetes позволяет обновлять все через API, эти шаги можно автоматизировать через скрипты.
Еще одна вещь, которую нужно реализовать — это точка входа тестировщика (LoadBalancer или через Ingress), через которую можно получить доступ только к новой версии. Она может быть использована для просмотра вручную.
В следующих статьях мы проверим другие автоматизированные решения, которые реализуют большинство из того, что мы сделали.
Статьи из этого цикла:
- (эта статья)
- Canary Deployment при помощи ArgoCI
- Canary Deployment при помощи Istio
- Canary Deployment при помощи Jenkins-X Istio Flagger
Выполнять Canary-деплой мы будем руками через GitOps и создание/изменение основных ресурсов Kubernetes. Эта статья предназначена в первую очередь для знакомства с тем, как работает в Kubernetes Canary деплой, так как есть более эффективные способы автоматизации, которые мы рассмотрим в следующих статьях.
You must be registered for see links
Canary Deployment
При Canary-стратегии обновления сначала применяются только для части пользователей. Через мониторинг, данные с логов, ручное тестирование или другие каналы обратной связи релиз тестируется перед его применением для всех пользователей.
Kubernetes Deployment (rolling update)
Стратегия по умолчанию для Kubernetes Deployment — это rolling-update, где запускается определенное количество подов с новыми версиями образов. Если они создались без проблем, поды со старыми версиями образов завершаются, а новые поды создаются параллельно.
GitOps
Мы используем GitOps в этом примере, так как мы:
- используем Git как единый источник истины
- используем Git Operations для сборки и деплоя (никаких команд, кроме git tag/merge не нужно)
Пример
Возьмем хорошую практику — иметь один репозиторий для кода приложений и один для инфраструктуры.
Репозиторий для приложений
Это очень простая API на Python+Flask, возвращающая ответ в виде JSON. Мы соберем пакет через GitlabCI и запушим результат в Gitlab Registry. В регистри у нас есть две разные версии релизов:
- 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
Вам нужно сделать форк
You must be registered for see links
и создать переменную KUBECONFIG в GitlabCI, которая будет содержать конфиг для доступа kubectl к вашему кластеру.О том, как получить учетные данные для кластера (Gcloud) можно почитать
You must be registered for see links
.Инфраструктурный Yaml
В инфраструктурном репозитории у нас есть service:
apiVersion: v1
kind: Service
metadata:
labels:
id: app
name: app
spec:
ports:
- port: 80
protocol: TCP
targetPort: 5000
selector:
id: app
type: LoadBalancer
И deployment в 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
И другой deployment в 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 пока не имеет определенных реплик.
Выполнение начального деплоя
Для запуска начального deployment вы можете запустить пайплайн GitlabCI вручную в мастер-ветке. После этого kubectl дожен вывести следующее:
Мы видим app deployment c 10 репликами и app-canary с 0. Так же есть LoadBalancer с которого мы можем обращаться через curl по External 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) и видим в итоге:
Наш Service будет указывать на оба деплоя, так как у обоих есть селектор app. Из-за случайного распределения по умолчанию в Kubernetes мы должны увидеть разные ответы на ~ 10% запросов:
Текущее состояние нашего приложения (GitOps, взятый с Git как с Single Source Of Truth) это наличие двух deployments c активными репликами, по одному для каждой версии.
~10% пользователей знакомятся с новой версией и ненамеренно тестируют ее. Теперь настало время проверить наличие ошибок в логах и данных мониторинга для поиска проблем.
Шаг 2: выпустить новую версию для всех пользователей
Мы решили, что все прошло хорошо и теперь нам нужно развернуть новую версию на всех пользователей. Для этого мы просто обновляем deploy.yaml устанавливая новую версию образа и количество реплик, равное 10. В deploy-canary.yaml мы устанавливаем количество реплик равное обратно 0. После деплоя результат будет следующим:
Подводя итог
Для меня запуск деплоя вручную таким образом помогает понять как легко он может быть настроен при помощи k8s. Так как Kubernetes позволяет обновлять все через API, эти шаги можно автоматизировать через скрипты.
Еще одна вещь, которую нужно реализовать — это точка входа тестировщика (LoadBalancer или через Ingress), через которую можно получить доступ только к новой версии. Она может быть использована для просмотра вручную.
В следующих статьях мы проверим другие автоматизированные решения, которые реализуют большинство из того, что мы сделали.