KRM on GDG DevFest 2022台北場

Published in

輕鬆小品-k8s的點滴

12 min readDec 13, 2022

GDG DevFest 2022，是舉辦給開發者社群的實體活動，由於疫情的關係已經停辦了兩年，這次終於回到台大的共同教室舉辦(*撒花*)，這次開了八個Chapters: Cloud, 資安, Machine Learning, Web + DevOps, Mobile, WTM (Woman Techmakers 女性技術發展), GDSC, Workshops，這次筆者參加的是Cloud技術的分享～

詳細的GDG活動分享與志工組分享，可以看程序猿碎念的分享。這次的參與也讓自己過了一次在共同教室101大講堂幫大家上課的癮（*自high*)。

其實每次的分享，對自己都是一個強迫學習，由於Deadline就在那裡，必須之前看懂想分享的資訊，並能結合自己的經驗，將自己學習到的知識，分享給大家。這次由於之前已經在K8S Summit分享過Software Delivery Shield，Skaffold v2也被選走了，一咬牙來分享一個自己之前學了一半，但還沒太精通的KRM (Kubernetes Resource Model)概念，由於KRM有點過於抽象，也找了個有趣的工具(KPT)給大家感受一下。

這次的題目用的是『WYSIWYG：Config as Data for Kubernetes』，大概的分享區分為四個部分：

Config as Challenge?

這個題目算是對最近DevOps的一個反思，雖然我們都知道雲和容器化，都可以加速企業創新。然而在企業分享K8S及雲的這幾年裡，發現大家對於設定，都有著很高的擔憂感：

SWE ( 開發工程師)要學習IaC/K8S網路，甚至需要具備LoadBalancer的知識才能看到自己開發的軟體，有沒有簡易的方式，讓我快速看到我開發的成果？
SRE(維運工程師) 依需求使用/部署許多第三方服務時，這些第三方提供的參數該如何正確的設定？更棘手的是，多種環境部署(e.g. Dev, SIT, Staging, Production) 所用的設定該如何控制？
SE(資安工程師）更擔心會不會有SWE/SRE不小心就部署了不准許的設定(e.g. 忘記加密因而違反ISO 27001等內部資安規範）或是將服務區域部署錯地方(e.g. 把虛擬機開到他國）等。

更麻煩的是，IaC(Infrastructure as Code)跟KRM (Kubernetes Resource Management) 裡的東西好多，該怎麼選擇一個適合的管理機制？

Config as Data的現況

IaC與KRM在目前主流社群裡，仍是兩個不同的流派，IaC以Terraform, Pulumi為首，強調的是將Infrastructure的呼叫以Code的方式記錄起來。而KRM的主導專案有Helm或是Kustomize等，主要偏重於將複雜K8S Workloads或多環境的參數，編寫為獨立的變數檔 (e.g. Kustomize的overwrite yml或是Helm Chart裡的values.yml)。

近年來，KRM這裡有越來越多的專案，延伸到IaC的範疇，試著抽象化Infrastructure成為K8S的CRD，這個嘗試已經廣泛的應用到現行K8S叢集的創建（特別是與IaaS的協作），包含筆者2019年K8S Summit分享的ClusterAPI，Cluster Autoscaler，GCP主推的Kubernetes Config Connector，以及最近一個當紅炸子雞CrossPlane(目前GCP上的MultiCloud API的底層），都是很棒的例子。讓我們嗅到一個IaC+KRM可能統一的味道。

KPT: KRM的資源管理套件

KPT的定位是一個納管多個KRM工具的套件，今年Q3 Release了1.0 Beta。作為管理套件，它的目的是管理套件的組成(包含一個參數改變與確認的機制）以及部署後元件的Live狀態。

管理套件的組成描述，主要通過一組宣告式的YAML語法，主要定義了套件的：開發維運者，來源，與Pipeline:mutators 和 Pipeline:validators，其中Mutators是用來修改套件中YAML裡的參數，而Validators是用來檢查修改的參數是否符合Validator所定義的邊界或是格式等。目前KPT提供許多OOB的Functions供套件使用者呼叫。

apiVersion: kpt.dev/v1
kind: Kptfile
metadata:
  name: gdg-live
upstream:
  type: git
  git:
    repo: https://github.com/shawnho1018/gdg-kpt-blueprint
    directory: /wordpress
    ref: v4
  updateStrategy: resource-merge
upstreamLock:
  type: git
  git:
    repo: https://github.com/shawnho1018/gdg-kpt-blueprint
    directory: /wordpress
    ref: wordpress/v4
    commit: a7912003315cd9a71a1deea3079ce315925643bd
info:
  emails:
    - kpt-team@google.com
  description: This is an example wordpress package with mysql subpackage.
pipeline:
# 通過package-context.yaml設定namespace名稱，並將設定後的YAML檔進行K8S YAML語法檢查。
  mutators:
    - image: gcr.io/kpt-fn/set-namespace:v0.4.1
      configPath: package-context.yaml
  validators:
    - image: gcr.io/kpt-fn/kubeval:v0.3

Demo 1: Mutator/Validator

通過Setter.yaml修改Replicas, Image Tag 名稱, 與環境變數，並通過kubeval的語法檢查。

目前KPT也提供Kubernetes Config Connector(KCC)與CrossPlane的支援。只要在K8S Cluster中部署好對應的KCC or CrossPlane Operator，只要將CRD部署到所需的名稱空間，即可呼叫Operator產生對應的Infrastructure.

在Demo-2的展示中我們預先先部署好KCC的CNRM Operator在cnrm namespace中，之後在Kptfile裡定義使用enable-gcp-services:v0.1函式，這個函式主要是用來啟動專案下的GCP服務。通過這個函式，可以生成KCC YAML檔案，需要產生哪個服務的依據為services.yaml

# Kptfile
apiVersion: kpt.dev/v1
kind: Kptfile
metadata:
  name: gcp-p1
upstream:
  type: git
  git:
    repo: https://github.com/GoogleContainerTools/kpt-functions-catalog
    directory: /examples/enable-gcp-services-simple
    ref: enable-gcp-services/v0.1.0
  updateStrategy: resource-merge
upstreamLock:
  type: git
  git:
    repo: https://github.com/GoogleContainerTools/kpt-functions-catalog
    directory: /examples/enable-gcp-services-simple
    ref: enable-gcp-services/v0.1.0
    commit: 1b6d4ae2e8cd188d475146799530d3da0ac4fe4e
pipeline:
  mutators:
    - image: gcr.io/kpt-fn/apply-setters:v0.2.0
      configPath: setters.yaml
    - image: gcr.io/kpt-fn/enable-gcp-services:v0.1
      configPath: services.yaml

# services.yaml
apiVersion: blueprints.cloud.google.com/v1alpha1
kind: ProjectServiceSet
metadata: #kpt-merge: /proj1-service
  name: shawn-mesh-2022-service #kpt-set: ${projectID}-service
  namespace: cnrm #必須產生在KCC Operator對應的名稱空間中
  annotations:
    config.kubernetes.io/local-config: "true"
    internal.kpt.dev/upstream-identifier: 'blueprints.cloud.google.com|ProjectServiceSet|default|shawn-mesh-2022-service' # kpt-set: blueprints.cloud.google.com|ProjectServiceSet|default|${projectID}-service
spec:
  services:
    - sqladmin.googleapis.com
    - redis.googleapis.com
  projectID: shawn-mesh-2022 # kpt-set: ${projectID}

Demo 2: Mutator/Live Monitor

使用KPT產生CNRM所使用的KCC 的CRD Yaml檔案，再通過kpt live apply將CRD部署到KCC Operator的名稱空間中，啟動對應的GCP服務，也可以通過kpt live destroy關閉對應的GCP服務。

KPT的工作流程：

KPT的想法是通過Git Repository進行發行與修改，發行者寫完後，將套件放上Git Repository稱為BluePrint，這時即可供使用者通過kpt pkg get方式下載使用。當使用者下載時，通過瀏覽Kptfile 可確認套件開發者規劃的Pipeline或是kpt pkg tree 來檢查套件所帶的CRDs檔案。

待修改完使用者所需的參數後，通過執行kpt fn render 即可將參數更新到對應的YAML檔案(e.g. Namespace or Image Tag)，這時就可以通過kpt live apply部署服務了。

Demo-3: 下載WordPress 藍圖並部署到K8S叢集

Kpt fn render取得更新後的CRDs後，除了通過kpt live apply外，還可以通過GitOps的方式套用。在下方的展示裡，我們使用Google提供的Config-Sync的機制，將Render後的YAML直接commit進Git-Ops的Repository，自動Apply到叢集中。

Demo-4: 使用GitOps套用Kpt fn render後的YAML

展望:

KPT目前還是在1.0 beta的版本，根據筆者這次的測試，個人覺得尚不是企業可以直接使用的工具。但值得關注的是，目前KPT已經被納入Open Linux Foundation Nephio的專案底下，作為Telco 5G自動化部署的基本工具之一，

底下是Nephio的基礎架構，如本篇文章所示，未來KPT（中間紅色部分）會用來作為NF K8S Operator(K8s服務）與Cloud K8S Operator（類似Infrastructure)的共同KRM管理工具，筆者誠心希望，通過5G CNF的強勁需求，可以加速KPT工具在2023年的成熟。

KRM on GDG DevFest 2022台北場

Config as Challenge?

Config as Data的現況

KPT: KRM的資源管理套件

KPT的工作流程：

展望:

Written by Shawn Ho