Add session persistence conformance tests by salonichf5 · Pull Request #4482 · kubernetes-sigs/gateway-api

salonichf5 · 2026-02-03T20:58:23Z

What type of PR is this?
/kind gep
/kind test

Optionally add one or more of the following kinds if applicable:
/area conformance-test

What this PR does / why we need it:

Which issue(s) this PR fixes:
Fixes #4258

Does this PR introduce a user-facing change?:
NONE

NONE

k8s-ci-robot · 2026-02-03T20:58:32Z

[APPROVALNOTIFIER] This PR is NOT APPROVED

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

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

Details

Needs approval from an approver in each of these files:

geps/OWNERS

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

k8s-ci-robot · 2026-02-03T20:58:34Z

Hi @salonichf5. 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.

Details

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.

robscott · 2026-02-05T05:46:27Z

Thanks @salonichf5!

/ok-to-test
/cc @DamianSawicki

k8s-ci-robot · 2026-02-05T05:46:29Z

@robscott: GitHub didn't allow me to request PR reviews from the following users: DamianSawicki.

Note that only kubernetes-sigs members and repo collaborators can review this PR, and authors cannot review their own PRs.

Details

In response to this:

Thanks @salonichf5!

/ok-to-test
/cc @DamianSawicki

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.

geps/gep-1619/index.md

DamianSawicki · 2026-02-05T08:33:53Z

geps/gep-1619/index.md

+
+| Session Persistence with cookieConfig.lifetimeType: Permanent and absoluteTimeout: 5min. | HTTPRoute MUST have Accepted=True in parent status. Response Set-Cookie header MUST contain `expiry` attribute. The expiry value MUST correspond to the configured absoluteTimeout duration. Session persistence MUST function correctly until cookie expires.  | HTTPRouteSessionPersistence, HTTPRouteSessionPersistenceCookie, HTTPRouteSessionPersistenceCookiePermanentLifetime |
+
+| Session Persistence Scoped to Route Rule: HTTPRoute with two rules: Rule 1 (path /a) and Rule 2 (path /b), both with sessionPersistence configured, routing to the same backend Service with multiple pods. | HTTPRoute MUST have Accepted=True in parent status. Sessions MUST NOT be shared between /a and /b. Verify with: 1) Request to /a establishes session to Pod-X, 2) Request to /b may route to any pod (Pod-X or Pod-Y), 3) Subsequent requests to /a with session cookie MUST still route to Pod-X, 4) Subsequent requests to /b with its session cookie MUST route to whichever pod was selected for /b. | HTTPRouteSessionPersistence |


Request to /b may route to any pod (Pod-X or Pod-Y)

To confirm this, we'd also need to send multiple requests. It may be obvious to the author, but perhaps it would be good to spell it out in the GEP for all readers.

Subsequent requests to /b with its session cookie MUST route to whichever pod was selected for /b

Well, with multiple requests it will be multiple pods.

DamianSawicki

A few more thoughts.

DamianSawicki · 2026-02-05T09:11:04Z

geps/gep-1619/index.md

+| :---- | :---- | :---- | 
+| Simple Cookie Session Persistence: An HTTPRoute with sessionPersistence configured with type: Cookie (default) on a single backend in gateway-conformance-infra namespace. | HTTPRoute MUST have Accepted=True in parent status. First request MUST receive a Set-Cookie header in response. Subsequent requests with the cookie MUST route to the same backend pod. Verify by checking pod identity across N requests (N>=50). | HTTPRouteSessionPersistence, HTTPRouteSessionPersistenceCookie |
+
+| Session Cookie Lifetime (Default): HTTPRoute with sessionPersistence and cookieConfig.lifetimeType: Session (default). | HTTPRoute MUST have Accepted=True in parent status. Cookie MUST NOT contain `expiry` attributes. | HTTPRouteSessionPersistence, HTTPRouteSessionPersistenceCookie |


What about the case of two paths in one rule?

kind: HTTPRoute metadata: name: routeX spec: rules: - matches: - path: value: /a - path: value: /b backendRefs: - name: servicev1 sessionPersistence: name: session

should they be shared? I guess it may be technically challenging because there can be only one path specified in Set-Cookie (link). Do we want to specify the behavior here or leave it as implementation specific?

