学习目标：掌握各种控制器特点以及使用定义方式
一、ReplicationController（废弃）和ReplicaSet（v1beta2废弃）
1. ReplicationController用来确保容器应用的副本数始终保持在用户定义的副本数，即如果有容器异常退出，会自动创建新的pod来代替；而如果异常多出来的容器也会被回收。新版本使用ReplicaSet，和RC没有本质不同，支持集合式的selector（标签选择）
2. 帮助命令：kubectl explain rs
3. 例子
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
二、Deployment
1. Deployment为pod和replicaSet提供了一个生命式定义方法，用来替代以前的ReplicationController来方便管理应用。
2. 典型应用场景：
a. 定义deployment来创建pod和replicaSet
b. 滚动升级的回滚应用
c. 扩容和缩容
d. 暂停和继续deployment
3. 例子
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 3
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: hub.atguigu.com/library/myapp:v1
ports:
- containerPort: 80
4. 扩容：
a. kubectl scale deployment nginx-deployment --replicas 10
5. 更新镜像
a. kubectl set image deployment/nginx-deployment nginx=wangyanglinux/myapp:v2
6. 回滚
a. kubectl rollout undo deployment/nginx-deployment
7. 更新策略
a. Deployment可以保证在升级时只有一定数量的Pod是down的，默认的，它会确保至少有比期望的pod数量少一个是up状态（最多一个不可用）
b. Deployment也可以确保只创建出超出期望数量一定数量的pod。默认的，它会确保最多比期望的pod数量多一个的pod是up的（最多一个surge）
c. 未来版本中，将从1-1编程25%-25%
d. 查看详情
kubectl describe deployments
8. 其它命令
a. kubectl rollout status deployment/nginx-deployment（查看回滚状态）
b. kubectl rollout undo deployment/nginx-deployment --to-revision=1 （回退到指定版本）
c. kubectl rollout pause deployment/nginx-deployment （暂停更新）
9. 清理Policy
a. 可以通过设置.spec.reversionHistoryLimit项来指定deployment最多保留多少reversion历史记录。默认地会保留所有的reversion；如果将该项设置为0，deployment就不允许回滚了。
三、DaemonSet
A、 DaemonSet确保全部（或者一些）Node上运行一个Pod的副本。当有Node加入集群时，也会为他们新增一个Pod。当有Node从集群移除时，这些pod也会被回收。删除DaemonSet会删除他所有Pod
B、 典型用法：
1. 运行集群存储daemon，例如在每个Node上运行glusterd、ceph
2. 在每个node上运行日志收集daemon，例如fluentd、logstash
3. 在每个node上运行监控daemon, 例如Prometheus、collectd、
C、例子
apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
name: daemonset-example
labels:
app: daemonset
spec:
selector:
matchLabels:
name: daemonset-example
template:
metadata:
labels:
name: daemonset-example
spec:
containers:
- name: daemonset-example
image: hub.atguigu.com/library/myapp:v1
四、Job
A、 Job负责批处理任务，即仅执行一次的任务，它保证批处理任务的一个或多个pod成功结束。
B、例子
apiVersion: batch/v1
kind: Job
metadata:
name: pi
spec:
template:
metadata:
name: pi
spec:
containers:
- name: pi
image: perl
command: ["perl","-Mbignum=bpi","-wle","print bpi(2000)"]
imagePullPolicy: IfNotPresent
restartPolicy: Never
C、注意
restartPolicy只有Never和OnFailure
五、CronJob（在特定的时间循环创建Job实现）
A、Cron管理基于时间的Job，即：
1. 在给定时间点只运行一次
2. 周期性地在给定时间点运行
B、 典型用法：
1. 在给定时间点调度Job运行
2. 创建周期性运行的Job，例如：数据库备份、发送邮件
C、Spec
1. spec.template格式通pod
2. RestartPolicy仅支持Never和OnFailure
3. 单个pod时，默认pod成功运行后job即结束
4. .spec.completions 标志job结束需要成功运行的pod个数，默认为1
5. .spec.parallelism标志并行运行的Pod个数，默认为1
6. .spec.activeDeadlineSeconds标志失败pod的重试最大时间，超过这个时间不会继续重试
7. .spec.schedule：调度，必须字段，指定任务运行周期，格式通Cron
8. .spec.jobTemplate：job模板，必须字段，指定要运行的任务，格式通Job
9. .spec.startingDeadlineSeconds：启动Job的期限（秒级别），该字段是可选的。如果因为任何原因而错过了被调度时间，那么错过执行时间的job将被认为是失败的。如果没有指定，则没有期限。
10. .spec.concurrencyPolicy：并发策略，该字段是可选的。它指定了如何处理被Cron Job创建Job的并发执行。只允许指定下面策略中的一种。
a. Allow（默认）:允许并发运行Job
b. Forbid：禁止并发运行，如果前一个还没有完成，则直接跳过下一个
c. Replace：取消当前正在运行的Job，用一个新的来替换
注意：当前策略只能应用于同一个Cron Job创建的Job。如果存在多个Cron Job，它们创建的Job之间总是允许并发运行。
11. .spec.suspend：挂起，该字段是可选的。如果设置为true，后续所有执行都会被挂起。它对已经开始执行的Job不起作用。默认值为false。
12. .spec.successfulJobHistoryLimit和.spec.failureJobHistoryLimit：历史限制，是可选字段。它们指定了可以保留多少完成和失败的Job。默认情况下，它们分别为3和1。设置限制为0，相关类型的job完成后将不被保留。
注意：
a. 删除cronjob不会自动删除job，需要手动删除
b. 创建Job操作应该是幂等的
六、StatefulSet
A、 StatefulSet作为Controller为Pod提供唯一标识。它可以保证部署和scale的顺序
B、 StatefulSet是为了解决有状态服务问题，应用场景包括：
1. 稳定持久化存储，即Pod重新调度后还是能访问到子相同的持久化数据，基于PVC实现
2. 稳定的网络标志，即Pod重新调度后其PodName和HostName不变，基于Headless Service来实现。
3. 有序部署、有序扩展，即Pod是有顺序的，在部署或扩展的时候要依据定义的顺序依次进行，基于init container来实现。
4. 有序收缩，有序删除
七、Horizontal Pod Autoscaling（使pod水平自动收缩）