当集群中某个服务需要升级时，我们可能需要停止目前与该服务相关的所有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
来源：掘金
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
网友评论