I wanted to keep it implementation specific only because how the path is determined for the session could be product specific. For NGINX, we take the longest common prefix of shared sessions for multiple path, and use that. But I would have to do some research for other implementations.

Agree, I want to update this in the GEP, it doesn't specify how or if the two paths on the same rule should share. I think it's likely we should prescribe sharing in the GEP, and then we can follow up with a new conformance test. For now, the current tests are fine.

DamianSawicki · 2026-02-05T09:11:08Z

geps/gep-1619/index.md

@@ -1077,6 +1077,29 @@ TODO
 - How do we provide a standard way to communicate that an implementation does not support Route Rule API?
    - Do we want something conceptually similar to the `IncompatibleFilters` reason?



This is not directly relevant to the changes in this PR, but before graduating the feature to Standard it would be good to have clarity about field names. I see sessionPersistence.sessionName and sessionPersistence.name used interchangeably in the GEP.

In sessionPersistence.sessionName we are repeating "session", which is generally discouraged. It also makes a misleading impression that this feature is about establishing some "session".

To be in line with the comment in the code snippet, it should ideally be sessionPersistence.tokenName, but that's probably overly technical, so perhaps sessionPersistence.name is close enough.

@DamianSawicki I agree with your points. I think name would work better. I can take this as an action when I update the GEP for #4268.

DamianSawicki · 2026-02-05T09:26:23Z

geps/gep-1619/index.md

+###  Feature Names
+
+* HTTPRouteSessionPersistence - Base feature for session persistence support
+* HTTPRouteSessionPersistenceCookie - Cookie-based session persistence (Core)


What is meant here by (Core)? As per

gateway-api/geps/gep-1619/index.md

Lines 619 to 622 in d8bb5d9

// SessionPersistence defines and configures session persistence

// for the route rule.

//

// Support: Extended

Session Persistence is in Extended rather than Core support on HTTPRoute, and similarly for GRPCRoute and BackendLBPolicy. As per https://gateway-api.sigs.k8s.io/concepts/conformance/#overlapping-support-levels, the entire feature should be in Extended support.

Right - you should actually remove HTTPRouteSessionPersistenceCookie altogether. The base/generic feature HTTPRouteSessionPersistence is the core functionality of the extended feature, which includes Cookie persistence, so to be consistent with other features, we should keep

HTTPRoute (Core) │ └─ HTTPRouteSessionPersistence (Extended) │ ├── Type: Cookie (core for HTTPRouteSessionPersistence) │ └── LifetimeType: Session (core for HTTPRouteSessionPersistence) │ └── HTTPRouteSessionPersistenceCookieLifetimeTypePermanent (Extended) └── LifetimeType: Permanent (Extended)

DamianSawicki · 2026-02-05T09:27:38Z

geps/gep-1619/index.md


+## Conformance Details
+
+###  Feature Names


What about the support in GRPCRoute and BackendLBPolicy? Is the intention here to prepare conformance tests for the HTTPRoute part and graduate it selectively to Standard, while keeping the rest in Experimental?

I think there's been some discussion around BackendLBPolicy to be retired so its been skipped on purpose. I need to add these for GRPR too, good catch
to just get started initial recommendation was this

I'm good with delaying BackendTrafficPolicy, as that is being re-considered. For GRPCRoute, you could add it here in this PR if you feel it's simple/similar enough, however I fine to add it in a follow-up PR.

salonichf5 · 2026-02-05T16:50:17Z

@DamianSawicki some things might feel unclear but we are also waiting on @gcs278 update of the GEP as per this issue

I have made a note that we need:

GRPCRoute conformance tests
Do we want conformance test for multiple paths
Clarify between extended and core
Clairfy between sessionPersistence.sessionName and sessionPersistence.name

@gcs278 I think in your update of the GEP you could tackle point 3. and 4. , if that is okay?

gcs278

@salonichf5 Thanks for the PR! Looks like a great start. I'm sorry about the delay in reviewing.

gcs278 · 2026-03-05T02:52:26Z

geps/gep-1619/index.md

@@ -1077,6 +1077,29 @@ TODO
 - How do we provide a standard way to communicate that an implementation does not support Route Rule API?
    - Do we want something conceptually similar to the `IncompatibleFilters` reason?



@DamianSawicki I agree with your points. I think name would work better. I can take this as an action when I update the GEP for #4268.

gcs278 · 2026-03-05T02:55:15Z

geps/gep-1619/index.md


+## Conformance Details
+
+###  Feature Names


I'm good with delaying BackendTrafficPolicy, as that is being re-considered. For GRPCRoute, you could add it here in this PR if you feel it's simple/similar enough, however I fine to add it in a follow-up PR.

gcs278 · 2026-03-05T20:54:17Z

geps/gep-1619/index.md

+###  Feature Names
+
+* HTTPRouteSessionPersistence - Base feature for session persistence support
+* HTTPRouteSessionPersistenceCookie - Cookie-based session persistence (Core)


Right - you should actually remove HTTPRouteSessionPersistenceCookie altogether. The base/generic feature HTTPRouteSessionPersistence is the core functionality of the extended feature, which includes Cookie persistence, so to be consistent with other features, we should keep

HTTPRoute (Core) │ └─ HTTPRouteSessionPersistence (Extended) │ ├── Type: Cookie (core for HTTPRouteSessionPersistence) │ └── LifetimeType: Session (core for HTTPRouteSessionPersistence) │ └── HTTPRouteSessionPersistenceCookieLifetimeTypePermanent (Extended) └── LifetimeType: Permanent (Extended)

gcs278 · 2026-03-05T21:02:09Z

geps/gep-1619/index.md

+* HTTPRouteSessionPersistence - Base feature for session persistence support
+* HTTPRouteSessionPersistenceCookie - Cookie-based session persistence (Core)
+* HTTPRouteSessionPersistenceCookieLifetimeTypePermanent - Permanent Lifetime for cookie-based session persistence (extended)
+


We should probably drop a note that this is still WIP, so folks aren't confused why it's not complete.

Suggested change

**Note**: Conformance tests are still WIP, and additional test coverage will be added in future PRs.

gcs278 · 2026-03-05T21:11:54Z

geps/gep-1619/index.md

+| Simple Cookie Session Persistence: An HTTPRoute with sessionPersistence configured with type: Cookie (default) on a single backend in gateway-conformance-infra namespace. | HTTPRoute MUST have Accepted=True in parent status. First request MUST receive a Set-Cookie header in response. Subsequent requests with the cookie MUST route to the same backend pod. Verify by checking pod identity across N requests (N>=50). | HTTPRouteSessionPersistence, HTTPRouteSessionPersistenceCookie |
+| Session Cookie Lifetime (Default): HTTPRoute with sessionPersistence and cookieConfig.lifetimeType: Session (default). | HTTPRoute MUST have Accepted=True in parent status. Cookie MUST NOT contain `expiry` attributes. | HTTPRouteSessionPersistence, HTTPRouteSessionPersistenceCookie |
+| Multiple Weighted Backends - Initial Distribution Honored: HTTPRoute with sessionPersistence and multiple backendRefs with weights (e.g., 70/30) on a path. | HTTPRoute MUST have Accepted=True in parent status. Initial requests (without session cookie) MUST respect weight distribution (~70/30 within statistical tolerance). Once session is established, subsequent requests with cookie MUST route to the same backend regardless of weight configuration.| HTTPRouteSessionPersistence, HTTPRouteSessionPersistenceCookie |
+| Session Persistence with cookieConfig.lifetimeType: Permanent and absoluteTimeout: 5min. | HTTPRoute MUST have Accepted=True in parent status. Response Set-Cookie header MUST contain `expiry` attribute. The expiry value MUST correspond to the configured absoluteTimeout duration. Session persistence MUST function correctly until cookie expires.  | HTTPRouteSessionPersistence, HTTPRouteSessionPersistenceCookie, HTTPRouteSessionPersistenceCookieLifetimeTypePermanent |


nit consider moving this down to the bottom, to have the core tests first, then the extended.

gcs278 · 2026-03-05T21:23:46Z

geps/gep-1619/index.md

