Kubernetes 將自身邊界內(nèi)的事物都抽象為資源。其中的主要部分，是以 Deployment、StatefulSet 為代表的 workload 工作負(fù)載控制器，其他各類資源都圍繞這些主要的資源工作。這些資源合并起來，可以為 IT 技術(shù)工作者展現(xiàn)出一個以 workload 為中心的模型。Kubernetes 中所有的資源，都通過聲明式配置文件來編輯描述，一條條的 Yaml 字段定義，給了 IT 技術(shù)人員最大的自由度的同時，也對技術(shù)人員的能力提出了極高的要求。

通過應(yīng)用模型簡化Kubernetes管理

當(dāng)你的團(tuán)隊(duì)已經(jīng)使用原生的 Kubernetes 一段時間，你多半會發(fā)現(xiàn)，并非每個 IT 技術(shù)人員都擅長編寫復(fù)雜的 Kubernetes 聲明式配置文件（YAML）。特別是對于開發(fā)人員他們的主要職責(zé)是業(yè)務(wù)開發(fā)，學(xué)習(xí)和編寫YAML會增加他們的負(fù)擔(dān)，甚至?xí)钟|使用。

開源項(xiàng)目Rainbond 是一個 云原生應(yīng)用管理平臺，它使用 以應(yīng)用為中心 的設(shè)計(jì)模式?；谶@一設(shè)計(jì)模式重新抽象出了比 workload 更高層次的應(yīng)用模型。從使用的體驗(yàn)上不需要學(xué)習(xí)和編寫YAML，實(shí)現(xiàn)業(yè)務(wù)應(yīng)用的全生命周期管理。應(yīng)用對應(yīng)一個完整的業(yè)務(wù)系統(tǒng)，由若干個可以單獨(dú)管理的服務(wù)組件組成，部署業(yè)務(wù)組件可以從源代碼和容器鏡像，通過“拖拉拽”的方式編輯服務(wù)調(diào)用關(guān)系。每一個服務(wù)組件，可以基于圖形化界面定義使用常見的一些運(yùn)維特征。在此基礎(chǔ)之上，用戶還可以利用應(yīng)用模型這一核心概念，做出更多高級操作，如將整個業(yè)務(wù)系統(tǒng)以應(yīng)用模板的形式發(fā)布出來，業(yè)務(wù)系統(tǒng)可以基于該模板一鍵安裝/升級。在軟件交付這個領(lǐng)域，這種能力十分有用，無論最終交付環(huán)境在線或離線，都可以基于應(yīng)用模板進(jìn)行快速交付，甚至個性化交付。

Rainbond 使用的應(yīng)用模型，讓開發(fā)人員關(guān)注應(yīng)用和業(yè)務(wù)本身，更易于被人所接受。對裁剪后保留下來的運(yùn)維特征通過圖形界面展示和交互，極大的降低了使用的難度，通過應(yīng)用模版絕大多數(shù)開發(fā)者不必編輯復(fù)雜聲明式配置文件就可以順暢使用 Kubernetes 了。

將Kubernetes的YAML轉(zhuǎn)換成應(yīng)用模型

整個轉(zhuǎn)化的過程，可以概括為三個步驟：

1. 對于開發(fā)人員最常用Workload，可以從源碼和容器鏡像向?qū)降淖詣由?，或?qū)胍延衁AML和運(yùn)行應(yīng)用，導(dǎo)入過程自動識別所有可轉(zhuǎn)化的 Workload 類型資源，包括 Deployment、StatefulSet， Job、CronJob 類型。這些資源會被轉(zhuǎn)化成應(yīng)用模型，轉(zhuǎn)化后會以服務(wù)組件的形式運(yùn)行。
2. 導(dǎo)入生成的服務(wù)組件后，基本的Workload屬性通過界面就可以查看和編輯，如環(huán)境變量、鏡像地址等。轉(zhuǎn)化過程中會將識別到的高級Workload 屬性添加給服務(wù)組件，以Key/Value 或 Yaml 形式查看和管理。
3. 非 Workload 的資源類型，如 Secret、ServiceAccount、Role 等資源，會被分類識別和加載到應(yīng)用界面的k8s資源 頁面中，供操作人員以交互體驗(yàn)方式進(jìn)行編輯。

