在Kubernetes上如何部署ArgoRollouts和Ambassador进行灰度发布
这篇文章给大家分享的是有关在Kubernetes上如何部署Argo Rollouts和Ambassador进行灰度发布的内容。小编觉得挺实用的,因此分享给大家做个参考,一起跟随小编过来看看吧。
目前创新互联公司已为成百上千家的企业提供了网站建设、域名、网站空间、网站托管维护、企业网站设计、辽中网站维护等服务,公司将坚持客户导向、应用为本的策略,正道将秉承"和谐、参与、激情"的文化,与客户和合作伙伴齐心协力一起成长,共同发展。
Ambassador API 网关与 Argo 集成
灰度发布(金丝雀发布/Canary)是一种强大的策略,通过增量地向用户子集发布软件的新版本来降低生产风险。假设你推出了服务的 v1.1 版本,但它有一个 bug。不是立即将它暴露给所有的流量,而是通过将 v1.1 暴露给流量的一个子集(例如 5%)来开始发布过程。随着时间的推移,你的流量逐渐增加到 100%。在此期间,任何暴露的 bug 都仅限于你的用户子集。
虽然理论上很简单,但在实践中使用灰度发布需要将 CI 流水线与持续部署工作流(如 Argo)集成在一起,并使用 API 网关来管理到服务的流量。
AmbassadorAPI 网关
Ambassador 是一个基于 Envoy 代理构建的开源 kubernetes 原生 API 网关和入口控制器。Ambassador 的常见用例包括路由 gRPC 流量、认证和速率限制。虽然 Ambassador 支持标准的 ingress 类,但大多数用户使用 Ambassador mapping 资源。mapping 资源定义了路由并支持大量的属性集,超出了 ingress 支持的标准集。下面是一个 mapping 示例:
apiVersion: getambassador.io/v2
kind: Mapping
metadata:
name: echo
spec:
prefix: /echo
rewrite: /echo
service: echo-stable:80
在 Kubernetes 上进行灰度发布
我们已经在 Argo Rollouts 和 Ambassador 之间建立了一个原生集成(代码)[1]。你现在可以创建一个 Rollout 资源来引用 Ambassador mapping:
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: echo-rollout
annotations:
spec:
replicas: 5
revisionHistoryLimit: 2
selector:
matchLabels:
app: echo
template:
metadata:
labels:
app: echo
spec:
containers:
- image: hashicorp/http-echo
args:
- "-text=VERSION 137"
- -listen=:8080
imagePullPolicy: Always
name: echo-v1
ports:
- containerPort: 8080
strategy:
canary:
stableService: echo-stable
canaryService: echo-canary
trafficRouting:
ambassador:
mapping:
- echo
steps:
- setWeight: 20
- pause: {duration: 10s}
- setWeight: 50
- pause: {duration: 10s}
- setWeight: 100
- pause: {duration: 10}
请注意上面粗体部分,它引用了上面定义的名为 echo 的 Ambassador mapping 资源。将这些配置应用到集群将启动 echo-canary 服务,该服务将把 20%的流量路由到 canary,持续 10 秒,然后在 10 秒内提升到 50%,然后再提升到 100%。
感谢各位的阅读!关于“在Kubernetes上如何部署Argo Rollouts和Ambassador进行灰度发布”这篇文章就分享到这里了,希望以上内容可以对大家有一定的帮助,让大家可以学到更多知识,如果觉得文章不错,可以把它分享出去让更多的人看到吧!
网页名称:在Kubernetes上如何部署ArgoRollouts和Ambassador进行灰度发布
网站URL:http://azwzsj.com/article/gddjdc.html