我有两个彩色曲目，我部署了两个不同版本的webapp（nginx + php-fpm），这些曲目可以通过服务获得，称为live和next。
经典的方法是将新版本的webapp部署到下一个，经过检查，通过切换服务将其发布到实时。
到现在为止还挺好。
考虑使用HPA进行自动缩放：在进行发布之前，我必须在活动pod的数量旁边进行预分频，以防止切换后负载过重。
这里的问题是HPA CPU负载测量的性质。在最坏的情况下，自动调节器会立即缩小预分频轨道的尺寸，从而计算来自下一个的cpu负载。
我发现的另一个问题是使用keepalive连接，这使得释放新的pod非常坚硬而不会杀死旧的pod。
如何解决问题？
我们有一些部署策略（还有更多，但我会指出最常见的）。
1）滚动更新 - 我们只需要一个部署。它会将包含新内容的pod添加到当前部署中，并在同一时间终止旧版本pod。有一段时间部署将包含新旧版本的混合。
2）蓝绿部署 - 这是最安全的策略，建议用于生产工作负载。我们需要共存两个部署，即v1和v2。在大多数情况下，旧部署正在耗尽（关闭与旧部署的所有连接/会话）并将所有新会话/连接重定向到新部署。通常情况下，这两个部署都会在生产和舞台上保持一段时间。
3）金丝雀部署 - 最难的部署。在这里，您还需要至少两个同时运行的部署。有些用户将连接到旧应用程序，其他用户将被重定向到新应用程序。它可以通过加载balancig /代理层配置来实现。在这种情况下，不允许使用HPA，因为我们同时使用两个部署，每个部署都有自己独立的自动扩展器。
就像@Mamuz在评论中指出的那样，在没有切换服务级别的情况下，Blue-Green策略听起来比滚动更新更好。
在这种情况下可能有用的另一个选项是使用流量转移的ISTIO进行蓝绿色部署。在此选项中，您可以将流量分为请求，即从100-0,80-20,60-40,20-80到0-100％
在this文章中描述了逐步使用ISTIO和HPA。 您可以阅读有关交通管理here的信息。 Istio和K8s here的例子。