Expedia 的性能和可靠性团队最近 开源了 其 容器启动自动扩缩器（container-startup-autoscaler，CSA）。CSA 是一个 Kubernetes 控制器，利用 Pod 资源的原地资源更新（In-Place Update of Pod Resources）特性，在启动过程中基于用户定义的启动时 / 启动后配置动态调整容器的 CPU 和 / 或内存资源。
Pod 资源的原地资源更新特性自 Kubernetes 1.27.0 进入 alpha 状态。该功能能够修改 Pod 资源（请求和限制），而无需重启 Pod。在此之前，对 Pod 的所有调整都必须重启 Pod 才能实现。
在 Kubernetes 工作负载的管理中，有一个长期存在的问题，那就是如何优化容器资源，以便于适应在启动阶段和启动后阶段展现出截然不同资源使用模式的工作负载。在原地资源更新特性引入之前，在启动密集型工作负载时，需要在实现一致的启动时间和尽量减少启动后资源浪费之间做出权衡：
a.设置高于请求的限制，在启动期间预留超出请求的资源
b.由于依赖于集群节点的负载情况，启动时间无法预测
c.启动后的性能也可能不稳定，原因在于额外回收（scavenged）资源的不确定性，尤其是在集群联合的机制中
2.确保 QoS（1）:
a.建立与请求相等的限制，优先考虑启动时间
b.可预测的启动时间和启动后性能，但是可能会造成浪费，尤其是在 Pod 副本数量过多的情况下
3.确保 QoS（2）:
a.设置与请求相等的限制，强调正常工作负载服务的性能
b.可预测和可接受的启动后性能，但代价是启动时间较慢，从而会延长部署的持续时间和水平扩展的反应时间，影响运行效率
容器启动自动扩缩器（CSA）在 Pod 级别运行。它与各种工作负载管理 API（如 Deployments、StatefulSets 和 DaemonSets）集成，确保不同 Pod 管理方法之间的兼容性。它既支持初始的容器启动，也支持 Kubernetes 启动的重启操作。
CSA 的逻辑模式
CSA 可关注 Pod 中的单个 non-init/ephemeral 容器。目标容器的名称和所需的启动时 / 启动后资源配置等细节信息都封装在特定 Pod 的注解中。
CSA 在监控要用于扩展的 Pod（通过标签识别）时，会对这些 Pod 中的变化做出响应。当探测出符合条件的 Pod 发生变化，CSA 就会评估目标容器的当前状态，并根据其状态执行如下所示的某个操作：
CSA 会在其 Pod 创建目标容器时以及 Kubernetes 重新启动目标容器时进行干预。CSA 在不必要时会避免执行扩缩操作。例如，如果目标容器在准备就绪前反复启动失败（促使 Kubernetes 以 CrashLoopBackOff 的方式重新启动），在这种情况下，CSA 只会应用一次启动资源。此外，CSA 还会生成度量指标、Kubernetes Pod 事件和详细的状态更新，所有的这些内容都会纳入到扩展的 Pod 注解中。
CSA 有一些限制：
CSA 的主要目标是让 Kubernetes 工作负载管理员在启动过程中精细调整容器资源，而不必在启动后进行资源配置，从而减少相关的权衡。这种方法有助于实现如下目标：
到 Kubernetes 1.29 为止，CSA 所依赖的 Pod 资源原地更新特性还处于 alpha 阶段。因此，CSA 功能需要启用 InPlacePodVerticalScaling 特性门控（feature gate）。鉴于该特性和 CSA 实现都在持续开发中，建议谨慎使用。在达到稳定状态之前，Expedia 团队建议仅将 CSA 用于本地或非生产 Kubernetes 环境中进行预览。
查看英文原文：
Expedia Opensourced Its Container-Startup-Autoscaler (CSA) for Kubernetes Workloads (
