2.5. 根据自定义指标自动扩展 pod

作为开发人员，您可以使用自定义指标自动扩展来指定 OpenShift Container Platform 如何根据不基于 CPU 或内存的自定义指标自动增加或减少部署、有状态集、自定义资源或作业的数量。

Custom Metrics Autoscaler Operator for Red Hat OpenShift 是一个可选的 operator，它基于 Kubernetes Event Driven Autoscaler (KEDA)，它允许使用 pod 指标以外的其他指标源进行扩展工作负载。

注意

自定义指标自动扩展目前仅支持 Prometheus、CPU、内存和 Apache Kafka 指标。

重要

自定义指标自动扩展只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议（SLA）支持，且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能，并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的更多信息，请参阅技术预览功能支持范围。

2.5.1. 自定义 Metrics Autoscaler Operator 发行注记

Red Hat Openshift 的自定义 Metrics Autoscaler Operator 发行注记介绍了新的功能和增强功能、已弃用的功能以及已知的问题。

Custom Metrics Autoscaler Operator 使用基于 Kubernetes 的 Event Driven Autoscaler (KEDA)，并基于 OpenShift Container Platform 横向自动扩展(HPA)构建。

注意

Custom Metrics Autoscaler Operator for Red Hat OpenShift 作为可安装的组件提供，它与 OpenShift Container Platform 核心不同。Red Hat OpenShift Container Platform 生命周期政策概述了发行版本兼容性。

2.5.1.1. 支持的版本

下表为每个 OpenShift Container Platform 版本定义自定义 Metrics Autoscaler Operator 版本。

VersionOpenShift Container Platform 版本公开发行（GA）

2.8.2-174

4.12

技术预览

2.8.2-174

4.11

技术预览

2.8.2-174

4.10

技术预览

2.5.1.2. 自定义 Metrics Autoscaler Operator 2.8.2-174 发行注记

此自定义 Metrics Autoscaler Operator 2.8.2-174 发行版本为在 OpenShift Container Platform 集群中运行的 Operator 提供了新功能和程序错误修复。Custom Metrics Autoscaler Operator 2.8.2-174 组件在 RHEA-2023:1683 中发布。

重要

自定义 Metrics Autoscaler Operator 目前是一个技术预览功能。

2.5.1.2.1. 新功能及功能增强
2.5.1.2.1.1. Operator 升级支持

现在，您可以从 Custom Metrics Autoscaler Operator 的早期版本升级。有关升级 Operator 的信息，请参阅"添加资源"中的"删除 Operator 更新频道"。

2.5.1.2.1.2. must-gather 支持

现在，您可以使用 OpenShift Container Platform must-gather 工具收集有关自定义 Metrics Autoscaler Operator 及其组件的数据。目前，使用带有自定义 Metrics Autoscaler 的 must-gather 工具的过程与其他 Operator 不同。如需更多信息，请参阅"添加资源"中的调试数据。

2.5.1.3. 自定义 Metrics Autoscaler Operator 2.8.2 发行注记

此自定义 Metrics Autoscaler Operator 2.8.2 发行版本为在 OpenShift Container Platform 集群中运行的 Operator 提供了新功能和程序错误修复。自定义 Metrics Autoscaler Operator 2.8.2 组件在 RHSA-2023:1042 中发布。

重要

自定义 Metrics Autoscaler Operator 目前是一个技术预览功能。

2.5.1.3.1. 新功能及功能增强
2.5.1.3.1.1. 审计日志记录

现在，您可以收集并查看自定义 Metrics Autoscaler Operator 及其相关组件的审计日志。审计日志是安全相关的按时间排序的记录，记录各个用户、管理员或其他系统组件影响系统的一系列活动。

2.5.1.3.1.2. 基于 Apache Kafka 指标扩展应用程序

现在，您可以使用 KEDA Apache kafka 触发器/scaler 根据 Apache Kafka 主题扩展部署。

重要

基于 Apache Kafka 指标的自动缩放是所有自定义 Metrics Autoscaler TP 版本和自定义 Metrics Autoscaler 正式发布版本中的一个技术预览 (TP) 功能。

技术预览功能不受红帽产品服务等级协议（SLA）支持，且功能可能并不完整。红帽不推荐在生产环境中使用它们。

2.5.1.3.1.3. 根据 CPU 指标扩展应用程序

现在，您可以使用 KEDA CPU 触发器/scaler 根据 CPU 指标扩展部署。

2.5.1.3.1.4. 根据内存指标扩展应用程序

现在，您可以使用 KEDA 内存触发器/scaler 根据内存指标扩展部署。

其他资源

2.5.2. 了解自定义指标自动扩展

Custom Metrics Autoscaler Operator 根据特定应用程序的自定义外部指标扩展 pod。您的其他应用程序继续使用其他扩展方法。您可以配置 触发器 （也称为 scaler），这是自定义指标自动扩展器用来决定如何扩展的事件和指标的来源。自定义指标自动扩展使用 metrics API 将外部指标转换为 OpenShift Container Platform 可以使用的形式。自定义指标自动扩展会创建一个执行实际缩放的 pod 横向自动扩展(HPA)。

要使用自定义指标自动扩展，您可以创建一个 ScaledObject 或 ScaledJob 对象，这是定义扩展元数据的自定义资源 (CR)。您可以指定要缩放的部署或作业、要缩放的指标源 (trigger) 以及其他参数，如允许的最小和最大副本数。

注意

您只能为每个您要扩展的工作负载创建一个扩展对象或扩展作业。另外，您不能在同一工作负载中使用扩展的对象或扩展作业以及 pod 横向自动扩展 (HPA)。

自定义指标自动扩展与 HPA 不同，可以缩减为零。如果将自定义指标自动扩展 CR 中的 minReplicaCount 值设置为 0，自定义指标自动扩展会将工作负载从 1 缩减到 0 个副本或从 0 个副本扩展到 1。这称为 激活阶段。扩展至 1 个副本后，HPA 会控制扩展。这称为 扩展阶段。

某些触发器允许您更改由集群指标自动扩展扩展的副本数量。在所有情况下，配置激活阶段的参数始终使用相同的短语，前缀为 激活。例如，如果 threshold 参数配置缩放，则 activationThreshold 将配置激活。通过配置激活和扩展阶段，您可以提高扩展策略的灵活性。例如，您可以配置更高的激活阶段，以便在指标特别低时防止扩展或缩减。

当每个决策不同时，激活值的优先级高于扩展值。例如，如果 threshold 被设置为 10，并且 activationThreshold 为 50，如果指标报告 40，则缩放器不会激活，并且 pod 缩减为零，即使 HPA 需要 4 个实例。

您可以通过查看自定义资源中的 pod 数量或查看自定义 Metrics Autoscaler Operator 日志来验证自动扩展是否已发生： 

Successfully set ScaleTarget replica count
Successfully updated ScaleTarget

如果需要，您可以临时暂停工作负载对象的自动扩展。例如，您可以在执行集群维护前暂停自动扩展。

2.5.3. 安装自定义指标自动扩展

您可以使用 OpenShift Container Platform Web 控制台安装自定义 Metrics Autoscaler Operator。

安装会创建五个 CRD：

  • ClusterTriggerAuthentication
  • KedaController
  • ScaledJob
  • ScaledObject
  • TriggerAuthentication

先决条件

  • 如果您使用社区 KEDA：

    • 卸载社区 KEDA。您不能在同一 OpenShift Container Platform 集群中运行 KEDA 和自定义指标自动扩展。

    • 运行以下命令来删除 KEDA 1.x 自定义资源定义： 

      $ oc delete crd scaledobjects.keda.k8s.io
      $ oc delete crd triggerauthentications.keda.k8s.io

