I'm looking for a commonly recommended architecture for deploying Windows self-hosted runners on Kubernetes. From what I can tell, the controller's support for Windows—especially with current runner scale sets—may be limited or require custom configuration. If there isn't a well-supported Kubernetes approach, what alternatives are people using to run Windows-based CI jobs reliably?
2 Answers
The setup isn’t turnkey, particularly if the jobs need Windows containers. One workable design is to run the runner on Linux and use custom container hooks to launch workflow pods on Windows nodes. You have to handle file transfers, path conversion, and other OS differences, but it can be stable once customized.
Windows is supported by the self-hosted runner application, but the controller’s Windows documentation mainly covers its older deployment API. That requires Windows worker nodes and a custom Windows runner image. For newer runner scale sets, Windows support should be treated as something you operate yourself rather than a standard reference architecture. If Kubernetes isn’t mandatory, Windows VMs are the cleaner supported boundary. Another option is to use the scale-set client for registration and autoscaling while managing the Windows infrastructure independently.
Do you know of any public documentation or a reference design for that approach? I’d especially like to understand the file-copying and path-rewriting pieces.