Add WG AI Integration #8519
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -3567,6 +3567,47 @@ workinggroups: | |
| liaison: | ||
| github: pohly | ||
| name: Patrick Ohly | ||
| - dir: wg-ai-integration | ||
| name: AI Integration | ||
| mission_statement: > | ||
| The AI Integration Working Group focuses on enabling seamless integration of AI/ML | ||
| control planes with Kubernetes, as well as providing standardized patterns for | ||
| deploying, managing, and operating AI applications at scale on Kubernetes. | ||
|
|
||
| charter_link: charter.md | ||
| stakeholder_sigs: | ||
| - API Machinery | ||
| - Apps | ||
| - Architecture | ||
| - Auth | ||
| - CLI | ||
| label: ai-integration | ||
| leadership: | ||
| chairs: | ||
| - github: ardaguclu | ||
| name: Arda Guclu | ||
| company: Red Hat | ||
| email: [email protected] | ||
| - github: rushmash91 | ||
| name: Arush Sharma | ||
| company: Amazon | ||
| email: [email protected] | ||
| - github: zvonkok | ||
| name: Zvonko Kaiser | ||
| company: NVIDIA | ||
| email: [email protected] | ||
| meetings: | ||
| - description: WG AI Integration Weekly Meeting | ||
| day: Wednesday | ||
| time: "9:30" | ||
| tz: PT (Pacific Time) | ||
| frequency: weekly | ||
| contact: | ||
| slack: wg-ai-integration | ||
| mailing_list: https://groups.google.com/a/kubernetes.io/g/wg-ai-integration | ||
| liaison: | ||
| github: pacoxu | ||
| name: Paco Xu 徐俊杰 | ||
| - dir: wg-batch | ||
| name: Batch | ||
| mission_statement: > | ||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,8 @@ | ||
| # See the OWNERS docs at https://go.k8s.io/owners | ||
|
|
||
| reviewers: | ||
| - wg-ai-integration-leads | ||
| approvers: | ||
| - wg-ai-integration-leads | ||
| labels: | ||
| - wg/ai-integration |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,39 @@ | ||
| <!--- | ||
| This is an autogenerated file! | ||
|
|
||
| Please do not edit this file directly, but instead make changes to the | ||
| sigs.yaml file in the project root. | ||
|
|
||
| To understand how this file is generated, see https://git.k8s.io/community/generator/README.md | ||
| ---> | ||
| # AI Integration Working Group | ||
|
|
||
| The AI Integration Working Group focuses on enabling seamless integration of AI/ML control planes with Kubernetes, as well as providing standardized patterns for deploying, managing, and operating AI applications at scale on Kubernetes. | ||
|
|
||
| The [charter](charter.md) defines the scope and governance of the AI Integration Working Group. | ||
|
|
||
| ## Stakeholder SIGs | ||
| * [SIG API Machinery](/sig-api-machinery) | ||
| * [SIG Apps](/sig-apps) | ||
| * [SIG Architecture](/sig-architecture) | ||
| * [SIG Auth](/sig-auth) | ||
| * [SIG CLI](/sig-cli) | ||
|
|
||
| ## Meetings | ||
| *Joining the [mailing list](https://groups.google.com/a/kubernetes.io/g/wg-ai-integration) for the group will typically add invites for the following meetings to your calendar.* | ||
| * WG AI Integration Weekly Meeting: [Wednesdays at 9:30 PT (Pacific Time)]() (weekly). [Convert to your timezone](http://www.thetimezoneconverter.com/?t=9%3A30&tz=PT%20%28Pacific%20Time%29). | ||
|
|
||
| ## Organizers | ||
|
|
||
| * Arda Guclu (**[@ardaguclu](https://github.com/ardaguclu)**), Red Hat | ||
| * Arush Sharma (**[@rushmash91](https://github.com/rushmash91)**), Amazon | ||
|
There was a problem hiding this comment. @rushmash91 can you work on getting your membership to be able to meet the requirements?
https://github.com/kubernetes/community/blob/master/committee-steering/governance/wg-governance.md There was a problem hiding this comment. Sure! Working on it, opened issue! |
||
| * Zvonko Kaiser (**[@zvonkok](https://github.com/zvonkok)**), NVIDIA | ||
|
|
||
| ## Contact | ||
| - Slack: [#wg-ai-integration](https://kubernetes.slack.com/messages/wg-ai-integration) | ||
| - [Mailing list](https://groups.google.com/a/kubernetes.io/g/wg-ai-integration) | ||
| - [Open Community Issues/PRs](https://github.com/kubernetes/community/labels/wg%2Fai-integration) | ||
| - Steering Committee Liaison: Paco Xu 徐俊杰 (**[@pacoxu](https://github.com/pacoxu)**) | ||
| <!-- BEGIN CUSTOM CONTENT --> | ||
|
|
||
| <!-- END CUSTOM CONTENT --> | ||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,105 @@ | ||
| # WG AI Integration Charter | ||
|
|
||
| This charter adheres to the conventions described in the [Kubernetes Charter | ||
| README] and uses the Roles and Organization Management outlined in | ||
| [wg-governance]. | ||
|
|
||
| ## Scope | ||
|
|
||
| The AI Integration Working Group focuses on enabling seamless integration of | ||
| AI/ML control planes with Kubernetes, as well as providing standardized | ||
| patterns for deploying, managing, and operating AI applications at scale | ||
| on Kubernetes. | ||
|
Comment on lines
+9
to
+12
There was a problem hiding this comment.
This makes sense to me: how can kubernetes best integrate with external AI systems.
This looks very close to wg-serving. Trying to confirm, wg-ai-integration is about how external AI system can use kube and wg-serving is about how best to run AI workloads on kube, right? There was a problem hiding this comment. Serving is for running AI models on k8s. The AI workloads (such as agents) connect to LLM/AI APIs such as those run by projects in WG Service scope or externally hosted. There was a problem hiding this comment. wg-serving is |
||
|
|
||
| The Working Group will provide a forum for a broad engineering community to | ||
| give feedback to the project on challenges encountered when integrating with | ||
| Kubernetes. | ||
|
|
||
| This addresses a broad need with many end-users deploying complex AI systems, | ||
| AI/ML platform providers, Kubernetes distributions, and developers of | ||
| distributed AI applications facing these integration challenges. Standardizing | ||
| solutions in this space benefits the entire Kubernetes ecosystem. Adjacent | ||
| ecosystems could link to the outputs of this WG as a trusted vehicle for | ||
| supporting AI integrations with Kubernetes. | ||
|
|
||
| ### In scope | ||
|
|
||
| * Develop a shared community point of view and associated best practices | ||
| enabling AI agent (or multi-agent) systems to integrate with Kubernetes. | ||
|
|
||
| * Provide a forum for intersecting code experimentation in AI integration | ||
| space and discussion with the existing Kubernetes community. | ||
|
|
||
| * Recommend an appropriate go forward governance model for AI Integrations | ||
| with the Kubernetes project. | ||
|
|
||
| * Identify appropriate auth(z) patterns for AI connector identities, its | ||
| closest caller, and Kubernetes RBAC. | ||
|
|
||
| * Defining benchmarks on pros/cons of design approaches to meet user outcomes. | ||
|
|
||
| * Ensure security, observability, and policy enforcement can be consistently | ||
| applied across integrated systems (K8s and external Control Planes such as | ||
| LLMs) and AI integration applications. | ||
|
|
||
| * Define potential enhancements to API conventions to scale AI integration | ||
| patterns that respect data privacy and safety concerns during our design | ||
| process. Consider alternative API patterns that could be a better fit for | ||
| AI enablement. | ||
|
|
||
| * Explore patterns for efficient network access to emergent protocols such | ||
|
There was a problem hiding this comment. @soltysh Here is the point related to networking :) There was a problem hiding this comment. Thank you, I've seen that, but still missed it 😅 |
||
| as MCP/A2A via proxies or gateways. | ||
|
|
||
| * Reduce the complexity and custom development required for deploying, | ||
| building and managing connectors of kubernetes API with AI agent ecosystems. | ||
|
|
||
| ### Out of Scope | ||
|
|
||
| * Development of AI/ML frameworks or applications | ||
| * General-purpose workload management not specific to AI/ML | ||
| * Deploying inference workloads on Kubernetes (which is covered by WG Serving) | ||
| * Manage accelerator devices (which is covered by WG Device Management) | ||
|
|
||
| ## Deliverables | ||
|
|
||
| * The WG will provide space for collaboration and experimentation. If/when any | ||
| solid ideas emerge that require changes to Kubernetes (for example, updates | ||
| to kubectl for AI consumption), the WG will facilitate and coordinate the delivery | ||
| of KEPs and their implementations by the participating SIGs. | ||
| * Interim artifacts will include documents capturing use cases, requirements, | ||
| integration architecture designs, and AI application communication patterns. | ||
| * Establish best practices document for AI tool integration with Kubernetes and | ||
| a clear recommendation if/what set of reference tools may best fit in | ||
| Kubernetes project itself informed from data driven experimentation with | ||
| appropriate governance model. | ||
|
|
||
| ## Stakeholders | ||
|
|
||
| * SIG Architecture | ||
| * SIG API Machinery | ||
| * SIG Apps | ||
| * SIG Auth | ||
| * SIG CLI | ||
| * SIG Network | ||
|
There was a problem hiding this comment. The big areas where SIG Network has been hearing about / dealing with AI are DRA (aka "Manage accelerator devices", which is marked out-of-scope) and inference-related Gateway features (which would seem to fall under "Deploying inference workloads", which is also marked out-of-scope, and which is the subject of a different AI WG proposal anyway). None of the things you list as "In scope" above seem like they need input from SIG Network. @kubernetes/sig-network-leads ? There was a problem hiding this comment. One area where SIG Network could have input is for protocol (such as MCP) proxies or gateways. There was a problem hiding this comment. I defer to Dan, I really not very familiar with these protocols you mention but it seems to me both WG-Serving and the AI-GW proposal Dan is indicating will overlap on that area There was a problem hiding this comment. Thanks for the review. I added an item for this in the charter. There was a problem hiding this comment. So do we still need sig-network here or not? And where is the updated point, I can't find it 😅 There was a problem hiding this comment. @aojea what are your specific concerns here? What are we currently doing with these WG Are we actively involved? Should we reduce this list? I know dev-mgmt, however are we as sig-net still playing a daily role in this? There was a problem hiding this comment. Let me try to answer, those WG touch areas from the SIG Network charter, node lifecycle with endpoints, device management with network endpoints, serving as inference ... we asked a fair question on what is the overlap with SIG network charter and the answer is A2A and MCP protocols that are the same as websocket, is not in SIG network charter... I dont have more interest than resolving a conversation, and I talked with mrunal in private to clarify... If any SIG network lead had approved without an unresolved conversation I would not have any objections, I trust other to make the call they think is good for the SIG ... But I found surprising to approve when the conversation was open and waiting for an answer There was a problem hiding this comment. I believe @shaneutt had a distinction between the current AI related working groups and the proposed. The question is fair, I am not contesting that, more asking for information on how to appropriately prioritize. We should have clear defined boundaries, however slight overlap isn't a bad thing at all. Shane is currently OOF, we should give him the benefit of the doubt this comment was missed? @shaneutt if you could address the concern from @danwinship? In the interest of transparency lets keep all conversations related to this PR here. There was a problem hiding this comment. Let me explain myself better, I'm totally in favor of this WG and I was on my way to +1 from my steering hat thinking this conversation was solved. This WG is going to be created with or without SIG Network, there are already 5 SIGs sponsoring it so let's not make a big drama of this Now, from the SIG Network hat, what is the role of SIG Network here? and as Dan correctly pointed out, we already have another WG on this area and a proposal for a new WG #8519 (comment) So, if you say SIG Network has a role here because of foo and does not intersect with any of the other WG then it is ok .... BUT at one point WGs want their things to get done and then go to the SIGs ... and I really want to avoid that in SIG Network we need to deal with conflicts of interest between WGs, because that burns people and breaks communities, people that get frustrated because they were working on the WG with one goal and people that has to say no or has to choose between competing implementation ... this mean that we didn't do our work as leads on reviewing the WG proposal, that is what we should do here, be objective and talk and discuss and agree and review thoroughly for the best of the project ... There was a problem hiding this comment. I just dropped SIG Network from the list. I would leave it up to sig-network leads if/how they engage with the WG. Thanks! |
||
|
|
||
| ## Roles and Organization Management | ||
|
|
||
| This working group adheres to the Roles and Organization Management outlined in | ||
| [wg-governance] and opts-in to updates and modifications to [wg-governance]. | ||
|
|
||
| ## Exit Criteria | ||
|
|
||
| The WG is done if/when a shared recommendation is in place for how the Kubernetes | ||
| project should or should not integrate with these emergent systems. This could | ||
| include a recommendation for Kubernetes to adopt and/or evolve tools (e.g. MCP | ||
| connectors, benchmark or environment validation tooling, etc.) and evolve its | ||
| own governance model to provide proper stewardship within the project or outside. | ||
|
|
||
| The working group will disband when the KEPs resulting from these discussions | ||
| have reached a terminal state. When the core functionality for AI workload | ||
| management reaches GA, we will evaluate whether the working group should | ||
| be disbanded and any remaining KEPs be left to the management of their owning | ||
| SIGs. | ||
|
|
||
| [wg-governance]: https://github.com/kubernetes/community/blob/master/committee-steering/governance/wg-governance.md | ||
| [Kubernetes Charter README]: https://github.com/kubernetes/community/blob/master/committee-steering/governance/README.md | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're missing:
section filled in, and the actual liaison appointed. I'll sync with the rest of the steering and will return with a name to put here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added with TBD, thanks!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mrunalp You can add me as the liaison of this workgroup.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@pacoxu I have added you as liaison. Thanks :) cc: @soltysh