如何不編寫 YAML 管理 Kubernetes 應用？
Kubernetes 將自身邊界內的事物都抽象為資源。其中的主要部分，是以 Deployment、StatefulSet 為代表的 workload 工作負載控制器，其他各類資源都圍繞這些主要的資源工作。這些資源合并起來，可以為 IT 技術工作者展現出一個以 workload 為中心的模型。Kubernetes 中所有的資源，都通過聲明式配置文件來編輯描述，一條條的 Yaml 字段定義，給了 IT 技術人員最大的自由度的同時，也對技術人員的能力提出了極高的要求。
通過應用模型簡化Kubernetes管理
當你的團隊已經使用原生的 Kubernetes 一段時間，你多半會發現，并非每個 IT 技術人員都擅長編寫復雜的 Kubernetes 聲明式配置文件（YAML）。特別是對于開發人員他們的主要職責是業務開發，學習和編寫YAML會增加他們的負擔，甚至會抵觸使用。
開源項目Rainbond 是一個 云原生應用管理平臺，它使用 以應用為中心 的設計模式。基于這一設計模式重新抽象出了比 workload 更高層次的應用模型。從使用的體驗上不需要學習和編寫YAML，實現業務應用的全生命周期管理。應用對應一個完整的業務系統，由若干個可以單獨管理的服務組件組成，部署業務組件可以從源代碼和容器鏡像，通過“拖拉拽”的方式編輯服務調用關系。每一個服務組件，可以基于圖形化界面定義使用常見的一些運維特征。在此基礎之上，用戶還可以利用應用模型這一核心概念，做出更多高級操作，如將整個業務系統以應用模板的形式發布出來，業務系統可以基于該模板一鍵安裝/升級。在軟件交付這個領域，這種能力十分有用，無論最終交付環境在線或離線，都可以基于應用模板進行快速交付，甚至個性化交付。
Rainbond 使用的應用模型，讓開發人員關注應用和業務本身，更易于被人所接受。對裁剪后保留下來的運維特征通過圖形界面展示和交互，極大的降低了使用的難度，通過應用模版絕大多數開發者不必編輯復雜聲明式配置文件就可以順暢使用 Kubernetes 了。
將Kubernetes的YAML轉換成應用模型
整個轉化的過程，可以概括為三個步驟：
- 對于開發人員最常用Workload，可以從源碼和容器鏡像向導式的自動生成，或導入已有YAML和運行應用，導入過程自動識別所有可轉化的 Workload 類型資源，包括 Deployment、StatefulSet， Job、CronJob 類型。這些資源會被轉化成應用模型，轉化后會以服務組件的形式運行。
- 導入生成的服務組件后，基本的Workload屬性通過界面就可以查看和編輯，如環境變量、鏡像地址等。轉化過程中會將識別到的高級Workload 屬性添加給服務組件，以Key/Value 或 Yaml 形式查看和管理。
- 非 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 ~]# 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更加容易落地。
