Kubernetes HPA 通过自定义指标快速扩展答案

【问题标题】：Kubernetes HPA Scales Up Rapidly with Custom MetricKubernetes HPA 通过自定义指标快速扩展
【发布时间】：2021-07-08 11:35:13
【问题描述】：

我有一个在 GKE 上运行的 Spring Boot 应用程序，需要大约 7 分钟才能准备好。我创建了一个 HPA，基于自定义的每秒请求指标如下：

kind: "HorizontalPodAutoscaler"
metadata:
  name: X
  namespace: X
spec:
  maxReplicas: 10
  minReplicas: 3
  scaleTargetRef:
    apiVersion: "apps/v1"
    kind: "Deployment"
    name: "X"
  metrics:
    - type: "Pods"
      pods:
        metric:
          name: "istio_requests_per_second"
        target:
          type: "AverageValue"
          averageValue: 30

istio_requests_per_second 指标已经计算了可用 pod 的平均 RPS，这会导致每个 pod 的值相同。例如，如果总共有 150 个 RPS，如果有 5 个可用 pod，则 istio_requests_per_second 将为 30。

当 istio_requests_per_second 略高于 30 时，HPA 将继续生成 pod，直到其中一个新创建的 pod 准备好接收部分请求——假设 2 RPS，以防指标为增加到 32 RPS。这完全有道理，因为在新创建的 pod 准备就绪之前，它们不会收到请求，HPA 会尝试将 RPS 的数量保持在目标值附近——30。

问题是，我不希望 HPA 生成数十个 pod，以防 RPS 略微增加。例如，在 32 RPS 的情况下，一个新的 pod 就足够了。我认为主要问题是启动时间过长，因为在扩展决策的时间和 Pod 准备就绪的时间之间存在自动扩展滞后。

因为我在 GKE 上运行，所以我无法更改 kube-controller-manager 标志，例如 --horizontal-pod-autoscaler-sync-period。

我也在 Kubernetes 1.17 上运行，所以配置渐进式扩展的行为字段是没有问题的。此外，我不想限制缩放，可能是 istio_requests_per_second 实际上飙升至 100 RPS 以上。

TL;DR：如何将 Kubernetes HPA 配置为在启动缓慢的应用程序每秒请求数略有增加的情况下不生成数十个 pod？

【问题讨论】：

标签： kubernetes google-kubernetes-engine autoscaling horizontal-pod-autoscaling

【解决方案1】：

要缩小 pod 缩放选项，您可以将自动缩放基于 multiple metrics。

您可以在 documentation 中查看 GKE 如何根据自定义或外部指标进行自动缩放的示例，以便更好地了解其利用率。

【讨论】：