我研究了Tanzu Service Mesh的自动缩放功能的用户界面和清单的区别

2 年 ago
文, 翔
2 minutes

Tanzu Service Mesh（以下简称TSM）提供了自动伸缩功能，可以根据负载自动扩展Pod数量。（官方文档请参考此处）
有三种设置方法供选择。

    1. 将设置从用户界面(UI)转换为GNS单位

 

    1. 将设置从API转换为GNS单位

 

    将设置从清单文件(Manifest)转换为集群内设定

※GNS：全局命名空间。TSM 在跨集群的命名空间中具有独特的功能。

在这里，我们将确认如何从UI界面和清单文件进行设置，并一起查看其差异。
同时，也要轻松确认与Kubernetes标准附带的自动扩展资源HPA的区别。

在用户界面中设置自动缩放。

1690767681719.png
項目意味Autoscaling Policy Nameポリシー名。2-30文字で小文字と数字とハイフンが利用可能。GNS Scope対象となるGNSTarget Service対象となるkind: Serviceオブジェクト。デプロイ済みServiceは選択できるが、デプロイしていないものは入力して追加する。Service VersionServiceのバージョン。バージョンの概念はこちら参照。Autoscaling Modeオートスケーリングのモード。パフォーマンス優先(Scale Downを認めない)の場合はPerformanceを選択し、リソースの効率活用を優先する場合はEfficiencyを選択する。Autoscaling Metricオートスケールに使用するメトリックを指定し、メトリクスの平均値を算出する際のメトリクス取得秒数(60-3600秒の間、windowSecondsに該当)も指定する。メトリックは以下から選択可能

  • RPS
  • リクエスト数
  • CPU利用率(％)
  • CPU利用量(コア数))
  • メモリ使用量(Bytes)
  • メモリ使用率(％)
  • p50 Latency
  • p90 Latency
  • p99 Latency

Scale-up Conditionスケールアップに使用する閾値Max. Instance Count最大Pod数Scale-down Condition※Efficiencyモードの時のみ入力スケールダウンする条件を設定。スケールアップの閾値より大きい値は指定できない。Min. Instance Count※Efficiencyモードの時のみ入力最小Pod数Scaling Methodスケーリングの方法を定義する。

  • Default Autoscaling: 計算式に基づいてPod数を決める
  • Stepped Autoscaling: 条件を満たした後、指定したスケールアップ数、スケールダウン数に基づいてPod数を増減する

TSMではステートレスなサービスの場合はDefaultを用い、ライセンスコストやストレージコストなどを気にする場合はstepを使うことを推奨している。

Panic Modeメトリクスが取得できなかったり、オートスケーラーがインスタンス数を計算出来なかったりした場合の振る舞いを指定する。

  • Do Not Scale Services: 何もしない
  • Scale to <指定値> instance(s): Pod数が指定値に達していない場合、指定値までスケールアップする

点击“NEXT”后，会询问关于保存策略后的行为方式。

Activate Policy: 保存すると即座にポリシーがデプロイされる

Simualtion Mode Only: シミュレーションモードでデプロイされる

当您选择”下一步”并点击后，会进入最后的确认页面。

1690769947272.png

サンプルをデプロイしてみる。
GNSが対象としているNamespaceに、Serviceを作成し、適切にDeploymentと紐付けられていれば、オートスケールしてくれる。

$ kubectl get pod
NAME                    READY   STATUS    RESTARTS   AGE
nginx-ff6774dc6-2r65z   2/2     Running   0          15m
nginx-ff6774dc6-8kjqh   2/2     Running   0          8m8s
nginx-ff6774dc6-jl8xx   2/2     Running   0          7m8s
nginx-ff6774dc6-s79p6   2/2     Running   0          7m8s
nginx-ff6774dc6-vqws2   2/2     Running   0          7m38s

在Manifest中进行集群内的设置。

在Manifest中可以定义与先前在UI中定义的策略相同的策略。
然而，由于使用Kubernetes资源向集群应用Manifest，无法引入GNS的概念。

ポリシーの定義はkind: Definitionで行う。
kind: Definitionの定義の説明はTanzu Service Mesh Service Autoscaler Configuration Referenceを参照するとよい。
ここでは、サンプルを元にどういった設定項目があるかを説明する。
最初に、scaleTargetRefはオートスケール対象を選択する箇所となる。

  scaleTargetRef:
    kubernetes:
      apiVersion: apps/v1
      kind: Deployment
      name: nginx

apiVersion、kind、nameが全て一致するものを対象とする。
なお、kindは以下を利用することが出来る。

    • Deployment

 

    • ReplicaSet

 

    StatefulSet

