问题描述
在使用Kubernetes进行部署时，面临一个问题：如何在部署时最小化通过Websocket连接的客户端中断。用户的堆栈包括GKE（区域性集群 – 1.22.8-gke.200）、Helm、Node.js/Websockets、HPA、滚动更新。用户的Kubernetes集群由处理和连接两类微服务组成。连接的微服务（称为ws-gateway）负责维护与客户端的Websocket连接。用户希望尽量保持连接活跃，即使在发布新版本的ws-gateway时，也能将连接保持到尽可能长的时间。客户端在重新建立连接时可能需要最多5分钟，但用户无法影响客户端的这种连接行为。
用户的目标是通过优化发布策略，使客户端仅需进行一次断开连接的操作。
解决方案
以下操作可能涉及版本差异或风险操作，请确保在执行操作前进行备份。
为了在部署时最小化Websocket连接的中断，可以采用以下策略：
1. 使用服务中的选择器
这种方法涉及为Pods添加标签以标识其版本，并通过Service的选择器将流量路由到新版本的Pods。以下是具体步骤：
- 在Pod模板中为每个版本的Pod添加适当的标签，例如
version: v1和version: v2。 - 在Service配置中，使用选择器将流量路由到新版本的Pods，例如选择
version: v2的Pods。
这样，只有选择器匹配的Pods才会接收流量。但是，需要注意以下问题：
- 当更新Service时，新的选择器配置将生效。这可能会导致流量切换到新版本的Pods，中断与旧版本的连接。
为了解决这个问题，你可以考虑以下方法：
- 在更新Service之前，确保先升级Pod版本。这可以通过控制Deployment的副本数来实现，逐步增加新版本Pods的副本数，然后再逐步减少旧版本Pods的副本数。
2. 使用Ingress和加权金丝雀部署
使用Ingress和加权金丝雀部署可以实现逐步切换流量到新版本的Pods。以下是一些步骤：
- 使用Nginx Ingress控制器，确保集群中有一个Ingress资源，它将流量路由到现有的Service（TCP类型）。
- 配置Ingress资源，使用
nginx.ingress.kubernetes.io/canary-weight注释来指定金丝雀流量的权重。
这样，你可以逐步增加新版本Pods的权重，实现流量逐渐切换。但需要注意：
- 加权金丝雀部署可能需要一些调整和测试，以确保在逐步切换流量时不会中断连接。
3. 蓝/绿部署
蓝/绿部署是一种在发布新版本时一次性切换所有流量到新版本的方法。这可能不符合用户的要求，因为他们希望在部署过程中客户端连接仍然保持活跃。
4. 使用Anthos（GCP Service Mesh）
使用Anthos等服务网格工具可以实现更复杂的部署策略，但可能会增加复杂性，适用于更大规模的部署。
5. 引发readinessProbe失败
这个方法可以考虑，但并不是官方的使用方式。通过故意使旧版本Pods的readinessProbe失败，可以将它们从Service中移除，从而逐步切换流量。但这可能会导致其他问题，并且不是一种优雅的解决方案。
请根据实际情况选择适合的部署策略，并在实际操作前进行充分的测试和验证。注意，不同的策略可能在不同的集群环境中表现不同，所以需要根据实际情况做出调整。
希望这些解决方案能够帮助你优化发布策略，最小化Websocket连接中断，达到预期的部署效果。如果你有关于其他选项的进一步疑问，可以深入阅读有关Ingress、金丝雀部署和蓝/绿部署的文档，以获取更多的见解。