Add a flag to override server address in the generated config

[Shadi]

We are using Kind in one of our project integration tests suites, these tests run inside a docker container using github actions, when kind creates a cluster as part of the test run preparation it uses the default "127.0.0.1" for server address: https://github.com/kubernetes-sigs/kind/blob/main/pkg/internal/apis/config/default.go#L57

when the test runs a kubectl command it can't connect to the created cluster since kubectl is being ran from inside a container and 127.0.0.1 resolves to that container instead of the cluster on the host machine.

This change would allow us to set a different address when preparing for tests so it can execute kubectl commands and connect to the created cluster

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: Shadi / name: Shadi Abdelfatah (8c5f304)

[k8s-ci-robot]

Welcome @Shadi!

It looks like this is your first PR to kubernetes-sigs/kind 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-sigs/kind has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[k8s-ci-robot]

Hi @Shadi. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: Shadi
To complete the pull request process, please assign aojea after the PR has been reviewed.
You can assign the PR to them by writing /assign @aojea in a comment when ready.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[BenTheElder]

Thank you for your PR.
In the future, per the contributor guide, we'd like to discuss features, how they will work, etc. before reviewing PRs.

CONTRIBUTING.md => https://kind.sigs.k8s.io/docs/contributing/getting-started/

We do not currently require KEPs like the rest of kubernetes, but we do prefer to flesh out the feature in an issue.

For example on such an issue I would ask:

• Does this need to be functionality in kind? It should be relatively straightforward to alter the address in kubeconfig yourself if we're just substituting it in kubeconfig vs say https://kind.sigs.k8s.io/docs/user/configuration/#api-server
• Which commands? This PR only seems to implement the flag for kind create cluster but there are other kubeconfig related commands
• What flag name sounds reasonable and clearest? apiServerAddress is not the typical naming convention (camelCase vs hypen-case) for flags and is also a misleading name IMO.
• Have we considered the related existing feature request issues and their discussions Need a way to get kubeconfig with node IP #1558 Improve kind get kubeconfig and kind export kubeconfig for multicluster #2246

[Shadi]

Hello @BenTheElder, thanks for taking a look

Thank you for your PR. In the future, per the contributor guide, we'd like to discuss features, how they will work, etc. before reviewing PRs.

CONTRIBUTING.md => https://kind.sigs.k8s.io/docs/contributing/getting-started/

We do not currently require KEPs like the rest of kubernetes, but we do prefer to flesh out the feature in an issue.

For example on such an issue I would ask:

• Does this need to be functionality in kind? It should be relatively straightforward to alter the address in kubeconfig yourself if we're just substituting it in kubeconfig vs say https://kind.sigs.k8s.io/docs/user/configuration/#api-server
• Have we considered the related existing feature request issues and their discussions Need a way to get kubeconfig with node IP #1558 Improve kind get kubeconfig and kind export kubeconfig for multicluster #2246

this indeed similar to Need a way to get kubeconfig with node IP #1558, the same sed workaround can be used in our case too, but it seemed it can be changed quickly by using --name flag as a guide so I created this PR without looking at the older issues, feel free to close this PR.

• Which commands? This PR only seems to implement the flag for kind create cluster but there are other kubeconfig related commands
  I'm not very familiar with this project and my goal was to only override the server address for the generated file at KubeconfigPath, so I didn't look at the other cases, but I'm happy to make changes for them too if you think this PR can be a starting point to implement this feature properly.

• What flag name sounds reasonable and clearest? apiServerAddress is not the typical naming convention (camelCase vs hypen-case) for flags and is also a misleading name IMO.
  I used name flag as a guide and changed it now to just address and updated the description.

I decided to create this PR since it seemed to be not a lot of work to implement this change in a way the name flag is being used now when creating clusters, if you prefer to have a proper implementation based on the discussion in Need a way to get kubeconfig with node IP #1558 then feel free to close it.

[aojea]

kubectl is being ran from inside a container and 127.0.0.1 resolves to that container instead of the cluster on the host machine.

you can use kind get kubeconfig --internal then, it will return a kubeconfig usable inside containers

[BenTheElder]

you can use kind get kubeconfig --internal then, it will return a kubeconfig usable inside containers

Or better yet: I think kind create cluster && kind export kubeconfig --internal is what you want (get returns it to stdout, export does the kubeconfig merging like kind create cluster)

We should really follow up on those issues and rethink these flags for some additional options though.