Skip to content
GitLab
Next
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • GitLab GitLab
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 44,761
    • Issues 44,761
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
    • Requirements
  • Merge requests 1,332
    • Merge requests 1,332
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Container Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • GitLab.orgGitLab.org
  • GitLabGitLab
  • Issues
  • #215501
Closed
Open
Issue created Apr 23, 2020 by Orit Golowinski@ogolowinskiDeveloper0 of 1 checklist item completed0/1 checklist item

Add Support for Canary-Weight ingress annotation via API

We want to allow our users additional flexibility for configuring advanced deployments. Based on the output of #199043 (closed), we have decided to extend our NGINX ingress support by adding support for additional parameters

Problem to solve

This issue is a first iteration for implementing a load balancer in GitLab, the idea is to add an easy way to configure NGNIX annotations which are used to customize their behavior. Simply put - it allows you to customize your canary to anything you want to control. We decided to start with weights - which is an elegant way to achieve blue/green deployments.

Intended users

  • Sasha (Software Developer)
  • Devon (DevOps Engineer)

Further details

A typical scenario of the rule is based on weight, that is, blue-green deployment. You can set the weight from 0 to 100 to implement that kind of application release. At any time, only one of the environments is production. For this example, currently green is production and blue is canary. Initially, the weight of canary is set to 0 which means no traffic is forwarded to this release. You can introduce a small portion of traffic to blue version step by step, test and verify it. If everything is OK then you can shift all requests from green to blue by set the weight of blue to 100 which makes blue the production release. In a word, with such canary releasing process, the application is upgraded smoothly.

image

nginx.ingress.kubernetes.io/canary-weight: The integer based (0 - 100) percent of random requests that should be routed to the service specified in the canary Ingress. A weight of 0 implies that no requests will be sent to the service in the Canary ingress by this canary rule. A weight of 100 means implies all requests will be sent to the alternative service specified in the Ingress.

Proposal

Use the following annotation syntax: ingress.annotations Ingress annotations {kubernetes.io/tls-acme: "true", kubernetes.io/ingress.class: "nginx"}``

User will fill in an integer weight value of 0-100.

$ kubectl apply -f weighted-canary.ingress -n ingress-demo
ingress.extensions/canary created

4.1. Now create a canaryIngress. The following file uses canary-weightannotation to introduce 30%of all traffic to the canary version.

The yaml file is as follows.

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: canary
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "30"
spec:
  rules:
  - host: kubesphere.io
    http:
      paths:
      - backend:
          serviceName: canary
          servicePort: 80

Not in scope of this issue

Any UI representation of the current status, configuration or ability to switch deployments

Permissions and Security

Documentation

Availability & Testing

What does success look like, and how can we measure that?

What is the type of buyer?

Is this a cross-stage feature?

Links / references

  • https://kubesphere.io/docs/quick-start/ingress-canary/
  • https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#canary
  • https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/

TODO

  • Update https://docs.gitlab.com/ee/user/project/deploy_boards.html#enabling-deploy-boards
Edited Oct 13, 2020 by Shinya Maeda
Assignee
Assign to
Time tracking