如何在GKE Autopilot中基于自定义指标实现水平Pod自动扩缩容

是否需要实现自定义Horizontal Pod Autoscaler #

不需要从零开发完整的自定义HPA控制器，基于K8s自带的HPA配合自定义指标就能满足需求，完全适配GKE Autopilot的运行环境。
你可以先在Pod内的应用中新增/metrics端点，把当前应用状态暴露为Prometheus格式的指标，比如用job_status的不同取值对应三种状态：0对应waiting for job、1对应running job、2对应completed job，再通过Prometheus Adapter将该指标同步为K8s可识别的自定义指标，配置HPA时直接以waiting for job状态的Pod数量作为阈值，就能稳定维持你需要的待命Pod比例。
如果你已经通过Scale API实现了扩容逻辑，只需要在现有逻辑上补充缩容的状态判断规则即可，不需要重构整套扩缩容体系。

能否为Pod的应用状态配置自定义探针 #

完全可以，有两种成熟的实现方案：

• 基于就绪探针实现：给应用新增/status检测接口，当Pod处于running job状态时返回非200状态码，处于waiting for job状态时返回200。如果你的Pod不需要承接Service转发的流量，这个方式不会对业务产生任何影响，还能直接把状态同步给K8s原生组件。
• 基于自定义指标实现：就是前面提到的暴露Prometheus指标的方案，灵活性更高，不仅可以给HPA提供决策依据，还能对接监控系统做状态告警。
  也可以额外部署一个轻量sidecar容器，定期检测应用状态，同步更新Pod的Annotation标签，方便其他控制器读取识别Pod状态。

是否可以使用Pod优先级或preStop钩子来实现该需求 #

两种方式都可以落地，各有适用场景：

• Pod优先级方案：先定义两个PriorityClass，高优先级分配给running job状态的Pod，低优先级分配给waiting for job状态的Pod，写一个简单的自定义控制器监听Pod状态变化，当Pod从waiting for job进入running job状态时，动态更新Pod的优先级配置。K8s缩容时会优先终止优先级更低的Pod，从调度层面就避免了杀掉正在运行任务的Pod，逻辑简单，性能损耗极小。
• preStop钩子方案：给Pod配置preStop钩子，执行自定义脚本检测当前应用状态，如果检测到处于running job状态就阻塞等待，直到任务执行完成再退出。需要注意要把Pod的terminationGracePeriodSeconds参数调整到大于你的最长任务耗时，避免K8s超时强制杀掉还没跑完的Pod。这个方案不需要额外开发控制器，直接修改Pod模板即可实现，适合小规模集群使用。
  除此之外你也可以配合PodDisruptionBudget（PDB）规则，给正在运行任务的Pod打专属标签，设置PDB的maxUnavailable: 0，即可保证这类Pod不会被批量驱逐，进一步提升稳定性。

内容的提问来源于stack exchange，提问作者patrick_corrigan