$ oc get ksvc <service_name> -o=jsonpath='{.status.latestCreatedRevisionName}'
您可以使用蓝绿部署策略安全地将应用程序的生产版本的流量重新路由到新版本。
集群上已安装 OpenShift Serverless Operator 和 Knative Serving。
安装 OpenShift CLI (oc
)。
将应用程序作为 Knative 服务创建和部署。
通过查看以下命令的输出,找到部署服务时创建的第一个修订版的名称
$ oc get ksvc <service_name> -o=jsonpath='{.status.latestCreatedRevisionName}'
$ oc get ksvc showcase -o=jsonpath='{.status.latestCreatedRevisionName}'
$ showcase-00001
将以下 YAML 添加到服务 spec
中,以将入站流量发送到该修订版
...
spec:
traffic:
- revisionName: <first_revision_name>
percent: 100 # All traffic goes to this revision
...
验证您可以通过运行以下命令获得的 URL 查看您的应用程序
$ oc get ksvc <service_name>
通过至少修改服务 template
spec 中的一个字段并重新部署它来部署应用程序的第二个修订版。例如,您可以修改服务的 image
或 env
环境变量。您可以通过应用服务 YAML 文件或使用 kn service update
命令(如果您已安装 Knative (kn
) CLI)来重新部署服务。
通过运行该命令,找到重新部署服务时创建的第二个最新修订版的名称
$ oc get ksvc <service_name> -o=jsonpath='{.status.latestCreatedRevisionName}'
此时,服务的第一个和第二个修订版都已部署并正在运行。
更新现有服务以创建第二个修订版的新的测试端点,同时仍然将所有其他流量发送到第一个修订版
...
spec:
traffic:
- revisionName: <first_revision_name>
percent: 100 # All traffic is still being routed to the first revision
- revisionName: <second_revision_name>
percent: 0 # No traffic is routed to the second revision
tag: v2 # A named route
...
重新应用 YAML 资源重新部署此服务后,应用程序的第二个修订版现在已暂存。没有流量路由到主 URL 的第二个修订版,Knative 创建了一个名为 v2
的新服务用于测试新部署的修订版。
通过运行以下命令获取第二个修订版的新服务的 URL
$ oc get ksvc <service_name> --output jsonpath="{.status.traffic[*].url}"
您可以使用此 URL 验证应用程序的新版本是否按预期运行,然后再将任何流量路由到它。
再次更新您的现有服务,以便50% 的流量发送到第一个版本,50% 的流量发送到第二个版本。
...
spec:
traffic:
- revisionName: <first_revision_name>
percent: 50
- revisionName: <second_revision_name>
percent: 50
tag: v2
...
当您准备好将所有流量路由到新版本的应用程序时,再次更新服务,将 100% 的流量发送到第二个版本。
...
spec:
traffic:
- revisionName: <first_revision_name>
percent: 0
- revisionName: <second_revision_name>
percent: 100
tag: v2
...
如果您不打算回滚版本,可以移除第一个版本,而不是将其流量设置为 0%。不可路由的版本对象随后将被垃圾回收。 |
访问第一个版本的 URL,以验证不再有流量发送到旧版本的应用程序。