ASP.NET Core on K8S深入学习（3）Deployment
上一篇《部署過(guò)程解析與安裝Dashboard》中我們了解K8S的部署過(guò)程，這一篇我們來(lái)了解一下K8S為我們提供的幾種應(yīng)用運(yùn)行方式：Deployment、DaemonSet與Job，它們是Kubernetes最重要的核心功能提供者?？紤]到篇幅和更新速度，我將其分為兩篇文章，本篇會(huì)主要介紹Deployment，主要參考自CloudMan《每天5分鐘玩轉(zhuǎn)Kubernetes》，也推薦大家購(gòu)買(mǎi)閱讀。
01
—
創(chuàng)建資源的兩種方式對(duì)比
K8S支持兩種創(chuàng)建資源的方式，分別是?使用kubectl命令直接創(chuàng)建?與?通過(guò)配置文件+kubectl apply創(chuàng)建，下面以上一篇中的ASP.NET Core示例來(lái)分別介紹下這兩種方式。
1.1 Kubectl命令直接創(chuàng)建
第一種是通過(guò)kubectl命令直接創(chuàng)建：
kubectl run k8s-demo-deployment --image=edisonsaonian/k8s-demo:latest --replicas=2 --namespace=aspnetcore這樣我們就部署了一個(gè)具有2個(gè)副本的k8s-demo（一個(gè)ASP.NET Core API示例）。
1.2 YAML配置文件創(chuàng)建
第二種是通過(guò)配置文件+kubectl apply(kubectl create也可以)創(chuàng)建：
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不過(guò)，上面的配置文件可能并不能直接運(yùn)行，因?yàn)槟J(rèn)情況下K8S還有一些必填項(xiàng)的驗(yàn)證，完整你可以參考下面這段配置。更多yaml文件的語(yǔ)法基礎(chǔ)，可以參考這一篇文章：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如上所示，我們將資源的屬性都寫(xiě)在了一個(gè)yaml格式的配置文件中，有了這個(gè)配置文件，我們只需要執(zhí)行一句：
kubectl apply -f k8s-demo-deployment.yaml1.3 相關(guān)補(bǔ)充
如果要?jiǎng)h除deployment，也只需要執(zhí)行一句：
kubectl delete deployment k8s-demo-deployment或者是下面這一句：
kubectl delete -f k8s-demo-deployment.yaml執(zhí)行之后，K8S會(huì)自動(dòng)幫我們刪除相關(guān)Deployment、ReplicaSet（副本集）以及Pod。
可以看出，直接通過(guò)kubectl創(chuàng)建會(huì)比較省力和快捷，但是它無(wú)法做到很好的管理，不適合正式的、規(guī)?；牟渴?#xff0c;因此我們一般會(huì)更加傾向于采用配置文件的方式，但是使用配置文件要求我們熟悉yaml的語(yǔ)法，如果存在類(lèi)似制表符之類(lèi)的特殊字符都是無(wú)法成功執(zhí)行的。
02
—
Deployment必知必會(huì)
2.1 Deployment類(lèi)型應(yīng)用運(yùn)行
這里我們?nèi)砸陨厦嫣岬降膋8s-demo示例項(xiàng)目為例，通過(guò)下面這個(gè)配置文件來(lái)創(chuàng)建資源：
通過(guò)下面的命令創(chuàng)建資源：
kubectl apply -f k8s-demo-deployment.yaml下面我們來(lái)看看K8S到底為我們做了些什么工作：
（1）查看k8s-demo-deployment狀態(tài)
kubectl get deployment k8s-demo-deployment -n aspnetcore
? 可以看到，對(duì)于我們的這個(gè)deployment，生成了2個(gè)副本且正常運(yùn)行。
如果想要獲得更加相信的信息，可以使用下面這句：
kubectl describe deployment k8s-demo-deployment -n aspnetcore從deployment的日志中，可以看到如下圖所示的信息：
? 可以看到，K8S的Deployment-Controller為k8s-demo創(chuàng)建了一個(gè)ReplicaSet名叫k8s-demo-deployment-54d5c97fb7，后面的Pod就是由這個(gè)ReplicaSet來(lái)管理的。
（2）查看ReplicaSet的狀態(tài)
kubectl describe replicaset -n aspnetcore會(huì)得到以下兩個(gè)圖所示的信息：
? 從上圖可以看出，這個(gè)ReplicaSet是由Deployment k8s-demo-deployment 創(chuàng)建的。
? 從上圖中的日志（Events代表日志）可以看出，兩個(gè)副本Pod是由ReplicaSet-Controller創(chuàng)建的，且創(chuàng)建成功。
（3）查看Pod的狀態(tài)
kubectl describe pod -n aspnetcore同樣，也會(huì)得到如下圖所示的兩個(gè)信息：
? 可以看出，此Pod是由ReplicaSet k8s-demo-deployment-54d5c97fb7創(chuàng)建的。下圖的日志記錄了Pod的啟動(dòng)過(guò)程：
? 從日志中可以看到Pod的啟動(dòng)過(guò)程，如果啟動(dòng)過(guò)程中發(fā)生了異常（比如拉取鏡像失敗），都可以通過(guò)輸出的錯(cuò)誤信息查看原因。
下圖是整個(gè)Deployment的部署過(guò)程，即kubectl→Deployment→ReplicaSet→Pod，也可以看出對(duì)象的命名方式的規(guī)則：
2.2 伸縮Scale
所謂伸縮，是指在線(xiàn)實(shí)時(shí)增加或減少Pod的副本數(shù)量。在剛剛的部署中，我們?cè)谂渲梦募卸x的是2個(gè)副本，如下圖所示：
? 可以看到，兩個(gè)副本分別位于k8s-node1 和 k8s-node2上面。一般默認(rèn)情況下，K8S不會(huì)將Pod調(diào)度到Master節(jié)點(diǎn)上，雖然Master節(jié)點(diǎn)也是可以作為Node節(jié)點(diǎn)曬用的。
這時(shí)，如果我們想要擴(kuò)展副本數(shù)量從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最終結(jié)果如下圖所示：
同理，如果想縮小副本數(shù)量，也是如上所述的步驟，不再贅述。
2.3 故障轉(zhuǎn)移FailOver
所謂K8S中的故障轉(zhuǎn)移（FailOver），就是當(dāng)某個(gè)Node節(jié)點(diǎn)失效或宕機(jī)時(shí)，會(huì)將該Node上所運(yùn)行的所有Pod轉(zhuǎn)移到其他健康的Node節(jié)點(diǎn)上繼續(xù)運(yùn)行。
這里繼續(xù)上例，我們有兩個(gè)Pod都運(yùn)行在k8s-node2上，那么我們這里模擬k8s-node2故障，強(qiáng)制關(guān)閉該節(jié)點(diǎn)：
halt -h
等待一段時(shí)間后（放心，不會(huì)很快），當(dāng)K8S檢測(cè)到k8s-node2不可用，會(huì)將k8s-node2上的Pod最終標(biāo)記為T(mén)erminating狀態(tài)，并在k8s-node1上新建兩個(gè)Pod，維持副本總數(shù)量為3?！ ?/span>
當(dāng)然，也可以從Dashboard中直觀的看到：
當(dāng)k8s-node2恢復(fù)后，Terminating的Pod會(huì)自動(dòng)被刪除，不過(guò)已經(jīng)運(yùn)行在k8s-node1的Pod是不會(huì)重新調(diào)度回k8s-node2的。
2.4 善用label控制Pod位置
默認(rèn)情況下，K8S的Scheduler會(huì)均衡調(diào)度Pod到所有可用的Node節(jié)點(diǎn)，但是有些時(shí)候希望將指定的Pod部署到指定的Node節(jié)點(diǎn)。例如，一個(gè)I/O密集型的Pod可以盡量部署在配置了SSD的Node節(jié)點(diǎn)，又或者一個(gè)需要GPU的Pod可以盡量部署在配置了GPU的Node節(jié)點(diǎn)上。
不用擔(dān)心，K8S為我們提供了label來(lái)實(shí)現(xiàn)這個(gè)功能，label是一個(gè)key/value對(duì)，可以靈活設(shè)置各種自定義的屬性。比如，我們這里假設(shè)我們的k8s-demo示例項(xiàng)目是一個(gè)I/O密集型的API，還假設(shè)k8s-node1是一個(gè)配置了SSD的Node節(jié)點(diǎn)：
kubectl label node k8s-node1 disktype=ssd kubectl get node --show-labels顯示結(jié)果如下：可以看到，現(xiàn)在k8s-node多了一個(gè)label => disktype=ssd
接下來(lái)，我們就可以在配置文件中為要部署的應(yīng)用指定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創(chuàng)建資源：
kubectl apply -f k8s-demo-deployment.yaml驗(yàn)證一下，所有的k8s-demo的Pod全都調(diào)度到了k8s-node1上面，符合預(yù)期：
? 如果k8s-node1不再是配置SSD了，那么我們就可以為其刪掉這個(gè)label了：
kubectl label node k8s-node1 disktype-注意，這里的 - 就代表刪除，而且此時(shí)Pod不會(huì)重新部署，除非你刪除配置文件中的配置然后再次apply。
03
—
小結(jié)
本文介紹了K8S中創(chuàng)建資源的兩種方式及對(duì)比，然后重點(diǎn)介紹了一下Deployment這個(gè)Controller，把玩了Deployment類(lèi)型的應(yīng)用運(yùn)行、伸縮、故障轉(zhuǎn)移以及使用label來(lái)控制Pod的位置。運(yùn)行應(yīng)用是K8S最核心的功能，下一篇會(huì)繼續(xù)研究DaemonSet和Job這兩個(gè)Controller的應(yīng)用方式和場(chǎng)景。當(dāng)然，筆者也還是初學(xué)，有很多不足之處，也請(qǐng)多包涵。對(duì)于催更的童鞋，請(qǐng)耐心等待。
參考資料：
（1）CloudMan，《每天5分鐘玩轉(zhuǎn)Kubernetes》
（2）李振良，《一天入門(mén)Kubernets教程》
（3）馬哥（馬永亮），《Kubernetes快速入門(mén)》
恰童鞋騷年，風(fēng)華不再正茂，仍想揮斥方遒
點(diǎn)個(gè)在看少個(gè)bug??
總結(jié)
以上是生活随笔為你收集整理的ASP.NET Core on K8S深入学习（3）Deployment的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。
- 上一篇： 史上最能“拜客户教”的公司，是如何做到持
- 下一篇： 8月语言排行：C#继续呈现增长态势