基于阿里云托管服务网格ASM完成应用全自动化渐进式发布的GitOps解决方案实践

本文涉及的产品
容器服务 Serverless 版 ACK Serverless,952元额度 多规格
容器镜像服务 ACR,镜像仓库100个 不限时长
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
简介: 简介 ASM ASM当前处于公测阶段,欢迎扫码入群进一步交流: 阿里云服务网格(Alibaba Cloud Service Mesh,简称 ASM)提供了一个全托管式的服务网格平台,兼容于社区 Istio 开源服务网格,用于简化服务的治理,包括服务调用之间的流量路由与拆分管理、服务间通信的认证安全以及网格可观测性能力,从而极大地减轻开发与运维的工作负担。

photo_1507235071172_438ca6950a8e_gaitubao_1000x749

简介

ASM

ASM当前处于公测阶段,欢迎扫码入群进一步交流:
dingding.png

阿里云服务网格(Alibaba Cloud Service Mesh,简称 ASM)提供了一个全托管式的服务网格平台,兼容于社区 Istio 开源服务网格,用于简化服务的治理,包括服务调用之间的流量路由与拆分管理、服务间通信的认证安全以及网格可观测性能力,从而极大地减轻开发与运维的工作负担。ASM的架构示意图如下:
asm_arch.png
ASM 定位于混合云、多云、多集群、非容器应用迁移等核心场景中,构建托管式统一的服务网格能力,能够为阿里云用户提供以下功能:

  • 一致的管理方式
    以一致的方式来管理运行于 ACK 托管 Kubernetes 集群、专有 Kubernetes 集群、ServerlessKubernetes 集群、混合云或多云场景下的接入集群上的应用服务,从而提供一致的可观测性和流量控制
  • 统一的流量管理
    支持容器或者虚拟机混合环境下统一的流量管理
  • 控制平面核心组件托管化
    托管控制平面的核心组件,最大限度地降低用户资源开销和运维成本

ArgoCD

ArgoCD是一个用于持续交付的Kubernetes配置管理工具。Argo CD 遵循 GitOps 模式,监听当前运行中应用的状态并与Git Repository中声明的状态进行比对,并自动将更新部署到环境中。ArgoCD的架构示意图如下:
argocd-arch.png

Flagger

Flagger是一个用于全自动化渐进式完成应用发布的Kubernetes operator,它通过分析Prometheus收集到的监控指标并通过Istio、App Mesh等流量管理技术或工具完成应用的渐进式发布。架构示意图如下:
flagger-arch.png

创建ASM实例

参考ASM帮助文档创建ASM实例并添加mesh01和mesh02 2个ACK集群:
asm-instance.png

部署入口网关服务到mesh01集群:
ingressgateway.png
ingressgateway.png

在控制平面创建一个命名空间test:
asm-controllpanel.png

在控制平面创建一个Gateway:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: public-gateway
  namespace: istio-system
spec:
  selector:
    istio: ingressgateway
  servers:
    - port:
        number: 80
        name: http
        protocol: HTTP
      hosts:
        - "*"

asm-gateway.png
asm-gateway.png

部署Flagger

分别在mesh1和mesh2 2个ACK集群上按照以下步骤部署Flagger及其依赖组件:

部署Prometheus

$ kubectl apply -k github.com/haoshuwei/argocd-samples/flagger/prometheus/

部署Flagger

使用ASM实例的kubeconfig创建secret:

$ kubectl -n istio-system create secret generic istio-kubeconfig --from-file kubeconfig
$ kubectl -n istio-system label secret istio-kubeconfig  istio/multiCluster=true

helm安装Flagger:

$ helm repo add flagger https://flagger.app
$ helm repo update
$ kubectl apply -f https://raw.githubusercontent.com/weaveworks/flagger/master/artifacts/flagger/crd.yaml
$ helm upgrade -i flagger flagger/flagger --namespace=istio-system --set crd.create=false --set meshProvider=istio --set metricsServer=http://prometheus:9090 --set istio.kubeconfig.secretName=istio-kubeconfig --set istio.kubeconfig.key=kubeconfig

部署Grafana

$ helm upgrade -i flagger-grafana flagger/grafana --namespace=istio-system --set url=http://prometheus:9090

我们可以在ASM实例的控制面板上创建grafana服务的虚拟服务来供外部访问:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: grafana
  namespace: istio-system
spec:
  hosts:
    - "grafana.istio.example.com"
  gateways:
    - public-gateway.istio-system.svc.cluster.local
  http:
    - route:
        - destination:
            host: flagger-grafana

grafana-gateway.png

访问服务:
grafana-view.png