流程

  1. 在 OpenShift Container Platform Web 控制台中，点击 Operators → OperatorHub。
  2. 从可用的 Operator 列表中选择 Custom Metrics Autoscaler，然后点 Install。
  3. 在 Install Operator 页面中，确保为 Installation Mode 选择 All namespaces on the cluster(default) 选项。这会在所有命名空间中安装 Operator。
  4. 确保为 Installed Namespace 选择了 openshift-keda 命名空间。如果集群中不存在命名空间，OpenShift Container Platform 会创建命名空间。
  5. 点 Install。

  6. 列出自定义 Metrics Autoscaler Operator 组件来验证安装：

    1. 导航到 Workloads → Pods。
    2. 从下拉菜单中选择 openshift-keda 项目，并验证 custom-metrics-autoscaler-operator-* pod 正在运行。
    3. 进入到 Workloads → Deployments 以验证 custom-metrics-autoscaler-operator 部署是否正在运行。

  7. 可选：使用以下命令在 OpenShift CLI 中验证安装： 

    $ oc get all -n openshift-keda

    输出结果类似如下：

    输出示例

    NAME                                                      READY   STATUS    RESTARTS   AGE
pod/custom-metrics-autoscaler-operator-5fd8d9ffd8-xt4xp   1/1     Running   0          18m

NAME                                                 READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/custom-metrics-autoscaler-operator   1/1     1            1           18m

NAME                                                            DESIRED   CURRENT   READY   AGE
replicaset.apps/custom-metrics-autoscaler-operator-5fd8d9ffd8   1         1         1       18m

  8. 安装 KedaController 自定义资源，该资源创建所需的 CRD：

    1. 在 OpenShift Container Platform web 控制台中，点击 Operators → Installed Operators。
    2. 点 Custom Metrics Autoscaler。
    3. 在 Operator Details 页面中，点 KedaController 选项卡。

    4. 在 KedaController 选项卡中，点 Create KedaController 并编辑文件。 

      kind: KedaController
apiVersion: keda.sh/v1alpha1
metadata:
  name: keda
  namespace: openshift-keda
spec:
  watchNamespace: '' 1
  operator:
    logLevel: info 2
    logEncoder: console 3
  metricsServer:
    logLevel: '0' 4
    auditConfig: 5
      logFormat: "json"
      logOutputVolumeClaim: "persistentVolumeClaimName"
      policy:
        rules:
        - level: Metadata
        omitStages: "RequestReceived"
        omitManagedFields: false
      lifetime:
        maxAge: "2"
        maxBackup: "1"
        maxSize: "50"
  serviceAccount: {}
      1 1
      指定自定义自动扩展应该监视的命名空间。在以逗号分隔的列表中输入名称。省略或设置空以监视所有命名空间。默认值为空。
      2
      指定自定义 Metrics Autoscaler Operator 日志消息的详细程度。允许的值有 debug、info 和error。默认为 info。
      3
      指定 Custom Metrics Autoscaler Operator 日志消息的日志记录格式。允许的值是 console 或 json。默认为 console。
      4
      指定自定义 Metrics Autoscaler Metrics 服务器的日志记录级别。允许的值是 0（用于 info）和 4（用于 debug ）。默认值为 0。
      5
      激活自定义 Metrics Autoscaler Operator 的审计日志记录，并指定要使用的审计策略，如"配置审计日志记录"部分中所述。
    5. 点 Create 创建 KEDAController。

2.5.4. 了解自定义指标自动扩展触发器

触发器（也称为 scalers）提供自定义 Metrics Autoscaler Operator 用来扩展 pod 的指标。

注意

自定义指标自动扩展目前只支持 Prometheus、CPU、内存和 Apache Kafka 触发器。

您可以使用 ScaledObject 或 ScaledJob 自定义资源为特定对象配置触发器，如后面的章节中所述。

2.5.4.1. 了解 Prometheus 触发器

您可以基于 Prometheus 指标扩展 pod，该指标可以使用已安装的 OpenShift Container Platform 监控或外部 Prometheus 服务器作为指标源。如需有关使用 OpenShift Container Platform 监控作为指标源所需的配置的信息，请参阅附加资源。

注意

如果 Prometheus 从自定义指标自动扩展器扩展的应用程序中获取指标，请不要在自定义资源中将最小副本数设置为 0。如果没有应用程序 pod，自定义指标自动扩展没有任何要缩放的指标。

带有 Prometheus 目标的扩展对象示例

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: prom-scaledobject
  namespace: my-namespace
spec:
 ...
  triggers:
  - type: prometheus 1
    metadata:
      serverAddress: https://thanos-querier.openshift-monitoring.svc.cluster.local:9092 2
      namespace: kedatest 3
      metricName: http_requests_total 4
      threshold: '5' 5
      query: sum(rate(http_requests_total{job="test-app"}[1m])) 6
      authModes: "basic" 7
      cortexOrgID: my-org 8
      ignoreNullValues: false 9
      unsafeSsl: "false" 10

1
将 Prometheus 指定为 scaler/trigger 类型。
2
指定 Prometheus 服务器的地址。本例使用 OpenShift Container Platform 监控。
3
可选：指定您要缩放的对象的命名空间。如果 OpenShift Container Platform 监控作为指标的源，则需要此参数。
4
指定在 external.metrics.k8s.io API 中标识指标的名称。如果您使用的是多个触发器，则所有指标名称都必须是唯一的。
5
指定开始缩放的值。
6
指定要使用的 Prometheus 查询。
7
指定要使用的身份验证方法。Prometheus scalers 支持 bearer 身份验证 (bearer)、基本身份验证 (basic) 或 TLS 身份验证 (tls)。您可以在触发器身份验证中配置特定的身份验证参数，如以下部分所述。根据需要，您还可以使用 secret。
8
可选：将 X-Scope-OrgID 标头传递给多租户 Cortex 或 Prometheus 的 Mimir 存储。这个参数只需要带有多租户 Prometheus 存储，以指示 Prometheus 应该返回哪些数据。
9
可选：指定在 Prometheus 目标丢失时触发器应如何进行操作。
  • 如果为 true，当 Prometheus 目标丢失时触发器将继续操作。这是默认值。
  • 如果为 false，当 Prometheus 目标丢失时触发器会返回错误。
10
可选：指定是否应跳过证书检查。例如，如果在 Prometheus 端点中使用自签名证书，您可以跳过检查。
  • 如果为 true，则执行证书检查。
  • 如果为 false，则不会执行证书检查。这是默认值。

2.5.4.2. 了解 CPU 触发器

您可以根据 CPU 指标扩展 pod。此触发器使用集群指标作为指标的源。

自定义指标自动扩展扩展与对象关联的 pod，以维护您指定的 CPU 用量。自动缩放器增加或减少最小和最大数量之间的副本数量，以维护所有 pod 的指定 CPU 使用率。内存触发器考虑整个 pod 的内存使用率。如果 pod 有多个容器，则内存使用率是所有容器的总和。

注意
  • 此触发器不能与 ScaledJob 自定义资源一起使用。
  • 当使用内存触发器扩展对象时，对象不会扩展到 0，即使您使用多个触发器。

使用 CPU 目标扩展对象示例

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: cpu-scaledobject
  namespace: my-namespace
spec:

 ...

  triggers:
  - type: cpu 1
    metricType: Utilization 2
    metadata:
      value: "60" 3
      containerName: "api" 4

1
将 CPU 指定为 scaler/trigger 类型。
2
指定要使用的指标类型，可以是 Utilization 或 AverageValue。
3
指定触发扩展操作的值：
  • 在使用 Utilization 时，target 值是所有相关 pod 中资源指标的平均值，以 pod 资源请求的值的百分比表示。
  • 使用 AverageValue 时，target 值是所有相关 Pod 的指标平均值。
