Kuma proposal for SandBox #436
Labels
Comments
amye
added
new project
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
{{ message }}
amye
added
new project
Hello,
We would like to propose to donate Kuma to CNCF as a SandBox project. We are opening this GitHub issue according to the process outlined here with the format outlined here.
Authors:
Background
Project Goal
Kuma is a modern control plane for Service Mesh and Microservices. It can run and be operated natively across both Kubernetes and VM environments, making it easy to adopt by every team in the organization with the goal of accelerating both Kubernetes and Service Mesh adoption.
By bundling the Envoy proxy as the underlying data-plane technology, Kuma can instrument any L4/L7 traffic to secure, observe, route and enhance connectivity between any service or database. It can be used natively in Kubernetes via CRDs, while at the same time providing a RESTful API, a native CLI tool and a built-in GUI that can be used to better integrate Kuma with the rest of the organization.
While Kuma provides easy to use Policy abstractions for most use-cases, Kuma also allows for the configuration of the underlying Envoy data-planes in a more fine-grained manner via the
ProxyTemplatepolicy. By doing so, Kuma can be used by both first-time users of Service Mesh, as well as the most experienced ones who want greater control of the underlying networing stack.Current Status
Project releases: Kuma has made 11 releases so far, with the latest one being 0.5 RC1 on April 17th 2020. The first release of Kuma was 0.1 on September 10th 2019.
Community status: Kuma has introduced open governance guidelines in April 2020, and has bi-weekly community calls to discuss the status of the project and its roadmap. It has about 1,400 stars on GitHub and 18 total contributors so far.
Kuma is currently being adopted by a few enterprise organizations to build zero-trust security model across different lines of business and platforms, as well as to accelerate the adoption of Envoy across the board.
Future Plans
Near-Term:
Long-Term:
Project Scope
Clear project definition
Does the project have a clear and well defined scope
The project aims to provide a universal control plane for Service Mesh with native Envoy support to secure, observe, and orchestrate service connectivity in any application - and across every platform - with ease of use, portability and extensibility in mind.
Value-add to the CNCF ecosystem
Does the project have a clear value add to the current project ecosystem. How does it relate to other projects with overlapping capabilities.
Kuma aligns with the CNCF mission as explained in chapter 1, and should advance the adoption of Envoy as the de-facto data plane for any modern architecture. As such Kuma is the only control plane for Service Mesh with native Envoy support that is in the process of being donated to the CNCF.
Envoy is quickly becoming the data-plane of the future for any modern application, and today the CNCF ecosystem doesn't have a donated and vendor-neutral control plane to help organizations increase the adoption of Envoy. As more digital products are built with cloud-native technologies, Kuma wants to advance the adoption of Envoy and other cloud-native projects across every organization and every industry with an open, neutral, portable and easy to use solution, and building an inclusive and diverse community that can support the growth of the project in the CNCF home.
Alignment with other CNCF projects
Does the project align and actively collaborate with other CNCF projects?
Kuma is fully aligned in supporting CNCF projects and integrations in order to help every user build a modern cloud-native infrastructure with a modern Service Mesh solution. In specific:
And more.
Does the project require any specific versions of projects (or APIs) to interoperate? (e.g. K8s API, CSI, CNI, CRI)?
We leverage the APIs of some projects (like Kubernetes) but we don't require specific versions.
Does the project augment or benefit other CNCF projects?
Kuma benefits the adoption of Envoy, Prometheus, Jager and of course Kubernetes.
Anticipated use cases
What problems does the project solve?
Security and Compliance: Automatically provides encryption and identity to any L4/L7 workload including (but not limited to) APIs, Microservices and Databases. This accelerates the security compliance journey of the organization, reduces risks and enables a Zero-Trust model across the entire organization.
Traffic Reliability: Improves the reliability of all the traffic running across any workload, any cloud and any platform (running on VMs or Kubernetes, both legacy and modern) by providing ready to use Envoy-based network policies.
Infrastructure Control: Provides out-of-the-box policies to manage the service traffic lifecycle and helps enable architectural control over the entire infrastructure. By reducing the overhead, teams can now focus more on delivering business logic and meeting their goals. Eliminating management of the network abstractions also reduces shadow IT practices.
Productivity and Speed: Reduces the network management overhead on the applications and provides a Service Mesh “overlay” across the entire organization. This allows the team to focus on delivering better and more reliable products faster - while leveraging ready-to-use network connectivity policies powered by Kuma.
Distributed Observability: Provides distributed metrics, logs and network traces across every workload running in the organization. This helps the organization identify connectivity and application errors in a shorter time frame and in more areas, and accelerates the delivery of better uptime.
Kubernetes Adoption: Decouples the networking management from existing VM-based applications to simplify the adoption of Kubernetes and containers, while providing security and observability to the transition reducing risks and accelerating the K8s journey.
Alignment with SIG Reference Model
Does the project align with the SIG CNCF reference model and which capabilities does it require/provide at each level of the reference model.
High level architecture
Describe the overall architecture of the project. Feel free to add diagrams.
There are two main components of Kuma that are very important to understand:
A minimal Kuma deployment involves one or more instances of the control-plane (kuma-cp), and one or more instances of the data-planes (kuma-dp) which will connect to the control-plane as soon as they startup. Kuma supports two modes:
Kubernetes mode
When running on Kubernetes, Kuma will store all of its state and configuration on the underlying Kubernetes API Server, therefore requiring no dependency to store the data. Kuma will also automatically inject the sidecar Envoy proxy to the workloads.
Universal mode
When running in Universal mode, Kuma will require a PostgreSQL database to store its state. The PostgreSQL database and schema will have to be initialized accordingly to the installation instructions.
Unlike kubernetes mode, Kuma won't require the kuma-injector executable to run:
More information can be accessed from the official documentation: https://kuma.io/docs/latest/documentation/overview/
Formal Requirements
Document that the project fulfills the requirements as documented in the CNCF graduation criteria for sandbox
Are there any anticipated issues with any of the criteria ?
No.
Has the TOC been approached for sponsorship? If yes, which TOC members have agreed to sponsor the project?
We also got positive feedback from:
CNCF IP Policy
Becoming a sandbox project requires adoption of the CNCF IP Policy: https://github.com/cncf/foundation/blob/master/charter.md#11-ip-policy
Kuma's source code is licensed under Apache License Version 2.0.
Has the IP policy been reviewed?
List the repos for the project and their current license
List any dependent repos (upstream/downstream) that are required to build the project (including but not limited to libraries, commercial tools, plugins)
The Kuma GUI, which is by default embedded into Kuma, is been developed at https://github.com/Kong/kuma-gui
What actions are required to be compliant with the IP policy?
Transfer ownership of Kuma's trademark and logo assets to the Linux Foundation.
Other Considerations
Please note, these are not gating criteria but rather to:
Cloud Native
Does the project meet the definition of Cloud Native? The CNCF charter states:
Yes.
Project and Code Quality
Are there any metrics around code quality? Are there good examples of code reviews? Are there enforced coding standards?
We run static analysis on every PR, this is an example of code review and we try to address codes styling in those reviews.
What are the performance goals and results? What performance tradeoffs have been made? What is the resource cost?
The main goal for any Kuma user is to make sure that the service-to-service communication is as fast as it can get: for this goal we are relying fully on Envoy, since Kuma itself is not on the execution path of the service traffic. No trade-offs have been made when it comes to Kuma itself, but as you can imagine there is always room for improvements (like pushing only selective changes to the underlying Envoy proxies as opposed to dynamically generating the entire configuration at once).
What is the CI/CD system? Are there code coverage metrics? What types of tests exist?
We are using CircleCI, and we provide both unit tests and integration tests when it comes to the features that have been built. The tests are executed on every PR, and they are a criteria of acceptance in order to be merged.
Is there documentation?
Yes, primarily at kuma-website in the
docsfolder. Also accessible at https://kuma.io/docs/.How is it deployed?
By using the official release tooling in the
toolsfolder. Kuma is being compiled on a variety of different operating systems by leveraging Docker, and then each resulting output is being compressed and made available to the end-user.How is it orchestrated?
Kuma can be fully orchestrated in Kubernetes when running in Kubernetes mode, and can be integrated via its RESTful API or native CLI on other environments when running in Universal mode. The
kumactlCLI tool also provides helpers in Kubernetes to install Kuma, to install Prometheus + Grafana as well as Jaeger for tracing.How will the project benefit from acceptance into the CNCF?
We will be providing a vendor-neutral home for the project, and since we will be donating the first control plane with native Envoy support to the community, we would like Kuma to become a neutral control plane primitive for higher level use-cases that the industry may want to build on top. Kuma will also benefit from being considered by other CNCF projects when it comes to providing integration points to their technology.
Has a security assessment by the security SIG been done? If not, what is the status/progress of the assessment?
No.
Promotion to Incubation
Open Governance
How are committers chosen?
Using the following criteria:
How are architectural and roadmap decisions made?
By opening GitHub issues to discuss proposals, as well as bringing up discussion topics in the bi-weekly community calls.
How many decision makers are outside the sponsoring organization.
None at the moment, although we have one committer that has demonstrated continued contributions to the project that is potentially on track to be added as an additional maintainer.
Adoption
Who are the current maintainers?
How long has the project been developed for?
Since September 10th, 2019.
Is there a commercial version of the project or a primary commercial sponsor?
There is no commercial version of the project. Kong Inc is the primary commercial sponsor.
Is the project used in production? If so, please list some of the accounts.
It's being used by a series of companies, including:
Other enterprise companies are using Kuma, but we cannot disclose their names because of legal contractual obligations. They will have to come forward and disclose it themselves.
Does the project participate in a CNCF User Group?
No.
Vendor Independence
Is the project reasonably independent from the sponsoring vendor?
Kong Inc - the original author of the project - has sponsored most of the development and in preparation to the CNCF donation we have been promoting project independence via public open governance guidelines and community calls. We are open to accept new maintainers to the project and we welcome every contributions that meets the project guidelines.
Are all communication channels and project resources hosted just for this project or with other CNCF projects/resources?
We use a Kuma slack channel.
Is all code that is part of the project hosted and part of the CNCF managed orgs and repos?
Not at moment since we are in the process of donating, but it can obviously be after the donation.
Are all defaults for upstream reporting either unset or community hosted infrastructure (i.e. doesn’t point to vendor hosted SaaS control plane or analytics server for usage data)? Is all project naming independent of vendors?
We are using Google Analytics and Splunk on our accounts, but those can certainly be transfered.
Relevant Assets regarding vendor independence
The text was updated successfully, but these errors were encountered: