容器 PaaS 新技術架構下的運維實踐

2018年11月16-17日，運維&容器技術盛會 CNUTCon 全球運維技術大會在上海·光大會展中心成功舉辦。時速雲聯合創始人兼 CTO 王磊受邀參加這次大會，並發表主題演講。
王磊這次演講的題目爲《容器PaaS 新技術架構下的運維實踐》，詳細爲你們講解了在基於 Docker +Kubernetes 構建容器 PaaS 的過程當中，如何以應用爲中心，經過新的技術、工具對服務、節點、集羣、平臺等多個方面進行管理運維，提升系統的自動化運維能力。同時結合基於容器PaaS 構建 DevOps、微服務產品的實踐經驗，分享如何在簡化DevOps 工具和微服務框架自己的同時，提升其可用性和簡化運維管理的成本。

王磊認爲，隨着容器技術的普及落地，容器 PaaS 平臺成爲了企業雲計算戰略或雲平臺建設中不可或缺的部分；同時，容器技術也推進了DevOps 和微服務的逐步標準化和深刻發展，容器 PaaS已經成爲這些新理念、新技術、新框架的理想支撐平臺。但在容器 PaaS 新技術架構落地過程當中，企業和運維人員還面臨着以下挑戰:

• 新技術、新理念帶來的學習成本
• 技術生態的飛速發展帶來的複雜性以及如何保證其穩定性
• 管理高密度、快速變化的運行時環境的複雜性
• 如何在新技術架構下提升自由度和創新能力
• 如何進行跨中心的開發協做 – DevOps
• 微服務架構下的平臺支撐及運維

咱們先來看一下基於 Kubernetes 的容器 PaaS 平臺有哪些運維的主要方式，這裏從用戶服務、節點、集羣、平臺自身運維幾個角度分別介紹。

用戶服務運維的手段，主要包含如下幾點：

• 所在節點故障，自動遷移 - 設置合適的驅趕時間
• 設置探針，防止容器中服務無響應時帶來的故障
• 合理設置探針各項參數，滾動升級時保障服務不中斷
• 使用PodDisruptionBudget服務可用性、PodSecurityPolicy安全性、定義 PriorityClass優先級
• 經過服務分佈及各項資源使用狀況，打散熱點進行從新調度
• 根據服務的狀態、重啓次數等數據及持續時間告警
• 根據服務日誌匹配策略、頻率告警
• 結合 ConfigMap與 gitlab的配置版本控制
• 把調試工具交給用戶
• 服務操做審計、事件統一管理

同時對於數據中間件的支撐，能夠經過 CRD 和自定義 operator 的方式來對不一樣的中間件集羣進行部署運維等操做。包括集羣的建立維護，數據的備份恢復，存儲的擴容等，均可以經過不一樣的 CRD 及 controller 的方式進行實現，既要保證服務的可用性，又要保證數據的安全性。

集羣節點的運維，能夠從如下幾點考慮並靈活運用：

• 主要資源指標監控、告警
• Node affinity /taint
• 鏡像、容器gc 策略
• 擴展節點設備類型- ListAndWatch / Allocate
• 節點維護狀態
• 時間同步
• 節點故障、自定義 agent 上報異常狀況

• 節點資源不足時的處理

  驅趕策略
  節點 OOM 行爲
  最佳實踐（預留資源、服務QoS、DaemonSet）

對於 Kubernetes 集羣的運維，主要從集羣高可用、聯邦集羣、資源管理、配額管理，集羣的運維工具、清理工具等方面進行了介紹。同時，在不一樣的底層 IaaS 平臺基礎上，還能夠充分發揮 IaaS 的一些能力來簡化或者改善容器 PaaS 的運維工做。隨着 Kubernetes 自身的快速迭代，升級也就成了不起不考慮的一方面，目前咱們提供兩種升級路徑，in-place或者 data migration，分別適合小版本升級和跨度較大的版本升級。

