Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Windows "nodes" (not hosts, which are supported) #410

Closed
cyriltovena opened this issue Mar 27, 2019 · 11 comments
Closed

Support Windows "nodes" (not hosts, which are supported) #410

cyriltovena opened this issue Mar 27, 2019 · 11 comments
Labels
kind/feature Categorizes issue or PR as related to a new feature. lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. priority/backlog Higher priority than priority/awaiting-more-evidence.

Comments

@cyriltovena
Copy link

Since 1.14 Kubernetes provides stable windows nodes. It would be great to be able to run also windows nodes on KIND allowing fast development and testing for windows containers.

Possible implementation

Obviously as of today only windows support both linux and windows containers so this feature should only be focused for the windows version of KIND.

Since LCOW you can run both windows and linux container at the same time so LCOW should be required.

  • Via the config file we should be able to select the node os
  • We should also provide a windows node image.
@neolit123
Copy link
Member

the first prerequisite would be that kubeadm has to support Windows nodes propertly:
kubernetes/kubeadm#1393

we have this tracked for 1.15, but some help from SIG Windows will be required.

/priority backlog
/kind feature

@k8s-ci-robot k8s-ci-robot added priority/backlog Higher priority than priority/awaiting-more-evidence. kind/feature Categorizes issue or PR as related to a new feature. labels Mar 27, 2019
@BenTheElder
Copy link
Member

Another issue is that our CI is not Windows capable currently, and the images would have to be built from Windows.

As-is our Windows-as-a-host support is mainly trying hard not to break it (due to resources). I think @neolit123 is the only active contributor working from Windows. I occasionally test from a personal machine.

Last I checked the kernel version compatibility issue would make this tricky to ship to desktop users: https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/version-compatibility

I wouldn't say this won't happen, I certainly understand how it might be useful, but I don't think it is likely to happen soon given that even kubeadm isnt supported yet, Windows will need more support first.

It looks like minikube doesn't have any plans for this yet either 🤔

@cyriltovena
Copy link
Author

cyriltovena commented Mar 27, 2019 via email

@fejta-bot
Copy link

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

@k8s-ci-robot k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Jun 25, 2019
@BenTheElder
Copy link
Member

Forgot to update this, I think it might not actually be possible (to run CRI in a windows container) currently per @PatrickLang

@neolit123
Copy link
Member

would it be easier to get docker on the nodes working?
(probably not)

@BenTheElder
Copy link
Member

BenTheElder commented Jun 25, 2019

Er no, to clarify, I'm using CRI as shorthand for container runtimes in general. I haven't tried myself yet but my understanding from Patrick is that you can't nest them at all in Windows containers (which are a bit different from linux containers...)

@neolit123
Copy link
Member

i see. so this means we cannot have kind creating Windows node images.
which is quite the blocker, until further notice.

@BenTheElder BenTheElder added lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels Jun 25, 2019
@BenTheElder BenTheElder changed the title Support Windows node Support Windows "nodes" (not hosts, which are supported) Jun 25, 2019
@BenTheElder
Copy link
Member

if we can confirm it is infeasible, we should just close this and come back at some future date if that changes... otherwise, freezing.

@BenTheElder
Copy link
Member

AFAICT this is not possible. Linux containers on a linux "node" can run on windows in various ways, but a windows "node" container is not possible at the moment.

@BenTheElder
Copy link
Member

We will come back to this if / when it becomes possible

stg-0 pushed a commit to stg-0/kind that referenced this issue Feb 6, 2024
* version v0.18.0-alpha

* update docs for v0.17.0

* fix kind version in readme

* comments-update-buildcontext

* separated only offline feature

* removed old images registry script

* changed offline to private_registry. removed offline flag

* cleaned RewriteDescriptorFile

* ensure image building

* fixing rewrite descriptor bugs

* fixed RewriteDescriptorFile

---------

Co-authored-by: Benjamin Elder <[email protected]>
Co-authored-by: Daman <[email protected]>
Co-authored-by: Kubernetes Prow Robot <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/feature Categorizes issue or PR as related to a new feature. lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. priority/backlog Higher priority than priority/awaiting-more-evidence.
Projects
None yet
Development

No branches or pull requests

5 participants