我有一个在 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?