Kubernetes Windows nodes

When Kubernetes Windows nodes make sense for your workloads

Windows nodes let a Kubernetes cluster schedule Windows containers next to Linux workloads, so a Windows Server application can share the same deployment, service discovery and monitoring model as the rest of the platform. Teams usually need them when they run .NET Framework or other Windows-dependent applications that cannot move to Linux without a substantial rewrite, and when keeping those systems on separate infrastructure has become costly to operate. If your applications already run on Linux, or can be ported on a timeline you control, Windows nodes may add more operating surface than they remove. Start with an inventory of which applications must stay on Windows and the specific reason for each one.

The control plane stays on Linux. The API server, scheduler, controller manager and etcd run on Linux machines, and Windows machines join the cluster as worker nodes. A Windows node runs only Windows containers, so a Linux-only sidecar, init container or DaemonSet cannot be placed on it unless a Windows-compatible image exists for that component. Your cluster will therefore need both operating systems in its node pools, and every workload must declare where it runs. Before you choose a target Kubernetes version, confirm in the official Kubernetes Windows documentation which Kubernetes versions and Windows Server releases are supported, because that support has changed across releases.

Adding Windows nodes is a design decision, not a single switch. Plan the network plugin, storage drivers, ingress, log and metrics collection and the image build pipeline with Windows in mind, because many Linux-oriented components either lack Windows builds or behave differently on Windows. Decide which namespaces and node pools host Windows work, how node selectors and taints keep Linux pods off Windows nodes, and who owns Windows patching, base image rebuilds and node replacement. Ask every platform vendor and add-on maintainer in your stack whether its component supports Windows nodes and which features are missing on that platform before you commit.

Answer four questions before you build. Which applications truly require Windows? Can their dependencies, such as databases, identity providers and file shares, be reached reliably from Windows nodes? What operating skills does your team have for Windows Server, including authentication, certificates and patch management? And what support path applies to the Kubernetes version you select? Ask for a written scope that covers these items. Effort and cost depend on the number of applications, their dependencies and the number of Windows images you must build and maintain, so a quote should separate design, build, validation and ongoing patching as distinct line items.

Which Windows node pattern fits each workload

This table compares the main Windows node patterns, the workloads each one suits, and the operational effort each adds. Read the fit column first, then the effort column to see what your team would own. Version support for Windows Server, container runtimes and HostProcess features is not stated here, so confirm it in the Kubernetes documentation and with your vendor before you choose.

Option	When it fits	Effort and what to confirm
Dedicated Windows node pool	Most workloads are Windows-only, and the platform team wants Windows node images, patching and scaling managed separately from Linux.	Separate node image and patch cycle, plus separate monitoring agents. Confirm supported Windows Server and kubelet combinations in the Kubernetes Windows documentation.
Mixed cluster with node selectors and taints	A few Windows workloads share a cluster with Linux services, and one platform team manages both.	Linux pods must avoid Windows taints or tolerate them deliberately. Enforce placement with admission rules. Confirm OS label and taint behavior in the docs.
Windows containers for ordinary applications	Applications run on Windows userspace and need no node-level access, such as IIS sites or .NET Framework services.	The image base must match the node's Windows version. Confirm base image compatibility rules and the vendor's support statement for your application.
HostProcess containers for node tasks	Agents, log collectors and node configuration tasks that need host access, used in place of privileged pods.	Needs tight RBAC and Pod Security review. Confirm the Kubernetes version and maturity of HostProcess, and whether your agent vendor supports it.
Move the workload to Linux	The app is portable across operating systems, such as modern .NET, Java, Go or Node.js, with no Windows-only APIs.	Rebuild images and retest. Check for registry, COM, GDI, Active Directory and driver dependencies first. Retire Windows nodes once they are empty.
Keep the workload on Windows	The app depends on Windows-only APIs, .NET Framework, Windows drivers or vendor software that has no Linux build.	Ongoing Windows node lifecycle, licensing and patching. Ask the vendor in writing whether containers and Kubernetes scheduling are supported.

How a Linux control plane schedules work onto Windows nodes

The control plane runs on Linux, and Windows nodes only run workloads. The API server, scheduler, controller manager and etcd stay on Linux hosts in a mixed cluster, and the Windows worker nodes run Windows containers under a kubelet that registers with that Linux control plane. Plan the cluster around that split from the start. Your Linux nodes handle control plane duties and any Linux workloads, while Windows nodes handle only the workloads that need Windows. Confirm which Kubernetes minor version and which Windows Server release your chosen distribution supports before you size either pool, because the Windows support matrix varies by release and the version skew rules still apply to every kubelet you add.

The scheduler decides where each pod lands, so placement rules are the main control you have over Windows workloads. Node labels identify Windows nodes, and the kubelet sets an operating system label on each node that you can confirm in your own cluster. Node selectors and node affinity then steer Windows pods to those nodes. Taints go the other way: a taint on Windows nodes keeps Linux pods off them unless a pod carries a matching toleration. Use both directions. A selector without a taint still lets Linux pods land on Windows nodes if they are unconstrained, and a taint without a selector leaves Windows pods unable to find a home. Write these rules into your deployment templates and admission policies so that a missing selector is caught before a pod is scheduled.

The Linux control plane needs the same design work as any production cluster, and Windows nodes add pressure to it. Run at least three control plane nodes behind a TCP load balancer on port 6443 in front of kube-apiserver, so that losing one control plane node does not stop scheduling for the Windows pool. Choose between a stacked etcd layout and an external etcd cluster before the first node joins. etcd should run with an odd number of members, and Kubernetes documentation recommends five members for production. Back up etcd on a schedule you have tested, because every placement decision, label and taint your Windows nodes depend on is stored there. The High Availability and etcd planning in the Kubernetes pillar covers these steps in detail.

Cluster add-ons are the most common source of Windows failures, and each one must be checked for Windows support before deployment. Networking, storage and monitoring components often ship as DaemonSets that assume Linux, so a Linux-only agent can crash-loop on every Windows node and consume scheduling capacity. For each add-on, confirm three things with its vendor: that it publishes Windows images, that it supports the Windows Server release and container runtime you plan to use, and that its chart or manifest can exclude Windows nodes where it is not supported. Record the result in a support matrix that your team reviews at each Kubernetes upgrade, since add-on support changes independently of the Kubernetes release schedule.

Why HostProcess containers replace privileged pods for Windows node tasks

HostProcess containers let a Windows node agent run with host access without the privileged pod model used on Linux nodes. That access is still host access, so the platform team must scope it, control who can create it, and review it like other node-level software. The five controls below are the ones to own before any agent is approved.

Scope host access for each agent

A HostProcess container runs in the host process context rather than inside a pod sandbox, so an agent using it can reach host resources that an ordinary container cannot. Before approval, list each agent, the host resources it touches and the identity it runs under. Treat every entry as code with node-level authority, and retire any agent whose purpose no longer needs that access.

Restrict who can create HostProcess pods

Creating a pod, or a workload object such as a DaemonSet or Deployment that generates pods, is the step that grants host access, so RBAC must govern those verbs as well as direct pod creation. Limit create and update rights to a small platform group and review role bindings on a fixed schedule. Confirm that no broad cluster role, wildcard rule or inherited group grants the same rights.

Set namespace Pod Security levels

Pod Security Admission applies one of three standards per namespace: Privileged, Baseline or Restricted, in enforce, audit or warn mode. Place node agents in a dedicated, labeled namespace and keep enforce on every namespace that must not run them. Test changes in warn and audit mode first, then confirm in the current Pod Security Standards documentation how HostProcess fields are evaluated at each level for your Kubernetes version.

Verify Windows image provenance

