什么是控制器

Kubernetes中内建了很多controller (控制器)， 这些相当于个状态机，用来控制Pod的具体状态和行为

控制器类型

ReplicationController(过去式，已被RS替代)和ReplicaSet
Deployment
DaemonSet
State FulSet
Job/CronJob
Horizontal Pod Autoscaling

ReplicationController 和 ReplicaSet

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

Deployment

Deployment 为 Pod 和 ReplicaSet 提供了一个声明式定义 (declarative) 方法，用来替代以前的ReplicationController 来方便的管理应用。
典型的应用场景包括:
- 定义 Deployment 来创建 Pod 和 ReplicaSet
- 滚动升级和回滚应用
- 扩容和缩容
- 暂停和继续 Deployment

什么是 DaemonSet

DaemonSet 确保全部 (或者 - 些) Node. 上运行一个 Pod 的副本。当有 Node 加入集群时，也会为他们新增一个 Pod。当有 Node 从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod
使用 DaemonSet 的 - - 些典型用法:
●运行集群存储 daemon, 例如在每个 Node. 上运行 | glusterd、ceph
●在每个 Node . 上运行日志收集 daemon, 例如 fluentd、| logstash
●在每个 Node 上运行监控 daemon, 例如 Prometheus Node Exporter、| collectd、 Datadog 代理、
New Relic 代理，或 Ganglia | gmond

apiVersion: apps/v1
kind: DaemonSet
metadata :
  name: deamonset-example
  labels:
    app: daemonset
spec:
  selector:
    matchLabels:
      name: deamonset- example
template:
  metadata:
    labels:
      name: deamonset-example
spec:
  containers :
  - name: daemonset-example
    image: hub.dev-site.cn/myapp:v1

Job

Job负责批处理任务，即仅执行一次的任务,它保证批处理任务的一一个或多个Pod成功结束

CronJob

Cron Job管理基于时间的Job,即:
- 在给定时间点只运行-次
- 周期性地在给定时间点运行

使用前提条件: 当前使用的Kubernetes集群，版本>= 1.8 (对CronJob)。对于先前版本的集群，版本<1.8,启动API Server时，通过传递选项--runtime-config-batch/v2alpha1=true可以开启batch/v2alpha1API
典型的用法如下所示:
- 在给定的时间点调度Job运行
- 创建周期性运行的Job,例如:数据库备份、发送邮件

StatefulSet

StatefulSet作为Controller为Pod提供唯一-的标识。 它可以保证部署和scale的顺序
StatefulSet是为了解决有状态服务的问题(对应Deployments和ReplicaSets是为无状态服务而设计)
其应用场景包括:
- 稳定的持久化存储，即Pod重新调度后还是能访问到相同的持久化数据，基于PVC来实现
- 稳定的网络标志，即Pod重新调度后其PodName和HostName不变，基于Headless Service (即没有Cluster IP的Service)来实现
- 有序部署,有序扩展，即Pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次依次进行(即从0到N-1,在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态)，基于init containers来实现
- 有序收缩，有序删除(即从N-1到0)

Horizontal Pod Autoscaling

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

RS 与 RC 与 Deployment 关联

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

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

apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata :
  name: frontend
spec:
  replicas: 3
  selector:
    matchLabels:
      tier: frontend
  template:
    metadata:
     labels:
       tier: frontend
    spec:
      containers:
      - name: php-redis
        image: gcr. io/google_ samples/ gb- frontend:v3
        env:
        name: GET_ HOSTS_ FROM
          value: dns
       ports:
       - containerPort: 80

Deployment

Deployment 为 Pod 和 ReplicaSet 提供了一个声明式定义 (declarative) 方法，用来替代以前的 ReplicationController 来方便的管理应用。典型的应用场景包括：
定义 Deployment 来创建 Pod 和 ReplicaSet
滚动升级和回滚应用
扩容和缩容
暂停和继续 Deployment

Ⅰ、部署一个简单的 Nginx 应用

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

kubectl create -f https://kubernetes.io/docs/user-guide/nginx-deployment.yaml --record
## --record参数可以记录命令，我们可以很方便的查看每次revision 的变化

Ⅱ、扩容

kubectl scale deployment nginx-deployment --replicas 10

Ⅲ、如果集群支持 horizontal pod autoscaling 的话，还可以为 Deployment 设置自动扩展

kubectl autoscale deployment nginx-deployment --min=10 --max=15 --cpu-percent=80

IV、更新镜像也比较简单

kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1

V. 回滚

kubectl rollout undo deployment/nginx-deployment

更新 Deployment

假如我们现在想要让 nginx pod 使用 nginx:1.9.1 的镜像来代替原来的 nginx:1.7.9 的镜像

$ kubectl set image deployment/ nginx-deployment nginx=nginx:1.9.1
deployment " nginx-deployment" image updated

可以使用 edit 命令来编辑 Deployment

$ kubectl edit deployment/nginx-deployment
deployment "nginx-deployment" edited

查看 rollout 的状态

$ kubectl rollout status deployment/ nginx-deployment
Waiting for rollout to finish: 2 out of 3 new replicas have been updated. . .
deployment "nginx-deployment" successfully rolled out

查看历史 RS

$ kubectl get rs
NAME                            DESIRED CURRENT READY AGE
nginx-deployment-1564180365     3       3       0     6s
nginx- deployment - 2035384211  0       0       0     36s

Deployment 更新策略

Deployment 可以保证在升级时只有一定数量的 Pod 是 down 的。默认的，它会确保至少有比期望的 Pod 数量少一个是 up 状态 (最多 - 个不可用)
Deployment 同时也可以确保只创建出超过期望数量的一定数量的 Pod。默认的，它会确保最多比期望的 Pod 数量多一个的 Pod 是 up 的 (最多 1 个 surge)
未来的 Kuberentes 版本中，将从 1-1 变成 25%- 25%

$ 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
都创建完成后才开始改变航道**

回退 Deployment

kubectl set image deployment/nginx-deployment nginx=nginx:1.91
kubectl rollout status deployments nginx-deployment
kubectl get pods
kubectl rollout history deployment/nginx-deployment
kubectl rollout undo deployment/nginx- deployment
kubectl rollout undo deployment/nginx-deployment --to-revision=2 ## 可以使用--revision参数指定某个历史版本
kubectl rollout pause deployment/nginx- deployment  ##暂停deployment的更新

您可以用 kubect1 rollout status 命令查看 Deployment 是否完成。如果 rollout 成功完成，kubectl rollout status 将返回一个 0 值的 Exit Code

$ kubectl rollout status deploy/nginx
Waiting for rollout to finish: 2 of 3 updated replicas are available...
deployment "nginx" successfully rolled out
$ echo $?
0

清理 Policy

您可以通过设置.spec . revisonHistoryLimit 项来指定 deployment 最多保留多少 revision 历史记录。默认的会保留所有的 revision; 如果将该项设置为 0, Deployment 就不允许回退了