add node-name-strategy option

[Issacwww]

Issue #, if available:

Description of changes:
Add support for AL2023 self managed node group to have EC2Instance Based Name

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

Testing

Tested with AL2 AMI

kubetest2-eksapi --kubernetes-version=1.28 --up --unmanaged-nodes --ami ami-0c63d30c477bc4cc2 --node-name-strategy=EC2PrivateDNSName --nodes=1

k get nodes
NAME                                           STATUS   ROLES    AGE     VERSION
ip-192-168-36-81.us-west-2.compute.internal    Ready    <none>   8m54s   v1.28.5-eks-5e0fdde

Tested with self build AL2023 1.28 AMI, along with this change

kubetest2-eksapi --kubernetes-version=1.28 --up --user-data-format=nodeadm --unmanaged-nodes --ami ami-0b41e47dab79e8cea --node-name-strategy=SessionName --nodes=1

k get nodes
NAME                  STATUS   ROLES    AGE     VERSION
i-00e37501896aa8468   Ready    <none>   4m39s   v1.28.5-eks-5e0fdde

[cartermckinnon]

Can we make this option a little more targeted to this specific behavior, something like --node-name-strategy?

We'll eventually have to add --ami-type to test with MNG, but that concept doesn't mean anything for an unmanaged nodegroup.

[Issacwww]

Do you mean we need to decouple the behaviors from the os-distro? Option like naming strategy would allow use cases like AL2 + SessionName and AL2023 + PrivateDNSName. Although we can control it via pipeline, is there any other user will use it in that way?

[cartermckinnon]

Option like naming strategy would allow use cases like AL2 + SessionName and AL2023 + PrivateDNSName.

Yeah exactly. When we add support for AL2023 managed node groups, this tool will need an option for --ami-type, and we will set --node-name-strategy based on that value; but for unmanaged nodes, the AMI may use bootstrap.sh, nodeadm, or something else entirely. I want to avoid making too many assumptions about feature sets here, and just expose the individual options. Our higher level test framework that uses this tool can centralize all the details of which AMI's support which feature, how to test a given AMI, etc.

[cartermckinnon]

I think we should use a proper go template for this, since we're filling in 2 values now. Examples in the deployers/eksapi/templates package

[cartermckinnon]

I think the stdlib has something like this now: https://pkg.go.dev/slices