一个 Kubernetes 应用程序拉取 Pub/Sub 消息并写入 Filestore；单个 Pod 无法实时处理消息，导致消息积压。处理过程是 I/O 密集型的。您应该如何扩展处理能力？

正确答案是配置由 subscription/numundeliveredmessages Pub/Sub 指标驱动的 Kubernetes 自动扩缩部署。由于处理过程是 I/O 密集型的，CPU 利用率可能不是瓶颈，因此基于 CPU 的自动扩缩（选项一）可能无法有效解决消息积压。启用集群自动扩缩（选项三）可以增加节点，但不会直接根据应用程序负载调整 Pod 数量。subscription/pushrequestlatencies（选项二）衡量的是推送请求的延迟，而不是未处理消息的数量，可能无法准确反映积压情况。subscription/numundeliveredmessages 指标直接反映了 Pub/Sub 订阅中未被处理的消息数量，这正是导致消息积压的根本原因。通过此指标驱动自动扩缩，可以确保当消息积压时，Kubernetes 自动增加 Pod 数量来处理负载，从而有效解决问题。