本篇文章是 KubeSphere 2020 年度 Meetup 上講師宋磊分享內容整理而成。
大家好，我是宋磊，在運營商的一個科技子公司任職，主要做大數據業務。我主要負責公司的 IaaS 層和 PaaS 層的建設和運營的工作，涉及到兩個層面。因爲 Kubernetes 是一個非常全面的技術體系，並不是我們部署了一個集羣把業務放上去就能開箱即用，涉及到很多方面，比如服務器、網絡、存儲，還有一系列的工具鏈的支持，我們才能真正的去投產，所以我們團隊是比較適合做這件事的。
業務類型和實踐架構
我們目前有三種類型的業務： 1.接口的服務，容量佔比是比較大的一塊 2.APP 的應用 3.外部的應用系統，主要做智慧政務、智慧生態、智慧城市、智慧旅遊等業務
這三個類型的業務，整體的 TPS 的峯值大約在 2500，平均在 1500 左右。
我們整體的集羣規模：我們所有的集羣都是以物理服務器進行部署的，生產集羣有 50 個物理節點，測試的集羣有 20——30 個節點，整體的 Kubernetes 集羣的規模不到 100 個物理節點。
上面這張圖是我們 Kubernetes 的實踐。
IaaS 層： 數據中心物理層的網絡是 SDN 加 VXLAN 的架構，後續對於網絡插件的選型是有考慮的。
存儲這一塊我們主要是對接 Ceph，我們有一個比較大的 Ceph 集羣，大概有 50 個物理節點，其中對接層不單單跑了 KubeSphere 的這些業務，還跑了一些 OpenStack 的虛擬機。我們在 Ceph 上面做了一些數據的分層，閃存盤(存放集羣元數據)和 SATA 盤(存放真正的數據)，也做了一些數據的熱度分層，然後以 KubeSphere 爲中心的容器集羣周邊做了很多對接的工具鏈。這其中的一些工具鏈不是容器化的，而是外鏈的，比如說 CMDB 配置管理，Prometheus 的監控，Skywalking 主要做微服務的全鏈路監控，還有一些日誌的採集分析，主要還是以 ELK 的工具鏈爲主，也是在 KubeSphere 集羣之外的，DevOps 這層是基於 Jenkins 的 pipeline 去做的。
然後流量入口這一塊，因爲我們所有的業務類型都是互聯網性質的，所以我們在互聯網區域有一個整體的 Nginx 的集羣，主要做業務的路由分發和流量的集中控制。
存儲和網絡的選型與實踐
網絡
上文已經提到我們的物理網絡已經是 SDN 加 VXLAN 的大二層的租戶性質，所以對於 KubeSphere 的網絡插件的選型，目前主要就兩種——Calico 和 Flannel。
Flannel 本身就是基於 VXLAN的，如果選擇它的話，相當於我們兩個層面——物理網絡和 Kubernetes 網絡都是 VXLAN，這就涉及到兩次層面的封包和解包的問題，對性能還是有一定的影響的，所以我們最終還是選擇了 Calico 這種純三層的 BGP 的網絡，然後做網絡的插件。
存儲
目前我們主要對接的是 Ceph 的塊存儲，服務於一些有狀態的服務，比如我們會做一些 helm 的鏡像，主要是 Zookeeper、Redis、MySQL。但是這些有狀態的服務主要是在測試集羣，給開發測試人員使用的。生產環境主要是一些無狀態的服務，比如分佈式框架的 Java微服務應用，還有 Python 和 go。go 主要是用來做區塊鏈，因爲現在區塊鏈跟 K8s 結合是非常有必要的業務類型。
但是 RBD 塊存儲有侷限性，我們很多業務需要多個 Pod 或者多個容器共同讀寫某一塊存儲，但塊存儲是實現不了的，後續我們還會有對象存儲和網絡存儲（NFS）的對接。
DevOps 和日誌採集的實踐
CI/CD 這塊，底層是 Jenkins，沒有集成到 KubeSphere 裏，因爲我們之前有一個 Jenkins 的 Master 和 Slave 的架構的平臺，基於 pipeline，鏡像直接打到 Kubernetes 集羣，做自動化的 CD。
日誌採集相對來說會麻煩一點，目前對接的 ELK 的工具鏈，底層主要是採集三種類型的日誌，宿主機日誌、Pod 業務日誌和 Kubernetes 組件相關的日誌。宿主機和 Kubernetes 組件日誌都是基於宿主機採集。
Pod 業務日誌的採集，主要有兩種方式：
- 在 Pod 里加一個 Sidecar 的容器
- 在一個業務容器裏起兩個服務，前臺服務是 Java 的微服務，後臺是採集的 Filebeat 的 agent，然後將採集agent直接打到鏡像裏運行
ELK 的工具鏈是比較成熟的工具鏈了，可以參見上圖。
灰度發佈
我們是以兩種形式來進行灰度發佈。
-
針對小版本迭代 基於權重，通過 Kubernetes 控制器的副本特性來做灰度發佈。一個業務中有多個副本，先灰度發佈一兩個，沒有問題就繼續灰度發佈，如果有問題就回退。這種方式是比較常規的。
-
針對大版本迭代 使用業務灰度方式。針對用戶的 HTTP 請求的頭部以及 body 裏用戶的 ID，通過 Nginx 和 lua 腳本，分發到不同的版本上面去。
服務治理
我們對於服務治理這塊後續可能會有一些需求，目前沒有一種特別好的實踐方式。
目前來說我們對於微服務治理都是基於輔助的手段，比如全鏈路監控，日誌的指標，來做微服務的流量控制和壟斷。後續我們想往服務網格上探索，把流量的監測和控制放在平臺層，開發只需要專注於業務的邏輯，目前還沒有比較好的落地方案。
本文由博客一文多發平臺 OpenWrite 發佈！