水果套餐网站,广州冼村和猎德村哪个最有钱,我附近的广告公司,厦门软件开发工资一般多少文章目录 前言自动渐进式交付概述自动渐进式交付准备创建生产环境创建 AnalysisTemplate访问生产环境安装Prometheus配置 Ingress-Nginx 和 ServiceMonitor验证 Ingress-Nginx 指标 自动渐进式交付实战自动渐进式交付成功自动渐进式交付失败 结语 前言 在实施金丝雀发布的过程中… 文章目录 前言自动渐进式交付概述自动渐进式交付准备创建生产环境创建 AnalysisTemplate访问生产环境安装Prometheus配置 Ingress-Nginx 和 ServiceMonitor验证 Ingress-Nginx 指标 自动渐进式交付实战自动渐进式交付成功自动渐进式交付失败 结语 前言 在实施金丝雀发布的过程中我们通过 Argo Rollout 的金丝雀策略将发布过程分成了 3 个阶段每个阶段金丝雀的流量比例都不同经过一段时间之后金丝雀环境变成了新的生产环境。实际上这也是一种渐进式的交付方式它通过延长发布时间来保护生产环境降低了发生生产事故的概率。 不过这种渐进式的交付方式存在一个明显的缺点无法自动判断金丝雀环境是否出错? 这可能会导致一种情况当金丝雀环境在接收生产流量之后它产生了大量的请求错误在缺少人工介入的情况下发布仍然按照计划进行最终导致生产环境故障。 为了解决这个问题我们希望渐进式交付变得更加智能一个好的工程实践方式是 通过指标分析来自动判断金丝雀发布的质量如果符合预期就继续金丝雀步骤如果不符合预期则进行回滚。 这样也就能够避免将金丝雀环境的故障带到生产环境中了这种分析方法也称之为金丝雀分析。 自动渐进式交付概述 相比较金丝雀发布自动渐进式交付增加了 Prometheus、Analysis Template 和 AnalysisRun 对象。其中Analysis Template 定义用于分析的模板AnalysisRun 是分析模板的实例化Prometheus 是用来存储指标的数据库。 自动渐进式交付流程图 自动渐进式交付开始时首先会先将金丝雀环境的流量比例设置为20%并持续两分钟然后将金丝雀环境的流量比例设置为40%并持续两分钟然后再以此类推到 60%、80%直到将金丝雀环境提升为生产环境为止。 从第二个阶段开始自动金丝雀分析开始运行在持续运行的过程中如果金丝雀分析失败那么金丝雀环境将进行自动回滚。这样就达到了自动渐进式交付的目的。 自动渐进式交付准备
创建生产环境 创建用于模拟生产环境的 Rollout 对象、Service 和 Ingress. cat rollout-with-analysis.yaml
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:name: canary-demo
spec:replicas: 1selector:matchLabels:app: canary-demostrategy:canary:analysis:templates:- templateName: success-ratestartingStep: 2args:- name: traefikvalue: traefik-service#- name: ingress# value: canary-democanaryService: canary-demo-canarystableService: canary-demotrafficRouting:traefik:weightedTraefikServiceName: traefik-service#nginx:# stableIngress: canary-demosteps:- setWeight: 20- pause:duration: 2m- setWeight: 40- pause:duration: 2m- setWeight: 60- pause:duration: 2m- setWeight: 80- pause:duration: 2mtemplate:metadata:labels:app: canary-demospec:containers:- image: argoproj/rollouts-demo:blueimagePullPolicy: Alwaysname: canary-demoports:- containerPort: 8080name: httpprotocol: TCPresources:requests:cpu: 5mmemory: 32Mi对比金丝雀发布的 Rollout 对象并没有太大差异只是在 canary 字段下面增加了analysis字段它的作用是指定金丝雀分析的模板模板内容需单独创建。另外这里同样使用了argoproj/rollouts-demo:blue镜像来模拟生产环境。 #创建生产环境和金丝雀环境所需要用到的 Service
cat canary-demo-service-v2.yaml
apiVersion: v1
kind: Service
metadata:name: canary-demolabels:app: canary-demo
spec:ports:- port: 80targetPort: httpprotocol: TCPname: httpselector:app: canary-demo
---
apiVersion: v1
kind: Service
metadata:name: canary-demo-canarylabels:app: canary-demo
spec:ports:- port: 80targetPort: httpprotocol: TCPname: httpselector:app: canary-demo$ kubectl apply -f canary-demo-service-v2.yaml#创建ingress
cat canary-demo-ingress-v2.yaml
apiVersion: traefik.containo.us/v1alpha1
kind: IngressRoute
metadata:name: canary-demolabels:app: canary-demo
spec:entryPoints:- webroutes:- match: Host(progressive.auto) PathPrefix(/)kind: Ruleservices:- name: canary-demoport: http创建 AnalysisTemplate
$ cat analysis-success.yaml
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:name: success-rate
spec:args:- name: traefikmetrics:- name: success-rateinterval: 10sfailureLimit: 3successCondition: result[0] 0.90provider:prometheus:address: http://prometheus-kube-prometheus-prometheus.prometheus:9090query: sum(rate(traefik_service_requests_total{traefik{{args.traefik}},status!~[4-5].*}[60s]))/sum(rate(traefik_service_requests_total{traefik{{args.traefik}}}[60s]))介绍一下 AnalysisTemplate 对象字段的含义 首先spec.args字段定义了参数该参数会在后续的 query 语句中使用它的值是从 Rollout 对象的 canary.analysis.args 字段传递进来的。 spec.metrics 字段定义了自动分析的相关配置。其中interval 字段为频率每 10 秒钟执行一次分析。failureLimit 字段代表“连续 3 次失败则金丝雀分析失败”此时要执行回滚动作。successCondition 字段代表判断条件这里的 result[0] 是一个表达式代表的含义是当查询语句的返回值大于 0.90 时说明本次金丝雀分析成功了。 spec.metrics.provider 字段定义了分析数据来源于 Prometheus还定义了 Prometheus Server 的连接地址 query 字段是金丝雀分析的查询语句。这条查询语句的含义简单理解为在 60 秒内 HTTP 状态码不为 4xx 和 5xx 的请求占所有请求的比例。换句话说当 HTTP 请求成功的比例大于 0.90 时代表一次金丝雀分析成功。 访问生产环境
http://progressive.auto/
安装Prometheus 由于金丝雀分析需要用到 Prometheus 来查询指标可以通过helm安装或者用自己本地环境的Prometheus也可以。 $ helm repo add prometheus-community https://prometheus-community.github.io/helm-charts
$ helm upgrade prometheus prometheus-community/kube-prometheus-stack \
--namespace prometheus --create-namespace --install \
--set prometheus.prometheusSpec.podMonitorSelectorNilUsesHelmValuesfalse \
--set prometheus.prometheusSpec.serviceMonitorSelectorNilUsesHelmValuesfalseRelease prometheus does not exist. Installing it now.
......
STATUS: deployed--set 对安装参数进行了配置这是为了让它后续能够顺利获取到 Ingress-Nginx 的监控指标配置 Ingress-Nginx 和 ServiceMonitor 为了让 Prometheus 能够顺利地获取到 HTTP 请求指标我们需要打开 Ingress-Nginx Metric 指标端口。 $ kubectl patch deployment ingress-nginx-controller -n ingress-nginx --typejson -p[{op: add, path: /spec/template/spec/containers/0/ports/-, value: {name: prometheus,containerPort:10254}}]
deployment.apps/ingress-nginx-controller patched然后为 Ingrss-Nginx Service 添加指标端口。
$ kubectl patch service ingress-nginx-controller -n ingress-nginx --typejson -p[{op: add, path: /spec/ports/-, value: {name: prometheus,port:10254,targetPort:prometheus}}]
service/ingress-nginx-controller patched用Traefik的话开启metrics即可- containerPort: 9101hostPort: 9101name: metrics创建 ServiceMonitor 对象它可以为 Prometheus 配置指标获取的策略 apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:name: nginx-ingress-controller-metricsnamespace: prometheuslabels:app: nginx-ingressrelease: prometheus-operator
spec:endpoints:- interval: 10sport: prometheusselector:matchLabels:app.kubernetes.io/instance: ingress-nginxapp.kubernetes.io/name: ingress-nginxnamespaceSelector:matchNames:- ingress-nginx如果你使用的是Traefik可以用以下配置
cat servicemonitor.yaml
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:name: traefik-ingress-controllernamespace: kubesphere-monitoring-systemlabels:app: traefik
spec:endpoints:- interval: 10sport: metricsselector:matchLabels:app: traefiknamespaceSelector:matchNames:- traefik验证 Ingress-Nginx 指标 测试Prometheus 是否已经成功获取到了 Ingress-Nginx 指标这将决定自动金丝雀分析是否能成功获取到数据博主此处用的是Traefik 自动渐进式交付实战 此次实战过程中会按照这张流程图分别进行两个实验。
自动渐进式交付成功图中①号链路自动渐进式交付失败图中②号链路
自动渐进式交付成功 验证的话只要更新 Rollout 对象的镜像版本即可。两种方式第一直接编辑 Rollout 对象并通过 kubectl apply 的方法来更新镜像版本。第二种通过Argo Rollout kubectl插件来更新镜像。 kubectl argo rollouts set image canary-demo canary-demoargoproj/rollouts-demo:green
rollout canary-demo image updated过一会儿看到绿色方块开始出现流量占比约为 20%如下图所示: 也可以打开Argo Rollout 控制台观察自动渐进式交付过程。可以看到目前处在 20% 金丝雀流量的下一阶段也就是暂停 2 分钟的阶段。 2 分钟后将进入到 40% 金丝雀流量阶段从这个阶段开始自动金丝雀分析开始工作直到最后金丝雀发布完成金丝雀环境提升为了生产环境这时自动分析也完成了.
自动渐进式交付失败 上述演示中由于应用返回的 HTTP 状态码都是 200 所以金丝雀分析自然是会成功的。 接下来我们来尝试进行自动渐进式交付失败的实验。 经过了自动渐进式交付成功的实验之后当前生产环境中的镜像为 argoproj/rollouts-demo:green我们继续使用Argo Rollout kubectl插件来更新镜像并将镜像版本修改为yellow版本。 kubectl argo rollouts set image canary-demo canary-demoargoproj/rollouts-demo:yellow
rollout canary-demo image updated接下来我们让应用返回错误的 HTTP 状态码。你可以滑动界面上的 ERROR 滑动块将错误率设置为 50% 现在你会在黄色方块中看到带有红色描边的方块这代表本次请求返回的 HTTP 状态码不等于 200说明 我们成功控制了一部分请求返回错误。 2 分钟后金丝雀发布会进入到 40% 流量的阶段此时自动分析将开始进行。可以通过 Argo Rollout 控制台实时观察。 等待一段时间后金丝雀分析将失败是预期内的 此时Argo Rollout 将执行自动回滚操作这时候重新返回http://progressive.auto打开应用你会看到黄色方块的流量消失所有请求被绿色方块取代说明已经完成回滚了如下图所示: 到这里一次完整的渐进式交付失败实验就完成了。
结语 跟之前金丝雀发布不同的是渐进式交付在金丝雀发布的过程中加入了自动金丝雀分析它可以验证新版本在生产环境中的表现而这是单纯的金丝雀发布所无法实现的。借助渐进式交付我们可以在发布过程通过指标实时分析金丝雀环境兼顾发布的安全性和效率。 值得注意的是为了能够查询到示例应用的 HTTP 指标开启了 Ingress-Nginx/Traefik-controller的指标开关这样所有经过 Ingress-Nginx 的流量都会被记录下来结合Prometheus ServiceMonitor实现了 HTTP 请求指标的采集。 此外为了让 ArgoCD 在渐进式交付时顺利运行金丝雀分析我们还需要创建AnalysisTemplate对象它实际上是 PromQL 编写的查询语句ArgoCD 在交付过程中会用这条语句去 Prometheus 查询并将返回的结果和预定义的阈值进行对比以此控制渐进式交付应该继续进行还是回滚。 在实际的业务场景中如果希望验证多个维度的指标你可以创建多个AnalysisTemplate并将它配置到 Rollout 对象中进一步提高分析的可靠性。另外还可以在金丝雀发布的steps阶段里配置“内联”的分析步骤比如在金丝雀环境 20% 和 40% 流量阶段的下一阶段分别运行不同的金丝雀分析具体参考 https://argoproj.github.io/argo-rollouts/features/analysis/
