08-Kubernetes Pod控制器—ReplicaSet

一、Pod控制器

1、Pod控制器的类型

（1）ReplicaSet（是ReplicationController的替代品）

• 核心作用在于：代用户创建指定数量的Pod副本并确保Pod副本一直处于，满足用户期望的数量的状态。多退少补。支持的操作：

1. 自动扩缩容—扩缩容的四种方法：【1】、在ReplicaSet的yaml文件中修改replicas的值；【2】、输入命令"kubectl  edit  rs  rs的名称"，然后修改里面的replicas的值；【3】、在命令行输入kubectl  scale...；【4】、在命令行输入kubectl patch...。
2. 声明性配置的逻辑（这种声明式配置的逻辑使得，创建资源时可以使用基于声明的逻辑来定义，那些所有更新的资源可以随时重新进行声明，随时改变在Apiserver上定义的目标期望状态，只要那些资源支持动态运行时的修改，可以用apply来管理）。
3. 手动更新升级—手动升级的四种方法：【1】、在ReplicaSet的yaml文件中修改容器的image的值；【2】、输入命令"kubectl  edit  rs  rs的名称"，然后修改里面的image的值；【3】、在命令行输入kubectl  set image...（注意：这种方法只针对修改镜像的版本）；【4】、在命令行输入kubectl patch...。

• 主要的组件：【1】、用户期望的Pod副本；【2】、标签选择器；【3】、新建Pod的模板
• K8s不建议使用ReplicaSet

（2）Deployment（工作在ReplicaSet之上，即Deployment管理ReplicaSet，再由ReplicaSet去管理Pod）—用来管理无状态应用的最好的控制器。

• 支持的操作：

1. ReplicaSet支持的自动扩缩容—扩缩容的四种方法：【1】、在ReplicaSet的yaml文件中修改replicas的值；【2】、输入命令"kubectl  edit  rs  rs的名称"，然后修改里面的replicas的值；【3】、在命令行输入kubectl  scale...；【4】、在命令行输入kubectl patch...。
2. 声明性配置的逻辑（这种声明式配置的逻辑使得，创建资源时可以使用基于声明的逻辑来定义，那些所有更新的资源可以随时重新进行声明，随时改变在Apiserver上定义的目标期望状态，只要那些资源支持动态运行时的修改，可以用apply来管理）。
3. 手动更新升级—手动升级的四种方法：【1】、在ReplicaSet的yaml文件中修改容器的image的值；【2】、输入命令"kubectl  edit  rs  rs的名称"，然后修改里面的image的值；【3】、在命令行输入kubectl  set image...（注意：这种方法只针对修改镜像的版本）；【4】、在命令行输入kubectl patch...。
4. 自动滚动更新升级—自动升级的四种方法：【1】、在ReplicaSet的yaml文件中修改容器的image的值；【2】、输入命令"kubectl  edit  rs  rs的名称"，然后修改里面的image的值；【3】、在命令行输入kubectl  set image...（注意：这种方法只针对修改镜像的版本）；【4】、在命令行输入kubectl patch...。
5. 自动回滚

• 主要的组件：【1】、用户期望的Pod副本；【2】、标签选择器；【3】、新建Pod的模板

（3）DaemonSet

• 支持的操作：

1. 声明性配置的逻辑（这种声明式配置的逻辑使得，创建资源时可以使用基于声明的逻辑来定义，那些所有更新的资源可以随时重新进行声明，随时改变在Apiserver上定义的目标期望状态，只要那些资源支持动态运行时的修改，可以用apply来管理）。
2. 手动更新升级—手动升级的四种方法：【1】、在ReplicaSet的yaml文件中修改容器的image的值；【2】、输入命令"kubectl  edit  rs  rs的名称"，然后修改里面的image的值；【3】、在命令行输入kubectl  set image...（注意：这种方法只针对修改镜像的版本）；【4】、在命令行输入kubectl patch...。
3. 自动滚动更新升级—自动升级的四种方法：【1】、在ReplicaSet的yaml文件中修改容器的image的值；【2】、输入命令"kubectl  edit  rs  rs的名称"，然后修改里面的image的值；【3】、在命令行输入kubectl  set image...（注意：这种方法只针对修改镜像的版本）；【4】、在命令行输入kubectl patch...。
4. 自动回滚

