Home • Explore • Blog • CI
☰



kubernetes
3rd chunk of `content/en/blog/_posts/2017-08-00-Kubernetes-Meets-High-Performance.md`
b2249e711d604aacad6d8c4b2075c32f194504159198eca00000000100000a06
Sites less invested in existing HPC applications can use existing scheduling facilities in Kubernetes for [jobs that run to completion](/docs/concepts/workloads/controllers/jobs-run-to-completion/). While this is an option, it may be impractical for many HPC users. HPC applications are often either optimized towards massive throughput or large scale parallelism. In both cases startup and teardown latencies have a discriminating impact. Latencies that appear to be acceptable for containerized microservices today would render such applications unable to scale to the required levels.

All of these solutions involve tradeoffs. The first option doesn’t allow resources to be shared (increasing costs) and the second and third options require customers to pick a single scheduler, constraining future flexibility.

## Mixed workloads on Kubernetes

A better approach is to support HPC and container workloads natively in the same shared environment. Ideally, users should see the environment appropriate to their workload or workflow type.

One approach to supporting mixed workloads is to allow Kubernetes and the HPC workload manager to co-exist on the same cluster, throttling resources to avoid conflicts. While simple, this means that neither workload manager can fully utilize the cluster.

Another approach is to use a peer scheduler that coordinates with the Kubernetes scheduler. Navops Command by Univa is a solution that takes this third approach, augmenting the functionality of the Kubernetes scheduler. Navops Command provides its own web interface and CLI and allows additional scheduling policies to be enabled on Kubernetes without impacting the operation of the Kubernetes scheduler and existing containerized applications. Navops Command plugs into the Kubernetes architecture via the 'schedulerName' attribute in the pod spec as a peer scheduler that workloads can choose to use instead of the Kubernetes stock scheduler as shown below.

 ![Screen Shot 2017-08-15 at 9.15.45 AM.png](https://lh6.googleusercontent.com/nKTtfQVVmL4qBoSR0lBmBuLt8KOrVEyjn9YcAu7hrhhV-rwnxRY3p-Y5Qfddf7BI6u1KN85VKfeaaU74xDl-oDk5NzybdIxAp0SJ42x14gwzpmwLwjVy5nIng6K8Ih-bRDlOmA9j)

With this approach, Kubernetes acts as a resource manager, making resources available to a separate HPC scheduler. Cluster administrators can use a visual interface to allocate resources based on policy or simply drag sliders via a web UI to allocate different proportions of the Kubernetes environment to non-container (HPC) workloads, and native Kubernetes applications and services.
Title: Mixed Workloads on Kubernetes: Towards a Shared Environment
Summary
Using Kubernetes scheduling for HPC applications is often impractical due to latency issues. Existing solutions involve tradeoffs like resource sharing and scheduler limitations. A better approach supports HPC and container workloads natively in a shared environment. One method is to have Kubernetes and an HPC workload manager coexist on the same cluster, though neither fully utilizes the cluster. Another approach involves a peer scheduler like Navops Command, which coordinates with the Kubernetes scheduler, allowing additional scheduling policies without impacting existing Kubernetes applications. This makes Kubernetes a resource manager for both containerized and HPC workloads, and administrators can allocate resources via a visual interface.