Enabling global access for internal HTTP(S) load balancer

[oofnikj]

I'm having an issue trying to create an internal L7 load balancer through the GCE ingress controller with global access enabled. In the docs, the following is written:

An internal HTTP(S) load balancer's forwarding rules are regional, even when global access is enabled. After you enable global access, the regional internal forwarding rule's allowGlobalAccess flag is set to true.

On another page, it's stated that global access cannot be enabled for existing forwarding rules. I confirmed this by running

% gcloud compute forwarding-rules update k8s2-fr-xxxxxxxx-monitoring-grafana-zzzzzzzz --region=us-central1 --allow-global-access
ERROR: (gcloud.compute.forwarding-rules.update) Could not fetch resource:
 - Invalid value for field 'resource.allowGlobalAccess': 'true'. Updating the allow-global-access flag is only supported for regional INTERNAL forwarding rules with backend service/target instance.

Once the load balancer and associated forwarding rule is created by the ingress controller, I tried manually creating a new forwarding rule and attaching it to the existing target HTTP proxy with global access enabled, which worked as expected. I would like to know if there is a way to do this declaratively through ingress annotations or some other means?

[hatemosphere]

we are actually experiencing the same issue here. we want to be able to access internal HTTP(s) LB residing in a different region while having VPC peering established between VPCs in two different regions. it's definitely technically possible to do that by manually creating a new global forwarding rule on top of existing non-global LB, but it's not clear how to do it via k8s Ingress object.

[cezarygerard]

/kind feature

the GCE L7 ILB is not yet supported by kubernetes' ingress-gce

[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/test-infra repository.