+| :---- | :---- | :---- | 
+| Simple Cookie Session Persistence: An HTTPRoute with sessionPersistence configured with type: Cookie (default) on a single backend in gateway-conformance-infra namespace. | HTTPRoute MUST have Accepted=True in parent status. First request MUST receive a Set-Cookie header in response. Subsequent requests with the cookie MUST route to the same backend pod. Verify by checking pod identity across N requests (N>=50). | HTTPRouteSessionPersistence, HTTPRouteSessionPersistenceCookie |
+
+| Session Cookie Lifetime (Default): HTTPRoute with sessionPersistence and cookieConfig.lifetimeType: Session (default). | HTTPRoute MUST have Accepted=True in parent status. Cookie MUST NOT contain `expiry` attributes. | HTTPRouteSessionPersistence, HTTPRouteSessionPersistenceCookie |


Agree, I want to update this in the GEP, it doesn't specify how or if the two paths on the same rule should share. I think it's likely we should prescribe sharing in the GEP, and then we can follow up with a new conformance test. For now, the current tests are fine.

gcs278 · 2026-03-05T21:27:21Z

geps/gep-1619/index.md

@@ -1064,8 +1064,6 @@ supported by some implementations due to their current designs.

 ### Conformance Details


Let's remove this section. I think the template has changed a couple times, and what you have below is fine.

Suggested change

### Conformance Details

add session persistence conformance tests

0a0143d

k8s-ci-robot added do-not-merge/hold Indicates that a PR should not merge because someone has issued a /hold command. needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. size/S Denotes a PR that changes 10-29 lines, ignoring generated files. labels Feb 3, 2026

k8s-ci-robot requested a review from howardjohn February 3, 2026 20:58

k8s-ci-robot requested a review from robscott February 3, 2026 20:58

salonichf5 mentioned this pull request Feb 3, 2026

STD: Session Persistence (GEP 1619) #4258

Open

2 tasks

k8s-ci-robot added ok-to-test Indicates a non-member PR verified by an org member that is safe to test. and removed needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. labels Feb 5, 2026

DamianSawicki reviewed Feb 5, 2026

View reviewed changes

fix github pages and remove TODO

007d458

salonichf5 force-pushed the feat/conformance-session-persistence branch from cb7e0a3 to 007d458 Compare February 5, 2026 16:52

gcs278 reviewed Mar 5, 2026

View reviewed changes


		\| Session Persistence with cookieConfig.lifetimeType: Permanent and absoluteTimeout: 5min. \| HTTPRoute MUST have Accepted=True in parent status. Response Set-Cookie header MUST contain `expiry` attribute. The expiry value MUST correspond to the configured absoluteTimeout duration. Session persistence MUST function correctly until cookie expires. \| HTTPRouteSessionPersistence, HTTPRouteSessionPersistenceCookie, HTTPRouteSessionPersistenceCookiePermanentLifetime \|

		\| Session Persistence Scoped to Route Rule: HTTPRoute with two rules: Rule 1 (path /a) and Rule 2 (path /b), both with sessionPersistence configured, routing to the same backend Service with multiple pods. \| HTTPRoute MUST have Accepted=True in parent status. Sessions MUST NOT be shared between /a and /b. Verify with: 1) Request to /a establishes session to Pod-X, 2) Request to /b may route to any pod (Pod-X or Pod-Y), 3) Subsequent requests to /a with session cookie MUST still route to Pod-X, 4) Subsequent requests to /b with its session cookie MUST route to whichever pod was selected for /b. \| HTTPRouteSessionPersistence \|

		@@ -1077,6 +1077,29 @@ TODO
		- How do we provide a standard way to communicate that an implementation does not support Route Rule API?
		- Do we want something conceptually similar to the `IncompatibleFilters` reason?

	// SessionPersistence defines and configures session persistence
	// for the route rule.
	//
	// Support: Extended



	Note: Conformance tests are still WIP, and additional test coverage will be added in future PRs.

		@@ -1064,8 +1064,6 @@ supported by some implementations due to their current designs.

		### Conformance Details

Conversation

salonichf5 commented Feb 3, 2026

Uh oh!

k8s-ci-robot commented Feb 3, 2026

Uh oh!

k8s-ci-robot commented Feb 3, 2026

Uh oh!

robscott commented Feb 5, 2026

Uh oh!

k8s-ci-robot commented Feb 5, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

DamianSawicki left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

salonichf5 commented Feb 5, 2026

Uh oh!

gcs278 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants