Skip to content

Commit

Permalink
Merge pull request #3835 from camilamacedo86/doc-roadmap
Browse files Browse the repository at this point in the history
📖 Add Roadmaps to bring visibility and allow better collaboration
  • Loading branch information
k8s-ci-robot authored Apr 23, 2024
2 parents 1bdc798 + 54ba629 commit 1ccc46b
Show file tree
Hide file tree
Showing 2 changed files with 229 additions and 0 deletions.
83 changes: 83 additions & 0 deletions roadmap/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,83 @@
# Kubebuilder Roadmaps

**Welcome to the Kubebuilder Roadmaps directory!**

This space is dedicated to housing the strategic roadmaps for the
Kubebuilder project, organized by year. Each document within this repository
outlines the key initiatives, objectives, and goals for Kubebuilder, reflecting our
commitment to enhancing the development experience within the Kubernetes ecosystem.

Below, you will find links to the roadmap document for each year. These documents provide insights into the
specific objectives set for the project during that time, the motivation behind each goal, and the progress
made towards achieving them:

- [Roadmap 2024](roadmap_2024.md)

## :point_right: New plugins/RFEs to provide integrations within other Projects

As Kubebuilder evolves, we prioritize a focused project scope and minimal reliance on third-party dependencies,
concentrating on features that bring the most value to our community.

While recognizing the need for flexibility, we opt not to directly support third-party project integrations.
Instead, we've enhanced Kubebuilder as a library, enabling any project to create compatible plugins.
This approach delegates maintenance to those with the deepest understanding of their projects, fostering higher
quality and community contributions.

