Flagger on ASM·基于Mixerless Telemetry实现渐进式灰度发布系列 1 遥测数据

本文涉及的产品
容器镜像服务 ACR,镜像仓库100个 不限时长
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
容器服务 Serverless 版 ACK Serverless,952元额度 多规格
简介: 服务网格ASM的Mixerless Telemetry技术,为业务容器提供了无侵入式的遥测数据。遥测数据一方面作为监控指标被ARMPS/prometheus采集,用于服务网格可观测性;另一方面被HPA和flaggers使用,成为应用级扩缩容和渐进式灰度发布的基石。本系列聚焦于遥测数据在应用级扩缩容和渐进式灰度发布上的实践,将分三篇介绍遥测数据(监控指标)、应用级扩缩容,和渐进式灰度发布。

服务网格ASM的Mixerless Telemetry技术,为业务容器提供了无侵入式的遥测数据。遥测数据一方面作为监控指标被ARMPS/prometheus采集,用于服务网格可观测性;另一方面被HPA和flaggers使用,成为应用级扩缩容和渐进式灰度发布的基石。

本系列聚焦于遥测数据在应用级扩缩容和渐进式灰度发布上的实践,将分三篇介绍遥测数据(监控指标)、应用级扩缩容,和渐进式灰度发布。

总体架构

本系列的总体架构如下图所示:

  1. ASM下发Mixerless Telemetry相关的EnvoyFilter配置到各ASM sidecar(envoy),启用应用级监控指标的采集。
  2. 业务流量通过Ingress Gateway进入,各ASM sidecar开始采集相关监控指标。
  3. Prometheus从各POD上采集监控指标。
  4. HPA通过Adapter从Prometheus查询相关POD的监控指标,并根据配置进行扩缩容。
  5. Flagger通过Prometheus查询相关POD的监控指标,并根据配置向ASM发起VirtualService配置更新。
  6. ASM下发VirtualService配置到各ASM sidecar,从而实现渐进式灰度发布。

3d017eb88d621b3d89d2adf4561d35a1.png

Flagger渐进式发布流程

Flagger官网描述了渐进式发布流程,这里翻译如下:

  1. 探测并更新灰度Deployment到新版本
  2. 灰度POD实例数从0开始扩容
  3. 等待灰度POD实例数到达HPA定义的最小副本数量
  4. 灰度POD实例健康检测
  5. 由flagger-loadtester实例发起acceptance-test验证
  6. 灰度发布在验证失败时终止
  7. 由flagger-loadtester实例发起load-test验证
  8. 在配置流量复制时开始从生产全流量复制到灰度
  9. 每分钟从Prometheus查询并检测请求成功率和请求延迟等监控指标
  10. 灰度发布在监控指标不符预期的数量到达阈值时终止
  11. 达到配置中迭代的次数后停止流量复制
  12. 开始切流到灰度POD实例
  13. 更新生产Deployment到新版本
  14. 等待生产Deployment滚动升级完毕
  15. 等待生产POD实例数到达HPA定义的最小副本数量
  16. 生产POD实例健康检测
  17. 切流回生产POD实例
  18. 灰度POD实例缩容至0
  19. 发送灰度发布分析结果通知

原文如下:

With the above configuration, Flagger will run a canary release with the following steps:

  • detect new revision (deployment spec, secrets or configmaps changes)
  • scale from zero the canary deployment
  • wait for the HPA to set the canary minimum replicas
  • check canary pods health
  • run the acceptance tests
  • abort the canary release if tests fail
  • start the load tests
  • mirror 100% of the traffic from primary to canary
  • check request success rate and request duration every minute
  • abort the canary release if the metrics check failure threshold is reached
  • stop traffic mirroring after the number of iterations is reached
  • route live traffic to the canary pods
  • promote the canary (update the primary secrets, configmaps and deployment spec)
  • wait for the primary deployment rollout to finish
  • wait for the HPA to set the primary minimum replicas
  • check primary pods health
  • switch live traffic back to primary
  • scale to zero the canary
  • send notification with the canary analysis result

前提条件

Setup Mixerless Telemetry

本篇将介绍如何基于ASM配置并采集应用级监控指标(比如请求数量总数istio_requests_total和请求延迟istio_request_duration等)。主要步骤包括创建EnvoyFilter、校验envoy遥测数据和校验Prometheus采集遥测数据。

