上一篇《部署过程解析与安装Dashboard》中我们了解K8S的部署过程，这一篇我们来了解一下K8S为我们提供的几种应用运行方式：Deployment、DaemonSet与Job，它们是Kubernetes最重要的核心功能提供者。考虑到篇幅和更新速度，我将其分为两篇文章，本篇会主要介绍Deployment，主要参考自CloudMan《每天5分钟玩转Kubernetes》，也推荐大家购买阅读。
01
—
创建资源的两种方式对比
K8S支持两种创建资源的方式，分别是 使用kubectl命令直接创建 与 通过配置文件+kubectl apply创建，下面以上一篇中的ASP.NET Core示例来分别介绍下这两种方式。
1.1 Kubectl命令直接创建
第一种是通过kubectl命令直接创建：
kubectl run k8s-demo-deployment --image=edisonsaonian/k8s-demo:latest --replicas=2 --namespace=aspnetcore这样我们就部署了一个具有2个副本的k8s-demo（一个ASP.NET Core API示例）。
1.2 YAML配置文件创建
第二种是通过配置文件+kubectl apply(kubectl create也可以)创建：
apiVersion: apps/v1
kind: Deployment
metadata: name: k8s-demo-deployment namespace: aspnetcore
spec: replicas: 2 template: spec: containers: - name: k8s-demo image: edisonsaonian/k8s-demo ports: - containerPort: 80不过，上面的配置文件可能并不能直接运行，因为默认情况下K8S还有一些必填项的验证，完整你可以参考下面这段配置。更多yaml文件的语法基础，可以参考这一篇文章：https://www.kubernetes.org.cn/1414.html
apiVersion: apps/v1
kind: Deployment
metadata: name: k8s-demo-deployment namespace: aspnetcore
spec: replicas: 2 selector: matchLabels: app: aspnetcore_webapi template: metadata: labels: app: aspnetcore_webapi spec: containers: - name: k8s-demo image: edisonsaonian/k8s-demo ports: - containerPort: 80如上所示，我们将资源的属性都写在了一个yaml格式的配置文件中，有了这个配置文件，我们只需要执行一句：
kubectl apply -f k8s-demo-deployment.yaml1.3 相关补充
如果要删除deployment，也只需要执行一句：
kubectl delete deployment k8s-demo-deployment或者是下面这一句：
kubectl delete -f k8s-demo-deployment.yaml执行之后，K8S会自动帮我们删除相关Deployment、ReplicaSet（副本集）以及Pod。
可以看出，直接通过kubectl创建会比较省力和快捷，但是它无法做到很好的管理，不适合正式的、规模化的部署，因此我们一般会更加倾向于采用配置文件的方式，但是使用配置文件要求我们熟悉yaml的语法，如果存在类似制表符之类的特殊字符都是无法成功执行的。
02
—
Deployment必知必会
2.1 Deployment类型应用运行
这里我们仍以上面提到的k8s-demo示例项目为例，通过下面这个配置文件来创建资源：
apiVersion: apps/v1
kind: Deployment
metadata: name: k8s-demo-deployment namespace: aspnetcore
spec: replicas: 2 selector: matchLabels: app: aspnetcore_webapi template: metadata: labels: app: aspnetcore_webapi spec: containers: - name: k8s-demo image: edisonsaonian/k8s-demo ports: - containerPort: 80通过下面的命令创建资源：
kubectl apply -f k8s-demo-deployment.yaml下面我们来看看K8S到底为我们做了些什么工作：
（1）查看k8s-demo-deployment状态
kubectl get deployment k8s-demo-deployment -n aspnetcore 
可以看到，对于我们的这个deployment，生成了2个副本且正常运行。
如果想要获得更加相信的信息，可以使用下面这句：
kubectl describe deployment k8s-demo-deployment -n aspnetcore 从deployment的日志中，可以看到如下图所示的信息： 
可以看到，K8S的Deployment-Controller为k8s-demo创建了一个ReplicaSet名叫k8s-demo-deployment-54d5c97fb7，后面的Pod就是由这个ReplicaSet来管理的。
（2）查看ReplicaSet的状态
kubectl describe replicaset -n aspnetcore 会得到以下两个图所示的信息： 
从上图可以看出，这个ReplicaSet是由Deployment k8s-demo-deployment 创建的。 
从上图中的日志（Events代表日志）可以看出，两个副本Pod是由ReplicaSet-Controller创建的，且创建成功。
（3）查看Pod的状态
kubectl describe pod -n aspnetcore 同样，也会得到如下图所示的两个信息： 
可以看出，此Pod是由ReplicaSet k8s-demo-deployment-54d5c97fb7创建的。下图的日志记录了Pod的启动过程： 
从日志中可以看到Pod的启动过程，如果启动过程中发生了异常（比如拉取镜像失败），都可以通过输出的错误信息查看原因。
下图是整个Deployment的部署过程，即kubectl→Deployment→ReplicaSet→Pod，也可以看出对象的命名方式的规则： 
2.2 伸缩Scale
所谓伸缩，是指在线实时增加或减少Pod的副本数量。在刚刚的部署中，我们在配置文件中定义的是2个副本，如下图所示： 
可以看到，两个副本分别位于k8s-node1 和 k8s-node2上面。一般默认情况下，K8S不会将Pod调度到Master节点上，虽然Master节点也是可以作为Node节点晒用的。
这时，如果我们想要扩展副本数量从2到3，只需要修改配置文件：
apiVersion: apps/v1
kind: Deployment
metadata: name: k8s-demo-deployment namespace: aspnetcore
spec: replicas: 3
......然后再次apply：
kubectl apply -f k8s-demo-deployment.yaml最终结果如下图所示：
同理，如果想缩小副本数量，也是如上所述的步骤，不再赘述。
2.3 故障转移FailOver
所谓K8S中的故障转移（FailOver），就是当某个Node节点失效或宕机时，会将该Node上所运行的所有Pod转移到其他健康的Node节点上继续运行。
这里继续上例，我们有两个Pod都运行在k8s-node2上，那么我们这里模拟k8s-node2故障，强制关闭该节点：
halt -h 
等待一段时间后（放心，不会很快），当K8S检测到k8s-node2不可用，会将k8s-node2上的Pod最终标记为Terminating状态，并在k8s-node1上新建两个Pod，维持副本总数量为3。 
当然，也可以从Dashboard中直观的看到：
当k8s-node2恢复后，Terminating的Pod会自动被删除，不过已经运行在k8s-node1的Pod是不会重新调度回k8s-node2的。
2.4 善用label控制Pod位置
默认情况下，K8S的Scheduler会均衡调度Pod到所有可用的Node节点，但是有些时候希望将指定的Pod部署到指定的Node节点。例如，一个I/O密集型的Pod可以尽量部署在配置了SSD的Node节点，又或者一个需要GPU的Pod可以尽量部署在配置了GPU的Node节点上。
不用担心，K8S为我们提供了label来实现这个功能，label是一个key/value对，可以灵活设置各种自定义的属性。比如，我们这里假设我们的k8s-demo示例项目是一个I/O密集型的API，还假设k8s-node1是一个配置了SSD的Node节点：
kubectl label node k8s-node1 disktype=ssd
kubectl get node --show-labels 显示结果如下：可以看到，现在k8s-node多了一个label => disktype=ssd 
接下来，我们就可以在配置文件中为要部署的应用指定label了：
apiVersion: apps/v1
kind: Deployment
metadata: name: k8s-demo-deployment namespace: aspnetcore
spec: replicas: 3 selector: matchLabels: app: aspnetcore_webapi template: metadata: labels: app: aspnetcore_webapi spec: containers: - name: k8s-demo image: edisonsaonian/k8s-demo ports: - containerPort: 80 nodeSelector: disktype: ssd然后，再次apply创建资源：
kubectl apply -f k8s-demo-deployment.yaml验证一下，所有的k8s-demo的Pod全都调度到了k8s-node1上面，符合预期：
如果k8s-node1不再是配置SSD了，那么我们就可以为其删掉这个label了：
kubectl label node k8s-node1 disktype-注意，这里的 - 就代表删除，而且此时Pod不会重新部署，除非你删除配置文件中的配置然后再次apply。
03
—
小结
本文介绍了K8S中创建资源的两种方式及对比，然后重点介绍了一下Deployment这个Controller，把玩了Deployment类型的应用运行、伸缩、故障转移以及使用label来控制Pod的位置。运行应用是K8S最核心的功能，下一篇会继续研究DaemonSet和Job这两个Controller的应用方式和场景。当然，笔者也还是初学，有很多不足之处，也请多包涵。对于催更的童鞋，请耐心等待。
参考资料：
（1）CloudMan，《每天5分钟玩转Kubernetes》
（2）李振良，《一天入门Kubernets教程》
（3）马哥（马永亮），《Kubernetes快速入门》
恰童鞋骚年，风华不再正茂，仍想挥斥方遒
点个在看少个bug ?
 F. One-Four Overload 构造 + 二分图染色)
 F. Please, another Queries on Array? 线段树 + 欧拉函数)
)
)
