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

Apply arbitrary labels to nodes #45

Closed
wbyoung opened this issue Mar 28, 2019 · 9 comments · Fixed by #49
Closed

Apply arbitrary labels to nodes #45

wbyoung opened this issue Mar 28, 2019 · 9 comments · Fixed by #49
Assignees

Comments

@wbyoung
Copy link

wbyoung commented Mar 28, 2019

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:

gcloud beta compute addresses update kubeip-ip-mx0 --update-labels kubeip=$GKE_CLUSTER_NAME,kubeip-node-labels=mx:second-label

gcloud beta compute addresses update kubeip-ip-web0 --update-labels kubeip=$GKE_CLUSTER_NAME,kubeip-node-labels=web

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.

@avivl avivl self-assigned this Mar 28, 2019
@avivl
Copy link
Contributor

avivl commented Mar 28, 2019

@wbyoung this shouldn't be too hard to add. I don't have the bandwidth for it now.
You can take a look here and make the replacment based on any rules

@avivl avivl removed their assignment Mar 28, 2019
@avivl
Copy link
Contributor

avivl commented Apr 29, 2019

@wbyoung Can you please explain what exactly do you need? You can apply any labels to your cluster.
What the expected behavior from Kubeip?

@wbyoung
Copy link
Author

wbyoung commented Apr 29, 2019

@avivl, I was thinking of the following use case for a single cluster:

  • Accept incoming mail
  • Accept incoming web traffic

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?

avivl added a commit that referenced this issue Apr 30, 2019
avivl added a commit that referenced this issue May 1, 2019
avivl added a commit that referenced this issue May 13, 2019
@avivl avivl closed this as completed in #49 May 13, 2019
@wbyoung
Copy link
Author

wbyoung commented May 13, 2019

I think #49 may be a different feature from the request here, but looks useful.

If #49 does solve the above use case, can you give an example of how to configure things to handle the previous comment (which is for a single node pool)?

@avivl
Copy link
Contributor

avivl commented May 13, 2019

@eranchetz can you explain(You'll probably do a better job than me)

@eranchetz
Copy link
Contributor

Hey @wbyoung,

I'll give a simplified example, I hope it will make sense.
I have 2 node pools with 1 instance each:

  • pool-web
  • pool-mx

I reserve 2 static ips and label them:
kubeip-node-pool=pool-web
kubeip-node-pool=pool-web

The result will be that pool-web will only use the web static ip address
and pool-mx will only use the mx static ip.

now, all we have to do is use nodeSelector for the web/mx deployment
deployment-web will run on the pool-web

Let us know if this makes sense for you.

@wbyoung
Copy link
Author

wbyoung commented May 14, 2019

@eranchetz and is there a way to get it working with a single node pool? That was part of my request & the above discussion.

@eranchetz
Copy link
Contributor

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.
I think that having a logical group (in this case a node-pool) is the "cheapest" most reliable option.

@wbyoung
Copy link
Author

wbyoung commented May 15, 2019

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?

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

Successfully merging a pull request may close this issue.

3 participants