OpenKruise v1.0：云原生应用自动化达到新的高峰
云原生應用自動化管理套件、CNCF Sandbox 項目 – OpenKruise，近期發布了 v1.0 大版本。
OpenKruise [1] ?是針對 Kubernetes 的增強能力套件，聚焦于云原生應用的部署、升級、運維、穩定性防護等領域。所有的功能都通過 CRD 等標準方式擴展，可以適用于 1.16 以上版本的任意 Kubernetes 集群。單條 helm 命令即可完成 Kruise 的一鍵部署，無需更多配置。
總得來看，目前 OpenKruise 提供的能力分為幾個領域：
- 應用工作負載： 面向無狀態、有狀態、daemon 等多種類型應用的高級部署發布策略，例如原地升級、灰度流式發布等。
- Sidecar 容器管理： 支持獨立定義 sidecar 容器，完成動態注入、獨立原地升級、熱升級等功能。
- 增強運維能力： 包括容器原地重啟、鏡像預拉取、容器啟動順序保障等。
- 應用分區管理： 管理應用在多個分區（可用區、不同機型等）上的部署比例、順序、優先級等。
- 應用安全防護： 幫助應用在 Kubernetes 之上獲得更高的安全性保障與可用性防護。
版本解析
在 v1.0 大版本中，OpenKruise 帶來了多種新的特性，同時也對不少已有功能做了增強與優化。
首先要說的是，從 v1.0 開始 OpenKruise 將 CRD/WehhookConfiguration 等資源配置的版本從?v1beta1?升級到?v1 ，因此可以支持 Kubernetes v1.22 及以上版本的集群，但同時也要求 Kubernetes 的版本不能低于 v1.16。
以下對 v1.0 的部分功能做簡要介紹，詳細的 ChangeLog 列表請查看 OpenKruise Github 上的 release 說明以及官網文檔。
支持環境變量原地升級
Author: @FillZpp [2]
OpenKruise 從早期版本開始就支持了 “原地升級” 功能，主要應用于 CloneSet 與 Advanced StatefulSet 兩種工作負載上。簡單來說，原地升級使得應用在升級的過程中，不需要刪除、新建 Pod 對象，而是通過對 Pod 中容器配置的修改來達到升級的目的。
如上圖所示，原地升級過程中只修改了 Pod 中的字段，因此：
然而，OpenKruise 過去只能對 Pod 中 image 字段的更新做原地升級，對于其他字段仍然只能采用與 Deployment 相似的重建升級。一直以來，我們收到很多用戶反饋，希望支持對 env 等更多字段的原地升級 – 由于受到 kube-apiserver 的限制，這是很難做到的。
經過我們的不懈努力，OpenKruise 終于在 v1.0 版本中，支持了通過 Downward API 的方式支持了 env 環境變量的原地升級。例如對以下 CloneSet YAML，用戶將配置定義在 annotation 中并關聯到對應 env 中。后續在修改配置時，只需要更新 annotation value 中的值，Kruise 就會對 Pod 中所有 env 里引用了這個 annotation 的容器觸發原地重建，從而生效這個新的 value 配置。
apiVersion: apps.kruise.io/v1alpha1 kind: CloneSet metadata:... spec:replicas: 1template:metadata:annotations:app-config: "... the real env value ..."spec:containers:- name: appenv:- name: APP_CONFIGvalueFrom:fieldRef:fieldPath: metadata.annotations['app-config']updateStrategy:type: InPlaceIfPossible與此同時，我們在這個版本中也去除了過去對鏡像原地升級的?imageID?限制，即支持相同 imageID 的兩個鏡像替換升級。
具體使用方式請參考文檔 [3] 。
配置跨命名空間分發
?Author: ? @veophi [4]
在對 Secret、ConfigMap 等 namespace-scoped 資源進行跨 namespace 分發及同步的場景中，原生 kubernetes 目前只支持用戶 one-by-one 地進行手動分發與同步，十分地不方便。
典型的案例有：
- 當用戶需要使用 SidecarSet 的 imagePullSecrets 能力時，要先重復地在相關 namespaces 中創建對應的 Secret，并且需要確保這些 Secret 配置的正確性和一致性。
- 當用戶想要采用 ConfigMap 來配置一些通用的環境變量時，往往需要在多個 namespaces 做 ConfigMap 的下發，并且后續的修改往往也要求多 namespaces 之間保持同步。
因此，面對這些需要跨 namespaces 進行資源分發和多次同步的場景，我們期望一種更便捷的分發和同步工具來自動化地去做這件事，為此我們設計并實現了一個新的 CRD — ResourceDistribution。
ResourceDistribution 目前支持 Secret 和 ConfigMap 兩類資源的分發和同步。
apiVersion: apps.kruise.io/v1alpha1 kind: ResourceDistribution metadata:name: sample spec:resource:apiVersion: v1kind: ConfigMapmetadata:name: game-demodata:...targets:namespaceLabelSelector:...# or includedNamespaces, excludedNamespaces如上述 YAML 所示，ResourceDistribution 是一類 cluster-scoped 的 CRD，其主要由?resource?和?targets?兩個字段構成，其中?resource?字段用于描述用戶所要分發的資源，targets?字段用于描述用戶所要分發的目標命名空間。
具體使用方式請參考文檔 [5] 。
容器啟動順序控制
Author: @Concurrensee [6]
對于 Kubernetes 的一個 Pod，其中的多個容器可能存在依賴關系，比如 容器 B 中應用進程的運行依賴于 容器 A 中的應用。因此，多個容器之間存在順序關系的需求：
- 容器 A 先啟動，啟動成功后才可以啟動 容器 B
- 容器 B 先退出，退出完成后才可以停止 容器 A
通常來說 Pod 容器的啟動和退出順序是由 Kubelet 管理的。Kubernetes 曾經有一個 KEP 計劃在 container 中增加一個 type 字段來標識不同類型容器的啟停優先級。但是由于 sig-node 考慮到對現有代碼架構的改動太大，目前這個 KEP 已經被拒絕了。
因此，OpenKruise 在 v1.0 中提供了名為 Container Launch Priority 的功能，用于控制一個 Pod 中多個容器的強制啟動順序：
對于任意一個 Pod 對象，只需要在 annotations 中定義?apps.kruise.io/container-launch-priority: Ordered，則 Kruise 會按照 Pod 中?containers?容器列表的順序來保證其中容器的串行啟動。
如果要自定義?containers?中多個容器的啟動順序，則在容器 env 中添加?KRUISE_CONTAINER_PRIORITY?環境變量，value 值是范圍在?[-2147483647, 2147483647]?的整數。一個容器的 priority 值越大，會保證越先啟動。
具體使用方式請參考文檔 [7] 。
kubectl-kruise 命令行工具
Author: @hantmac [8]
過去 OpenKruise 是通過 kruise-api、client-java 等倉庫提供了 Go、Java 等語言的 Kruise API 定義以及客戶端封裝，可供用戶在自己的應用程序中引入使用。但仍然有不少用戶在測試環境下需要靈活地用命令行操作 workload 資源。
然而原生?kubectl?工具提供的?rollout、set image?等命令只能適用于原生的 workload 類型，如 Deployment、StatefulSet，并不能識別 OpenKruise 中擴展的 workload 類型。
因此，OpenKruise 最新提供了?kubectl-kruise?命令行工具，它是?kubectl?的標準插件，提供了許多適用于 OpenKruise workload 的功能。
# rollout undo cloneset $ kubectl kruise rollout undo cloneset/nginx # rollout status advanced statefulset $ kubectl kruise rollout status statefulsets.apps.kruise.io/sts-demo # set image of a cloneset $ kubectl kruise set image cloneset/nginx busybox=busybox nginx=nginx:1.9.1具體使用方式請參考文檔 [9] 。
其余部分功能改進與優化
CloneSet:
- 通過?scaleStrategy.maxUnavailable?策略支持流式擴容
- Stable revision 判斷邏輯變化，當所有 Pod 版本與 updateRevision 一致時則標記為 currentRevision
WorkloadSpread:
- 支持接管存量 Pod 到匹配的 subset 分組中
- 優化 webhook 在 Pod 注入時的更新與重試邏輯
Advanced DaemonSet:
- 支持對 Daemon Pod 做原地升級
- 引入 progressive annotation 來選擇是否按 partition 限制 Pod 創建
SidecarSet:
- 解決 SidecarSet 過濾屏蔽 inactive Pod
- 在?transferenv?中新增?SourceContainerNameFrom?和?EnvNames?字段，來解決 container name 不一致與大量 env 情況下的冗余問題
PodUnavailableBudget:
- 新增 “跳過保護” 標識
- PodUnavailableBudget controller 關注 workload 工作負載的 replicas 變化
NodeImage:
- 加入?--nodeimage-creation-delay?參數，并默認等待新增 Node ready 一段時間后同步創建 NodeImage
UnitedDeployment:
- 解決?NodeSelectorTerms?為 nil 情況下 Pod?NodeSelectorTerms?長度為 0 的問題
Other optimization:
- kruise-daemon 采用 protobuf 協議操作 Pod 資源
- 暴露 cache resync 為命令行參數，并在 chart 中設置默認值為 0
- 解決 certs 更新時的 http checker 刷新問題
- 去除對 forked controller-tools 的依賴，改為使用原生 controller-tools 配合 markers 注解
社區參與
非常歡迎你通過 Github/Slack/釘釘/微信 等方式加入我們來參與 OpenKruise 開源社區。你是否已經有一些希望與我們社區交流的內容呢？可以在我們的社區雙周會 [10] 上分享你的聲音，或通過以下渠道參與討論：
- 加入社區?Slack channel [11] (English)
- 加入社區釘釘群：搜索群號 23330762 (Chinese)
- 加入社區微信群：添加用戶 openkruise 并讓機器人拉你入群 (Chinese)
參考資料
[1]??OpenKruise:
??https://openkruise.io??
[2]??@FillZpp:
??https://github.com/FillZpp??
[3]??文檔:
/docs/core-concepts/inplace-update
[4]??@veophi:
??https://github.com/veophi??
[5]??文檔:
/docs/user-manuals/resourcedistribution
[6]??@Concurrensee:
??https://github.com/Concurrensee??
[7]??文檔:
/docs/user-manuals/containerlaunchpriority
[8]??@hantmac:
??https://github.com/hantmac??
[9]??文檔:
/docs/cli-tool/kubectl-plugin
[10]??社區雙周會:
??https://shimo.im/docs/gXqmeQOYBehZ4vqo??
[11]??Slack channel:
??https://kubernetes.slack.com/channels/openkruise??
戳??原文??，查看 OpenKruise 項目官方主頁與文檔！
總結
以上是生活随笔為你收集整理的OpenKruise v1.0：云原生应用自动化达到新的高峰的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 云原生 Serverless Datab
- 下一篇： Serverless Kubernete