Node agents packaged as Windows container images carry the same supply chain risk as any host software, and they hold more reach than most workloads. Pull images from a private registry you control, pin them by digest, and verify signatures or build attestations before admission. Match each image's Windows base to the node OS build, because a mismatch often surfaces only at runtime.

Confirm current Windows security guidance

Windows-specific security behavior in Kubernetes can change between releases, so guidance written for an older cluster may not describe your nodes. Before sign-off, read the Windows security section of the Kubernetes documentation for your exact minor version and note which HostProcess settings it covers. Map the results to your CIS Kubernetes Benchmark review, then record any gaps as accepted risks with a named owner.

How to add a Windows node to a self-managed cluster

This sequence takes a Windows Server host from version checks to a verified test workload that reaches Linux services and DNS in a self-managed cluster. Each step ends with a check you can run, so problems surface before the next layer is added. Where your distribution provides its own installation path, follow that path and keep the same checks.

Confirm version compatibility before any install
Confirm the Kubernetes minor version, the Windows Server build and the container runtime against the official Kubernetes documentation for Windows nodes, and record each pairing. Check the Linux control plane version as well, because kubelet support follows the version skew policy for your cluster. Confirm that your CNI plugin and your distribution support Windows nodes at all. Platform leads usually own this decision, and a partner typically reviews it during planning. Done when you have a written version matrix and a named installation procedure approved by the owners of the cluster and the Windows hosts.
Prepare the Windows host and container runtime
Install the Windows Server build chosen in the previous step, with the patches, drivers and network settings your data center requires. Join the host to your directory domain if your policy calls for it. Install the container runtime that the compatibility documentation names for that build, and point it at your private image registry. The Windows administration team usually performs this work, and the platform team validates it. Check that the runtime service starts automatically, that the host can pull a Windows base image from your registry, and that a throwaway container starts and stops cleanly.
Join the node with kubeadm or your distribution
Install the kubelet and kube-proxy versions from your version matrix on the Windows host, then join the node to the cluster. If you build with kubeadm, follow the Windows join procedure in the kubeadm documentation for your release. Many distributions package the Windows components, supply their own join scripts or require an agent, so use the vendor procedure and treat upstream steps as a reference. Check that the kubelet service runs and that the node object appears in the cluster. Confirm the node reaches Ready within the time your procedure describes.
Confirm labels, taints and node readiness
Inspect the node object and confirm the operating system label that the join procedure set. Most Windows scheduling relies on the standard operating system label, but confirm the exact key and value in the documentation for your version. Record any taint on the node, because your test workload must tolerate it. Add site labels your scheduling model needs, such as a pool name for each Windows build. Check that the node description shows the expected labels, that the taints match your record and that the Ready condition is true.
Deploy a test Windows workload with a node selector
Create a minimal test deployment that uses a Windows image from your private registry, with a node selector on the operating system label and a toleration if the node carries a taint. Match the image build to the host build, because mismatched builds fail to start. Keep the manifest free of privileged settings and avoid pod fields that Windows does not support. Check that the pod reaches Running on the Windows node, that its logs show the expected output and that the pod description shows no scheduling or admission errors. Keep the test resources in a dedicated namespace until the networking checks pass.
Verify pod networking and DNS to Linux services
From the Windows test pod, reach a Linux service you already run by its cluster IP and by its DNS name. Then reach a pod on a Linux node to test the cross-platform pod network. Confirm that the Windows pod receives an address from the range your CNI plugin assigns, and that name resolution returns the service address through cluster DNS. If you plan to enforce network policy on Windows, confirm support with your distribution before testing it. Check that each connection and lookup succeeds, then record the results as the baseline for your runbook.

Which pod fields Windows does not support and how to find them

Several Linux-oriented pod and container fields either have no Windows equivalent or behave differently on Windows nodes, so every manifest that will move to a Windows node pool needs an audit before migration. The problem is rarely the workload author's intent. Security contexts, host namespace settings and volume types are often inherited from Helm charts, operator defaults or copied templates written for Linux nodes. An unsupported field may cause a pod to be rejected or stay pending, while a field that is accepted but ignored can quietly remove a control the team assumed was in place. Both outcomes should be found before cutover.

Start by inventorying what the cluster actually runs. Export the pod templates from every namespace that will be affected, including pods created by Helm releases, operators and DaemonSets. Collect each field set under the pod-level and container-level security context, along with host namespace settings (hostNetwork, hostPID and hostIPC), hostPath volumes, sysctls, and any node selectors or tolerations that assume Linux. A short script over the exported YAML is usually enough for a first pass. Then check each field against the Windows section of the Kubernetes documentation for the exact release you plan to run. For every field, record a result such as supported, supported with different behavior, unsupported or ignored, and store the release number beside it, because the list changes between releases.

Test the findings in a non-production cluster that uses a Windows node pool built from the same OS version as production. Deploy one representative workload from each category in the inventory and watch for three signals: admission rejections, pods that stay pending or fail to start, and settings that are accepted but have no effect. The third signal is the one teams most often miss. Do not stop at confirming that a pod was created. Inspect the running container and confirm that the expected user identity, file access and restrictions are actually in place. Record each test result against the audit row it covers, so the same evidence can later support a change record or a compliance review.

Expect the security settings and Linux capabilities to need the most rework. Controls that depend on Linux kernel features, such as capability sets, seccomp profiles and sysctl tuning, usually need a Windows-appropriate replacement, a change to the workload design, or a documented decision to accept a different control. Where a workload needs node-level access, review whether a HostProcess container is justified, since it runs with host privileges and needs its own review. Map every removed or replaced control to the requirement it served, so the security baseline and the evidence shown to auditors still describe the cluster accurately. Ask your Kubernetes distribution vendor and the Windows documentation which fields your release supports, and confirm the exact list against that release before the audit is signed off.

What to confirm in your environment before you commit

Before you choose a Windows node design, confirm five dependencies that the cluster cannot work around later. Each answer comes from a vendor, the Kubernetes documentation or your own environment, and each one changes the node pool layout, image pipeline, identity setup or cost model.

Windows Server build and runtime support

Each Windows node runs one Windows Server build and one container runtime, and container images must match that build. Ask your Kubernetes distribution vendor which Windows Server builds and runtimes it supports for the minor version you plan to run, then cross-check the Kubernetes documentation for that same version. The answer sets your OS release pipeline, your base image choices and how often you can patch nodes without rebuilding images.

Windows builds of add-on components

Every network plugin, storage driver and monitoring agent that runs on your nodes needs a Windows build, or it will not run on Windows workers. Check each project's documentation and release notes for Windows support on your Kubernetes version, then prove it in a test cluster with a Windows node. Gaps here force split DaemonSets, extra node selectors or a separate monitoring path for Windows, which changes both operations and support scope.

GPU, Active Directory and gMSA needs

Confirm whether the application uses GPUs, Active Directory authentication or group managed service accounts (gMSA). Ask the application owner and your identity team, and ask your hardware vendor which GPUs and drivers work with Windows containers. Each need changes the design: GPUs usually call for a dedicated node pool, while AD and gMSA require domain join and network paths from nodes to domain controllers, plus identity setup that happens outside Kubernetes.

Windows Server licensing for hosts

Ask your licensing advisor and your cloud or data center provider how Windows Server is licensed for the hosts that will run your Windows nodes. Virtual machine licensing, bring-your-own-license eligibility and whether the terms count cores or hosts all vary by agreement and provider, so get the answers in writing. The result drives node sizing, the number of Windows nodes you can justify, and whether your existing agreements cover the nodes you plan to run.

Pod fields Windows does not support

Windows nodes do not support every pod spec field that Linux nodes do, and some Linux security settings have no Windows equivalent. Review the Kubernetes documentation for your version and list every field your manifests and Helm charts set, including security context settings. Work that needs privileged host access should move to HostProcess containers, which need their own review for access rights, image provenance and rollout.

