Skip to content

Commit 3c1038b

Browse files
GallardotGallardot
authored
feat: Apache APISIX support. Fixes argoproj#2395 (argoproj#2437)
* feat: Apache APISIX support Signed-off-by: Gallardot <[email protected]> * feat: Apache APISIX support Signed-off-by: Gallardot <[email protected]> * feat: Improve the apisix route Signed-off-by: Gallardot <[email protected]> * chore: add apisix doc and examples Signed-off-by: Gallardot <[email protected]> * chore: add apisix doc and examples Signed-off-by: Gallardot <[email protected]> * chore: add UT Signed-off-by: Gallardot <[email protected]> * doc: update README Signed-off-by: Gallardot <[email protected]> Signed-off-by: Gallardot <[email protected]>
1 parent b4c1d9e commit 3c1038b

File tree

32 files changed

+3298
-597
lines changed

32 files changed

+3298
-597
lines changed

‎.gitignore

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -9,6 +9,8 @@ cmd/**/debug
99
debug.test
1010
coverage.out
1111
coverage.html
12+
junit.xml
13+
rerunreport.txt
1214
site/
1315
vendor/
1416
# generated

‎README.md

Lines changed: 19 additions & 14 deletions
Original file line numberDiff line numberDiff line change
@@ -1,28 +1,32 @@
11

