<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>WG Device Management on Kubernetes Contributors</title><link>https://deploy-preview-846--kubernetes-contributor.netlify.app/community/community-groups/wg/device-management/</link><description>Recent content in WG Device Management on Kubernetes Contributors</description><generator>Hugo</generator><language>en</language><atom:link href="https://deploy-preview-846--kubernetes-contributor.netlify.app/community/community-groups/wg/device-management/index.xml" rel="self" type="application/rss+xml"/><item><title>WG Device Management Charter</title><link>https://deploy-preview-846--kubernetes-contributor.netlify.app/community/community-groups/wg/device-management/charter/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://deploy-preview-846--kubernetes-contributor.netlify.app/community/community-groups/wg/device-management/charter/</guid><description>&lt;h1 id="wg-device-management-charter">WG Device Management Charter&lt;/h1>
&lt;p>This charter adheres to the conventions described in the &lt;a href="https://github.com/kubernetes/community/blob/master/committee-steering/governance/README.md"
 
 target="_blank" rel="noopener">Kubernetes Charter
README&lt;/a>
 and uses the Roles and Organization Management outlined in
&lt;a href="https://github.com/kubernetes/community/blob/master/committee-steering/governance/wg-governance.md"
 
 target="_blank" rel="noopener">wg-governance&lt;/a>
.&lt;/p>
&lt;h2 id="scope">Scope&lt;/h2>
&lt;p>Enable simple and efficient configuration, sharing, and allocation of
accelerators and other specialized devices. This working group focuses on the
APIs, abstractions, and feature designs needed to configure, target, and share
the necessary hardware for both batch and serving (inference) workloads.&lt;/p>
&lt;h3 id="in-scope">In scope&lt;/h3>
&lt;ul>
&lt;li>Enable efficient utilization of specialized hardware devices. This includes
sharing one or more resources effectively (many workloads sharing a pool of
devices), as well as sharing individual devices effectively (several workloads
dividing up a single device for sharing).&lt;/li>
&lt;li>Enable workload authors to specify “just enough” details about their workload
requirements to ensure it runs optimally, without having to understand exactly
how the infrastructure team has provisioned the cluster.&lt;/li>
&lt;li>Enable the scheduler to choose the correct place to run a workload the vast
majority of the time (rejections should be extremely rare).&lt;/li>
&lt;li>Enable cluster autoscalers and other node auto-provisioning components to
predict whether creating additional resources will satisfy workload needs,
before provisioning those resources.&lt;/li>
&lt;li>Enable the shift from “pods run on nodes” to “workloads consume capacity”.
This allows Kubernetes to provision sets of pods on top of sets of nodes and
specialized hardware, while taking into account the relationships between
those infrastructure components.&lt;/li>
&lt;li>Enable in-node devices as well as network-accessible devices.&lt;/li>
&lt;li>Minimize workload disruption due to hardware failures.&lt;/li>
&lt;li>Address fragmentation of accelerator due to fractional use.&lt;/li>
&lt;li>Additional problems that may be identified and deemed in scope as we gather
use cases and requirements from WG Serving, WG Batch, and other stakeholders.&lt;/li>
&lt;li>Address all of the above while with a simple API that is a natural extension
of the existing Kubernetes APIs, and avoids or minimizes any transition
effort.&lt;/li>
&lt;/ul>
&lt;h3 id="out-of-scope">Out of Scope&lt;/h3>
&lt;ul>
&lt;li>Higher-level workload controller APIs (for example, the equivalent of
Deployment, StatefulSet, or DaemonSet) for specific types of workloads.&lt;/li>
&lt;li>General resource management requirements not related to devices.&lt;/li>
&lt;/ul>
&lt;h2 id="deliverables">Deliverables&lt;/h2>
&lt;p>The WG will coordinate the delivery of KEPs and their implementations by the
participating SIGs. Interim artifacts will include documents capturing use
cases, requirements, and designs; however, all of those will eventually result
in KEPs and code owned by SIGs.&lt;/p></description></item></channel></rss>