Project: KUDO (App Definition and Development / Application Definition & Image Build)
File: 0006-stable-kafka-example.md

kep-number: 6 title: Stable Kafka Example short-description: Description for a full Kafka Operator authors: "@guenter" owners: TBD "@guenter" editor: TBD creation-date: 2019-03-07 status: provisional * * * * * * * * * * * * Created by In order to get KUDO ready for production it's useful to pick a specific workload, make it stable, and drive the KUDO roadmap from its requirements. Apache Kafka is a good candidate for the following reasons: it's one of the most popular stateful distributed systems its operator tasks are similar to many other stateful systems an example already exists in the KUDO repository A team-sponsored production ready operator using KUDO helps with prioritizing features needed to achieve this goal. Define criteria for what is considered a stable KUDO operator Identify features required for a stable Kafka and ZooKeeper operator, create KEPs for them Create a stable Kafka operator Create a stable ZooKeeper operator Any new KUDO features will not be covered by this KEP As a Kafka administrator I want to deploy a Kafka cluster with a single command so I can get started quickly. As a Kafka administrator I want to deploy Kafka clusters of different sizes so I can size my cluster to the application. As a Kafka administrator I want to deploy multiple Kafka clusters on the same Kubernetes cluster so that I can use my resources efficiently. As a Kafka administrator I want to deploy Kafka with a dedicated ZooKeeper, so that I can minimize the impact of ZooKeeper downtime to a single Kafka cluster and not learn how to manage it. As a Kafka administrator I want to have an indication of when my cluster is ready so that know when to start using it. As a Kafka administrator I want to have an indication of cluster health so that know when it is degraded. As a Kafka administrator I want to change the resources used by Kafka brokers (CPU, memory) with minimal disruption to clients so I can scale my cluster vertically when the workload increases. As a Kafka administrator I want to change the number of Kafka brokers in a cluster with minimal disruption to clients so I can scale my cluster horizontally when the workload increases. As a Kafka administrator I want to deploy configuration changes to the cluster with minimal disruption to clients so I can make changes without creating a new cluster. When a Pod corresponding to Kafka Broker is restarted (because of a Kubelet failure, for example), I want a task to run to verify the health of the Broker and to perform a maintenance if needed As a Kafka administrator I want to upgrade to a new Kafka version with minimal disruption to clients so I can deploy bug fixes and enable new features. As a Kafka administrator I want to optionally deploy Kafka with TLS enabled so that I can secure it. As a Kafka administrator I want to optionally deploy Kafka with Kerberos enabled so that I can secure it. As a Kafka administrator I want to use a secrets store for secure storage and distribution of the credentials for Kafka. As a Kafka administrator I want to have easy access to all relevant logs so I can easily debug problems. As a Kafka administrator I want to have easy access to Kafka's JMX metrics so I can easily debug problems.