1

我的 kubernetes 应用程序由几种类型的节点组成，几个“调度程序”将任务发送到更多的“工作”节点。为了使此应用程序正常工作，所有节点必须具有完全相同的代码版本。

部署是使用标准 ReplicaSet 执行的，当我的 CICD 启动时，它只是进行简单的滚动更新。这会导致一个问题，因为在滚动更新期间，不同代码版本的节点共存了几秒钟，因此在此期间有一些任务会得到错误的结果。

理想情况下，我想要的是部署一个新版本将创建一个全新的应用程序，该应用程序只与自身通信并有时间预热其缓存，然后轻按一下开关，这个新应用程序就会变得活跃并开始获取新的客户端请求. 旧应用程序将保持活动状态几秒钟，然后关闭。

我正在使用 Istio sidecar 进行网状通信。

有没有标准的方法来做到这一点？通常如何处理这样的要求？

4

2 回答 2

2

I also had such a situation. Kubernetes alone cannot satisfy your requirement, I was also not able to find any tool that allows to coordinate multiple deployments together (although Flagger looks promising).

So the only way I found was by using CI/CD: Jenkins in my case. I don't have the code, but the idea is the following:

  1. Deploy all application deployments using single Helm chart. Every Helm release name and corresponding Kubernetes labels must be based off of some sequential number, e.g. Jenkins $BUILD_NUMBER. Helm release can be named like example-app-${BUILD_NUMBER} and all deployments must have label version: $BUILD_NUMBER . Important part here is that your Services should not be a part of your Helm chart because they will be handled by Jenkins.

  2. Start your build with detecting the current version of the app (using bash script or you can store it in ConfigMap).

  3. Start helm install example-app-{$BUILD_NUMBER} with --atomic flag set. Atomic flag will make sure that the release is properly removed on failure. And don't delete previous version of the app yet.

  4. Wait for Helm to complete and in case of success run kubectl set selector service/example-app version=$BUILD_NUMBER. That will instantly switch Kubernetes Service from one version to another. If you have multiple services you can issue multiple set selector commands (each command executes immediately).

  5. Delete previous Helm release and optionally update ConfigMap with new app version.

Depending on your app you may want to run tests on non user facing Services as a part of step 4 (after Helm release succeeds).

Another good idea is to have preStop hooks on your worker pods so that they can finish their jobs before being deleted.

于 2022-01-09T17:00:00.127 回答
0

您应该考虑蓝/绿部署策略

于 2022-01-11T03:42:02.550 回答