Clarify and document Windows OS version support

[marosset]

This issue will be used to facilitate discussion around clarifying/documents Windows OS version support and will result in documentation PRs reflecting the outcomes of this discussion.

Current Kubernetes documentation only claims to support Windows Server 2019 (https://kubernetes.io/docs/setup/production-environment/windows/intro-windows-in-kubernetes/#compute) but there have been several Windows Server SAC releases since then which have offer Windows container enhancements that may not be feasible to backport to Windows Server 2019.

More info on Windows Server LTSC vs SAC releases can be found at https://docs.microsoft.com/en-us/windows-server/get-started-19/servicing-channels-19

Proposal

OS Version support

• Commit to supporting latest Windows Server LTSC release and 1-2 latest Windows SAC releases.

Support Commitment (from SIG-Windows)

• Provide e2e/conformance testing of Windows workloads running on all supported Windows OS nodes
• Maintain test container images for all supported Windows OS versions
• Provide publicly hosted infrastructure container images (ex: pause image) for all supported Windows OS

/sig windows

[marosset]

/cc @michmike @craiglpeters @immuzz @pjh @adelina-t @claudiubelu
Let's continue the conversation from today's sig-windows meeting here

[immuzz]

I think supporting LTSC + 2 SAC releases makes sense as long as we have added the e2e conformance tests for it. We will need to know how long it takes to add the tests for a new version.

[pjh]

Would it be feasible for every K8s version to support just one LTSC version and just one SAC version? For example, for the rest of this year it might look something like:

• K8s 1.18: 2019 for LTSC, 1903 or 1909 for SAC (not sure if we officially decided this...)
• K8s 1.19: 2019 for LTSC, 20-04 for SAC
• K8s 1.20: 2019 for LTSC, 20-04 for SAC
• K8s 1.21: 2019 for LTSC, 20-10 for SAC

A 1:1 mapping from K8s versions to SAC versions would be straightforward and would limit SIG-Windows' test + maintenance burden. One argument against this proposal is that the SAC versions would update too rapidly for users or even for SIG-Windows to keep up, but I'd argue that if this cadence is too fast then one shouldn't be using SAC in the first place.

In terms of the support requirements that @marosset listed, the first one "Provide e2e/conformance testing..." would be pretty manageable - Azure and GCE make new SAC releases available with little delay, and updating the test jobs to target new Windows releases requires just a straightforward code + config change.

The second two requirements, updating the test container images and the infrastructure container images, seem more burdensome to perform every time a new SAC release comes out. @claudiubelu and @adelina-t can share more thoughts.

[adelina-t]

It shouldn't be difficult to create the test container images, especially with the work that @claudiubelu has done with the image promoter it should be reasonably pain free to create different versions for images. @claudiubelu thoughts?

[claudiubelu]

Indeed, it's quite easy to build the test images now, especially due to several changes we've managed to get in (for example, the Agnhost Image Centralization PRs, which cumulatively reduced the the image count by 20+). This can still be an issue if we have to rebuild every single image that is used across all the supported Kubernetes versions, like we had to do because of the February Updates.

From our perspective, it's pretty straight-forward to add support for a new OS Version in the e2e test images. For that, we would only have to:

• Create and configure a new Windows Build node with that OS Version + Remote Docker enabled (which is described in test/images/README.MD)
• add an windows/amd64/OS_VERSION for it in the images' BASEIMAGE file.
• build.

As for which OS versions we're supporting and which not, at the moment, we're building for 1809, 1903, and 1909. It'll be a lot easier to track and manage once we merge the following PRs:

#77398
#77269
#89424

which basically adds the Windows support for the needed e2e test images. Then, after they merge, we can change those BASEIMAGE files in accordance to what versions we decide to support that release. Plus, the plan is to have all those images automatically built without our intervention via the Image Promoter.

[marosset]

/assign

[marosset]

Docs have been updated with kubernetes/website#21652
/close

[k8s-ci-robot]

@marosset: Closing this issue.

In response to this:

Docs have been updated with kubernetes/website#21652
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.