TBD: Support different classes of Gateway API#1990
TBD: Support different classes of Gateway API#1990rikatz wants to merge 1 commit intoopenshift:masterfrom
Conversation
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
@rikatz: The following test failed, say
Full PR test history. Your PR dashboard. DetailsInstructions 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-sigs/prow repository. I understand the commands that are listed here. |
| Each GatewayClass maps to a specific service type and | ||
| configuration: external LoadBalancer, internal LoadBalancer, or | ||
| ClusterIP. The Cluster Ingress Operator (CIO) provisions a default | ||
| ConfigMap per GatewayClass using the sail-operator library, |
There was a problem hiding this comment.
minor point - is this implying the sail-operator would create the config map for us, and thus the OSSM team owns the logic? I don't think that's what we would want - CIO should own creating the gatewayclasses right?
|
|
||
| ## Proposal | ||
|
|
||
| The Cluster Ingress Operator will be extended to recognize three |
There was a problem hiding this comment.
Hmm what about discoverability? It feels like we should auto create the gatewayclasses, otherwise, it's not clear that they are available to the user.
We could either:
- Keep workflow as
openshift-defaultinstalls GWAPI and CIO creates the 3 new gatewayclasses afteropenshift-defaultis created - Enable all
openshift-*to install GWAPI (like you have described here), but create the other 3 when installing.
Thoughts? Maybe it's not that big of a deal, but it would be a nice-to-have UX improvement.
2 participants
What
Enhancement proposal for supporting different Gateway API service topologies via dedicated GatewayClasses (
openshift-external,openshift-internal,openshift-clusterip), allowing users to provision Gateways with the right service configuration based on the GatewayClass they select.Why
Today, the
openshift-defaultGatewayClass always provisions an external LoadBalancer service. Users who need internal LoadBalancers or ClusterIP services must manually patch the provisioned service, which is fragile and unsupported. Cluster administrators need a declarative way to get the right service topology — including platform-specific annotations,externalTrafficPolicy, and OVNlocal-with-fallback— automatically applied, the same way CIO already does for IngressControllers. This is also a common pattern in other Gateway API implementations where different GatewayClasses map to different service configurations. Backporting is desired for existing OCP deployments.Changes
enhancements/ingress/support-different-gateway-api-service-provisioning-with-different-gatewayclass.mdopenshift-external: external LoadBalancer with platform-specific annotations (AWS NLB, Azure, GCP, IBM, OpenStack)openshift-internal: internal LoadBalancer with the corresponding internal annotations per platformopenshift-clusterip: ClusterIP service, no LoadBalancer or DNS provisionedopenshift-*GatewayClass name prefix is reserved for the OpenShift controller name, and only the four allowlisted class names are permitted (CREATE-only, since name and controllerName are immutable)externalTrafficPolicyand OVNlocal-with-fallbackannotation