-
Notifications
You must be signed in to change notification settings - Fork 72
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
Apply arbitrary labels to nodes #45
Comments
@wbyoung Can you please explain what exactly do you need? You can apply any labels to your cluster. |
@avivl, I was thinking of the following use case for a single cluster:
In this case, it'd be useful to be able to have two pools of static IPs (with the appropriate DNS records) and to have the nodes run the corresponding services, right? The labels would allow defining rules for which nodes the services would run on. Is there another way one would handle this? |
@eranchetz can you explain(You'll probably do a better job than me) |
Hey @wbyoung, I'll give a simplified example, I hope it will make sense.
I reserve 2 static ips and label them: The result will be that pool-web will only use the web static ip address now, all we have to do is use Let us know if this makes sense for you. |
@eranchetz and is there a way to get it working with a single node pool? That was part of my request & the above discussion. |
Not really, I also think this is not good practice, since a node-pool instance is ephemeral, tagging a specific node (especially in cloud environments) might create a situation in which your static ip is not attached to the correct service. |
The point would be to allow the service (pod) to be assigned to the proper node based on the label. That responsibility applied to the developer and/or cluster admin, right? If tags are assigned when the static IPs are assigned and nodes that have static IPs don't have them removed (I'm assuming this is how this project works), then I'm not sure how this would be unsafe. The ephemeral nature of nodes doesn't really seem like it changes much here. Labels just allow rules for how to schedule pods regardless of the lifetime of a node. If a node dies or is removed, the freed static IP becomes available. Pods running on the node will be restarted (and may not be scheduable based on label based constraints). A new node may or may not be created to replace this node. The static IP that is now free will be assigned to a node if possible. The same tag that went with the node before will be assigned when the IP is assigned. It's possible that the scheduler will now be able to schedule pods that were previously unscheduable. There's nothing odd going on here that the ephemeral nature of nodes interferes with. Can you give a more complete example to the contrary? |
Similar to #15, I'd like to have fewer static IPs than nodes. I'd like to, however have the ability to tag the node with a more customized label to allow the static IPs to serve different purposes (this is a small scale deployment at this time).
For instance:
Would this be something that fits in the scope of this project? Would it be hard to add? I can take a stab when I have time if you can point me in the right direction.
The text was updated successfully, but these errors were encountered: