歡迎光臨
每天分享高質量文章

基於Kubernetes 構建.NET Core 的技術體系

很多公司技術支持崗位的工作,如配置域名,部署環境,修改複位配置,服務重啟,擴容縮容,梳理和完善監控,根據開發的需要查找日誌等工作,需要和開發進行大量的溝通,如什麼是外網域名,什麼是內網域名、A name、C name,防火牆規則該如何設定,操作系統等基礎環境需要什麼依賴。因為很多研發不瞭解運維的術語和知識點,導致溝通困難,效率很低。而且這樣的需求還很多,把運維壓的喘不過氣,占用了幾乎所有的時間,但是開發的需求可能還是遲遲不能滿足。

這樣的公司可能遇到了以下問題:

  • 系統架構過於陳舊,性能、可靠性無法滿足現有的需求;
  • 原有IT架構不靈活,業務模塊新增或變更帶來巨大成本壓力;
  • 系統功能繁雜,結構紊亂,定製的代碼與系統耦合性極高;
  • 服務種類繁多,各種技術棧橫行;
  • 人員流動交接不充分,新接手的團隊對部署環境不瞭解,只能做周邊的修補,不敢遷移 。

如何才能解決?答案是流程化、標準化、自動化、平臺化。

流程化

即主動梳理運維工作任務,形成標準化的操作流程,尤其是針對需要多人協作完成的任務,比如應用的發佈部署,把流程固化到流程平臺系統中,保證每個人執行都能按照流程嚴格執行,不會有哪些環節遺漏,而且當前的流程狀態對所有人都可見,能清晰的看到誰正在處理,處理人也會更主動儘快的完成該任務。

標準化

從架構角度按照應用類別制定應用的部署標準,比如Web型別的應用,服務化的應用(我們內部用的.NET Core),或者是比較新的微服務的應用(.NET Core等),部署腳本和工具平臺按照約定好的規範進行設計開發(基於Kubernetes),減少了因為應用種類繁多導致工具和平臺的複雜。

自動化

很多公司早期寫了非常多的腳本,任務執行機到要執行任務的服務器之間通過SSH免密鑰認證,再根據需要批量執行命令。隨著服務器規模和應用數量的擴張,很快腳本執行的方式無法滿足業務發展,難以理解,同一個型別的任務多個腳本並存,存在誤操作,缺乏清晰的操作歷史記錄和回滾機制,即使後續替換瞭如Puppet,Saltstack,Ansible這樣的配置管理工具,但根本問題並沒有解決。

平臺化

平臺化一定要在前面三條的基礎上進行建設,如果沒有清晰的流程,明確的標準,平臺建設起來也只是自動化工具的集成,解決不了公司核心問題。

以下說的平臺化內容主要是PaaS平臺化,即主要從應用和中間件的角度,這裡不討論IaaS的內容。

PasS平臺化將問題的關註點從基礎資源上升到了應用層面,標的是提供一個幫助開發人員運行、管理應用的平臺,讓使用者更關註運行的代碼(業務邏輯)。
PaaS能解決的問題:

  • 應用聚合:如開發需要一個Redis,直接啟動一個Redis容器即可
  • 服務發現、快速伸縮、狀態管理等
  • 服務監控、恢復、容災
  • 安全管控:不管什麼平臺,安全都非常重要,例如A應用可以訪問B,B不允許訪問A以及安全審計等。
  • 快速部署。

隨著Docker容器技術的出現,讓我們有了更合適的工具建設PaaS平臺,具備了基於應用構建服務的能力。 在Docker容器調度框架上,我們自然選擇了Kubernetes平臺。Kubernetes具有資源調度、服務發現、服務編排、資源邏輯隔離、服務自愈、安全配置管理、Job任務支持、自動回滾、內部域名服務、健康檢查、有狀態支持、運行監控/日誌、擴容縮容、負載均衡、灰度升級、容災恢復、應用HA等。Kubernetes的核心是如何解決自動部署,擴展和管理容器化(containerized)應用程式。

下圖是一張最小化的PaaS 架構圖:

  1. 最上面的Ingress服務跟傳統的負載均衡器的功能類似,提供請求分發的功能,分為兩類: 對外提供API服務的API網關以及對外提供服務的站點,對外的API網關採用Ocelot 進行開發,Ocelot完成了對Kubernetes的集成工作,這個功能已經在我們的平臺上工作一段時間了,上個月把代碼合併進入Ocelot主幹,已經可以通過Nuget包下載,具體參見 kubernetes 客戶端KubeClient使用及常用api
  2. Service相當於後端Pod的一個代理服務器,Service需要通過Ingress服務才能被外部Client訪問, Service 提供了服務的註冊和服務發現。
  3. Pod則相當於我們傳統的一個服務。
  4. 最小化PaaS平臺還用到了DNS組件,在內部服務運行起來之後,我們會通過DNS組件分配一個內部域名供訪問時使用。

Kubernetes 選用騰訊雲 TKE ,TKE 服務在集群內預設啟用了基於騰訊雲負載均衡器實現的 l7-lb-controller,支持 HTTP、HTTPS,同時也支持 nginx-ingress 型別,可以根據業務需要選擇不同的 Ingress 型別。

平臺關鍵能力說明
  • 應用持續部署,平臺實現快速、可視化自動部署功能。支持對應用的快速、可視化部署。用戶僅需在界面中選擇相應的鏡像和組件,並填寫簡單的配置信息,點擊部署按鈕,即可完成整個應用的安裝或者升級。
  • 應用彈性伸縮,構建具有需求預測和容器按需供給能力的彈性伸縮子系統,具有基於應用的負載和資源情況進行彈性伸縮能力,以應對互聯網用戶高併發的特點,應對流量衝擊。其中,包括容器彈性伸縮、物理機彈性伸縮功能。
  • 容器和組件的統一管理,從整體應用的角度出發,平臺不僅管理鏡像和容器,而是將一個應用涉及的所有組件均做了統一管理,通過對系統相關組件和容器統一管理,平臺將可以實現系統的全域性統一部署、配置、升級/回滾、監控、故障處理等功能。
  • 高可靠性,容器的故障恢復,當服務器宕機時,平臺系統會自動在其它服務器上重新啟動容器併為其分配資源,從而達到秒級啟動,恢復業務。保障業務不掉線,高可靠運行;
  • 應用Docker化封裝,系統支持如下幾類常見應用:.NET Core、Jexus、Nginx、Redis、Mongodb等。
PaaS平臺功能組件

具體實施時,主要有幾個基礎組件需要開發:

  • 鏡像管理,實際運行的應用鏡像由 “基礎中間件鏡像”+“應用包”+“配置” 自動構建,借助於Visual Studio 2017/2019以及Visual Studio Code,以及微軟開源的Helm、Draft,通過標準化內部培訓,讓開發人員快速理解鏡像概念和製作鏡像以及開發流程;
  • DNS管理,定製化公司內部使用的DNS管理平臺,對公司的DNS進行統一管理;
  • 服務管理,需要定製化一套Kubernetes的Deployment模板,從Ingress到Service再到RC都定義在這套模板裡面,方便對容器進行擴容、縮容、刪除操作;
  • 服務內Pod管理,屬於Kubernetes自有範疇,查看Service內的Pod運行情況、Pod日誌輸出等功能;
  • 日誌管理,將日誌輸出到公司的日誌平臺(如ELK平臺),對接研發人員排查問題、資料埋點使用;
  • 監控管理,參考方案:cAdvisor + InfluxDB + Grafana/ Heapster + Grafana/Prometheus/Zabbix:https://www.cnblogs.com/Cherry-Linux/p/9144650.html

雖然我們屬於創業公司,我們相信技術的力量,技術幫助我們實現業務的持續健康發展,從發展的初期就規避很多公司的一些困境,一個中小企業做成這樣後,日常運維的工作量即可大量減少,兩三個人就能完成日常的應用運維工作,有興趣地話可以去挑戰一下。當然做完這些後,還只是一個小型的PaaS平臺,我們基於騰訊雲的TKE 平臺構建這樣一個小型的PaaS平臺。
如果是再複雜一點的PaaS平臺,應該還有哪些要繼續做的呢?環境管理:即一套平臺管理多套不同的Kubernetes集群、安全管理、流程管理、計費管理等功能模塊。還有因為規模增加和更高的可靠性要求,對應的網絡,IO等各種優化。其實還有很多功能就不一一列舉了,可以根據自己的實際情況添加功能模塊,設計有自己公司特色的PaaS平臺。

赞(0)

分享創造快樂