如何不編寫 YAML 管理 Kubernetes 應用？

Kubernetes 將自身邊界內的事物都抽象為資源。其中的主要部分，是以 Deployment、StatefulSet 為代表的 workload 工作負載控制器，其他各類資源都圍繞這些主要的資源工作。這些資源合併起來，可以為 IT 技術工作者展現出一個以 workload 為中心的模型。Kubernetes 中所有的資源，都通過宣告式配置檔案來編輯描述，一條條的 Yaml 欄位定義，給了 IT 技術人員最大的自由度的同時，也對技術人員的能力提出了極高的要求。

通過應用模型簡化Kubernetes管理

當你的團隊已經使用原生的 Kubernetes 一段時間，你多半會發現，並非每個 IT 技術人員都擅長編寫複雜的 Kubernetes 宣告式配置檔案（YAML）。特別是對於開發人員他們的主要職責是業務開發，學習和編寫YAML會增加他們的負擔，甚至會抵觸使用。

開源專案Rainbond 是一個 雲原生應用管理平臺，它使用 以應用為中心 的設計模式。基於這一設計模式重新抽象出了比 workload 更高層次的應用模型。從使用的體驗上不需要學習和編寫YAML，實現業務應用的全生命週期管理。應用對應一個完整的業務系統，由若干個可以單獨管理的服務元件組成，部署業務元件可以從原始碼和容器映象，通過“拖拉拽”的方式編輯服務呼叫關係。每一個服務元件，可以基於圖形化介面定義使用常見的一些運維特徵。在此基礎之上，使用者還可以利用應用模型這一核心概念，做出更多高階操作，如將整個業務系統以應用模板的形式釋出出來，業務系統可以基於該模板一鍵安裝/升級。在軟體交付這個領域，這種能力十分有用，無論最終交付環境線上或離線，都可以基於應用模板進行快速交付，甚至個性化交付。

Rainbond 使用的應用模型，讓開發人員關注應用和業務本身，更易於被人所接受。對裁剪後保留下來的運維特徵通過圖形介面展示和互動，極大的降低了使用的難度，通過應用模版絕大多數開發者不必編輯複雜宣告式配置檔案就可以順暢使用 Kubernetes 了。

將Kubernetes的YAML轉換成應用模型

整個轉化的過程，可以概括為三個步驟：

1. 對於開發人員最常用Workload，可以從原始碼和容器映象嚮導式的自動生成，或匯入已有YAML和執行應用，匯入過程自動識別所有可轉化的 Workload 型別資源，包括 Deployment、StatefulSet， Job、CronJob 型別。這些資源會被轉化成應用模型，轉化後會以服務元件的形式執行。
2. 匯入生成的服務元件後，基本的Workload屬性通過介面就可以檢視和編輯，如環境變數、映象地址等。轉化過程中會將識別到的高階Workload 屬性新增給服務元件，以Key/Value 或 Yaml 形式檢視和管理。
3. 非 Workload 的資源型別，如 Secret、ServiceAccount、Role 等資源，會被分類識別和載入到應用介面的 k8s資源 頁面中，供操作人員以互動體驗方式進行編輯。

可被納管和轉化的 高階Workload 屬性包括：

屬性名稱	作用
nodeSelector	節點選擇器：指定某種型別節點排程時使用。
labels	標籤：用於為服務元件自定義標籤以被選擇器使用。
volumes	儲存卷：用於定義不被 Rainbond 管理的卷型別的掛載。
volumeMounts	掛載卷：與 volumes 搭配使用，將卷掛載給容器。
affinity	親和性：更高階的排程方式，包括節點親和性和Pod親和性。
tolerations	容忍度：與節點汙點搭配使用，具備指定容忍度的Pod才可以排程到指定節點上。
serviceAccountName	服務賬戶名：為服務元件指定某個已存在的SA，使對應的Pod具備某些許可權。
privileged	特權模式：名副其實的配置，非必要不開啟。
env	環境變數：用於定義不被 Rainbond 管理的環境變數，支援引用操作。

值得注意的是，擴充套件後的 RAM 模型，依然能夠釋出為應用模板，供後續一鍵安裝/升級/交付整套業務系統之用。

匯入已有Kubernetes應用的測試和實踐

以下測試是基於Rainbond v5.8進行的，為了測試 Kubernetes 已有應用匯入，我計劃使用已經在 wp 名稱空間中部署完成的 Wordpress 建站系統來進行一次匯入測試。這套系統由以下資源組成：

[root@localhost ~]# kubectl get secret,service,deployment,statefulset,pod -n wp
NAME                         TYPE                                  DATA   AGE
secret/default-token-nq5rs   kubernetes.io/service-account-token   3      27m
secret/mysql-secret          Opaque                                2      27m
NAME                TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
service/wordpress   NodePort    10.43.157.40    <none>        8080:30001/TCP   5m19s
service/wp-mysql    ClusterIP   10.43.132.223   <none>        3306/TCP         27m
NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/wordpress   1/1     1            1           5m19s
NAME                        READY   AGE
statefulset.apps/wp-mysql   1/1     27m
NAME                             READY   STATUS    RESTARTS   AGE
pod/wordpress-66bc999449-qv97v   1/1     Running   0          5m19s
pod/wp-mysql-0                   1/1     Running   0          27m

訪問 Rainbond ，在叢集處選擇匯入，在這個頁面中，可以選擇要匯入資源的名稱空間 wp。平臺會根據 label 來對資源進行分組：

Rainbond 根據資源定義的 label 來劃分應用，如符合 app.kubernetes.io/name:wp-mysql 或 app:wordpress 的資源，會分佈到圖中兩個不同的應用中去，而不具備上述 label 的資源，則會統一劃分到一個未分組的應用中去。應用的劃分非常關鍵，因為應用模型的高階應用是針對一個應用整體而言的，所以匯入之前一定要仔細規劃，新增合理的 label。

匯入過程中，Rainbond 將不同的屬性，交由擴充套件後的模型管理，大部分運維操作已經變得很易用了，而另一部分，則交由 Kubernetes 屬性頁面進行管理。

一旦完成匯入，wordpress 和 wp-mysql 兩個應用就可以使用 Rainbond 進行管理了。

• 埠管理

wordpress 在匯入之前依靠 NodePort 型別的 Service 對外暴露，但匯入 Rainbond 管理之後，就可以藉助閘道器對外暴露自己的 80 埠了。需要注意的是，你必須重啟一次 wordpress 服務元件，來讓訪問策略生效。

對於某些業務而言，訪問的入口不支援動態指定，這就需要業務側也做出一些改動，來適應新的訪問入口。對於 Wordpress 而言，需要重新定義常規選項中的站點地址。

• 儲存管理

我部署的這套 wordpress 系統，所有元件的儲存都使用的 hostpath 模式，這種配置雖說簡單，但是並不適用於 Pod 可能發生漂移的大規模 Kubernetes 環境。Rainbond 部署後，會提供易用的共享儲存，這種儲存支援多個 Pod 間共享資料，以及 Pod 跨主機的遷移。原有的 hostpath 儲存，可以重新進行定義。重新定義後的儲存路徑會變為空，所以記得找到新舊不同的路徑，進行一次資料遷移。

實際意義

通過應用模型，讓IT 技術人員可以更多的關心業務本身，而不是底層複雜工具的使用問題。最終的效果是簡化操作成本和理解難度，讓Kubernetes更加容易落地。