mirror of https://github.com/cncf/toc.git
Merge 049100ca42 into 51afd615e1
This commit is contained in:
Lin Sun
GitHub
commit
483f9e2ca4
|
|
@ -0,0 +1,103 @@
|
|||
---
|
||||
title: Knative Adopter Interview - Adopter 4
|
||||
|
||||
---
|
||||
|
||||
# Knative Adopter Interview - Adopter 4
|
||||
|
||||
## Organization Intro
|
||||
|
||||
|
||||
### Can you give us an overview of your organization and what it does?
|
||||
|
||||
Adopter 4 provides a platform for AI workloads.
|
||||
|
||||
## Motivation
|
||||
|
||||
### Compared with other products in this space (proprietary and open), what drew you to the project?
|
||||
|
||||
Knative was the leader in the space and provided the right set of features and abstractions. Adopter 4 did not want to build something from scratch themselves.
|
||||
|
||||
|
||||
## Usage Scenario
|
||||
|
||||
### How long has your organization used the project?
|
||||
|
||||
For about four years.
|
||||
|
||||
### What were the main motivations to adopt the project and which key features do you use today?
|
||||
|
||||
* Autoscaling (Knative pod autoscaler which takes advantage of user metrics)
|
||||
* Throughput and latency for metrics
|
||||
* Scale to zero is particularly useful.
|
||||
* Revision management and gradual rollout.
|
||||
* Handling complex network configuration.
|
||||
|
||||
|
||||
### What is the current level of usage (pre-production, production) and scale?
|
||||
|
||||
Knative is used in production for Adopter 4's platform.
|
||||
|
||||
Scale varies a lot by customer. Customers use it for both development and production, as well as with both medium and big models, so scale is not that big per customer. There are generally dozens of workloads per customer, but only several replicas.
|
||||
|
||||
|
||||
### What version is used and what is your update cadence with the project?
|
||||
|
||||
Adopter 4 is focusing on 1.18. There are different flavors of the platform. Some flavors are more managed by Adopter 4, and in some the customer is responsible for installing. Generally, they follow a twice-a-year “validation” for the latest versions.
|
||||
|
||||
|
||||
### Can you walk me through what your experience was in either adopting it outright or integrating it with your existing services and applications? What challenges did you experience with the project?
|
||||
|
||||
Adoption was pretty straightforward. It works really well most or all of the time. There were no issues that were not easy to spot or related to something that Adopter 4 did wrong.
|
||||
|
||||
### Did you find the information in the repo valuable to your implementation? What specifically?
|
||||
|
||||
|
||||
The docs are generally good, and in some areas excellent. In some areas, they are less organized or missing. For example, there are different ways to configure a service and revision, including per revision and global settings. Most of those settings are well organized, but many of them are scattered across different sections, which makes it hard to get the full picture or to know where to look for a particular feature. For some more advanced topics (for example, the different replica load balancing strategies), the formal docs don’t cover everything and info can only be found by reading code or sometimes markdown files in the repo. Reading code is a common way to address advanced topics.
|
||||
|
||||
### Has your implementation of the project provided measurable value?
|
||||
|
||||
Yes, Knative provides relevant features and it’s easy to measure cost savings from autoscaling and scale to zero. Customers can easily measure this. Adopter 4 also realized cost savings by avoiding developing a custom solution.
|
||||
|
||||
### Do you have any future plans regarding the project? More involvement, feature requests, expansion, etc.
|
||||
|
||||
Not planning to be involved in the community, but will keep using Knative.
|
||||
|
||||
Inference is changing a lot. With GenAI and LLMs and distributed inference, Knative is becoming a bit outdated. You either can’t use it or you need to spend a lot of time/effort to make it work. It might not be the right approach for emerging workloads.
|
||||
|
||||
|
||||
## Perception
|
||||
|
||||
### What is your perception in terms of the project’s:
|
||||
|
||||
#### Community openness
|
||||
|
||||
#### Governance
|
||||
|
||||
#### Community growth potential
|
||||
|
||||
#### Maintainer diversity and ladder
|
||||
|
||||
#### Maintainer response
|
||||
|
||||
### How are you participating in the project community?
|
||||
|
||||
### Did you need to engage with the community members or maintainers? If so, what was the context of the engagement and did it reach an acceptable outcome?
|
||||
|
||||
Adopter 4 is generally not familiar with the community. They feel that the project is very mature for what it does and rarely need to engage with the community. They do leverage GitHub, but generally find the answers in documentation or in old GitHub issues.
|
||||
|
||||
## Project Strengths
|
||||
|
||||
### In your opinion, what are the overall strengths of the project?
|
||||
|
||||
Autoscaling and scale to zero are particularly useful.
|
||||
|
||||
## Project Improvements
|
||||
|
||||
### Is there something you feel that holds the project back from reaching its ultimate potential?
|
||||
|
||||
There are some conflicts or clashes between Knative and KServe. It might be beneficial for those projects to merge; there is some perception that KServe is more mature/better than Knative. The project could provide better documentation to clarify the differences between the projects and highlight use cases where it excels.
|
||||
|
||||
### In your opinion, what can the project do better?
|
||||
|
||||
The docs could be better, and Knative could do more to stay relevant with the latest developments in inference serving. Overall, the project is really great for what it does, but needs to take a step forward to evolving workloads.
|
||||
|
|
@ -0,0 +1,115 @@
|
|||
---
|
||||
title: Knative Adopter Interview - Gojek
|
||||
|
||||
---
|
||||
|
||||
# Knative Adopter Interview - Gojek
|
||||
|
||||
Interviewee: Roman Wozniak, Head of Engineering, Gojek
|
||||
|
||||
|
||||
## Organization Intro
|
||||
|
||||
### Can you give us an overview of your organization and what it does?
|
||||
|
||||
The merger of Gojek and Tokopedia created the largest technology company in Indonesia, offering ride-hailing, e-commerce, and delivery services to millions of users across Indonesia and Singapore.
|
||||
|
||||
|
||||
## Motivation
|
||||
|
||||
### Compared with other products in this space (proprietary and open), what drew you to the project?
|
||||
|
||||
In 2019, my team and I worked closely with data scientists at Gojek to help them productize ML deployments and integrate them with the rest of the engineering systems. This approach worked well momentarily, but it didn’t scale as the company grew (hiring more ML engineers to embed them into product streams was expensive and time-consuming). That’s when we decided to build a scalable self-serve platform that would cater to data scientists' needs and offer them easy-to-use interfaces. We had a feature store (hist) and looked at the missing pieces of the lifecycle. We started examining existing platforms and did not find anything that matched our needs and was open-source and easy to use.
|
||||
|
||||
|
||||
## Usage Scenario
|
||||
|
||||
### How long has your organization used the project?
|
||||
|
||||
We have used Knative since 2020, first as a dependency of KF Serving (now, KServe) and later as an independent component of our DS Platform.
|
||||
|
||||
### What were the main motivations to adopt the project and which key features do you use today?
|
||||
|
||||
We currently use Knative Serving. We are looking at eventing, but largely using Serving for HTTP requests.
|
||||
|
||||
|
||||
|
||||
### What is the current level of usage (pre-production, production) and scale?
|
||||
|
||||
Knative has been used in production since very early in our adoption, and at very large scale. Serving millions of our users with over 100,000 RPS during peak times.
|
||||
|
||||
### What version is used and what is your update cadence with the project?
|
||||
|
||||
The update cadence follows latest minus one. Basically every time a new Knative and kserve release happens, we begin adopting N-1.
|
||||
|
||||
|
||||
### Can you walk me through what your experience was in either adopting it outright or integrating it with your existing services and applications? What challenges did you experience with the project?
|
||||
|
||||
We started building an ML model-serving component, but decided to go one level deeper. We looked at open-source components that could allow us to put together various elements and create a product to expose to end users. We first adopted Kserve and built easy-to-use tools and user interfaces on top to develop the platform. Later, we built an integration for ML experimentation based purely on Knative. It provides an API that converts to Knative resources and orchestrates those.
|
||||
|
||||
We did not encounter any major challenges while adopting. Post-COVID, cost optimization was a significant focus to understand how to use Knative more efficiently, specifically regarding right-sizing and tuning. We aimed to explore vertical autoscaling, but Knative primarily supported horizontal scaling at the time. We proposed a feature request to integrate VPA into Knative, but it wasn't finalized. This was not due to the project's unwillingness; rather, the complexity of integrating it into Knative was very high. Additionally, this was early in the Knative project, and Kubernetes also lacked maturity in this area (for instance, an API for in-place PodVerticalScaling was added to Kubernetes v1.33 and is still in beta).
|
||||
|
||||
|
||||
### Did you find the information in the repo valuable to your implementation? What specifically?
|
||||
|
||||
|
||||
The high level direction of the project and the project’s roadmap was very useful to help plan and understand where the project was going.
|
||||
|
||||
Github in general was very useful, specifically Github issues and release notes. Following the discussion on issues and pull requests helped understand the state of the project better.
|
||||
|
||||
|
||||
### Has your implementation of the project provided measurable value?
|
||||
|
||||
Yes.
|
||||
|
||||
### Do you have any future plans regarding the project? More involvement, feature requests, expansion, etc.
|
||||
|
||||
We are looking at possible agentic orchestration
|
||||
|
||||
## Perception
|
||||
|
||||
### What is your perception in terms of the project’s:
|
||||
|
||||
#### Community openness
|
||||
|
||||
The community feels open. At KubeCon North America we were able to talk to Knative maintainers.
|
||||
|
||||
#### Governance
|
||||
|
||||
We have a positive opinion of the governance.
|
||||
|
||||
#### Community growth potential
|
||||
|
||||
The community feels pretty mature, don’t feel like worry about the project health.
|
||||
|
||||
|
||||
#### Maintainer diversity and ladder
|
||||
|
||||
We have a positive impression of the maintainer pool.
|
||||
|
||||
#### Maintainer response
|
||||
|
||||
Response time from the maintainers is good.
|
||||
|
||||
### How are you participating in the project community?
|
||||
|
||||
### Did you need to engage with the community members or maintainers? If so, what was the context of the engagement and did it reach an acceptable outcome?
|
||||
|
||||
We have interacted with the community via community calls, slack, and on github. Github is the primary mechanism, followed by community calls, and then slack. Most of the time, we have had an acceptable outcome. The VPA scenario was less acceptable.
|
||||
|
||||
## Project Strengths
|
||||
|
||||
### In your opinion, what are the overall strengths of the project?
|
||||
|
||||
Scalability is the primary strength. The abstractions defined are good and provided lots of flexibility and allowed us to build a fairly stable API on top of it so we could focus on the problems we wanted to solve. Another strength is the the stable API. There are not frequent breaking changes.
|
||||
|
||||
|
||||
## Project Improvements
|
||||
|
||||
### Is there something you feel that holds the project back from reaching its ultimate potential?
|
||||
|
||||
Nothing comes to mind.
|
||||
|
||||
### In your opinion, what can the project do better?
|
||||
|
||||
The project is good and nothing actionable comes to mind.
|
||||
|
|
@ -0,0 +1,137 @@
|
|||
# Knative Adopter Interview - SVA
|
||||
|
||||
Interviewee: Norris Sam Osarenkhoe, Principal Solutions Architect, SVA System Vertrieb Alexander GmbH.
|
||||
|
||||
Interview date: June 18, 2025
|
||||
|
||||
## Organization Intro
|
||||
|
||||
|
||||
### Can you give us an overview of your organization and what it does?
|
||||
|
||||
SVA System Vertrieb Alexander GmbH is one of the leading system integrators in Germany in the fields of holistic IT with more than 3,200 employees at 27 branch offices. SVA focusses on the combination of high quality IT products with the project know-how and flexibility of SVA to achieve optimum solutions. Core subjects are Digital Process Solutions, Datacenter Infrastructure, IT Security, Business Continuity, SAP, Big Data and Analytics, End User Computing and Mainframe. Furthermore, SVA offers professional services around topics such as DevOps, Cloud-Native Software Development, Microsoft, IoT, SAM and many more topics.
|
||||
|
||||
## Motivation
|
||||
|
||||
### Compared with other products in this space (proprietary and open), what drew you to the project?
|
||||
|
||||
Open Standards are a big factor, as well as digital sovereignty. The cloud events spec was important. 2022 - we started evaluating different options, and realizing that hyperscalers were widely adopting the Cloud Events spec. On top of that, Knatives' architecture seems well thought in terms of separation of concerns between its components. E.g. in Eventing the architecture is cleanly cut into roughly three distinct areas:
|
||||
* eventing-core - Implements the general, non-specific Knative Eventing API (Ingress, Routing, Egress)
|
||||
* eventing-messaging - Implements a generic Knative Eventing messaging model API, like Broker/Trigger or Channel/Subscription
|
||||
* eventing-messaging-bindings - Integrates a specific messaging technology on top of the messaging model API (like Kafka)
|
||||
We knew if something were to happen at each level we could fix it or at least had the flexibility to swap in another solution. Additionally, Eventing offered integration with well known messaging solutions such as Kafka, NATS and RabbitMQ, which all were relevant for us. Cloud providers using these solutions as well, meant we would easily find specialist if needed.
|
||||
|
||||
Knative has a very plug and play architecture, which attracted us. It is very easy to onboard users. Eventing is very easy to explain, and allows building pretty complex use cases.
|
||||
|
||||
We did look at some other projects, but their governance wasn’t clear. The Knative governance stood out to us. It feels like it will be a project that will be around for some time and will have maintainers for some time.
|
||||
|
||||
|
||||
## Usage Scenario
|
||||
|
||||
### How long has your organization used the project?
|
||||
|
||||
We started using it in 2022. It appeared to be the right tool for our problem. In order to validate our assumption we started prototyping and did lots of performance testing to better understand failure modes, performance KPIs and the inner workings.
|
||||
|
||||
In the summer of 2022, we started said testing and prototyping. In parallel, we started to built up other environments. As of March 2023, we have successfully released our customized Knative-backed event-mesh on our customer project infrastructure.
|
||||
|
||||
2 FTEs were involved in this.
|
||||
|
||||
|
||||
### What were the main motivations to adopt the project and which key features do you use today?
|
||||
|
||||
The main motivations were:
|
||||
|
||||
* License
|
||||
* Open Standards
|
||||
* Clean, Extensible architecture via plugins.
|
||||
* Clean abstraction layer.
|
||||
|
||||
HTTP for serving and eventing was very easy to integrate and adopt.
|
||||
|
||||
Eventing was integrated first, the event driven architecture was used to help decouple legacy architectures. Kafka integration was a pretty crucial one.
|
||||
|
||||
Serving is used for more cross-cutting things within the platform, not exposed directly to end users. This is more of an enablement problem.
|
||||
|
||||
|
||||
### What is the current level of usage (pre-production, production) and scale?
|
||||
|
||||
It is used in production and handles roughly over a million events daily, with an availability of 99.9% supporting approx. 11 org units.
|
||||
|
||||
### What version is used, and what is your update cadence with the project?
|
||||
|
||||
We update quarterly, using OpenShift Serverless. OpenShift Serverless aligns with the upstream Knative project, but we use the downstream release for compliance reasons.
|
||||
|
||||
|
||||
### Can you walk me through what your experience was in either adopting it outright or integrating it with your existing services and applications? What challenges did you experience with the project?
|
||||
|
||||
Originally in 2022, the documentation was a bit lacking on the administration side. We needed to look at source code to help understand.
|
||||
|
||||
The operator had some issues around order of deletion of custom resources, and we had to do things like clean up finalizers.
|
||||
|
||||
Another challenge was dependencies on control plane webhooks (of the Knative Operator). The Knative Operator invokes a mutating webhook for part of the reconciler loop check when certain custom resources are to be deleted. If there is a CrashLoopbackOff or these webhooks are unreachable, the operator cleanup can become difficult if you are not deeply knowledgeable of the control plane dependencies.
|
||||
|
||||
Adoption on the end user side was pretty easy technically speaking. Mind shift for customers adopting an asynchronous event-driven architecture was more challenging. Knative team doesn’t have experience in highly regulated industries and some testing is lacking there in my opinion. This is apparent when looking at it from an admin perspective working in a usually air gapped environment, with challenges such as access to Container Images, private Certificate Authority or custom certificates. Most challenges in my view really are to be found on the administration side of things. However, it needs to be said, that Knative has done a lot to alleviate some admin issues we had.
|
||||
|
||||
|
||||
|
||||
### Did you find the information in the repo valuable to your implementation? What specifically?
|
||||
|
||||
### Has your implementation of the project provided measurable value?
|
||||
|
||||
The implementation has allowed us to build a solution that is entirely On-Prem, but with different environments. The ease of use and faster integrations has provided value for modernizing legacy applications at our customer site. It has cut down on onboarding quite a bit. We went from 2 weeks to onboard legacy services to one hour. It has also allowed us to add compliance checking and enforce more compliance in said regulated environments.
|
||||
|
||||
|
||||
### Do you have any future plans regarding the project? More involvement, feature requests, expansion, etc.
|
||||
|
||||
We have built some observability tooling around Knative Eventing, and would like to contribute that back. We would also like to create a blueprint for other federal agencies in Germany.
|
||||
|
||||
|
||||
## Perception
|
||||
|
||||
### What is your perception in terms of the project’s:
|
||||
|
||||
#### Community openness
|
||||
|
||||
The community is very open. For the number of people involved, the Knative community achieves a lot. Lots of sub-projects under the umbrella (e.g. knative-extensions).
|
||||
|
||||
#### Governance
|
||||
|
||||
The project has great governance.
|
||||
|
||||
#### Community growth potential
|
||||
|
||||
There is a lot of interaction for some use cases. The project probably need more contributions.
|
||||
|
||||
#### Maintainer diversity and ladder
|
||||
|
||||
The maintainer diversity could be better. It feels like mostly Red Hat is maintaining the project, based on who is at the booth (at KubeCon) and on slack. However, despite that the available amount of maintainers appears to be stable.
|
||||
|
||||
#### Maintainer response
|
||||
|
||||
The maintainers are pretty responsive. We feel very safe with Knative.
|
||||
|
||||
### How are you participating in the project community?
|
||||
|
||||
Via Slack and Github
|
||||
|
||||
### Did you need to engage with the community members or maintainers? If so, what was the context of the engagement and did it reach an acceptable outcome?
|
||||
|
||||
We have had good experience providing feedback to the community via Red Hat.
|
||||
|
||||
## Project Strengths
|
||||
|
||||
### In your opinion, what are the overall strengths of the project?
|
||||
|
||||
Knative has good open standards and is easy to adopt. It is also very stable and has very good performance, we have not been able to overwhelm it or bring it to its knees and feel very confident in it covering future demand.
|
||||
|
||||
|
||||
## Project Improvements
|
||||
|
||||
### Is there something you feel that holds the project back from reaching its ultimate potential?
|
||||
|
||||
The project could use more diversity of companies contributing to the Knative Serving side.
|
||||
|
||||
|
||||
### In your opinion, what can the project do better?
|
||||
|
||||
Better docs and guidance for admin scenarios would be better. For example, how to measure event congestion. Nothing talks about how to fine tune Kafka for Knative. More specific docs like that would be useful. It could also have better observability to support administration of deployments.
|
||||
|
|
@ -0,0 +1,103 @@
|
|||
# Knative Adopter Interview - Y Meadows
|
||||
|
||||
Interviewee: Adam Rich, VP and co-founder of Y Meadows
|
||||
|
||||
Interview Date: June 4, 2025
|
||||
|
||||
## Organization Intro
|
||||
|
||||
### Can you give us an overview of your organization and what it does?
|
||||
|
||||
Y Meadows provides AI-Driven Automation for Business Operations, such as order operations, customer inquiries, and account management.
|
||||
|
||||
## Motivation
|
||||
|
||||
### Compared with other products in this space (proprietary and open), what drew you to the project?
|
||||
|
||||
We use Knative serving. The main motivation was the scale to 0 functionality. We wanted to use that to help control costs, so that pods only use resources while they are running.
|
||||
|
||||
We started in 2020, and at the time there were only a few ways to scale to 0. We think Knative provides a clean way to do it. There are no restrictions on service or framework and it is open source. The project has a strong community presence and is used by GCP for their cloud run products so it is battle tested. It only has a few moving parts and minimum dependencies.
|
||||
|
||||
## Usage Scenario
|
||||
|
||||
### How long has your organization used the project?
|
||||
|
||||
About 5 years.
|
||||
|
||||
### What were the main motivations to adopt the project and which key features do you use today?
|
||||
|
||||
We use Knative serving for the scale to zero feature.
|
||||
|
||||
### What is the current level of usage (pre-production, production) and scale?
|
||||
|
||||
Knative is used in real production flow for all of our clients including some big name customers. It is a core part of our platform. We have used it in production at scale, for years.
|
||||
|
||||
### What version is used and what is your update cadence with the project?
|
||||
|
||||
We upgraded recently to 1.18. We upgrade about twice a year on average.
|
||||
|
||||
### Can you walk me through what your experience was in either adopting it outright or integrating it with your existing services and applications? What challenges did you experience with the project?
|
||||
|
||||
The install guide has decent docs. We had to make some adjustments for high availability and had to make minor config changes as to how we want to handle timeouts.
|
||||
|
||||
We ran into some scaling issues later on. Per the recommendation of maintainers, we switched the network plugin to Contour which helped. We also switched to GKE Data Plane v2 (which is Cilium based). We use a lot of IPs when we scale to a large number of services with Knative, and Cilium handles that well. We can also run on spot instances in GKE to cut cost which works well with Knative.
|
||||
|
||||
### Did you find the information in the repo valuable to your implementation? What specifically?
|
||||
|
||||
The project docs are critical. They are decent. They have nice reference docs, maintain change docs, and release notes. They also have a high availability section which is important.
|
||||
|
||||
### Has your implementation of the project provided measurable value?
|
||||
|
||||
Yes. The main value is that it reduces costs for us.
|
||||
|
||||
### Do you have any future plans regarding the project? More involvement, feature requests, expansion, etc.
|
||||
|
||||
We are happy with Knative and plan to continue using it. We plan to explore the internal TLS feature and upgrade to use the operator. We haven’t used Eventing yet, but could be using it in the future.
|
||||
|
||||
## Perception
|
||||
|
||||
### What is your perception in terms of the project’s:
|
||||
|
||||
#### Community openness
|
||||
|
||||
The community has been helpful to us when we interact on Slack and GitHub.
|
||||
|
||||
#### Governance
|
||||
|
||||
The maintainers work together in the open on Slack and GitHub and seem to be maintaining the project well.
|
||||
|
||||
#### Community growth potential
|
||||
|
||||
I believe that to cost effectively use the cloud you need to be able to autoscale and the ideal of autoscaling is to scale to zero. KNative is an excellent way of achieving that. I think that there is a lot of potential to grow usage and the community.
|
||||
|
||||
#### Maintainer diversity and ladder
|
||||
|
||||
I am not familiar enough with the maintainers and their backgrounds to comment on this.
|
||||
|
||||
#### Maintainer response
|
||||
|
||||
The maintainers are responsive and have been helpful to us. They are active on Slack and GitHub.
|
||||
|
||||
### How are you participating in the project community?
|
||||
|
||||
We have contributed to discussions on Slack and GitHub, providing our perspective as an end user.
|
||||
|
||||
### Did you need to engage with the community members or maintainers? If so, what was the context of the engagement and did it reach an acceptable outcome?
|
||||
|
||||
We had communications with [Dave Protasowski](@dprotaso) on CNCF slack, he was helpful and jumped on a call with us - really going above and beyond. We have also looked up GitHub issues for guidance. Most communications were in Slack.
|
||||
|
||||
## Project Strengths
|
||||
|
||||
### In your opinion, what are the overall strengths of the project?
|
||||
|
||||
The project has a solid architecture, scales well and solid documentation. It is transparent to workloads and doesn’t require clients to treat it differently and it is designed to fit the Kubernetes philosophy.
|
||||
|
||||
## Project Improvements
|
||||
|
||||
### Is there something you feel that holds the project back from reaching its ultimate potential?
|
||||
|
||||
For Knative serving, I think it is really reaching its potential. We would like Kourier to be considered as the default networking plugin instead of an extension. We would love to see TLS internally becomes the default as well. We would like see operator upgrade path from Helm as well.
|
||||
|
||||
### In your opinion, what can the project do better?
|
||||
|
||||
Same answer as above
|
||||
|
|
@ -0,0 +1,448 @@
|
|||
# Knative Graduation Due Diligence
|
||||
|
||||
- Link to [Graduation application issue](https://github.com/cncf/toc/issues/1509)
|
||||
- Based on the [graduation DD template](https://github.com/cncf/toc/blob/main/operations/toc-templates/template-dd-pr-graduation.md)
|
||||
- Project Repo(s): github.com/knative, github.com/knative-extensions
|
||||
- Project Site: https://www.knative.dev
|
||||
- Sub-Projects: Serving, Eventing, Functions, Client
|
||||
- Communication: https://cloud-native.slack.com/ #knative and various channels with #knative- prefix
|
||||
- Project points of contacts: steering@knative.team
|
||||
|
||||
## Graduation Evaluation Summary for Knative
|
||||
|
||||
### Criteria Evaluation
|
||||
|
||||
Lin Sun & Jeremy Rickard conducted the due diligence of Knative who applied for graduation. The project has completed the criteria that show its maturity at graduation. The following criteria implementations are noteworthy to call out:
|
||||
- Knative is a mature project that are endorsed by multiple adopters.
|
||||
- The project is not only vendor neutral but also has a very diverse set of maintainers, adopters and integrators. The steering committee is composed of members from 4 different set of organizations.
|
||||
- Knative documentation is fairly clear and easy to follow. The documentation contains not only knative architecture, get started, install, upgrade, troubleshooting but also administrator topics such as [configuring HA for serving](https://knative.dev/docs/serving/config-ha/) or [configuring application security with security guard](https://knative.dev/docs/serving/app-security/security-guard-about/)
|
||||
- The project does an excellent job of making sure that its working group public meetings are well documented.
|
||||
- According to the most recent [CNCF project velocity report](https://docs.google.com/spreadsheets/d/116ZU_ltVkJip7G073ocULHxKhy4F1OgWjNjtZ1IPBWk/edit?gid=0#gid=0), knative is the 36th most active project in CNCF, with over 120 authors and over 4000 commits) for the past 12 months.
|
||||
|
||||
The following actions were provided to the project that were considered blocking but since resolved:
|
||||
|
||||
- Add a [governance.md file](https://github.com/knative/community/pull/1685) to the community repo to make it visible and easy discover.
|
||||
- Clarify [subproject documentation](https://github.com/knative/community/pull/1703)
|
||||
- Clarify [maintainer affliation](https://github.com/knative/community/pull/1694).
|
||||
- [Updated maintainer list](https://github.com/knative/community/pull/1700) to be accurate.
|
||||
- Achieved [100% passing on OpenSSF best practice badge](https://www.bestpractices.dev/en/projects/5913#analysis).
|
||||
- [Removed mentioning of community meetings](https://github.com/knative/community/pull/1704) as it is not active any more.
|
||||
|
||||
The following recommendations were provided to the project that are non-blocking in the TOC's assessment but should be completed by the project to ensure continued viability of the project:
|
||||
|
||||
- [GTR review](https://github.com/knative/community/issues/1706) is being started by the project.
|
||||
- Asked the knative team to [add more production readiness documentation](https://github.com/knative/community/issues/1707).
|
||||
|
||||
### Adoption Evaluation
|
||||
|
||||
The adopter interviews showed project usage at a level compatible with CNCF graduation. Adopters interviewed deploy Knative in production systems as part of managed platform offerings, supporting a variety of workload types. The Serving sub-project has the most adoption and was cited repeatedly for it's scalability and stability, and have realized value in terms of cost-savings.
|
||||
|
||||
Adopters indicated that Knative is mature for the use cases that it solves, with API stability, performance, and the length of time adopters have successfully used it in production being key indicators. Several adopters highlighted an opportunity for Knative to evolve to support emerging workloads within the A.I. space, particularly around supporting new developments in inference serving.
|
||||
|
||||
Many adopters also indicated that Knative has an active community and has suitable documentation, however several adopters expressed a desire to see additional documentation around advanced administrative concepts.
|
||||
|
||||
|
||||
|
||||
|
||||
### Final Assessment
|
||||
|
||||
The TOC has found the project to have satisfied the criteria for Graduation.
|
||||
|
||||
### Criteria
|
||||
|
||||
## Application Process Principles
|
||||
|
||||
### Suggested
|
||||
|
||||
N/A
|
||||
|
||||
### Required
|
||||
|
||||
- [x] **Give a presentation and engage with the domain specific TAG(s) to increase awareness**
|
||||
|
||||
TAG Runtime - Presentation Feb 3rd, 2022 ([notes](https://docs.google.com/document/d/1k7VNetgbuDNyIs_87GLQRH2W5SLgjgOhB6pDyv89MYk/edit?tab=t.0#heading=h.wjqgcvq8889g), [video](https://www.youtube.com/watch?v=Qt--cUJOaQY&feature=youtu.be))
|
||||
TAG App Delivery - Presentation Nov 8th, 2023 ([slides](https://docs.google.com/presentation/d/1ZxsRVTYW2vdlqQqVkLTQupLIDe4Ie8aBzRy4PNDaxmY/edit#slide=id.p)). Note this was in person during KubeCon thus no recording.
|
||||
|
||||
- [x] **All project metadata and resources are [vendor-neutral](https://contribute.cncf.io/maintainers/community/vendor-neutrality/).**
|
||||
|
||||
The project's GitHub repos and project site are aligned with the TOC expectations for vendor neutrality.
|
||||
|
||||
- [X] **Review and acknowledgement of expectations for [sandbox](sandbox.cncf.io) projects and requirements for moving forward through the CNCF Maturity levels.**
|
||||
- [X] We [met](https://github.com/cncf/toc/issues/1509#issuecomment-2844841621) with the project lead and went over the expectation and requirements for graduated project on 01-May-2025.
|
||||
|
||||
- [x] **Due Diligence Review.**
|
||||
|
||||
Completion of this due diligence document, resolution of concerns raised, and presented for public comment satisfies the Due Diligence Review criteria.
|
||||
|
||||
- [X] **Additional documentation as appropriate for project type, e.g.: installation documentation, end user documentation, reference implementation and/or code samples.**
|
||||
|
||||
Knative provides a few additional types of documentation to support adopters. The installation doc provided a variety of options that is easy to understand with code samples. The project also has a production recommendations doc with some limited content and the TOC has suggested adding more to assist adopters in covering their production challenges and opportunities with Knative at scale.
|
||||
|
||||
## Governance and Maintainers
|
||||
|
||||
Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy.
|
||||
|
||||
### Suggested
|
||||
|
||||
- [x] **Governance has continuously been iterated upon by the project as a result of their experience applying it, with the governance history demonstrating evolution of maturity alongside the project's maturity evolution.**
|
||||
|
||||
[Governance review for the Knative project](https://docs.google.com/document/d/1kwlizyag6EsMn9GECYSam-beSosQZhLj5Q1R_FLYQyo/edit?tab=t.0) was performed in May 2025 and it looks reasonable and healthy for the project. No major must fix issues were flagged.
|
||||
|
||||
### Required
|
||||
|
||||
- [X] **Clear and discoverable project governance documentation.**
|
||||
|
||||
The TOC was able to discover the [governance file](https://github.com/knative/community/blob/main/GOVERNANCE.md) easily after suggesting the team to add one to improve discoverability. The project's overall governance is directly captured in the [Steering Committee](https://github.com/knative/community/commits/main/STEERING-COMMITTEE.md) file, which is linked from the GOVERNANCE.md.
|
||||
|
||||
- [X] **Governance is up to date with actual project activities, including any meetings, elections, leadership, or approval processes.**
|
||||
|
||||
The Steering Committee file provides the general information on how the project is governed, and reflects their current project activities and demonstrates conformance to their governance.
|
||||
|
||||
- [X] **Governance clearly documents [vendor-neutral](https://contribute.cncf.io/maintainers/community/vendor-neutrality/) of project direction.**
|
||||
|
||||
It is clearly documented in the governance doc: https://github.com/knative/community/blob/main/GOVERNANCE.md, where it states "Knative is a vendor-neutral project under the [CNCF](https://cncf.io/)". It also mentioned in the governance doc who are eligible for participation of SC elections of knative, which shapes the project direction. The current composition of SC looks relative vendor neutral to me as well.
|
||||
|
||||
- [X] **Document how the project makes decisions on leadership, contribution acceptance, requests to the CNCF, and changes to governance or project goals.**
|
||||
|
||||
The Knative [steering committee doc](https://github.com/knative/community/blob/main/STEERING-COMMITTEE.md) has detailed explanations on how project elects leaders, updates to the charter doc and make decisions, who is elegible to vote etc.
|
||||
|
||||
- [X] **Document how role, function-based members, or sub-teams are assigned, onboarded, and removed for specific teams (example: Security Response Committee).**
|
||||
|
||||
[Community roles doc](https://github.com/knative/community/blob/main/ROLES.md) explain different roles and what to do when a given role becomes inactive. Also the project has clear [security policy](https://github.com/knative/community/tree/main?tab=security-ov-file#readme) defined.
|
||||
|
||||
- [X] **Document complete list of current maintainers, including names, contact information, domain of responsibility, and affiliation.**
|
||||
|
||||
Both [steering committee](https://github.com/knative/community/blob/main/STEERING-COMMITTEE.md#committee-members) and [working group leads](https://github.com/knative/community/blob/main/working-groups/WORKING-GROUPS.md#working-groups) are documented. The entire [list of maintainers](It is documented here: https://github.com/knative/community/blob/main/MAINTAINERS.md) is documented as well.
|
||||
|
||||
- [X] **A number of active maintainers which is appropriate to the size and scope of the project.**
|
||||
|
||||
For the current cadence of changes in the project and backlog of work, the project has sufficient active maintainers to sustain its current and future momentum.
|
||||
|
||||
- [X] **Document a complete maintainer lifecycle process (including roles, onboarding, offboarding, and emeritus status).**
|
||||
|
||||
This is [documented](https://github.com/knative/community/blob/main/ROLES.md#approver) well including onboarding, offboarding and emeritus status.
|
||||
|
||||
- [X] **Demonstrate usage of the maintainer lifecycle with outcomes, either through the addition or replacement of maintainers as project events have required.**
|
||||
|
||||
From a few most recent PRs, this appears to be managed well. For example:
|
||||
- Remove someone off a working group lead: https://github.com/knative/community/pull/1682
|
||||
- Add someone to a working group lead: https://github.com/knative/community/pull/1677
|
||||
|
||||
- [X] **Project maintainers from at least 2 organizations that demonstrates survivability.**
|
||||
|
||||
Confirmed that knative has maintainers from at least 2 organizations based on the [steering committee](https://github.com/knative/community/blob/main/STEERING-COMMITTEE.md#committee-members) and [working group leads](https://github.com/knative/community/blob/main/working-groups/WORKING-GROUPS.md#working-groups) documents. The [maintainer file](https://github.com/knative/community/blob/main/MAINTAINERS.md) also show a diverse set of maintainers from multiple companies (Red Hat, IBM, AWS, Bloomberg, Vmware, etc).
|
||||
|
||||
- [X] **Code and Doc ownership in Github and elsewhere matches documented governance roles.**
|
||||
|
||||
Based on my limited browsing of the repository, it does seem to match, nothing is flagged. The project leadership team also recently updated the maintainer list to accurately reflect the current list of maintainers and their affliations. The owner alias files, for example https://github.com/knative/serving/blob/main/OWNERS_ALIASES or https://github.com/knative/eventing/blob/main/OWNERS_ALIASES are well maintained based on my research.
|
||||
|
||||
- [X] **Document agreement that project will adopt CNCF Code of Conduct.**
|
||||
|
||||
This is documented in the home page of the community repo: https://github.com/knative/community
|
||||
|
||||
- [X] **CNCF Code of Conduct is cross-linked from other governance documents.**
|
||||
|
||||
Yes, this is documented at https://github.com/knative/community/blob/main/CODE-OF-CONDUCT.md. Also linked from https://github.com/knative/community/blob/main/GOVERNANCE.md and https://github.com/knative/community/blob/main/ROLES.md as well as [Steering charter](https://github.com/knative/community/blob/main/STEERING-COMMITTEE.md#charter)
|
||||
|
||||
- [X] **All subprojects, if any, are listed.**
|
||||
|
||||
Subprojects are managed by Knative working groups (https://github.com/knative/community/blob/main/working-groups/WORKING-GROUPS.md). The three main (user-facing) subprojects are:
|
||||
* Serving
|
||||
* Eventing
|
||||
* Functions
|
||||
Which are documented as top-level tabs on [https://knative.dev/docs/concepts/](https://knative.dev/docs/concepts/).
|
||||
|
||||
A [PR](https://github.com/knative/community/pull/1703) has been opened to add additional subproject info on this.
|
||||
|
||||
- [X] **If the project has subprojects: subproject leadership, contribution, maturity status documented, including add/remove process.**
|
||||
|
||||
All repos in knative and knative-extensions are owned by a working group (see above), with the following process for requesting a new repository or promoting an extension repository to core:
|
||||
https://github.com/knative/community/blob/main/REPOSITORY-GUIDELINES.md
|
||||
|
||||
Working group leadership is managed by the process in https://github.com/knative/community/blob/main/ROLES.md, with current leads in https://github.com/knative/community/blob/main/working-groups/WORKING-GROUPS.md (and Peribolos used to manage actual role assignments)
|
||||
|
||||
Each extension repo should have its own reported maturity status, as described in https://github.com/knative/community/blob/main/REPOSITORY-GUIDELINES.md#additional--experimental-repositories
|
||||
|
||||
## Contributors and Community
|
||||
|
||||
Note: this section may be augmented by the completion of a Governance Review from TAG Contributor Strategy.
|
||||
|
||||
### Suggested
|
||||
|
||||
- [ ] **Contributor ladder with multiple roles for contributors.**
|
||||
|
||||
<!-- (TOC Evaluation goes here) -->
|
||||
|
||||
### Required
|
||||
|
||||
- [X] **Clearly defined and discoverable process to submit issues or changes.**
|
||||
|
||||
To request a new feature or propose changes to roadmap, users can use this link: https://github.com/knative/community/blob/main/mechanics/FEATURE-TRACKS.md. To change the charter, it is documented in the steering doc.
|
||||
|
||||
- [X] **Project must have, and document, at least one public communications channel for users and/or contributors.**
|
||||
|
||||
Yes, knative has a slack channel in CNCF. It was quite active.
|
||||
|
||||
- [X] **List and document all project communication channels, including subprojects (mail list/slack/etc.). List any non-public communications channels and what their special purpose is.**
|
||||
|
||||
Social media related discussion are documented here: https://github.com/knative/community/blob/main/SOCIAL-MEDIA.md
|
||||
Working group meeting and community meeting are also documented in the community repo: https://github.com/knative/community?tab=readme-ov-file#meetings-and-work-groups
|
||||
Slack guideline with channel info are listed here: https://github.com/knative/community/blob/main/SLACK-GUIDELINES.md
|
||||
|
||||
- [X] **Up-to-date public meeting schedulers and/or integration with CNCF calendar.**
|
||||
|
||||
This is very well documented in https://github.com/knative/community/blob/main/CALENDAR.MD.
|
||||
|
||||
- [X] **Documentation of how to contribute, with increasing detail as the project matures.**
|
||||
|
||||
Details on how to contribute are documented [here](https://github.com/knative/community/blob/main/CONTRIBUTING.md).
|
||||
|
||||
- [X] **Demonstrate contributor activity and recruitment.**
|
||||
|
||||
The project has run quite a bunch of [LF mentorship programs](https://github.com/cncf/mentoring/tree/main/programs) and other programs to recruit more contributors. There's lots of Knative projects:
|
||||
|
||||
* CNCF - Knative: Design and Implement Levels for Educational Game (2025 Term 1)
|
||||
* CNCF - Knative: Improve Knative Eventing Onboarding (2024 Term 2)
|
||||
* CNCF - Knative: Applying pre-prepared website design (2024 Term 2)
|
||||
* Knative - Contributor Journey Research (2024 Term 1)
|
||||
* Knative - Cross Namespace Event Links (2024 Term 1)
|
||||
* CNCF - Knative: Porting Knative Serving to Microshift (2023 Term 2)
|
||||
|
||||
Prior to the CNCF acceptance, the project also participated Google Summer of Code directly:
|
||||
https://github.com/knative/community/blob/main/google-summer-of-code/gsoc-2022.md
|
||||
https://github.com/knative/community/blob/main/google-summer-of-code/gsoc-2023.md
|
||||
|
||||
|
||||
## Engineering Principles
|
||||
|
||||
### Suggested
|
||||
|
||||
N/A
|
||||
|
||||
### Required
|
||||
|
||||
- [x] **Document project goals and objectives that illustrate the project’s differentiation in the Cloud Native landscape as well as outlines how this project fulfills an outstanding need and/or solves a problem differently.**
|
||||
|
||||
The [Knative website](https://knative.dev/docs/) identifies the goal of the project is to be:
|
||||
_"The easiest way to build and run serverless workloads on Kubernetes."
|
||||
|
||||
The website identifies two main subprojects: _serving_ and _eventing_.
|
||||
|
||||
There is a good overview of the [serving subproject](https://github.com/knative/specs/blob/main/specs/serving/overview.md) and the [eventing subproject](https://github.com/knative/specs/tree/main/specs/eventing) in the project Github repository. The Knative Github repository includes both motivation and goals for both subprojects. This information can also be found on the project website.
|
||||
|
||||
The stated [goal for serving](https://github.com/knative/specs/blob/main/specs/serving/motivation.md):
|
||||
|
||||
_"The goal of the Knative Serving project is to provide a common toolkit and API framework for serverless workloads."_
|
||||
|
||||
The stated [goal for eventing](https://github.com/knative/specs/blob/main/specs/eventing/motivation.md#motivation):
|
||||
|
||||
_"The goal of the Knative Eventing project is to define common primitives to enable composing event-processing applications through configuration, rather than application code."_
|
||||
|
||||
- [x] **Document what the project does, and why it does it - including viable cloud native use cases.**
|
||||
|
||||
The project website contains a good [overview](https://knative.dev/docs/concepts/) of what the project does, and the [resources](https://knative.dev/docs/concepts/serving-resources/revisions/) that are used to implement the project goals.
|
||||
|
||||
The website also has a detailed overview of the project's approach to [resource modeling](https://knative.dev/docs/concepts/duck-typing/) and why the approach was taken.
|
||||
|
||||
The project documentation has an extensive [testimonials](https://knative.dev/docs/about/testimonials/) and [case studies](https://knative.dev/docs/about/case-studies/) highlighting viable cloud native use cases.
|
||||
|
||||
- [x] **Document and maintain a public roadmap or other forward looking planning document or tracking mechanism.**
|
||||
|
||||
The project maintains public roadmaps in Github using Github project boards.
|
||||
|
||||
Each subproject maintains a separate roadmap. For example:
|
||||
|
||||
[Serving](https://github.com/orgs/knative/projects/53)
|
||||
[Client](https://github.com/orgs/knative/projects/37/)
|
||||
[Eventing](https://github.com/orgs/knative/projects/38)
|
||||
[Functions](https://github.com/orgs/knative/projects/49)
|
||||
|
||||
- [x] **Roadmap change process is documented.**
|
||||
|
||||
The project maintains a [consistent set of instructions](https://github.com/knative/community/blob/main/mechanics/ROADMAPS.md) for maintaining roadmaps across subprojects.
|
||||
|
||||
- [x] **Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of the project's documentation.**
|
||||
|
||||
The Knative documentation provides a basic [overview](https://knative.dev/docs/concepts/) of Knative concepts. Further detailed information can be found about [eventing](https://github.com/knative/specs/blob/main/specs/eventing/overview.md) resources and [serving](https://knative.dev/docs/serving/) resources. The documentation also provides relevant digrams depicting [serving architecture](https://knative.dev/docs/serving/architecture/) and [request flow](https://knative.dev/docs/serving/request-flow/) that provide additional supporting evidence of the cloud native use cases the project supports.
|
||||
|
||||
The serving and eventing documentation includes topics targeted toward both [developers](https://knative.dev/docs/eventing/event-delivery/#configuring-broker-event-delivery) and [administrators](https://knative.dev/docs/serving/knative-kubernetes-services/).
|
||||
|
||||
|
||||
- [x] **Document the project's release process and guidelines publicly in a RELEASES.md or equivalent file that defines:**
|
||||
|
||||
- [x] Release expectations (scheduled or based on feature implementation)
|
||||
- [x] Tagging as stable, unstable, and security related releases
|
||||
- [x] Information on branch and tag strategies
|
||||
- [x] Branch and platform support and length of support
|
||||
- [x] Artifacts included in the release.
|
||||
- Additional information on topics such as LTS and edge releases are optional. Release expectations are a social contract between the project and its end users and hence changes to these should be well thought out, discussed, socialized and as necessary agreed upon by project leadership before getting rolled out.
|
||||
|
||||
Knative documents the project release processes and guidelines in several files:
|
||||
|
||||
[RELEASE SCHEDULE](https://github.com/knative/community/blob/8921c0ad7fff98bc1a5d357910ae4fe806f09aa0/mechanics/RELEASE-SCHEDULE.md)
|
||||
|
||||
[RELEASE VERSIONING PRINCIPLES](https://github.com/knative/community/blob/8921c0ad7fff98bc1a5d357910ae4fe806f09aa0/mechanics/RELEASE-VERSIONING-PRINCIPLES.md)
|
||||
|
||||
These documents provide a good overview on the release schedule, how branches are used and supported, and what end users can expect in terms of API version compatability and compatability with Kubernetes.
|
||||
|
||||
While this documentaiton does not detail what artifacts are included in a release, the project uses Github for releases, including for Serving manifests and artifacts are easily observed. GCR is used for container image releases and released manifests use SHA references.
|
||||
|
||||
|
||||
- [x] **History of regular, quality releases.**
|
||||
|
||||
Each of the subprojects within Knative utilize Github to publish releases and have a lengthy history of releases. KNative Serving had a v1.0.0 release in November 2021 and has had regular releases since then. Releases appear to have good release notes and clearly indicate breaking changes and bug fixes.
|
||||
|
||||
## Security
|
||||
|
||||
Note: this section may be augmented by a joint-assessment performed by TAG Security.
|
||||
|
||||
### Suggested
|
||||
|
||||
- [ ] **Achieving OpenSSF Best Practices silver or gold badge.**
|
||||
|
||||
<!-- (TOC Evaluation goes here) -->
|
||||
|
||||
### Required
|
||||
|
||||
- [x] **Clearly defined and discoverable process to report security issues.**
|
||||
|
||||
The project has a [SECURITY.md](https://github.com/knative/community/blob/main/SECURITY.md) file defined in the community repo.
|
||||
|
||||
- [x] **Enforcing Access Control Rules to secure the code base against attacks (Example: two factor authentication enforcement, and/or use of ACL tools.)**
|
||||
|
||||
Two factor authentication is required for the [knative](https://github.com/knative) org as well as the [knative-extensions](https://github.com/knative-extensions) org in Github.
|
||||
|
||||
- [x] **Document assignment of security response roles and how reports are handled.**
|
||||
|
||||
The project has a [vulnerability disclosure response policy](https://github.com/knative/community/blob/main/working-groups/security/responding.md) that outlines the Product Security Taskforce, as well as the process for fixing an issue identified as a vulnerability and general timelines for remediation.
|
||||
|
||||
The project also has a documented policy for [early disclosure of security vulnerabilities](https://github.com/knative/community/blob/main/working-groups/security/disclosure.md) for distributors of Knative.
|
||||
|
||||
- [x] **Document Security Self-Assessment.**
|
||||
|
||||
Knative has completed a [security self-assessment](https://github.com/cncf/tag-security/blob/main/community/assessments/projects/knative/self-assessment.md).
|
||||
|
||||
- [x] **Third Party Security Review.**
|
||||
|
||||
- [x] Moderate and low findings from the Third Party Security Review are planned/tracked for resolution as well as overall thematic findings, such as: improving project contribution guide providing a PR review guide to look for memory leaks and other vulnerabilities the project may be susceptible to by design or language choice ensuring adequate test coverage on all PRs.
|
||||
|
||||
Knative underwent a [Third Party Security Audit](https://github.com/knative/docs/blob/main/reports/ADA-knative-security-audit-2023.pdf) by Ada Logics in 2023. The audit found 16 security issues, 15 of which were fixed with upstream patches. The remaining issue was not addressed, because it was only exploitable if fundamental security assumptions of the cluster were already broken. This is not planned to be fixed.
|
||||
|
||||
- [X] **Achieve the Open Source Security Foundation (OpenSSF) Best Practices passing badge.**
|
||||
|
||||
The passing badge is currently shown as 100%.
|
||||
|
||||
## Ecosystem
|
||||
|
||||
### Suggested
|
||||
|
||||
N/A
|
||||
|
||||
### Required
|
||||
|
||||
- [x] **Publicly documented list of adopters, which may indicate their adoption level (dev/trialing, prod, etc.)**
|
||||
|
||||
A list of public adopters can be found in the [ADOPTERS.md](https://github.com/knative/community/blob/main/ADOPTERS.MD) file.
|
||||
|
||||
|
||||
- [x] **Used in appropriate capacity by at least 3 independent + indirect/direct adopters, (these are not required to be in the publicly documented list of adopters)**
|
||||
|
||||
The project provided the TOC with a list of adopters for verification of use of the project in production. The project is used by a many global organizations and the TOC was able to verify confirm production use with all interviewed adopters.
|
||||
|
||||
- [x] **TOC verification of adopters.**
|
||||
|
||||
The Knative maintainers provided the TOC with a list of 20 adopters from different geographic regions and business segments who agreed to be interviewed for the Graduation Due Diligence process. 4 of these adopters were interviewed. The adoption portion of this document contains interview summaries from adopters who approved public attribution. All adopters recommended Knative for graduation and commented on project maturity. Scalability and stability were common strengths identified by adopters. The Knative Serving project especially was highlighted as providing a great deal of value to adopters.
|
||||
|
||||
Refer to the Adoption portion of this document.
|
||||
|
||||
- [x] **Clearly documented integrations and/or compatibility with other CNCF projects as well as non-CNCF projects.**
|
||||
|
||||
The Knative documentation highlights a number of integrations with Kubernetes as well as with other CNCF projects, including:
|
||||
|
||||
[Istio](https://knative.dev/docs/install/installing-istio/)
|
||||
[Helm](https://knative.dev/docs/install/operator/knative-with-operators/#install-via-helm-option-2)
|
||||
[Contour](https://knative.dev/docs/install/yaml-install/serving/install-serving-with-yaml/#__tabbed_1_3)
|
||||
[NATS](https://knative.dev/docs/install/yaml-install/eventing/install-eventing-with-yaml/#__tabbed_1_3)
|
||||
[cert-manager](https://knative.dev/docs/install/installing-cert-manager/)
|
||||
[Backstage](https://knative.dev/docs/install/installing-backstage-plugins)
|
||||
[Open Telemetry](https://knative.dev/docs/serving/observability/metrics/collecting-metrics/#about-opentelemetry)
|
||||
|
||||
Additionally, Knative integrates with non CNCF projects such as:
|
||||
|
||||
[Apache Kafka](https://knative.dev/docs/install/yaml-install/eventing/install-eventing-with-yaml/#optional-install-a-default-channel-messaging-layer)
|
||||
[rabbit mq](https://knative.dev/docs/install/yaml-install/eventing/install-eventing-with-yaml/#__tabbed_2_3)
|
||||
|
||||
Several of these integrations were mentioned during adoption interviewes as well.
|
||||
|
||||
|
||||
#### Adoption
|
||||
|
||||
##### Adopter 1 - YMeadows
|
||||
|
||||
Y Meadows provides AI-Driven Automation for Business Operations, such as order operations, customer inquiries, and account management.
|
||||
|
||||
YMeadows was interviewed as a Knative adopter on June 4, 2025. They have been using Knative in production for about five years, supporting all of their customers.
|
||||
|
||||
YMeadows originally adopted Knative for it's "scale to zero" features in order to control costs. The open source nature of the project, along with it's minimal dependencies, and active community presence were also strong factors in adopting the project.
|
||||
|
||||
When adopting Knative, YMeadows encountered some scaling issues, which were resolved by replacing the ingress component they were using. They generally found the documentation for the project to be adequate, however they had some issues related to supporting high availability and to address timeouts due to the size of workloads being used.
|
||||
|
||||
YMeadows has a positive opinion of the Knative community and views the project as having open and transparent governance, as well as a helpful community with responsive maintainers.
|
||||
|
||||
YMeadows would like to see internal TLS as a default configuration, more support for Kourier as a default networking plugin, and a smoother operator upgrade experience.
|
||||
|
||||
Overall, YMeadows recommended Knative for graduation and highlighted the cost reduction benefits the project helped deliver and highlighted the stability, scalability, documentation, and alignment with the general Kubernetes philosophy as overall strengths of the project.
|
||||
|
||||
The entire adopter interview can be found here: [YMeadows Adopter Interview](knative-adopter-interview-ymeadows.md)
|
||||
|
||||
##### Adopter 2 - SVA System Vertrieb Alexander GmbH
|
||||
|
||||
Note: This adopter uses Knative via the Red Hat OpenShift Serverless product for compliance reasons.
|
||||
|
||||
SVA System Vertrieb Alexander GmbH is one of the leading system integrators in Germany.
|
||||
|
||||
SVA System Vertrieb Alexander GmbH was interviewed as a Knative adopter on June 18, 2025. They adopted Knative in 2022, and are currently running the project in production, handling over a million events daily with 99.9% availability across 11 organizational units.
|
||||
|
||||
SVA System Vertrieb Alexander GmbH chose Knative for its open standards, clean abstraction layers, extensible architecture, and strong governance. The plug-and-play nature and integration with messaging systems like Kafka were key factors.
|
||||
|
||||
SVA System Vertrieb Alexander GmbH found Knative easy to adopt and saw dramatically reduced onboarding times for customers and were able to implement improved compliance controls in regulated environments. When adopting Knative, SVA System Vertrieb Alexander GmbH faced some challenges relating to documentation, particularly around administrative topics.
|
||||
|
||||
SVA System Vertrieb Alexander GmbH indicated they have a positive perception of the governance of Knative, although they would like to see increased contributor diversity.
|
||||
|
||||
Overall, they recommended the project for graduation in part due to it's stability, performance, ease of adoption.
|
||||
|
||||
The entire adopter interview can be found here: [SVA System Vertrieb Alexander GmbH Adopter Interview](knative-adopter-interview-sva.md)
|
||||
|
||||
##### Adopter 3 - Gojek
|
||||
|
||||
Gojek is a technology company in Indonesia, offering ride-hailing, e-commerce, and delivery services to millions of users across Indonesia and Singapore.
|
||||
|
||||
Gojek initially started using Knative in 2020 via the KServe project, before migrating directly to Knative. It is currently used in production at a very large scale, supporting millions of users and 100,000+ requests per second at peak times.
|
||||
|
||||
Gojek adopted Knative while building a self-serve ML model-serving and experimentation platform for data scientists. They chose Knative for it's ease of use, flexibility, and because it was an active open-source project.
|
||||
|
||||
While adopting, they had a positive experience overall. They saw immediate value and were able to deliver a platforms that were scalable, flexible, and had stable APIs. After the COVID-19 pandemic, cost optimization became a focus and they wanted to explore vertical autoscaling, but Knative primarily supported horizontal scaling at the time. They proposed a feature request to integrate VPA into Knative, but it wasn't finalized. This was not due to the project's unwillingness; rather, the complexity of integrating it into Knative was very high.
|
||||
|
||||
Gojek views the project as mature and effective, and did not offer any areas for improvement.
|
||||
|
||||
The entire adopter interview can be found here: [Gojek Adopter Interview](knative-adopter-interview-gojek.md)
|
||||
|
||||
|
||||
##### Adopter 4 - Cloud Service Provider
|
||||
|
||||
Adopter 4 provides a platform for AI workloads. They elected to provide this adopter interview anonymously.
|
||||
|
||||
Adopter 4 has run Knative in production for about four years, as part of their hosted platform. When building their platform, they wanted to provide the following features:
|
||||
|
||||
* Autoscaling
|
||||
* Throughput and latency for metrics
|
||||
* Scale to zero
|
||||
|
||||
Knative provided these capabilities, which meant that they did not have to build a solution on their own. Adoption for them was straightforward, with very few issues. Problems they did encounter were easily to identify and resolve using project documentation and by reviewing Github issues.
|
||||
|
||||
Adopter 4 does not actively participate in the community, finding they rarely need to engage with the community because the project is mature. Adopter 4 did comment that while the documentation is generally good, and in some areas excellent, some advanced topics were harder to find in documentation adn required some review of code and markdown files in order to find answers to some questions.
|
||||
|
||||
Overall, Adopter 4 feels that Knative is very mature for the problems that it solves, but commented that Knative might not be the right solution for emerging workloads and the project should consider how to evolve to support changes in the space.
|
||||
|
||||
The entire adopter interview can be found here: [Adopter 4 Adopter Interview](knative-adopter-interview-adopter-4.md)
|
||||
|
||||
Loading…
Reference in New Issue