4
可选。根据该容器的内存使用率，而不是整个 pod，指定要缩放的独立容器。在这里，只有名为 api 的容器才会扩展。

2.5.4.3. 了解内存触发器

您可以根据内存指标扩展 pod。此触发器使用集群指标作为指标的源。

自定义指标自动扩展扩展与对象关联的 pod，以维护您指定的平均内存用量。自动缩放器会增加和减少最小和最大数量之间的副本数量，以维护所有 pod 的指定内存使用率。内存触发器考虑整个 pod 的内存使用率。如果 pod 有多个容器，则内存使用率是所有容器的总和。

注意
  • 此触发器不能与 ScaledJob 自定义资源一起使用。
  • 当使用内存触发器扩展对象时，对象不会扩展到 0，即使您使用多个触发器。

使用内存目标扩展对象示例

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: memory-scaledobject
  namespace: my-namespace
spec:

 ...

  triggers:
  - type: memory 1
    metricType: Utilization 2
    metadata:
      value: "60" 3
      containerName: "api" 4

1
将 memory 指定为 scaler/trigger 类型。
2
指定要使用的指标类型，可以是 Utilization 或 AverageValue。
3
指定触发以下的扩展操作的值：
  • 在使用 Utilization 时，target 值是所有相关 pod 中资源指标的平均值，以 pod 资源请求的值的百分比表示。
  • 使用 AverageValue 时，target 值是所有相关 Pod 的指标平均值。
4
可选。根据该容器的内存使用率，而不是整个 pod，指定要缩放的独立容器。在这里，只有名为 api 的容器才会扩展。

2.5.4.4. 了解 Kafka 触发器

您可以根据 Apache Kafka 主题或支持 Kafka 协议的其他服务扩展 pod。自定义指标自动扩展不会缩放 Kafka 分区数量，除非在扩展的对象或扩展任务中将 allowIdleConsumers 参数设置为 true。

注意

如果消费者组数量超过主题中的分区数量，则额外的消费者组处于闲置状态。

要避免这种情况，默认情况下副本数不会超过：

  • 如果指定了主题，则主题上的分区数量。
  • 如果没有指定主题，则消费者组中的所有主题的分区数量。
  • 在扩展对象或扩展作业 CR 中指定的 maxReplicaCount。

您可以使用 allowIdleConsumers 参数禁用这些默认行为。

使用 Kafka 目标扩展对象示例

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: kafka-scaledobject
  namespace: my-namespace
spec:
 ...
  triggers:
  - type: kafka 1
    metadata:
      topic: my-topic 2
      bootstrapServers: my-cluster-kafka-bootstrap.openshift-operators.svc:9092 3
      consumerGroup: my-group 4
      lagThreshold: '10' 5
      activationLagThreshold 6
      offsetResetPolicy: 'latest' 7
      allowIdleConsumers: true 8
      scaleToZeroOnInvalidOffset: false 9
      excludePersistentLag: false 10
      version: 1.0.0 11
      partitionLimitation: '1,2,10-20,31' 12

1
指定 Kafka 作为 scaler/trigger 类型。
2
指定 Kafka 在处理偏移滞后的 Kafka 主题的名称。
3
指定要连接的 Kafka 代理的逗号分隔列表。
4
指定用于检查主题上的偏移以及处理相关滞后的 Kafka 消费者组的名称。
5
可选：指定触发扩展操作的平均目标值。默认值为 5。
6
可选：指定激活阶段的目标值。
7
可选：为 Kafka 使用者指定 Kafka 偏移重置策略。可用值包括：latest 和 earliest。默认为 latest。
8
可选：指定 Kafka 副本数是否可以超过主题中的分区数量。
  • 如果为 true，则 Kafka 副本数可能会超过主题上的分区数量。这允许闲置 Kafka 用户。
  • 如果为 false，则 Kafka 副本数不能超过主题上的分区数量。这是默认值。
9
指定当 Kafka 分区没有有效偏移时触发器的行为方式。
  • 如果为 true，则该分区的用户将缩减为零。
  • 如果为 false，则 scaler 为该分区保留单个消费者。这是默认值。
10
可选：指定触发器是否为当前偏移与之前轮询周期的当前偏移量相同或排除分区滞后。
  • 如果为 true，则扩展程序会排除这些分区中的分区滞后。
  • 如果为 false，则触发器在所有分区中包含所有消费者滞后。这是默认值。
11
可选：指定 Kafka 代理的版本。默认值为 1.0.0。
12
可选：指定一个以逗号分隔的分区 ID 列表来限制缩放。如果设置，则仅考虑计算滞后列出的 ID。默认为考虑所有分区。

其他资源

2.5.5. 了解自定义指标自动扩展触发器身份验证

触发器身份验证允许您在扩展对象或可供关联容器使用的扩展作业中包含身份验证信息。您可以使用触发器身份验证来传递 OpenShift Container Platform secret、平台原生 Pod 验证机制、环境变量等。

您可以在与您要缩放的对象相同的命名空间中定义一个 TriggerAuthentication 对象。该触发器身份验证只能由该命名空间中的对象使用。

另外，要在多个命名空间中对象间共享凭证，您可以创建一个可在所有命名空间中使用的 ClusterTriggerAuthentication 对象。

触发验证和集群触发器身份验证使用相同的配置。但是，集群触发器身份验证需要在扩展对象的验证引用中有一个额外的 kind 参数。

使用 secret 的触发器验证示例

kind: TriggerAuthentication
apiVersion: keda.sh/v1alpha1
metadata:
  name: secret-triggerauthentication
  namespace: my-namespace 1
spec:
  secretTargetRef: 2
  - parameter: user-name 3
    name: my-secret 4
    key: USER_NAME 5
  - parameter: password
    name: my-secret
    key: USER_PASSWORD

1
指定您要缩放的对象的命名空间。
2
指定此触发器身份验证使用 secret 进行授权。
3
使用 secret 指定提供的身份验证参数。
4
指定要使用的 secret 的名称。
5
指定 secret 中与指定参数一起使用的密钥。

使用 secret 的集群触发器身份验证示例

kind: ClusterTriggerAuthentication
apiVersion: keda.sh/v1alpha1
metadata: 1
  name: secret-cluster-triggerauthentication
spec:
  secretTargetRef: 2
  - parameter: user-name 3
    name: secret-name 4
    key: USER_NAME 5
  - parameter: user-password
    name: secret-name
    key: USER_PASSWORD

1
请注意，没有命名空间用于集群触发器身份验证。
2
指定此触发器身份验证使用 secret 进行授权。
3
使用 secret 指定提供的身份验证参数。
4
指定要使用的 secret 的名称。
5
指定 secret 中与指定参数一起使用的密钥。

使用令牌进行触发器身份验证示例

kind: TriggerAuthentication
apiVersion: keda.sh/v1alpha1
metadata:
  name: token-triggerauthentication
  namespace: my-namespace 1
spec:
  secretTargetRef: 2
  - parameter: bearerToken 3
    name: my-token-2vzfq 4
    key: token 5
  - parameter: ca
    name: my-token-2vzfq
    key: ca.crt

1
指定您要缩放的对象的命名空间。
2
指定此触发器身份验证使用 secret 进行授权。
3
使用令牌指定要提供的身份验证参数。
4
指定要使用的令牌名称。
5
指定令牌中用于指定参数的密钥。

使用环境变量的触发器身份验证示例

kind: TriggerAuthentication
apiVersion: keda.sh/v1alpha1
metadata:
  name: env-var-triggerauthentication
  namespace: my-namespace 1
