我在 OpenShift 上尝试了渐进式交付!(应用 Argo Rollouts 高级篇 – 与 Prometheus 的度量指标进行协同)

背景 – Background

由于本文是以下文章的延续,请查阅以下文章了解背景信息。
在OpenShift上尝试进行渐进式部署!(基础篇-使用 Argo Rollouts CLI)
在OpenShift上尝试进行渐进式部署!(基本篇-使用 Argo Rollouts GUI)

前提 (in Chinese)

    以下の記事に記載されている手順でArgo Rolloutsの導入が完了していること

尝试使用 OpenShift 进行渐进式交付!(Argo Rollouts CLI 基础教程)

    以下の記事に記載されている手順でOpenShiftクラスターにPrometheus Operatorが導入されていること

我在 OpenShift v4.6 中引入 Prometheus Operator 来进行用户定义项目的监控!

请试试看

切换到验证项目。

只使用Prometheus Operator将OpenShift v4.6中的自定义项目监控,参照“OpenShift v4.6にPrometheus Operatorを導入してユーザー定義プロジェクトのモニタリングに使ってみた!”中的步骤进行验证。

PS D:\git> oc project prometheus-operator
Now using project "prometheus-operator" on server "https://c103-e.us-south.containers.cloud.ibm.com:31989".
PS D:\git>

创建AnalysisTemplate的清单文件

