|
| 1 | +# WG AI Gateway Charter |
| 2 | + |
| 3 | +This charter adheres to the conventions described in the [Kubernetes Charter |
| 4 | +README] and uses the Roles and Organization Management outlined in |
| 5 | +[wg-governance]. |
| 6 | + |
| 7 | +[wg-governance]:https://github.com/kubernetes/community/blob/master/committee-steering/governance/wg-governance.md |
| 8 | +[Kubernetes Charter README]:https://github.com/kubernetes/community/blob/master/committee-steering/governance/README.md |
| 9 | + |
| 10 | +## Scope |
| 11 | + |
| 12 | +The AI Gateway Working Group focuses on the intersection of AI and |
| 13 | +networking, particularly in the context of extending load-balancer, gateway |
| 14 | +and proxy technologies to manage and route traffic for AI Inference. |
| 15 | + |
| 16 | +This working group will define terms like "AI Gateway" within the context of |
| 17 | +Kubernetes and key use cases for users and implementations. It will propose |
| 18 | +deliverables that need to be adopted in order to serve AI Inference on |
| 19 | +Kubernetes. |
| 20 | + |
| 21 | +This comes at a time where there is a proliferation of "AI Gateways" being used |
| 22 | +for AI Inference, and a strong need for focus and collaboration to ensure |
| 23 | +standards around this space so that Kubernetes users get the features they need |
| 24 | +in a consistent way on the platform. |
| 25 | + |
| 26 | +### In Scope |
| 27 | + |
| 28 | +Overall guidance for the WG is to control scope as much as is feasible. The WG |
| 29 | +should avoid AI-specific functionality where it can: instead favoring the |
| 30 | +addition of provisions that help with AI use-cases, but are otherwise normal |
| 31 | +networking facilities. Under that guidance, the following is in-scope: |
| 32 | + |
| 33 | +* Providing definitions for networking related AI terms in a Kubernetes |
| 34 | + context. |
| 35 | + |
| 36 | +* Defining important AI networking use-cases for Kubernetes users. |
| 37 | + |
| 38 | +* Determining which common features and capabilities in the "AI Gateway" space |
| 39 | + need to be covered by Kubernetes standards and APIs according to user and |
| 40 | + implementation needs. |
| 41 | + |
| 42 | +* Creating proposals for "AI Gateway" features and capabilities to the |
| 43 | + appropriate sub-projects. |
| 44 | + |
| 45 | +* Propose new sub-projects if existing sub-projects are not sufficient. |
| 46 | + |
| 47 | +### Out of Scope |
| 48 | + |
| 49 | +* Developing whole "AI Gateway" solutions. This group will focus on |
| 50 | + enabling existing and new solutions to be more easily deployed and managed on |
| 51 | + Kubernetes, not adding any new production solutions maintained thereafter by |
| 52 | + upstream Kubernetes. |
| 53 | + |
| 54 | +* Any specific kind of hardware support is generally out of scope. |
| 55 | + |
| 56 | +* This group will not cover the entire spectrum of networking for AI. For |
| 57 | + instance: RDMA networks are generally out of scope. |
| 58 | + |
| 59 | +## Deliverables |
| 60 | + |
| 61 | +* A compendium of AI related networking definitions (e.g. "AI Gateway") and a |
| 62 | + key use-cases for Kubernetes users. |
| 63 | + |
| 64 | +* Provide a space for collaboration and experimentation to determine the most |
| 65 | + viable features and capabilities that Kubernetes should support. If there is |
| 66 | + strong consensus on any particular ideas, the WG will facilitate and |
| 67 | + coordinate the delivery of proposals in the appropriate areas. |
| 68 | + |
| 69 | +## Stakeholders |
| 70 | + |
| 71 | +* SIG Network |
| 72 | + |
| 73 | +### Related WGs |
| 74 | + |
| 75 | +* WG Serving - The domain of WG Serving is AI Workloads, which can be served by |
| 76 | + some of the networking support we want to add. When we have proposals that |
| 77 | + are strongly relevant to serving, we will loop them in so they can provide |
| 78 | + feedback. |
| 79 | + |
| 80 | +## Roles and Organization Management |
| 81 | + |
| 82 | +This working group adheres to the Roles and Organization Management outlined in |
| 83 | +[wg-governance] and opts-in to updates and modifications to [wg-governance]. |
| 84 | + |
| 85 | +[wg-governance]:https://github.com/kubernetes/community/blob/master/committee-steering/governance/wg-governance.md |
| 86 | + |
| 87 | +## Exit Criteria |
| 88 | + |
| 89 | +The WG is done when its deliverables are complete, according to the defined |
| 90 | +scope and a list of key use cases and features agreed upon by the group. |
| 91 | + |
| 92 | +Ideally we want the lifecycle of the WG to go something like this: |
| 93 | + |
| 94 | +1. Determine definitions and key use cases for Kubernetes users and |
| 95 | + implementations, and document those. |
| 96 | +2. Determine a list of key features that Kubernetes needs to best support the |
| 97 | + defined use cases. |
| 98 | +3. For each feature in that list, make proposals which support them to the |
| 99 | + appropriate sub-projects OR propose new sub-projects if deemed necessary. |
| 100 | +4. Once the feature list is complete, leave behind some guidance and best |
| 101 | + practices for future implementations and then exit. |
0 commit comments