How upgrades and version skew affect Windows nodes

The version skew policy sets the order of every Windows node upgrade. Upgrade kube-apiserver first, one minor version at a time, then kube-controller-manager and kube-scheduler, and then kubelets. Kubelets may be up to three minor versions older than kube-apiserver, so a Windows node pool can lag the control plane without breaking the cluster. Treat that allowance as the outer limit of your plan and set the actual schedule earlier. Before any Windows kubelet moves, confirm that the target control plane version is supported by your Windows node images and container runtime.

Windows nodes often run on a different schedule from Linux nodes. The Windows Server host image is patched and replaced on its own lifecycle, and your team may approve and test those images through a separate process. Plan Windows node pools as their own upgrade track, sequenced after the control plane and within the skew window. Ask your distribution whether its upgrade tooling manages Windows node pools or only Linux pools. Confirm which Windows Server builds each Kubernetes minor supports in the Kubernetes Windows node documentation before you set dates.

Drain and replace is the pattern most teams use for Windows nodes. Cordon a node so no new pods schedule there, drain its workloads, then remove the node and join a replacement built from the new image. Check that PodDisruptionBudgets exist for stateful and multi-replica Windows workloads, because drain respects them and a missing budget can let every replica leave at once. Confirm how DaemonSets, including node-level agents, behave during drain, and whether any HostProcess workloads need separate handling. Record the node order and drain timeouts so the rollout can be paused and resumed.

Test Windows workloads on each Kubernetes minor release before the upgrade reaches production. A test cluster should match production in Windows Server build, container runtime version, and the CNI and CSI plugins that support Windows nodes. Run your own Windows images with the same startup behavior, storage mounts, network policies and health probes you use in production. Record which Kubernetes minor and Windows build each image was tested against, so the next upgrade starts from a known result. Confirm with each plugin vendor that its release supports both the target minor and Windows nodes.

Current support windows set the deadline for each upgrade. As of September 2026, the Kubernetes project maintains 1.37, which reaches end of life on October 28, 2027, 1.36, which reaches end of life on June 28, 2027, and 1.35, which reaches end of life on February 28, 2027, according to the Kubernetes releases page. Patch support for 1.19 and newer runs about one year, roughly 14 months including the pre-release period. A new minor release arrives about every 14 weeks, so check the releases page at planning time and schedule each move off a version before its end-of-life date.

What Windows node work costs and what it needs from your team

What drives the cost of Kubernetes Windows node work?

The main drivers are the number of Windows applications, the pod field audit, add-on compatibility, identity needs and operational runbooks. Applications set the test matrix, since each one may depend on Windows features, drivers or service accounts that need checking. The pod field audit finds specs that use fields Windows nodes do not support, and each affected workload may need redesign. Add-ons such as network plugins, storage drivers, monitoring agents and security tools may not all run on Windows, which adds evaluation work. Identity decides how Windows workloads authenticate to directories and file shares, and runbooks decide how much procedure your team needs before go-live. A short application list with few Linux-only dependencies generally narrows the work.

Which parts of Windows node work are one-time and which recur?

One-time work covers design, workload migration, testing and the first runbooks. Design sets node pools, networking, the container runtime and where HostProcess containers replace privileged pods. Migration moves each application and checks its pod spec against Windows limits. Testing covers functional checks, failover and upgrade rehearsals. Recurring work covers patching Windows hosts and node images, keeping the control plane and kubelets within the supported version skew, and monitoring node health and capacity. Kubernetes allows kubelets to be up to three minor versions older than kube-apiserver, so Windows node upgrades still need a schedule that stays inside that window. Ask each partner to split its quote into one-time and recurring lines so the ongoing cost is visible before you sign.

What does our team need to provide before Windows node work starts?