spec:
  env: 2
  - parameter: access_key 3
    name: ACCESS_KEY 4
    containerName: my-container 5

1
指定您要缩放的对象的命名空间。
2
指定此触发器身份验证使用环境变量进行授权。
3
指定要使用此变量设置的参数。
4
指定环境变量的名称。
5
可选：指定需要身份验证的容器。容器必须与扩展对象中的 scaleTargetRef 引用的资源相同。

使用 pod 验证供应商的触发器身份验证示例

kind: TriggerAuthentication
apiVersion: keda.sh/v1alpha1
metadata:
  name: pod-id-triggerauthentication
  namespace: my-namespace 1
spec:
  podIdentity: 2
    provider: aws-eks 3

1
指定您要缩放的对象的命名空间。
2
指定此触发器身份验证使用平台原生 Pod 验证方法进行授权。
3
指定 pod 身份。支持的值为 none, azure, aws-eks, 或 aws-kiam。默认为 none。

其他资源

2.5.5.1. 使用触发器身份验证

您可以使用触发器验证和集群触发器身份验证，方法是使用自定义资源来创建身份验证，然后添加对扩展对象或扩展任务的引用。

先决条件

  • 必须安装 Custom Metrics Autoscaler Operator。

  • 如果使用 secret，Secret 对象必须存在，例如：

    secret 示例

    apiVersion: v1
kind: Secret
metadata:
  name: my-secret
data:
  user-name: <base64_USER_NAME>
  password: <base64_USER_PASSWORD>

流程

  1. 创建 TriggerAuthentication 或 ClusterTriggerAuthentication 对象。

    1. 创建定义对象的 YAML 文件：

      使用 secret 的触发器验证示例

      kind: TriggerAuthentication
apiVersion: keda.sh/v1alpha1
metadata:
  name: prom-triggerauthentication
  namespace: my-namespace
spec:
  secretTargetRef:
  - parameter: user-name
    name: my-secret
    key: USER_NAME
  - parameter: password
    name: my-secret
    key: USER_PASSWORD

    2. 创建 TriggerAuthentication 对象： 

      $ oc create -f <file-name>.yaml

  2. 创建或编辑 ScaledObject YAML 文件：

    缩放对象示例

    apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: scaledobject
  namespace: my-namespace
spec:
  scaleTargetRef:
    name: example-deployment
  maxReplicaCount: 100
  minReplicaCount: 0
  pollingInterval: 30
  triggers:
  - authenticationRef:
    type: prometheus
    metadata:
      serverAddress: https://thanos-querier.openshift-monitoring.svc.cluster.local:9092
      namespace: kedatest # replace <NAMESPACE>
      metricName: http_requests_total
      threshold: '5'
      query: sum(rate(http_requests_total{job="test-app"}[1m]))
      authModes: "basic"
    - authenticationRef: 1
        name: prom-triggerauthentication
      metadata:
        name: prom-triggerauthentication
      type: object
    - authenticationRef: 2
        name: prom-cluster-triggerauthentication
        kind: ClusterTriggerAuthentication
      metadata:
        name: prom-cluster-triggerauthentication
      type: object

    1
    可选：指定一个触发器验证。
    2
    可选：指定一个集群触发器身份验证。您必须包含 kind: ClusterTriggerAuthentication 参数。
    注意

    不需要同时指定命名空间触发器身份验证和集群触发器身份验证。

  3. 创建对象。例如： 

    $ oc apply -f <file-name>

2.5.6. 配置自定义指标自动扩展以使用 OpenShift Container Platform 监控

您可以使用已安装的 OpenShift Container Platform Prometheus 监控作为自定义指标自动扩展使用的指标的来源。但是，需要执行一些额外的配置。

注意

外部 Prometheus 源不需要这些步骤。

您必须执行以下任务，如本节所述：

  • 创建服务帐户以获取令牌。
  • 创建角色。
  • 将该角色添加到服务帐户。
  • 在 Prometheus 使用的触发器验证对象中引用令牌。

先决条件

  • 必须安装 OpenShift Container Platform 监控。
  • OpenShift Container Platform 监控中必须启用对用户定义的工作负载的监控监控，如创建用户定义的工作负载监控配置映射部分所述。
  • 必须安装 Custom Metrics Autoscaler Operator。

流程

  1. 使用您要缩放的对象切换到项目： 

    $ oc project my-project

  2. 如果您的集群没有服务帐户，请使用以下命令来创建服务帐户： 

    $ oc create serviceaccount <service_account>

    其中：

    <service_account>
    指定服务帐户的名称。

  3. 使用以下命令查找分配给服务帐户的令牌： 

    $ oc describe serviceaccount <service_account>

    其中：

    <service_account>
    指定服务帐户的名称。

    输出示例

    Name:                thanos
Namespace:           my-project
Labels:              <none>
Annotations:         <none>
Image pull secrets:  thanos-dockercfg-nnwgj
Mountable secrets:   thanos-dockercfg-nnwgj
Tokens:              thanos-token-9g4n5 1
Events:              <none>

    1
    在触发器身份验证中使用此令牌。

  4. 使用服务帐户令牌创建触发器身份验证：

    1. 创建一个类似以下示例的 YAML 文件： 

      apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: keda-trigger-auth-prometheus
spec:
  secretTargetRef: 1
  - parameter: bearerToken 2
    name: thanos-token-9g4n5 3
    key: token 4
  - parameter: ca
    name: thanos-token-9g4n5
    key: ca.crt
      1
      指定此对象使用 secret 进行授权。
      2
      使用令牌指定要提供的身份验证参数。
      3
      指定要使用的令牌名称。
      4
      指定令牌中用于指定参数的密钥。

    2. 创建 CR 对象： 

      $ oc create -f <file-name>.yaml

  5. 创建用于读取 Thanos 指标的角色：

    1. 使用以下参数创建 YAML 文件： 

      apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: thanos-metrics-reader
rules:
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - get
- apiGroups:
  - metrics.k8s.io
  resources:
  - pods
  - nodes
  verbs:
  - get
  - list
  - watch

    2. 创建 CR 对象： 

      $ oc create -f <file-name>.yaml

  6. 创建用于读取 Thanos 指标的角色绑定：

    1. 创建一个类似以下示例的 YAML 文件： 

      apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: thanos-metrics-reader 1
  namespace: my-project 2
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: thanos-metrics-reader
subjects:
- kind: ServiceAccount
  name: thanos 3
  namespace: my-project 4
      1
      指定您创建的角色的名称。
      2
      指定您要缩放的对象的命名空间。
      3
      指定要绑定到角色的服务帐户的名称。
      4
      指定您要缩放的对象的命名空间。

    2. 创建 CR 对象： 

      $ oc create -f <file-name>.yaml

现在，您可以部署扩展的对象或扩展作业来为应用程序启用自动扩展，如以下部分所述。要将 OpenShift Container Platform 监控用作源，在触发器或 scaler 中指定 prometheus 类型，并使用 https://thanos-querier.openshift-monitoring.svc.cluster.local:9092 作为 serverAddress。

其他资源

2.5.7. 暂停工作负载的自定义指标自动扩展

您可以通过在该工作负载的自定义指标自动扩展中添加 autoscaling.keda.sh/paused-replicas 注解来暂停工作负载的自动扩展。自定义指标自动扩展将该工作负载的副本扩展到指定的值，并暂停自动扩展，直到注解被删除为止。 

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  annotations:
    autoscaling.keda.sh/paused-replicas: "4"
...

要重启自动扩展，请编辑 ScaledObject CR 以删除注解。

例如，您可能想要在执行集群维护前暂停自动扩展，或通过删除非传输工作负载来避免资源不足。

