Finding the ProviderID fails when using a custom domain in the dhcp options about cloud-provider-aws HOT 12 CLOSED

This issue is currently awaiting triage.

If cloud-provider-aws contributors determine this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

from cloud-provider-aws.

There’s a few quirks when using a custom domain name in your DHCP options, because it will only be reflected in the instance’s PrivateDnsName (the filter being used to map a Node to an EC2 instance) if one of these DNS attributes of your VPC is disabled: https://docs.aws.amazon.com/vpc/latest/userguide/vpc-dns.html#vpc-dns-support

The PrivateDnsName in the EC2 API is not always the same as the hostname from the OS (which is what kubelet will use as its node name by default).

In general, I would recommend just passing the provider ID to kubelet yourself, instead of relying on the node name -> EC2 instance lookup, as the former is much more efficient.

from cloud-provider-aws.

/kind support

from cloud-provider-aws.

I understand that manually specifying it would work but there is code to try to determine it would having to manually set it. The code assumes that if the hostname starts with "i-", it assumes it is the instance id. It seems like just stripping off the rest of the nodename would solve most issues, when using the the resource name in the subnet settings. Is there a reason that something like the following wouldn't work?

+++ b/pkg/providers/v1/aws.go
@@ -5124,6 +5124,7 @@ func nodeNameToIPAddress(nodeName string) string {
func (c *Cloud) nodeNameToInstanceID(nodeName types.NodeName) (InstanceID, error) {
  if strings.HasPrefix(string(nodeName), rbnNamePrefix) {
+   nodeName = strings.Split(nodeName, ".")[0]
     return InstanceID(nodeName), nil
}

from cloud-provider-aws.

Hm refreshing my memory -- previously we expected just the instance ID when resource-based naming was used, but @tzneal fixed that in: dce57f7

Shouldn't that cover this scenario? That commit is in 1.27+ currently, feel free to cherry-pick it to 1.26 if that would fix this for you

from cloud-provider-aws.

Actually, yeah, I was looking in 1.27.1 and it looks like that was changed between 1.27.1 and 1.272.

from cloud-provider-aws.

In the compatibility matrix, I am using 1.26 and it lists 1.26.1 as the version I should be using. For 1.27, it lists 1.27.1. The latest version of cloud-provider-aws for 1.26.9 and does not have that change. If I use 1.27.2, would it still be compatible with kubernetes 1.26? It does not look like it based on the support matrix and does not look like 1.27.2 should be used.

from cloud-provider-aws.

The matrix is just out of date, sorry about that. You should always use the latest CCM release for a given k8s minor version, I'll get the README updated.

from cloud-provider-aws.

Ok, I tested kubernetes 2.6.11 and it does work using 1.27.2 when I create a new cluster. It doesn't match the version though. Is the fix going to be backported to the 1.26.x branch of cloud-provider-aws?

from cloud-provider-aws.

I think it makes sense to cherry-pick this, we haven't heard of it causing any breakage. Feel free to open a PR 👍

from cloud-provider-aws.

/close

from cloud-provider-aws.

@cartermckinnon: Closing this issue.

from cloud-provider-aws.