Microsoft Open Source Blog 
As more users take advantage of Kubernetes for their Windows applications, the Windows community in Kubernetes has been working on improvements that enable even more use cases.
With the release of Kubernetes v1.18, many of these changes are taking shape. In addition to the typical enrichment of testing, which makes every Kubernetes release more robust, the community has enabled Container Storage Interface (CSI) drivers on Windows, graduated features like GMSA and RunAsUsername, introduced experimental support for ContainerD as the container runtime, and more. Read on for more details on these improvements and get a glimpse into future work.
Please join us in the SIG Windows community, which meets Tuesdays at 9:30am PST, or on slack.
Improvements with this release
With the release of Kubernetes v1.18, an alpha version of the CSI Proxy for Windows enables the use of CSI drivers on Windows hosts. CSI (docs, spec) allows storage providers to deliver a common driver that will work across multiple container orchestrators, such as Kubernetes and Docker Swarm.
Until now, our users could not take advantage of the CSI interface because of a dependency on privileged containers, which are not yet supported on Windows. The proxy approach works by allowing pre-approved containers to connect to a host-based proxy, which then manages the connection and takes required actions on host-connected storage. Using a domain-specific proxy can provide significant advantages over a generalized privileged container by enabling targeted capability without requiring privileged containers. Give this a try on Azure using aks-engine to configure your Windows node with CSI Proxy connecting to Azure Disk. Read more about this feature on the Kubernetes blog.
Before this release, Docker was the only supported container runtime for Windows. With this release, the Windows community has taken the initial steps to add ContainerD support. The initial implementation is alpha and will allow the Windows SIG to build test coverage and gather feedback from users. We invite you to experiment with it using aks-engine and provide your feedback to the SIG in the #sig-windows slack channel. You can learn more about the goals and stages of development by reading the Kubernetes Enhancement Proposal (KEP).
Kubeadm is becoming the de facto standard for users to deploy Kubernetes clusters. Kubeadm support for Windows has added the ability to set kubelet flags on Windows and in documentation and tests to bring it to beta in Kubernetes v1.18.
In Kubernetes release v1.15, support for Windows Group Managed Service Accounts (GMSA) was introduced as an alpha feature. GMSA enables your Windows containers to operate more securely at scale by eliminating manual password management.
This feature is used heavily in many .NET applications and its support in Kubernetes simplifies migration to the cloud. The adoption and maturity of the feature in Kubernetes warranted graduation from beta to stable with the release of v1.18, so you can have confidence it will be supported for many releases to come without changes to the API.
Likewise, Windows RunAsUserName, the Windows equivalent to RunAsUser for Linux, has proven itself over the past two releases and is now graduating from beta to stable.
A couple of other notable issues that our users have run into are also fixed in Kubernetes v1.18. First, up until the most recent releases, CPU resource limits have not been correctly respected for Windows (issue). This has been fixed and now resource limits should better reflect expectations. Second, some users ran into a problem with the stats latency on Windows (issue), which could cause various cascading problems through collection via Prometheus or metrics-server. The fix should have similar cascading benefits.
Plans for the future
In addition to the community investments in storage through CSI and runtimes with CRI-ContainerD, there is also an effort underway to make mixed OS cluster management better through Cluster API and to smooth out the rough edges for workloads running on mixed OS clusters through RuntimeClass.
Running Windows containers in clusters that also include Linux workers (most of the ones we’ve observed) requires the somewhat confusing use of taints and tolerations. To provide a simpler user experience the Windows community implemented the Kubernetes RuntimeClass for Windows in v1.17, so a pod spec can include an annotation for matching a set of nodes in a cluster that implements that runtime class. In v1.19, this feature will leverage this capability to enable the use of Hyper-V so that older container-based images will be able to run on newer Windows host versions. You can read more about the plans for the Windows RuntimeClass feature in its KEP.
In case you are looking for a managed service experience for all this goodness, know that Kubernetes v1.18 will soon be available in Azure Kubernetes Service.