流程

  1. 使用以下命令编辑工作负载的 ScaledObject CR： 

    $ oc edit ScaledObject scaledobject

  2. 使用任何值添加 autoscaling.keda.sh/paused-replicas 注解： 

    apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  annotations:
    autoscaling.keda.sh/paused-replicas: "4" 1
  creationTimestamp: "2023-02-08T14:41:01Z"
  generation: 1
  name: scaledobject
  namespace: my-project
  resourceVersion: "65729"
  uid: f5aec682-acdf-4232-a783-58b5b82f5dd0
    1
    指定自定义 Metrics Autoscaler Operator 将副本扩展到指定的值，并停止自动扩展。

2.5.8. 配置审计日志记录

您可以收集审计日志，它们是与安全相关的按时间排序的记录，记录各个用户、管理员或其他系统组件影响系统的一系列活动。

例如，审计日志可帮助您了解自动扩展请求来自哪里。当后端因为用户应用程序发出的请求造成过载时，这个信息非常重要，您需要确定哪个是有问题的应用程序。您可以通过编辑 KedaController 自定义资源来为自定义 Metrics Autoscaler Operator 配置审计。日志通过 KedaController CR 中的持久性卷声明发送到卷的审计日志文件。

先决条件

  • 必须安装 Custom Metrics Autoscaler Operator。

流程

  1. 编辑 KedaController 自定义资源以添加 auditConfig 小节： 

    kind: KedaController
apiVersion: keda.sh/v1alpha1
metadata:
  name: keda
  namespace: openshift-keda
spec:
 ...
  metricsServer:
 ...
    auditConfig:
      logFormat: "json" 1
      logOutputVolumeClaim: "pvc-audit-log" 2
      policy:
        rules: 3
        - level: Metadata
        omitStages: "RequestReceived" 4
        omitManagedFields: false 5
      lifetime: 6
        maxAge: "2"
        maxBackup: "1"
        maxSize: "50"
    1
    指定审计日志的输出格式，可以是 legacy 或 json。
    2
    指定用于存储日志数据的现有持久性卷声明。所有来自 API 服务器的请求都会记录到此持久性卷声明。如果将此字段留空，日志数据将发送到 stdout。
    3
    指定应记录哪些事件及其应包含哪些数据：
    • None ：不记录事件。
    • Metadata ：仅记录请求的元数据，如用户、时间戳等。不要记录请求文本和响应文本。这是默认值。
    • Request ：仅记录元数据和请求文本，而不记录响应文本。这个选项不适用于非资源请求。
    • RequestResponse ：日志事件元数据、请求文本和响应文本。这个选项不适用于非资源请求。
    4
    指定没有创建事件的阶段。
    5
    指定是否省略请求的 managed 字段，并从写入 API 审计日志的响应正文，可以是 true 来省略字段，或 false 包含字段。
    6
    指定审计日志的大小和生命周期。
    • MaxAge ：根据文件名中编码的时间戳，保留审计日志文件的最大天数。
    • maxBackup ：要保留的审计日志文件的最大数量。设置为 0 以保留所有审计日志文件。
    • maxsize ：在轮转审计日志文件前以 MB 为单位的最大大小。

验证

  1. 直接查看审计日志文件：

    1. 获取 keda-metrics-apiserver the pod 的名称： 

      oc get pod -n openshift-keda

      输出示例

      NAME                                                  READY   STATUS    RESTARTS   AGE
custom-metrics-autoscaler-operator-5cb44cd75d-9v4lv   1/1     Running   0          8m20s
keda-metrics-apiserver-65c7cc44fd-rrl4r               1/1     Running   0          2m55s
keda-operator-776cbb6768-zpj5b                        1/1     Running   0          2m55s

    2. 使用类似如下的命令查看日志数据： 

      $ oc logs keda-metrics-apiserver-<hash>|grep -i metadata 1
      1
      可选： 您可以使用 grep 命令指定要显示的日志级别： Metadata、Request、RequestResponse。

      例如： 

      $ oc logs keda-metrics-apiserver-65c7cc44fd-rrl4r|grep -i metadata

      输出示例

       ...
{"kind":"Event","apiVersion":"audit.k8s.io/v1","level":"Metadata","auditID":"4c81d41b-3dab-4675-90ce-20b87ce24013","stage":"ResponseComplete","requestURI":"/healthz","verb":"get","user":{"username":"system:anonymous","groups":["system:unauthenticated"]},"sourceIPs":["10.131.0.1"],"userAgent":"kube-probe/1.26","responseStatus":{"metadata":{},"code":200},"requestReceivedTimestamp":"2023-02-16T13:00:03.554567Z","stageTimestamp":"2023-02-16T13:00:03.555032Z","annotations":{"authorization.k8s.io/decision":"allow","authorization.k8s.io/reason":""}}
 ...

  2. 另外，您可以查看特定的日志：

    1. 使用类似如下的命令登录到 keda-metrics-apiserver the pod: 

      $ oc rsh pod/keda-metrics-apiserver-<hash> -n openshift-keda

      例如： 

      $ oc rsh pod/keda-metrics-apiserver-65c7cc44fd-rrl4r -n openshift-keda

    2. 进入 /var/audit-policy/ 目录： 

      sh-4.4$ cd /var/audit-policy/

    3. 列出可用的日志： 

      sh-4.4$ ls

      输出示例

      log-2023.02.17-14:50  policy.yaml

    4. 根据需要查看日志： 

      sh-4.4$ cat <log_name>/<pvc_name>|grep -i <log_level> 1
      1
      可选： 您可以使用 grep 命令指定要显示的日志级别： Metadata、Request、RequestResponse。

      例如： 

      sh-4.4$ cat log-2023.02.17-14:50/pvc-audit-log|grep -i Request

      输出示例

       ...
{"kind":"Event","apiVersion":"audit.k8s.io/v1","level":"Request","auditID":"63e7f68c-04ec-4f4d-8749-bf1656572a41","stage":"ResponseComplete","requestURI":"/openapi/v2","verb":"get","user":{"username":"system:aggregator","groups":["system:authenticated"]},"sourceIPs":["10.128.0.1"],"responseStatus":{"metadata":{},"code":304},"requestReceivedTimestamp":"2023-02-17T13:12:55.035478Z","stageTimestamp":"2023-02-17T13:12:55.038346Z","annotations":{"authorization.k8s.io/decision":"allow","authorization.k8s.io/reason":"RBAC: allowed by ClusterRoleBinding \"system:discovery\" of ClusterRole \"system:discovery\" to Group \"system:authenticated\""}}
 ...

其他资源

2.5.9. 收集调试数据

在提交问题单时同时提供您的集群信息，可以帮助红帽支持为您进行排除故障。

建议您提供以下信息：

  • 使用 must-gather 工具收集的数据。
  • 唯一的集群 ID。

您可以使用 must-gather 工具来收集有关自定义 Metrics Autoscaler Operator 及其组件的数据，包括：

  • openshift-keda 命名空间及其子对象。
  • Custom Metric Autoscaler Operator 安装对象。
  • Custom Metric Autoscaler Operator CRD 对象。

以下命令为自定义 Metrics Autoscaler Operator 运行 must-gather 工具： 

$ oc adm must-gather --image="$(oc get packagemanifests openshift-custom-metrics-autoscaler-operator \
-n openshift-marketplace \
-o jsonpath='{.status.channels[?(@.name=="stable")].currentCSVDesc.annotations.containerImage}')"
注意

标准 OpenShift Container Platform must-gather 命令 oc adm must-gather 将不会收集自定义 Metrics Autoscaler Operator 数据。