• 用于确保集群中的每一个Node节点只运行一个特定的Pod副本。通常用来实现系统级的后台任务。
• 把系统级的后台任务托管到K8s上的好处：【1】、系统级的后台任务down掉之后，可以被DeamonSet控制器自动重构。（如果以守护进程的方式，来运行。其缺点在于：系统级的后台任务down掉后，没法被重构）；【2】、当系统中想增加一个Node节点的时候，DaemonSet会自动在该Node节点上，增加该系统级的后台任务。
• DeamonSet中不能够自定义，期望运行的Pod数量。因为每个Node节点上只能运行一个Pod。
• 主要的组件：【1】、标签选择器；【2】、新建Pod的模板
• DaemonSet也可以根据自己的需求，在满足条件的部分Node节点中的每个Node上运行一个Pod。

（4）Job

• 在K8s集群上，可以根据用户指定的数量启动指定数量的Pod。Pod启动之后，开始执行自己应该完成的任务。如果，任务还没有完成，Pod挂掉了或是不小心删除了，那么Pod就会重启；如果，任务完成了，Pod需要正常退出，不需要重启。

（5）CronJob

• 与Job类似，只是Job是一次性的，而CronJob是周期性的。悲剧的是：如果上一次任务还没有完成，就到了下一个周期，你怎么办？所以，CronJob还要处理并解决此类问题。

（6）StatefluSet—用来管理无状态应用的最好的控制器。

• StatefulSet管理的每个Pod副本都是被单独管理的，拥有着自己独有的标识和独有的数据集。一旦这个Pod挂掉了，新的Pod重启之前，需要进行很多操作。（所以需要进行的操作，要写在一个脚本文件中，而且将这个脚本文件放在“新建Pod的模板”中—这个难度相当的大）

（7）正是因为StatefulSet管理Pod难度相当大，所以就引入了下面的东西

• TPR：Third Party Resources（第三方资源）。K8s的1.2版本增加了TPR，1.8版本又删除了TPR，引入了下面的东西
• CDR：Cluster Defined Resources（自定义资源）。K8s 1.8版本后支持CDR。

2、Deployment和DaemonSet的共同特点

• 所管理的Pod所提供的服务是无状态的。
• 所管理的Pod所提供的服务必须是守护进程类的，必须始终持续地运行在后台。不忙的时候，也需要监听文件的变动或用户对某套接字的访问请求。

3、Job、CronJob与Deployment、DaemonSet的不同点

• Deployment、DaemonSet所管理的Pod是要始终运行的；Job、CronJob所管理的Pod不是始终运行的，Pod需要执行的任务完成之后，可以正常退出。 

4、Helm—Kubernetes包管理器。类似于yum。

二、ReplicaSet（简称rs）

[root@master manifests]# vim rs-demo.yaml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
        name: myapp
        namespace: default
spec:
        replicas: 2 
        selector: 
                matchLabels:   #基于等值关系的标签选择器
                        app: myapp
                        release: canary
        template:
                metadata:
                        name: myapp-pod   #这里的name配置没有什么实际的意义（不会生效），Pod的名字默认是以ReplicaSet的名字myapp开头，并在后面紧跟"-和一串随机的数字"。这里不用配置namspace，这是因为容器的namespace必须与上面ReplicaSet里面的namespace相同
                        labels:      #这里容器的标签必须包含上面replicaSet中的标签选择器中定义的标签
                                app: myapp
                                release: canary
                                environment: qa
                spec:
                        containers:
                        - name: myapp-container
                          image: nginx:latest
                          ports:
                          - name: http
                            containerPort: 80


[root@master manifests]# kubectl create -f rs-demo.yaml 


[root@master manifests]# kubectl get rs
NAME    DESIRED   CURRENT   READY   AGE
myapp   2         2         2       4m49s


