(Tracking issue for GSoC proposal)

Now that we're making good progress on the various pieces of machinery and integrations for cluster-addons, it's feasible to start a real effort to create addon operators for the most popular and most interesting cluster addons. Good candidates would be the addons in the (deprecated) cluster directory of k/k, the packaged addons in kops and the other addons in kops. Or your favorite addons!

Working through packaging some of these has a lot of intrinsic value, but we also hope to discover areas where there are problems with the tooling and/or with the approach. Hopefully that will seed further interesting mini-projects which can ideally be solved in collaboration with the community, ranging from docs fixes to deeper technical fixes in the machinery.

Some likely areas of investigation:

• How should we package and distribute the base yaml files - e.g. the manifest bundle proposal
• Can we streamline the process further for simple / generic addons? Do they need their own controller?
• Can we address the lack of granularity of RBAC?
• What is the best UX for consuming addons in cluster management tooling?
• What information do we need on the cluster? (e.g. addon discovery )

The addons you build will likely end up being used on every kubernetes cluster! kubeadm and kops are actively working on supporting these operators, and Redhat is also contributing with their background from the Operator SDK / CoreOS / OpenShift.

Proposed mentors: @justinsb and @stealthybox