Folks from Intel, NVIDIA, Google, IBM, Red Hat. and Microsoft (among others) participated.
You can read the outcomes of that 3-day meeting [here](https://docs.google.com/document/d/13_nk75eItkpbgZOt62In3jj0YuPbGPC_NnvSCHpgvUM/edit).
The group’s prioritized list of features for increasing workload coverage on Kubernetes enumerated in the [charter](https://github.com/kubernetes/community/tree/master/wg-resource-management) of the Resource Management Working group includes:
- Support for performance sensitive workloads (exclusive cores, cpu pinning strategies, NUMA)
- Integrating new hardware devices (GPUs, FPGAs, Infiniband, etc.)
- Improving resource isolation (local storage, hugepages, caches, etc.)
- Improving Quality of Service (performance SLOs)
- Performance benchmarking
- APIs and extensions related to the features mentioned above
The discussions made it clear that there was tremendous overlap between needs for various workloads, and that we ought to de-duplicate requirements, and plumb generically.
## Workload Characteristics
The set of initially targeted use-cases share one or more of the following characteristics:
- Deterministic performance (address long tail latencies)
- Isolation within a single node, as well as within groups of nodes sharing a control plane
- Requirements on advanced hardware and/or software capabilities
- Predictable, reproducible placement: applications need granular guarantees around placement
The Resource Management Working Group is spearheading the feature design and development in support of these workload requirements. Our goal is to provide best practices and patterns for these scenarios.
## Initial Scope
In the months leading up to our recent face-to-face, we had discussed how to safely abstract resources in a way that retains portability and clean user experience, while still meeting application requirements. The working group came away with a multi-release [roadmap](https://docs.google.com/spreadsheets/d/1NWarIgtSLsq3izc5wOzV7ItdhDNRd-6oBVawmvs-LGw/edit) that included 4 short- to mid-term targets with great overlap between target workloads:
- [Device Manager (Plugin) Proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/resource-management/device-plugin.md)
- Kubernetes should provide access to hardware devices such as NICs, GPUs, FPGA, Infiniband and so on.
- [CPU Manager](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/cpu-manager.md)
- Kubernetes should provide a way for users to request static CPU assignment via the Guaranteed QoS tier. No support for NUMA in this phase.
- [HugePages support in Kubernetes](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/resource-management/hugepages.md)
- Kubernetes should provide a way for users to consume huge pages of any size.
- [Resource Class proposal](https://github.com/kubernetes/community/pull/782)
- Kubernetes should implement an abstraction layer (analogous to StorageClasses) for devices other than CPU and memory that allows a user to consume a resource in a portable way. For example, how can a pod request a GPU that has a minimum amount of memory?
## Getting Involved & Summary
Our charter document includes a [Contact Us](https://github.com/kubernetes/community/tree/master/wg-resource-management#contact-us) section with links to our mailing list, Slack channel, and Zoom meetings. Recordings of previous meetings are uploaded to [Youtube](https://www.youtube.com/channel/UCyfvrmhAGcsFlJeGgZQvZ6g). We plan to discuss these topics and more at the 2017 Kubernetes Developer Summit at [CloudNativeCon | KubeCon](http://events.linuxfoundation.org/events/cloudnativecon-and-kubecon-north-america) in Austin. Please come and join one of our meetings (users, customers, software and hardware vendors are all welcome) and contribute to the working group!