Test:

# kubectl get gateway my-gateway -oyaml
apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  creationTimestamp: "2024-06-11T06:19:15Z"
  generation: 8
  name: my-gateway
  namespace: default
  resourceVersion: "3293345"
  uid: 41a0fb4c-4781-4e34-a1fd-462762fbc6f3
spec:
  addresses:
  - type: IPAddress
    value: 172.18.0.140
  gatewayClassName: cilium
  listeners:
  - allowedRoutes:
      namespaces:
        from: Same
    name: web-gw
    port: 80
    protocol: HTTP
status:
  addresses:
  - type: IPAddress
    value: 172.18.0.140
  conditions:
  - lastTransitionTime: "2024-06-11T08:04:55Z"
    message: Gateway successfully scheduled
    observedGeneration: 8
    reason: Accepted
    status: "True"
    type: Accepted
  - lastTransitionTime: "2024-06-11T08:04:55Z"
    message: Gateway successfully reconciled
    observedGeneration: 8
    reason: Programmed
    status: "True"
    type: Programmed
  listeners:
  - attachedRoutes: 1
    conditions:
    - lastTransitionTime: "2024-06-11T08:04:55Z"
      message: Listener Programmed
      observedGeneration: 8
      reason: Programmed
      status: "True"
      type: Programmed
    - lastTransitionTime: "2024-06-11T08:04:55Z"
      message: Listener Accepted
      observedGeneration: 8
      reason: Accepted
      status: "True"
      type: Accepted
    - lastTransitionTime: "2024-06-11T08:04:55Z"
      message: Resolved Refs
      reason: ResolvedRefs
      status: "True"
      type: ResolvedRefs
    name: web-gw
    supportedKinds:
    - group: gateway.networking.k8s.io
      kind: HTTPRoute

/test

/cc @sayboras PTAL.

Thanks for your PR.

The current Gateway API is with kind + L2LB setup, so I assume that we can enable GatewayStaticAddresses theoretically? Probably we need to check how the upstream test is configured with additional params.

Exempt feature:

Related PR on l2lb: #28926

Another point is to highlight the feature dependency L2LB + Gateway Address for end user.

Another point is to highlight the feature dependency L2LB + Gateway Address for end user.

Should I highlight this in the cilium document?

/test

/ci-gateway-api

/ci-aks

Should I highlight this in the cilium document?

yes, it will be awesome. We can update the docs in a separate PR as well.

Thanks for this PR @chaunceyjiang! This is a great start, but as Tam says, it only addresses the case that the cluster is using Cilium's LBIPAM. If the cluster is using another Loadbalancer provider (for example, if it's running in a cloud), this won't work.

In order for this to work, this code will need to grow some way to know what loadbalancer provider it should use (Cilium LBIPAM, a cloud provider, or something else), so that it can know what annotations to add.

I suppose we could add this as is, but I suspect that even if we put a big "ONLY WORKS WITH CILIUM LB IPAM", then we will get a bunch of issues from folks who try it in EKS, GKE, or AKS, where this won't work.

This pull request has been automatically marked as stale because it
has not had recent activity. It will be closed if no further activity
occurs. Thank you for your contributions.

Hi, @sayboras @youngnick

The Conformance/GatewayStaticAddresses conformance test has passed in my local environment. However, there are currently two issues that need to be discussed with you.

1. Where should the documentation be written?
2. During CI execution, how should the parameters UNUSABLE_NETWORK_ADDRESSES and USABLE_NETWORK_ADDRESSES be passed to the conformance test?

We'll need an update to the documentation in Documentation/network/servicemesh/gateway-api. I think the best way would be a new .rst file similar to the host-network-mode.rst one that documents the feature, along with clearly calling out that it's only available for LB-IPAM.

Writing that out, I think I'm going to end up being super picky about it, so it's probably better that I just write the docs as a followup once this merges. Let's get the feature in first, and I'll document it.

I think this one also updates #21926 - although it won't close it, since we may need to add support for more deployment scenarios in the future.

Thanks again for pushing this ahead, really appreciated!

/cc @sayboras @youngnick PTAL.

/test

/cc @youngnick PTAL.