全应用级滚动更新
全应用级滚动更新
提问于 2022-01-09 15:30:34
我的kubernetes应用程序由几种类型的节点组成，一些“调度器”将任务发送给更多的“工作者”节点。为了使该应用程序正确工作，所有节点必须完全相同的代码版本。
部署是使用一个标准的ReplicaSet执行的，当我的CICD启动它时，只需要做一个简单的滚动更新。这导致了一个问题，因为在滚动更新过程中，不同代码版本的节点共存了几秒钟，因此这段时间内的一些任务会产生错误的结果。
理想情况下，我想要的是，部署一个新版本将创建一个完全新的应用程序，它只与自身通信，并有时间来温暖缓存，然后在切换时，这个新应用程序就会活跃起来，并开始接收新的客户端请求。旧的应用程序将保持活跃的几秒钟，然后关闭。
我在用Istio sidecar进行mesh通讯。
有什么标准的方法吗？这样的要求通常是如何处理的？
回答 2
Stack Overflow用户
发布于 2022-01-09 17:00:00
我也遇到过这样的情况。单靠Kubernetes无法满足您的需求，我也无法找到任何允许将多个部署协调在一起的工具(尽管旗杆看起来很有希望)。
因此，我发现的唯一方法是在我的案例中使用CI/CD: Jenkins。我没有代码，但是我的想法是：
- 使用单个Helm图表部署所有应用程序。每个Helm发布名称和相应的Kubernetes标签必须基于某些顺序编号，例如Jenkins
$BUILD_NUMBER。Helm发行版可以像example-app-${BUILD_NUMBER}一样命名，所有部署都必须有标签version: $BUILD_NUMBER。这里的重要部分是您的Services不应该是您的Helm图表的一部分，因为它们将由Jenkins处理。 - 从检测应用程序的当前版本开始构建(使用bash脚本，或者可以将其存储在
ConfigMap中)。 - 在设置
helm install example-app-{$BUILD_NUMBER}标志的情况下启动--atomic。原子标志将确保在失败时正确地删除版本。也不要删除之前版本的应用程序。 - 等待Helm完成，如果成功，请运行
kubectl set selector service/example-app version=$BUILD_NUMBER。这将立即将KubernetesService从一个版本切换到另一个版本。如果您有多个服务，您可以发出多个set selector命令(每个命令立即执行)。 - 删除以前的Helm发行版，并可选择使用新的应用程序版本更新
ConfigMap。
根据应用程序的不同，您可能希望在面向Services的非用户上运行测试，作为步骤4的一部分(在Helm发布成功之后)。
另一个好主意是在员工吊舱上安装preStop挂钩，这样他们就可以在被删除之前完成他们的工作。
Stack Overflow用户
发布于 2022-01-11 03:42:02
你应该考虑蓝色/绿色部署策略
页面原文内容由Stack Overflow提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接：
https://stackoverflow.com/questions/70642776
复制相关文章
相似问题
腾讯云开发者