先决条件

  • 使用具有 cluster-admin 角色的用户访问集群。
  • 已安装 OpenShift Container Platform CLI (oc)。

流程

  1. 进入要存储 must-gather 数据的目录。

    注意

    如果集群使用受限网络，则需要执行额外的步骤。如果您镜像的容器镜像仓库有一个信任的 CA，您必须首先将这个信任的 CA 添加到集群中。对于受限网络中的所有集群，您必须运行以下命令来导入默认的 must-gather 镜像作为镜像流。 

    $ oc import-image is/must-gather -n openshift

  2. 执行以下之一：

    • 要只获取自定义 Metrics Autoscaler Operator must-gather 数据，请使用以下命令： 

      $ oc adm must-gather --image="$(oc get packagemanifests openshift-custom-metrics-autoscaler-operator \
-n openshift-marketplace \
-o jsonpath='{.status.channels[?(@.name=="stable")].currentCSVDesc.annotations.containerImage}')"

      must-gather 命令的自定义镜像直接从 Operator 软件包清单中拉取，以便它可用于提供 Custom Metric Autoscaler Operator 的任何集群。

    • 除了 Custom Metric Autoscaler Operator 信息外，要收集默认的 must-gather 数据：

      1. 使用以下命令获取自定义 Metrics Autoscaler Operator 镜像并将其设置为环境变量： 

        $ IMAGE="$(oc get packagemanifests openshift-custom-metrics-autoscaler-operator \
  -n openshift-marketplace \
  -o jsonpath='{.status.channels[?(@.name=="stable")].currentCSVDesc.annotations.containerImage}')"

      2. 使用带有自定义 Metrics Autoscaler Operator 镜像的 oc adm must-gather ： 

        $ oc adm must-gather --image-stream=openshift/must-gather --image=${IMAGE}

    例 2.1. Custom Metric Autoscaler 的 must-gather 输出示例：

    └── openshift-keda
    ├── apps
    │   ├── daemonsets.yaml
    │   ├── deployments.yaml
    │   ├── replicasets.yaml
    │   └── statefulsets.yaml
    ├── apps.openshift.io
    │   └── deploymentconfigs.yaml
    ├── autoscaling
    │   └── horizontalpodautoscalers.yaml
    ├── batch
    │   ├── cronjobs.yaml
    │   └── jobs.yaml
    ├── build.openshift.io
    │   ├── buildconfigs.yaml
    │   └── builds.yaml
    ├── core
    │   ├── configmaps.yaml
    │   ├── endpoints.yaml
    │   ├── events.yaml
    │   ├── persistentvolumeclaims.yaml
    │   ├── pods.yaml
    │   ├── replicationcontrollers.yaml
    │   ├── secrets.yaml
    │   └── services.yaml
    ├── discovery.k8s.io
    │   └── endpointslices.yaml
    ├── image.openshift.io
    │   └── imagestreams.yaml
    ├── k8s.ovn.org
    │   ├── egressfirewalls.yaml
    │   └── egressqoses.yaml
    ├── keda.sh
    │   ├── kedacontrollers
    │   │   └── keda.yaml
    │   ├── scaledobjects
    │   │   └── example-scaledobject.yaml
    │   └── triggerauthentications
    │       └── example-triggerauthentication.yaml
    ├── monitoring.coreos.com
    │   └── servicemonitors.yaml
    ├── networking.k8s.io
    │   └── networkpolicies.yaml
    ├── openshift-keda.yaml
    ├── pods
    │   ├── custom-metrics-autoscaler-operator-58bd9f458-ptgwx
    │   │   ├── custom-metrics-autoscaler-operator
    │   │   │   └── custom-metrics-autoscaler-operator
    │   │   │       └── logs
    │   │   │           ├── current.log
    │   │   │           ├── previous.insecure.log
    │   │   │           └── previous.log
    │   │   └── custom-metrics-autoscaler-operator-58bd9f458-ptgwx.yaml
    │   ├── custom-metrics-autoscaler-operator-58bd9f458-thbsh
    │   │   └── custom-metrics-autoscaler-operator
    │   │       └── custom-metrics-autoscaler-operator
    │   │           └── logs
    │   ├── keda-metrics-apiserver-65c7cc44fd-6wq4g
    │   │   ├── keda-metrics-apiserver
    │   │   │   └── keda-metrics-apiserver
    │   │   │       └── logs
    │   │   │           ├── current.log
    │   │   │           ├── previous.insecure.log
    │   │   │           └── previous.log
    │   │   └── keda-metrics-apiserver-65c7cc44fd-6wq4g.yaml
    │   └── keda-operator-776cbb6768-fb6m5
    │       ├── keda-operator
    │       │   └── keda-operator
    │       │       └── logs
    │       │           ├── current.log
    │       │           ├── previous.insecure.log
    │       │           └── previous.log
    │       └── keda-operator-776cbb6768-fb6m5.yaml
    ├── policy
    │   └── poddisruptionbudgets.yaml
    └── route.openshift.io
        └── routes.yaml

  3. 从工作目录中创建的 must-gather 目录创建一个压缩文件。例如，在使用 Linux 操作系统的计算机上运行以下命令： 

    $ tar cvaf must-gather.tar.gz must-gather.local.5421342344627712289/ 1
    1
    将 must-gather-local.5421342344627712289/ 替换为实际目录名称。
  4. 在红帽客户门户中为您的问题单附上压缩文件。

其他资源

2.5.10. 访问性能指标

Custom Metrics Autoscaler Operator 会公开从集群监控组件中提取的可随时使用的指标。您可以使用 Prometheus Query Language (PromQL) 来分析和诊断问题来查询指标。控制器 pod 重启时会重置所有指标。

您可以使用 OpenShift Container Platform Web 控制台访问指标并运行查询。

流程

  1. 在 OpenShift Container Platform Web 控制台中选择 Administrator 视角。
  2. 选择 Observe → Metrics。
  3. 要创建自定义查询，请将 PromQL 查询添加到 Expression 字段中。
  4. 要添加多个查询，选择 Add Query。

2.5.10.1. 提供的指标

Custom Metrics Autoscaler Operator 会公开以下指标，您可以使用 OpenShift Container Platform Web 控制台查看这些指标。

表 2.2. 自定义 Metric Autoscaler Operator 指标

指标名称描述

keda_scaler_activity

特定的 scaler 是活跃的还是不活跃的。值 1 表示 scaler 处于活跃状态； 0 表示 scaler 不活跃。

keda_scaler_metrics_value

每个 scaler 的指标的当前值，由计算目标平均值中的 Horizontal Pod Autoscaler (HPA) 使用。

keda_scaler_metrics_latency

从每个 scaler 检索当前指标的延迟。

keda_scaler_errors

每个 scaler 发生的错误数量。

keda_scaler_errors_total

所有 scaler 遇到的错误总数。

keda_scaled_object_errors

每个扩展的对象发生的错误数量。

keda_resource_totals

每个命名空间中的自定义 Metrics Autoscaler 自定义资源总数，每种自定义资源类型。

keda_trigger_totals

根据触发器类型的触发器总数。

自定义 Metrics Autoscaler Admission Webhook 指标

自定义 Metrics Autoscaler Admission Webhook 也会公开以下 Prometheus 指标。

指标名称描述

keda_scaled_object_validation_total

扩展对象验证的数量。

keda_scaled_object_validation_errors

验证错误的数量。

2.5.11. 了解如何添加自定义指标自动扩展

要添加自定义指标自动扩展，请为部署、有状态集或自定义资源创建 ScaledObject 自定义资源。为作业创建 ScaledJob 自定义资源。

