解構HE2E中的Kubernetes技術應用
摘要：我們從Kubernetes技術應用的角度解構華為雲DevCloud HE2E DevOps實踐。
本文分享自華為雲社群《解構HE2E中的Kubernetes技術應用》，作者： 敏捷小智 。
在《解構 H E2E 中的容器技術應用》 一文當中，為大家分析了HE2E專案的程式碼倉庫、編譯構建、部署等各環節中對於容器技術的應用。今天，我們將從Kubernetes技術應用的角度解構華為雲 DevCloud HE2E D evOps 實踐 。
什麼是Kubernetes？
Kubernetes （也稱K8S）是用於自動部署，擴充套件和管理容器化應用程式的開源系統。
K8S與CCE
在上一篇文章中，大家已經瞭解了HE2E專案中通過Docker實現容器化部署，在該實踐中通過此方式部署至ECS彈性雲伺服器中，並稱之為ECS部署。在該實踐中，提供了另外一套部署方式，將應用部署至CCE叢集當中，即CCE部署，使用的工具即K8S。
總之，根據部署目標的不同，HE2E實踐中分別介紹了ECS部署與CCE部署。根據部署採用的技術工具不同，也可以將這兩種方式稱為Docker部署與K8S部署。
為什麼選擇K8S
在正式的生產環境中，企業和團隊往往會需要將應用部署至多個伺服器主機，而CCE叢集和K8S則共同為應用的部署、執行及管理提供了保障。相較而言，HE2E實踐中介紹的ECS部署方式更傾向於開發、測試等環境下的單機部署。
K8S的程式碼配置
回到專案本身，程式碼倉庫中的./kompose/資料夾下有多個yaml檔案。可以看出，每個服務都有兩個配置檔案（*-deployment.yaml與*-service.yaml）共同進行配置。
此處以db-deployment.yaml為例，對yaml配置僅作簡短的介紹，幫助大家理解配置內容。隨著叢集版本和產品能力的更迭，也有很多配置資訊將發生變化。所以在實踐當中，需要調整 yaml 檔案配置 。
• apiVersion：此處值為apps/v1，這個版本號需要根據安裝的K8S版本和資源型別進行變化。目前實踐中對應v1.19版本的K8S叢集。
• kind：此處建立的是Deployment，根據實際情況，此處資源型別可以是Pod、Job、Ingress、Service等。如：在*-service.yaml檔案中，建立的資源型別則是Service。
• metadata：包含Deployment的一些meta資訊。其中，annotations的含義是註解。
• spec：你所期望的該物件的狀態。包括replicas、selector、containers等Kubernetes需要的引數。其中，containers定義了該deployment使用的映象：docker-server/docker-org/postgres:9.4。在上篇文章中提到過，這裡的docker-server、docker-org都會在構建任務中替換為實際映象對應的映象地址和組織。strategy、restartPolicy等欄位共同構成了容器失敗時重啟的策略。
在*-service.yaml當中，主體內容與*-deployment.yaml相差也不算大，主要差異集中於spec這部分。*-service.yaml對應的spec主要是定義了叢集內訪問的方式，使各個服務之間可以互相訪問。
可以看出，*-deployment.yaml 與*-service.yaml共同定義了一個服務*。*-deployment.yaml主要定義了該服務的映象源，或者說工作負載是什麼。而*-service.yaml則定義了該服務訪問方式。
K8S的部署配置
在編譯構建環節，主體還是製作映象上傳到SWR映象倉庫，與上篇文章的沒有區別。相關的配置檔案也通過構建任務上傳到軟體釋出庫了，所以這裡就不贅述了。
映象、配置和叢集資源都準備妥當以後，就是使用K8S部署的環節了。
代理機配置
我們在HE2E實踐中採用的是代理機的部署方式，將叢集中的一個節點作為代理機進行授信、部署。所以在實踐中我們從叢集下載Kubectl配置檔案並配置到節點主機當中（見《配置 Kubectl 》）。通過配置Kubectl的操作，我們就可以在節點主機上執行命令進而影響整個CCE叢集。
CCE部署任務
HE2E實踐中，phoenix-cd-cce是我們所需執行的部署任務。該任務將配置檔案傳輸到目標主機，即代理機、叢集節點。
而後，通過執行shell命令啟動Kubenetes。
kubectl delete secret regcred kubectl create secret docker-registry regcred --docker-server=${docker-server} --docker-username=${docker-username} --docker-password=${docker-password} --docker-email=***@***.cn kubectl delete -f /root/phoenix-sample-deploy/kompose/ kubectl apply -f /root/phoenix-sample-deploy/kompose/
• 這裡先是刪除原有的secret，這一步主要是為了防止由於使用臨時登入命令變化而導致secret錯誤引發的任務執行失敗。
• 接著，建立新的secret。包含docker-server、docker-username、docker-password等資訊。
• 按配置檔案（/root/phoenix-sample-deploy/kompose/）刪除資源。
• 按配置檔案（/root/phoenix-sample-deploy/kompose/）對資源進行配置。
成功執行該部署任務後，可以在CCE叢集中看到五個工作負載已經處於“執行中”的狀態。
不過目前還需要設定“節點訪問”才能正常訪問。所以在後續實踐中對工作負載vote和result手動新增訪問方式。
節點訪問設定完畢後，即可訪問專案的使用者端與管理端了。
K8S的模板部署方式
理論上，講到現在，HE2E實踐中的K8S部署就已經講完了。但是，筆者猜到，肯定有很多人不喜歡這種通過代理機部署叢集的方式。不過沒關係，下面我就來介紹DevCloud當中的Kubernetes模板部署。
新建模板時，現在可以選擇模板：Kubernetes部署。
進入模板以後，可以選擇叢集型別、區域、名稱空間、部署方式等資訊。
由於本專案通過10個yaml檔案共同配置，所以需要新增相同的“Kubernetes部署”步驟共計10個，每個步驟都對應一個yaml檔案。
而由於我們在程式碼倉庫中的配置並非我們最終部署時所需的配置（經過編譯構建修改docker-server等引數），所以我們需要每個步驟都設定軟體釋出庫中對應的yaml檔案。此時，我們會發現，我們原本的構建任務是將所有yaml檔案進行了打包壓縮後才上傳的，沒有辦法直接選中。所以，我們可以再次建立一個構建任務或者在原有構建任務上進行修改，以使軟體釋出庫中存放有所有的yaml檔案。
構建任務上傳步驟的配置參考：（上傳所有yaml檔案而非打包後上傳）
完成以上配置以後，執行Kubernetes部署模板任務，即可將服務部署至選定的CCE叢集當中。此時再新增節點訪問方式即可訪問使用者端與管理端。
當然，我們也可以將節點訪問也寫入yaml檔案中，實現進一步的一鍵部署。這裡就暫且留作一個小思考題，感興趣的小夥伴可以自己嘗試一下，將節點訪問寫入yaml當中。
結語
本篇文章一面介紹了HE2E實踐中的CCE部署方式，一面又介紹了該實踐中未提到的Kubernetes模板部署。兩者的主要區別是“CCE部署”是通過代理機控制叢集進行K8S部署；Kubernetes模板部署則是直接在叢集中部署。此外，本文也對專案中關於K8S的配置進行了一定程度的解析。
希望可以幫助小夥伴們理解K8S、HE2E，祝大家在技術成長的道路上越走越遠。感謝小夥伴們的閱讀。如果覺得還不錯，不妨點個贊再走~
此文由DevSecOps專家服務團隊出品，前往 專家服務 ，獲取更多DevSecOps工程方法、工具平臺、最佳實踐等乾貨。