22
# Argo Rollouts - Progressive Delivery for Kubernetes
3+
34
[![codecov](https://codecov.io/gh/argoproj/argo-rollouts/branch/master/graph/badge.svg)](https://codecov.io/gh/argoproj/argo-rollouts)
45
[![slack](https://img.shields.io/badge/slack-argoproj-brightgreen.svg?logo=slack)](https://argoproj.github.io/community/join-slack)
56
[![CII Best Practices](https://bestpractices.coreinfrastructure.org/projects/3834/badge)](https://bestpractices.coreinfrastructure.org/projects/3834)
67
[![Artifact HUB](https://img.shields.io/endpoint?url=https://artifacthub.io/badge/repository/argo-rollouts)](https://artifacthub.io/packages/helm/argo/argo-rollouts)
78

89
## What is Argo Rollouts?
9-
Argo Rollouts is a Kubernetes controller and set of CRDs which provide advanced deployment capabilities such as blue-green, canary, canary analysis, experimentation, and progressive delivery features to Kubernetes.
10+
11+
Argo Rollouts is a Kubernetes controller and set of CRDs which provide advanced deployment capabilities such as blue-green, canary, canary analysis, experimentation, and progressive delivery features to Kubernetes.
1012

1113
Argo Rollouts (optionally) integrates with ingress controllers and service meshes, leveraging their traffic shaping abilities to gradually shift traffic to the new version during an update. Additionally, Rollouts can query and interpret metrics from various providers to verify key KPIs and drive automated promotion or rollback during an update.
1214

1315
[![Argo Rollotus Demo](https://img.youtube.com/vi/hIL0E2gLkf8/0.jpg)](https://youtu.be/hIL0E2gLkf8)
1416

1517
## Quick Start
1618

17-
```
19+
```bash
1820
kubectl create namespace argo-rollouts
1921
kubectl apply -n argo-rollouts -f https://github.com/argoproj/argo-rollouts/releases/latest/download/install.yaml
2022
```
2123

22-
Follow the full [getting started guide](docs/getting-started.md) to walk through creating and then updating a rollout object.
24+
Follow the full [getting started guide](docs/getting-started.md) to walk through creating and then updating a rollout object.
2325

2426
## Why Argo Rollouts?
27+
2528
Kubernetes Deployments provides the `RollingUpdate` strategy which provide a basic set of safety guarantees (readiness probes) during an update. However the rolling update strategy faces many limitations:
29+
2630
* Few controls over the speed of the rollout
2731
* Inability to control traffic flow to the new version
2832
* Readiness probes are unsuitable for deeper, stress, or one-time checks
@@ -32,6 +36,7 @@ Kubernetes Deployments provides the `RollingUpdate` strategy which provide a bas
3236
For these reasons, in large scale high-volume production environments, a rolling update is often considered too risky of an update procedure since it provides no control over the blast radius, may rollout too aggressively, and provides no automated rollback upon failures.
3337

3438
## Features
39+
3540
* Blue-Green update strategy
3641
* Canary update strategy
3742
* Fine-grained, weighted traffic shifting
@@ -43,23 +48,25 @@ For these reasons, in large scale high-volume production environments, a rolling
4348
* Metric provider integration: Prometheus, Wavefront, Kayenta, Web, Kubernetes Jobs, Datadog, New Relic, InfluxDB
4449

4550
## Supported Traffic Shaping Integrations
46-
| Traffic Shaping Integration | SetWeight | SetWeightExperiments | SetMirror | SetHeader |
47-
|------------------------------|------------------------------|-----------------------------|----------------------------|----------------------------|
48-
| ALB Ingress Controller | :white_check_mark: (stable) | :white_check_mark: (stable) | :x: | :white_check_mark: (alpha) |
49-
| Ambassador | :white_check_mark: (stable) | :x: | :x: | :x: |
50-
| Istio | :white_check_mark: (stable) | :white_check_mark: (stable) | :white_check_mark: (alpha) | :white_check_mark: (alpha) |
51-
| Nginx Ingress Controller | :white_check_mark: (stable) | :x: | :x: | :x: |
52-
| SMI | :white_check_mark: (stable) | :white_check_mark: (stable) | :x: | :x: |
53-
| Traefik | :white_check_mark: (beta) | :x: | :x: | :x: |
51+
| Traffic Shaping Integration | SetWeight | SetWeightExperiments | SetMirror | SetHeader |
52+
|-----------------------------------|------------------------------|-----------------------------|----------------------------|----------------------------|
53+
| ALB Ingress Controller | :white_check_mark: (stable) | :white_check_mark: (stable) | :x: | :white_check_mark: (alpha) |
54+
| Ambassador | :white_check_mark: (stable) | :x: | :x: | :x: |
55+
| Apache APISIX Ingress Controller | :white_check_mark: (alpha) | :x: | :x: | :x: |
56+
| Istio | :white_check_mark: (stable) | :white_check_mark: (stable) | :white_check_mark: (alpha) | :white_check_mark: (alpha) |
57+
| Nginx Ingress Controller | :white_check_mark: (stable) | :x: | :x: | :x: |
58+
| SMI | :white_check_mark: (stable) | :white_check_mark: (stable) | :x: | :x: |
59+
| Traefik | :white_check_mark: (beta) | :x: | :x: | :x: |
5460

5561
:white_check_mark: = Supported
5662

5763
:x: = Not Supported
5864

5965
## Documentation
66+
6067
To learn more about Argo Rollouts go to the [complete documentation](https://argoproj.github.io/argo-rollouts/).
6168

62-
## Community
69+
## Community
6370

6471
You can reach the Argo Rollouts community and developers via the following channels:
6572

@@ -89,5 +96,3 @@ You can reach the Argo Rollouts community and developers via the following chann
8996
* [How Scalable is Argo-Rollouts: A Cloud Operator’s Perspective](https://www.youtube.com/watch?v=rCEhxJ2NSTI)
9097
* [Minimize Impact in Kubernetes Using Argo Rollouts](https://medium.com/@arielsimhon/minimize-impact-in-kubernetes-using-argo-rollouts-992fb9519969)
9198
* [Progressive Application Delivery with GitOps on Red Hat OpenShift](https://www.youtube.com/watch?v=DfeL7cdTx4c)
92-
93-

‎docs/features/traffic-management/apisix.md

Lines changed: 186 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,186 @@
1+
# Apache APISIX
2+
3+
You can use the [Apache APISIX](https://apisix.apache.org/) and [Apache APISIX Ingress Controller](https://apisix.apache.org/docs/ingress-controller/getting-started/) for traffic management with Argo Rollouts.
4+
5+
The [ApisixRoute](https://apisix.apache.org/docs/ingress-controller/concepts/apisix_route/) is the object that supports the ability for [weighted round robin load balancing](https://apisix.apache.org/docs/ingress-controller/concepts/apisix_route/#weight-based-traffic-split) when using Apache APISIX Ingress Controller as ingress.
6+
7+
This guide shows you how to integrate ApisixRoute with Argo Rollouts using it as weighted round robin load balancer
8+
9+
## Prerequisites
10+
11+
Argo Rollouts requires Apache APISIX v2.15 or newer and Apache APISIX Ingress Controller v1.5.0 or newer.
12+
13+
Install Apache APISIX and Apache APISIX Ingress Controller with Helm v3:
14+
15+
```bash
16+
helm repo add apisix https://charts.apiseven.com
17+
kubectl create ns apisix
18+
19+
helm upgrade -i apisix apisix/apisix --version=0.11.3 \
20+
--namespace apisix \
21+
--set ingress-controller.enabled=true \
22+
--set ingress-controller.config.apisix.serviceNamespace=apisix
23+
```
24+
25+
## Bootstrap
26+
27+
First, we need to create the ApisixRoute object using its ability for weighted round robin load balancing.
28+
29+
```yaml
30+
apiVersion: apisix.apache.org/v2
31+
kind: ApisixRoute
32+
metadata:
33+
name: rollouts-apisix-route
34+
spec:
35+
http:
36+
- name: rollouts-apisix
37+
match:
38+
paths:
39+
- /*
40+
hosts:
41+
- rollouts-demo.apisix.local
42+
backends:
43+
- serviceName: rollout-apisix-canary-stable
44+
servicePort: 80
45+
- serviceName: rollout-apisix-canary-canary
46+
servicePort: 80
47+
```
48+
49+
```bash
50+
kubectl apply -f https://raw.githubusercontent.com/argoproj/argo-rollouts/master/examples/apisix/route.yaml
51+
```
52+
53+
Notice, we don't specify the `weight` field. It is necessary to be synced with ArgoCD. If we specify this field and Argo Rollouts controller changes it, then the ArgoCD controller will notice it and will show that this resource is out of sync (if you are using Argo CD to manage your Rollout).
54+
55+
Secondly, we need to create the Argo Rollouts object.
56+
57+
```yaml
58+
apiVersion: argoproj.io/v1alpha1
59+
kind: Rollout
60+
metadata:
61+
name: rollout-apisix-canary
62+
spec:
63+
replicas: 5
64+
strategy:
65+
canary:
66+
canaryService: rollout-apisix-canary-canary
67+
stableService: rollout-apisix-canary-stable
68+
trafficRouting:
69+
apisix:
70+
route:
71+
name: rollouts-apisix-route
72+
rules:
73+
- rollouts-apisix
74+
steps:
75+
- setWeight: 20
76+
- pause: {}
77+
- setWeight: 40
78+
- pause:
79+
duration: 15
80+
- setWeight: 60
81+
- pause:
82+
duration: 15
83+
- setWeight: 80
84+
- pause:
85+
duration: 15
86+
revisionHistoryLimit: 2
87+
selector:
88+
matchLabels:
89+
app: rollout-apisix-canary
90+
template:
91+
metadata:
92+
labels:
93+
app: rollout-apisix-canary
94+
spec:
95+
containers:
96+
- name: rollout-apisix-canary
97+
image: argoproj/rollouts-demo:blue
98+
ports:
99+
- name: http
100+
containerPort: 8080
101+
protocol: TCP
102+
resources:
103+
requests:
104+
memory: 32Mi
105+
cpu: 5m
106+
```
107+
108+
```bash
109+
kubectl apply -f https://raw.githubusercontent.com/argoproj/argo-rollouts/master/examples/apisix/rollout.yaml
110+
```
111+
112+
Finally, we need to create the services for the Argo Rollouts object.
113+
114+
```yaml
115+
apiVersion: v1
116+
kind: Service
117+
metadata:
118+
name: rollout-apisix-canary-canary
119+
spec:
120+
ports:
121+
- port: 80
122+
targetPort: http
123+
protocol: TCP
124+
name: http
125+
selector:
126+
app: rollout-apisix-canary
127+
# This selector will be updated with the pod-template-hash of the canary ReplicaSet. e.g.:
128+
# rollouts-pod-template-hash: 7bf84f9696
129+
---
130+
apiVersion: v1
131+
kind: Service
132+
metadata:
133+
name: rollout-apisix-canary-stable
134+
spec:
135+
ports:
136+
- port: 80
137+
targetPort: http
138+
protocol: TCP
139+
name: http
140+
selector:
141+
app: rollout-apisix-canary
142+
# This selector will be updated with the pod-template-hash of the stable ReplicaSet. e.g.:
143+
# rollouts-pod-template-hash: 789746c88d
144+
```
145+
146+
```bash
147+
kubectl apply -f https://raw.githubusercontent.com/argoproj/argo-rollouts/master/examples/apisix/services.yaml
148+
```
149+
150+
Initial creations of any Rollout will immediately scale up the replicas to 100% (skipping any canary upgrade steps, analysis, etc...) since there was no upgrade that occurred.
151+
152+
The Argo Rollouts kubectl plugin allows you to visualize the Rollout, its related resources (ReplicaSets, Pods, AnalysisRuns), and presents live state changes as they occur. To watch the rollout as it deploys, run the get rollout --watch command from plugin:
153+
154+
```bash
155+
kubectl argo rollouts get rollout rollout-apisix-canary --watch
156+
```
157+
158+
## Updating a Rollout
159+
160+
Next it is time to perform an update. Just as with Deployments, any change to the Pod template field (`spec.template`) results in a new version (i.e. ReplicaSet) to be deployed. Updating a Rollout involves modifying the rollout spec, typically changing the container image field with a new version, and then running `kubectl apply` against the new manifest. As a convenience, the rollouts plugin provides a `set image` command, which performs these steps against the live rollout object in-place. Run the following command to update the `rollout-apisix-canary` Rollout with the "yellow" version of the container:
161+
162+
```shell
163+
kubectl argo rollouts set image rollout-apisix-canary \
164+
rollout-apisix-canary=argoproj/rollouts-demo:yellow
165+
```
166+
167+
During a rollout update, the controller will progress through the steps defined in the Rollout's update strategy. The example rollout sets a 20% traffic weight to the canary, and pauses the rollout indefinitely until user action is taken to unpause/promote the rollout.
168+
169+
You can check ApisixRoute's backend weights by the following command
170+
```bash
171+
kubectl describe apisixroute rollouts-apisix-route
172+
173+
......
174+
Spec:
175+
Http:
176+
Backends:
177+
Service Name: rollout-apisix-canary-stable
178+
Service Port: 80
179+
Weight: 80
180+
Service Name: rollout-apisix-canary-canary
181+
Service Port: 80
182+
Weight: 20
183+
......
184+
```
185+
186+
The `rollout-apisix-canary-canary` service gets 20% traffic through the Apache APISIX.

‎docs/features/traffic-management/index.md

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -20,6 +20,7 @@ Argo Rollouts enables traffic management by manipulating the Service Mesh resour
2020

2121
- [AWS ALB Ingress Controller](alb.md)
2222
- [Ambassador Edge Stack](ambassador.md)
23+
- [Apache APISIX](apisix.md)
2324
- [Istio](istio.md)
2425
- [Nginx Ingress Controller](nginx.md)
2526
- [Service Mesh Interface (SMI)](smi.md)

‎examples/apisix/rollout.yaml

Lines changed: 48 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,48 @@
1+
apiVersion: argoproj.io/v1alpha1
2+
kind: Rollout
3+
metadata:
4+
name: rollout-apisix-canary
5+
spec:
6+
replicas: 5
7+
strategy:
8+
canary:
9+
canaryService: rollout-apisix-canary-canary
10+
stableService: rollout-apisix-canary-stable
11+
trafficRouting:
12+
apisix:
13+
route:
14+
name: rollouts-apisix-route
15+
rules:
16+
- rollouts-apisix
17+
steps:
18+
- setWeight: 20
19+
- pause: { }
20+
- setWeight: 40
21+
- pause:
22+
duration: 15
23+
- setWeight: 60
24+
- pause:
25+
duration: 15
26+
- setWeight: 80
27+
- pause:
28+
duration: 15
29+
revisionHistoryLimit: 2
30+
selector:
31+
matchLabels:
32+
app: rollout-apisix-canary
33+
template:
34+
metadata:
35+
labels:
36+
app: rollout-apisix-canary
37+
spec:
38+
containers:
39+
- name: rollouts-demo
40+
image: argoproj/rollouts-demo:blue
41+
ports:
42+
- name: http
43+
containerPort: 8080
44+
protocol: TCP
45+
resources:
46+
requests:
47+
memory: 32Mi
48+
cpu: 5m

‎examples/apisix/route.yaml

Lines changed: 23 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,23 @@
1+
apiVersion: apisix.apache.org/v2
2+
kind: ApisixRoute
3+
metadata:
4+
name: rollouts-apisix-route
5+
spec:
6+
http:
7+
- name: rollouts-apisix
8+
match:
9+
paths:
10+
- /*
11+
methods:
12+
- GET
13+
- POST
14+
- PUT
15+
- DELETE
16+
- PATCH
17+
hosts:
18+
- rollouts-demo.apisix.local
19+
backends:
20+
- serviceName: rollout-apisix-canary-stable
21+
servicePort: 80
22+
- serviceName: rollout-apisix-canary-canary
23+
servicePort: 80

‎examples/apisix/services.yaml

Lines changed: 29 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,29 @@
1+
apiVersion: v1
2+
kind: Service
3+
metadata:
4+
name: rollout-apisix-canary-canary
5+
spec:
6+
ports:
7+
- port: 80
8+
targetPort: http
9+
protocol: TCP
10+
name: http
11+
selector:
12+
app: rollout-apisix-canary
13+
# This selector will be updated with the pod-template-hash of the canary ReplicaSet. e.g.:
14+
# rollouts-pod-template-hash: 7bf84f9696
15+
---
16+
apiVersion: v1
17+
kind: Service
18+
metadata:
19+
name: rollout-apisix-canary-stable
20+
spec:
21+
ports:
22+
- port: 80
23+
targetPort: http
24+
protocol: TCP
25+
name: http
26+
selector:
27+
app: rollout-apisix-canary
28+
# This selector will be updated with the pod-template-hash of the stable ReplicaSet. e.g.:
29+
# rollouts-pod-template-hash: 789746c88d

0 commit comments

Comments
 (0)