Support multiple addresses (including IPv6)

[nikhiljindal]

The ingress spec supports specifying an ip address with the kubernetes.io/ingress.global-static-ip-name annotation, but the ingress-gce controller assumes that it is an ipv4 IP address.

GCLB supports specifying both an ipv4 and ipv6 IPs as per: https://cloud.google.com/compute/docs/load-balancing/http/cross-region-example.

Are there plans to support ipv6?
I tried to find an existing issue, but didnt and hence am filling this. Feel free to close as duplicate if there is an existing issue.

cc @bowei @nicksardo @csbell

[nikhiljindal]

One potential way to support it could be to add another annotation kubernetes.io/ingress.global-static-ipv6-name and the controller will then handle it appropriately?

Anything else I am missing?

[nicksardo]

I've looked at the code and don't see any assumptions on IPv4, but I agree it would be nice to support both simultanously. Instead of making it a separate annotation, what if we make that annotation CSV capable? Any reason why we shouldn't support N addresses per ingress? Only allowing 1 ipv4 and 1 ipv6 seems unnecessarily restrictive if the GCLB can handle it...

[nikhiljindal]

Yes good point. Will try to play with multiple IP addresses with GCLB and see how it goes.

FWIW, this was in response to user feedback on kubemci where users want to specify both an ipv4 and an ipv6 address.

[aaron-trout]

Are there any issues preventing this field being migrated from an annotation to a proper item in the IngressSpec somewhere? Attaching one or more static IP addresses to the load balancer seems like it would be useful across providers / not google cloud specific.

One that springs to mind now that I am writing this is non-provider ingress controllers like nginx or traefik...

[thockin]

@aaron-trout The issue is that there's no universal way to describe that (is it an IP value or a named IP in some control plane) nor is it implementable on all (or even most) ingresses.

[bmhatfield]

Hey there - thanks for maintaining ingress-gce :-)

I just wanted to chime in and say that I've also hit this issue but have been unable to determine a workaround. Perhaps the second ingress using an IPv6 is appropriate?

[mofirouz]

I'd really like to have this feature where an Ingress/LB setup via Kube will have both an IPv4 and IPv6 address. Most apps/games that are developed for iOS require IPv6 for App Store submission. This is a hard requirement from Apple.

Can we use this as a valid request to push for supporting IPv6 LB frontend support via Kube?

[sijnc]

We use loadBalancerSourceRanges to restrict access to staging environments. We're starting to see residential ISPs issuing IPv6 addresses and we are unable to provide stage access to these clients because of this issue. I suspect we'll start seeing even more IPv6 in the future making the problem even worse. We really need this ASAP so another +1 for getting this working in GKE. I'm ok with using an annotation until a proper fix is found. @thockin

[thockin]

Note that Load-balancer source ranges is a totally different feature than Ingress. I have no problem adding support for V6 IPs to ingress-gce. Need to see a specialist for how they get defined and stored in status, but otherwise fine with me. Volunteers?

…

On Mon, Aug 27, 2018, 11:15 AM sijnc ***@***.***> wrote: We use loadBalancerSourceRanges to restrict access to staging environments. We're starting to see residential ISPs issuing IPv6 addresses and we are unable to provide stage access to these clients because of this issue. I suspect we'll start seeing even more IPv6 in the future making the problem even worse. We really need this ASAP so another +1 for getting this working in GKE. I'm ok with using an annotation until a proper fix is found. @thockin <https://github.com/thockin> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#87 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AFVgVNRUuhIvf8eGb3QO1v9akmeyDUl-ks5uVDdegaJpZM4RKQ7I> .

[rramkumar1]

/good-first-issue
/help-wanted

[k8s-ci-robot]

@rramkumar1:
This request has been marked as suitable for new contributors.

Please ensure the request meets the requirements listed here.

If this request no longer meets these requirements, the label can be removed
by commenting with the /remove-good-first-issue command.

In response to this:

/good-first-issue
/help-wanted

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.

[adrianlop]

no news here guys? we need simultaneous IPv4 and IPv6 in the same Ingress/GCP LB too
will try creating a second Ingress for now.

[agadelshin]

I'd like to take this issue.

[sammy]

+1 this would be very helpful.

For the time being we manually assign a second ip to the loadbalancer created via the GCP console

