编者注：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源创计划”，欢迎正在阅读的你也加入，一块儿分享。