Канареечный деплой — это очень эффективный способ тестирования нового кода на каком-то подмножестве пользователей. Он значительно снижает трафик-нагрузку, с которой могут возникнуть проблемы в процессе развертывания, так как происходит только в пределах определенной подгруппы. Эта заметка посвящена тому, как организовать подобный деплой средствами Kubernetes и автоматизации деплоя. Предполагается, что вы кое-что знаете о Helm и ресурсах Kubernetes.
Простой канареечный деплой в Kubernetes включает в себя два ключевых ресурса: сам сервис и инструмент развертывания. Канареечный деплой работает через одну службу, которая взаимодействует с двумя разными ресурсами, обслуживающими трафик обновления. Один из этих ресурсов будет работать с «канареечной» версией, а второй — со стабильной. В этой ситуации мы можем регулировать количество канареечных версий для того, чтобы снизить объем необходимого к обслуживанию трафика. Если, к примеру, вы предпочитаете использовать Yaml, то выглядеть в Kubernetes это будет следующим образом:
kind: Deployment
metadata:
name: app-canary
labels:
app: app
spec:
replicas: 1
...
image: myapp:canary
---
kind: Deployment
metadata:
name: app
labels:
app: app
spec:
replicas: 5
...
image: myapp:stable
---
kind: Service
selector:
app: app # Selector will route traffic to both deployments.
~/charts/app
+-- Chart.yaml
+-- README.md
+-- templates
¦ +-- NOTES.txt
¦ +-- _helpers.tpl
¦ +-- deployment.yaml
¦ L-- service.yaml
L-- values.yaml
selector:
app.kubernetes.io/name: myapp
helm upgrade
--install myapp --namespace default --set app.name=myapp \ # Goes into app.kubernetes.io/name
--set app.version=v1 \ # Goes into app.kubernetes.io/version
--set image.tag=stable --set replicaCount=5
helm upgrade
--install myapp-canary --namespace default --set app.name=myapp \ # Goes into app.kubernetes.io/name
--set app.version=v2 \ # Goes into app.kubernetes.io/version
--set image.tag=canary --set replicaCount=1
К сожалению, не доступен сервер mySQL