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鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multiple node support? #117

Closed
luxas opened this issue Nov 16, 2018 · 10 comments

Comments

Projects
None yet
6 participants
@luxas
Copy link

commented Nov 16, 2018

Don't know if this has been discussed yet. But it'd be nice to be able to bootstrap joining "nodes" in more docker containers, like kubeadm-dind-cluster does 馃槃. WDYT?

@aledbf

This comment has been minimized.

Copy link

commented Nov 16, 2018

@luxas is present in the todo list

@BenTheElder

This comment has been minimized.

Copy link
Member

commented Nov 16, 2018

Yes! We'd love to get this working, I've just prioritized it lower than getting the other functionality implemented really well first. I've left a lot of the ground work with how the nodes are handled currently.

@fabriziopandini was going to sync up with me next week about up-streaming a working multi-node implementation :-)

/kind enhancement
/priority important-longterm

@BenTheElder

This comment has been minimized.

Copy link
Member

commented Nov 21, 2018

Hmm it seems you're not a member of kubernetes-sigs yet @fabriziopandini, if you join I'm happy to assign you as well :-)

Roughly, we discussed the need to:

  • add better support internally for taking actions across a topology of nodes
  • add support for more nodes
  • add support for tracking / recording the statuses of nodes (my initial thought: place a status record file in each node container, but please suggest options!)
  • hash out how flags / cli / configuration should look for this further, discuss this with you all and others

Fabrizio demoed a very nice local "HA" cluster setup with his current patches, this should bring some very cool opportunities to cheaply testing interesting cluster topologies when it's done 馃槃

If anyone else has thoughts or requests for this, I'd love to hear them!

@neolit123

This comment has been minimized.

Copy link
Contributor

commented Nov 21, 2018

Fabrizio demoed a very nice local "HA" cluster setup with his current patches, this should bring some very cool opportunities to cheaply testing interesting cluster topologies when it's done smile

that's great news.
i wash i was part of your meeting to get a better context.

add support for tracking / recording the statuses of nodes (my initial thought: place a status record file in each node container, but please suggest options!)

adding state on disk is usually not the best of options, but it depends of what type of node status we want to store. we also have https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#ClusterStatus

hash out how flags / cli / configuration should look for this further, discuss this with you all and others

we can definitely share our thoughts after working on the kubeadm ComponentConfig for some many releases.

@BenTheElder

This comment has been minimized.

Copy link
Member

commented Nov 21, 2018

i wash i was part of your meeting to get a better context.

yes, it was fairly unplanned, in the future I'd love to meet with you and others about this.

adding state on disk is usually not the best of options, ...

well only "on disk" within the node containers, so it will be cleaned up and be associated with them, it's not so different compared to say, the logs.

but it depends of what type of node status we want to store. we also have https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm#ClusterStatus

It needs to have the status of the node even before we've run kubeadm, from my understanding of @fabriziopandini's intent there.

we can definitely share our thoughts after working on the kubeadm ComponentConfig for some many releases.

I hoped so! I really want to ensure that it's easy for someone that "just needs kubernetes for testing" to use and understand and set the number of nodes etc, while allowing someone like you or Fabrizio to have full control over every step on every node.

@neolit123

This comment has been minimized.

Copy link
Contributor

commented Nov 21, 2018

well only "on disk" within the node containers, so it will be cleaned up and be associated with them, it's not so different compared to say, the logs.

so it will also be read the same way as the logs, i guess.

It needs to have the status of the node even before we've run kubeadm, from my understanding of @fabriziopandini's intent there.

interested to find out what status such files would hold.

I hoped so! I really want to ensure that it's easy for someone that "just needs kubernetes for testing" to use and understand and set the number of nodes etc, while allowing someone like you or Fabrizio to have full control over every step on every node.

馃憤

@luxas

This comment has been minimized.

Copy link
Author

commented Nov 22, 2018

xref this on ComponentConfig for configuring all this topology stuff ;) https://docs.google.com/document/d/1nZnzJD9dC0xrtEla2Xa-J6zobbC9oltdHIJ3KKSSIhk/edit

Overall the direction of the thread sounds great to me!

@fabriziopandini

This comment has been minimized.

Copy link
Contributor

commented Nov 23, 2018

/assign
I will followup with dedicated issue for each topic asap; this issue remains as a umbrella for general discussion for multi-node

@fabriziopandini

This comment has been minimized.

Copy link
Contributor

commented Dec 16, 2018

/lifecycle active

@BenTheElder

This comment has been minimized.

Copy link
Member

commented Jan 14, 2019

We have this now ref #164, thanks to @fabriziopandini :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can鈥檛 perform that action at this time.