We're here to support you in developing your own Kubebuilder plugins.
For guidance on [Creating Your own plugins](https://kubebuilder.io/plugins/creating-plugins).

This strategy empowers our users and contributors to innovate,
keeping Kubebuilder streamlined and focused on essential Kubernetes development functionalities.

**Therefore, our primary objective remains to offer a CLI tool that assists users in developing
solutions for deployment and distribution on Kubernetes clusters using Golang.
We aim to simplify the complexities involved and speed up the development process,
thereby lowering the learning curve.**

## :steam_locomotive: Contributing

Your input and contributions are what make Kubebuilder a continually
evolving and improving project. We encourage the community to participate in discussions,
provide feedback on the roadmaps, and contribute to the development efforts.

If you have suggestions for future objectives or want to get involved
in current initiatives, please refer to our [contributing guidelines](./../CONTRIBUTING.md)
or reach out to the project maintainers. Please, feel free either
to raise new issues and/or Pull Requests against this repository with your
suggestions.

## :loudspeaker: Stay Tuned

For the latest updates, discussions, and contributions to the Kubebuilder project,
please join our community channels and forums. Your involvement is crucial for the
sustained growth and success of Kubebuilder.

**:tada: Thank you for being a part of the Kubebuilder journey.**

Together, we are building the future of Kubernetes development.

## Template for roadmap items

```markdown
### [Goal Title]

**Status:** [Status Emoji] [Short Status Update]

**Objective:** [Brief description of the objective]

**Context:** [Optional - Any relevant background or broader context]

**Motivations:** [Optional - If applicable]
- [Key motivation 1]
- [Key motivation 2]

**Proposed Solutions:** [Optional - If applicable]
- [Solution 1]
- [Solution 2]
- [More as needed]

**References:** [Optional - Links to discussions, PRs, issues, etc.]
- [Reference 1 with URL]
- [Reference 2 with URL]
- [More as needed]
```
146 changes: 146 additions & 0 deletions roadmap/roadmap_2024.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,146 @@
# Kubebuilder Project Roadmap 2024

### **(Major Release for Kubebuilder CLI 4.x)** Removing Deprecated Plugins for Enhanced Maintainability and User Experience

**Status:** :construction: Work in Progress

**Objective:** To remove all deprecated plugins from Kubebuilder to improve project maintainability and
enhance user experience. This initiative also includes updating the project documentation to provide clear
and concise information, eliminating any confusion for users. **More Info:** [GitHub Discussion #3622](https://github.com/kubernetes-sigs/kubebuilder/discussions/3622)

**Motivation:** By focusing on removing deprecated plugins—specifically, versions or kinds that can no
longer be supported—we aim to streamline the development process and ensure a higher quality user experience.
Clear and updated documentation will further assist in making development workflows more efficient and less prone to errors.

---
### Proposal Pending: Seeking Feedbacks for kube-rbac-proxy's Role in Default Scaffold

**Status:** :construction: Work in Progress. See: https://github.com/kubernetes-sigs/kubebuilder/pull/3860

**Objective:** Evaluate potential modifications or the exclusion of [kube-rbac-proxy](https://github.com/brancz/kube-rbac-proxy)
from the default Kubebuilder scaffold in response to deprecations and evolving user requirements.

**Context:** [kube-rbac-proxy](https://github.com/brancz/kube-rbac-proxy) , a key component for securing Kubebuilder-generated projects,
faces significant deprecations that impact automatic certificate generation.
For more insights into these challenges, see [Issue #3524](https://github.com/kubernetes-sigs/kubebuilder/issues/3524).

This situation necessitates a reevaluation of its inclusion and potentially prompts users to
adopt alternatives like cert-manager by default. Additionally, the requirement to manually rebuild
[kube-rbac-proxy images—due](https://github.com/kubernetes-sigs/kubebuilder/blob/master/RELEASE.md#to-build-the-kube-rbac-proxy-images)
to its external status from Kubernetes-SIG—places a considerable maintenance
burden on Kubebuilder maintainers.

**Motivations:**
- Address kube-rbac-proxy breaking changes/deprecations.
- For further information: [Issue #3524 - kube-rbac-proxy warn about deprecation and future breaking changes](https://github.com/kubernetes-sigs/kubebuilder/issues/3524)
- Feedback from the community has highlighted a preference for cert-manager's default integration, aiming security with Prometheus and metrics.
- More info: [GitHub Issue #3524 - Improve scaffolding of ServiceMonitor](https://github.com/kubernetes-sigs/kubebuilder/issues/3657)
- Desire for kube-rbac-proxy to be optional, citing its prescriptive nature.
- See: [Issue #3482 - The kube-rbac-proxy is too opinionated to be opt-out.](https://github.com/kubernetes-sigs/kubebuilder/issues/3482)
- Reduce the maintainability effort to generate the images used by Kubebuilder projects and dependency within third-party solutions.
- Related issues:
- [Issue #1885 - use a NetworkPolicy instead of kube-rbac-proxy](https://github.com/kubernetes-sigs/kubebuilder/issues/1885)
- [Issue #3230 - Migrate away from google.com gcp project kubebuilder](https://github.com/kubernetes-sigs/kubebuilder/issues/3230)

**Proposed Solutions:**

- **Making kube-rbac-proxy Optional:** Offering users the option to include kube-rbac-proxy caters to diverse project
requirements and simplifies the transition towards its potential externalization or removal,
reducing future maintenance efforts.

- **Leveraging NetworkPolicies:** This alternative focuses on minimizing external dependencies by
utilizing Kubernetes-native solutions like NetworkPolicies, in line with our maintenance reduction goals.

- **Default Enablement of cert-manager:** While not directly addressing the maintenance concerns related to
kube-rbac-proxy, defaulting to cert-manager responds to community feedback and navigates the upcoming deprecations.
This strategy also acknowledges cert-manager's existing role as a prerequisite for webhooks.

---
### Providing Helpers for Project Distribution

#### Distribution via Kustomize

**Status:** :white_check_mark: Complete

As of release ([v3.14.0](https://github.com/kubernetes-sigs/kubebuilder/releases/tag/v3.14.0)),
Kubebuilder includes enhanced support for project distribution.
Users can now scaffold projects with a `build-installer` makefile target.
This improvement enables the straightforward deployment of solutions directly to Kubernetes clusters.
Users can deploy their projects using commands like:

```shell
kubectl apply -f https://raw.githubusercontent.com/<org>/my-project/<tag or branch>/dist/install.yaml
```

This enhancement streamlines the process of getting Kubebuilder projects running on clusters, providing a seamless deployment experience.

#### (New Optional Plugin) Helm Chart Packaging

**Status:** :raised_hands: Proposal in Progress; Seeking Contributions

**Objective:** We aim to introduce a new plugin for Kubebuilder that packages projects as Helm charts,
facilitating easier distribution and integration of solutions within the Kubernetes ecosystem. For details on this proposal and how to contribute,
see [GitHub Pull Request #3632](https://github.com/kubernetes-sigs/kubebuilder/pull/3632).

**Motivation:** The growth of the Kubernetes ecosystem underscores the need for flexible and
accessible distribution methods. A Helm chart packaging plugin would simplify the distribution of the solutions
and allow easily integrations with common applications used by administrators.

---
### Updating Scaffolding to Align with the Latest changes of controller-runtime

**Status:** :raised_hands: Seeking help from the contributors

**Objective:** Update Kubebuilder's controller scaffolding to align with the latest changes
in controller-runtime, focusing on compatibility and addressing recent updates and deprecations
mainly related to webhooks.

**Context:** Kubebuilder's plugin system is designed for stability, yet it depends on controller-runtime,
which is evolving rapidly with versions still under 1.0.0. Notable changes and deprecations,
especially around webhooks, necessitate Kubebuilder's alignment with the latest practices
and functionalities of controller-runtime. We need update the Kubebuilder scaffolding,
samples, and documentation.

**References:**
- [Issue - Deprecations in Controller-Runtime and Impact on Webhooks](https://github.com/kubernetes-sigs/kubebuilder/issues/3721) - An issue detailing the deprecations in controller-runtime that affect Kubebuilder's approach to webhooks.
- [PR - Update to Align with Latest Controller-Runtime Webhook Interface](https://github.com/kubernetes-sigs/kubebuilder/pull/3399) - A pull request aimed at updating Kubebuilder to match controller-runtime's latest webhook interface.
- [PR - Enhancements to Controller Scaffolding for Upcoming Controller-Runtime Changes](https://github.com/kubernetes-sigs/kubebuilder/pull/3723) - A pull request proposing enhancements to Kubebuilder's controller scaffolding in anticipation of upcoming changes in controller-runtime.

---
### Transition from Google Cloud Platform (GCP) to build and promote binaries and images

**Status:** :construction: Seeking Feedbacks and Contributions
- **Kubebuilder CLI**: :white_check_mark: Complete. It has been building using go releaser. [More info](./../build/.goreleaser.yml)
- **kube-rbac-proxy Images:** :raised_hands: Seeking Feedback, see: https://github.com/kubernetes-sigs/kubebuilder/pull/3860
- **EnvTest binaries:** :construction: Controller-Runtime maintainers are working in a solution to build them out and take the ownership over this one. More info:
- https://kubernetes.slack.com/archives/C02MRBMN00Z/p1712457941924299
- https://kubernetes.slack.com/archives/CCK68P2Q2/p1713174342482079

**Objective:** Shift Kubernetes (k8s) project infrastructure from GCP to shared infrastructures.
Furthermore, move away from the registry `k8s.gcr.io` to `registry.k8s.io`.

**Motivation:** The initiative to move away from GCP aligns with the broader k8s project's
goal of utilizing shared infrastructures. This transition is crucial for ensure the availability
of the artifacts in the long run and align complience with other projects under the kubernetes-sig org.
[Issue #2647](https://github.com/kubernetes/k8s.io/issues/2647) provides more details on the move.

**Context:** Currently, Google Cloud is used only for:

- **Rebuild and provide the images for kube-rbac-proxy:**

A particular challenge has been the necessity to rebuild images for the
[kube-rbac-proxy](https://github.com/brancz/kube-rbac-proxy), which is in the process of being
donated to kubernetes-sig. This transition was expected to eliminate the need for
continuous re-tagging and rebuilding of its images to ensure their availability to users.
The configuration for building these images is outlined
[here](https://github.com/kubernetes-sigs/kubebuilder/blob/master/RELEASE.md#to-build-the-kube-rbac-proxy-images).

- **Build and Promote EnvTest binaries**:

The development of Kubebuilder Tools and EnvTest binaries,
essential for controller tests, represents another area reliant on k8s binaries
traditionally built within GCP environments. Our documentation on building these artifacts is
available [here](https://github.com/kubernetes-sigs/kubebuilder/blob/master/RELEASE.md#to-build-the-kubebuilder-tools-artifacts-required-to-use-env-test).

**We encourage the Kubebuilder community to participate in this discussion, offering feedback and contributing ideas
to refine these proposals. Your involvement is crucial in shaping the future of secure and efficient project scaffolding in Kubebuilder.**

0 comments on commit 1ccc46b

Please sign in to comment.