envoyproxy / envoyproxy/gateway

Gateway `ExternalIP` assignement

Open
#7,426 14 comments 0 reactions 1 assignee Claimed by @cnvergence View on GitHub
area/infra-mgr no stalebot provider/kubernetes
Dominant language
Go
Stars
3k
Forks
864
Avg merge
2d 2h
Merged PRs (30d)
140

Description

Good morning,

I have a `GatewayClass` with an `EnvoyProxy` config that sets `mergeGateways` to `true` and assigns an `ExternalIP` to the corresponding service.

```yaml
apiVersion: gateway.envoyproxy.io/v1alpha1
kind: EnvoyProxy
# ...
spec:
mergeGateways: true
provider:
kubernetes:
envoyService:
externalTrafficPolicy: Local
loadBalancerClass: io.cilium/bgp-control-plane
patch:
type: StrategicMerge
value:
spec:
externalIPs:
- 40.40.40.1
type: LoadBalancer
type: Kubernetes
```

When a user creates a `Gateway`, we expect external-dns to use the `ExternalIP` of the gateway as target. However, it's using the address mentioned in the gateway `Status`, which refers to the LB IP:

```yaml
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
# ...
status:
addresses:
- type: IPAddress
value: 10.10.10.3
```

Some time ago I was told I can work around by setting the `Spec.Addresses` field on the `Gateway`. It works fine, although it actually doesn't care about the configured value, as it would read it from the `Service` if it exists.

```yaml
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
# ...
spec:
addresses:
- type: IPAddress
value: 1.2.3.4
# ...
status:
addresses:
- type: IPAddress
value: 40.40.40.1
```

I'm wondering if this could be reworked to make it a bit more intuitive -- happy to contribute if need be.
In my case, I'm managing the `GatewayClass` and users are responsible for deploying their own `Gateway` -- so I don't really want to tell them they have to put a dummy IP (this is confusing) or the public IP (which varies depending on the env/site/..) in their manifests.

I'm thinking about something like this:
1. if the gateway has an address defined, use this one (ofc some validation is required here)
2. then, use the external IP of the service if it exists
3. otherwise, reuse the existing logic depending on the service type (LB, ClusterIP, ..)

FYI the logic comes from this piece of code: https://github.com/envoyproxy/gateway/blob/main/internal/gatewayapi/status/gateway.go#L55

Any feedback or idea is welcome, thanks!

Contributor guide

No contributing guide indexed for this repository

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.