Pod控制器就是帮助我们自动的调度管理Pod，并满足期望的Pod数量。
Pod控制器大致有以下7类：

• Replication Controllers
• ReplicaSet
• Deployment
• StatefulSets
• DaemonSet
• Jobs
• CronJob

- Replication Controllers

由于这种控制器的功能有限，而且已经推出了更高级的Pod控制器，所以已经不再推荐使用。

- ReplicaSet

ReplicaSet是Replication Controllers的下一代，他们之间唯一的区别就是标签选择器的区别，ReplicaSet支持最新的基于集合形式的标签选择器，大多数支持Replication Controllers的kubectl的命令也能支持ReplicaSet，但唯独有一条rolling-update
如果想要滚动更新功能请使用 Deployment。rolling-update命令是必需的，而 Deployment 是声明性的，因此我们建议通过 rollout,虽然 ReplicaSets 可以独立使用，但今天它主要被Deployments用作协调 Pod 创建、删除和更新的机制。 当使用 Deployment 时，不需要管理它们创建的ReplicaSet。Deployment 会管理它们的 ReplicaSet。
ReplicaSet 确保任何时间都有指定数量的 Pod 副本在运行。 然而，Deployment 是一个更高级的概念，它管理 ReplicaSet，并向 Pod 提供声明式的更新以及许多其他有用的功能。 因此，我们平时只使用 Deployment 而不是直接使用 ReplicaSet，除非需要自定义更新业务流程或根本不需要更新。
在编写方面，与其他Kubernetes API对象一样，也要定义apiVersion、kind、metadata、spec,而temlate就是pod模板，下面看一段示例

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend
  labels:
    app: guestbook
    tier: frontend
spec:
  replicas: 3
  selector:
    matchLabels:
      tier: frontend
    matchExpressions:
      - {key: tier, operator: In, values: [frontend]}
  template:
    metadata:
      labels:
        app: guestbook
        tier: frontend
    spec:
      containers:
      - name: php-redis
        image: gcr.io/google_samples/gb-frontend:v3
        resources:
          requests:
            cpu: 100m
            memory: 100Mi
        env:
        - name: GET_HOSTS_FROM
          value: dns
        ports:
        - containerPort: 80

• 创建ReplicaSet可以使用

#从网络拉取
kubectl create -f http://k8s.io/examples/controllers/frontend.yaml
#从本地提交
kubectl create -f frontend.yaml
#查看状态
kubectl describe rs/frontend

• 删除ReplicaSetkubectl delete默认会把所有有依赖关系的Pod删除，如果想只删除ReplicaSet而后创建新的ReplicaSet取代他，我推荐使用Dployment的滚动更新功能。
• 如果想只把某个Pod隔离，便于排错，可以用更改标签的方式让他从ReplicaSet中脱离出来，如果replicas数量没有变的话会有新的Pod顶替上。
• 扩缩容ReplicaSet只要更改.spec.replicas字段即可

- Deployment

模板示例：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.15.4
        ports:
        - containerPort: 80

• 创建命令
  kubectl apply -f nginx-deployment.yaml
  从模板上看和ReplicaSet非常相似，但是创建命令有些区别就是，Deployment是支持声明式更新的，就是说更改了yaml文件直接重新声明，新的配置就会应用上。
• 查看状态
  要查看 Deployment 展开状态，运行
  kubectl rollout status deployment/nginx-deployment
  待更新过程结束后可以执行
  kubectl get deployment查看状态
  kubectl get rs 查看由Deployment创建的ReplicaSet
  
  image.png
• 升级Deployment
  升级的方式有很多种，这里介绍一种比较简单的直接编辑
  kubectl edit deployment.v1.apps/nginx-deployment直接编辑image字段即可
  然后可以kubectl rollout status deployment.v1.apps/nginx-deployment查看更新的动态过程
  更新的时候有一个更新策略
  Deployment 可确保在更新时仅关闭一定数量的 Pods。默认情况下，它确保至少 75%所需 Pods 运行（25%最大不可用）。
  Deployment 还确保仅创建一定数量的 Pods 高于期望的 Pods 数。默认情况下，它可确保最多增加 25% 期望 Pods 数（25%最大增量）。
  更新的时候Deployment会创建另一个ReplicaSet，新的ReplicaSet会满足新的Pod期望数量，而旧的ReplicaSet的replicas会缩减为0，每更新一次就会创建出一个新的ReplicaSet，保留历史版，如果新版本出现了不稳定不兼容的问题，还可以立即回滚。
  使用命令kubectl rollout history deployment.v1.apps/nginx-deployment
  即可检查Deployment的修改历史
  
  image.png
• 查看某一版本历史的详细信息
  kubectl rollout history deployment.v1.apps/nginx-deployment --revision=2
  
  image.png
• 回滚上一次的操作
  kubectl rollout undo deployment.v1.apps/nginx-deployment
  或者回滚到某一特定的版本
  kubectl rollout undo deployment.v1.apps/nginx-deployment --to-revision=2
• 缩放Deployment
  可以使用如下指令缩放 Deployment ：
  kubectl scale deployment.v1.apps/nginx-deployment --replicas=10
  还可以启动自动水平扩展，并且可以根据指定的CPU的使用率为依据进行缩放
  kubectl autoscale deployment.v1.apps/nginx-deployment --min=10 --max=15 --cpu-percent=80
• 如果更新的过程中发现了书写错误，还可以暂停
  kubectl rollout pause deployment.v1.apps/nginx-deployment
kubectl rollout resume deployment.v1.apps/nginx-deployment
  总的来说Deployment功能比ReplicaSet强大，因为他是构建在ReplicaSet之上的高级控制器，也是官方推荐的控制器。剩下几种控制器下篇再介绍