Kops: Customize how node names are generated

[miracle2k]

Currently, the nodes I see in kubectl get nodes look like this:

ip-172-20-32-129.eu-west-2.compute.internal

I find those unhelpful. Here is how I see it:

First, the internal IP is used here, so to actually connect to a node, to get it's ip address, I have to use -o wide.

Second, I do not see the instance group. If I have a bunch of regular and one or two beefier machines, there is no way for me to see, for example in kubectl top pods which one is which.

Third, I see no information that I can even match with the instance list in the AWS UI. There, by default, I see:

Name: ig-name-mydomain.org  
Instance-ID: i-0fa7abf3e7d6538a2
Public-DNS: ec2....4.eu-west-2.compute.amazonaw

So if I see an instance in the web UI, and I would like to do a kubectl describe on that node, I have to find the private dns name in the AWS UI.

Similarly, the reverse: I actually have to use the search feature to search for the private IP to find a node by the information given to me in the kubectl get nodes output.

Nothing impossible, but I feel the user experience would be so much nicer if the names actually meant something, and where human readable:

igName-{1,2,3,4,...}

or:

igName-amazing-einstein

or a different scheme. Whatever it is, I would like to see it match the Name column in the AWS instance list.

[miracle2k]

Looking into this, it seems that at least on AWS, it is currently impossible for a custom hostname to be specified due to a Kubernetes limitation:

https://github.com/kubernetes/kubernetes/issues/64659
https://github.com/kubernetes/website/pull/8873

It seems that until Kubernetes supports this, there is little we can do here. One possible fix is:

https://github.com/kubernetes/kubernetes/pull/61878

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[ReillyTevera]

/remove-lifecycle stale

[swarupdonepudi]

I would like to see the node names to be in the following format:

For etcd: <ip-xx-xx-xx-xx>.etcd.<cluster-domain>
For master nodes: <ip-xx-xx-xx-xx>.master.<cluster-domain>
For worker nodes: <ip-xx-xx-xx-xx>.worker.<cluster-domain>

Benefits of the above format:

1. Easy to identify which cluster the nodes belongs to
2. Easy to identify the instance group etcd or master or a worker node
3. Easy to setup SSH access using wildcards in ~/.ssh/config file

[rocktavious]

I agree with @swarupdonepudi but for worker pool nodes i'd like to take the name from instance group definition and use that. We run a few worker pools in each k8s kops cluster and knowing which nodes go with which workerpool is hard to decern unless you do kubectl get nodes --show-labels but the main usecase we have is something like this kubectl get pods -l app=ourapp -o wide which prints out the node name the pod is running on (and it would be nice to look at the node name and know which worker pool it was in)

NAME                          READY   STATUS        RESTARTS   AGE   IP                NODE                             NOMINATED NODE
coordinator-0   1/1     Running       0          21h   100.126.131.131   ip-172-28-135-122.ec2.internal   <none>
coordinator-1   1/1     Running       0          20h   100.109.137.71    ip-172-28-171-202.ec2.internal   <none>
coordinator-2   1/1     Running       0          21h   100.100.6.196     ip-172-28-206-121.ec2.internal   <none>
coordinator-3   1/1     Running       0          21h   100.114.28.131    ip-172-28-152-80.ec2.internal    <none>
coordinator-4   1/1     Running       0          21h   100.116.46.71     ip-172-28-162-57.ec2.internal    <none>

the node names are useless but if they were
<ip>.<IG name>.<cluster> it would be really easy to tell which worker pool they are running in.

[thomaspeitz]

I want to add that adding instance group into name would help in a lot of exporter cases e.g. https://github.com/google-cloud-tools/kube-eagle/ to identify on which instancegroup the container is running without the stress to make selects or anything like that.

It would allow a lot easier monitoring.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[rocktavious]

Bumping to keep alive - i really want this to become a thing as it would help out alot with larger more diverse clusters!

[pradeepnnv]

This feature would be really helpful.

[and3rson]

Bumping. Would love to give nodes nicer names.

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[ReillyTevera]

/remove-lifecycle rotten

[jasoares]

Bumping, would love to have this....

[shachar-ash]

Bumping, this feature would be amazing!

[jmcdonagh]

yea if the nodenames could begin with a user-specified prefix, that'd be great. simple use case is setting up your ssh config to use the bastion, you coud have Host prefix-* then the ProxyJump command to go through the bastion. ip-whatever default prefix is not great because you could have multiple clusters with that same prefix with different bastions.

[xunliu]

This feature would be really helpful.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[miracle2k]

/remove-lifecycle stale

[Tawmu]

Bumping to keep alive - would be very helpful.

[rocktavious]

+1

[paul-theorem]

I'd like to see this.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[andrewdunai]

/remove-lifecycle stale

[olemarkus]

Most of this has little to do with kops and more to do with k8s in itself.

In kops 1.19 we do have kops get instances that will provide some of the info requested above though.

[olemarkus]

Unless someone has an idea of what can be improved from the kOps side, I will close this one.