toc icon indicating copy to clipboard operation
toc copied to clipboard
verified publisher icon cncf

[Incubation] Kgateway Incubation Application

Open linsun opened this issue 7 months ago • 0 comments

Review Project Moving Level Evaluation

[x] I have reviewed the TOC's moving level readiness triage guide, ensured the criteria for my project are met before opening this issue, and understand that unmet criteria will result in the project's application being closed.

Kgateway Incubation Application

v1.6 This template provides the project with a framework to inform the TOC of their conformance to the Incubation Level Criteria.

Project Repo(s): https://github.com/kgateway-dev/kgateway, https://github.com/kgateway-dev/community Project Site: kgateway.dev Sub-Projects: N/A Communication: #kgateway on CNCF slack.

Project points of contacts: [email protected]; [email protected]; [email protected]

Incubation Criteria Summary for Kgateway

Application Level Assertion

  • [x] This project is currently Sandbox, accepted on March 4, 2025, and applying to Incubation.
  • [x] This project is applying to join the CNCF at the Incubation level.

Adoption Assertion

The project has been adopted by the following organizations in a testing and integration or production capacity:

Application Process Principles

Suggested

N/A

Required

  • [X] Engage with the domain specific TAG(s) to increase awareness through a presentation or completing a General Technical Review.
    • If applicable this was completed and occurred on DD-MMM-YYYY, and can be discovered at $LINK.

The team presented to TAG network on Feb 13th, 2025. The recording is available on YouTube. TAG co-chair feedback was very positive: "It is Tag Networks recommendation that Kgateway is accepted as a Sandbox project, the project is mature, well governed and very well adopted by large and small organizations. The Github issues show good code sanity and code hygiene.

It feels like Kgateway could qualify for Incubation status and Tag Network would fully support this application. However, it is the maintainers request that the project is accepted as a Sandbox project before progressing with the Incubation process."

The team has done a best effort exercise on this and vendor neutrality is specifically highlighted in the project's governance doc

  • [x] Review and acknowledgement of expectations for Sandbox projects and requirements for moving forward through the CNCF Maturity levels.

The kgateway team is familar with the sandbox, incubation and graduation expectations. Met during Project's application on 06-Oct-2025.

  • [ ] 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.

Kgateway has lots of docs. The experience starts with quick install, traffic management, resilience, security, AI gateway, Integration with other projects such as Istio, Argo Rollout, Kubernetes, agentgateway etc. It also has a lot of docs around operations and show users how to install, upgrade, debug, uninstall along with using some sample apps.

Governance and Maintainers

Note: this section may be augmented by the completion of a Governance Review from the Project Reviews subproject.

Suggested

  • [ ] 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.
  • [x] Clear and discoverable project governance documentation.

The governance doc is at the root of the community repo.

  • [x] Governance is up to date with actual project activities, including any meetings, elections, leadership, or approval processes.

The governance doc was recently established in March 2025. There has not been much need to update it.

  • [x] Governance clearly documents vendor-neutral of project direction.

Vendor neutrality is specifically highlighted in the project's governance doc.

  • [x] Document how the project makes decisions on leadership, contribution acceptance, requests to the CNCF, and changes to governance or project goals.

While most business in kgateway is conducted by "lazy consensus", periodically the Maintainers may need to vote on specific actions or changes. The vote process is clearly documented in the voting section of project's governance doc. In this section it is also highlighted no single company should have more than six eligible voters. The changes to governce section clearly documents the change process for changing governence.

  • [ ] Document how role, function-based members, or sub-teams are assigned, onboarded, and removed for specific teams (example: Security Response Committee).
  • [ ] Document a complete maintainer lifecycle process (including roles, onboarding, offboarding, and emeritus status).
  • [ ] Demonstrate usage of the maintainer lifecycle with outcomes, either through the addition or replacement of maintainers as project events have required.
  • [ ] If the project has subprojects: subproject leadership, contribution, maturity status documented, including add/remove process.

Required

  • [x] Document complete list of current maintainers, including names, contact information, domain of responsibility, and affiliation.

This is documented in the community repo: https://github.com/kgateway-dev/community/blob/main/MAINTAINERS.md which includes names, github ID, affliation and area of maintainership.

  • [x] A number of active maintainers which is appropriate to the size and scope of the project.

The kgateway project has been running smoothly which regular releases: https://github.com/kgateway-dev/kgateway/tags. The team also has run community meeting every other Tuesday. The project is seen with steady Github star growth. 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] Code and Doc ownership in Github and elsewhere matches documented governance roles.

This is documented well including onboarding, offboarding and emeritus status.

  • [X] Document adoption and adherence to the CNCF Code of Conduct or the project's CoC which is based off the CNCF CoC and not in conflict with it.

The CoC can be easily found in the community repo: https://github.com/kgateway-dev/community/blob/main/CODE-OF-CONDUCT.md. It starts with "All members of the kgateway community must abide by the CNCF Code of Conduct".

  • [x] CNCF Code of Conduct is cross-linked from other governance documents.

Yes, this is documented at https://github.com/kgateway-dev/community/blob/main/CODE-OF-CONDUCT.md. Also following CNCF code of conduct is highlighted as one of the key contributor responsibilities. It is also included in the begginning of the governance doc

  • [x] All subprojects, if any, are listed.

No subprojects at the moment.

Contributors and Community

Note: this section may be augmented by the completion of a Governance Review from the Project Reviews subproject.

Suggested

  • [ ] Contributor ladder with multiple roles for contributors.

Required

  • [x] Clearly defined and discoverable process to submit issues or changes.

This is documented in the contributing section, where it describes the process to open issues. Also, in the contributing code section, it describes how to contribute small or large changes and engage with the maintainer community.

  • [x] Project must have, and document, at least one public communications channel for users and/or contributors.

