來自社群使用者（SRE運維手記）投稿
背景
在雲原生的時代背景下，Kubernetes 已經成為了主流選擇。然而，Kubernetes 的原生操作複雜性和學習曲線較高，往往讓很多團隊在使用和管理上遇到挑戰。因此，市面上出現了許多對 Kubernetes 進行封裝和最佳化的工具，其中 KubeSphere 是一個整合了多種開源工具、提供全方位解決方案的企業級容器管理平臺。
我們團隊早期在持續整合和持續交付（CI/CD）、微服務治理、多租戶管理和 DevOps 自動化方面就遇到了不少挑戰，如 Jenkins 的許可權管理短板、開發除錯互動困難、多叢集管理分散增加運維成本等。為了提升開發效率和運維質量，我們決定評估和引入一個適合的 Kubernetes 平臺工具。經過調研和比較，我們最終選擇了 KubeSphere。
選型說明
我們選擇了 KubeSphere 3.3.2 版本，在選型過程中，我們主要考量了以下幾個因素：
- 易用性：平臺是否提供直觀的使用者介面和簡單易懂的操作流程，能夠降低學習成本。
- 功能完備性：平臺是否整合了 CI/CD、監控、日誌管理、微服務治理等功能，能夠滿足我們現有和未來的需求。
- 擴充套件性：平臺是否支援外掛機制，能夠方便地整合第三方工具和服務。
- 社群活躍度：平臺的社群是否活躍，是否有及時的技術支援和豐富的文件資源。
在對比了幾款主流的 Kubernetes 平臺工具後，我們發現 KubeSphere 在上述幾個方面表現得都非常出色。尤其是在易用性和功能完備性方面，KubeSphere 提供了使用者友好的介面和全方位的功能整合，能夠顯著降低我們的運維難度和學習成本。
實踐過程
基礎設施與部署架構
我們使用的是公有云環境，劃分了 3 個 VPC，分別為非生產網路、生產網路，以及運維網路，其中非生產和生產網路隔離，而運維網路與其他網路打通，我們在運維網路中部署了運維中控平臺用於管理這 3 個 VPC 的資源，KubeSphere 則藉助其聯邦模式，以運維網路的叢集為主，其餘網路的叢集為成員，實現多叢集管理，為了方便運維中控平臺的管理，伺服器推行了標準化，保障規格和配置的一致性，統一採用 32 核 128G 的配置，作業系統為 Centos7.9。
KubeSphere 叢集節點介面截圖：
部署架構示意圖：
相關業務與 KubeSphere 的契合點
在選擇和使用 KubeSphere 的過程中，我們發現它與我們現有的業務需求有著高度的契合，具體表現在以下幾個方面：
-
持續整合與持續交付（CI/CD）：我們的開發流程高度依賴於 CI/CD 流水線，以確保程式碼的快速構建、測試和部署。我們採用的是 Jenkins pipeline 的技術方案，恰好 KubeSphere 也整合了 Jenkins，支援 pipeline 的流水線釋出，使我們能夠快速遷移和整合現有的 CI/CD 流程。
-
可觀測性和日誌管理：KubeSphere 整合了 Prometheus、Grafana 和 EFK（Elasticsearch、Fluentd、Kibana）等工具 ，與我們在用的運維技術框架非常相似，也方便我們快速遷移。
-
易用性和使用者體驗：Kubernetes 的原生操作複雜性較高，而 KubeSphere 提供了直觀的使用者介面和簡單易懂的操作流程，使得我們的開發和運維人員能夠快速上手並高效使用。KubeSphere 的易用性大大降低了我們的學習成本，提升了團隊的整體工作效率。
總的來說，KubeSphere 在多個方面與我們的業務需求高度契合，透過其全面的功能整合和優異的使用者體驗，顯著提升了我們的開發和運維效率，確保了業務的持續穩定執行。
儲存與網路
儲存
因為是公有云環境，我們選擇了阿里雲 NAS 作為 K8s 叢集的儲存，走的是 NFS 協議，我們根據儲存的效能（通用型和極速型）定義了兩個 StorageClass，其中有狀態應用使用的是極速型儲存，延遲在 0.3ms 左右。另外還安裝了 csi-provisioner 外掛，賦予叢集自動建立和刪除卷的能力，提升運維效率。
網路
cni 外掛用的是阿里雲的 Terway 獨佔 ENI 模式，為每個 Pod 分配一個獨立的 ENI 和 IP 地址，每個 Pod 都擁有自己的網路介面，並且網路效能更接近於傳統虛擬機器。
平臺和應用的日誌、監控、APM
日誌
為了保持業務埋點資料採集流程不受影響，我們採用 Filebeat+Logstash+Elasticsearch+Kibana 的日誌採集和分析方案，在 k8s 叢集部署 filebeat deamonset 採集日誌至外部 Logstash 叢集，經過日誌加工處理後存入 Elasticsearch 叢集，Elasticsearch 叢集採用冷熱分層儲存，最近 14 天的日誌資料會被儲存在熱節點，超過 14 天的日誌資料會被轉移到冷節點。
日誌告警使用 elastalert2，根據自定義的規則實現日誌告警，為了方便規則配置和管理，我們在運維平臺開發了 elastalert2 視覺化管理介面
監控
使用 KubeSphere 平臺整合的 Prometheus-operator+Grafana，多叢集採集的監控指標資料透過 RemoteWrite 的方式傳給 Thanos-Receive，再由 Alertmanager 根據策略進行告警，告警的資料會經過我們自主開發的 NotifyCenter 進行資料格式化、告警分組等，最終推送到電話或者聊天會話。
APM
前端使用 Sentry，後端使用 Skywalking，二者之間透過 RequestId 進行打通實現全鏈路監控，用於異常定位和效能分析。
CI/CD
在 KubeSphere 中，我們透過整合 DevOps 流水線功能和 Jenkins Shared Libraries 提高了 pipeline 的可管理性和程式碼的可複用性。Shared Libraries 的引入有效地解決了我們以往流水線雜亂和難以管理的局面，使得 CI/CD 流程更加高效和一致。
此外，為了進一步統一和管理 Kubernetes 配置，我們採用了 Kustomize 來管理 K8s YAML 檔案。Kustomize 允許我們透過不同的 overlay 輕鬆管理各種環境的配置差異，確保配置的一致性和可維護性。
這種整合使得我們在 KubeSphere 中只需建立一個簡單而高效的流水線，Jenkinsfile 的複雜度也大大降低，示例如下：
有狀態服務管理
我們已經將 Mysql、Redis、Clickhouse、Zookeeper、Etcd 等有狀態服務部署到 K8s，使用有將近一年多，很是穩定，同時也避免了傳統伺服器部署的單點隱患。
使用效果
使用效果主要總結為以下五點：
- 穩定可靠：KubeSphere 在使用過程中表現出極高的穩定性，未出現任何異常。
- 效率提升：KubeSphere 的自動化部署和流水線管理功能顯著提升了開發和運維效率。透過整合 CI/CD 流程，減少了手動操作和人為錯誤，加快了程式碼釋出和部署速度。
- 使用者體驗：KubeSphere 的直觀使用者介面簡化了操作，降低了學習曲線。統一的管理平臺使團隊成員能夠更高效地進行日常運維和監控管理，提升了整體工作體驗。
- 安全管理：KubeSphere 提供了細粒度的許可權控制和全面的審計日誌功能，增強了系統的安全性。透過統一的安全策略管理，我們能夠更好地保護敏感資料和關鍵應用。
- 降低成本：透過 KubeSphere 的便捷視覺化管理，運維可以將部分工作實現開發人員自助化管理，有效降低了運維成本。
未來規劃
隨著 AI 智慧領域的崛起，出現了不少優秀的 AI Agent，也讓我們不得不去思考和探索 AIOPS，我們希望未來的運維場景可以跟 AI 有更多的結合，如故障分析、告警自愈和預測分析等等，同時也希望 KubeSphere 有 AI 功能的出現，相信未來的運維會更加精彩。
本文由部落格一文多發平臺 OpenWrite 釋出！