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

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

背景介紹

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

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

針對部署難的問題，我們將部分組件、服務容器化，采用 Docker 發布管理解決了部分問題，但仍未降低對開發人員的運維技能要求，

下面是我們基于虛擬機管理開發環境的流程：

從上圖中我們也能發現當前架構存在的問題：

• 下發虛機由各部開發人員管理，虛機安全問題難以維護、保障；
• 基于 shell 運維，專業性過強；
• 基于手動打包、發布，耗時耗力且不可靠，

選型說明

針對上述提到的痛點，我們決定對運維架構進行改造，新建運管平臺，技術選型整體基于云原生，優先選取 CNCF 專案，

Kubernetes 成為了我們平臺底座的不二選擇， 但 Kubernetes 原生的 Dashboard 不太滿足實際使用需求，

而從頭開發一套 workbench 又耗時耗力，由此我們目光轉向了開源社區，

此時，一個集顏值 + 強大功能于一身的開源專案進入我們視野，是的，它便是 KubeSphere，

而 KubeSphere 愿景是打造一個以 Kubernetes 為內核的云原生分布式作業系統，它的架構可以非常方便地使第三方應用與云原生生態組件進行即插即用（plug-and-play）的集成，支持云原生應用在多云與多集群的統一分發和運維管理，

對于 KubeSphere 能否作為部署平臺，最終結論如下：

KubeSphere 雖功能強大，但更適合作為管理端使用，不太適合面向普通用戶，

我們需要本地化一套 workbench ，簡化部分功能，屏蔽專業性術語（如作業負載、容器組、安全背景關系等），

本地化部分內容如下：

• 基于企業空間、命名空間，本地化租戶、作業空間的概念，一個租戶（企業空間）可管理一個到多個作業空間（命名空間），并接入獨立用戶體系，
• 本地化應用發布流程： 由拆分的應用發布流程（構建鏡像+創建負載），本地化為：創建應用 -> 上傳 jar -> 指定配置 -> 啟動運行的串行流程，
• 本地化鏈路監控：構建鏡像預先埋點，創建應用時選擇是否開啟鏈路追蹤，
• 本地化配置、應用路由等，添加版本管理功能，

事實上，我們本地化的重點是應用管理，但是 KubeSphere 功能過于強大、特性過于靈活，導致配置起來項過于繁瑣，

針對部分配置項我們采用設定默認值的方式，而非交由用戶去配置，（比如：容器安全背景關系、同步主機時間、鏡像拉取策略、更新策略、調度策略等）

改造后的運維架構如下：

實踐程序

基于 KubeSphere 的運管平臺整體架構如下：

環境資訊表：

本地化部署流程如下：

鏡像本地化

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 基礎鏡像內，

5. 路由集群外服務

由于部分應用部署于 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 發布！

標籤：其他

上一篇：下一代架構？從組裝式企業到組裝式應用

下一篇：初始Docker