All communication channels including slack are documented here.

  • [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.

Per the communication channels documented in the community repo:

  • CNCF slack #kgatewy channel: any questions regarding using or contributing to kgateway.
  • kgateway community meeting: You are welcome to ask us any kgateway questions/concerns or presenting your kgateway use cases.
  • Report kgateway security issues, please follow our vulnerability disclosure best practices.
  • [x] Up-to-date public meeting schedulers and/or integration with CNCF calendar.

Community meetings is in the kgateway community calendar. Recordings of the community meetings are available on a google drive.

  • [x] Documentation of how to contribute, with increasing detail as the project matures.

This is documented in the contributing section, where it describes how to contribute to the project. Also, in the contributing code section, it describes how to contribute small or large changes so new contributors can be effective.

  • [x] Demonstrate contributor activity and recruitment.

The project has been demonstrating continued contributor requirements, some examples below:

  • In May 2025, we had a big feature implemented by a user recently kgateway-dev/kgateway#11169.
  • We have been doing spotlight of contributors in the community to recognize contributors and in hope to recruit more contributors as well. Examples: ** https://www.linkedin.com/feed/update/urn:li:activity:7349480111953367041 ** https://www.linkedin.com/feed/update/urn:li:activity:7341857533822685186 ** https://www.linkedin.com/feed/update/urn:li:activity:7339300777095548928
  • We ran a LFX mentorship program for 2Q successfully with 2 mentees. Here are some examples of the work by our mentees: ** https://www.linkedin.com/feed/update/urn:li:activity:7368647668878753793 ** https://www.linkedin.com/feed/update/urn:li:activity:7361114726958784512
  • We are currently running LFX mentorship program for kgateway for Q3 as well with 2 mentees.

Engineering Principles

Suggested

  • [ ] Roadmap change process is documented.
  • [ ] History of regular, quality releases.

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. This requirement may also be satisfied by completing a General Technical Review.
    • If applicable a general Technical Review was completed/updated on DD-MMM-YYYY, and can be discovered at $LINK.

The kgateway website identifies the goal of the project is to be the most widely deployed gateway in Kubernetes:

  • Ingress gateway: This feature existed when kgateway first created as Gloo in 2018. The project has a long history of providing scalable API gateway solutions to its broad use base. Scroll down to the Users section of the website homepage, you can see a bunch of users.
  • Inference gateway: kgateway has passed the Kubernetes Gateway API inference extension conformance test.
  • LLM gateway: : kgateway can mediate traffic from microservice or AI agents to LLMs.
  • MCP/agent gateway: kgateway with agentgateway can mediate traffic among agent-to-agent or agent-to-mcp server tools.
  • [x] Document and maintain a public roadmap or other forward looking planning document or tracking mechanism.

This is well documented in the project roadmap doc.

  • [x] Document overview of project architecture and software design that demonstrates viable cloud native use cases, as part of the project's documentation. This requirement may also be satisfied by completing a General Technical Review.
    • If applicable a general Technical Review was completed/updated on DD-MMM-YYYY, and can be discovered at $LINK.

Kgateway architecture is documented in the architecture page in the project's documentation.

Kgateway's deployment patterns are documented in the deployment pattern page in the project's documentation. These deployment patterns capture common use cases of kgateway and how they are used by the project's adopters.

The project's documentation also contains detailed reviews of kgateway's custom resources that are built on top of the Kubernetes Gateway API along with supported policies.

  • [x] Document the project's release process.

The project's release process is documented here, which can be easily discovered in the main kgateway repo.

Security

Suggested

N/A

Required

Note: this section may be augmented by a joint-assessment performed by TAG Security and Compliance.

  • [x] Clearly defined and discoverable process to report security issues.

This is explained clearly in a few different ways:

  • From the main kgateway repo, navigate to the Security tab, the security policy shows the steps in details.
  • The community repo also has the CVE process, which can be easily discovered from the repo.
  • [x] Enforcing Access Control Rules to secure the code base against attacks (Example: two factor authentication enforcement, and/or use of ACL tools.)

The project uses automation to enforce access control rules based on what is specified in our project's admin, maintainer and voter yaml file.

  • [x] Document assignment of security response roles and how reports are handled.

From the CVE process, which refers to the process in the documentation, the following processes related to security vulnerabilities are documented:

  • Where to report
  • When to send a report
  • When not to send a report
  • How a CVE is evaluated and remediated
  • How to get on the early disclosure mailing list
  • Where to get updates or ask any other questions.
  • [x] Document Security Self-Assessment.

The project's security self-assessment is available for review in the project's repo. No critical vulnerabilities were discovered during the review.

  • [x] Achieve the Open Source Security Foundation (OpenSSF) Best Practices passing badge.

The project has achieved the best practice 100% passing badge: https://www.bestpractices.dev/en/projects/10534

Ecosystem

Suggested

N/A

Required

  • [x] Publicly documented list of adopters, which may indicate their adoption level (dev/trialing, prod, etc.)

The list of adopters are documented in the project's website, scroll down to the Users section. The website also contains a few quotes from users in the community.

  • [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 via the adopter interview form for verification of use of the project at the level expected, i.e. production use for graduation, dev/test for incubation.

  • [ ] TOC verification of 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 kgateway documentation highlights a number of integrations with Kubernetes as well as with other CNCF projects, including:

Additional Information

The project is known as Gloo (also open source) before the CNCF donation. Gloo was created in 2018. Idit tried to submit the project for incubation in Nov 2024, see https://github.com/cncf/toc/issues/1484 for details. We decided we wanted to get into CNCF first I submitted it as a sandbox project in early 2025 then applying for incubation.

linsun avatar Oct 06 '25 20:10 linsun