Допустим у нас в качестве ingress controller используется nginx. В таком случае можно легко и просто реализовать "канарейку" для проверки нового кода.
Суть реализации - у нас есть на проде стабильно работающее приложение и есть ветка в которой добавляется новый функционал, который требует проверки на проде, но не сразу, а постепенно, например мы хотим 10% трафика пустить на новый код, остальное оставить на старом. Для этого нужно разрешить тем или иным способом, в зависимости от реализации CI/CD деплой новой ветки на прод. Обычно хорошо использовать завязку именования kubernetes объектов по переменной CI_COMMIT_REF_SLUG в gilab-ci, таким образом и если мы используем helm, это создаст новый набор кубовых сущностей с другим именем.
Далее просто выставляем в канареечном ingress нужные аннотации и делаем host равный host основного ingress.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: canary
annotations:
nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-weight: "10"
spec:
ingressClassName: nginx
rules:
- host: example.ingress.host
http:
paths:
- pathType: Prefix
path: /
backend:
service:
name: canary
port:
number: 80
canary-weight - это процент трафика, который будет идти на данный релиз.
host - должен быть точно такой же, как у основного ingress.
Из практических наблюдений. Бывает такое, что используется набор из нескольких ingress у приложения. Например ingress-int для открытия каких-то внутренних роутов и ingress-ext - внешний, куда проксирует запросы к примеру nginx, обслуживающий внешние домены. Так вот, если оба этих ingress используют один и тот же backend (k8s service), то канарейка работать не будет. В данном случае нужно обязательно пускать каждый ingress через свой backend.
#kubernetes