Pod类型：
自主式 Pod：无管理者，Pod退出了，此类型的Pod不会被创建
控制器管理的 Pod：在控制器的生命周期里，始终要维持 Pod的副本数目
控制器：
Kubernetes中内建了许多contoller(控制器)，这些相当于一个状态机，用来控制Pod的具体状态和行为
控制器类型
1）ReplicaSet和ReplicationController（废除）
2）Deployment
3）DaemonSet
4）StateFulSet
5）Job/CronJob
6）Horizontal Pod Autoscaling
1.ReplicaSet
rs支持应用容器的副本数目始终保持在用户定义的副本数。创建新的Pod来替代异常退出的Pod。异常多出来的容器自动回收。
rs和rc没有本质的不同，rs支持集合式的selector；rs通过标签Labels（matchLabels）选择与控制
示例：Example006：
/root/yaml/001_pod_rs_deployment_svc/006_rs.yaml
RS与Deployments的关联：deployment通过修改rs的创建来管理对应的Pod，以及通过rs版本的的交替来完成滚动更新
2.Deployment
为Pod和ReplicaSet提供一个声明式定义（declarative）方法，用来替代以前的ReplicationCotroller来方便的管理应用。典型的应用场景包括：
1）定义Deployment来创建Pod和ReplicaSet
2）动升级和回滚应用
3）扩容和缩容
4）暂停和继续更新 Deployment
命令式编程：它侧重于如何实现 create rs
声明式编程：它侧重于结果 apply Deployment
示例：Example007：
/root/yaml/001_pod_rs_deployment_svc/007_deployment.yaml
1）--record
# kubectl apply -f deployment.yaml --record
--record可以记录命令，方便查看每次revision的变化，用于回滚
2）扩容：
kubectl scale deployment nginx-deployment --replicas 10
3）如果集群支持HPA的话，还可以为Deployment设置自动扩展
4）更新镜像
# kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1
# kubectl set image deployment/nginx-deployment nginx=httpd:latest
Deployment更新策略 # kubectl describe deployments
默认1-1，未来25%-25%
可以在yaml模版中定义新策略
rollover（多个rollout并行）
v1版本创建了一半，开始升级至v2版，直接杀死v1版的所有pod，并创建v2版本的Pod
5）回滚
# kubectl rollout history deployment/nginx-deployment //查看历史版本
# kubectl rollout undo deployment/nginx-deployment //回滚至上一个版本
# kubectl rollout undo deployment/nginx-deployment --to-revision=2 //回滚到指定版本
# kubectl rollout status deployment/nginx-deployment //查看回滚/更新状态，是否更新完成。
# echo $?
0 //Exit Code 退出码为0 ，更新成功
# kubectl rollout pause deployment/nginx-deployment //暂停deployment的更新
Deployment.spec.revisionHistoryLimit 可以指定revision历史记录的条数， 默认全保留， 0则不保留历史版本。这同rs版本的数量一致
3.DaemonSet
DaemonSet确定全部Node（注意：污点和容忍）上运行一个Pod的副本。新node加入集群，也会为其创建一个Pod。当有Node从集群移除时，这些Pod也会被回收。删除DaemonSet将会删除它创建的所有Pod
典型用法：
1）运行集群存储daemon，例如在每个Node上运行 glusterd、ceph
2）在每个Node上运行日志收集daemon，例如fluentd、logstash
3）在每个Node上运行监控daemon，例如 Prometheus Node Exporter、collectd、Datadog代理、New Relic代理，或Ganglia gmond
示例：Example008：
/root/yaml/001_pod_rs_deployment_svc/008_DaemonSet.yaml
集群调度：对应的Pod指定到对应的Node上，通过标签选择和污点
4.Job（执行脚本）
job负责批处理任务，即仅执行一次的任务，它保证批处理任务的一个或多个Pod成功结束
Job Spec 特殊说明
* RestartPolicy仅支持Never或OnFailure
* 单个Pod时，默认Pod成功运行后Job即结束
* .spec.completions 标志Job结束需要成功运行的Pod个数，默认为1
* .spec.parallelism 标志并行运行的Pod的个数，默认为1
* .spec.activeDeadlineSeconds 标志失败Pod的重试最大时间，超过这个时间不会继续重试
示例：Example009：
/root/yaml/001_pod_rs_deployment_svc/009_job.yaml
5.CronJob（版本>=1.8）
CronJob管理基于时间的Job（分 时 日 月 周 ，同crontab）
典型用法：
1）指定时间点调度Job运行
2）周期性的运行Job，例如：数据库备份、发邮件
CronJob Spec 特殊说明：（同Job Spec）
* RestartPolicy仅支持Nerver或者OnFailure
* 单个Pod时，默认Pod成功运行后Job即结束
* .spec.completions 标志Job结束需要成功运行的Pod个数，默认为1
* .spec.parallelism 标志并行运行的Pod的个数，默认为1
* .spec.activeDeadlineSeconds 标志失败Pod的重试最大时间，超过这个时间不会继续重试
重点字段：
* .spec.schedule: 调度，必需字段，指定任务运行周期，格式同cron
* .spec.jobTemplate: Job模版，必需字段，指定需要运行的任务，格式同Job
* .spec.startingDeadlineSeconds: 启动Job的期限（秒级别），该字段是可选的。如果因为任何原因错过了被调度的时间，那么错过执行时间的Job将被认为是失败的。如果没有指定，则没有期限
* spec.concurrencyPolicy: 并发策略，可选字段。它指定了如何处理被Cron Job创建的Job的并发执行。只允许指定下面策略中的一种：
Allow（默认）：允许并发运行Job
Forbid：禁止并发执行，如果前一个还没有完成，则直接跳过下一个
Replace：取消当前正在运行的Job，用一个新的来替换。
注意：当前策略只能用于同一个CronJob创建的Job。如果存在多个CronJob，它们创建的Job之间总是允许并发。
* spec.suspend: 挂起，可选字段。如果设置为true，后续所有执行都会被挂起。它对已经开始执行的Job不起作用。默认值为false
* spec.successfulJobHistoryLimit和.spec.failedJobsHistoryLimit:历史限制，可选字段。他们指定了可以保留多少完成和失败的Job。默认情况下，他们分别设置为3和1。设置限制的值为 0，相关类型的Job完成后将不会被保留。
示例：Example010：
/root/yaml/001_pod_rs_deployment_svc/010_cronJob.yaml
注意：删除cronjob的时候不会自动删除job。需要独立删除 kubectl delete job
CronJob限制:
1）cronJob创建Job操作应该是 幂等的
2）cronJob定期运行Job。Job的运行结果运行状态 并不返回给cronJob
6.StatefulSet
对应与Deployments和ReplicaSets是无状态服务的设计，StatefulSet是为了解决有状态服务的问题
需要借助到存储 PV-PVC
StatefulSet会为Controller为Pod提供唯一的标识。它可以保证部署和scale的顺序，保证存储的稳定连接
应用场景：
1）稳定的持久化存储，即Pod重新调度后还是能访问到相同的持久化数据，基于PVC来实现。 稳定的mongodb，mysql不稳定
2）稳定的网络标志，即Pod重新调度后其PodName和HostName不变，基于Headless Service（即没有Cluster IP的Service）来实现
3）有序部署，有序扩展，即Pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次进行（即如 mysql->tomcat -> nginx, 在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态），基于init containers来实现
4）有序收缩，有序删除（即 nginx->tomcat->mysql）
示例在 pv-pvc 处介绍
7.Horizontal Pod Autoscaling
hpa管理deployment，实现Pod的水平自动扩容和缩容，提高集群的整体资源利用率。需要借助到资源收集模块metrics-server。
示例在资源收集模块处介绍
