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