Skip to content

Prepare our current Canary to support Canary-Weight ingress annotation

Problem to solve

Broken off of #215501 (closed)

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 to additional parameters

Intended users

User experience goal

Proposal

Iteration 1: Migrate to Ingress-level traffic routing and create Canary Ingress resource on canary deplyoment

  • This iteration is basically to change the current routing mode for Canary Ingress and fixing existing features if it's broken.
  • BE updates auto-deploy-app (kubernetes charts) to always create Canary Ingress resource.
    • Make sure that it doesn't break the existing workflow.
    • Compute weight by the number of pods.
    • Move onto Ingress-level traffic routing, and deprecate service-level traffic routing.
    • There is an on-going effort here gitlab-org/charts/auto-deploy-app!75 (diffs)
  • BE fixes deploy board to correctly show the status of pods.
  • Documentation
canary:
  script:
    # If canary deployment doesn't exist, it does
    # - create a service for canary deployment
    # - create a canary ingress and set a weight.
    # - update production-service to route to production-deployment only.
    # If canary deployment exists, it does legacy process.
    - auto-deploy deploy canary

production:
  script:
    - auto-deploy deploy
    - auto-deploy delete canary

Further details

Permissions and Security

Documentation

Availability & Testing

V0 resource architecture

graph TD;
subgraph gl-managed-app
Z[Nginx Ingress]
end
Z[Nginx Ingress] --> A(Ingress);
Z[Nginx Ingress] --> B(Ingress);
subgraph stg namespace
B[Ingress] --> H(...);
end
subgraph prd namespace
A[Ingress] --> D(Service);
D[Service] --> E(Deployment:Pods:app:stable);
D[Service] --> F(Deployment:Pods:app:canary);
D[Service] --> I(Deployment:Pods:app:rollout);
E(Deployment:Pods:app:stable)---id1[(Pods:Postgres)]
F(Deployment:Pods:app:canary)---id1[(Pods:Postgres)]
I(Deployment:Pods:app:rollout)---id1[(Pods:Postgres)]
end

Proposal: V1 resource architecture

graph TD;
subgraph gl-managed-app
Z[Nginx Ingress]
end
Z[Nginx Ingress] --> A(Ingress);
Z[Nginx Ingress] --> B(Ingress);
subgraph stg namespace
B[Ingress] --> H(...);
end
subgraph prd namespace
A[Ingress] --> J(Canary Ingress);
J(Canary Ingress) --> X{should route to canary?}
X{should route to canary?} --> |No| D(Service);
X{should route to canary?} --> |Yes| K(Service);
subgraph stable track
D[Service] --> E(Deployment:Pods:app:stable);
end
subgraph canary track
K[Service] --> F(Deployment:Pods:app:canary);
end
E(Deployment:Pods:app:stable)---id1[(Pods:Postgres)]
F(Deployment:Pods:app:canary)---id1[(Pods:Postgres)]
end

NOTES:

  • rollout track is removed. Instead, we change the scale by the canary weight.

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

Edited by Shinya Maeda