K8S使用deployment 管理Pod以及滚动更新

Posted 2021-03-03

前面有使用pod的举例，但是我们现在有一个Pod正在提供线上的服务，我们来想想一下我们可能会遇到的一些场景：

某次运营活动非常成功，网站访问量突然暴增可以使用【HPA】
运行当前Pod的节点发生故障了，Pod不能正常提供服务了【高可用pod】
后面是解决方法，但是如果没有或者我们不了解底层pod运行模式，需要手动去干预处理，将会非常的麻烦。
第一种情况，可能比较好应对，一般活动之前我们会大概计算下会有多大的访问量，提前多启动几个Pod，活动结束后再把多余的Pod杀掉，虽然有点麻烦，但是应该还是能够应对这种情况的。

第二种情况，可能某天夜里收到大量报警说服务挂了，然后起来打开电脑在另外的节点上重新启动一个新的Pod，问题也很好的解决了。

k8s中已经想到了这些问题所以为我们提供了相对应的机制
Replication Controller（RC）
RC可以保证在任意时间运行Pod的副本数量，能够保证Pod总是可用的。
比如运行2个Pod的节点挂了，RC检测到Pod失败了，就会去合适的节点重新启动一个Pod就行，不需要我们手动去新建一个Pod。
还有就是在之前我们定义了20个pod，一旦流量上来之后，自动扩容，这样可以减少我们人工干预，另外也自动化特别方便。
现在我们来使用RC来管理我们前面使用的nginx的Pod，YAML文件如下：

kind：ReplicationController
spec.replicas: 指定Pod副本数量，默认为1
spec.selector: RC通过该属性来筛选要控制的Pod
spec.template: 这里就是我们之前的Pod的定义的模块，但是不需要apiVersion和kind了
spec.template.metadata.labels: 注意这里的Pod的labels要和spec.selector相同，这样RC就可以来控制当前这个Pod了。

---

意思就是定义了一个RC资源对象，它的名字叫rc-demo，保证一直会有3个Pod运行，Pod的镜像是nginx镜像。

【注意】：注意spec.selector和spec.template.metadata.labels这两个字段必须相同，否则会创建失败的，当然我们也可以不写spec.selector，这样就默认与Pod模板中的metadata.labels相同了

查看一下是否启动：

我们通过RC来修改下Pod的副本数量为2
kubectl edit rc rc-demo

再次查看

我们还可以用RC来进行滚动升级，比如我们将镜像地址更改为nginx:1.7.9

咱们看一下效果

看到了吧，比如我们有2个pod，如果要升级，是先启动一个，然后在删掉原来旧的一个，在启动一个新的，在删掉原来的旧的，一个一个替换，不会直接都删掉的，这样保证了业务对外的不间断性，提高了业务的访问良好
看一下效果



效果非常的好

Replication Set简称RS，随着Kubernetes的高速发展，官方已经推荐我们使用RS和Deployment来代替RC了，实际上RS和RC的功能基本一致
最后我们总结下关于RC/RS的一些特性和作用吧：

大部分情况下，我们可以通过定义一个RC实现的Pod的创建和副本数量的控制
RC中包含一个完整的Pod定义模块（不包含apiversion和kind）
RC是通过label selector机制来实现对Pod副本的控制的
通过改变RC里面的Pod副本数量，可以实现Pod的扩缩容功能
通过改变RC里面的Pod模板中镜像版本，可以实现Pod的滚动升级功能（但是不支持一键回滚，需要用相同的方法去修改镜像地址）
总结：
Replication Controller和Replica Set两种资源对象，RC和RS的功能基本上是差不多的，唯一的区别就是RS支持集合的selector。我们也学习到了用RC/RS来控制Pod副本的数量，也实现了滚动升级Pod的功能

------------------------------===========================------------------------
接下来开始控制器：
Deployment的使用
概念总结
RC的全部功能：Deployment具备上面描述的RC的全部功能
事件和状态查看：可以查看Deployment的升级详细进度和状态
回滚：当升级Pod的时候如果出现问题，可以使用回滚操作回滚到之前的任一版本
版本记录：每一次对Deployment的操作，都能够保存下来，这也是保证可以回滚到任一版本的基础
暂停和启动：对于每一次升级都能够随时暂停和启动

启动一下，然后查看

我们这里重点给大家演示下Deployment的滚动升级和回滚功能。

看一下yaml中有哪些修改

minReadySeconds:
Kubernetes在等待设置的时间后才进行升级
如果没有设置该值，Kubernetes会假设该容器启动起来后就提供服务了
如果没有设置该值，在某些极端情况下可能会造成服务不正常运行

maxSurge:
升级过程中最多可以比原先设置多出的POD数量
例如：maxSurage=1，replicas=5,则表示Kubernetes会先启动1一个新的Pod后才删掉一个旧的POD，整个升级过程中最多会有5+1个POD。

maxUnavaible:
升级过程中最多有多少个POD处于无法提供服务的状态
当maxSurge不为0时，该值也不能为0
例如：maxUnavaible=1，则表示Kubernetes整个升级过程中最多会有1个POD处于无法服务的状态。
看一下升级后的RS

暂停和继续 升级：

比如要回滚

查看有多少个版本
kubectl rollout history deployment nginx-deploy

---

kubectl rollout history deployment nginx-deploy --revision=1

上面是查看信息的
包括每个版本镜像和labels

---

接下来回滚，最好指定版本，不容易混乱
kubectl rollout undo deployment nginx-deploy --to-revision=1

逐个在替换

这个指定版本比较推荐，当然也可以直接使用
kubectl rollout undo deployment nginx-deploy
直接回滚到上个版本，

好了deployment，今天就讲到这里，后面有啥疑问可以私信我，欢迎评论区留言