Eksctl: feat: Instance ID as Node Name

[mumoshu]

Extracted from https://github.com/weaveworks/eksctl/issues/500#issuecomment-459956779

Makinig it easier to correlate Kubernetes nodes and EC2 instances, this feature would be useful for cluster operator who maintains Kubernetes nodes.

This isn't easy as it looks. We need to enhance kubelet and aws-cloud-provider because they are currently hard-coded to use private DNS names as node names.

[errordeveloper]

@christopherhein I recall hearing about work being done in this area, but cannot find it now, would you be able to confirm?

[whereisaaron]

I think I prefer the current behavior because the node names contain the node IP address. This is generally more useful to me.

I would like a way to correlate a node with the instance ID, but I’d prefer that was a node label.

In the end, if there is single a kubectl get nodes command with custom columns that can display both instance ID and IP address, that would be great.

[christopherhein]

We still have a good way of getting it, it's not a label but it's a part of or the spec as providerID it used to be externalID… but that was deprecated - https://github.com/kubernetes/kubernetes/issues/60466

You'll have to parse it out but it's relatively easy.

k get nodes {nodeName} -o jsonpath="{.spec.providerID}"

if you want to get it and then parse in one line you could do something hacky like this.

provider=$(k get nodes {nodeName} -o jsonpath="{.spec.providerID}") && echo ${provider##*\/} 

[errordeveloper]

Thanks everyone for the input! Should we keep this open?

On Sat, 16 Feb 2019, 3:46 am Christopher Hein <[email protected]
wrote:

We still have a good way of getting it, it's not a label but it's a part
of or the spec as providerID it used to be externalID…

You'll have to parse it out but it's relatively easy.

k get nodes {nodeName} -o jsonpath="{.spec.providerID}"

if you want to get it and then parse in one line you could do something
hacky like this.

provider=$(k get nodes ip-192-168-50-164.us-west-2.compute.internal -o jsonpath="{.spec.providerID}") && echo ${provider##*/}

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/weaveworks/eksctl/issues/509#issuecomment-464281755,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAPWS_uwVnNTzcGUrZqLCXQNChkELWeTks5vN38BgaJpZM4aiY-I
.

[errordeveloper]

To be clear - we have a label now also. I don't know if the label is still
needed, once 'providerID' can be used.

On Wed, 20 Feb 2019, 10:12 am Ilya Dmitrichenko <[email protected]
wrote:

Thanks everyone for the input! Should we keep this open?

On Sat, 16 Feb 2019, 3:46 am Christopher Hein <[email protected]
wrote:

We still have a good way of getting it, it's not a label but it's a part
of or the spec as providerID it used to be externalID…

You'll have to parse it out but it's relatively easy.

k get nodes {nodeName} -o jsonpath="{.spec.providerID}"

if you want to get it and then parse in one line you could do something
hacky like this.

provider=$(k get nodes ip-192-168-50-164.us-west-2.compute.internal -o jsonpath="{.spec.providerID}") && echo ${provider##*/}

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/weaveworks/eksctl/issues/509#issuecomment-464281755,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAPWS_uwVnNTzcGUrZqLCXQNChkELWeTks5vN38BgaJpZM4aiY-I
.

[christopherhein]

Thanks everyone for the input! Should we keep this open?
…
On Sat, 16 Feb 2019, 3:46 am Christopher Hein @.* wrote: We still have a good way of getting it, it's not a label but it's a part of or the spec as providerID it used to be externalID… You'll have to parse it out but it's relatively easy. k get nodes {nodeName} -o jsonpath="{.spec.providerID}" if you want to get it and then parse in one line you could do something hacky like this. provider=$(k get nodes ip-192-168-50-164.us-west-2.compute.internal -o jsonpath="{.spec.providerID}") && echo ${provider##*/} — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#509 (comment)>, or mute the thread https://github.com/notifications/unsubscribe-auth/AAPWS_uwVnNTzcGUrZqLCXQNChkELWeTks5vN38BgaJpZM4aiY-I .

I'd say close.

[whereisaaron]

@errordeveloper I think @mumoshu may still want the actual name of the node to be the AWS instance id. At least as a 'one day' feature. Though maybe since this is an aws-cloud-provider patch is it outside the scope of eksctl?

[errordeveloper]

Yes, it would fall under cloud provider/controller. Also, it was me who
brought up the topic of using instance IDs as names, while we were
discussing @mumoshu's PR that added IDs as labels.

On Wed, 20 Feb 2019, 6:48 pm Aaron Roydhouse <[email protected]
wrote:

@errordeveloper https://github.com/errordeveloper I think @mumoshu
https://github.com/mumoshu may still want the actual name of the node
to be the AWS instance id. At least as a 'one day' feature. Though maybe
since this is an aws-cloud-provider patch is it outside the scope of
eksctl?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/weaveworks/eksctl/issues/509#issuecomment-465705969,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAPWS0PMN8xbP0kMNLxeVhqDZ3v97X4hks5vPZibgaJpZM4aiY-I
.

[nckturner]

I'd like to circle back on this, and see what dependencies still need to change to actually support instance ID as a node name. Before I go digging, is anyone up to date on the current status of this? I know for EKS, the authenticator would need to change, and cloud provider. Also, is there a tracking issue in k/k? I'm way out of date on issues there.

[errordeveloper]

Yes, I am quite lost also. I do recall there was some movement in this
direction a while back, but I might have mislead myself... What do you
think?

On Wed, 10 Apr 2019, 5:56 pm Nicholas Turner, [e-mail]
wrote:

I'd like to circle back on this, and see what dependencies still need to
change to actually support instance ID as a node name. Before I go digging,
is anyone up to date on the current status of this? I know for EKS, the
authenticator would need to change, and cloud provider. Also, is there a
tracking issue in k/k? I'm way out of date on issues there.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/weaveworks/eksctl/issues/509#issuecomment-481773959,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAPWSxrsCkQUY6jT8keFx2VcZGZjt45Nks5vfhe2gaJpZM4aiY-I
.

[danbeaulieu]

There was a discussion during the sig-aws meeting back in February. https://docs.google.com/document/d/1-i0xQidlXnFEP9fXHWkBxqySkXwJnrGJP9OGyP2_P14/edit#heading=h.fynosqcijrf

it has some links to historical references and current

@mcrute had some thoughts and I think mentioned this might be fixed in 1.15... @mcrute, is there a k/k umbrella issue for this?

[mcrute]

@danbeaulieu this is something I'm working on fixing for the 1.15 release cycle. I haven't rolled all the k/k issues up into one parent issue yet but will tag this to it as well once I do.

[errordeveloper]

Thanks, Mike. Will be looking forward to hearing an update!

On Tue, 16 Apr 2019, 7:17 pm Mike Crute, [e-mail] wrote:

@danbeaulieu https://github.com/danbeaulieu this is something I'm
working on fixing for the 1.15 release cycle. I haven't rolled all the k/k
issues up into one parent issue yet but will tag this to it as well once I
do.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/weaveworks/eksctl/issues/509#issuecomment-483786668,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAPWS5Ed6nO1IFLwvDNB7Br1YZ69CfsCks5vhhOXgaJpZM4aiY-I
.

[ChillarAnand]

This seems to be a stale issue. Any plans on working on this?

[github-actions[bot]]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.