wip: Windows containerd support

[PatrickLang]

Reason for Change:
Once completed, this will install ContainerD and configure Kubernetes to use it on Windows

Requirements:

• uses conventional commit messages
• includes documentation
• adds unit tests
• tested upgrade from previous version

Notes:
/hold do-not-merge

[PatrickLang]

This is going to be open a few days or more. My goal is to get the PR open early with the changes that could break Linux or fail unit tests and let the CI system find those issues. Meanwhile, I still have a lot of work to do in the Windows setup steps that aren't covered in those tests.

[codecov]

Codecov Report

Merging #1322 into master will increase coverage by <.01%.
The diff coverage is 76%.

@@            Coverage Diff             @@
##           master    #1322      +/-   ##
==========================================
+ Coverage   72.47%   72.47%   +<.01%     
==========================================
  Files         140      140              
  Lines       25589    25612      +23     
==========================================
+ Hits        18545    18562      +17     
- Misses       5976     5981       +5     
- Partials     1068     1069       +1

[PatrickLang]

This may not even build right now - did a few hours of work on a plane and then --force-with-lease

🤠

[stale]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[acs-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: PatrickLang

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [PatrickLang]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[stale]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[PatrickLang]

ok, another day, another rebase + squash with a commit amend to appease Semantic Pull Request

[PatrickLang]

/hold cancel

Ready for review. It's not done, but it builds clusters.

next steps (not in any order):

• Get valid containerd Move Windows nodes to public ContainerD builds #2827 & sdnbridge Move Windows ContainerD CNI plugin to public builds #2828 builds
• Set up test pass in AKS-Engine repo Add multi-OS ContainerD test pass for AKS-Engine #2829
• Create a new Kubernetes job Add AKS-Engine-Windows-ContainerD test pass to testgrid #2830
• Add Azure-CNI build compatible with Windows ContainerD - I'm not sure where to track this yet

[marosset]

Right now it looks like we already have a mix of windows specific settings in both kubernetesConfig (azureCNIURLWindows) and windowsProfile (windowsDockerVersion)...
I don't think we should add this to agentPoolProfile but need to think about kubernetesConfig or windowsProfile

[marosset]

Lets keep it in the kubernetesConfig since it logically fits in with the other config values in there.
If we need more flexibility I think it make more sense to add a per node pool override in the agentPoolProfile but that can come later.

[marosset]

And we should maybe consider moving the WindowsDockerVersion out of windowsProfile to kubernetesConfig too (and document that flag in clusterdefintions.md)

[marosset]

I don't think we should change this now but i'm curious if you think these belong here or under the WindowsProfile long-term?

[PatrickLang]

a bit of history - this codebase originally supported mesos and docker swarm too, so the container runtime version existed before kubernetesConfig.

I do think these may should have a cluster-wide default, but with a per-agentpool override. All of them happen to be in kubernetesConfig

• containerRuntime
• runtime version (containerdVersion / mobyVersion)
• kubeletConfig

So getting back to an answer - I'd consider moving them from kubernetesConfig to an agent pool setting as a group in the future for consistency, not just a single setting

[marosset]

/lgtm
Looks good for the state we are currently targeting :)