Project summary
K2s is a lightweight Kubernetes distribution for running mixed Windows and Linux workloads, with strong support for offline and air-gapped environments.
Project description
K2s is a Kubernetes distribution focused on making mixed Windows and Linux workloads practical, repeatable, and easy to operate. It packages Kubernetes and a curated set of open source components into a small, CLI-driven solution that can run on Windows hosts, reusing the Windows host itself as a worker node while running Linux workloads through a compact Linux environment using Hyper-V or WSL.
K2s addresses a gap for organizations that need Kubernetes-native operation for existing Windows applications, on-premises systems, edge environments, regulated environments, or air-gapped deployments. It provides offline installation packages, addon export/import, delta packages for upgrades, diagnostics, cluster lifecycle commands, and optional addons for ingress, monitoring, logging, registry, GitOps rollout, storage, security, GPU support, KubeVirt, and selected domain-specific workloads.
K2s started as an internal Siemens Healthineers project and is now used across different business units.
Org repo URL (provide if all repos under the org are in scope of the application)
N/A
Project repo URL in scope of application
https://github.com/Siemens-Healthineers/K2s
Additional repos in scope of the application
N/A
Website URL
https://siemens-healthineers.github.io/K2s/
Roadmap
https://github.com/Siemens-Healthineers/K2s/blob/main/ROADMAP.md
Roadmap context
The roadmap focuses on maturing K2s as a practical mixed-OS Kubernetes distribution for local, on-premises, edge, and air-gapped environments. Near-term work includes improving the Windows-host variant, maturing the experimental Linux-host variant, strengthening the provider architecture, hardening lifecycle operations, improving offline installation and upgrade workflows, expanding automated test coverage, and keeping the addon catalog practical and curated.
Contributing guide
https://github.com/Siemens-Healthineers/K2s/blob/main/docs/dev-guide/contributing/index.md
Code of Conduct (CoC)
https://github.com/Siemens-Healthineers/K2s/blob/main/CODE_OF_CONDUCT.md
Adopters
https://github.com/Siemens-Healthineers/K2s/blob/main/ADOPTERS.md
Maintainers file
https://github.com/Siemens-Healthineers/K2s/blob/main/MAINTAINERS.md
Security policy file
https://github.com/Siemens-Healthineers/K2s/blob/main/SECURITY.md
Standard or specification?
N/A
K2s is an implementation and distribution project. It does not define a new standard or specification. It builds on Kubernetes APIs and existing cloud native interfaces.
Business product or service to project separation
K2s started as an internal Siemens Healthineers AG project and is used across different business units. The project is already published as open source under a permissive license and has public documentation, contribution guidance, CI workflows, security reporting guidance, maintainers, adopters, governance information, and issue/PR based development.
The intended CNCF donation would establish K2s as a neutral upstream open source project. Siemens Healthineers may continue to use K2s in products, internal infrastructure, prototypes, or customer scenarios, but product-specific integrations, support offerings, validation, or commercial packaging would remain separate from the upstream project.
Why CNCF?
K2s is fundamentally a cloud native project: it packages and operates Kubernetes and related ecosystem components for users who need mixed Windows and Linux workloads, offline operation, and practical lifecycle management outside always-connected Linux-only environments.
CNCF is the right home because K2s sits directly in the Kubernetes ecosystem and complements several CNCF projects. A CNCF Sandbox donation would give the project a neutral governance path, increase visibility beyond its Siemens Healthineers origin, and invite collaboration from other organizations that run Windows workloads, edge/on-premises clusters, regulated environments, medical or industrial systems, or air-gapped deployments.
Benefit to the landscape
K2s benefits the Cloud Native Landscape by addressing mixed Windows and Linux Kubernetes workloads in offline, on-premises, edge, and regulated environments. Its differentiator is the combination of Windows-host reuse as a Kubernetes node, low-footprint Linux hosting through Hyper-V or WSL, experimental Linux-host support, offline packaging, addon export/import, node packages, delta packages, diagnostics, and a curated addon system.
Cloud native 'fit'
K2s fits into the cloud native ecosystem as a Kubernetes distribution and lifecycle tool for mixed-OS, offline-capable environments. It uses Kubernetes as the workload orchestration layer and relies on standard Kubernetes APIs, container images, manifests, networking, storage integrations, ingress, GitOps, metrics, logging, registry, and security ecosystem components.
Cloud native 'integration'
K2s integrates with Kubernetes and adjacent cloud native ecosystem components such as container runtimes, CNI networking, Helm-style packaging, Argo CD, Flux CD, KEDA, ingress controllers, monitoring/logging components, registry components, security policy components, and KubeVirt. K2s does not replace these projects; it packages, configures, and lifecycle-manages them for mixed Windows/Linux and offline scenarios.
Cloud native overlap
K2s overlaps partially with Kubernetes distributions and local/edge Kubernetes tools such as kind, minikube, k3s, MicroK8s, kubeadm-based distributions, Rancher Desktop, and Docker Desktop Kubernetes. K2s differs by focusing on mixed Windows/Linux workloads, reuse of a Windows host as a Kubernetes worker node, low-footprint Linux hosting through Hyper-V or WSL, and strong offline/air-gapped packaging workflows.
Similar projects
k3s, MicroK8s, minikube, kind, kubeadm, Rancher Desktop, Docker Desktop Kubernetes, OpenShift Local / CRC, Windows worker node support in upstream Kubernetes, AKS hybrid / AKS on Azure Stack HCI, and KubeVirt.
Landscape
K2s is not currently listed on the CNCF Cloud Native Landscape.
Insights
K2s is not currently listed on LFX Insights.
Trademark and accounts
IP policy
Will the project require a license exception?
The project is currently licensed under the MIT License and follows the REUSE specification for license metadata across repository files. Third-party licenses are tracked under the LICENSES directory and checked by CI.
We do not believe a license exception should be required for the current project license because MIT is a permissive open source license. However, we understand CNCF’s preference and policy expectations around Apache-2.0 for contributed project code. If CNCF requires Apache-2.0 for acceptance or long-term alignment, the maintainers and contributing organization are prepared to discuss relicensing or other remediation as part of the contribution agreement and IP review.
Project "Domain Technical Review"
A demo of K2s was presented to the Kubernetes SIG Windows group. The feedback from the group was very positive, especially regarding K2s' focus on mixed Windows/Linux Kubernetes workloads, reuse of the Windows host as a Kubernetes node, and support for practical offline/on-premises scenarios.
This engagement is relevant because SIG Windows is the Kubernetes community group closest to K2s' Windows workload and Windows node use cases. We would welcome continued technical feedback from SIG Windows during CNCF Sandbox review and future project development.
Demo on K2s in SIG Windows
Application contact email(s)
dieter.krotz@siemens-healthineers.com
Contributing or sponsoring entity signatory information
Krotz Dieter
Siemens Healthineers
dieter.krotz@siemens-healthineers.com
CNCF contacts
SIG Windows
dpalilonis@linuxfoundation.org
Additional information
K2s is already a public open source project with documentation, CI workflows, release history, contribution guidance, Code of Conduct, governance documentation, maintainer information, adopter information, security reporting guidance, and automated license compliance checks.
Repository: https://github.com/Siemens-Healthineers/K2s
Website/docs: https://siemens-healthineers.github.io/K2s/
The project contains Go code, PowerShell modules/scripts, Kubernetes manifests, addon definitions, documentation, and packaging automation. CI includes unit tests, REUSE/license checks, CLI builds, artifact builds, documentation builds, release automation, and commit checks.
K2s includes a provider architecture to keep platform-specific implementation behind interfaces while exposing consistent CLI behavior. Its addon system includes integrations for autoscaling, dashboard, DICOM workloads, GPU node support, ingress, KubeVirt, logging, metrics, monitoring, registry, GitOps rollout, security, SMB storage, and viewer workloads.
K2s maintainers have collaborated with the Linkerd community on Linkerd support for Windows, reflecting the project’s practical engagement with CNCF ecosystem needs around Windows workloads and mixed-OS Kubernetes clusters.
Offline operation is a core project goal, including offline installation packages, addon export/import, node packages, GPU-enabled node packages, and delta packages.
Project summary
K2s is a lightweight Kubernetes distribution for running mixed Windows and Linux workloads, with strong support for offline and air-gapped environments.
Project description
K2s is a Kubernetes distribution focused on making mixed Windows and Linux workloads practical, repeatable, and easy to operate. It packages Kubernetes and a curated set of open source components into a small, CLI-driven solution that can run on Windows hosts, reusing the Windows host itself as a worker node while running Linux workloads through a compact Linux environment using Hyper-V or WSL.
K2s addresses a gap for organizations that need Kubernetes-native operation for existing Windows applications, on-premises systems, edge environments, regulated environments, or air-gapped deployments. It provides offline installation packages, addon export/import, delta packages for upgrades, diagnostics, cluster lifecycle commands, and optional addons for ingress, monitoring, logging, registry, GitOps rollout, storage, security, GPU support, KubeVirt, and selected domain-specific workloads.
K2s started as an internal Siemens Healthineers project and is now used across different business units.
Org repo URL (provide if all repos under the org are in scope of the application)
N/A
Project repo URL in scope of application
https://github.com/Siemens-Healthineers/K2s
Additional repos in scope of the application
N/A
Website URL
https://siemens-healthineers.github.io/K2s/
Roadmap
https://github.com/Siemens-Healthineers/K2s/blob/main/ROADMAP.md
Roadmap context
The roadmap focuses on maturing K2s as a practical mixed-OS Kubernetes distribution for local, on-premises, edge, and air-gapped environments. Near-term work includes improving the Windows-host variant, maturing the experimental Linux-host variant, strengthening the provider architecture, hardening lifecycle operations, improving offline installation and upgrade workflows, expanding automated test coverage, and keeping the addon catalog practical and curated.
Contributing guide
https://github.com/Siemens-Healthineers/K2s/blob/main/docs/dev-guide/contributing/index.md
Code of Conduct (CoC)
https://github.com/Siemens-Healthineers/K2s/blob/main/CODE_OF_CONDUCT.md
Adopters
https://github.com/Siemens-Healthineers/K2s/blob/main/ADOPTERS.md
Maintainers file
https://github.com/Siemens-Healthineers/K2s/blob/main/MAINTAINERS.md
Security policy file
https://github.com/Siemens-Healthineers/K2s/blob/main/SECURITY.md
Standard or specification?
N/A
K2s is an implementation and distribution project. It does not define a new standard or specification. It builds on Kubernetes APIs and existing cloud native interfaces.
Business product or service to project separation
K2s started as an internal Siemens Healthineers AG project and is used across different business units. The project is already published as open source under a permissive license and has public documentation, contribution guidance, CI workflows, security reporting guidance, maintainers, adopters, governance information, and issue/PR based development.
The intended CNCF donation would establish K2s as a neutral upstream open source project. Siemens Healthineers may continue to use K2s in products, internal infrastructure, prototypes, or customer scenarios, but product-specific integrations, support offerings, validation, or commercial packaging would remain separate from the upstream project.
Why CNCF?
K2s is fundamentally a cloud native project: it packages and operates Kubernetes and related ecosystem components for users who need mixed Windows and Linux workloads, offline operation, and practical lifecycle management outside always-connected Linux-only environments.
CNCF is the right home because K2s sits directly in the Kubernetes ecosystem and complements several CNCF projects. A CNCF Sandbox donation would give the project a neutral governance path, increase visibility beyond its Siemens Healthineers origin, and invite collaboration from other organizations that run Windows workloads, edge/on-premises clusters, regulated environments, medical or industrial systems, or air-gapped deployments.
Benefit to the landscape
K2s benefits the Cloud Native Landscape by addressing mixed Windows and Linux Kubernetes workloads in offline, on-premises, edge, and regulated environments. Its differentiator is the combination of Windows-host reuse as a Kubernetes node, low-footprint Linux hosting through Hyper-V or WSL, experimental Linux-host support, offline packaging, addon export/import, node packages, delta packages, diagnostics, and a curated addon system.
Cloud native 'fit'
K2s fits into the cloud native ecosystem as a Kubernetes distribution and lifecycle tool for mixed-OS, offline-capable environments. It uses Kubernetes as the workload orchestration layer and relies on standard Kubernetes APIs, container images, manifests, networking, storage integrations, ingress, GitOps, metrics, logging, registry, and security ecosystem components.
Cloud native 'integration'
K2s integrates with Kubernetes and adjacent cloud native ecosystem components such as container runtimes, CNI networking, Helm-style packaging, Argo CD, Flux CD, KEDA, ingress controllers, monitoring/logging components, registry components, security policy components, and KubeVirt. K2s does not replace these projects; it packages, configures, and lifecycle-manages them for mixed Windows/Linux and offline scenarios.
Cloud native overlap
K2s overlaps partially with Kubernetes distributions and local/edge Kubernetes tools such as kind, minikube, k3s, MicroK8s, kubeadm-based distributions, Rancher Desktop, and Docker Desktop Kubernetes. K2s differs by focusing on mixed Windows/Linux workloads, reuse of a Windows host as a Kubernetes worker node, low-footprint Linux hosting through Hyper-V or WSL, and strong offline/air-gapped packaging workflows.
Similar projects
k3s, MicroK8s, minikube, kind, kubeadm, Rancher Desktop, Docker Desktop Kubernetes, OpenShift Local / CRC, Windows worker node support in upstream Kubernetes, AKS hybrid / AKS on Azure Stack HCI, and KubeVirt.
Landscape
K2s is not currently listed on the CNCF Cloud Native Landscape.
Insights
K2s is not currently listed on LFX Insights.
Trademark and accounts
IP policy
Will the project require a license exception?
The project is currently licensed under the MIT License and follows the REUSE specification for license metadata across repository files. Third-party licenses are tracked under the LICENSES directory and checked by CI.
We do not believe a license exception should be required for the current project license because MIT is a permissive open source license. However, we understand CNCF’s preference and policy expectations around Apache-2.0 for contributed project code. If CNCF requires Apache-2.0 for acceptance or long-term alignment, the maintainers and contributing organization are prepared to discuss relicensing or other remediation as part of the contribution agreement and IP review.
Project "Domain Technical Review"
A demo of K2s was presented to the Kubernetes SIG Windows group. The feedback from the group was very positive, especially regarding K2s' focus on mixed Windows/Linux Kubernetes workloads, reuse of the Windows host as a Kubernetes node, and support for practical offline/on-premises scenarios.
This engagement is relevant because SIG Windows is the Kubernetes community group closest to K2s' Windows workload and Windows node use cases. We would welcome continued technical feedback from SIG Windows during CNCF Sandbox review and future project development.
Demo on K2s in SIG Windows
Application contact email(s)
dieter.krotz@siemens-healthineers.com
Contributing or sponsoring entity signatory information
Krotz Dieter
Siemens Healthineers
dieter.krotz@siemens-healthineers.com
CNCF contacts
SIG Windows
dpalilonis@linuxfoundation.org
Additional information
K2s is already a public open source project with documentation, CI workflows, release history, contribution guidance, Code of Conduct, governance documentation, maintainer information, adopter information, security reporting guidance, and automated license compliance checks.
Repository: https://github.com/Siemens-Healthineers/K2s
Website/docs: https://siemens-healthineers.github.io/K2s/
The project contains Go code, PowerShell modules/scripts, Kubernetes manifests, addon definitions, documentation, and packaging automation. CI includes unit tests, REUSE/license checks, CLI builds, artifact builds, documentation builds, release automation, and commit checks.
K2s includes a provider architecture to keep platform-specific implementation behind interfaces while exposing consistent CLI behavior. Its addon system includes integrations for autoscaling, dashboard, DICOM workloads, GPU node support, ingress, KubeVirt, logging, metrics, monitoring, registry, GitOps rollout, security, SMB storage, and viewer workloads.
K2s maintainers have collaborated with the Linkerd community on Linkerd support for Windows, reflecting the project’s practical engagement with CNCF ecosystem needs around Windows workloads and mixed-OS Kubernetes clusters.
Offline operation is a core project goal, including offline installation packages, addon export/import, node packages, GPU-enabled node packages, and delta packages.