Adding GEP-3539: Gateway API to Expose Pods on Cluster-Internal IP Address (ClusterIP Gateway)

[ptrivedi]

Recommend reviewing deploy preview so examples are inlined: https://deploy-preview-3608--kubernetes-sigs-gateway-api.netlify.app/geps/gep-3539/

Signed-off-by: Pooja Trivedi [email protected]

What type of PR is this?

/kind gep

What this PR does / why we need it:

This defines via documentation how Gateway API can be used to accomplish ClusterIP Service behavior. It also proposes DNS record format for ClusterIP Gateway, proposes an EndpointSelector resource, and briefly touches upon Gateway API usage to define LoadBalancer and NodePort behaviors.

Which issue(s) this PR fixes:

Fixes #3539

Does this PR introduce a user-facing change?:

NONE

[linux-foundation-easycla[bot]]

The committers listed above are authorized under a signed CLA.

• :white_check_mark: login: ptrivedi / name: Pooja Trivedi (b2aac6ef1d67ee61bb1ba1c3965f117d62034237, 72865bda630c1c136906a4a81d4b05f92ed3689c, 6a061ca86d3e7c9dcf2df120f9b359fac2688374, 5176c6defe270262f4fed349715bf54ba8ad394e, 741292c4058c374250e5e436f1eb914122baa54a, e876ced0d9134763a37b77838a710d576a3f1553)

[k8s-ci-robot]

Hi @ptrivedi. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions 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.

[ptrivedi]

Adding this comment here for tracking a few open items resulting from the comments on the google doc here: https://docs.google.com/document/d/1N-C-dBHfyfwkKufknwKTDLAw4AP2BnJlnmx0dB-cC4U/edit?tab=t.0

1. Topology aware routing feature needs to be discussed and hashed out in detail. Features like internal/externalTrafficPolicy should then be appropriately morphed and provided as a part of topology aware routing
2. EndpointSelector resource and DNS for Gateway topics warrant followup GEPs focused on these areas
3. Headless, ExternalName, and other DNS functionality may warrant separate DNS API/Object. Subject to further discussion
4. Need broader discussion around where do we implement this functionality, does it replace Service API completely in the long term and that we should have a migration plan, or does it become an underlying implementation for Service functionality allowing the simpler UX provided by Service API to be unchanged for end users while allowing advanced users to deal with Gateway API resources directly

@robscott @bowei @aojea @howardjohn @mskrocki

[ptrivedi]

/assign @thockin

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: ptrivedi Once this PR has been reviewed and has the lgtm label, please ask for approval from thockin. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment Approvers can cancel approval by writing /approve cancel in a comment

[gauravkghildiyal]

/cc

[bowei]

/ok-to-test

[bowei]

/assign

[youngnick]

I still haven't had the bandwidth to come back and give this a full, proper pass, but I did want to point out that, while this PR is currently targeting "Provisional" status, which isn't bound by Gateway API's release cycle, if you did want to look at moving this to Experimental (and thus, having something be implementable) this year, an item needs to be added to the Scoping discussion at #3760 to cover including it there.

If folks don't feel there will be bandwidth to push this forward, we can concentrate on getting this into Provisional in the v1.4 timeframe, then look at Experimental for v1.5.

[ptrivedi]

I still haven't had the bandwidth to come back and give this a full, proper pass, but I did want to point out that, while this PR is currently targeting "Provisional" status, which isn't bound by Gateway API's release cycle, if you did want to look at moving this to Experimental (and thus, having something be implementable) this year, an item needs to be added to the Scoping discussion at #3760 to cover including it there.

If folks don't feel there will be bandwidth to push this forward, we can concentrate on getting this into Provisional in the v1.4 timeframe, then look at Experimental for v1.5.

Yes, there will not be bandwidth to push this forward during this cycle, hence I did not add anything to the scoping discussion. Also there are open questions that need to be addressed and discussion areas to be kicked off.

[ptrivedi]

I still haven't had the bandwidth to come back and give this a full, proper pass, but I did want to point out that, while this PR is currently targeting "Provisional" status, which isn't bound by Gateway API's release cycle, if you did want to look at moving this to Experimental (and thus, having something be implementable) this year, an item needs to be added to the Scoping discussion at #3760 to cover including it there.

If folks don't feel there will be bandwidth to push this forward, we can concentrate on getting this into Provisional in the v1.4 timeframe, then look at Experimental for v1.5.

@youngnick target would have to be Provisional in the v1.4 timeframe, given bandwidth constraints.

[aojea]

I was checking the feasibility of this disaggregation last weekend and it was not as complex as I thought. Having a new object like

// EndpointSelectorSpec describes the desired state of an EndpointSelector.
type EndpointSelectorSpec struct {
	// labelSelector for selecting pods.
	// +optional
	LabelSelector *metav1.LabelSelector `json:"labelSelector,omitempty"`

	// ports defines the port information for the EndpointSlices.
	// This field is optional. If you leave it out, EndpointSlices will be created
	// without port information. This can be useful for L3-only routing.
	// +optional
	Ports []EndpointSelectorPort `json:"ports,omitempty"`
}

and when you create a Service anendpointSelector-Controller in the kube-controller-manager derives an EndpointSelector object from the existing Service selector, and the endpointslices-controller generates the EndpointSlices from the selector keeps backwards compatibility for the simple scenarios and allow to solve two issues like Service with all Ports or better selectors for Services.

The problem is with the generation of the EndpointSlices, because we leaked the TrafficDistribution and other Service details on the generation it require some thoughts on how to handle this to maintain the backwards compatibiliy