search

kubernetes-sigs / kind

Kubernetes IN Docker - local clusters for testing Kubernetes
https://kind.sigs.k8s.io/
Apache License 2.0
13.57k stars 1.57k forks source link

Support ignite backend #705

Open BenTheElder opened 5 years ago

BenTheElder commented 5 years ago

What would you like to be added: Support for using ignite as a docker-like backend with improved isolation.

Why is this needed: This provides a relatively fast but much more isolated option for nodes. On the surface the UX is very similar to the docker CLI, and it operates around standard docker images, with the requirement that you use an /sbin/init (which we do, though wrapped for docker in docker workarounds).

Some thoughts:

/priority backlog /assign

aojea commented 5 years ago

Just for clarification, the goal is to replace current provider or to allow kind to use multiple providers? By the way, I was able to play with ignite and sounds and awesome idea, this also allow to test different kernels , ...

BenTheElder commented 5 years ago

Definitely not replace (!) There's too many environments that won't have access to this, realistically, and we have our existing users etc. 🙃

As an additional backend this would be pretty useful and mostly can map pretty closely to what we do already 😁

tao12345666333 commented 5 years ago

SGTM. I think this will be fun. The main reason for choosing ignite is due to its UX?

danielfbm commented 4 years ago

I am working to add kubernetes as a new provider (using kubectl to manage pods, etcs), is this a viable/desirable goal for kind ? If yes, I would like to contribute (and probably would need some guidance)

BenTheElder commented 4 years ago

Hi, I've actually already written this as a joke, it came up at our kubecon deep dive too :+)

At this time we're not ready for that, it might be amusing someday, but we aren't prepared to actually support it and wouldn't recommend it, and need to land other changes.

On Tue, Dec 10, 2019, 05:47 Daniel Filipe Bruehmueller Morinigo < notifications@github.com> wrote:

I am working to add kubernetes as a new provider (using kubectl to manage pods, etcs), is this a viable/desirable goal for kind ? If yes, I would like to contribute (and probably would need some guidance)

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/kubernetes-sigs/kind/issues/705?email_source=notifications&email_token=AAHADKY6UMB2DZTMAHDYKVLQX6MVFA5CNFSM4IDTHVCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGPI47Q#issuecomment-564039294, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHADK35U5FZBI35QRZ2DELQX6MVFANCNFSM4IDTHVCA .

danielfbm commented 4 years ago

Could you kindly share the code if possible? In our team kind fits as a perfect development environment, but not really possible to run directly from our laptops, so considering a kubernetes cluster to handle the orchestration seems fair. Thanks

On Wed, Dec 11, 2019, 1:13 AM Benjamin Elder notifications@github.com wrote:

Hi, I've actually already written this as a joke, it came up at our kubecon deep dive too :+)

At this time we're not ready for that, it might be amusing someday, but we aren't prepared to actually support it and wouldn't recommend it, and need to land other changes.

On Tue, Dec 10, 2019, 05:47 Daniel Filipe Bruehmueller Morinigo < notifications@github.com> wrote:

I am working to add kubernetes as a new provider (using kubectl to manage pods, etcs), is this a viable/desirable goal for kind ? If yes, I would like to contribute (and probably would need some guidance)

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub < https://github.com/kubernetes-sigs/kind/issues/705?email_source=notifications&email_token=AAHADKY6UMB2DZTMAHDYKVLQX6MVFA5CNFSM4IDTHVCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGPI47Q#issuecomment-564039294 , or unsubscribe < https://github.com/notifications/unsubscribe-auth/AAHADK35U5FZBI35QRZ2DELQX6MVFANCNFSM4IDTHVCA

.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kubernetes-sigs/kind/issues/705?email_source=notifications&email_token=ABGPZ7UFVIN4TZOFNQEBRDDQX7E4HA5CNFSM4IDTHVCKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGQATCY#issuecomment-564136331, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABGPZ7RM2UAH26ML25W4U33QX7E4HANCNFSM4IDTHVCA .

BenTheElder commented 4 years ago

it's not in a good state, however there are many comments here about running kind in kubernetes clusters :grimacing:

I highly recommend avoiding that if at all possible, it's tricky to avoid the various footguns, in general I don't recommend creating priviliged containers in kubernetes clusters unless you are working on a system component like kube-proxy.

danielfbm commented 4 years ago

that is our main issue. Our team is mostly working with operators/CRDS/aggregations and the need to share resources (cluster of servers) is big deal for us, so we are willing to give it a shot to avoid creating another orchestration tool 😅, but really appreciate the heads up.

I looked through most of the issues that reference this kind of use case, I think #303 is the most important one here and I will post the issues I found there if it is ok for you.

Also, from what I gathered, kubernetes, istio and other projects use case is actually more like: Pod using docker-in-docker then running kind inside, which is also a docker-in-docker solution. Would that approach be recommended instead of directly running a pod as a k8s node?

BenTheElder commented 4 years ago

I don't recommend it, unfortunately we must do it anyhow. This is all deeply on my backlog, currently focused on some kubernetes testing needs and https://github.com/kubernetes-sigs/kind/issues/148