Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Sandbox] kubegateway - name to be finalized pending cncf/k8s naming guideline #319

Open
2 tasks done
linsun opened this issue Jan 6, 2025 · 0 comments
Open
2 tasks done
Labels
New New Application

Comments

@linsun
Copy link

linsun commented Jan 6, 2025

Application contact emails

[email protected]; [email protected]; [email protected]

Project Summary

KubeGateway is a feature-rich, fast, and flexible Kubernetes-native ingress controller and next-generation API gateway that is built on top of Envoy proxy and the Kubernetes Gateway API.

Project Description

Built on open source and open standards, KubeGateway integrates Kubernetes Gateway API with a federated control plane that scales from lightweight microgateway deployments between services, to massively parallel centralized gateways handling billions of API calls, to advanced AI gateway use cases for safety, security, and governance when integrating applications with third-party LLMs. KubeGateway brings omni-directional API connectivity to any cloud and any environment.

The project is known as Gloo Gateway before the CNCF donation. Idit tried to submit the project for incubation in Nov 2024, see cncf/toc#1484 for details.

Org repo URL (provide if all repos under the org are in scope of the application)

https://github.com/k8sgateway

Project repo URL in scope of application

https://github.com/k8sgateway/k8sgateway, https://github.com/k8sgateway/community

Additional repos in scope of the application

Note: the repo/org/website name to be updated pending the final project name.

Website URL

https://k8sgateway.io/

Roadmap

https://github.com/k8sgateway/community/blob/main/ROADMAP.md

Roadmap context

The project is in the process of sanitize all Gloo related mention to be vendor neutral. The roadmap provides a high level overview of major work being planned, designed or implemented. This is the result of feedback from the community and agreed upon by project maintainers. To suggest a roadmap update, please submit a PR updating this roadmap file with your suggested item. For large changes discussion in slack or a meeting may be required. Roadmap changes which are not controversial may merge or a vote may be called if consensus cannot be reached.

Contributing Guide

https://github.com/k8sgateway/community/blob/main/CONTRIBUTING.md

Code of Conduct (CoC)

https://github.com/k8sgateway/community/blob/main/CODE-OF-CONDUCT.md

Adopters

https://k8sgateway.io/ scroll down to the Users section

Contributing or Sponsoring Org

solo.io

Maintainers file

https://github.com/k8sgateway/community/blob/main/MAINTAINERS.md

IP Policy

  • If the project is accepted, I agree the project will follow the CNCF IP Policy

Trademark and accounts

  • If the project is accepted, I agree to donate all project trademarks and accounts to the CNCF

Why CNCF?

Donating the project to the CNCF can provide significant benefits to the project and the broader cloud-native ecosystem.

  • Vendor-Neutral Governance: By donating the project, we can ensure the project is governed independently, which increases trust among users and contributors. We believe vendor-neutral projects often see broader adoption because enterprises feel confident they aren’t locked into a single vendor’s ecosystem.
  • Increased Adoption and Ecosystem Integration: As part of the CNCF, the project can gain visibility and adoption among enterprises and developers already invested in the CNCF ecosystem. The project already has integration with popular CNCF projects like Kubernetes, Envoy, Istio, Argo, Cert-Manager, External-DNS, OpenAI, and others can be added, enabling more seamless user experiences and driving adoption.
  • Promoting Open Standards: The project implements the Kubernetes's Gateway API, being part of CNCF would reinforce its role as an open, extensible API gateway, setting it apart from proprietary alternatives.
  • Community Growth: CNCF attracts a diverse and global developer and user community. Donating the project to CNCF could expand its contributor base, fostering innovation and accelerating feature development.
  • Technical Oversight and Best Practices: CNCF’s Technical Oversight Committee (TOC) and resources can help the project evolve with best practices for scalability, security, and maintainability. This ensures the project remains robust and competitive as user demands and the cloud-native landscape evolve.
  • Enhanced Collaboration & Innovation with the CNCF Ecosystem: The project’s donation would encourage tighter collaboration with other CNCF-hosted technologies. Projects like Envoy (already central to Gloo Gateway) and Kubernetes would naturally complement its evolution, benefiting end-users.