[abevoelker]

This would be very nice to have. As it stands, cert-manager, a popular TLS certificate solution on GKE due to lack of managed certs, runs into difficulties when trying to do IPv4 + IPv6 for the same host on two separate Ingresses.

༼ つ ◕_◕ ༽つ @pondohva take my energy ༼ つ ◕_◕ ༽つ

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[bowei]

/lifecycle frozen

[purificant]

+1 this would be very helpful

[Arachnid]

IPv6 / multiple IP support would be really useful, and long overdue.

[nicholasklem]

Optimistically tried

kubernetes.io/ingress.global-static-ip-name: "api-customer-ipv4,api-customer-ipv6"

no luck yet.

[bowei]

We are tracking this in the backlog. It looks at first blush straightforward to support...

[bowei]

/assign

[nikars]

Hi! Any progress / ETA for this?

[Darkspirit]

This bug is the root cause why Mozilla doesn't support IPv6 for most services.

[WesleyVestjens]

Although it's not really obvious, it's actually possible to make the same resource available through dual-stack IPv4 and IPv6. We've accomplished this by creating 2 ingresses pointing at the same resource:

---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: my-project-name-ingress-ipv4
  annotations:
    kubernetes.io/ingress.global-static-ip-name: "ipv4-static-address"
    networking.gke.io/managed-certificates: my-certificate,my-other-certificate
spec:
  backend:
    serviceName: my-service-name
    servicePort: 80
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: my-project-name-ingress-ipv6
  annotations:
    kubernetes.io/ingress.global-static-ip-name: "ipv6-static-address"
    networking.gke.io/managed-certificates: my-certificate,my-other-certificate
spec:
  backend:
    serviceName: my-service-name
    servicePort: 80

[nappy]

make the same resource available through dual-stack IPv4 and IPv6

Since you will need 2 configurations, 2 ingresses and are charged 2 times, I would not agree with the term dual-stack.
I would call that double-stack.

[agadelshin]

Also you will have 2 load balancers in GCP

[WesleyVestjens]

I agree, it's not an ideal solution, but for those who absolutely need it, it offers a way to get it done for now.

[avasani]

What is the status of this issue? Is anyone working on this?

[nicholasklem]

Any news?

[bowei]

PRs are welcome -- we are looking into the prioritization for this feature.

[joelsdc]

What do you guys need from the community to get this prioritized?

On a side note, we've tried adding manually (via GUI / gcloud) an IPv6 front-end to the GKE-Ingress created load balancer and it seems to work, in our case we also use self-managed SSL certs and when we patch the ingress.gcp.kubernetes.io/pre-shared-cert annotation to make an update the changes are not applied to the load balancer front-ends, I think that with google-managed SSL certs it might work, however this workaround is ugly and unreliable at best.

[nzapponi]

+1

[leonelvsc]

Any update ?

[olivierboucher]

@bowei I'm looking to work on this. Would the new annotation being proposed by @nikhiljindal be the way to go?

[swetharepakula]

With the introduction of the Gateway API, we will look to add dual stack support there.

[koenpunt]

With the introduction of the Gateway API, we will look to add dual stack support there.

How is the Gateway API solving this?

[jeremyvisser]

Because the Gateway API has explicit support for multiple addresses: https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1beta1.Gateway

---
apiVersion: gateway.networking.k8s.io/v1beta1
kind: Gateway
spec:
  addresses:
  - value: '10.0.0.1'
  - value: '2001:db8::1'

[koenpunt]

While we do like to use the Kubernetes Gateway API, the lack of Cloud CDN support still prevents us from using it.

[willianmga]

Still facing the issue of adding a second IP to the Ingress. And none of the workarounds suggested works because:

• Migrating to Gateway API won't be possible because it does not have support for cloud CDN
• Using two different Ingresses won't work because CertManager only supports setting up one of them for the http01 challenge. If you setup the ipv4 ingress, then let's encrypt will not issue the certificate because it will reach the ipv6 ingress by default. If you setup the ipv6 ingress, then CertManager won't be able to get its self check done because it can't reach an IPv6 IP from an IPv4 cluster.

Anybody still having similar issues that makes the workarounds unsuitable?

Any thoughts on how these challenges could be solved?