[[442732]]

一、背景

在云原生應(yīng)用發(fā)布平臺KubeNest中，trait表示跟應(yīng)用相關(guān)的運維動作，如DNS trait用于解決在不同環(huán)境中修改應(yīng)用主workload的DNS配置的運維問題，像DNS trait這樣的trait在KubeNest中已經(jīng)有10多款，且隨著業(yè)務(wù)需求增加而不斷增多。在原有KubeNest技術(shù)中，每一個trait所需的運維邏輯都是通過Operator實現(xiàn)的，隨著trait的不斷增加，在trait開發(fā)和運維上的存在一些問題：

• 不必要重建：在一次應(yīng)用發(fā)布過程中可能涉及多個trait，這些trait由Operator實現(xiàn)都去修改workload，每次修改都會造成pod重建，實際生產(chǎn)過程中，pod重建應(yīng)該盡量避免
• 開發(fā)成本高：新開發(fā)一個trait需要通過新建一個operator應(yīng)用來實現(xiàn)，雖然可以利用kubebuidler開發(fā)框架簡化開發(fā)，但是仍然需要幾天才能完成，且需要開發(fā)者了解Operaotr的開發(fā)機制，對于開發(fā)者有一定語言能力要求
• 運維成本高：trait數(shù)量過多，一旦涉及到公共邏輯代碼修改(如status增加字段)時，需修改n個trait工程，同時需要升級m個集群，帶來的維護成本將是o(n^2)的
• 資源浪費：每個trait是一個單獨的應(yīng)用，而應(yīng)用部署時最低配置都是1核1G且多副本，然而內(nèi)部執(zhí)行的是簡單轉(zhuǎn)換邏輯僅用100M左右，因此這些trait實際上帶來大量資源浪費
• 代碼不規(guī)范：在trait共建方面，KubeNest僅規(guī)定了輸入輸出標(biāo)準，用戶可定制化trait開發(fā)，這也很容易因為代碼不規(guī)范造成bug
• 不一致問題：面對相同的輸入，在Operator代碼邏輯不當(dāng)可能會帶來輸出數(shù)據(jù)順序不同，而該不一致問題很容易導(dǎo)致pod重建，如toleration順序變化會導(dǎo)致pod重建，而這是無效的重建

為了解決這些問題，我們不僅要規(guī)范trait的輸入輸出，更應(yīng)進一步優(yōu)化trait開發(fā)。

二、舊的架構(gòu)

在KubeOne，trait是不會直接操作workload，這些trait中90%的trait都是patch類型trait，而且大部分trait的邏輯僅是簡單的邏輯轉(zhuǎn)換，下面介紹patch類trait的舊的實現(xiàn)架構(gòu)。

1.Trait Operator化

patch類trait具體的架構(gòu)如下：

如上圖所示，trait Operator是接受trait CR進行運維邏輯處理后將運維動作以YAML碎片的形式直接patch到workload上，其中trait CR包括兩部分數(shù)據(jù)：

應(yīng)用數(shù)據(jù)：應(yīng)用相關(guān)的數(shù)據(jù)，用戶無需關(guān)心但在Operator邏輯處理所需要的，存在metadata的annatation數(shù)據(jù)中，如workload的apiVersion和kind，在apply時需要。

用戶數(shù)據(jù)：屏蔽k8s白屏化展示用戶的數(shù)據(jù)，在trait CR的spec數(shù)據(jù)中。

下面以toleration trait進行說明：

• toleration trait CR (用戶選擇底層資源)

apiVersion: apps.kubeone.alibaba-inc.com/v1 
kind: TolerationInjector 
metadata: 
  annotations: 
    kubeone.ali/workload-api-version: apps.kruise.io/v1alpha1 # 應(yīng)用數(shù)據(jù) 
    kubeone.ali/workload-kind: StatefulSet # 應(yīng)用數(shù)據(jù) 
    ... 
#用戶數(shù)據(jù) 
spec:  
  parameters: 
    sigma.ali/is-ecs: "true" 
    sigma.ali/resource-pool: "example" 

該CR表示用戶希望將pod布置在打上污點標(biāo)sigma.ali/is-ecs: "true"和sigma.ali/resource-pool: "example"的node上。

• toleration trait產(chǎn)生的YAML片段

toleration trait根據(jù)trait CR中用戶輸入轉(zhuǎn)化成YAML片段，然后將該YAML片段直接patch到workload上，完成該運維操作。

# YAML片段 
apiVersion: apps.kruise.io/v1alpha1 
kind: StatefulSet 
metadata: 
  name: sts-example 
  namespace: ns-example 
spec: 
  template: 
    spec: 
      tolerations: 
        - effect: NoSchedule 
          key: sigma.ali/resource-pool 
          operator: Equal 
          value: example 
        - effect: NoSchedule 
          key: sigma.ali/is-ecs 
          operator: Equal 
          value: 'true' 

2.風(fēng)險點

• 順序?qū)е轮亟?/li>

在原生的statefulset和Open kruise statefulset中，YAML內(nèi)容的順序不同也會導(dǎo)致重啟。因此，在舊的架構(gòu)中，trait除了要關(guān)注輸入?yún)?shù)的值，還需關(guān)注參數(shù)的順序問題。當(dāng)參數(shù)順序不同時，trait產(chǎn)生的YAML片段順序也會不同，當(dāng)patch到workload上時，就會引發(fā)workload重啟，從而可能帶來pod重建的故障風(fēng)險。

• 多次apply導(dǎo)致重建

一次發(fā)布過程中可能有多個trait施加運維操作，此時會有多次apply workload而導(dǎo)致pod多次重建。從安全生產(chǎn)角度考慮，用戶希望pod重建次數(shù)越少越好。

三、trait配置化開發(fā)框架

從前面的架構(gòu)中，我們可以看出trait operator其實就是一個converter，將用戶數(shù)據(jù)和應(yīng)用數(shù)據(jù)映射成一個YAML片段，然后patch到workload。原有的convert邏輯用operator來實現(xiàn)，低效且浪費資源?，F(xiàn)采用一種基于配置的convert方案，完成trait邏輯開發(fā)。

1.Trait開發(fā)框架

從上圖可以框架分為兩部分：

Trait convert：trait實現(xiàn)借助于Universal Operator通過數(shù)據(jù)+配置模版=YAML片段的方式生成YAML Fragment，該YAML Fragment會通過ConfigMap存儲。

Apply：會聚合一次發(fā)布過程中產(chǎn)生的所有YAML Fragment，然后做一次patch到應(yīng)用workload，從而避免了多次重建。

下面重點介紹下配置化的“Trait Convert”的設(shè)計：

• trait CR：用戶提交的運維動作，其中包括應(yīng)用數(shù)據(jù)(存在metadata)和用戶數(shù)據(jù)(存在spec)，可以參考toleration trait CR的示例
• trait definition：去operator，將運維邏輯配置化，本質(zhì)是一個YAML
  • name：該條數(shù)據(jù)的標(biāo)示，在template中，通過name來渲染數(shù)據(jù)
  • keyRef：數(shù)據(jù)來源，值為json path的形式，會根據(jù)keyRef從spec中讀取數(shù)據(jù)
  • default：默認值，如果從spec中找不到數(shù)據(jù)則用默認值
  • required：表明此屬性是否必須
  • description：對該屬性的描述
  • params：在模版中定義了該運維邏輯所需要的用戶數(shù)據(jù)和每條用戶數(shù)據(jù)的基本屬性，每個數(shù)據(jù)屬性有name、default、keyRef、description、required
  • tasks：對于配置化的切面拓展，90%的trait是可以直接轉(zhuǎn)換的，對于不能轉(zhuǎn)換需要添加復(fù)雜邏輯的，trait開發(fā)者可以通過tasks來自定義，task會在生成YAML片段前執(zhí)行，目前支持的task類型有shell、job、http
  • template：以go template為基礎(chǔ)的trait模版，結(jié)合數(shù)據(jù)render成最終的YAML片段
• Universal Trait Controller：核心的轉(zhuǎn)換控制器，結(jié)合trait CR和trait definiton生成YAML片段

2.流程介紹

Universal Trait Controller會結(jié)合trait CR和trait definition生成YAML片段，具體流程如下：

