Support for DualStack IPv4/Ipv6

[qwerp]

is there a way we can enable DualStack Support on "Kubernetes" part. (not on settingup cloud component on AWS).

for instance,

I have successfully configured a DualStack Setup for the physical nodes.

(this is a one control plane 2x node setup)

#> kubectl get nodes -o=custom-columns="NAME:.metadata.name,ADDRESSES:.status.addresses[?(@.type=='InternalIP')].address,PODCIDRS:.spec.podCIDRs[*]" NAME ADDRESSES PODCIDRS i-05b36e8afa33fd240 2406:da1a:d4d:b805::e5e7,172.24.108.176 2406:da1a:d4d:b805:bacb::/80 i-07dd78d533265ec1c 2406:da1a:d4d:b803::fd1d,172.24.42.237 2406:da1a:d4d:b803:823b::/80 i-0828d9ace7f498ca9 2406:da1a:d4d:b804::16cc,172.24.78.179 2406:da1a:d4d:b804:714c::/80

as you can see we have physical dual ip on the host, however will need to configure multip podcidrs to fully enable dualstack on kubernetes.

https://kubernetes.io/docs/concepts/services-networking/dual-stack/

it will need to set --service-cluster-ip-range=<IPv4 CIDR>,<IPv6 CIDR> --cluster-cidr=<IPv4 CIDR>,<IPv6 CIDR> --node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6

which are currently not supported. clusterCIDR: description: ClusterCIDR is CIDR Range for Pods in cluster. type: string

          serviceClusterIPRange:
            description: ServiceClusterIPRange is the CIDR, from the internal
              network, where we allocate IPs for services
            type: string

currently only support a single "entry"

also, there is no support for --node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6

or is there a alternate way to enable this? Thanks.

[hakman]

Hi @qwerp, there is no way to enable DualStack with kOps. There is also no plan to support it in the future.

[qwerp]

Can i kindly ask for some recommendation on how would be the best way to run a "dual stack" API Service using Kops?

Any recommendation?

Thanks

[justinsb]

Our working theory in kOps is that dual-stack gives the all the downsides of IPv4, so it's less useful to then use IPv6.

However, we know that (for example) the pure IPv6 clusters aren't as reachable from IPv4 clients (but I think there are some workarounds using AWS load balancers). But I think we have support for reaching IPv4-only internet services from IPv6-only Pods.

What is your use-case - what are you trying to achieve here?

[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.