Skip to content
This repository has been archived by the owner on Jun 21, 2023. It is now read-only.

Should we support leaderelection? #32

Open
LeoLiuYan opened this issue Jul 27, 2020 · 9 comments
Open

Should we support leaderelection? #32

LeoLiuYan opened this issue Jul 27, 2020 · 9 comments

Comments

@LeoLiuYan
Copy link

Now, virtual-kubelet not support leaderelection, should we support it?

@LeoLiuYan
Copy link
Author

ping @cpuguy83

@cpuguy83
Copy link
Collaborator

What for? What needs a leader?

@LeoLiuYan
Copy link
Author

LeoLiuYan commented Jul 28, 2020

What for? What needs a leader?

For example, when deploy a virtual-node which use the virtual-kubelet lib, we wish the virtual-node have HA traint to prevent the virtual-node down and then pods running in virtual-node migrate to other nodes. The virtual-node may be a cluster which many pods running in it. Am I making myself clear?

@cpuguy83

@LeoLiuYan
Copy link
Author

ping @cpuguy83

@cpuguy83
Copy link
Collaborator

This seems out of scope for VK which only seeks to operate a single node in a cluster.
But I may not be understanding the case here.

@LeoLiuYan
Copy link
Author

LeoLiuYan commented Aug 11, 2020

This seems out of scope for VK which only seeks to operate a single node in a cluster.
But I may not be understanding the case here.

For example, in tensile-kube we treat a cluster as a virtual-node.

image

@LeoLiuYan
Copy link
Author

cc @cwdsuzhou

@LeoLiuYan
Copy link
Author

ping @cpuguy83

@pires
Copy link
Member

pires commented Nov 27, 2020

Virtual or not, it is a Node so it relies on kube-scheduler to decide to put workloads on it, and on the kube-controller-manager to evict workloads in case the Node goes down. If you have multiple instances, you don't need leader-election but to manage taints properly.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants