編者注：2018年12月11日，KUDO曾以Maestro爲名發佈，這個開源項目是一種實現Kubernetes Day 2 Operator的無代碼方式。git
01github
什麼是KUDO？數據庫
開源項目KUDO的全稱是：Kubernetes Universal Declarative Operator (Kubernetes通用聲明性控制器)，它爲生產級別Kubernetes Operator的開發提供了一種聲明性方法，能夠覆蓋整個應用程序的生命週期。安全
Operator是一種使用Kubernetes API打包和管理Kubernetes應用程序的方法。構建Operator一般涉及實現自定義資源和控制器，並須要數千行代碼和對Kubernetes的深刻理解。微信
KUDO則爲大衆提供了一個能夠經過聲明性規範 (YAML文件) 配置的通用控制器，來構建任意的工做負載。架構
02app
KUDO的設計初衷框架
自從兩年前引入Operator概念以來，咱們看到許多由系統製造商以及社區成員建立的、用於自動化不一樣分佈式系統項目。然而，雖然許多Operator都處理軟件的初始部署，但他們卻不能實現二進制升級、配置更新、故障修復等Day 2運維任務的自動化。因爲Operator結合了自定義資源和控制器等先進的Kubernetes概念，須要對Kubernetes的專業知識有深刻了解，因此複雜工做負載的生產級Operator一般須要數千行代碼以及數月的開發時間。所以，目前可用的Operator 質量良莠不齊，有些能夠在網上找到的Operators僅僅是腳本，沒法處理分佈式系統中可能發生的複雜故障場景。運維
多年來，Mesosphere一直與合做夥伴們保持密切合做，以實現數據庫、消息隊列、文件系統及其餘有狀態分佈式系統複雜的生命週期自動化。大約三年前，爲了讓更多用戶能夠僅經過聲明式規範的方式構建服務自動化，咱們開始提煉總結DC/OS Commons SDK (https://github.com/mesosphere/dcos-commons)中的框架構建經驗，包括Apache Kafka、Apache Cassandra、Elastic等多項技術的實踐經驗。在SDK以前，建立一個框架須要具有Apache Mesos和分佈式系統操做方面的專業知識，且軟件供應商須要編寫數千行代碼，而DC/OS SDK的主要概念並不依賴於Mesos，因此咱們開始着力於爲Kubernetes建立SDK版本——這就是KUDO誕生的初衷。分佈式
03
KUDO如何優化Operator開發體驗
1. 腳手架 (Scaffolding)
KUDO可以生成許多構建和打包Operator所需的構件，好比Helm charts。沒有KUDO，Operator的建立者就必須學習高級的Kubernetes概念，以及多種不一樣工具和庫的配置格式，纔可以發佈可部署的程序包。而KUDO則能夠由單一的規範生成全部這些構件。
2. 生產級的通用Operator
KUDO包括Universal Operator實施功能——一個在有狀態機器上的通用Operator，幫助建立者解決編寫數千行代碼和進行重複性工做的煩惱。Universal Operator可使由故障引發的複雜狀態變化轉化爲所需的系統狀態。由此，即使是Kubernetes新手，也能輕鬆建立一個生產級的Operator。
3. 內置最佳實踐
經過爲各類軟件建立Operator而積累的最佳實踐將不斷地反饋給KUDO。所以，基於KUDO的Operator能夠經過簡單的最新版本升級來利用這些最佳實踐。
4. 便於測試
KUDO配備的工具使Operator測試變得很是容易。
5. 一致性
使用KUDO構建的Operator具備一致的API端點及常見的打包格式，爲運行多個不一樣Operator的用戶提供一致性體驗。
04
KUDO的架構
KUDO Universal Operator的核心是「Framework」CRD，該CRD是一個聲明性規範，可以描述框架的實施細節，例如部署計劃、所需組件和啓用程序包所需的其餘信息。「計劃」則是Kudo的一個關鍵概念，它容許建立者對系統的任何生命週期事件建模，例如初始部署、配置更新、二進制升級和故障修復。它們在Kubernetes的基礎上提供了一個更高層次的抽象概念，這對於使用運行手冊的人來講很是熟悉，同時初學者也更容易上手。
建立Framework會觸發Operator建立特定程序包的CRD。用戶將建立這些受KUDO監控的CRD，而後根據Framework CRD的規範建立服務。在初始階段，這隻能支持幾個生命週期Hood，但其路線圖則包括實現任意的計劃規範，以及使用定製代碼建立計劃複寫，這將支持管理ZooKeeper或etcd集羣等軟件更復雜的生命週期。
05
KUDO 0.2.0發佈
1. 發佈亮點
Go Templating 和 Sprig
經過使用Sprig做爲模板, KUDO已轉向Go Templating。全部Mustache模板都應被替換爲相應的Go模板，可用關鍵字以下:
{{ .Name }} - Name of the instance
{{ .Namespace }} - Namespace the instance is located in
{{ .FrameworkName }} - Name of the framework
{{ .PlanName }} - Name of the plan being run
{{ .PhaseName }} - Name of the phase being run
{{ .StepName }} - Name of the step being run
{{ .StepNumber }} - Number of the step being run
此外，目前模板中的全部參數都嵌套在{{ .Params }}下。例如，Username參數能夠做爲{{ .Params.Username }}使用。
KUDO在模板中提供了Sprig功能庫，爲框架開發人員提供了普遍的可用功能。爲了安全起見，KUDO禁用了在管理者容器中與環境和文件系統相關的功能。在此版本中，涉及: env, expandenv, base, dir, clean, ext, isAbs。
接下來，咱們將持續優化，並向KEP-9: Operator Toolkit中描述的格式邁進。
基於谷歌雲存儲的KUDO註冊表
KUDO如今使用GCS做爲註冊表，再也不須要.git-credentials，從而使安裝程序包的過程變得更加簡單。咱們將繼續使用KEP-9: Operator Toolkit、KEP-3: CLI和WIP KEP-10來完成這方面的工做，這表明了在KUDO程序包管理器中正在進行的工做。
安裝參數語法更改
KUDO Install CLI如今使用一種新的語法來設置參數。若要設置參數，請使用:kubectl kudo install kafka -p cpus=3，這與Helm等工具更加一致。
Homebrew Tap
KUDO kubectl插件如今可使用Homebrew tap。如要使用它，只需點擊回購和安裝:
$ brew tap kudobuilder/tap
$ brew install kudo-cli
控制器分佈
KUDO控制器的分佈已在文檔中收錄，其中包含了將KUDO安裝到集羣中所需的Kubernetes清單。您能夠在入門指南(https://github.com/kudobuilder/kudo/blob/master/docs/getting-started.md)中找到更多細節。同時，咱們正在KUDO網站上整合這些文檔，併爲KUDO準備了「生產就緒」的安裝說明。
2. 變動日誌
此外，團隊還解決了許多與bug和性能問題相關的問題。查看完整的變動日誌，以及此版本的貢獻者列表，請訪問Github發佈頁面: https://github.com/kudobuilder/kudo/releases/tag/v0.2.0
06
下一步計劃
KUDO v0.2.0已經發布，團隊將開始規劃並着手執行v0.3.0。v0.3.0的重點將是穩定框架開發人員的打包格式和框架擴展，以便爲KUDO的Helm Charts和CNAB bundle等格式提供排序邏輯。
今天就開始使用KUDO吧！歡迎點擊閱讀原文安裝體驗。KUDO社區(https://kudo.dev/docs/community/)也已經準備好接收反饋讓KUDO變得更好!
同時也歡迎您在6月24-26日KubeCon期間（上海世博中心），來Mesosphere展臺（S12），咱們的技術專家將在現場展現Live Demo—「如何經過KUDO優化Kubernetes Operator開發體驗」。
本文分享自微信公衆號 - D2iQ（d2iq_apac）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。