同時，對於整個平臺的監控、運維，咱們開發了一個獨立的、易於部署的監控平臺，用來對開發測試鏡像倉庫，生產鏡像倉庫、PaaS 平臺、各種 API 服務、K8s 集羣及其核心組件、各節點組件等進行統一狀態收集，能夠監控相關服務的狀態，也能夠對歷史狀態和異常狀況進行回溯，從總體上考量每一個組件的服務質量。

對於平臺的運維，固然也要考慮到對數據的備份和恢復，以便在某些場景下對數據進行回滾操做。咱們的容器 PaaS 上也提供了平臺、集羣相關的數據定時備份及恢復管理，能夠把平臺的 MySQL 數據及每一個集羣的 etcd 數據進行統一管理，也容許接入自定義備份源，實現對數據的統一管理。

接下來，介紹一下咱們如何基於 Kubernetes 構建本身的 DevOps 平臺。首先說一下時速雲對本身的 DevOps 平臺的指望：

• 能夠更簡單的同其它 DevOps 或者第三方工具集成
• 用戶的 DevOps 需求比較多樣，須要有更好的定製能力
• 更容易安裝、運維、擴展和伸縮
• 減小客戶和公司內部的學習成本
• 同 PaaS 平臺保持一致的用戶體驗和數據一致性，充分發揮 PaaS 平臺已有的能力
• 幫助本身的 PaaS 和微服務治理產品實現更好的 DevOps 能力

總體 DevOps 平臺的基本架構以下，經過自定義 CRD 和 operator 來對構建任務進行管理，日誌的收集、監控告警、節點管理、構建資源的伸縮、配額管理、權限控制均可以同PaaS 層的能力相一致，同時能夠利用 PaaS 上的 Pod、Job、CronJob、Volume、ConfigMap、Secret 等諸多資源的能力，在持續集成、持續交付、持續部署等方面進行創新。將來 PaaS 層的新功能、功能改善，均可以直接適用於 DevOps 平臺，大大下降了 DevOps 的開發和運維成本。

接着，咱們來看一下如何在 DevOps平臺上實現 CI/CD的一些例子：

• 實現 docker 鏡像的構建
• 如何對構建中的產出物進行管理（war 包、jar 包等）
• 實現 Gitlab/Jenkins/Sonar 等工具的集成
• 人工審覈任務
• 實現 Gitlab/Harbor/Jira 等工具的集成

最後，再分享一下如何在容器 PaaS 的新技術平臺上更好的支撐位服務治理框架。主要包括如何對跨部門、跨中心的微服務協同開發進行支撐，如何減小微服務框架和 PaaS 平臺之間的能力衝突，使彼此更好的融合。

在 Spring Cloud 和 K8s融合方面，可使用 Spring Cloud開源的依賴項目，使用 K8s自身的服務發現、配置管理等相關能力；同時爲了方便管理運維，咱們將 Zuul 的路由配置使用數據庫進行持久化，將 Zipkin 的調用鏈數據和 Hystrix 的熔斷監控數據分別進行了持久化，以便隨時對歷史數據進行回溯；也能夠直接在微服務治理平臺上動態配置熔斷策略或者開啓降級操做。

在 Dubbo 和 K8s 融合方面，咱們在 K8s 上進行了擴展，並對 Dubbo 的依賴包進行定製，替換了 zookeeper，使用 k8s 做爲服務發現和註冊中心，並支持 dubbo consumer 和 provider 之間經過 K8s 的 service 或者 pod ip 進行通訊，用戶能夠根據本身的需求選擇使用服務端負載均衡仍是 Dubbo 的客戶端負載均衡。

綜上，咱們一直致力於打造具有可靠、簡單、自動化、集成擴展、協做等特色的容器PaaS、DevOps 和微服務治理平臺，但願可讓用戶更快捷、安全的進行雲原生應用的實踐與創新，將來咱們也會繼續在自動化、智能化運維以及引入適合於 容器 PaaS 的 ChatOps 上繼續本身的努力。