北京
自动扩缩容长期缺少可观测性
Kubernetes 里的资源管理自动化，一直需要平台工程师付出很高的信任成本。把 CPU 和内存规格交给 Vertical Pod Autoscaler（VPA）之后，团队期待它能高效地调整容器配置，同时不引入意外重启或性能回退。但对很多在生产环境跑 VPA 的人来说，这个组件过去更像一个黑盒。
想查看 VPA 的决策，以前只能依赖标准 Kubernetes 事件，或者执行 kubectl describe vpa。这些事件是瞬时的，通常一小时后就过期。如果某个 Pod 在夜间批处理任务中被意外驱逐，或者原地扩容因为节点容量限制而静默失败，第二天早上再来定位根因会非常困难。
决策日志进入 Cloud Logging
为了补上这块可观测性缺口，GKE 团队发布了 VerticalPodAutoscaler（VPA）Logs 的公测版。该功能适用于运行 1.36.0-gke.1601000 或更新版本的 GKE 集群，会把结构化的 VPA 决策事件直接写入 Cloud Logging。
垂直扩缩容的决策本身就很复杂。VPA 控制器持续评估历史 CPU 和内存利用率，计算带有上下安全边界的推荐值，并判断当前容器是否需要调整。过去缺少持久化日志时，一些基础运维问题很难回答：为什么 Pod 被调整了规格、推荐值为什么和实际应用值不一致、某次操作为什么被跳过或失败。
现在，VPA 决策事件作为一类控制平面日志（KCP_VPA）导出到 Cloud Logging，平台运营者就拥有了一条永久审计轨迹。再结合已有的 Horizontal Pod Autoscaler（HPA）日志，团队可以在水平和垂直两个扩缩容维度上获得完整可见性。
日志结构与状态字段
VPA 日志由 vpa-controller 控制平面组件发出，存储在 Cloud Logging 的 container.googleapis.com/vpa-controller 日志目标下。每条日志以结构化 JSON 负载形式到达，包含目标工作负载的详细元数据、评估状态以及计算出的资源边界。
每条日志都带有 state 字段，取值为 SUCCEEDED、SKIPPED 或 FAILED，并附带一个解释性的 reason 字符串。当操作成功时，reason 字段会说明实际应用的推荐值是否因为策略上限或 Autopilot 比例约束而与原始推荐值发生偏离。
负载中还有一个 confidence 字段，用来表达本次推荐的可信程度。这个字段让团队在自动化决策之外，仍然可以判断某次调整是否值得人工复核。
如何启用 VPA 决策日志
VPA 日志可以在新建和已有的 GKE 集群上启用，操作通过 Google Cloud CLI 完成。新建集群时，需要在 --logging 标志中加入 KCP_VPA，同时保留 SYSTEM 日志：
gcloud container clusters create CLUSTER_NAME --location=LOCATION --project=PROJECT_ID --logging=SYSTEM,KCP_VPA
对已有集群，也可以通过更新日志配置的方式把 KCP_VPA 加入进来。启用后，VPA 的每一次评估、跳过和失败都会留下结构化记录，不再依赖那些一小时后就消失的瞬时事件。
从黑盒到可审计的自动化
这项能力的意义在于，平台团队终于可以把 VPA 的自动化决策纳入日常排障流程。夜间任务中 Pod 被驱逐，第二天可以从 Cloud Logging 里直接查看对应决策事件，确认是容量限制、策略约束还是评估失败。原地扩容静默失败时，也能通过 FAILED 状态和 reason 字段快速定位原因。
对追求可靠自主工作负载管理的团队来说，VPA 决策日志把“信任自动化”变成了“验证自动化”。每一次资源调整都有据可查，而不是只能靠事后猜测。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