Benefit to the Landscape

Adding the project to the CNCF landscape creates a win-win scenario for the CNCF, solo.io and the global cloud-native community. The project expands the CNCF’s portfolio of cloud-native technologies by adding a robust, modern, feature rich cloud native API gateway solution that has been adopted by many adopters. CNCF already hosts foundational projects like Kubernetes, Envoy, and Istio and a few other API gateway projects, the project complements these technologies by providing advanced API management, traffic routing, and rich integration support. By adding another robust and feature rich API gateway project, end users would benefit from choosing the best technology stack along with the preferred vendor neutral governance. It ensures the project’s long-term sustainability, accelerates its adoption, and strengthens the CNCF’s position as the leader in driving innovation and interoperability in cloud-native technologies.

Cloud Native 'Fit'

Landscape: Gateway & Connectivity
TAGs: TAG-Network

The project fits seamlessly into the cloud-native landscape by addressing critical needs for API management, traffic control, and integration in modern distributed architectures. Here's how it aligns with the principles and components of the cloud-native ecosystem:

  • Kubernetes-Native: The project integrates deeply with Kubernetes, offering features like ingress controller capabilities, namespace isolation, and CRD-based configuration. Kubernetes is the de facto standard for cloud-native orchestration, and the project’s Kubernetes-native design makes it an ideal fit for managing traffic in containerized environments.
  • API Gateway for Cloud-Native Applications: The project serves as an API gateway, acting as a centralized entry point for managing and routing
  • Aligning with Cloud-Native Principles: The project embodies cloud-native principles such as scalability, resilience, and declarative APIs.
    Cloud-native architectures prioritize modularity, automation, and elasticity. The project supports these principles through its dynamic routing, fault tolerance, and integration with CI/CD pipelines.
  • Multi-Protocol support: The project supports a wide range of protocols, including HTTP, TCP, gRPC, and WebSocket.
  • Service Mesh integration The project integrates with Istio service mesh nicely and could easily be made to integrate with Linkerd or other meshes.

Cloud Native 'Integration'

The project is a feature-rich, fast, and flexible Kubernetes-native ingress controller and next-generation API gateway that is built on top of Envoy proxy and the Kubernetes Gateway API. The project supports the broad cloud native ecosystem by integrating with top open-source projects, including Kubernetes, Envoy, Istio, Cert-Manager, External-DNS for Kubernetes, OpenFaaS, Argo and many others.

The project's architecture is highly extensible and allows rapid integration of future popular open-source projects as they emerge.

Cloud Native Overlap

Searching "gateway" or "ingress" in CNCF landscape revealed the following projects in CNCF:

While these projects all attempting implementing k8s Gateway APIs, there are some differences. For example LoxiLB is based on eBPF. Emissary-Ingress and Kuadrant is lacking its k8s Gateway API implementation or update to GA. Easegress is not just focusing on API gateway but also service mesh. Contour isn't as feature rich as kubegateway as an API gateway.

Similar projects

There are a bunch of Gateway projects if you search the famous CNCF landscape, such as Kusk Gateway, Higress, Emissary-Ingress, KubeGateway (another project), Kong Gateway etc.

Landscape

Yes, it was listed in CNCF landscape as Gloo Gateway before the CNCF donation and will be added soon once the naming is finalized.

Business Product or Service to Project separation

Similar as Envoy, the project is designed to be highly extensible. Any product built on top of the project can use extension points to extend additional features.

Project Domain Technical Review

Not yet but plan to engage a specific TAG as soon as possible once the naming is finalized.

CNCF Contacts

No response

Additional information

No response

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
New New Application
Projects
Development

No branches or pull requests

1 participant