[root@master manifests]# kubectl get pods 
NAME          READY   STATUS    RESTARTS   AGE
myapp-2p9mt   1/1     Running   0          7m5s
myapp-qcn2c   1/1     Running   0          7m5s



[root@master manifests]# kubectl describe pods myapp-qcn2c    #随便查看其中的一个Pod
IP:           10.244.1.10


[root@master manifests]# curl 10.244.1.10     #访问这个Pod的地址，可以看到nginx的默认页







Welcome to nginx!
If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.

For online documentation and support please refer to
nginx.org.

Commercial support is available at
nginx.com.

Thank you for using nginx.

1、演示ReplicaSet维护期望副本数的场景

下面构造Pod的个数小于ReplicaSet中定义的2
[root@master manifests]# kubectl get pods 
NAME          READY   STATUS    RESTARTS   AGE
myapp-2p9mt   1/1     Running   0          12m
myapp-qcn2c   1/1     Running   0          12m

[root@master manifests]# kubectl delete pods myapp-2p9mt   #删除容器myapp-2p9mt
pod "myapp-2p9mt" deleted

[root@master manifests]# kubectl get pods     #可以看到自动生成了一个myapp-m9rlw
NAME          READY   STATUS    RESTARTS   AGE
myapp-m9rlw   1/1     Running   0          27s
myapp-qcn2c   1/1     Running   0          12m

下面构造Pod的个数大于ReplicaSet中定义的2
[root@master manifests]# kubectl create -f pod-demo.yaml   #新增一个pod-demo的容器


[root@master manifests]# kubectl get pods --show-labels    #查看Pod的标签
NAME          READY   STATUS    RESTARTS   AGE   LABELS
myapp-m9rlw   1/1     Running   1          12h   app=myapp,environment=qa,release=canary
myapp-qcn2c   1/1     Running   1          12h   app=myapp,environment=qa,release=canary
pod-demo      2/2     Running   0          23s   app=myapp,tier=frontend


[root@master manifests]# kubectl label pods pod-demo release=canary   #将pod-demo的标签设置为ReplicaSet所设置的变迁选择器中的标签（app=myapp,release=canary），以此来构造Pod的个数大于2的情况。


[root@master manifests]# kubectl get pods --show-labels  #查看Pod的状态，可以看到pod-demo的状态为Terminating。（ReplicaSet随机删除掉多余的Pod）
NAME          READY   STATUS        RESTARTS   AGE   LABELS
myapp-m9rlw   1/1     Running       1          12h   app=myapp,environment=qa,release=canary
myapp-qcn2c   1/1     Running       1          12h   app=myapp,environment=qa,release=canary
pod-demo      2/2     Terminating   0          50s   app=myapp,release=canary,tier=frontend


[root@master manifests]# kubectl get pods --show-labels  #几分钟后，可以看到pod-demo挂掉了
NAME          READY   STATUS    RESTARTS   AGE   LABELS 
myapp-m9rlw   1/1     Running   1          12h   app=myapp,environment=qa,release=canary
myapp-qcn2c   1/1     Running   1          13h   app=myapp,environment=qa,release=canary

2、演示ReplicaSet自动扩缩容的场景

• 扩缩容的四种方法：【1】、在ReplicaSet的yaml文件中修改replicas的值；【2】、输入命令"kubectl  edit  rs  rs的名称"，然后修改里面的replicas的值；【3】、在命令行输入kubectl  scale...；【4】、在命令行输入kubectl patch...。

下面构造自动扩容的场景
[root@master manifests]# kubectl get pods
NAME          READY   STATUS    RESTARTS   AGE
myapp-m9rlw   1/1     Running   1          13h
myapp-qcn2c   1/1     Running   1          13h

[root@master manifests]# kubectl edit rs myapp  #将里面的replicas修改为3
spec:
  replicas: 3

[root@master manifests]# kubectl get pods
NAME          READY   STATUS    RESTARTS   AGE
myapp-hj5vg   1/1     Running   0          17s
myapp-m9rlw   1/1     Running   1          13h
myapp-qcn2c   1/1     Running   1          13h