创建命名空间并添加标签

$ kubectl create ns test
$ kubectl label namespace test istio-injection=enabled

部署ArgoCD

我们可以选择任意一个ACK集群部署ArgoCD
部署ArgoCD Server:

$ kubectl create namespace argocd
$ kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

部署ArgoCD CLI:

$ VERSION=$(curl --silent "https://api.github.com/repos/argoproj/argo-cd/releases/latest" | grep '"tag_name"' | sed -E 's/.*"([^"]+)".*/\1/')
$ curl -sSL -o /usr/local/bin/argocd https://github.com/argoproj/argo-cd/releases/download/$VERSION/argocd-linux-amd64
$ chmod +x /usr/local/bin/argocd

获取和修改登录密码:

$ kubectl get pods -n argocd -l app.kubernetes.io/name=argocd-server -o name | cut -d'/' -f 2
$ argocd login ip:port
$ argocd account update-password

访问服务:
argocd-view.png

完成应用全自动化渐进式发布的GitOps流程示例

ArgoCD添加集群并部署应用

在这个示例中,我们将会把示例应用podinfo部署到mesh02集群,把loadtester测试应用部署到mesh01集群,统一部署在test命名空间下。
添加Git Repository https://github.com/haoshuwei/gitops-demo.git到ArgoCD:

$ argocd repo add https://github.com/haoshuwei/argocd-samples.git--name argocd-samples
repository 'https://github.com/haoshuwei/argocd-samples.git' added
$ argocd repo list
TYPE  NAME         REPO                                          INSECURE  LFS    CREDS  STATUS      MESSAGE
git   argocd-samples  https://github.com/haoshuwei/argocd-samples.git  false     false  false  Successful

使用kubeconfig添加mesh01和mesh02 2个集群到ArgoCD:

$ argocd cluster add mesh01 --kubeconfig=mesh01
INFO[0000] ServiceAccount "argocd-manager" created in namespace "kube-system"
INFO[0000] ClusterRole "argocd-manager-role" created
INFO[0000] ClusterRoleBinding "argocd-manager-role-binding" created
$ argocd cluster add mesh02 --kubeconfig=mesh02
INFO[0000] ServiceAccount "argocd-manager" created in namespace "kube-system"
INFO[0000] ClusterRole "argocd-manager-role" created
INFO[0000] ClusterRoleBinding "argocd-manager-role-binding" created
$ argocd cluster list |grep mesh
https://xx.xx.xxx.xx:6443       mesh02   1.16+    Successful
https://xx.xxx.xxx.xx:6443      mesh01   1.16+    Successful

部署应用podinfomesh02集群:

$ argocd app create --project default --name podinfo --repo https://github.com/haoshuwei/argocd-samples.git --path flagger/podinfo --dest-server https://xx.xx.xxx.xx:6443 --dest-namespace test --revision latest --sync-policy automated

以上命令行做的事情是创建一个应用podinfo,这个应用的Git Repository源是https://github.com/haoshuwei/gitops-demo.git 项目flagger/podinfo子目录下的文件,分支为latest,应用部署到https://xx.xx.xxx.xx:6443集群的test命名空间下,应用的同步策略是automated

flagger/podinfo 子目录下包括4个编排文件deployment.yaml hpa.yaml kustomization.yamlcanary.yaml,其中canary.yaml文件就是我们这个示例中完成应用全自动化渐进式金丝雀发布的核心编排文件,内容如下:

apiVersion: flagger.app/v1beta1
kind: Canary
metadata:
  name: podinfo
  namespace: test
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: podinfo
  progressDeadlineSeconds: 60
  autoscalerRef:
    apiVersion: autoscaling/v2beta1
    kind: HorizontalPodAutoscaler
    name: podinfo
  service:
    port: 9898
    gateways:
    - public-gateway.istio-system.svc.cluster.local
    hosts:
    - app.istio.example.com
    trafficPolicy:
      tls:
        # use ISTIO_MUTUAL when mTLS is enabled
        mode: DISABLE
  analysis:
    interval: 30s
    threshold: 10
    maxWeight: 50
    stepWeight: 5
    metrics:
    - name: request-success-rate
      threshold: 99
      interval: 30s
    - name: request-duration
      threshold: 500
      interval: 30s
    webhooks:
      - name: load-test
        url: http://loadtester.test/
        timeout: 5s
        metadata:
          cmd: "hey -z 1m -q 10 -c 2 http://podinfo-canary.test:9898/"

canary.yaml文件中定义了以下几个关键部分

spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: podinfo
  progressDeadlineSeconds: 60
  autoscalerRef:
    apiVersion: autoscaling/v2beta1
    kind: HorizontalPodAutoscaler
    name: podinfo

以上字段表示这个canary资源会监听和引用名为podinfo的deployments资源和HorizontalPodAutoscaler资源。

service:
    port: 9898
    gateways:
    - public-gateway.istio-system.svc.cluster.local
    hosts:
    - app.istio.example.com
    trafficPolicy:
      tls:
        # use ISTIO_MUTUAL when mTLS is enabled
        mode: DISABLE

以上字段表示canary资源会在ASM控制面板自动为podinfo应用创建虚拟服务,名字也是podinfo

analysis:
    interval: 30s
    threshold: 5
    maxWeight: 50
    stepWeight: 5
    metrics:
    - name: request-success-rate
      threshold: 99
      interval: 30s
    - name: request-duration
      threshold: 500
      interval: 30s
    webhooks:
      - name: load-test
        url: http://loadtester.test/
        timeout: 5s
        metadata:
          cmd: "hey -z 1m -q 10 -c 2 http://podinfo-canary.test:9898/"

以上字段表示我们在发布新版本podinfo应用时,要先对新版本应用做一些测试和分析,
interval: 30s, 每隔30s测试一次
threshold: 5, 失败次数超过5次则认为失败
maxWeight: 50, 流量权重最大可以切换到50
stepWeight: 5, 每次增加权重为5
metrics中定义了2种指标,
request-success-rate 请求成功率不能小于99
request-duration RT均值不能大于500ms
用来生成测试任务的则定义在webhooks字段。

部署测试应用loadtestermesh01集群:

$ argocd app create --project default --name loadtester --repo https://github.com/haoshuwei/argocd-samples.git --path flagger/charts/loadtester --dest-server https://xx.xxx.xxx.xx:6443 --dest-namespace test --revision latest --sync-policy automated

以上应用创建完成后,由于我们设置的sync策略为自动部署,所以应用会自动部署到mesh01和mesh02集群中,我们可以在ArgoCD页面上查看应用详细信息:
argocd-app.png
podinfo详情:
podinfo.png
loadtester详情:
loadtester.png

在ASM的控制面板我们可以查看flagger动态创建的虚拟服务和目标规则:
podinfo-vs.png
podinfo-rules.png

访问服务:
podinfo-view.png

GitOps自动发布

新建分支修改应用容器镜像版本提交,并创建指向latest分支的PullRequest:
github-pr.png

管理员审批并merge pr后,latest分支有新代码进入,ArgoCD会自动把更新同步集群环境中,flagger检测到podinfo应用有新版本变更,则开始自动化渐进式地发布新版本应用,通过以下命令可以查看应用发布进度:

$ watch kubectl get canaries --all-namespaces
Every 2.0s: kubectl get canaries --all-namespaces                                                                                                         Tue Mar 17 19:04:20 2020

NAMESPACE   NAME      STATUS        WEIGHT   LASTTRANSITIONTIME
test        podinfo   Progressing   10       2020-03-17T11:04:01Z

访问应用可以看到有流量切换到新版本上:
podinfo.png

同时我们也可以在grafana面板中查看到新版本测试指标情况:
grafana.png

整个发布过程的messages输出如下:

"msg":"New revision detected! Scaling up podinfo.test","canary":"podinfo.test"
"msg":"Starting canary analysis for podinfo.test","canary":"podinfo.test"
"msg":"Advance podinfo.test canary weight 5","canary":"podinfo.test"
"msg":"Advance podinfo.test canary weight 10","canary":"podinfo.test"
"msg":"Advance podinfo.test canary weight 15","canary":"podinfo.test"
"msg":"Advance podinfo.test canary weight 20","canary":"podinfo.test"
"msg":"Advance podinfo.test canary weight 25","canary":"podinfo.test"
"msg":"Advance podinfo.test canary weight 30","canary":"podinfo.test"
"msg":"Advance podinfo.test canary weight 35","canary":"podinfo.test"
"msg":"Advance podinfo.test canary weight 40","canary":"podinfo.test"
"msg":"Advance podinfo.test canary weight 45","canary":"podinfo.test"
"msg":"Advance podinfo.test canary weight 50","canary":"podinfo.test"
"msg":"Copying podinfo.test template spec to podinfo-primary.test","canary":"podinfo.test"
"msg":"Halt advancement podinfo-primary.test waiting for rollout to finish: 3 of 4 updated replicas are available","canary":"podinfo.test"
"msg":"Routing all traffic to primary","canary":"podinfo.test"
"msg":"Promotion completed! Scaling down podinfo.test","canary":"podinfo.test"

