k8s控制器

pod的分类

自主式pod： pod 退出了。此类型的pod不会被创建

控制器管理的pod:在控制器的生命周期里，始终维持pod的副本数目

什么是控制器
Kubernetes 中内建了很多 controller（控制器），这些相当于一个状态机，用来控制 Pod 的具体状态和行为

控制器类型

ReplicationController 和 ReplicaSet
Deployment
DaemonSet
StateFulSet
Job/CronJob
Horizontal Pod Autoscaling

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

在新版本的 Kubernetes 中建议使用 ReplicaSet 来取代 ReplicationController 。ReplicaSet 跟ReplicationController 没有本质的不同，只是名字不一样，并且 ReplicaSet 支持集合式的 selector；（标签）

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

申明式编程 （Deployment） apply（优） create
命令式 （rs） create（优） apply

命令式编程：它侧重于如何实现程序，就像我们杠接触编程的时候那样，我们需要把程序的实现过程按照逻辑结果一步步写下来。create

声明式编程：它侧重于定义想要什么，然后告诉计算机/引擎。让他们帮你去实现
优点（可以重复执行，重复执行结果是幂等关系。 apply
sql语句 就是一个典型的声明式编程

Deployment–创建rs —创建pod

更新回滚底层原理

一般的应用程序可以运行在RS 和Deployment ,守护进程的程序可以选用DaemonSet
需要定时任务的可以运行在Job和CronJob，有状态服务部署在StatefulSet

对于docker来说最适合运行无状态服务

DaemonSet 确保全部（或者一些）Node 上运行一个 Pod 的副本。当有 Node 加入集群时，也会为他们新增一个Pod 。当有 Node 从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod使用 DaemonSet 的一些典型用法：

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

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

CronJob
Cron Job 管理基于时间的 Job，即：
1.在给定时间点只运行一次
2.周期性地在给定时间点运行

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

典型的用法如下所示：
1.在给定的时间点调度 Job 运行
2.创建周期性运行的 Job，例如：数据库备份、发送邮件

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

mysql还不太适合部署在k8s

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