上节我们讲解了使用Deployment的滚动升级和回滚内容，今来讲解Replication Controller的滚动升级
使用kubectl rolling-update命令完成RC的滚动升级
对于RC的滚动升级，kubernetes还提供了一个 kubectl rolling-update命令进行实现。该命令创建了一个新的RC，然后自动控制旧的RC中的Pod副本数量减少到0，同时新的的RC中的Pod副本数量从0逐个增加到目标值，来完成Pod的升级。需要注意的是，系统要求新的RC与旧的RC都在相同的命名空间内。
以tomcat为例，假设当前运行的tomcat Pod是6.0版本，现在需要升级到7.0版本。
创建tomcat-controller-v1.yaml的配置文件如下：
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
2kind: ReplicationController
3metadata:
4 name: tomcat
5 labels:
6 name: tomcat
7 version: v1
8spec:
9 replicas: 2
10 selector:
11 name: tomcat
12 template:
13 metadata:
14 labels: #可以自己定义key-value
15 name: tomcat
16 spec:
17 containers:
18 - name: tomcat
19 image: tomcat:6.0
20 imagePullPolicy: IfNotPresent
21 ports:
22 - containerPort: 8080
23 env: #环境变量
24 - name: GET_HOSTS_FROM
25 value: dns
26
27
创建tomcat-controller-v2.yaml的配置文件如下：
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
2kind: ReplicationController
3metadata:
4 name: tomcat2
5 labels:
6 name: tomcat
7 version: v2
8spec:
9 replicas: 2
10 selector:
11 name: tomcat2
12 template:
13 metadata:
14 labels: #可以自己定义key-value
15 name: tomcat2
16 spec:
17 containers:
18 - name: tomcat
19 image: tomcat:7.0
20 imagePullPolicy: IfNotPresent
21 ports:
22 - containerPort: 8080
23 env: #环境变量
24 - name: GET_HOSTS_FROM
25 value: dns
26
在执行过程中我们可以重新开一个窗口，用kubectl get rc 命令查看
滚动更新完成后再次查看，注意名字恢复了。
可见升级成了7.0
在配置文件中需要注意以下两点。
◎ RC的名字（name）不能与旧RC的名字相同。
◎ 在selector中应至少有一个Label与旧RC的Label不同，以标识其为新RC。在本例中新增了一个名为version的Label，以与旧RC进行区分。即确保同一个Key至少有一个Value不一个。
等所有新的Pod都启动完成后，旧的Pod也被全部销毁，这样就完成了容器集群的更新工作。
另一种方法是不使用配置文件，直接用kubectl rolling-update命令，加上–image参数指定新版镜像名称来完成Pod的滚动升级：
2
2
与使用配置文件的方式不同，执行的结果是旧RC被删除，新RC仍将使用旧RC的名称。
可以看到，kubectl通过新建一个新版本Pod，停掉一个旧版本Pod，如此逐步迭代来完成整个RC的更新。
可以看到，kubectl给RC增加了一个key为“deployment”的Label（这个key的名字可通过–deployment-label-key参数进行修改），Label的值是RC的内容进行Hash计算后的值，相当于签名，这样就能很方便地比较RC里的Image名字及其他信息是否发生了变化。
如果在更新过程中发现配置有误，则用户可以中断更新操作，并通过执行kubectl rolling- update –rollback完成Pod版本的回滚：
2
2
至此，可以看到Pod恢复到更新前的版本了。
可以看出，RC的滚动升级不具有Deployment在应用版本升级过程中的历史记录、新旧版本数量的精细控制等功能，在Kubernetes的演进过程中，RC将逐渐被RS和Deployment所取代，建议用户优先考虑使用Deployment完成Pod的部署和升级操作。
其他管理对象的更新策略
Kubernetes从1.6版本开始，对DaemonSet和StatefulSet的更新策略也引入类似于Deployment的滚动升级，通过不同的策略自动完成应用的版本升级。
1.DaemonSet的更新策略
目前DaemonSet的升级策略包括两种：OnDelete和RollingUpdate。
（1）OnDelete：DaemonSet的默认升级策略，与1.5及以前版本的Kubernetes保持一致。当使用OnDelete作为升级策略时，在创建好新的DaemonSet配置之后，新的Pod并不会被自动创建，直到用户户手动删除旧版本的Pod，才触发新建操作。
（2）RollingUpdate：从Kubernetes 1.6版本开始引入。当使用RollingUpdate作为升级策略对DaemonSet进行更新时，旧版本的Pod将被自动杀掉，然后自动创建新版本的DaemonSet Pod。整个过程与普通Deployment的滚动升级一样是可控的。不过有两点不同于普通Pod的滚动升级：一是目前Kubernetes还不支持查看和管理DaemonSet的更新历史记录；二是DaemonSet的回滚（Rollback）并不能如同Deployment一样直接通过kubectl rollback命令来实现，必须通过再次提交旧版本配置的方式实现。
2.StatefulSet的更新策略
Kubernetes从1.6版本开始，针对StatefulSet的更新策略逐渐向Deployment和DaemonSet的更新策略看齐，也将实现RollingUpdate、Paritioned和OnDelete这几种策略，以保证StatefulSet中各Pod有序地、逐个地更新，并且能够保留更新历史，也能回滚到某个历史版本。
小结：
今天的内容就说到这里了，希望大家可以多多点关注哦！
谢谢大家的支持！
