五、资源控制器

Pod的分类

自主式Pod：Pod退出，此类型的 Pod不会被创建
控制器管理的 Pod：在控制器的生命周期里，始终要维持Pod 的副本数目

控制器类型

ReplicationController和 ReplicaSet

ReplicationController(RC)用来确保容器应用的副本数始终保持在用户定义的副本数，即如果有容器异常退出，会自动创建新的Pod来替代;而如果异常多出来的容器也会自动回收;
在新版本的Kubernetes 中建议使用ReplicaSet来取代ReplicationController。ReplicaSet跟ReplicationController没有本质的不同，只是名字不一样，并且ReplicaSet支持集合式的selector;

Deployment

Deployment为Pod和ReplicaSet提供了一个声明式定义(declarative)方法，用来替代以前的ReplicationController来方便的管理应用。典型的应用场景包括;

• 定义Deployment来创建Pod和Replicaset：deployment不是直接管理pod，而是通过rs管理
  

• 滚动升级和回滚应用：通过创建新的rs来创建新的pod升级和回滚

• 扩容和缩容

• 暂停和继续Deployment

命令式编程:它侧重于如何实现程序，就像我们刚接触编程的时候那样，我们需要把程序的实现过程按照逻辑结果一步步写下来
声明式编程:它侧重于定义想要什么，然后告诉计算机/引擎，让他帮你去实现,例如SQL的编写

DaemonSet

DaemonSet确保全部(或者一些) Node 上运行一个Pod的副本。当有Node加入集群时，也会为他们新增一个Pod。当有Node 从集群移除时，这些Pod也会被回收。删除 DaemonSet将会删除它创建的所有Pod。监控RS的副本数量，基本都是以label（标签）为基础
使用DaemonSet的一些典型用法:

• 运行集群存储daemon，例如在每个Node 上运行glusterd 、ceph
• 在每个Node 上运行日志收集daemon，例如fluentd 、logstash
• 在每个Node上运行监控daemon，例如Prometheus Node Exporter、collectd 、Datadog代理、New Relic 代理，或 Ganglia gmond

StateFulSet

StatefulSet作为Controller为Pod提供唯一的标识。它可以保证部署和scale的顺序
StatefulSet是为了解决有状态服务的问题（对应Deployments和ReplicaSets是为无状态服务而设计)，其应用场景包括:

• 稳定的持久化存储，即Pod重新调度后还是能访问到相同的持久化数据，基于PVC来实现
• 稳定的网络标志，即Pod重新调度后其PodName和HostName不变，基于Headless Service(即没有Cluster lP的Service)来实现
• 有序部署，有序扩展，即Pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次依次进行
  (即从0到N-1，在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态)，基于init containers来实现
• 有序收缩，有序删除(即从N-1到0)
  

Job

Job负责批处理任务，即仅执行一次的任务，它保证批处理任务的一个或多个Pod成功结束。基于执行结果来，定义执行成功多少次之后退出

CronJob 在特定的时间循环创建Job

CronJob管理基于时间的Job，即: * * * * * （分 时 日 月 周）

• 在给定时间点只运行—次
• 周期性地在给定时间点运行

使用前提条件: 当前使用的 Kubernetes集群，版本>=1.8(对CronJob)。对于先前版本的集群
版本<1.8，启动API Server时，通过传递选项–runtime-config=batch/v2alpha1=true]可以开启 batch/v2alpha1AP|

典型的用法如下所示:

• 在给定的时间点调度Job运行
• 创建周期性运行的Job，例如:数据库备份、发送邮件

Horizontal Pod Autoscaling

应用的资源使用率通常都有高峰和低谷的时候，如何削峰填谷，提高集群的整体资源利用率，让service中的Pod个数自动调整呢?这就有赖于Horizontal Pod Autoscaling了，顾名思义，使Pod水平自动缩放

不同控制器的演示

RS与RC与Deployment关联

RC(ReplicationController ）主要的作用就是用来确保容器应用的副本数始终保持在用户定义的副本数。即如果有容器异常退出，会自动创建新的Pod来替代;而如果异常多出来的容器也会自动回收

Kubernetes官方建议使用RS(ReplicaSet)）替代 Rc (ReplicationController ）进行部署，RS跟RC没有本质的不同，只是名字不—样，并且RS支持集合式的selector

rs-demo.yaml

apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata:
  name: frontend
spec:
  replicas: 3
  selector:
    matchLabels:
      tier: frontend
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
      - name: myapp
        image: hub.atguigu.com/library/myapp:v1
        env:
        - name: GET_HOSTS_FROM
          value: dns
        ports:
        - containerPort: 80
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

测试,修改pod label后新创建一个pod。证明rs的副本监控以label为基础

# 创建pod
kubectl create -f rs-demo.yaml
# 查看副本数量
kubectl get pod
# 修改其中一个pod标签名称
kubectl label pod frontend-g7p2r tier=fronted1 --overwrite=True
# 删除所有rs
kubectl delete rs --all
# 删除所有pod
kubectl delete pod --all
1
2
3
4
5
6
7
8
9
10

RS与Deployment的关联

RS实现滚动更新的示意图如下，新版本rs创建

使用Deployment部署一个简单的nginx应用

nginx-dep.yaml

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  template:
    metadata:
      labes:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

测试命令

# 创建deployment，--record可以记录命令，我们可以很方便的查看每次revision的变化
kubectl apply -f nginx-dep.yaml --record

# 查看deployment
kubectl get deployment

# 查看rs数量，生成三个，再次证明deployment和rs的唯一对应关系
kubectl get rs
1
2
3
4
5
6
7
8

扩容

kubectl scale deployment nginx-deployment --replicas 10 
1

更新镜像

# 将nginx-deployment的deployment中nginx标签用到的镜像换成nginx:1.9.1
kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
1
2

查看更换结果，nginx版本
查看更换结果，rs情况，旧的rs被弃用，新的rs生成了10个副本

回滚

kubectl rollout undo deployment/nginx-deployment
1

默认回滚上一个版本，如果想回滚到之前的指定版本，可以通过添加参数 --to-revision=2来指定版本
查看回滚结果，nginx回滚到之前的模板文件中的版本也就是1.7.9版本了

rs数量也显示最开始的rs数量为10，代表回滚成功

常用的混滚命令可以参考如下

Deployment更新策略

Deployment 可以保证在升级时只有一定数量的Pod是down的。默认的，它会确保至少有比期望的Pod数量少一个是up状态(最多一个不可用)

Deployment同时也可以确保只创建出超过期望数量的一定数量的Pod。默认的，它会确保最多比期望的Pod数量多一个的Pod是up的(最多1个surge )

未来的Kuberentes版本中，将从1-1变成25%-25% I
通俗来讲，当创建新的rs时，会在新的rs中创建25%的新pod，然后在旧的rs中删除25%的旧的pod，依次执行
kubectl describe deployments

Rollover（多个rollout并行）

假如您创建了一个有5个niginx:1.7.9 replica的 Deployment，但是当还只有3个nginx:1.7.9的replica创建出来的时候您就开始更新含有5个nginx:1.9.1 replica的 Deployment。在这种情况下，Deployment会立即杀掉已创建的3个nginx:1.7.9的Pod，并开始创建nginx:1.9.1的Pod。它不会等到所有的5个 nginx:1.7.9的Pod都创建完成后才开始改变航道

清理Policy

可以通过设置‘.spec.revisonHistoryLimit’项来指定deployment最多保留多少revision历史记录，默认的会保留所有的revision；如果将该项设置为0，则Deployment就不允许回滚了