您只能为每个您要扩展的工作负载创建一个扩展对象或扩展作业。另外，您不能在同一工作负载中使用扩展的对象或扩展作业以及 pod 横向自动扩展 (HPA)。

2.5.11.1. 在工作负载中添加自定义指标自动扩展

您可以为 Deployment、StatefulSet 或 custom resource 对象创建的工作负载创建自定义指标自动扩展。

先决条件

  • 必须安装 Custom Metrics Autoscaler Operator。

  • 如果您使用自定义指标自动扩展来根据 CPU 或内存进行扩展：

    • 您的集群管理员必须已配置了集群指标。您可以使用 oc describe PodMetrics <pod-name> 命令来判断是否已配置了指标。如果配置了指标，输出将类似以下示例，CPU 和 Memory 在 Usage 下显示。 

      $ oc describe PodMetrics openshift-kube-scheduler-ip-10-0-135-131.ec2.internal

      输出示例

      Name:         openshift-kube-scheduler-ip-10-0-135-131.ec2.internal
Namespace:    openshift-kube-scheduler
Labels:       <none>
Annotations:  <none>
API Version:  metrics.k8s.io/v1beta1
Containers:
  Name:  wait-for-host-port
  Usage:
    Memory:  0
  Name:      scheduler
  Usage:
    Cpu:     8m
    Memory:  45440Ki
Kind:        PodMetrics
Metadata:
  Creation Timestamp:  2019-05-23T18:47:56Z
  Self Link:           /apis/metrics.k8s.io/v1beta1/namespaces/openshift-kube-scheduler/pods/openshift-kube-scheduler-ip-10-0-135-131.ec2.internal
Timestamp:             2019-05-23T18:47:56Z
Window:                1m0s
Events:                <none>

    • 与您要缩放的对象关联的 pod 必须包含指定的内存和 CPU 限值。例如：

      pod 规格示例

      apiVersion: v1
kind: Pod
 ...
spec:
  containers:
  - name: app
    image: images.my-company.example/app:v4
    resources:
      limits:
        memory: "128Mi"
        cpu: "500m"

流程

  1. 创建一个类似如下的 YAML 文件：只有名称 <2>, 对象名称 <4>, 和对象类型 <5> 是必需的。

    缩放对象示例

    apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  annotations:
    autoscaling.keda.sh/paused-replicas: "0" 1
  name: scaledobject 2
  namespace: my-namespace
spec:
  scaleTargetRef:
    apiVersion: apps/v1 3
    name: example-deployment 4
    kind: Deployment 5
    envSourceContainerName: .spec.template.spec.containers[0] 6
  cooldownPeriod:  200 7
  maxReplicaCount: 100 8
  minReplicaCount: 0 9
  metricsServer: 10
    auditConfig:
      logFormat: "json"
      logOutputVolumeClaim: "persistentVolumeClaimName"
      policy:
        rules:
        - level: Metadata
        omitStages: "RequestReceived"
        omitManagedFields: false
      lifetime:
        maxAge: "2"
        maxBackup: "1"
        maxSize: "50"
  fallback: 11
    failureThreshold: 3
    replicas: 6
  pollingInterval: 30 12
  advanced:
    restoreToOriginalReplicaCount: false 13
    horizontalPodAutoscalerConfig:
      name: keda-hpa-scale-down 14
      behavior: 15
        scaleDown:
          stabilizationWindowSeconds: 300
          policies:
          - type: Percent
            value: 100
            periodSeconds: 15
  triggers:
  - type: prometheus 16
    metadata:
      serverAddress: https://thanos-querier.openshift-monitoring.svc.cluster.local:9092
      namespace: kedatest
      metricName: http_requests_total
      threshold: '5'
      query: sum(rate(http_requests_total{job="test-app"}[1m]))
      authModes: "basic"
  - authenticationRef: 17
      name: prom-triggerauthentication
    metadata:
      name: prom-triggerauthentication
    type: object
  - authenticationRef: 18
      name: prom-cluster-triggerauthentication
    metadata:
      name: prom-cluster-triggerauthentication
    type: object

    1
    可选：指定自定义 Metrics Autoscaler Operator 将副本扩展到指定的值和停止自动扩展，如 "Pausing the custom metrics autoscaler for a workload" 部分所述。
    2
    指定此自定义指标自动扩展的名称。
    3
    可选：指定目标资源的 API 版本。默认为 apps/v1。
    4
    指定要缩放的对象名称。
    5
    指定 kind 为 Deployment, StatefulSet 或 CustomResource。
    6
    可选：指定目标资源中的容器的名称，其中的自定义自动扩展器获取包含 secret 的环境变量等。默认为 .spec.template.spec.containers[0]。
    7
    可选。指定一个在最后的触发器报告后等待的时间（以秒为单位），在经过这个时间后才会将部署缩减为 0（如果 minReplicaCount 设置为 0）。默认值为 300。
    8
    可选：指定扩展时的最大副本数量。默认值为 100。
    9
    可选：指定缩减时的最小副本数量。
    10
    可选：指定审计日志的参数。如"配置审计日志记录"部分中所述。
    11
    可选：指定在扩展程序无法从源中获取由 failureThreshold 参数定义的次数时回退到的副本数。有关回退行为的更多信息，请参阅 KEDA 文档。
    12
    可选：指定检查每个触发器的时间间隔（以秒为单位）。默认值为 30。
    13
    可选：指定是否在删除扩展对象后将目标资源扩展为原始副本数。默认为 false，这会在删除扩展对象时保留副本数。
    14
    可选：指定 pod 横向自动扩展的名称。默认为 keda-hpa-{scaled-object-name}。
    15
    可选：指定一个扩展策略来控制用来扩展或缩减 pod 的速度，如"扩展策略"部分中所述。
    16
    指定用作扩展基础的触发器，如"识别自定义指标自动扩展触发器"部分中所述。本例使用 OpenShift Container Platform 监控。
    17
    可选：指定触发器身份验证，如 "Creating a custom metrics autoscaler trigger authentication" 部分所述。
    18
    可选：指定集群触发器身份验证，如 "Creating a custom metrics autoscaler trigger authentication" 部分所述。
    注意

    不需要同时指定命名空间触发器身份验证和集群触发器身份验证。

  2. 创建自定义指标自动扩展： 

    $ oc create -f <file-name>.yaml

验证

  • 查看命令输出，以验证是否已创建自定义指标自动扩展： 

    $ oc get scaledobject <scaled_object_name>

    输出示例

    NAME            SCALETARGETKIND      SCALETARGETNAME        MIN   MAX   TRIGGERS     AUTHENTICATION               READY   ACTIVE   FALLBACK   AGE
scaledobject    apps/v1.Deployment   example-deployment     0     50    prometheus   prom-triggerauthentication   True    True     True       17s

    请注意输出中的以下字段：

  • TRIGGERS ：指示正在使用的触发器或缩放器。
  • AUTHENTICATION ：指示所使用的任何触发器身份验证的名称。

  • READY ：指示扩展对象是否准备好启动缩放：

    • 如果为 True，则扩展的对象已就绪。
    • 如果 False，由于您创建的对象中的一个或多个对象有问题，扩展的对象将不可用。

  • ACTIVE ：指示扩展是否发生：

    • 如果为 True，则会进行缩放。
    • 如果 False，则不会发生缩放，因为您创建的一个或多个对象中没有指标或多个问题。

  • FALLBACK ：指示自定义指标自动扩展是否能够从源获取指标

    • 如果 False，自定义指标自动扩展器会获取指标。
    • 如果为 True，自定义指标自动扩展会获取指标，因为您创建的一个或多个对象中没有指标或多个问题。

其他资源

2.5.11.2. 在作业中添加自定义指标自动扩展