应用发布完毕后,所有流量切换到新版本上:
podinfo.png

若新版本应用测试指标不达标,则应用自动回滚到初始稳定状态:

"msg":"New revision detected! Scaling up podinfo.test","canary":"podinfo.test"
"msg":"Starting canary analysis for podinfo.test","canary":"podinfo.test"
"msg":"Advance podinfo.test canary weight 10","canary":"podinfo.test"
"msg":"Halt advancement no values found for istio metric request-success-rate probably podinfo.test is not receiving traffic","canary":"podinfo.test"
"msg":"Halt advancement no values found for istio metric request-duration probably podinfo.test is not receiving traffic","canary":"podinfo.test"
"msg":"Halt advancement no values found for istio metric request-duration probably podinfo.test is not receiving traffic","canary":"podinfo.test"
"msg":"Halt advancement no values found for istio metric request-duration probably podinfo.test is not receiving traffic","canary":"podinfo.test"
"msg":"Halt advancement no values found for istio metric request-duration probably podinfo.test is not receiving traffic","canary":"podinfo.test"
"msg":"Synced test/podinfo"
"msg":"Rolling back podinfo.test failed checks threshold reached 5","canary":"podinfo.test"
"msg":"Canary failed! Scaling down podinfo.test","canary":"podinfo.test"

参考资料

https://medium.com/google-cloud/automated-canary-deployments-with-flagger-and-istio-ac747827f9d1
https://docs.flagger.app/
https://docs.flagger.app/dev/upgrade-guide#istio-telemetry-v2
https://github.com/weaveworks/flagger
[](https://help.aliyun.com/document_detail/149550.html)

目录
相关文章
|
4月前
|
运维 监控 Kubernetes
kubevela可观测体系问题之KubeVela 的面向应用监控界面的问题如何解决
kubevela可观测体系问题之KubeVela 的面向应用监控界面的问题如何解决
|
4月前
|
Prometheus 运维 监控
kubevela可观测体系问题之KubeVela的用户在描述应用时加入可观测的配置的问题如何解决
kubevela可观测体系问题之KubeVela的用户在描述应用时加入可观测的配置的问题如何解决
|
4月前
|
运维 Prometheus Kubernetes
kubevela可观测体系问题之KubeVela 的可观测性能力通过插件机制进行扩展的问题如何解决
kubevela可观测体系问题之KubeVela 的可观测性能力通过插件机制进行扩展的问题如何解决
|
4月前
|
Cloud Native 测试技术 开发者
阿里云服务网格ASM多集群实践(二):高效按需的应用多环境部署与全链路灰度发布
介绍服务网格ASM提出的一种多集群部署下的多环境部署与全链路灰度发布解决方案。
|
运维 Kubernetes Cloud Native
应用纳管和灰度发布:谐云基于 KubeVela 的企业级云原生实践
谐云通过类比事务的方式,将渲染过程分为正向和逆向,同时将首次纳管和真正的纳管动作进行了分离,完成了平台升级的同时,给应用的纳管行为留下了一定的可操作空间。
应用纳管和灰度发布:谐云基于 KubeVela 的企业级云原生实践
|
自然语言处理 运维 监控
《云原生架构容器&微服务优秀案例集》——01 互联网——站酷 基于 ASM 解决多语言技术栈下服务管理难题,实现运维提效
《云原生架构容器&微服务优秀案例集》——01 互联网——站酷 基于 ASM 解决多语言技术栈下服务管理难题,实现运维提效
240 0
|
运维 Kubernetes Cloud Native
利用 Rainbond 云原生平台简化 Kubernetes 业务问题排查
Kubernetes 已经成为了云原生时代基础设施的事实标准,越来越多的应用系统在 Kubernetes 环境中运行。Kubernetes 已经依靠其强大的自动化运维能力解决了业务系统的大多数运行维护问题,然而还是要有一些状况是需要运维人员去手动处理的。那么和传统运维相比,面向 Kubernetes 解决业务运维问题是否有一些基本思路,是否可以借助其他工具简化排查流程,就是今天探讨的主题。
|
运维 Kubernetes Cloud Native
|
Kubernetes 安全 Cloud Native
Kubernetes 多集群管理平台 OCM v0.9.0 发布:进一步改善托管集群安全性问题
随着 OpenClusterManagement(OCM)项目的持续发展,我们觉得有必要周期性向大家同步近期项目的一些进展了,包括我们我们下一步未来发展的方向以及作为贡献者如何参与进来我们的社区。2022 年的尾声即将到来,让我们来进一步看一下项目研发方面的新内容吧!