尝试在OpenShift中进行渐进式交付!(Argo Rollouts基础教程-CLI版本)
背景 – (Background)
蓝/绿布署 (Blue/Green Deployment) 和金丝雀发布 (Canary Release) 等实践方法是在云计算和容器出现之前就存在的用于生产环境发布的技术,但由于许多阻碍因素,直到现在仍然很难实践。
-
- 必要なときだけサーバーリソースを手に入れることが出来ないため本番と同等の環境を2つも用意できない
-
- 必要な機能が多岐にわたる上に候補となる製品も多く、さらには担当するチームが異なる
高度なネットワーク制御(インフラチーム)
アプリケーションのデプロイ(アプリチーム or 運用チーム)
アプリケーションの機能検証(アプリチーム)
アプリケーションのパフォーマンス分析(運用チーム)
関連する製品が多いため自動化が困難で手動オペレーションに頼らざるを得ない
近年,云计算和容器已经成为常态,这类问题几乎都可以很容易地解决。
-
- クラウドやコンテナ・プラットフォームが主流となり、誰でも必要な時に必要なだけサーバーリソースを調達できるようになる
-
- 必要な機能のほとんどがコンテナ・プラットフォーム(Kubernetes)で用意されるようになった上に利用方法も簡単に
高度なトラフィック制御(Istio、Linkerd、Nginx Ingress)
アプリケーションのデプロイ(Kubernetes標準機能)
アプリケーションの機能検証(従来のテスト自動化製品)
アプリケーションのパフォーマンス分析(Prometheus)
以前,我们已经能够利用各种CI工具和自动化服务(如Jenkins)来解决最终自动化的困难问题。然而,从需要手动执行各种工具的步骤来看,实现简单的自动化发布操作并不容易,因为这需要我们理解这些工具的协作方式。
-
- Istioを利用することでBlue/Greenやカナリア・リリースに不可欠なトラフィック制御も簡単にできるとはいえ、切り替えを自動化する仕組みは作り込まなきゃいけないのか?
- Prometheusから得た様々なメトリクスを分析する事はできるが、分析結果を元にリリースプロセスに組むにはどうすればよいのか?
这次介绍的工具包括Argo Rollouts等Progressive Delivery工具,它们可以解决以上的问题。Flagger是与Argo Rollouts一起在Kubernetes上运行的工具,它们都可以使用声明性方法来记录发布流程,因此不需要了解操作Istio和Prometheus的方法。
这篇文章总结了根据手册步骤试用了一下Argo Rollouts基本功能的结果。
前提 tí) – Premise
-
- Kubernetesクラスター
OpenShift on IBM Cloud (v4.6)
クライアント環境
Argo Rollouts Kubectl plugin の Dockerコンテナ(Docker Desktop on Windows 10)
由于缺少适用于Windows端的Argo Rollouts Kubectl插件的执行文件,无法直接在Windows设备上运行命令。
幸运的是,通过查看手册,可以使用Docker容器镜像来代替。
使用Docker与CLI命令。
此外,该容器会在启动时执行通过参数传递的命令,不支持在容器启动后在容器内部执行命令的用法。
在处理与API服务器的认证时,虽然版本命令的例子很好,但我在本地终端上与API服务器进行认证并挂载本地的~/.kube/config文件时遇到了一些问题,并在试错中意识到这一点。
此外,如果不挂载服务器证书,会出现错误,但由于这很麻烦,我们通过指定–insecure-skip-tls-verify来避免。
请参考以下具体命令。
引入的步驟
请参考以下步骤,在IBM Cloud上安装OpenShift控制器。
https://argoproj.github.io/argo-rollouts/installation/
控制器安装
- OpenShiftへログイン
PS D:\git> oc login --token=sha256~xxxxxxxxxxxxxxxxxxxxxxxxx --server=https://c103-e.us-south.containers.cloud.ibm.com:31989
Logged into "https://c103-e.us-south.containers.cloud.ibm.com:31989" as "IAM#strada@jp.ibm.com" using the token provided.
You have access to 79 projects, the list has been suppressed. You can list all projects with ' projects'
Using project "default".
- 新規プロジェクトの作成
PS D:\git> oc new-project argo-rollouts
Now using project "argo-rollouts" on server "https://c103-e.us-south.containers.cloud.ibm.com:31989".
You can add applications to this project with the 'new-app' command. For example, try:
oc new-app rails-postgresql-example
to build a new example application in Ruby. Or use kubectl to deploy a simple Kubernetes application:
kubectl create deployment hello-node --image=k8s.gcr.io/serve_hostname
- コントローラの導入
PS D:\git> oc apply -n argo-rollouts -f https://github.com/argoproj/argo-rollouts/releases/latest/download/install.yaml
customresourcedefinition.apiextensions.k8s.io/analysisruns.argoproj.io created
customresourcedefinition.apiextensions.k8s.io/analysistemplates.argoproj.io created
customresourcedefinition.apiextensions.k8s.io/clusteranalysistemplates.argoproj.io created
customresourcedefinition.apiextensions.k8s.io/experiments.argoproj.io created
customresourcedefinition.apiextensions.k8s.io/rollouts.argoproj.io created
serviceaccount/argo-rollouts created
clusterrole.rbac.authorization.k8s.io/argo-rollouts-aggregate-to-admin created
clusterrole.rbac.authorization.k8s.io/argo-rollouts-aggregate-to-edit created
clusterrole.rbac.authorization.k8s.io/argo-rollouts-aggregate-to-view created
clusterrole.rbac.authorization.k8s.io/argo-rollouts-clusterrole created
clusterrolebinding.rbac.authorization.k8s.io/argo-rollouts-clusterrolebinding created
service/argo-rollouts-metrics created
deployment.apps/argo-rollouts created
Argo发布Kubectl插件
- Docker Desktopの共有設定を確認
如果你正在使用Docker Desktop,请确保在Docker Desktop的设置或下面的齿轮图标中的资源->文件共享中确认kubeconfig文件的存储位置已经共享。
PS D:\git> docker run --rm -v C:\Users\YASUYUKIKUBOTA\.kube\config:/.kube/config quay.io/argoproj/kubectl-argo-rollouts:master version
kubectl-argo-rollouts: v1.1.0+unknown
BuildDate: 2021-07-03T00:27:43Z
GitCommit:
GitTreeState: clean
GoVersion: go1.16.3
Compiler: gc
Platform: linux/amd64
试行
我将参考以下页面的手册进行尝试。
https://argoproj.github.io/argo-rollouts/getting-started/
虽然手册中没有提到,但先确认一下先决条件的Rollout配置。
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: rollouts-demo
spec:
replicas: 5
strategy:
canary:
steps:
- setWeight: 20
- pause: {}
- setWeight: 40
- pause: {duration: 10}
- setWeight: 60
- pause: {duration: 10}
- setWeight: 80
- pause: {duration: 10}
revisionHistoryLimit: 2
selector:
matchLabels:
app: rollouts-demo
template:
metadata:
labels:
app: rollouts-demo
spec:
containers:
- name: rollouts-demo
image: argoproj/rollouts-demo:blue
ports:
- name: http
containerPort: 8080
protocol: TCP
resources:
requests:
memory: 32Mi
cpu: 5m
-
- RolloutのStrategyはCanaryに設定されています。
-
- RolloutのStepは20%ずつCanaryに推移していく設定になっています。
-
- 20%から40%へのStepの移行までの間隔(pauseで指定されたオブジェクトのduration属性)が無指定なのでここで一旦停止します。
- 40%以降は移行までの間隔に10秒(単位無指定の場合は秒になる)に設定されています。
- 部署一个推出计划
- Rolloutの作成
PS D:\git> oc apply -f https://raw.githubusercontent.com/argoproj/argo-rollouts/master/docs/getting-started/basic/rollout.yaml
rollout.argoproj.io/rollouts-demo created
PS D:\git> oc apply -f https://raw.githubusercontent.com/argoproj/argo-rollouts/master/docs/getting-started/basic/service.yaml
service/rollouts-demo created
- Rolloutの状況を確認
docker run --rm -v C:\Users\YASUYUKIKUBOTA\.kube\config:/.kube/config quay.io/argoproj/kubectl-argo-rollouts:master get rollout rollouts-demo --watch --insecure-skip-tls-verify
在任何推出的初始创建中,将立即将复制品扩展至100%(跳过任何金丝雀升级步骤、分析等),因为没有发生任何升级。
根据手册的说明,创建 Rollout 时立即达到100%是正确的行为。
- 更新一个强化
Rolloutで参照しているコンテナ・イメージを変更
PS D:\git> docker run --rm -v C:\Users\YASUYUKIKUBOTA\.kube\config:/.kube/config quay.io/argoproj/kubectl-argo-rollouts:master set image rollouts-demo rollouts-demo=argoproj/rollouts-demo:yellow --insecure-skip-tls-verify
rollout "rollouts-demo" image updated
在更新过程中,控制器会按照部署更新策略中定义的步骤进行进展。示例部署设置了20%的流量权重给金丝雀版本,并且会暂停部署直到用户采取行动取消暂停/推进部署。在更新完镜像后,再次观察部署进展直到达到暂停状态。
当演示版本从第二步开展时,我们可以从插件中看到Rollout处于暂停状态,并且现在有1个新版本的pod模板正在运行中,而有4个旧版本正在运行中,占总数的20%,根据setWeight:20步骤定义的权重。
- 推广一个推出
RolloutをPromote
PS D:\git> docker run --rm -v C:\Users\YASUYUKIKUBOTA\.kube\config:/.kube/config quay.io/argoproj/kubectl-argo-rollouts:master promote rollouts-demo --insecure-skip-tls-verify
rollout 'rollouts-demo' promoted
- 中止一个推出
Rolloutを実行
PS D:\git> docker run --rm -v C:\Users\YASUYUKIKUBOTA\.kube\config:/.kube/config quay.io/argoproj/kubectl-argo-rollouts:master set image rollouts-demo rollouts-demo=argoproj/rollouts-demo:red --insecure-skip-tls-verify
rollout "rollouts-demo" image updated
RolloutをAbort
这次执行的不是Promote,而是Abort。
总结
在本文中,我們實施了「Get Started」中「Basic Usage」的步驟,使用 Argo Rollouts 的 Rollout 資源,體驗了將程式推移至 Canary 的步驟。我們也發現可以使用 Pause 來判斷是否要將 Canary 推廣為穩定版。如果判斷 Canary 存在問題,我們也發現可以通過 Abort 回到原始版本。
我想要验证如何使用仪表板的功能来执行通过 Argo Rollouts Kubectl 插件执行的 Promote 和 Abort 命令。
建议
每次运行 argo rollouts get rollout 命令,正在运行的容器就会不断增多。
如果在结束时使用Ctrl+C退出的话,容器中的进程会继续运行而不会退出容器,即使指定了“–rm”,容器仍然会保持运行状态。如果不想在增加垃圾的情况下,希望容器保持运行状态,可以通过docker exec进入运行中的容器,直接使用kubectl-argo-rollouts命令操作,这样就不会增加垃圾。
PS D:\git> docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
b0317447efc9 quay.io/argoproj/kubectl-argo-rollouts:master "/bin/kubectl-argo-r…" 5 minutes ago Up 5 minutes sleepy_elbakyan
PS D:\git> docker exec -it b0317447efc9 /bin/bash
I have no name!@b0317447efc9:/home/argo-rollouts$ kubectl-argo-rollouts get rollout rollouts-demo --watch --insecure-skiptls-verify
Error: unknown flag: --insecure-skiptls-verify
I have no name!@b0317447efc9:/home/argo-rollouts$ kubectl-argo-rollouts get rollout rollouts-demo --watch --insecure-skip-tls-verify
Name: rollouts-demo
Namespace: argo-rollouts
Status: ✔ Healthy
Strategy: Canary
Step: 8/8
SetWeight: 100
ActualWeight: 100
Images: argoproj/rollouts-demo:blue (stable)
Replicas:
Desired: 5
Current: 5
Updated: 5
Ready: 5
Available: 5