我有两个彩色的轨道，分别在其中部署了两个不同版本的Web应用程序（nginx + php-fpm），这些轨道可通过服务（实时和下一个）获得。
经典方法是将新版本的webapp部署到下一个，经过检查后，通过切换服务将其发布以供使用。
到目前为止很好。
考虑使用HPA自动缩放： 在发布之前，我必须在活动吊舱的数量旁边进行预缩放，以防止切换后负载过重。
这里的问题是HPA cpu负载测量的本质。在最坏的情况下，自动缩放器会立即缩小预缩放的轨道，这是因为计算cpu负载的原因来自下一个。
我发现的另一个问题是使用Keepalive连接，这使释放新Pod的生活变得十分艰苦，而又不杀死旧Pod。
如何解决问题？
答案 0 :(得分：0)
我们有一些部署策略（还有更多部署策略，但我会指出最常见的策略）。
1）滚动更新-我们只需要进行一次部署。它将具有新内容的容器添加到当前部署中，并同时终止旧版本的容器。在一段时间内，部署将包含新旧版本的混合。
2）蓝绿色部署-这是最安全的策略，建议用于生产工作负载。我们需要同时存在两个部署，即v1和v2。在大多数情况下，旧的部署会耗尽（将所有连接/会话关闭到旧的部署），并将所有新的会话/连接重定向到新的部署。通常，这两种部署都会在生产和阶段中保持一段时间。
3）金丝雀部署-最困难的部署。在这里，您还需要至少两个同时运行的部署。一些用户将连接到旧的应用程序，其他用户将被重定向到新的应用程序。这可以通过负载平衡/代理层配置来实现。在这种情况下，不允许使用HPA，因为我们同时使用两个部署，每个部署将具有自己的独立自动缩放器。
就像@Mamuz在评论中指出蓝绿色策略（未开启） 在这种情况下，服务水平听起来要比滚动更新好得多。
在这种情况下可能有用的另一个选项是蓝绿色 使用流量转移使用ISTIO进行部署。在此选项中，您 可以根据请求划分流量，即从100-0、80-20、60-40、20-80 到0-100％
this文章中介绍了逐步使用ISTIO和HPA。
您可以阅读有关流量管理here的信息。
Istio和K8s here的示例。