ASP.NET Core on K8S深刻学习（3-1）Deployment

本篇已加入《.NET Core on K8S学习实践系列文章索引》，能够点击查看更多容器化技术相关系列文章。

上一篇《部署过程解析与安装Dashboard》中咱们了解K8S的部署过程，这一篇咱们来了解一下K8S为咱们提供的几种应用运行方式：Deployment、DaemonSet与Job，它们是Kubernetes最重要的核心功能提供者。考虑到篇幅和更新速度，我将其分为两篇文章，本篇会主要介绍Deployment，主要参考自CloudMan《天天5分钟玩转Kubernetes》，也推荐你们购买阅读。

1、建立资源的两种方式

　　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还有一些必填项的验证，完整你能够参考下面这段配置：

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

View Code

　　更多yaml文件的语法基础，能够参考这一篇文章：https://www.kubernetes.org.cn/1414.html

　　如上所示，咱们将资源的属性都写在了一个yaml格式的配置文件中，有了这个配置文件，咱们只须要执行一句：

kubectl apply -f k8s-demo-deployment.yaml

1.3 相关补充

　　若是要删除deployment，也只须要执行一句：

kubectl delete deployment k8s-demo-deployment

　　或者是下面这一句：

kubectl delete -f k8s-demo-deployment.yaml

　　执行以后，K8S会自动帮咱们删除相关Deployment、ReplicaSet（副本集）以及Pod。

　　能够看出，直接经过kubectl建立会比较省力和快捷，可是它没法作到很好的管理，不适合正式的、规模化的部署，所以咱们通常会更加倾向于采用配置文件的方式，可是使用配置文件要求咱们熟悉yaml的语法，若是存在相似制表符之类的特殊字符都是没法成功执行的。

2、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。

3、小结

　　本文介绍了K8S中建立资源的两种方式及对比，而后重点介绍了一下Deployment这个Controller，把玩了Deployment类型的应用运行、伸缩、故障转移以及使用label来控制Pod的位置。运行应用是K8S最核心的功能，下一篇会继续研究DaemonSet和Job这两个Controller的应用方式和场景。固然，笔者也仍是初学，有不少不足之处，也请多包涵。对于催更的童鞋，请耐心等待。

参考资料

（1）CloudMan，《天天5分钟玩转Kubernetes》

（2）李振良，《一天入门Kubernets教程》

（3）马哥（马永亮），《Kubernetes快速入门》

 

做者：周旭龙

出处：https://edisonchou.cnblogs.com

本文版权归做者和博客园共有，欢迎转载，但未经做者赞成必须保留此段声明，且在文章页面明显位置给出原文连接。