Support NodePort and LoadBalancer Service Types for GatewayStatus Addresses field

[kate-osborn]

Set the GatewayStatus addresses field based on the type of Service that exposes NKG.

The initial issue for supporting GatewayStatus addresses is limited in scope and will set the GatewayStatus address field to the ClusterIP of the Service, regardless of the Service type.

This issue covers the work to support addresses for LoadBalancer and NodePort Services.

Acceptance

• When the user gets the GatewayStatus, the IP address of the service that fronts the Gateway is present in the addresses field when the fronting service is either a NodePort or LoadBalancer.

[ciarams87]

Note: this is a blocker for external-dns integration (we need the address from the fronting LoadBalancer Service).

[sjberman]

Another note: we set the GatewayStatus to the Pod IP, not the Service's ClusterIP. Should we also support ClusterIP as part of this story? (or maybe not since we'll always use the NodePort or LoadBalancer IP?)

[brianehlert]

Another note: we set the GatewayStatus to the Pod IP, not the Service's ClusterIP. Should we also support ClusterIP as part of this story? (or maybe not since we'll always use the NodePort or LoadBalancer IP?)

Service ClusterIP is not appropriate. Since the Gateway is always fronting the service. You got there.

[sjberman]

Do we want to support setting the address to Hostname if available? (https://github.com/kubernetes-sigs/gateway-api/blob/main/apis/v1beta1/shared_types.go#L719)

Or do we only support IP addresses right now?

[kate-osborn]

Do we want to support setting the address to Hostname if available? (https://github.com/kubernetes-sigs/gateway-api/blob/main/apis/v1beta1/shared_types.go#L719)

Or do we only support IP addresses right now?

I think we also want to support Hostname since some LoadBalancers (like AWS NLB) will be exposed with a dns name instead of an IP address.

[sjberman]

Decided to punt on NodePort support for now: #1142