1 EnvoyFilter

登录ASM控制台,左侧导航栏选择服务网格 >网格管理,并进入ASM实例的功能配置页面。

  • 勾选开启采集Prometheus 监控指标
  • 点选启用自建 Prometheus,并填入Prometheus服务地址:`prometheus:9090(本系列将使用社区版Prometheus,后文将使用这个配置)。如果使用阿里云产品ARMS,请参考集成ARMS Prometheus实现网格监控
  • 勾选启用 Kiali(可选)

f92a68dbd9d2428f347abb0eccb5fc17.png

点击确定后,我们将在控制平面看到ASM生成的相关EnvoyFilter列表:

6b998570374366c7e22c3c92ca9b5266.png

2 Prometheus

2.1 Install

执行如下命令安装Prometheus(完整脚本参见:demo_mixerless.sh)。

kubectl --kubeconfig "$USER_CONFIG" apply -f $ISTIO_SRC/samples/addons/prometheus.yaml

2.2 Config Scrape

安装完Prometheus,我们需要为其配置添加istio相关的监控指标。登录ACK控制台,左侧导航栏选择配置管理>配置项,在istio-system下找到prometheus一行,点击编辑

e99b7f58e38a2fb5e85fbd342becfca2.png

prometheus.yaml配置中,将scrape_configs.yaml中的配置追加到scrape_configs中。

24b21ed0f59c779f29fb929b8d36772c.png

保存配置后,左侧导航栏选择工作负载>容器组,在istio-system下找到prometheus一行,删除Prometheus POD,以确保配置在新的POD中生效。

可以执行如下命令查看Prometheus配置中的job_name

kubectl --kubeconfig "$USER_CONFIG" get cm prometheus -n istio-system -o jsonpath={.data.prometheus\\.yml} | grep job_name
- job_name: 'istio-mesh'
- job_name: 'envoy-stats'
- job_name: 'istio-policy'
- job_name: 'istio-telemetry'
- job_name: 'pilot'
- job_name: 'sidecar-injector'
- job_name: prometheus
  job_name: kubernetes-apiservers
  job_name: kubernetes-nodes
  job_name: kubernetes-nodes-cadvisor
- job_name: kubernetes-service-endpoints
- job_name: kubernetes-service-endpoints-slow
  job_name: prometheus-pushgateway
- job_name: kubernetes-services
- job_name: kubernetes-pods
- job_name: kubernetes-pods-slow

Mixerless验证

1 podinfo

1.1 部署

使用如下命令部署本系列的示例应用podinfo

kubectl --kubeconfig "$USER_CONFIG" apply -f $PODINFO_SRC/kustomize/deployment.yaml -n test
kubectl --kubeconfig "$USER_CONFIG" apply -f $PODINFO_SRC/kustomize/service.yaml -n test

1.2 生成负载

使用如下命令请求podinfo,以产生监控指标数据

podinfo_pod=$(k get po -n test -l app=podinfo -o jsonpath={.items..metadata.name})
for i in {1..10}; do
   kubectl --kubeconfig "$USER_CONFIG" exec $podinfo_pod -c podinfod -n test -- curl -s podinfo:9898/version
  echo
done

2 确认生成(Envoy)

本系列重点关注的监控指标项是istio_requests_totalistio_request_duration。首先,我们在envoy容器内确认这些指标已经生成。

2.1 istio_requests_total

使用如下命令请求envoy获取stats相关指标数据,并确认包含istio_requests_total

kubectl --kubeconfig "$USER_CONFIG" exec $podinfo_pod -n test -c istio-proxy -- curl -s localhost:15090/stats/prometheus | grep istio_requests_total

返回结果信息如下:

:::: istio_requests_total ::::
# TYPE istio_requests_total counter
istio_requests_total{response_code="200",reporter="destination",source_workload="podinfo",source_workload_namespace="test",source_principal="spiffe://cluster.local/ns/test/sa/default",source_app="podinfo",source_version="unknown",source_cluster="c199d81d4e3104a5d90254b2a210914c8",destination_workload="podinfo",destination_workload_namespace="test",destination_principal="spiffe://cluster.local/ns/test/sa/default",destination_app="podinfo",destination_version="unknown",destination_service="podinfo.test.svc.cluster.local",destination_service_name="podinfo",destination_service_namespace="test",destination_cluster="c199d81d4e3104a5d90254b2a210914c8",request_protocol="http",response_flags="-",grpc_response_status="",connection_security_policy="mutual_tls",source_canonical_service="podinfo",destination_canonical_service="podinfo",source_canonical_revision="latest",destination_canonical_revision="latest"} 10

istio_requests_total{response_code="200",reporter="source",source_workload="podinfo",source_workload_namespace="test",source_principal="spiffe://cluster.local/ns/test/sa/default",source_app="podinfo",source_version="unknown",source_cluster="c199d81d4e3104a5d90254b2a210914c8",destination_workload="podinfo",destination_workload_namespace="test",destination_principal="spiffe://cluster.local/ns/test/sa/default",destination_app="podinfo",destination_version="unknown",destination_service="podinfo.test.svc.cluster.local",destination_service_name="podinfo",destination_service_namespace="test",destination_cluster="c199d81d4e3104a5d90254b2a210914c8",request_protocol="http",response_flags="-",grpc_response_status="",connection_security_policy="unknown",source_canonical_service="podinfo",destination_canonical_service="podinfo",source_canonical_revision="latest",destination_canonical_revision="latest"} 10

2.2 istio_request_duration

使用如下命令请求envoy获取stats相关指标数据,并确认包含istio_request_duration

kubectl --kubeconfig "$USER_CONFIG" exec $podinfo_pod -n test -c istio-proxy -- curl -s localhost:15090/stats/prometheus | grep istio_request_duration

返回结果信息如下:

:::: istio_request_duration ::::
# TYPE istio_request_duration_milliseconds histogram
istio_request_duration_milliseconds_bucket{response_code="200",reporter="destination",source_workload="podinfo",source_workload_namespace="test",source_principal="spiffe://cluster.local/ns/test/sa/default",source_app="podinfo",source_version="unknown",source_cluster="c199d81d4e3104a5d90254b2a210914c8",destination_workload="podinfo",destination_workload_namespace="test",destination_principal="spiffe://cluster.local/ns/test/sa/default",destination_app="podinfo",destination_version="unknown",destination_service="podinfo.test.svc.cluster.local",destination_service_name="podinfo",destination_service_namespace="test",destination_cluster="c199d81d4e3104a5d90254b2a210914c8",request_protocol="http",response_flags="-",grpc_response_status="",connection_security_policy="mutual_tls",source_canonical_service="podinfo",destination_canonical_service="podinfo",source_canonical_revision="latest",destination_canonical_revision="latest",le="0.5"} 10

istio_request_duration_milliseconds_bucket{response_code="200",reporter="destination",source_workload="podinfo",source_workload_namespace="test",source_principal="spiffe://cluster.local/ns/test/sa/default",source_app="podinfo",source_version="unknown",source_cluster="c199d81d4e3104a5d90254b2a210914c8",destination_workload="podinfo",destination_workload_namespace="test",destination_principal="spiffe://cluster.local/ns/test/sa/default",destination_app="podinfo",destination_version="unknown",destination_service="podinfo.test.svc.cluster.local",destination_service_name="podinfo",destination_service_namespace="test",destination_cluster="c199d81d4e3104a5d90254b2a210914c8",request_protocol="http",response_flags="-",grpc_response_status="",connection_security_policy="mutual_tls",source_canonical_service="podinfo",destination_canonical_service="podinfo",source_canonical_revision="latest",destination_canonical_revision="latest",le="1"} 10
...

3 确认采集(Prometheus)

最后,我们验证Envoy生成的监控指标数据,是否被Prometheus实时采集上来。对外暴露Prometheus服务,并使用浏览器请求该服务。然后在查询框输入istio_requests_total,得到结果如下图所示。

728223d4754ad0b162549d34e9ceeae8.png

目录
相关文章
|
6月前
|
Kubernetes Cloud Native 测试技术
使用ASM流量泳道的全链路灰度发布实践
服务网格ASM实现全链路灰度发布:通过流量泳道隔离不同版本环境,配置虚拟服务实现灰度比例控制。从创建泳道、打标签、部署新版本到灰度切流、最终上线及下线旧版。
|
负载均衡 测试技术 数据处理
阿里云服务网格ASM的流量标签及路由功能之(4): 基于ASM实现全链路灰度发布
当您需要在多个服务间实现全链路的灰度发布时,可以通过配置TrafficLabel来识别流量特征,将网关入口流量分为正常流量和灰度流量。灰度流量特征会在请求调用链经过的各个服务间进行传递,从而实现全链路灰度发布。本文介绍如何通过TrafficLabel能力来实现微服务的全链路灰度发布。
425 0
阿里云服务网格ASM的流量标签及路由功能之(4): 基于ASM实现全链路灰度发布
|
测试技术 Serverless
使用ASM管理Knative服务(5):在Knative on ASM中基于流量灰度发布服务
Knative on ASM提供了基于流量的灰度发布能力。当创建Knative服务时,Knative会自动为服务创建第一个修订版本Revision。此后当Knative服务的配置发生变化时,Knative都会创建一个新的修订版本。通过修改流量发往不同修订版本的分配比例,即可实现灰度发布功能。本文介绍如何在Knative on ASM中基于流量灰度发布服务。
242 0
使用ASM管理Knative服务(5):在Knative on ASM中基于流量灰度发布服务
|
Rust Kubernetes 负载均衡
【服务网格】eBPF 和 Wasm:探索服务网格数据平面的未来
【服务网格】eBPF 和 Wasm:探索服务网格数据平面的未来
|
Web App开发 弹性计算 Kubernetes
全景剖析阿里云容器网络数据链路(六):ASM Istio
本篇文章主要聚焦在ASM Istio服务网格模式下,被注入pod的数据面流量转发链路情况。istio灵活注入实现了在Pod维度对流量的定制化配置和观测性,带来了业务链路角度实现的更多种的可能。
全景剖析阿里云容器网络数据链路(六):ASM Istio
|
Web App开发 弹性计算 Kubernetes
全景剖析阿里云容器网络数据链路(六)—— ASM Istio
近几年,企业基础设施云原生化的趋势越来越强烈,从最开始的IaaS化到现在的微服务化,客户的颗粒度精细化和可观测性的需求更加强烈。容器网络为了满足客户更高性能和更高的密度,也一直在高速的发展和演进中,这必然对客户对云原生网络的可观测性带来了极高的门槛和挑战。为了提高云原生网络的可观测性,同时便于客户和前后线同学增加对业务链路的可读性,ACK产研和AES联合共建,合作开发ack net-exporter和云原生网络数据面可观测性系列,帮助客户和前后线同学了解云原生网络架构体系,简化对云原生网络的可观测性的门槛,优化客户运维和售后同学处理疑难问题的体验 ,提高云原生网络的链路的稳定性。
605 0
全景剖析阿里云容器网络数据链路(六)—— ASM Istio
|
存储 Kubernetes 测试技术
[10.25 深圳 WorkShop] 「动手实践」ASM服务网格全链路灰度发布
阿里云 ASM 服务网格 全链路灰度发布实践
342 0
|
Prometheus 监控 Cloud Native
Flagger on ASM——基于Mixerless Telemetry实现渐进式灰度发布系列 3 渐进式灰度发布
作为CNCF[成员](https://landscape.cncf.io/card-mode?category=continuous-integration-delivery&grouping=category&selected=weave-flagger),[Weave Flagger](flagger.app)提供了持续集成和持续交付的各项能力。Flagger将渐进式发布总结为3类: - **灰度发布/金丝雀发布(Canary)**:用于渐进式切流到灰度版本(progressive traffic shifting) - **A/B测试(A/B Testing)**:用于根据请求信息将
639 0
Flagger on ASM——基于Mixerless Telemetry实现渐进式灰度发布系列 3 渐进式灰度发布
|
XML 运维 Prometheus
Flagger on ASM——基于Mixerless Telemetry实现渐进式灰度发布系列 2 应用级扩缩容
应用级扩缩容是相对于运维级而言的。像监控CPU/内存的利用率就属于应用无关的纯运维指标,针对这种指标进行扩缩容的HPA配置就是运维级扩缩容。而像请求数量、请求延迟、P99分布等指标就属于应用相关的,或者叫业务感知的监控指标。 本篇将介绍3种应用级监控指标在HPA中的配置,以实现应用级自动扩缩容。
541 0
Flagger on ASM——基于Mixerless Telemetry实现渐进式灰度发布系列 2 应用级扩缩容
|
6月前
|
Oracle 关系型数据库
oracle asm 磁盘显示offline
oracle asm 磁盘显示offline
328 2
下一篇
无影云桌面