[转]K8S学习笔录 - Deployment的升级和回滚

当集群中某个服务需要升级时，我们可能需要停止目前与该服务相关的所有Pod，然后下载新版本镜像并创建新的Pod。

然而这个升级/回滚方案在集群较大的时候代价是巨大的，会导致较长时间的服务不可用。K8S提供了滚动升级功能来解决这些问题。

不同的管理对象的更新配置和操作是不同的

对于Deployment来讲，更新的过程如下

Deployment的ReplicaSet原本有3个Pod副本

在更新开始前，创建一个新的ReplicaSet对象，配置与旧的ReplicaSet一致

根据更新规则，逐渐扩容新的RS、缩容旧的RS，直到新的RS容量与旧的一致、旧的RS容量为0

根据存储历史版本配置决定是否删除超出存储数量的历史ReplicaSet

配置

升级

当前拥有一个名为nginx-deployment的Deployment对象

假如要将其nginx版本从1.13.0升级到最新的1.14.0

有两种方案可以进行升级，效果一样

通过执行kubectl edit (RESOURCE/NAME | -f FILENAME) [options]

具体用法可以通过kubectl edit --help查看

通过执行kubectl set SUBCOMMAND [options]

具体用法可以通过kubectl set --help查看

我们使用第二种方案进行升级

我们可以根据上面的信息看到

Annotations:            deployment.kubernetes.io/revision: 2

当前Deployment的版本是2

RollingUpdateStrategy:  25% max unavailable, 25% max surge

此Deployment对象的滚动升级策略为最多25%不可用，最多同时升级25%的Pod，Events信息中的行为与配置要求行为完全一致

Replicas:              3 desired | 2 updated | 4 total | 3 available | 1 unavailable

当前的更新进度，也可以通过kubectl rollout status deployments nginx-deployment来监听

Conditions:

当前Deployment可用，正在进行ReplicaSet升级

OldReplicaSets:  ...  NewReplicaSet:  ...

存在的新旧ReplicaSets信息

Events: ...

当前Deployment对象发生的事件

最终状态下，原来的nginx-deployment-7f555c9b4b中Pod的数量将会变成0，而新的nginx-deployment-58cdcbb467中的Pod数量将会变为3

由于Deployment的配置中保留历史版本数使用了默认的10，所以旧的RS会与新的同时存在，用于回滚

回滚

可以使用kubectl rollout命令来对Deployment进行回滚，通过kubectl rollout --help查看具体用法

在回滚版本前，可以通过kubectl rollout history来查看当前存在的版本

如果在创建Deployment的时候，使用了--record参数，每次Deployment被修改的时候，还会记录下来修改的命令

作者：LIYUNFAN

链接：https://juejin.cn/post/6844904051247710222

来源：掘金

著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

作者：LIYUNFAN

链接：https://juejin.cn/post/6844904051247710222

来源：掘金

著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

作者：LIYUNFAN

链接：https://juejin.cn/post/6844904051247710222

来源：掘金

著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

作者：LIYUNFAN

链接：https://juejin.cn/post/6844904051247710222

来源：掘金

著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。