- 以下の設定でAnalysisTemplateのリソースを定義
    - successCondition: 以下のqueryの結果が5回以下
    - provider:prometheus
        - address: [OpenShift v4.6にPrometheus Operatorを導入してユーザー定義プロジェクトのモニタリングに使ってみた!](https://qiita.com/strada/items/23bccc596be587fe003c)の手順で公開したPrometheus Serviceのエンドポイント
        - query: 以下の条件に合致するHTTPリクエストの増分
            - HTTP応答コードが200番以外
            - namespace="kubota-test"のservice="rollout-canary"が対象
apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: failure-count
spec:
  metrics:
  - name: http_error_count
    successCondition: result[0] <= 5
    provider:
      prometheus:
        address: "http://prometheus.prometheus-operator.svc:9090"
        query: |
          delta(http_requests_total{code!~"200",namespace="prometheus-operator",service="rollout-canary"}[5m])

创建Rollout、Service、ServiceMonitor的清单文件。

    • 以下の設定でRolloutのリソースを定義

strategy: canary

steps:

20%をcanaryに振る
一時停止
promoteされたらfailure-countのAnalysisTemplateの分析を実行
成功したら40%をcanaryに振る
40秒待機
60%をcanaryに振る
20秒待機
80%をcanaryに振る
20秒待機
100%をcanaryに振り、Rollout完了し、canary->stableになる。

# This example demonstrates a Rollout using the canary update strategy with a customized rollout
# plan. The prescribed steps initially sets a canary weight of 20%, then pauses indefinitely. Once
# resumed, the rollout performs a gradual, automated 20% weight increase until it reaches 100%.
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: rollout-canary
spec:
  replicas: 5
  revisionHistoryLimit: 2
  selector:
    matchLabels:
      app: rollout-canary
  template:
    metadata:
      labels:
        app: rollout-canary
    spec:
      containers:
      - name: rollouts-demo
        image: quay.io/brancz/prometheus-example-app:v0.2.0
        imagePullPolicy: Always
        ports:
        - containerPort: 8080
  strategy:
    canary:
      steps:
      - setWeight: 20
      # The following pause step will pause the rollout indefinitely until manually resumed.
      # Rollouts can be manually resumed by running `kubectl argo rollouts promote ROLLOUT`
      - pause: {}
      - analysis:
          templates:
          - templateName: failure-count
      - setWeight: 40
      - pause: {duration: 40s}
      - setWeight: 60
      - pause: {duration: 20s}
      - setWeight: 80
      - pause: {duration: 20s}
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: rollout-canary
  name: rollout-canary
spec:
  ports:
  - port: 8080
    protocol: TCP
    targetPort: 8080
    name: web
  selector:
    app: rollout-canary
  type: ClusterIP
---
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  labels:
    team: frontend
    k8s-app: rollout-canary
  name: rollout-canary
spec:
  endpoints:
  - interval: 30s
    port: web
    scheme: http
  selector:
    matchLabels:
      app: rollout-canary

应用清单文件

PS D:\git> oc apply -f .\prometheus-anlysis-template.yaml
analysistemplate.argoproj.io/failure-count created
PS D:\git> oc apply -f .\rollout-canary.yaml
rollout.argoproj.io/rollout-canary created
service/rollout-canary created
servicemonitor.monitoring.coreos.com/rollout-canary created
PS D:\git>

启动UI仪表板

PS D:\git> docker run -p 3100:3100 -v C:\Users\YASUYUKIKUBOTA\.kube\config:/.kube/config quay.io/argoproj/kubectl-argo-rollouts:master dashboard --insecure-skip-tls-verify
time="2021-07-13T07:14:38Z" level=info msg="Argo Rollouts Dashboard is now available at localhost 3100"

登录仪表板并显示Rollout。

    localhost:3100にアクセスし、NSで作成した検証用プロジェクトを選択
image.png

首次的推出将在没有分析的情况下完成。

访问示例应用程序

    以下のコマンドを実行し、rollout-canary Serviceの8080ポートをlocalhostに転送
PS D:\git> oc port-forward svc/rollout-canary 8080:8080
Forwarding from 127.0.0.1:8080 -> 8080
Forwarding from [::1]:8080 -> 8080
    localhost:8080/errに2回ほどアクセス

※ 画面上不需要显示任何内容就可以了。

访问Prometheus用户界面

    以下のコマンドを実行し、Prometheus Serviceの9090ポートをlocalhostに転送
PS D:\git> oc port-forward svc/prometheus 9090:9090 -n prometheus-operator
Forwarding from 127.0.0.1:9090 -> 9090
Forwarding from [::1]:9090 -> 9090
    localhost:9090にアクセスし以下のクエリーを実行
http_requests_total{code!~"200",namespace="prometheus-operator",service="rollout-canary"}
image.png

如果能够显示对结果/错误的访问次数,那就可以了。

    AnalysisTemplateで使用する実際のクエリーを実行
delta(http_requests_total{code!~"200",namespace="prometheus-operator",service="rollout-canary"}[5m])
image.png

由于最近5分钟内没有出现404错误的增量,所以应该显示为0。
※如果访问时机恰好是在Prometheus抓取之前或之后,则可能显示为1。

执行Rollout(正常情况下)。

Dashboard(localhost:3100)にアクセスしContainersのrollout-demoのタグをv0.3.0へ変更しRolloutを開始

詳細手順はOpenShiftでProgressive Deliveryやってみた!(Argo Rollouts基本編-GUI)を参照

20%がcanaryに割り振られたところで一時停止したらPROMOTEをクリック

image.png
    以下のようにAnalysis Runが成功し、しばらくするとRolloutが完了
image.png

进行Rollout(在分析中失败并自动回滚)。

image.png
delta(http_requests_total{code!~"200",namespace="prometheus-operator",service="rollout-canary"}[5m])
image.png

如果此查询的结果不超过5,则分析运行成功,并确认结果是否超过了6。

    Dashboard(localhost:3100)にアクセスしPROMOTEをクリックするとAnalysis Runが失敗する
image.png
image.png

总结

我通过在 Argo Rollouts 的 AnalysisTemplate 中指定 Prometheus 的查询,并根据获取的结果决定是否自动推进 Rollout 或中止它的能力已经得到证实。然而,这次尝试也揭示了以下问题。

    • Argo RolloutsがPrometheusの認証なしHTTPエンドポイントにしか対応していないため、OpenShift v4.6のユーザー定義プロジェクトのモニタリングとは連携できないので別途Prometheus Operatorの導入が必要

 

    • PrometheusのメトリクスはcanaryのPodのみから取得したいがクエリーで選別する方法が不明

ServiceMonitorではなくPodMonitorを使用すれば解決する?

为了在实际场景中使用,必须解决这些问题,但至少确认了基本操作,所以如果有对这个领域感兴趣的客户,我将积极提出建议。

广告
将在 10 秒后关闭
bannerAds