Update KUDO proposal based on recent feedback

This commit is contained in:
Tobi Knaup 2019-07-31 11:51:27 -07:00
parent cb455cb417
commit 205a3ecf93
1 changed files with 10 additions and 9 deletions

View File

@ -4,19 +4,19 @@
*Description:*
The Kubernetes Universal Declarative Operator (KUDO) is a highly productive toolkit for writing Operators for Kubernetes. Using KUDO, you can deploy your applications, give your users the tools they need to operate it and understand how it's behaving in their environments.
The Kubernetes Universal Declarative Operator (KUDO) is a highly productive toolkit for writing Operators for Kubernetes, with a focus on distributed data services. Using KUDO, you can deploy your applications, give your users the tools they need to operate it and understand how it's behaving in their environments.
The KUDO creators have years of experience automating distributed data services such as https://kafka.apache.org[Apache Kafka] and https://cassandra.apache.org/[Apache Cassandra] on top of https://mesos.apache.org/[Apache Mesos] using the open source https://github.com/mesosphere/dcos-commons[DC/OS SDK]. KUDO aims to bring the successful patterns and user experience of the DC/OS SDK to Kubernetes.
*KUDO Orchestrates Existing Tooling*
Software like databases weren't built only to run on Kubernetes. They already have a rich set of tooling for deployment and operations, no matter where they are deployed. These tools are written, tested, and maintained by the experts who know this software best.
KUDO encourages you to build operators that take advantage of this work.
Software like databases weren't built only to run on Kubernetes. They already have a rich set of tooling for deployment and operations, no matter where they are deployed. These tools are written, tested, and maintained by the experts who know this software best. KUDO encourages you to build operators that take advantage of this work.
Instead of rewriting all of these tools in Go, KUDO allows you to encapsulate your operations into plans that KUDO executes in the right sequence. As a developer, plans are your route for exposing best practice operations for your software. As a user, run plans like backup and restore in confidence that these plans work and are tested.
*Lifecycle Management for Complex Software*
Software with complicated lifecycles is the kind of software KUDO was built for. In many cases, submitting a bunch of manifests and letting pods crash until other pods have run creates additional complexity in the deployment and maintenance of this software.
Software with complicated lifecycles like distributed data services is the kind of software KUDO was built for. In many cases, submitting a bunch of manifests and letting pods crash until other pods have run creates additional complexity in the deployment and maintenance of this software.
Init Containers go awry, binaries get wrapped in esoteric launch scripts that are hard to debug, and Kubernetes users have to navigate a minefield of misleading data with poor resolution. The solution? Write software that deploys your software and handles this sequencing for you.
@ -33,8 +33,9 @@ KUDO operators are just a series of Custom Resource Definitions and Kubernetes t
*Statement on alignment with CNCF mission:*
KUDO aligns with the CNCF mission of making cloud-native computing ubiquitous by enabling more teams to build Kubernetes operators.
In our conversations with software vendors we found that they are hesitant to use any toolkit that is not managed by a neutral foundation like the CNCF to build Operators, which they see as business-critical. The project creators started with the goal in mind to donate KUDO to a foundation and modeled project governance after other CNCF projects from the start.
It offers a declarative approach for building operators, and users get declarative APIs for managing the lifecycle of KUDO-based workloads, which is the expectation for cloud-native software.
KUDO offers a declarative approach for building operators, and users get declarative APIs for managing the lifecycle of KUDO-based workloads, which is the expectation for cloud-native software. It complements other CNCF projects, for example by providing a way to add Day 2 automation to existing Helm charts (see https://github.com/kudobuilder/kudo/blob/master/keps/0013-external-specs.md[KEP-0013]).
KUDO democratizes patterns for managing the lifecycle of complex distributed workloads that would otherwise be out of reach or many teams.
@ -111,8 +112,8 @@ https://github.com/kudobuilder/kudo/projects/4 (Supported, but being merged into
We currently use numbered releases with the changelog and binaries published to kudobuilder/kudo/releases. The current release process is documented here: https://github.com/kudobuilder/kudo/blob/master/RELEASE.md
*Community Size (as of 6/25):*
*Community Size (as of 7/31):*
* 209 Stars
* 37 Committers
* 248 Stars
* 40 Committers
* 6 full-time engineers