试用 Argo Rollouts 的新功能“实验”
您是否听说过 Argo Rollouts 项目?
这个项目旨在给 Kubernetes 的 Deployment 添加蓝绿部署和金丝雀发布等功能。
具体来说,将使用新创建的Rollout资源,而不是Deployment资源,因为它们的定义非常相似,可以通过简单修改实现上述各种多样的部署方式。
在本文中,我们将介绍于2019年11月发布的v0.6.0版本中新增的实验功能-Experiments。
我在KubeCon NA 2019的”Leveling Up Your CD: Unlocking Progressive Delivery on Kubernetes”演讲中了解到这个功能,觉得很有意思,所以决定深入研究并选择这个作为本次的主题。
※本文是作为Z实验室工作的一部分撰写的。
实验是一种科学方法,用于收集数据和验证假设。
Experiments是一种机制,能够部署多个ReplicaSet并对生成的Pod执行一些分析。
用户可以通过创建一个被CRD定义的资源,名为Experiments,来指示执行这些分析。
被考虑的使用案例
-
- 2つのバージョンのアプリケーションを一定時間デプロイし、その後Kayantaのようなツールで2つのバージョンのメトリクスの違いなどを分析します。
-
- A/B/Cと異なるバージョンを長い間同時に実行し続けます。
- 新しいアプリケーションを別のラベルで立ち上げます。これにより新しいバージョンのアプリケーションにはServiceによるロードバランスがされず、静かな環境でテストを実施することができます。
行动的状态
我将在GitHub上尝试一下这个示例。
以下是「实验」的定义。我在下面进行了内联解释。
apiVersion: argoproj.io/v1alpha1
kind: Experiment # Experimentリソースです。
metadata:
name: experiment-with-analysis # 名前です。なんでも良いです。
spec:
templates: # ここはDeploymentのためのTemplateです。 実験したいバージョン分だけ配列を続けます
- name: purple # 1つ目のDeploymentです
selector:
matchLabels:
app: rollouts-demo
template: # ここはPodのためのTemplateです
metadata:
labels:
app: rollouts-demo
v: purple
spec:
containers:
- name: rollouts-demo
image: argoproj/rollouts-demo:purple # ここでバージョン指定です。ここだけがもう一つと違います。
imagePullPolicy: Always
- name: orange # 2つ目のDeploymentです
selector:
matchLabels:
app: rollouts-demo
template:
metadata:
labels:
app: rollouts-demo
v: orange
spec:
containers:
- name: rollouts-demo
image: argoproj/rollouts-demo:orange # ここでバージョン指定です。ここだけがもう一つと違います。
imagePullPolicy: Always
analyses: # 試したい分析の数だけ続きます。今回は2つの分析を登録しています。
- name: pass
templateName: pass # 分析の方法を参照しています。定義は別途紹介。
- name: random
templateName: random-fail # 分析の方法を参照しています。定義は別途紹介。
实验是一个资源,它包含了与部署非常相似的资源列表和分析任务的列表。
每个列表表示了分析的工作负载和对应的分析任务。
以下是一份绝对会成功的分析报告。
kind: AnalysisTemplate
apiVersion: argoproj.io/v1alpha1
metadata:
name: pass
spec:
metrics:
- name: pass
interval: 5s
failureLimit: 1
provider:
job:
spec:
template:
spec:
containers:
- name: sleep
image: alpine:3.8
command: [sh, -c]
args: [exit 0]
restartPolicy: Never
backoffLimit: 0
以下是随机失败的Analysys。
kind: AnalysisTemplate
apiVersion: argoproj.io/v1alpha1
metadata:
name: random-fail
spec:
metrics:
- name: random-fail
interval: 5s
failureLimit: 1
provider:
job:
spec:
template:
spec:
containers:
- name: sleep
image: alpine:3.8
command: [sh, -c]
args: [FLIP=$(($(($RANDOM%10))%2)) && exit $FLIP]
restartPolicy: Never
backoffLimit: 0
在这个示例中,我们定义了两个无用的Analysis,但通过将这部分转化为Curl或http基准测试脚本,我们可以进行有用的分析。
除了我们介绍的两个提供者job之外,还可以指定其他提供者如prometheus或Kayenta。
如果使用 Prometheus,您可以使用 PromQL 来定义条件。此外,Kayenta 是一个专门的分析工具,可以在之前版本和金丝雀发布版本之间进行指标比较,以判断是否存在异常情况。这看起来非常有用。
(↑ 目前仓库中尚未有prometheus的示例,但KubeCon NA 2019的演讲资料中列举了类似上图的示例。这个示例同时使用PromQL进行分析,并接受来自名为args的工作负载的可指定参数。)
现在,让我们将上述清单部署到集群中,并观察情况。
首先,部署 Argo Rollout 自身。
$ kubectl create namespace argo-rollouts
$ kubectl apply -n argo-rollouts -f https://raw.githubusercontent.com/argoproj/argo-rollouts/stable/manifests/install.yaml
为了可视化检查 Experiments 的状态,我们将安装一个 kubectl 插件。
$ curl -LO https://github.com/argoproj/argo-rollouts/releases/download/v0.6.0/kubectl-argo-rollouts-darwin-amd64
$ chmod +x ./kubectl-argo-rollouts-darwin-amd64
$ sudo mv ./kubectl-argo-rollouts-darwin-amd64 /usr/local/bin/kubectl-argo-rollouts
(参考链接:https://argoproj.github.io/argo-rollouts/features/kubectl-plugin/)
接下来,我们将部署之前介绍的实验和分析模板(Experiments, AnalysisTemplate)。
过了一段时间后,我会使用kubectl来确认情况。
在实验中,它已经以“Failed”状态停止。进一步观察可以发现,experiment-with-analysis-random已经失败了两次。而experiment-with-analysis-pass则在两次尝试中都取得了成功。
我们可以得知由于存在超过规定次数的失误分析,导致实验目标的部署结束了。
我已经确认按照Experiment资源中所述的方式运行工作负载,并进行指定的分析,并且结果被记录下来了。
总结
我测试了 Argo Rollouts 的新功能 Experiments。
Experiments 主要进行多版本的部署和相应的测试。虽然手动逐个执行Deployment或Job也能实现相同的功能,但使用 Experiments 可以以”声明式”的方式进行测试,这是一个优点。
此次没有介绍,但是可以在Argo Rollouts的主要功能之一的Blue/Green部署或者Canary部署的前阶段执行Experiments,因此可以在生产环境中进行操作测试,如果没有问题,就可以部署新版本。我认为Experiments在这种情况下非常有用,可以实现带有逻辑的部署,例如展开。特别是通过使用Kayenta来对之前的工作负载和新的工作负载进行综合比较,以判断是否与之前有所不同,这种测试方法将会流行起来吗?这是我感到的。
我原本想尝试与Kayenta的合作,但是找不到简单的部署步骤,所以放弃了。如果有人能试一下并告诉我该怎么做,我会很感激。