sandbox
sandbox copied to clipboard
cncf
[Sandbox] Kubean
Application contact emails
[email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Project Summary
Kubean is a product-ready cluster lifecycle management toolchain based on kubespray and other cluster LCM engines.
Project Description
If you already have a Kubernetes cluster (referred to as a bootstrap cluster), Kubean simplifies the process of deploying additional production-ready Kubernetes clusters and ensures smooth lifecycle management. With Kubean, you can effortlessly extend your existing infrastructure and efficiently manage multiple clusters with ease. Its user-friendly features and streamlined processes enable a more graceful deployment experience for your Kubernetes clusters.
Kubean offers the following key features:
Easy Deployment: Kubean can be easily deployed using Helm Chart or kubectl commands. It facilitates efficient lifecycle management of Kubernetes clusters through declarative APIs, such as manifests.Offline Package Support: Kubean provides offline packages for OS packages, container images, and binaries. This feature is particularly useful in air-gapped environments where internet connectivity is limited or unavailable. The availability of offline packages ensures seamless operations in such scenarios.Multi-Architecture Support: Kubean supports multiple architectures, including AMD and ARM, across common Linux distributions. This comprehensive support enhances compatibility and flexibility, allowing users to deploy Kubean on different hardware platforms based on their specific needs.Customizability: Kubean allows for easy customization by enabling the addition of custom actions before or after operations. These custom actions can be implemented without modifying the core functionality of Kubespray. This modular approach empowers users to tailor Kubean according to their unique requirements and extend its capabilities effortlessly.It's
Org repo URL (provide if all repos under the org are in scope of the application)
https://github.com/kubean-io
Project repo URL in scope of application
https://github.com/kubean-io/kubean
Additional repos in scope of the application
No response
Website URL
https://kubean-io.github.io/kubean/en/
Roadmap
https://kubean-io.github.io/kubean/en/develop/roadmap/
Roadmap context
No response
Contributing Guide
https://github.com/kubean-io/kubean/blob/main/CONTRIBUTING.md
Code of Conduct (CoC)
https://github.com/kubean-io/kubean/blob/main/code-of-conduct.md
Adopters
- daocloud: https://docs.daocloud.io/en
- anonymous customer: https://github.com/clay-wangzhi/kube-on-kube
Contributing or Sponsoring Org
No response
Maintainers file
https://github.com/kubean-io/kubean/blob/main/MAINTAINERS.md
IP Policy
- [X] If the project is accepted, I agree the project will follow the CNCF IP Policy
Trademark and accounts
- [X] If the project is accepted, I agree to donate all project trademarks and accounts to the CNCF
Why CNCF?
The CNCF is the premier organization for cloud-native technologies and is backed by many leading companies in the industry. It also provides a platform for collaboration and community-building, which can lead to increased visibility, adoption, and contributions to Kubean.
Benefit to the Landscape
Managing the Kubernetes lifecycle is generally considered complicated and potentially insecure. With Kubean, this process can be simplified by applying resource manifests. We believe that the community will have a new and trendy way of managing clusters with the introduction of Kubean.
Cloud Native 'Fit'
Kubean is built using cloud-native technologies and fits within the "Certified Kubernetes - Installer" area.
Cloud Native 'Integration'
Kubean is based on the Kubespray engine by default, thus it possesses all the capabilities of Kubespray. Although Kubespray is excellent, in the scenario where there is already an existing Kubernetes cluster, using Kubean to manage the lifecycle of another cluster may be a better choice. Kubean simplifies any processes with the support of an existing cluster by leveraging Custom Resources (CR). It also provides built-in and custom hooks before or after cluster operations. In general, if you have used Kubespray before, using Kubean again may feel more relaxed. Additionally, in the future, Kubean will also support switching to different engines, such as kubekey.
Cloud Native Overlap
No response
Similar projects
KubeKey is an excellent Kubernetes/K3s installer that runs on the command line. In contrast, Kubean is a Kubernetes Operator that provides and processes CR resources specifically designed for clusters and their operations. It uses Jobs to complete cluster operations such as deploying a cluster.
Kops is another easy way to get a production-grade Kubernetes cluster up and running. It is also a command-line tool that is tightly integrated with cloud vendors and provides features that are unique to being used on a cloud platform, and it supports a limited variety of operating systems. In contrast, Kubean works for bare-metal and virtual machines, and also for cloud platforms.
Furthermore, Kubean provides a manifest that identifies and manages the range of versions of major components needed to deploy a cluster supported by its current version.
Landscape
Yes
Business Product or Service to Project separation
N/A
Project presentations
- https://twitter.com/i/status/1650655778284666880 - kubean demo
- https://killercoda.com/kubean - An introduction on how to use kubean
Project champions
No response
Additional information
No response
@ErikJiang It'd be great if you could present at a TAG Runtime meeting before the next TOC sandbox vote on Sept 12.
cc @raravena80 @helayoty @rajaskakodkar
Started the discussion in https://github.com/kubean-io/kubean/issues/899 to coordinate the discussion/presentation.
@nikhita @rajaskakodkar
Thank you very much, the core developers of the Kubean team will present at TAG's August 31st general meetings.
@nikhita @rajaskakodkar
😁 Hello, just now, the Kubean meeting has ended, If you have any questions, please feel free to write in the comments, Kubean developers will be positively answered, Thank you very much!
Slides:
https://docs.google.com/presentation/d/1Gh-Y8t4QGrq4s2nYI5YR0rycVHjQcmEOtxB1Xqotqr8/edit?usp=sharing
Q: What are the main differences between this project and Cluster API?
A: Kubean depends on kubespray, which runs as a Job pod for cluster lifecycle management operations, while kubean controls specific functions such as cluster creation, scaling, upgrading, deletion, etc. through custom resources. Cluster-API is an excellent project with a rich set of infrastructure providers, but it’s too complex for us to use, compared to Kuban, which is relatively simple because it doesn’t focus on infrastructure management, it focuses on k8s clusters, and there are only two CRDs that you really need to work with. As long as you’re familiar with Ansible and know how to configure kubespray, kubean is pretty easy for you to get started with.
Thanks for the great work @ErikJiang!
I'm one of the kubespray maintainers, we do lots of work to maintaince the kubespray is ready for production in a bare-metal environment, and intergate lots of addons. And kubespray is a pure ansible project.
The Kubean is good ecosystem project for kubespray. It leveage the ability of kubespray and make it works like operator . It can help more users to use the kubespray.
So Kubespray has said they would welcome Kubean as a subproject. Is there a reason not to go in that direction?
+1 to that if that's an approach under https://github.com/kubernetes-sigs/ ?
On Tue, Feb 27, 2024 at 11:52 AM Josh Berkus @.***> wrote:
So Kubespray has said they would welcome Kubean as a subproject. Is there a reason not to go in that direction?
— Reply to this email directly, view it on GitHub https://github.com/cncf/sandbox/issues/49#issuecomment-1967294738, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAPSIPVJNGE2OGKRPQTJATYVYMNLAVCNFSM6AAAAAA2WRKRIGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRXGI4TINZTHA . You are receiving this because you are subscribed to this thread.Message ID: @.***>
-- Cheers,
Chris Aniszczyk https://aniszczyk.org
Hi.
Adding here (apologies for the delay) the project was part of the sandbox review in December.
After review the TOC considered:
- This project is very useful for the community
- Operators have not been included as standalone projects in the CNCF
- The recommendation is to consider the proposal above and evaluate becoming part of the kubespray ecosystem as a sub-project
🤔 While kubean being a subproject of Kubespray is indeed one option,
based on my understanding, projects like Strimzi, serving as a Kafka operator, have already entered the sandbox.
Why is kubean being blocked? Is there a specific reason for it?
@rochaporto
Thanks @ErikJiang .
If you could add some more info motivating kubean as a separate project (instead of a sub-project of kubespray) this will help the TOC the next time the item is discussed.
I prefer kubean to exist as an independent project within the sandbox. This way, kubean would have more freedom to develop and evolve independently, without being constrained or influenced by kubespray's limitations and decisions. For example, as an independent project, kubean could implement specific features or improvements more quickly to meet the users' needs. Additionally, being an independent project would allow kubean to make decisions autonomously based on its requirements and goals, providing better flexibility to cater to different users and organizations.
While we desire kubean to develop independently, we also recognize that kubean still benefits from the kubespray community. We can collaborate with the kubespray community to ensure seamless integration between kubean and kubespray, offering users a more comprehensive solution.
I hope these points better support the application of kubean as an independent project within the sandbox. If you have any further questions or need more information, please let me know. Thank you!
Thanks @ErikJiang .
If you could add some more info motivating kubean as a separate project (instead of a sub-project of kubespray) this will help the TOC the next time the item is discussed.
@jberkus @rochaporto @caniszczyk @rajaskakodkar @nikhita
I am thrilled about the lively discussions surrounding kubean. Here are some of my thoughts on the relationship between kubean and Kubespray, kubean provides many other core features besides kubespray:
- Kubernetes on Kubernetes in a few minutes(Kubean provides a way to run another K8s cluster on Kubernetes in various deployment configurations. such as strimzi incubating project).An adopter has designed their public cloud hosting solution for Kubernetes clusters based on Kubean.
- Provides turnkey one-stop K8s air gap installation, upgrade, and update ability (supports most popular Linux distributions, including OCI images, system dependencies package, K8s binaries, etc.). These processes can be maintained through continuous integration and continuous deployment (CICD) workflows.
- Provide expansion capabilities pre and post cluster life cycle management, and support user-defined extensions plugins
- Support pre-installation validation, such as connectivity validate and configuring the system repository source.
- Support extension plugins installation after cluster installation.
- kubean has some built-in best practice plug-ins and supports user customization.
- Cluster tuning: Kubean facilitates the adjustment of various Kubernetes (K8s) parameters and system kernel parameters based on the size of the cluster.
- Support log traceback for each cluster operation and maintenance action (update, expansion, uninstallation), and support cluster rollback to a certain operating state.
- kubean's architecture can support multiple engines for cluster life cycle management in the future (such as projects similar to kubespray, kubekey etc). Already in the roadmap.
In other words, kubespray focuses on Deploy a Production Ready Kubernetes Cluster, while kubean focuses on the following core features it provides:
- Declarative, base on bare-metal
- Supports more Linux distributions, K8s production-level offline support
- Pre and Post plugin frameworks that are more practical for production.
- Multiple K8s lifecycle engines support
For these reasons, Kubean and Kubespray have distinct focuses. It might be more suitable for Kubean to evolve and develop as a separate project.
For context, TAG-Runtime is OK with Kubean being in sandbox.
One concern was that this project relied only on Kubespray, but if Kubean already added another engine(s) (Kubekey, etc.) to their roadmap, that addresses the concern.
Something to look for in the future if Kubean decides to apply for incubation is that they already have support for those additional engines.
Thanks a lot @raravena80 ! Very looking forward to Kubean joining sandbox in completing the final stage of the end-to-end cloud-native journey.
Thanks @ErikJiang . If you could add some more info motivating kubean as a separate project (instead of a sub-project of kubespray) this will help the TOC the next time the item is discussed.
@jberkus @rochaporto @caniszczyk @rajaskakodkar @nikhita
I am thrilled about the lively discussions surrounding kubean. Here are some of my thoughts on the relationship between kubean and Kubespray, kubean provides many other core features besides kubespray:
Kubernetes on Kubernetes in a few minutes(Kubean provides a way to run another K8s cluster on Kubernetes in various deployment configurations. such as strimzi incubating project).An adopter has designed their public cloud hosting solution for Kubernetes clusters based on Kubean.
Provides turnkey one-stop K8s air gap installation, upgrade, and update ability (supports most popular Linux distributions, including OCI images, system dependencies package, K8s binaries, etc.). These processes can be maintained through continuous integration and continuous deployment (CICD) workflows.
Provide expansion capabilities pre and post cluster life cycle management, and support user-defined extensions plugins
- Support pre-installation validation, such as connectivity validate and configuring the system repository source.
- Support extension plugins installation after cluster installation.
- kubean has some built-in best practice plug-ins and supports user customization.
Cluster tuning: Kubean facilitates the adjustment of various Kubernetes (K8s) parameters and system kernel parameters based on the size of the cluster.
Support log traceback for each cluster operation and maintenance action (update, expansion, uninstallation), and support cluster rollback to a certain operating state.
kubean's architecture can support multiple engines for cluster life cycle management in the future (such as projects similar to kubespray, kubekey etc). Already in the roadmap.
In other words, kubespray focuses on Deploy a Production Ready Kubernetes Cluster, while kubean focuses on the following core features it provides:
- Declarative, base on bare-metal
- Supports more Linux distributions, K8s production-level offline support
- Pre and Post plugin frameworks that are more practical for production.
- Multiple K8s lifecycle engines support
For these reasons, Kubean and Kubespray have distinct focuses. It might be more suitable for Kubean to evolve and develop as a separate project.
Yes, I agree with @wawa0210 's suggestion.
I've also discussed the roadmap for Kubespray at Kubecon Pairs with other Kubespray maintainers. For kubespray, the most important thing is to maintain a stable ansible kernel that can deploy Kubernetes production. It will be focusing on making ansible playbooks better.
So, kubean and kubespray have different concerns.
Vote created
@castrojo has called for a vote on [Sandbox] Kubean (#49).
The members of the following teams have binding votes:
| Team |
|---|
| @cncf/cncf-toc |
Non-binding votes are also appreciated as a sign of support!
How to vote
You can cast your vote by reacting to this comment. The following reactions are supported:
| In favor | Against | Abstain |
|---|---|---|
| 👍 | 👎 | 👀 |
Please note that voting for multiple options is not allowed and those votes won't be counted.
The vote will be open for 7days. It will pass if at least 66% of the users with binding votes vote In favor 👍. Once it's closed, results will be published here as a new comment.
![git-vote[bot] avatar](https://avatars.githubusercontent.com/in/206179?v=4 "Published by a pub.dev verified publisher"){kind=small}
Vote status
So far 36.36% of the users with binding vote are in favor (passing threshold: 66%).
Summary
| In favor | Against | Abstain | Not voted |
|---|---|---|---|
| 4 | 0 | 0 | 7 |
Binding votes (4)
| User | Vote | Timestamp |
|---|---|---|
| rochaporto | In favor | 2024-04-09 18:40:25.0 +00:00:00 |
| TheFoxAtWork | In favor | 2024-04-09 21:50:38.0 +00:00:00 |
| dims | In favor | 2024-04-09 17:37:12.0 +00:00:00 |
| kgamanji | In favor | 2024-04-10 16:17:06.0 +00:00:00 |
| @mauilion | Pending | |
| @linsun | Pending | |
| @dzolotusky | Pending | |
| @kevin-wangzefeng | Pending | |
| @cathyhongzhang | Pending | |
| @nikhita | Pending | |
| @erinaboyd | Pending |
Non-binding votes (1)
| User | Vote | Timestamp |
|---|---|---|
| pacoxu | In favor | 2024-04-10 0:13:06.0 +00:00:00 |
Vote status
So far 54.55% of the users with binding vote are in favor (passing threshold: 66%).
Summary
| In favor | Against | Abstain | Not voted |
|---|---|---|---|
| 6 | 0 | 0 | 5 |
Binding votes (6)
| User | Vote | Timestamp |
|---|---|---|
| dims | In favor | 2024-04-09 17:37:12.0 +00:00:00 |
| rochaporto | In favor | 2024-04-09 18:40:25.0 +00:00:00 |
| kgamanji | In favor | 2024-04-10 16:17:06.0 +00:00:00 |
| linsun | In favor | 2024-04-11 10:32:24.0 +00:00:00 |
| TheFoxAtWork | In favor | 2024-04-09 21:50:38.0 +00:00:00 |
| cathyhongzhang | In favor | 2024-04-11 15:59:29.0 +00:00:00 |
| @mauilion | Pending | |
| @dzolotusky | Pending | |
| @kevin-wangzefeng | Pending | |
| @nikhita | Pending | |
| @erinaboyd | Pending |
Non-binding votes (3)
| User | Vote | Timestamp |
|---|---|---|
| pacoxu | In favor | 2024-04-10 0:13:06.0 +00:00:00 |
| SSmallMonster | In favor | 2024-04-11 2:11:52.0 +00:00:00 |
| wawa0210 | In favor | 2024-04-11 13:31:55.0 +00:00:00 |
Vote status
So far 63.64% of the users with binding vote are in favor (passing threshold: 66%).
Summary
| In favor | Against | Abstain | Not voted |
|---|---|---|---|
| 7 | 0 | 0 | 4 |
Binding votes (7)
| User | Vote | Timestamp |
|---|---|---|
| dims | In favor | 2024-04-09 17:37:12.0 +00:00:00 |
| kgamanji | In favor | 2024-04-10 16:17:06.0 +00:00:00 |
| nikhita | In favor | 2024-04-12 9:29:17.0 +00:00:00 |
| rochaporto | In favor | 2024-04-09 18:40:25.0 +00:00:00 |
| cathyhongzhang | In favor | 2024-04-11 15:59:29.0 +00:00:00 |
| TheFoxAtWork | In favor | 2024-04-09 21:50:38.0 +00:00:00 |
| linsun | In favor | 2024-04-11 10:32:24.0 +00:00:00 |
| @mauilion | Pending | |
| @dzolotusky | Pending | |
| @kevin-wangzefeng | Pending | |
| @erinaboyd | Pending |
Non-binding votes (3)
| User | Vote | Timestamp |
|---|---|---|
| pacoxu | In favor | 2024-04-10 0:13:06.0 +00:00:00 |
| SSmallMonster | In favor | 2024-04-11 2:11:52.0 +00:00:00 |
| wawa0210 | In favor | 2024-04-11 13:31:55.0 +00:00:00 |