作者：任建偉，某知名互聯網公司雲原生工程師，容器技術信徒，雲原生領域的實踐者。
背景介紹
在接觸容器化之前，我們團隊內部的應用一直都是基於虛擬機運管，由開發人員自行維護。
由於面向多開發部門服務，而開發人員運維能力參差不齊，所以每次部署新的環境時往往都要耗費大量時間。
針對部署難的問題，我們將部分組件、服務容器化，採用 Docker 發佈管理解決了部分問題，但仍未降低對開發人員的運維技能要求。
下面是我們基於虛擬機管理開發環境的流程：
從上圖中我們也能發現當前架構存在的問題：
- 下發虛機由各部開發人員管理，虛機安全問題難以維護、保障；
- 基於
shell運維，專業性過強； - 基於手動打包、發佈，耗時耗力且不可靠。
選型說明
針對上述提到的痛點，我們決定對運維架構進行改造。新建運管平臺，技術選型整體基於雲原生，優先選取 CNCF 項目。
Kubernetes 成爲了我們平臺底座的不二選擇， 但 Kubernetes 原生的 Dashboard 不太滿足實際使用需求。
而從頭開發一套 workbench 又耗時耗力，由此我們目光轉向了開源社區。
此時，一個集顏值 + 強大功能於一身的開源項目進入我們視野。是的，它便是 KubeSphere。
而 KubeSphere 願景是打造一個以 Kubernetes 爲內核的雲原生分佈式操作系統，它的架構可以非常方便地使第三方應用與雲原生生態組件進行即插即用（plug-and-play）的集成，支持雲原生應用在多雲與多集羣的統一分發和運維管理。
對於 KubeSphere 能否作爲部署平臺，最終結論如下：
KubeSphere 雖功能強大，但更適合作爲管理端使用，不太適合面向普通用戶。
我們需要本地化一套 workbench ，簡化部分功能，屏蔽專業性術語（如工作負載、容器組、安全上下文等）。
本地化部分內容如下：
- 基於企業空間、命名空間，本地化租戶、工作空間的概念，一個租戶（企業空間）可管理一個到多個工作空間（命名空間），並接入獨立用戶體系。
- 本地化應用發佈流程： 由拆分的應用發佈流程（構建鏡像+創建負載），本地化爲：創建應用 -> 上傳 jar -> 指定配置 -> 啓動運行的串行流程。
- 本地化鏈路監控：構建鏡像預先埋點，創建應用時選擇是否開啓鏈路追蹤。
- 本地化配置、應用路由等，添加版本管理功能。
事實上，我們本地化的重點是應用管理，但是 KubeSphere 功能過於強大、特性過於靈活，導致配置起來項過於繁瑣。
針對部分配置項我們採用設置默認值的方式，而非交由用戶去配置。（比如：容器安全上下文、同步主機時間、鏡像拉取策略、更新策略、調度策略等）
改造後的運維架構如下：
實踐過程
基於 KubeSphere 的運管平臺整體架構如下：
環境信息表：
| 名稱 | 版本 | 說明 |
|---|---|---|
| kukekey | v1.0.1 | KubeSphere 安裝工具 |
| kubesphere | v3.0.0 | 基於 K8s 的面向雲原生應用的分佈式操作系統 |
| kuberentes | v1.18.6 | 容器編排系統 |
| docker | v19.03.15 | 容器引擎 |
| CentOS | 7 | 操作系統 |
| kernel | 5.4 | 操作系統內核 |
本地化部署流程如下：
鏡像本地化
1️⃣ 基於 harbor 搭建私有鏡像庫。
2️⃣ 離線下載並上傳 kubesphere 依賴鏡像至私有 harbor 內，project 名稱保持不變。
3️⃣ 本地化 B2I 基礎鏡像，本地化如下內容：
- 內置 Arthas，便於調試；
- 內置 SkyWalking Agent 用於集成鏈路追蹤；
- 內置 Prometheus Agent 用於指標監控；
- 添加
windows字體。
4️⃣ 本地化應用商店初始化鏡像（openpitrix/release-app）。
由於預置的 chart 有很多我們實際並未使用，所以我們刪除預置了 chart ，並導入實際所需 chart （包括本地化的中間件 chart 、中臺 chart）
5️⃣ 鏡像 GC。
針對頻繁構建的 repo ，配置合理的 GC 策略：
搭建 K8s
基於 KubeKey 1.0.1 部署了三主多從節點 K8s v1.18.6 集羣：
搭建 Rook 集羣
使用 KubeKey 1.0.1 新增三個存儲節點並打上污點標籤，搭建 Rook 集羣
對於存儲的替換主要出於以下方面考慮：
- 有 Ceph 裸機部署使用經驗；
- 對比默認存儲 OpenEBS Local PV，Rook 支持多存儲類型；
- Rook 爲 CNCF 畢業項目。
搭建 KubeSphere 平臺
基於 KubeKey 1.0.1 部署了 KubeSphere，未作本地化修改。
CI/CD 實踐
CI/CD 部分我們並沒有使用 KubeSphere 提供的流水線功能，而是選擇 gitlab-runner + ArgoCD 方案。
CI 實現
CI 部分利用 gitlab-ci 切換構建時特性，我們抽象出了 provider 概念。provider 本質爲工具 / 程序的容器化封裝，提供某一方面能力了。如：
- maven-provider:
java程序構建時環境，內置私有nexus配置； - npm-provider:
nodejs程序構建時環境，內置私有npm源配置； - email-provider:
smtp交互程序，用於郵件通知； - chrome-headless-provider: 瀏覽器截屏。
使用時，只需引用並傳遞相應參數即可：
variables:
AAA: xxx
BBB: yyy
stages:
- build
- scan
- email
build:
stage: build
image: harbor.devops.io/devops/maven-provider
tags:
- k8s-runner
script:
- mvn clean package
only:
refs:
- develop
changes:
- src/**/*
scan:
stage: scan
image: harbor.devops.io/devops/sonar-provider
tags:
- k8s-runner
script: xxx
rules:
- if: '$CI_PIPELINE_SOURCE == "schedule"'
email:
stage: email
image: harbor.devops.io/devops/sendmail
tags:
- k8s-runner
script:
- /work/send-mail sonar --email-to=$EMAIL_TO_LIST --email-cc=$EMAIL_CC_LIST --sonar-project-id=$PROJECT_NAME --sonar-internal-url=$SONAR_INTERNAL_ADDR --sonar-external-url=$SONAR_EXTERNAL_ADDR
rules:
- if: '$CI_PIPELINE_SOURCE == "schedule"'
CD 實現
CD 部分，我們利用 chart 對應用進行定義，並將 chart 剝離於開發庫，獨立於配置庫進行管理，用於 ArgroCD 同步。
對於配置庫與開發庫分離，主要出於以下考慮：
- 清晰分離了應用程序代碼與應用程序配置。
- 更清潔的審計日誌：出於審計目的，只保存配置庫歷史更改記錄，而不是摻有日常開發提交的日誌記錄。
- 訪問的分離：開發應用程序的開發人員不一定是能夠 / 應該推送到生產環境的同一個人，無論是有意的還是無意的。
通過使用單獨的庫，可以將提交訪問權限授予源代碼庫，而不是應用程序配置庫。 - 自動化
CI Pipeline場景下，將清單更改推送到同一個Git存儲庫可能會觸發構建作業和Git提交觸發器的無限循環。
使用一個單獨的repo來推送配置更改，可以防止這種情況發生。
角色劃分
角色方面，我們定義了三種類型角色，職責如下：
使用效果
通過引入 KubeSphere 平臺以及 CI/CD，效率提升明顯：
- 計算資源池化，不再下發虛機，計算資源統一運管；
- 基於容器化的流水線構建、發佈應用，保障了構建的可靠性，同時解放雙手；
- 基於本地化
workbench運維，由於屏蔽了專業性詞彙術語，降低使用者學習成本。日誌查看、應用更新等操作更爲便捷； - 針對角色的劃分，使得運維邊界清晰，責任明確。
問題 & 解決
在一年多的容器平臺使用過程中，我們遇到了蠻多的小問題，這裏我舉幾個有代表性的例子：
B2I 沒有清理策略
存在問題：
在使用 kubesphere v3.0 的過程中我們發現：不斷通過 B2I 構建應用，會產生大量的 B2I 任務記錄，並且 minio 內上傳的程序包文件越來越多，且並沒有相應的清理策略。
解決方案：
開發定時 job , 定期進行清理。
內核版本過低，導致容器相關漏洞的發生
存在問題：
初期，我們使用 CentOS7 默認的 3.10 版本內核。
解決方案：
升級內核版本至 5.x。
鏈路追蹤
存在問題：
KubeSphere 預裝的 jaeger 不支持 dubbo 協議，無法對 dubbo 應用進行監控。
解決方案：
利用 SkyWalking 用於鏈路追蹤，並在基礎鏡像內埋點。
報表相關服務缺少字體
解決方案：
將缺少 windows 字體安裝至 B2I 基礎鏡像內。
- 路由集羣外服務
由於部分應用部署於 K8s 外部，針對這部分應用我們選擇 Endpoint + ExternalName + Ingress 的方式進行路由。
未來規劃或展望
1️⃣ 有狀態應用的 Operator 開發
當前有狀態應用依賴 helm hook 管理， 且功能單一。
未來我們計劃，針對常用有狀態應用，開發對應 operator，提供創建、擴容、備份等常用功能。
2️⃣ CNI 遷移至 Cilium
選取 Cilium 替換 Calico 主要出於以下考慮 :
Cilium爲CNCF畢業項目，活躍度高；Cilium基於eBPF實現，在粒度和效率上實現了對系統和應用程序的可觀測性和控制；Cilium安全防護功能更強，提供了過濾單個應用協議請求的能力，例如 :- 允許所有使用
GET方法和/public/.*路徑的HTTP請求，拒絕所有其他請求； - 允許
service1在Kafka主題topic1上生產，允許service2在topic1上消費，拒絕所有其他 Kafka 消息； - 要求
HTTP報頭X-Token:[0-9]+出現在所有REST調用中。
- 允許所有使用
3️⃣ cri 由 Docker 替換爲 Containerd
4️⃣ 容器文件瀏覽器功能開發
當前階段，開發人員下載容器內文件的需求，只能由運維人員使用 kubectl cp 的方式協助獲取，後續我們規劃開發容器文件瀏覽器相應功能。
5️⃣ 容器宿主機系統替換爲 rocky，以應對 CentOS 停止維護。
本文由博客一文多發平臺 OpenWrite 發佈！