可被納管和轉(zhuǎn)化的 高級Workload 屬性包括：

值得注意的是，擴(kuò)展后的 RAM 模型，依然能夠發(fā)布為應(yīng)用模板，供后續(xù)一鍵安裝/升級/交付整套業(yè)務(wù)系統(tǒng)之用。

導(dǎo)入已有Kubernetes應(yīng)用的測試和實(shí)踐

以下測試是基于Rainbond v5.8進(jìn)行的，為了測試 Kubernetes 已有應(yīng)用導(dǎo)入，我計(jì)劃使用已經(jīng)在 wp 命名空間中部署完成的 Wordpress 建站系統(tǒng)來進(jìn)行一次導(dǎo)入測試。這套系統(tǒng)由以下資源組成：

[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 ，在集群處選擇導(dǎo)入，在這個頁面中，可以選擇要導(dǎo)入資源的命名空間 ??wp??。平臺會根據(jù) label 來對資源進(jìn)行分組：

Rainbond 根據(jù)資源定義的 label 來劃分應(yīng)用，如符合 app.kubernetes.io/name:wp-mysql 或  app:wordpress 的資源，會分布到圖中兩個不同的應(yīng)用中去，而不具備上述 label 的資源，則會統(tǒng)一劃分到一個未分組的應(yīng)用中去。應(yīng)用的劃分非常關(guān)鍵，因?yàn)閼?yīng)用模型的高級應(yīng)用是針對一個應(yīng)用整體而言的，所以導(dǎo)入之前一定要仔細(xì)規(guī)劃，添加合理的 label。

導(dǎo)入過程中，Rainbond 將不同的屬性，交由擴(kuò)展后的模型管理，大部分運(yùn)維操作已經(jīng)變得很易用了，而另一部分，則交由 Kubernetes 屬性頁面進(jìn)行管理。

一旦完成導(dǎo)入，wordpress 和 wp-mysql 兩個應(yīng)用就可以使用 Rainbond 進(jìn)行管理了。

• 端口管理

wordpress 在導(dǎo)入之前依靠 NodePort 類型的 Service 對外暴露，但導(dǎo)入 Rainbond 管理之后，就可以借助網(wǎng)關(guān)對外暴露自己的 80 端口了。需要注意的是，你必須重啟一次 wordpress 服務(wù)組件，來讓訪問策略生效。

對于某些業(yè)務(wù)而言，訪問的入口不支持動態(tài)指定，這就需要業(yè)務(wù)側(cè)也做出一些改動，來適應(yīng)新的訪問入口。對于 Wordpress 而言，需要重新定義常規(guī)選項(xiàng)中的站點(diǎn)地址。

• 存儲管理

我部署的這套 wordpress 系統(tǒng)，所有組件的存儲都使用的 hostpath 模式，這種配置雖說簡單，但是并不適用于 Pod 可能發(fā)生漂移的大規(guī)模 Kubernetes 環(huán)境。Rainbond 部署后，會提供易用的共享存儲，這種存儲支持多個 Pod 間共享數(shù)據(jù)，以及 Pod 跨主機(jī)的遷移。原有的 hostpath 存儲，可以重新進(jìn)行定義。重新定義后的存儲路徑會變?yōu)榭?，所以記得找到新舊不同的路徑，進(jìn)行一次數(shù)據(jù)遷移。

實(shí)際意義

通過應(yīng)用模型，讓IT 技術(shù)人員可以更多的關(guān)心業(yè)務(wù)本身，而不是底層復(fù)雜工具的使用問題。最終的效果是簡化操作成本和理解難度，讓Kubernetes更加容易落地。