DeployOpen works inside your cloud accounts, data centers or air-gapped networks, so it needs controlled access. Typical inputs include access to the cluster with rights to inspect nodes and workloads, the Windows host images or the build pipeline that produces them, and named application owners who can explain each workload and sign off tests. Test data matters: representative datasets or safe copies let teams verify behavior before cutover. Your team also supplies change windows, a contact for security approvals and access to the directory, monitoring and logging systems the nodes must join. Confirm each item in the written scope, including who owns the Windows image source and who approves node changes. Missing owners are a common source of delay.

Can our internal platform team run Windows nodes without outside help?

Often yes, when the team already runs Linux Kubernetes well and has Windows Server administration skills. The gaps tend to be the pod field audit, Windows-specific container images, HostProcess security settings, Windows-capable monitoring and the first upgrade cycle, where node-by-node sequencing is new. Test this honestly with a short list of questions: who patches Windows images each month, who reads Windows node events, and who can rebuild a node from a clean image. If the answers are unclear, the work is a skills gap as well as a project. A partner can cover the design and first migration while your team takes over operations through documented runbooks, and those runbooks should be agreed in the written scope.

What should we ask for in a written scope for Windows nodes?

A written scope should name the Windows applications, their versions and owners, and the Kubernetes release and Windows Server versions in use. Ask for the pod field audit method and the format of its results, the add-on compatibility review, the identity design, the runbooks and the handover plan. Require acceptance tests tied to each application, a list of exclusions and a change process for scope changes. DeployOpen engagements are fixed-scope: scope, deliverables and timelines are agreed in writing before work starts, and a quote follows from that written scope. Compare proposals on how completely they state these items, and then on the total.

Does a fixed-scope engagement include ongoing Windows node support?

No. A fixed-scope engagement covers the agreed deliverables, and ongoing support, upgrades and continuous testing are available as retainers that are scoped separately. Ask what a retainer covers for Windows nodes: image patching, Kubernetes upgrade rehearsals, monitoring review and response expectations. Ask whether the handover includes runbooks your team can execute without a partner on call. Decide early whether the first year runs on your team, under a retainer or as a mix, because that choice sets the recurring cost line in your budget. Make sure the project scope and any retainer do not overlap on the same tasks, so each piece of work is paid for once and owned by one party.

How do we confirm Windows support for our Kubernetes version?

Start with the Kubernetes release you run and the Windows Server versions your distribution documents. Kubernetes maintains the three most recent minor releases, and as of September 2026 these were 1.37 (end of life October 28, 2027), 1.36 (June 28, 2027) and 1.35 (February 28, 2027). Windows support depends on the distribution and container runtime, so confirm the exact pairing with the vendor and in the Kubernetes documentation for your version. Plan Windows node upgrades around the end of life dates of your current release. Write the confirmed support matrix into the scope so the design rests on documented support.

How DeployOpen scopes and delivers Windows node work

DeployOpen plans and builds Windows node support for Kubernetes inside infrastructure you control, with the Linux control plane, node images and workload rules designed together. Engagements are fixed-scope, so the supported Windows versions, runtimes and pod constraints are agreed in writing before any build work starts.

How we scope

Written scope lists the Windows Server versions and container runtimes you intend to run.
Workload inventory maps each application to Windows or Linux nodes and identifies unsupported pod fields.
Scope names which HostProcess containers replace privileged pods, and which need a redesign first.

How we build

Linux control plane and Windows node pools are provisioned in your accounts or data centers, with networking agreed first.
Node images, container runtime and kubelet settings are built and documented before workloads move in.
Windows-specific scheduling rules, such as node selectors and taints, are tested against sample workloads.

How we hand over

Handover includes architecture notes, runbooks for node joins, drains and image updates.
Test evidence shows scheduling, pod networking and HostProcess workloads behaving as the scope describes.
Your team receives configuration in your repositories, so changes stay under your own change control.

How we support

Ongoing support for Windows nodes can run as a retainer, with coverage agreed in writing up front.
Upgrades follow the Kubernetes version skew policy, with control plane upgraded before kubelets on Windows nodes.
Support scope re-checks Windows version and runtime support at each upgrade plan.