• 用戶數(shù)據(jù)處理(Merge)。trait CR中有用戶數(shù)據(jù)(user data)和應(yīng)用數(shù)據(jù)(app data)，params中規(guī)定了參數(shù)要求，merge過程將用戶數(shù)據(jù)和params結(jié)合輸出，記為merged data
• 定制化邏輯處理(TaskRun)。tasks是配置化方案的拓展，是用戶自定義的邏輯，包括多種shell、http、job、func等多種方式。此過程會將merged data和app data作為task的輸入?yún)?shù)，順序執(zhí)行多個task，tasks執(zhí)行完會產(chǎn)生新的輸出數(shù)據(jù)，記為output data
• 數(shù)據(jù)渲染(Render)。app data、merged data和output data作為終態(tài)數(shù)據(jù)，將這些數(shù)據(jù)與template通過go template技術(shù)渲染得到Y(jié)AML片段，YAML暫存在Fragment(configMap)中

重點介紹下YAML片段會用到的應(yīng)用數(shù)據(jù)，從安全的角度考慮，平臺提供給trait開發(fā)者的應(yīng)用數(shù)據(jù)做出了限制，目前僅支持以下參數(shù)：

• OrderId：每次發(fā)布的orderId
• AppName：應(yīng)用name
• WorkloadApiVersion：workload的apiVersion
• WorkloadKind：workload的Kind
• Namespace：應(yīng)用的namespace
• CoreNamespace：kubeNest的namespace，值為ark-system
• Replicas：副本數(shù)

3.示例

apiVersion: core.oam.dev/v1alpha1 
kind: TraitDefinition 
metadata: 
  name: etcd-secret-injector 
  namespace: ns-example 
spec: 
  ... 
  params: 
    - name: END_POINT 
      type: "string" 
      description: "this is a description" 
      default: "https://127.0.0.1" 
      required: false 
  tasks: 
    - name: etcd-http 
      kind: http # shell / job / http / func 
      spec: 
        script: '{{.Params.END_POINT}}/etcd' 
        outputs: 
          - name: TOKEN 
            default: "default token" 
          - name: KEY 
            default: "default key" 
  template: | 
    apiVersion: v1 
    kind: secret 
    metadata: 
      name: {{ .AppName }} 
      namespace: {{ .Namespace }} 
    data: 
      token: {{ .Outputs.TOKEN | b64dec }} 
      key: {{ .Outputs.KEY | b64dec}} 

從上面可以看出，etcd-secret-injector的作用是接受用戶輸入etcd的endpoint，然后轉(zhuǎn)換生成secret密鑰。

四、方案對比

資源配置化開發(fā)去Operator，提供了通用trait的開發(fā)輸入輸出標(biāo)準化管理，開發(fā)者僅需配置YAML，極大縮短了開發(fā)周期，同時將trait 應(yīng)用收斂，降低運維成本和資源消耗，同時避免了多次重建保障了生產(chǎn)的穩(wěn)定性。

五、總結(jié)

KubeNest作為有狀態(tài)應(yīng)用的部署運維平臺，目標(biāo)是“一鍵部署，隨處運行”，能夠極大的幫助用戶提高部署運維效率。trait配置化開發(fā)方案，現(xiàn)已上線KubeNest，經(jīng)過雙十一的驗證，有效地保障了KubeNest上應(yīng)用的穩(wěn)定性。最后總結(jié)下trait配置化開發(fā)優(yōu)點：

• 降本提效：該方案去operator應(yīng)用能夠有效的收斂資源，同時YAML配置化開發(fā)大大的提高了開發(fā)效率和降低了運維(部署、升級)成本;
• 數(shù)據(jù)一致性：模版化保證了數(shù)據(jù)是面向終態(tài)的，使得開發(fā)無需關(guān)注數(shù)據(jù)順序，保障數(shù)據(jù)一致性，消除亂序帶來重啟的風(fēng)險;
• 促進開源：該方案目前已經(jīng)經(jīng)過生產(chǎn)級的驗證，得到很好的反響，并輸出到KubeVela中，使得用戶自定義開發(fā)trait更為簡單，促進KubeVela開源生態(tài)的建設(shè)。

【本文為51CTO專欄作者“阿里巴巴官方技術(shù)”原創(chuàng)稿件，轉(zhuǎn)載請聯(lián)系原作者】

戳這里，看該作者更多好文