Use cases for Windows containers with hyper-v isolation

[fady-azmy-msft]

We are evaluating the priority of enabling Windows Hyper-v containers support in Kubernetes, and would like to hear from you.

What use cases do you have for Windows hyper-v containers in Kubernetes? What sort of applications do you want to run?

[doctorpangloss]

• better security for

  • ci/cd
  • if it were supported, sharing the directx display adapter aka for running graphics applications

• making it possible to schedule LCOW containers via hyper-v would reduce a lot of toil, even if it were resource intensive

[fady-azmy-msft]

I see. @doctorpangloss can you expand on the better security need for CI/CD? How would you view the need for better security vs using more resources?

[doctorpangloss]

@doctorpangloss can you expand on the better security need for CI/CD? How would you view the need for better security vs using more resources?

Regarding CI/CD,

• I value the ability to easily schedule, maintain and author workloads in Kubernetes over better node efficiency / performance.
• I build untrusted (third party or customer) code in Tekton pipelines on Windows
• for some applications, I am running untrusted Python code (third party) that wants to access the GPU.

hyper-v to me could replace gvisor for my linux tasks. using more resources is okay because the workloads are ephemeral.

[fady-azmy-msft]

Super helpful! When would you consider hyper-v over gvisor for linux tasks? And what sort of GPU tasks would you run on Windows containers?

[doctorpangloss]

When would you consider hyper-v over gvisor for linux tasks?

I wrote that poorly. I don't consider hyper-v an alternative to gvisor. But for all the code that isn't written by me, hyper-v plays the same role for Windows applications as gvisor does for linux. So having a container runtime option in kubernetes that selects hyper-v would be great.

And what sort of GPU tasks would you run on Windows containers?

Here is an example of a GPU task running on Windows containers: https://appmana.com/watch/virtualtestdrive (tap drive and have fun) - trusted code games, rendering backends like After Effects with Windows-only plugins, running tests for Windows-destined AI applications like ComfyUI

making it possible to schedule LCOW containers via hyper-v would reduce a lot of toil, even if it were resource intensive

to expand on this, the MVP could be kubelet running correctly in a Windows-deployed host process container daemonset. Many people already use kubevirt to sort of do the opposite, running Windows workloads on Linux. To me, the whole point of Windows is the graphics stack and pre-existing Windows only application ecosystem, which is very graphics oriented in terms of stuff that makes sense to run in the backend.

[Nova-Logic]

@fady-azmy-msft I hope the most important use-case is better stability and compatibility, because it would provide a safe way to patch hosts and containers without relying on being on same patches. At this moment we faced a bug on host that was introduced in previous month updates, that still is not fixed. Our main goal of running windows containers: to run asp.net framework(4.5) containers

[microsoft-github-policy-service[bot]]

This issue has been open for 30 days with no updates. @ritikaguptams, @fady-azmy-msft, please provide an update or close this issue.

[microsoft-github-policy-service[bot]]

This issue has been open for 30 days with no updates. @ritikaguptams, please provide an update or close this issue.

[microsoft-github-policy-service[bot]]

This issue has been open for 30 days with no updates. @ritikaguptams, please provide an update or close this issue.