上节我们讲解了使用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的配置文件如下：

apiVersion: v1
kind: ReplicationController
metadata:
  name: tomcat
  labels:
    name: tomcat
    version: v1
spec:
  replicas: 2
  selector:
    name: tomcat
  template:
    metadata:
      labels:   #可以自己定义key-value
        name: tomcat
    spec:
      containers:
      - name: tomcat
        image: tomcat:6.0
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 8080
        env:             #环境变量
        - name: GET_HOSTS_FROM
          value: dns

 

创建tomcat-controller-v2.yaml的配置文件如下：

ersion: v1
kind: ReplicationController
metadata:
  name: tomcat2
  labels:
    name: tomcat
    version: v2
spec:
  replicas: 2
  selector:
    name: tomcat2
  template:
    metadata:
      labels:   #可以自己定义key-value
        name: tomcat2
    spec:
      containers:
      - name: tomcat
        image: tomcat:7.0
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 8080
        env:             #环境变量
        - name: GET_HOSTS_FROM
          value: dns

 

在执行过程中我们可以重新开一个窗口，用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的滚动升级：

kubectl rolling-update tomcat --image=tomcat:6.0

与使用配置文件的方式不同，执行的结果是旧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版本的回滚：

kubectl rolling-update tomcat --image=tomcat:6.0 --rollback

至此，可以看到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有序地、逐个地更新，并且能够保留更新历史，也能回滚到某个历史版本。

 

 

小结：

         今天的内容就说到这里了，希望大家可以多多点关注哦！

          谢谢大家的支持！