The Genesis and Purpose of the Resource Management Working Group

## Why do this? Kubernetes covers generic web hosting capabilities very well, so why go through the effort of expanding workload coverage for Kubernetes at all? The fact is that workloads elegantly covered by Kubernetes today, only represent a fraction of the world’s compute usage. We have a tremendous opportunity to safely and methodically expand upon the set of workloads that can run optimally on Kubernetes. To date, there’s demonstrable progress in the areas of expanded workload coverage: - Stateful applications such as Zookeeper, etcd, MySQL, Cassandra, ElasticSearch - Jobs, such as timed events to process the day’s logs or any other batch processing - Machine Learning and compute-bound workload acceleration through Alpha GPU support Collectively, the folks working on Kubernetes are hearing from their customers that we need to go further. Following the tremendous popularity of containers in 2014, industry rhetoric circled around a more modern, container-based, datacenter-level workload orchestrator as folks looked to plan their next architectures. As a consequence, we began advocating for increasing the scope of workloads covered by Kubernetes, from overall concepts to specific features. Our aim is to put control and choice in users hands, helping them move with confidence towards whatever infrastructure strategy they choose. In this advocacy, we quickly found a large group of like-minded companies interested in broadening the types of workloads that Kubernetes can orchestrate. And thus the working group was born. ## Genesis of the Resource Management Working Group After extensive development/feature [discussions](https://docs.google.com/document/d/1p7scsTPzPyouktBFTxu4RhRwW8yUn5Lj7VGY9SaOo-8/edit?ts=5824ee1f) during the Kubernetes Developer Summit 2016 after [CloudNativeCon | KubeCon Seattle](http://events.linuxfoundation.org/events/kubecon/program/schedule), we decided to [formalize](https://groups.google.com/d/msg/kubernetes-dev/Sb0VlXOM8eQ/La3YCe2-CgAJ) our loosely organized group. In January 2017, the Kubernetes _[Resource Management Working Group](https://github.com/kubernetes/community/tree/master/wg-resource-management)_ was formed. This group (led by Derek Carr from Red Hat and Vishnu Kannan from Google) was originally cast as a temporary initiative to provide guidance back to sig-node and sig-scheduling (primarily). However, due to the cross-cutting nature of the goals within the working group, and the depth of [roadmap](https://docs.google.com/spreadsheets/d/1NWarIgtSLsq3izc5wOzV7ItdhDNRd-6oBVawmvs-LGw/edit) quickly uncovered, the Resource Management Working Group became its own entity within the first few months.

The Resource Management Working Group was formed to broaden the types of workloads that Kubernetes can orchestrate, expanding beyond generic web hosting to cover stateful applications, jobs, and machine learning. The group originated after discussions at the Kubernetes Developer Summit 2016 and was formalized in January 2017, initially to guide sig-node and sig-scheduling, but later becoming its own entity due to the scope of its roadmap.