您可以为任何作业对象创建自定义指标自动扩展。

先决条件

  • 必须安装 Custom Metrics Autoscaler Operator。

流程

  1. 创建一个类似以下示例的 YAML 文件： 

    kind: ScaledJob
apiVersion: keda.sh/v1alpha1
metadata:
  name: scaledjob
  namespace: my-namespace
spec:
  failedJobsHistoryLimit: 5
  jobTargetRef:
    activeDeadlineSeconds: 600 1
    backoffLimit: 6 2
    parallelism: 1 3
    completions: 1 4
    template:  5
      metadata:
        name: pi
      spec:
        containers:
        - name: pi
          image: perl
          command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
  maxReplicaCount: 100 6
  pollingInterval: 30 7
  successfulJobsHistoryLimit: 5 8
  failedJobsHistoryLimit: 5 9
  envSourceContainerName: 10
  rolloutStrategy: gradual 11
  scalingStrategy: 12
    strategy: "custom"
    customScalingQueueLengthDeduction: 1
    customScalingRunningJobPercentage: "0.5"
    pendingPodConditions:
      - "Ready"
      - "PodScheduled"
      - "AnyOtherCustomPodCondition"
    multipleScalersCalculation : "max"
  triggers:
  - type: prometheus 13
    metadata:
      serverAddress: https://thanos-querier.openshift-monitoring.svc.cluster.local:9092
      namespace: kedatest
      metricName: http_requests_total
      threshold: '5'
      query: sum(rate(http_requests_total{job="test-app"}[1m]))
      authModes: "bearer"
  - authenticationRef: 14
      name: prom-triggerauthentication
    metadata:
      name: prom-triggerauthentication
     type: object
  - authenticationRef: 15
      name: prom-cluster-triggerauthentication
    metadata:
      name: prom-cluster-triggerauthentication
    type: object
    1
    指定作业可以运行的最长持续时间。
    2
    指定作业的重试次数。默认值为 6。
    3
    可选：指定作业应并行运行多少个 pod 副本；默认为 1。
    • 对于非并行作业，请保留未设置。如果未设置，则默认值为 1。
    4
    可选：指定标记作业完成需要成功完成多少个 pod。
    • 对于非并行作业，请保留未设置。如果未设置，则默认值为 1。
    • 对于具有固定完成计数的并行作业，请指定完成数。
    • 对于带有工作队列的并行作业，请保留 unset。当取消设置默认值时，默认值为 parallelism 参数的值。
    5
    指定控制器创建的 pod 模板。
    6
    可选：指定扩展时的最大副本数量。默认值为 100。
    7
    可选：指定检查每个触发器的时间间隔（以秒为单位）。默认值为 30。
    8
    可选：指定成功完成作业的数量。默认值为 100。
    9
    可选：指定应保留多少个失败作业。默认值为 100。
    10
    可选：指定目标资源中的容器的名称，其中的自定义自动扩展器获取包含 secret 的环境变量等。默认为 .spec.template.spec.containers[0]。
    11
    可选：指定在更新扩展作业时是否被终止现有作业：
    • default ：如果关联的扩展作业被更新，则自动扩展器会终止一个现有作业。自动扩展会使用最新的 specs 重新创建作业。
    • gradual ：如果关联的扩展作业被更新，则自动扩展不会终止现有的作业。自动缩放器使用最新的 specs 创建新作业。
    12
    可选：指定一个扩展策略： default、custom 或 accurate。默认为 default。如需更多信息，请参阅下面的"添加资源"部分中的链接。
    13
    指定用作扩展基础的触发器，如"识别自定义指标自动扩展触发器"部分中所述。
    14
    可选：指定触发器身份验证，如 "Creating a custom metrics autoscaler trigger authentication" 部分所述。
    15
    可选：指定集群触发器身份验证，如 "Creating a custom metrics autoscaler trigger authentication" 部分所述。
    注意

    不需要同时指定命名空间触发器身份验证和集群触发器身份验证。

  2. 创建自定义指标自动扩展： 

    $ oc create -f <file-name>.yaml

验证

  • 查看命令输出，以验证是否已创建自定义指标自动扩展： 

    $ oc get scaledjob <scaled_job_name>

    输出示例

    NAME        MAX   TRIGGERS     AUTHENTICATION              READY   ACTIVE    AGE
scaledjob   100   prometheus   prom-triggerauthentication  True    True      8s

    请注意输出中的以下字段：

  • TRIGGERS ：指示正在使用的触发器或缩放器。
  • AUTHENTICATION ：指示所使用的任何触发器身份验证的名称。

  • READY ：指示扩展对象是否准备好启动缩放：

    • 如果为 True，则扩展的对象已就绪。
    • 如果 False，由于您创建的对象中的一个或多个对象有问题，扩展的对象将不可用。

  • ACTIVE ：指示扩展是否发生：

    • 如果为 True，则会进行缩放。
    • 如果 False，则不会发生缩放，因为您创建的一个或多个对象中没有指标或多个问题。

其他资源

2.5.12. 卸载自定义 Metrics Autoscaler Operator

您可以从 OpenShift Container Platform 集群中删除自定义指标自动扩展。删除自定义 Metrics Autoscaler Operator 后，删除与 Operator 相关的其他组件以避免出现潜在的问题。

注意

您应该首先删除 KedaController 自定义资源 (CR)。如果您没有特别删除 CR，OpenShift Container Platform 会在删除 openshift-keda 项目时挂起。如果在删除 CR 前删除了自定义 Metrics Autoscaler Operator，您将无法删除 CR。

先决条件

  • 必须安装 Custom Metrics Autoscaler Operator。

流程

  1. 在 OpenShift Container Platform web 控制台中，点击 Operators → Installed Operators。
  2. 切换到 openshift-keda 项目。

  3. 删除 KedaController 自定义资源。

    1. 找到 CustomMetricsAutoscaler Operator 并点 KedaController 选项卡。
    2. 找到自定义资源，然后点 Delete KedaController。
    3. 点 Uninstall。

  4. 删除自定义 Metrics Autoscaler Operator:

    1. 点 Operators → Installed Operators。
    2. 找到 CustomMetricsAutoscaler Operator 并点 Options 菜单 kebab 并选择 Uninstall Operator。
    3. 点 Uninstall。

  5. 可选： 使用 OpenShift CLI 删除自定义指标自动扩展组件：

    1. 删除自定义指标自动扩展 CRD：

      • clustertriggerauthentications.keda.sh
      • kedacontrollers.keda.sh
      • scaledjobs.keda.sh
      • scaledobjects.keda.sh
      • triggerauthentications.keda.sh 
      $ oc delete crd clustertriggerauthentications.keda.sh kedacontrollers.keda.sh scaledjobs.keda.sh scaledobjects.keda.sh triggerauthentications.keda.sh

      删除 CRD 会删除关联的角色、集群角色和角色绑定。但是，可能存在一些必须手动删除的集群角色。

    2. 列出任何自定义指标自动扩展集群角色： 

      $ oc get clusterrole | grep keda.sh

    3. 删除列出的自定义指标自动扩展集群角色。例如： 

      $ oc delete clusterrole.keda.sh-v1alpha1-admin

    4. 列出任何自定义指标自动扩展集群角色绑定： 

      $ oc get clusterrolebinding | grep keda.sh

    5. 删除列出的自定义指标自动扩展集群角色绑定。例如： 

      $ oc delete clusterrolebinding.keda.sh-v1alpha1-admin

  6. 删除自定义指标自动扩展项目： 

    $ oc delete project openshift-keda

  7. 删除 Cluster Metric Autoscaler Operator： 

    $ oc delete operator/openshift-custom-metrics-autoscaler-operator.openshift-keda