Introduction

When you create a Kubernetes Ingress on Google Kubernetes Engine, Google Cloud usually provisions an external HTTP load balancer behind the scenes. That load balancer eventually gets an external IP address, and many teams want Terraform to expose that value as an output for DNS, certificates, or deployment logs.

The tricky part is timing. Terraform can declare the Ingress resource, but the actual IP is assigned asynchronously by the Kubernetes controller and Google Cloud infrastructure after the resource exists.

Reading the Ingress Status from Terraform

If you manage the Ingress with the Kubernetes provider, the load balancer address is usually available through the resource status once provisioning completes.

A typical configuration looks like this:

1resource "kubernetes_ingress_v1" "app" {
2  metadata {
3    name = "app-ingress"
4  }
5
6  spec {
7    default_backend {
8      service {
9        name = "app-service"
10        port {
11          number = 80
12        }
13      }
14    }
15  }
16}
17
18output "ingress_ip" {
19  value = try(
20    kubernetes_ingress_v1.app.status[0].load_balancer[0].ingress[0].ip,
21    null
22  )
23}

The try call matters because the status block may be empty during the first apply while the load balancer is still being created.

Depending on the ingress controller, the address may appear in ip or hostname. For the default GKE HTTP load balancer, ip is the usual field to check.

Why the Output Is Sometimes Null

An Ingress does not receive an external address the instant Terraform submits it. Several background steps must happen first:

• The Kubernetes controller notices the Ingress
• Google Cloud provisions the load balancer resources
• Health checks and backend wiring are created
• The external IP is assigned and written back to Ingress status

Terraform finishes its resource operation before some of that asynchronous work completes. As a result, your output may be null on the first run and populated on a later refresh or apply.

This is not always a Terraform bug. It is often just the boundary between declarative infrastructure and an eventually consistent control plane.

The More Reliable Pattern: Reserve a Static IP

If you need a deterministic value, reserve a global static IP in Google Cloud first and tell the Ingress to use it. Then Terraform can output the address directly from the Google resource without waiting for Ingress status propagation.

1resource "google_compute_global_address" "app" {
2  name = "app-ingress-ip"
3}
4
5resource "kubernetes_ingress_v1" "app" {
6  metadata {
7    name = "app-ingress"
8    annotations = {
9      "kubernetes.io/ingress.global-static-ip-name" = google_compute_global_address.app.name
10    }
11  }
12
13  spec {
14    default_backend {
15      service {
16        name = "app-service"
17        port {
18          number = 80
19        }
20      }
21    }
22  }
23}
24
25output "reserved_ingress_ip" {
26  value = google_compute_global_address.app.address
27}

This is usually the best production design because the address is stable across Ingress recreation and easier to plug into DNS management.

When You Need the Actual Controller Status

Sometimes you still want the live Ingress status because you are integrating with an existing cluster or you do not control static IP allocation. In that case, use Terraform output from the Kubernetes resource, but expect that:

• The first apply may not produce the final value
• A refresh-only run or second apply may be needed
• Misconfigured backends can prevent the address from appearing

If the output stays empty longer than expected, inspect the Ingress directly:

kubectl get ingress app-ingress -o yaml
kubectl describe ingress app-ingress

Those commands often reveal missing annotations, backend service issues, or controller events that Terraform itself does not surface clearly.

DNS and Operational Considerations

If you plan to create DNS records from the load balancer IP, a reserved static address is strongly preferred. Without it, a destroyed and recreated Ingress may receive a different IP, which forces downstream updates and increases outage risk.

In multi-environment setups, it also helps to treat the IP as a first-class infrastructure resource. That keeps network identity under Terraform control instead of relying on a controller to assign an address opportunistically.

Common Pitfalls

The most common pitfall is assuming the Ingress IP will always be available in the same apply that creates the resource. In GKE, asynchronous provisioning often breaks that assumption.

Another issue is reading the wrong field. Some ingress controllers populate hostname instead of ip, so always inspect the actual status if your output is empty.

It is also easy to forget that the Kubernetes provider only knows what the API server reports. If the controller has not updated status yet, Terraform has nothing to output.

Finally, if you need a stable public endpoint, do not depend on an ephemeral assigned IP when a reserved global address is available.

Summary

• Terraform can output a GKE Ingress load balancer address from Ingress status once the controller has populated it.
• The status may be empty on the first apply because load balancer provisioning is asynchronous.
• 'try(...) is useful to avoid failures when status fields are not ready yet.'
• Reserving a google_compute_global_address is usually the most reliable production pattern.
• If the output remains empty, inspect the live Ingress with kubectl to debug controller state.