下面构造自动缩容的场景
[root@master manifests]# kubectl get pods
NAME          READY   STATUS    RESTARTS   AGE
myapp-hj5vg   1/1     Running   0          17s
myapp-m9rlw   1/1     Running   1          13h
myapp-qcn2c   1/1     Running   1          13h

[root@master manifests]# kubectl edit rs myapp   #将replicas的值设置为2
spec:
  replicas: 2

[root@master manifests]# kubectl get pods   #rs这个ReplicaSet会自动杀掉一个pod
NAME          READY   STATUS    RESTARTS   AGE
myapp-m9rlw   1/1     Running   1          13h
myapp-qcn2c   1/1     Running   1          13h

3、演示ReplicaSet手动更新升级（所谓升级就是改Pod所管理的容器的镜像版本、或是修改其他的一些信息）的场景

• 手动升级的四种方法：【1】、在ReplicaSet的yaml文件中修改容器的image的值；【2】、输入命令"kubectl  edit  rs  rs的名称"，然后修改里面的image的值；【3】、在命令行输入kubectl  set image...（注意：这种方法只针对修改镜像的版本）；【4】、在命令行输入kubectl patch...。

[root@master manifests]# kubectl get rs -o wide
NAME    DESIRED   CURRENT   READY   AGE   CONTAINERS        IMAGES         SELECTOR
myapp   2         2         2       13h   myapp-container   nginx:latest   app=myapp,release=canary

[root@master manifests]# kubectl edit rs myapp  #修改image中的版本
    spec:
      containers:
      - image: nginx:v1

[root@master manifests]# kubectl get rs -o wide   #可以看到nginx:latest变成了nginx:v1
NAME    DESIRED   CURRENT   READY   AGE   CONTAINERS        IMAGES     SELECTOR
myapp   2         2         2       13h   myapp-container   nginx:v1   app=myapp,release=canary


[root@master manifests]# kubectl get pods -o wide
NAME          READY   STATUS    RESTARTS   AGE   IP            NODE     NOMINATED NODE   READINESS GATES
myapp-m9rlw   1/1     Running   1          13h   10.244.2.21   node02              
myapp-qcn2c   1/1     Running   1          13h   10.244.1.12   node01              


[root@master manifests]# curl 10.244.2.21   #访问myapp-m9rlw所管理的容器，可以访问到。这是因为该pod还是未更新升级之前的pod（镜像版本为nginx:latest，而不是nginx:v1），可以正常访问。
...
Welcome to nginx!
...


[root@master manifests]# kubectl delete pods myapp-qcn2c   #删除myapp-qcn2c
pod "myapp-qcn2c" deleted


[root@master manifests]# kubectl get pods -o wide   #可以看到新生成的myapp-jcrrw的状态为ImagePullBackOff，而不是Running。这是因为我上面修改之后的nginx:v1镜像不存在。
NAME          READY   STATUS             RESTARTS   AGE     IP            NODE     NOMINATED NODE   READINESS GATES
myapp-jcrrw   0/1     ImagePullBackOff   0          4m13s   10.244.1.14   node01              
myapp-m9rlw   1/1     Running            1          13h     10.244.2.21   node02              

• 值得注意的是：只有重建出的Pod资源所管理的容器的版本才会是修改之后的版本。之前创建好的Pod资源所管理的容器版本还会是原来的版本。

4、ReplicaSet手动更新升级的三种方法

（1）ReplicaSet更新升级时，手动删除一个Pod，ReplicaSet再自动创建一个Pod，就这样完成手动更新升级的过程；

（2）蓝绿更新的方法1：在ReplicaSet1更新升级之前，创建一个ReplicaSet2，ReplicaSet1和ReplicaSet2都由Service1来管理，创建好ReplicaSet2之后，停掉ReplicaSet1；

（3）蓝绿更新的方法2：在ReplicaSet1更新升级之前，创建一个ReplicaSet2然后让Service1来管理ReplicaSet2，而不去管理ReplicaSet1；