Namespaceの指定ができないが、これはkind: Definitionを対象となるオブジェクトと同じNamespaceにデプロイする必要があることを意味する。
また、対象となるオブジェクトが複数存在してはならないと、ドキュメントに記載があるが、CRDとしては重複を禁止していないため注意が必要である。（おそらく意図しないオートスケールの挙動を取る可能性がある）。

次にscaleRuleを見ていく。modeはUIと同じくPERFORMANCEかEFFICIENCYを指定する。それぞれの意味はUIと同じため割愛する。

  scaleRule:
    mode: EFFICIENCY

当enabled为false时，相当于在UI中设置了”Activate Policy”，此时系统将进入仿真模式并进行操作。

    enabled: true

在`instances`中指定Pod的最大和最小数量、以及默认值和扩展方法。如果不指定`stepsDown`和`stepsUp`，将使用默认值（根据资源使用量进行比例扩展）。

    instances:
      min: 1
      max: 5
      default: 3
      stepsDown: 1
      stepsUp: 1

在触发器中，指定了哪个指标超过了多长时间阈值后进行扩缩容的触发部分。gracePeriodSeconds是指在扩容事件发生后，当事件被平息后进行缩容所需的时间间隔。

    trigger:
      gracePeriodSeconds: 200

默认情况下，gracePeriodSeconds的值为300秒，与UI不同，可以将其设置为0以立即进行缩容。对于不经常发生峰值的服务，可能也可以将其设置为0。

在metric部分，通过name参数指定作为自动缩放指标的度量 (CPU/内存使用量)，并使用scaleUP和scaleDown设置度量的阈值。

      metric:
        name: CPUUsageMillicores
        scaleUp: 500
        scaleDown: 100
        windowSeconds: 600

windowSeconds是用来判断是否满足条件的秒数， 默认为600秒，并且根据此时间段的平均值来进行自动缩放。

部署Manifest之后，可以确认以下的规模状态。

$ kubectl get asd
NAMESPACE         NAME           ENABLED   MODE         TRIGGER              MIN   MAX   CURRENT   DESIRED   READY
nginx-autoscale   frontend-asd   true      EFFICIENCY   CPUUsageMillicores   4     6     4         4         true

UI和Manifest之间的区别。

根据我亲自确认的感觉来看，大概有以下简要区别。

比較項目UIManifest対象GNS内のリソースクラスタ内Namespaceのリソーススケールダウン時のGracePeriodSeconds60秒から0秒から変更方法UIからEditを選択して変更Manifestやデプロイ済みオブジェクトを修正
1690798017238.png

与HPA的不同之处。

关于这个问题，在官方FAQ中也有记录。

简单概括一下，

    • アルゴリズムが独自であり、モードが複数あったりスケーリングの猶予期間があったり、UIと組み合わせてSLOが設定できるなど

 

    • 一方で、監視対象はCPU/メモリ/リクエストのみで、type: ExternalなどPrometheus連携みたいな利用はできない

 

    SaaS側にスケーリングの判断を任せているため、コントローラとSaaSとの接続が失われた場合はオートスケーリング出来ない

虽然没有进行详细验证，但从经验上来看，HPA的灵敏度有时不够好，所以我们希望通过算法改进来提高它的独特性。
（在我进行压力测试时，相比HPA，反应感官上更好）。
因此，HPA用户也有可能值得考虑转换，但转换时使用type: External的人要注意。

附录：样本清单

类型：部署

以下是示例样本。

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx
  name: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - image: nginx
        imagePullPolicy: Always
        name: nginx
        ports:
        - containerPort: 80
          protocol: TCP
      restartPolicy: Always

种类：服务

样品如下。

apiVersion: v1
kind: Service
metadata:
  labels:
    app: nginx
  name: nginx
spec:
  ports:
  - port: 80
  selector:
    app: nginx

种类：定义

样本如下。

apiVersion: autoscaling.tsm.tanzu.vmware.com/v1alpha1
kind: Definition
metadata:
  name: nginx-asd
  labels: 
    app: nginx-asd
spec:
  scaleTargetRef:
    kubernetes:
      apiVersion: apps/v1
      kind: Deployment
      name: nginx
  scaleRule:
    mode: EFFICIENCY
    enabled: true
    instances:
      min: 1
      max: 5
      default: 3
      stepsDown: 1
      stepsUp: 1
    trigger:
      gracePeriodSeconds: 200
      metric:
        name: CPUUsageMillicores
        scaleUp: 500
        scaleDown: 100
        windowSeconds: 600
bannerAds