基於 KubeSphere 的運管系統落地實踐

語言: CN / TW / HK

時間 2022-12-16 08:01:26 KubeSphere

主題:

作者：任建偉，某知名網際網路公司雲原生工程師，容器技術信徒，雲原生領域的實踐者。

背景介紹

在接觸容器化之前，我們團隊內部的應用一直都是基於虛擬機器運管，由開發人員自行維護。

由於面向多開發部門服務，而開發人員運維能力參差不齊，所以每次部署新的環境時往往都要耗費大量時間。

針對部署難的問題，我們將部分元件、服務容器化，採用 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 釋出！

「其他文章」