问题描述
在使用Node.js和GKE时，有一个需求是希望在应用程序有新版本正在部署时，能够使就绪探针失败。用户的应用程序使用websockets与客户端进行连接。在进行滚动更新时，客户端可能会连接到旧的Pod或新的Pod。用户希望最小化客户端的断开连接，并强制它们只连接到最新版本的Pod。用户希望最大化客户端连接的正常运行时间，不能容忍客户端多次连接/断开连接。
用户考虑使用就绪探针来实现这个目的。用户需要在滚动更新时，使旧的Pod的就绪探针失败。
用户不能使用重新创建策略，因为同时重新连接所有客户端会对系统产生很大的负载。
用户提出了一个想法，即使用ConfigMap来存储应用程序的最新版本，并通过就绪探针来比较当前版本和最新版本。如果不相等，则探针失败。
用户想知道是否有其他加速ConfigMap同步的方法，并且在回滚时会发生什么。
解决方案
请注意以下操作注意版本差异及修改前做好备份。
方案1
使用ConfigMap来存储应用程序的最新版本，并通过就绪探针来比较当前版本和最新版本。如果不相等，则探针失败。
以下是实现这个方案的步骤：
1. 创建一个ConfigMap，将最新版本的应用程序存储在其中。
2. 在应用程序的健康检查端点（/health）中返回当前版本和最新版本。
3. 就绪探针使用exec/curl命令来GET /health，并比较当前版本和最新版本。如果不相等，则探针失败。
请注意，ConfigMap的同步可能需要一些时间。为了加速同步，你可以尝试以下方法：
– 使用kubectl rollout restart deployment命令来重启Deployment，这将触发Pod的重新创建，并在重新创建时同步ConfigMap。
– 使用kubectl patch deployment命令来更新Deployment的标签，这将触发Pod的重新创建，并在重新创建时同步ConfigMap。
在回滚时，你需要更新ConfigMap并使就绪探针失败。你可以编写逻辑来更新ConfigMap，并使用kubectl apply -f命令来应用更新后的ConfigMap。
方案2
另一种方法是使用重新创建策略来滚动更新Pod。这将确保在部署新Pod之前终止旧Pod。
以下是使用重新创建策略的步骤：
1. 在Deployment的配置中将spec.strategy.type设置为Recreate。
2. 当进行滚动更新时，所有现有的Pod都会被终止，然后创建新的Pod。
请注意，使用重新创建策略可能会导致所有客户端同时重新连接，这可能会对系统产生较大的负载。你需要评估系统的负载能力，并根据实际情况选择合适的策略。
总结
在应用程序有新版本正在部署时，你可以使用ConfigMap来存储最新版本，并通过就绪探针来比较当前版本和最新版本。如果不相等，则探针失败。另一种方法是使用重新创建策略来滚动更新Pod。请根据实际情况选择合适的方案。
请注意以上操作可能存在版本差异，请在操作前做好备份并根据实际情况进行调整。
以上是解决这个问题的两种方案，你可以根据自己的需求选择合适的方案。希望对你有帮助！