API Server host is resolved to its ipv6 and not to its ipv4

[jobcespedes]

Describe the bug
The client tries to connect to the API Server and fails. In EKS with IPv6, API Server is only available in its IPv4 address. However, the client does not seem to fallback to the API Server ipv4. The error is:

request to https://somenumber.gr7.us-east-1.eks.amazonaws.com/apis/lms.krestomat.io/v1alpha1/lmsmoodles failed, reason: connect ETIMEDOUT 64:ff9b::a00:911c:443

** Client Version **
1.0.0-rc4

** Server Version **
1.29.3

To Reproduce

• EKS IPv6 cluster
• Call API server endpoint using the javascript client

Expected behavior
IPv4 is use if IPv6 is not accesible. Or at least it can be configured to use ipv4 resolution

Environment (please complete the following information):

• OS: Centos Stream 9
• NodeJS Version: 18
• Cloud runtime: EKS

[brendandburns]

I don't think that this is inside this client.

[jobcespedes]

You might be right. It seemed like an infra issue in EKS. Nonetheless, some troubleshooting findings suggested it was the client or node server: I used curl to make a request to the API Server endpoint in the same container node server and the client are running. With verbose output, it resolved to IPv6 and then IPv4 address and the request was successful. However, using explicit resolve option with the IPv6 address, curl also timeout. However, the error message reported above by the function calling the client seems to indicate the client is only trying the IPv6 address of the API server. Unfortunately, EKS API server does not work with its ipv6 address, despite one being assigned.

[jobcespedes]

Currently lookin at node option autoSelectFamily: true from https://nodejs.org/docs/latest-v18.x/api/net.html#socketconnectoptions-connectlistener; or --dns-result-order=ipv4first

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

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-sigs/prow repository.