WG-Creation-Request: WG etcd-operator
Benjamin Wang
Hello Kube community,
We'd like to propose a new working group, WG etcd-operator. It's dedicated to enabling automatic and efficient operation of etcd clusters in Kubernetes using an etcd-operator. The working group will discuss the requirement and use cases of such an etcd-operator. It will also try to create a roadmap to develop such an etcd-operator.
Note: the etcd clusters, to be managed by the etcd-operator, are to support applications instead of Kubernetes itself.
Please also see the draft charter for the working group.
Answers to the workgroup governance questions:
> What is the exact problem this group is trying to solve?
Enable automatic and efficient operation of etcd clusters in Kubernetes using an official etcd-operator, so as to minimize human intervention as much as possible.
To do this, we will
Create a survey (actually already did, see here) to collect requirements and use cases to better understand what users care about the most.
Prioritize the tasks based on the feedback and create a roadmap.
Bootstrap a project "etcd-operator" owned by both SIG etcd which resides in the etcd-io or kubernetes-sig Github orgs.
Survey existing etcd operator projects to see if any of them can supply code or a foundation for the new operator.
Discuss and design the core reconciliation workflow, and potentially provide a proof of concept.
> What is the artifact that this group will deliver, and to whom?
Survey results which describe the users requirements and use cases.
Roadmap for the project etcd-operator.
Core reconciliation workflow and PoC.
Evaluation results on existing etcd-operators, and decision on how to reference these existing projects.
A new repository "etcd-operator" owned by SIG etcd, and it should have implemented the very basic functionalities below,
Creation of a new etcd cluster with one or multiple members
Scale out and in the etcd cluster
Upgrading patch versions or one minor version
> How does the group know when the problem solving process is completed, and it is time for the Working Group to dissolve?
When all the deliverables mentioned above are done and there is no additional coordination needed, then we will disband this working group and continue to track the development of the project under SIG etcd.
> Who are all of the stakeholder SIGs involved in this problem this group is trying to solve?
SIG etcd
SIG Cluster Lifecycle
> What are the meeting mechanics (frequency, duration, roles)?
One hour meetings every other week, with a moderator.
> Does the goal of the Working Group represent the needs of the project as a whole, or is it focused on the interests of a narrow set of contributors or companies?
As discussed in the KubeCon Paris 2024, a broad set of users have expressed interested in this effort
> Who will chair the group, and ensure it continues to meet these requirements?
Benjamin Wang
Ciprian Hacman
James Blair
Josh Berkus
> Is diversity well-represented in the Working Group?
We welcome and encourage contributors of all backgrounds and geographies to participate.
As discussed in the KubeCon Paris 2024 and also in etcd/issues/17668, lots of projects require to operate etcd clusters in Kubernetes easily. Some of them (see below) have already expressed interested in an official etcd-operator
There are already several existing etcd-operators available, but they are either out of maintenance or not widely adopted within the community. We will try to reach out to the authors/maintainers of the existing etcd-operators, and invite them to participate.
Thank you!