k8s 如何升级应用

如何升级应用

在之前的分享中，我们知道一个程序如何放到容器中，一个镜像如何生成 pod， pod 的创建，运行，管理，删除过程，挂载等等

那么我们有没有想过，在真正的生产环境中，我们的一个应用程序，不可能就只有一个版本，一定会随着时间不断迭代的，那么，当我们需要替换上我们新版本的程序的时候，我们需要如何替换上新的程序，而又不影响服务端的运行呢？

我们替换程序的时候，我们可以有 2 个选择：

• 可以先删掉旧的 pod，然后创建新的 pod
• 可以先创建新的 pod， 然后删除旧的 pod

可以先删掉旧的 pod，然后创建新的 pod

正常情况下，我们再来回顾一下 pod 都是如何被 Service 和 ReplicaSet / ReplicationController 管理的

如上图，我们可以知道，多个 pod 是被 RS 或者 RC 管理的，可以进行扩容和缩容，他们是通过标签来选择的，Service 同样也是通过标签来选定的

那么先删掉旧的 pod，然后创建新的 pod有啥优缺点呢？

• 优点

操作比较简单，可以直接利用 RC/RS 的扩缩容，直接删除 pod ，然后 RC/RS 会通过标签识别到 pod 的数量变少，进而通过新的镜像来创建 pod

• 缺点

会导致自身的服务有一段时间不能正常提供服务

我们画个图来分享一下先删除 v1 版本的 pod，然后创建 v2 版本的 pod 的过程

一开始 RS 中的指定模板是 v1 版本的镜像，先创建了 3 个 v1 版本的 pod，然后将 RS 的镜像版本改成 v2 版本的，但是由于设定的 pod 数量没有变化，因此 pod 的实际版本还是 v1

现在将 v1 版本的 pod 删掉，RS 会马上创建出指定数量的 v2 版本的 pod ，在这个过程中，服务的提供会出现一定时间的中断

可以先创建新的 pod， 然后删除旧的 pod

那么先创建新的 pod，再删除旧的 pod 我们的思路又是如何的呢，我们可以分享一下？

这个的优点是：

• 应用提供的服务不会中断

这个的缺点是：

• 操作比较麻烦，不符合生产流程，比较繁琐
• 有一段时间同时有 2 个版本的应用程序对外提供服务，这个时候，如果服务的数据对于版本有一定的要求的话，可能会出现异常

一开始，RS 1 设定的 pod 模板是 v1 版本的，这个时候，我们 RS2 指定 v2 版本的 pod 模板，并创建出新的 pod

确定 RS 2 新的 pod 运行正常后，我们将 Service 的流量通过修改标签的方式，将流量切到 v2 版本的 pod 上面

最后设置 RS 1 的指定 pod 数量为 0，进而删除掉 v1 版本的 pod，最后 Service 的流量就完全的切到了 v2 版本的 pod 上面了