Support multiple addresses (including IPv6) about ingress-gce HOT 40 CLOSED

/assign

from ingress-gce.

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.

from ingress-gce.

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

from ingress-gce.

Hi! Any progress / ETA for this?

from ingress-gce.

+1 this would be very helpful

from ingress-gce.

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

from ingress-gce.

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.

from ingress-gce.

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

from ingress-gce.

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.

from ingress-gce.

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

from ingress-gce.

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.

from ingress-gce.

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

from ingress-gce.

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

from ingress-gce.

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

from ingress-gce.

+1

from ingress-gce.

Any update ?

from ingress-gce.

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

from ingress-gce.

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?

from ingress-gce.

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

from ingress-gce.

Also you will have 2 load balancers in GCP

from ingress-gce.

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

from ingress-gce.

from ingress-gce.

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.

from ingress-gce.

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?

from ingress-gce.

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

from ingress-gce.

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

from ingress-gce.

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?

from ingress-gce.

/good-first-issue
/help-wanted

from ingress-gce.

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

from ingress-gce.

I'd like to take this issue.

from ingress-gce.

+1 this would be very helpful.

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

from ingress-gce.

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 ༼ つ ◕_◕ ༽つ

from ingress-gce.

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

from ingress-gce.

/lifecycle frozen

from ingress-gce.

Optimistically tried

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

no luck yet.

from ingress-gce.

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

from ingress-gce.

Any news?

from ingress-gce.

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

How is the Gateway API solving this?

from ingress-gce.

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'

from ingress-gce.

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?

from ingress-gce.