[Sandbox] KusionStack #83
Comments
|
TAG-CS review, this project has:
|
@jberkus Thanks for the feedback! We'll take these as the action items. |
|
Nope! If there are questions, the TOC will send them to you or post them in this issue. |
|
@SparkYuan thank you for applying for CNCF Sandbox! The TOC would like to understand more about the project - please coordinate a presentation with TAG App Delivery and a recommendation from the TAG before the next Sandbox review in August. |
mrbobbytables
added
Postponed
mrbobbytables
added
TAG-assigned
|
@lianmakesthings @joshgav @thschue |
We have coordinated with TAG for a presentation session at the next meeting on July 10th. cc @angellk |
|
Slides from yesterday's presentation: https://drive.google.com/file/d/1XZcVpfF95G1o1NChACjEgPWyiUb41NQd/view?usp=sharing |
|
Looks like the project's roadmap has been moved, I was able to find the correct roadmap linked here: https://www.kusionstack.io/docs/reference/roadmap The adopters file linked is also invalid, this appears to be the correct file: https://github.com/KusionStack/community/blob/main/USERS.md Vault is a non-CNCF project. Does KusionStack have plans to integrate with Open-Bao? I see support for other commercial secrets mgmt solutions. For Compliance Report of Karpor, what are the sources of the compliance findings? Are they configurable? How often are they updated? looking at the other projects under KusionStack, they appear to be in varying states of maturity (using completeness of documentation as an indicator). Does KusionStack have plans to define levels for each of these? |
|
Hi @TheFoxAtWork, thanks for pointing out the outdated information! We have updated the links accordingly.
We can absolutely take a look at that. KusionStack itself is technology neutral. It’s designed to let platform engineers come in and define their preferred way to connect with ANY infrastructure, to eventually build a tailored golden path that meets specific organizational needs.
The reports are generated from third-party, open-source tools. Currently it has built-in support for a tool called kubeaudit which supports custom auditors. We have more third-party tools planned in the future, which extends the risk exposure beyond static YAML scanning to include things like CVE scanning, CIS Benchmarking, etc. Yes they will be configurable in the future. The reports are designed to be cached for 10 minutes by default and can be re-generated anytime on the spot.
Excellent question. We actually would like to discuss this a bit as well. KusionStack originates from years of experiences building platforms at scale at Ant Group. We are currently using KusionStack as an overarching group of platform engineering products we want to open source (i.e. stuff we believe that can be helpful for platform owners to build an IDP), including a Platform Orchestrator (Kusion), an insights & intelligence product (Karpor), a set of Kubernetes controllers solutions (operating & controller-mesh), and in the future, an IAM-related and perhaps a change-related product. They are designed to be loosely coupled but synergizes well when used together. So as you noticed, there’s a difference in maturity levels for these products because they are in different stages in their product lifecycle. Kusion is seen as the centerpiece and what we consider to be the most production-ready at this time. As a result, a significant chunk of our presentation is about Kusion as the platform orchestrator. And then we have other products that are proven to be valuable internally but obviously needs more polishing going into the community. We are more than happy to define their maturity levels individually and draw these lines somewhere if these differences are deemed problematic for its community success. As an extension to that statement, our question is, does the community generally welcome a larger initiative like this, or does it prefer smaller ones, i.e. break it apart into smaller pieces to have more certainty in each? And also from your experience, in terms of PLG, does either option presents a route that's more likely setting up the project for success? |
|
@ffforest thanks for the quick responses! I'd like to get better clarification on the separation of the described "Products" from the Open Source projects detailed here. I think that these technologies are what is currently used by Ant Group for their internal platforms and not currently products for purchase/subscription from Ant Group by non-Ant Group entities - Is this correct? Regarding:
The TOC sees several different patterns for projects that apply or are currently under the CNCF.
For the TOC's processes, if the project is substantially large - sub-projects not packaged with the "core" project are evaluated against the defined Project governance for managing them and their maturity and therefore the responsibility of the project to hold them accountable to that stated governance. For contributors, I cannot attest to their experience. @jberkus @CathPag @geekygirldawn : Do you have observations on this topic you can share? higher probability of contributions and engaged community in smaller or larger projects? I imagine it largely depends on the project governance. |
|
We have a few projects in the CNCF that are "federated" projects with multiple separable subprojects. Our experience is that the majority of contributors end up whichever of those subprojects becomes the most popular; Argo and Konveyor are both examples of this. So it's important for the core project to have plans for what to do if some of the subprojects "fall behind". |
|
Hi @TheFoxAtWork and @jberkus, appreciate the answer!
Yes that is correct. Here is a non-comprehensive list of companies that are using the open source version of kusion but there are no commercial activities if that's what you are asking.
Gotcha. You can find KusionStack's project level governance in the community repo. From an action standpoint, is there anything else we could provide in the meantime? |
|
Forest - thanks for the clarification! for now, as TAG, Community, and TOC have questions about the project, just answering them as you have time before the review in August. thank you for being so responsive! |
|
Hi @ffforest thanks for submitting your application! I have the following questions while reviewing your project:
Thanks! |
Hi @linsun,
|
Hi @linsun, |
|
The scope of this set of projects includes a number of areas including idp mesh and others. This raises a concern about accepting this project as defined as it's difficult to determine if the scope of the submission will change further over time. Can you provide some clarity around the roadmap and intended scope of kusionstack going forward? |
Hi @mauilion, I would characterize the intended scope of KusionStack as "tools that would be helpful for platform engineers to build an IDP that suits their needs". It's not a platform but rather a set of loosely coupled tools to help you get there. We are not expecting this vision to change long term because we believe internal platforms should be situationally tailored to their organizational needs. KusionStack first started with kusion and kcl (another sandbox project), which evolved to be platform orchestrator and config management DSL respectively. But that's not the only thing important when building an IDP. Throughout our platform engineering journey, we built out additional components in our IDP, including customized Kubernetes workloads and operators, and a multi-cluster data plane with intelligence (karpor), and decided to open source them because they were great additions to the platform. In the future we intend to open source an IAM-related and a change-related product as well. The roadmaps provided in this application refer to the individual ones for each of the tools mentioned above. Additionally there is a KusionStack-wide intro you can find here. It's basically what I said above but I'd be more than happy to consolidate them into a KusionStack-wide roadmap. |
Hi @mauilion, I’d like to add a little more on this subject. If this helps visualizing, this is our current interpretation of what building an IDP entails (diagram inspired by Pulumi), which sort of outlines the broad scope of what KusionStack intends to include in the future. Our vision is to enable platform builders to define opinionated golden paths rather than shipping a platform ourselves. That will be sort of the anchor during the development of this project. I have also added a KusionStack-level roadmap that includes the features to drive each project forward, grouped by their maturity levels. Also this might be a longshot but I’d be more than happy to talk over this at KubeCon HongKong next week if anyone is coming. |
|
Hi there, I'm checking to see if there any update on this issue. |
|
@ffforest apologies for the delay, I hope to have an update for you by end of this week. |
|
Moving to a vote 👍 |
Vote created@mrbobbytables has called for a vote on The members of the following teams have binding votes:
Non-binding votes are also appreciated as a sign of support! How to voteYou can cast your vote by reacting to
Please note that voting for multiple options is not allowed and those votes won't be counted. The vote will be open for |
|
/check-vote |
Vote statusSo far Summary
Binding votes (6)
|
| User | Vote | Timestamp |
|---|---|---|
| pacoxu | In favor | 2024-09-04 1:08:20.0 +00:00:00 |
| adohe | In favor | 2024-09-04 2:30:41.0 +00:00:00 |
| ffforest | In favor | 2024-09-04 3:47:32.0 +00:00:00 |
| SparkYuan | In favor | 2024-09-04 6:11:08.0 +00:00:00 |
| hoangndst | In favor | 2024-09-04 23:43:33.0 +00:00:00 |
|
/check-vote |
Vote statusSo far Summary
Binding votes (6)
|
| User | Vote | Timestamp |
|---|---|---|
| pacoxu | In favor | 2024-09-04 1:08:20.0 +00:00:00 |
| adohe | In favor | 2024-09-04 2:30:41.0 +00:00:00 |
| ffforest | In favor | 2024-09-04 3:47:32.0 +00:00:00 |
| SparkYuan | In favor | 2024-09-04 6:11:08.0 +00:00:00 |
| hoangndst | In favor | 2024-09-04 23:43:33.0 +00:00:00 |
|
/check-vote |
Vote statusSo far Summary
Binding votes (6)
|
| User | Vote | Timestamp |
|---|---|---|
| pacoxu | In favor | 2024-09-04 1:08:20.0 +00:00:00 |
| adohe | In favor | 2024-09-04 2:30:41.0 +00:00:00 |
| ffforest | In favor | 2024-09-04 3:47:32.0 +00:00:00 |
| SparkYuan | In favor | 2024-09-04 6:11:08.0 +00:00:00 |
| hoangndst | In favor | 2024-09-04 23:43:33.0 +00:00:00 |
|
/check-vote |
Vote statusSo far Summary
Binding votes (7)
|
| User | Vote | Timestamp |
|---|---|---|
| adohe | In favor | 2024-09-04 2:30:41.0 +00:00:00 |
| ffforest | In favor | 2024-09-04 3:47:32.0 +00:00:00 |
| SparkYuan | In favor | 2024-09-04 6:11:08.0 +00:00:00 |
| hoangndst | In favor | 2024-09-04 23:43:33.0 +00:00:00 |
| liu-hm19 | In favor | 2024-09-10 12:20:30.0 +00:00:00 |
| pacoxu | In favor | 2024-09-11 8:02:03.0 +00:00:00 |
|
/check-vote |
|
Votes can only be checked once a day. |
Vote closedThe vote passed! 🎉
Summary
Binding votes (8)
|
| User | Vote | Timestamp |
|---|---|---|
| @ffforest | In favor | 2024-09-04 3:47:32.0 +00:00:00 |
| @SparkYuan | In favor | 2024-09-04 6:11:08.0 +00:00:00 |
| @hoangndst | In favor | 2024-09-04 23:43:33.0 +00:00:00 |
| @liu-hm19 | In favor | 2024-09-10 12:20:30.0 +00:00:00 |
| @pacoxu | In favor | 2024-09-11 8:02:03.0 +00:00:00 |
| @adohe | In favor | 2024-09-12 2:22:08.0 +00:00:00 |
| @ruquanzhao | In favor | 2024-09-12 3:08:47.0 +00:00:00 |
|
I've created #295 to begin project onboarding. |
Application contact emails
Project Summary
A technology stack for building cloud-native Internal Developer Platforms (IDPs)
Project Description
What it does
KusionStack is a technology stack for building cloud-native IDPs. It enables application developers to perform all operational tasks throughout the DevOps lifecycle in one place, using one environment-agnostic configuration with building blocks, across multiple different infrastructures such as Kubernetes, clouds and on-premises infrastructures.
The building blocks are defined by platform engineers, designed to hide the infrastructure complexity while only exposing simple and developer-friendly schemas to the application developers, in order to reduce their cognitive overhead from the infrastructure concepts. The platform-standardized configurations such as security and compliance best practices are also codified into or serving as inputs to these building blocks.
Based on this design, KusionStack defines a new paradigm for application developers and platform engineers to collaborate. With the separation of concerns, different roles are focused on their parts based on their expertise and responsibility.
In addition, we are continuously adding components to KusionStack to provide a more secure and efficient path to build an IDP. For instance, operating and controller-mesh under KusionStack intend to enhance Kubernetes operational security, which help users build a more secure Kubernetes-based IDP.
Why it's needed
Cloud-native technologies are evolving constantly, delivering immense values but in the meantime, introducing new challenges to software organizations. The variety of infrastructures has exploded, significantly increasing the complexity of application delivery and operations. As the infrastructure continues to expand, developers face a rapidly multiplying cognitive overhead. In the meantime, the platform teams can't keep up with the pace of infrastructure development, making the platform a potential efficiency bottleneck. The traditional "ticketOps" approach is no longer suitable and we need a new way to navigate through the DevOps lifecycle of applications.
Org repo URL (provide if all repos under the org are in scope of the application)
https://github.com/KusionStack
Project repo URL in scope of application
https://github.com/KusionStack/kusion
Additional repos in scope of the application
https://github.com/KusionStack/karpor
https://github.com/KusionStack/operating
https://github.com/KusionStack/controller-mesh
Website URL
https://kusionstack.io/
Roadmap
Kusion: https://www.kusionstack.io/docs/reference/roadmap
Karpor: https://www.kusionstack.io/karpor/roadmap/
Roadmap context
This RoadMap listed above is at a high level and it's by each product under KusionStack.
Contributing Guide
https://github.com/KusionStack/community/blob/main/CONTRIBUTING.md
Code of Conduct (CoC)
https://github.com/KusionStack/community/blob/main/CODE_OF_CONDUCT.md
Adopters
https://github.com/KusionStack/community/blob/main/USERS.md
Contributing or Sponsoring Org
Ant Group
Maintainers file
https://github.com/KusionStack/community/blob/main/MAINTAINERS.md
IP Policy
Trademark and accounts
Why CNCF?
Alignment: As a Platform Engineering advocate, KusionStack has the vision to address challenges within applications' full DevOps lifecycle (delivery, operations, etc) in a time of aggressively expanding infrastructure technologies, and consequently, the cognitive burden for the developers that comes with it. KusionStack aims to eliminate infrastructure complexity for cloud-native applications and enable developer self-service via disciplines of Platform Engineering, which aligns perfectly with CNCF's mission to make cloud-native technologies ubiquitous.
Community: The CNCF hosts a large and vibrant community of developers and users, which can adopt, drive innovation, and contribute to KusionStack. Becoming a part of CNCF would help KusionStack attract more attention and developers, enrich the ecosystem, and accelerate growth.
Guidance and Governance: We wish to receive guidance from CNCF in building a healthy and dynamic community that helps KusionStack grow. In addition, adhering to the CNCF standards and interoperability makes it easier to integrate with other well-liked cloud-native technologies, which drives adoption.
Benefit to the Landscape
Help to build the Platform Engineering community: Being an early Platform Engineering practitioner, KusionStack is incubated at AntGroup based on years of cloud-native practice in production at a massive scale. The CNCF is also promoting and building a platform engineering community and has authored a platform whitepaper. We hope to join this community, contribute our efforts, and provide viable Platform Engineering solutions for the community with an aligned mission.
Simplify and drive adoption for other CNCF Projects: KusionStack has already integrated with several projects in the CNCF ecosystem. KusionStack aims to reduce if not eliminate the complexity of using cloud-native technologies via disciplines of Platform Engineering, which can drive adoption for other CNCF projects. Having such a toolset provides relevant users a leverage to harvest the full power of cloud-native technologies. With the ongoing effort to further integrate into the CNCF world, KusionStack will serve a broader range of scenarios, helping more users build more advanced platforms based on the principles of the CNCF platform whitepaper.
Cloud Native 'Fit'
Automation & Configuration
Cloud Native 'Integration'
As a tech stack to build an IDP, KusionStack is designed to minimize the friction in the DevOps lifecycle of cloud-native applications, ranging from application delivery to day-2 operations, which includes integration with a wide spectrum of cloud-native technologies.
In theory, KusionStack is technology neutral - In that it encapsulates a collection of tooling that enables the assembling of a golden path that meet the specific needs of its users (it can be either an individual user or an organization). The capabilities are modularized by design and can be extended with minimum effort.
In practice, KusionStack will prioritize integration for the most common needs in the lifecycle of cloud-native applications, such as:
The extendability of KusionStack (and therefore the integration mechanism with existing cloud-native technology) is mostly reflected in Kusion Modules. Kusion Modules are building blocks of re-usable code that represents a set of abstracted capabilities. Kusion Modules are defined by platform engineers and leveraged by the end user. We will also ship some common capabilities out-of-the-box.
Cloud Native Overlap
From the perspective of technical philosophy, product pattern and ultimate goal, we haven't found a significant overlap between KusionStack and other existing CNCF Projects. Although some might initially perceive an overlap between Kusion and KubeVela, they are in fact complementary and can be integrated to work together. As a lightweight, purely client-side tool, coupled with the corresponding Generator implementation, Kusion can render application configuration models to generate CRD resources for KubeVela and leverage KubeVela's control plane to implement application delivery.
KusionStack provides some of the foundational tools necessary for building an internal developer platform, but building a complete internal developer platform requires additional ecosystem support, such as infrastructure as code tools, CI/CD pipelines, GitOps engine, which fall outside the scope of KusionStack, also the community provides very mature technical solutions in these areas. Platform engineers can combine all these technologies to construct a truly production-ready IDP platform.
Similar projects
KubeVela
Landscape
Yes
Business Product or Service to Project separation
N/A
Project presentations
N/A
Project champions
N/A
Additional information
N/A
The text was updated successfully, but these errors were encountered: