Deployment
Deployment是k8s最常用的controller，通常k8s不会直接创建pod，而是通过controller来管理POD的。Controller中定义了POD的部署特性，比如有几个副本，在什么样的NODE上运行等，它可以管理pod的多个副本，并确保pod按照期望的状态运行。
运行Deployment
按照如下方式，运行一个Deployment
kubectl run nginx-deployment --image=nginx:1.7.9 --replicas=3上面的命令将部署包含三个副本的Deployment nginx-deployment，容器的image为nginx:1.7.9
如下所示：
通过kubectl get deployment可以看到nginx-deployment的状态
通过kubectl describe deployment了解更详细的信息。
在NewreplicaSet，可以看到创建了一个nginx-deployment-754846b88c的replicatset，说明deployment是通过replicaset来管理POD的。执行kubectl describe replicaset 查看详细信息。
Controller By指明此ReplicaSet是由Deployment/nginx-deployment创建的。
执行kubectl get pod和kubectl describe pod查看更详细的信息。
Controlled By指明了POD由谁创建，EVENT记录了pod的启动过程。
整个过程如下所示：
1.用户通过 kubectl 创建 Deployment。
2.Deployment 创建 ReplicaSet。
3.ReplicaSet 创建 Pod。
对象命令的方式是”子对象的名字=父对象名字+随机字符串或者数字"
配置文件
- 用 kubectl 命令直接创建，比如：
kubectl run nginx-deployment --image=nginx:1.7.9 --replicas=2
在命令行中通过参数指定资源的属性。
- 通过配置文件和 kubectl apply 创建，要完成前面同样的工作，可执行命令：
kubectl apply -f nginx.yml
nginx.yml 的内容为：
资源的属性写在配置文件中，文件格式为 YAML。
下面对这两种方式进行比较。
基于命令的方式：
简单直观快捷，上手快。
适合临时测试或实验。
基于配置文件的方式：
配置文件描述了 What，即应用最终要达到的状态。
配置文件提供了创建资源的模板，能够重复部署。
可以像管理代码一样管理部署。
适合正式的、跨环境的、规模化部署。
这种方式要求熟悉配置文件的语法，有一定难度。
kubectl apply 不但能够创建k8s资源，也能对资源进行更新，k8s还提供了kubectl create,kubectl reploace,kubectl edit和kubeclt path命令。
配置文件
配置文件主要是yaml格式，其他的controler跟deployment的配置文件方式类似
简单的配置文件如下所示：
① apiVersion 是当前配置格式的版本。
② kind 是要创建的资源类型，这里是 Deployment。
③ metadata 是该资源的元数据，name 是必需的元数据项。
④ spec 部分是该 Deployment 的规格说明。
⑤ replicas 指明副本数量，默认为 1。
⑥ template 定义 Pod 的模板，这是配置文件的重要部分。
⑦ metadata 定义 Pod 的元数据，至少要定义一个 label。label 的 key 和 value 可以任意指定。
⑧ spec 描述 Pod 的规格，此部分定义 Pod 中每一个容器的属性，name 和 image 是必需的
执行kubectl apply -f niginx.yml即可。
执行kubectl delete deploymet nginx-deployment或者kubectl delete -f nginx.yml进行删除
伸缩
配置文件如下
伸缩是指在线增加或者减少Pod的副本数
初始是1个副本，如下所示：
现在修改new_nginx,yml文件，将副本修改成5个。
再次执行kubectl -f apply，结果如下所示：
在dashboard上也能确认
用label控制pod的位置
默认情况下,sxhedulet会将pod调度到所有可用的node上，不过有些情况需要将pod部署到指定的node上，k8s使用label来实现这个功能的。
label是key-value对，各种资源都可以设置label,灵活添加各种自定义的属性，如下所示，标注k8s-node1是配置了ssd的节点
kubectl label node docker-1 disktype=ssd
其他的node还有k8s自己维护的label
有了disktype这个自定义的label,接下来就可以指定将pod部署node-1上
在pod模板的spec里通过nodeSelector指定将此pod部署到具有label disktype=ssd的node上。
DaemonSet
Deployment部署的副本pod会分布在各个node上，每个node都可以运行好几个副本。
DaemonSet的不通之处在于每个node上最多只能运行一个副本。
它的典型应用场景有:
1.在集群的每个几点上运行存储deamon，比如glusterd后者ceph
2.在每个节点上运行日志收集deamon，比如flunentd或者logstash
3.在每个几点上运行监控daemon，比如prometheus node exploer
其实k8s自己就在用DaemonSet运行系统组件
kube-proxy的配置文件，如下所示：
① kind: DaemonSet 指定这是一个 DaemonSet 类型的资源。
② containers 定义了 kube-proxy 的容器。
③ status 是当前 DaemonSet 的运行时状态，这个部分是 kubectl edit特有的。其实 Kubernetes 集群中每个当前运行的资源都可以通过 kubectl edit 查看其配置和运行状态，比如 kubectl edit deployment nginx-deployment。
job
容器按照持续运行的时间可分为两类：服务类容器和工作类容器
服务类容器通常持续提供服务，需要一直运行，比如http server，daemon等，工作容器是一次性人物，比如批处理程序，完成后容器就退出
k8s的deployment,replicaSet和daemonset都用于管理服务类容器，对工作类容器，使用job
以下是个简单的job配置文件
① batch/v1 是当前 Job 的 apiVersion。
② 指明当前资源的类型为 Job。
③ restartPolicy 指定什么情况下需要重启容器。对于 Job，只能设置为 Never 或者 OnFailure。对于其他 controller（比如 Deployment）可以设置为 Always 。
通过 kubectl apply -f myjob.yml 启动 Job。
通过kubectl get job来查看job的状态
通过kubectl get pod查看pod的状态
因为Pod执行完毕后，容器已经退出，需要用--show all才能查看completed状态的pod,通过kubectl logs可以查看pod的标准输出。
job的并行性
在同时运行多个pod，可以提高job的执行效率，可以通过parallelism设置。
将并行的pod数量设置为2
定时job
linux中有cron程序定时执行任务，k8s的cronjob提供了类似的功能，可以执行job,配置文件如下所示：
① batch/v2alpha1 是当前 CronJob 的 apiVersion。
② 指明当前资源的类型为 CronJob。
③ schedule 指定什么时候运行 Job，其格式与 Linux cron 一致。这里 /1 * 的含义是每一分钟启动一次。
④ jobTemplate 定义 Job 的模板，格式与前面 Job 一致。