Finish Route Rule API design and update edge case behaviors.

[ginayeh]

What type of PR is this?
/kind gep

Optionally add one or more of the following kinds if applicable:
N/A

What this PR does / why we need it:
The main goal of this PR is to get #1619 ready for implementable by answering the open questions in Graduation Criteria for Implementable Status:
4. Finish designing the Route Rule API and document edge cases in Edge Case Behavior for configuring session persistence on both BackendLBPolicy and route rules.

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

Does this PR introduce a user-facing change?:

NONE

[k8s-ci-robot]

Hi @ginayeh. 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/test-infra repository.

[k8s-ci-robot]

Welcome @ginayeh!

It looks like this is your first PR to kubernetes-sigs/gateway-api 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-sigs/gateway-api has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[robscott]

/cc @gcs278
/ok-to-test

[robscott]

Thanks @ginayeh!

[robscott]

Since we're making this "extended" support and elsewhere in the GEP we recognize that not everyone can support route-level config, I think we need to provide some kind of standard way to communicate that an implementation does not support the config at this level. Something conceptually similar to the IncompatibleFilters reason might make sense here, but I'm not sure that implementations that can't support session persistence config will want to reject the route. I don't think we need to solve this before the first experimental release of the API, but I just want to make sure we don't lose track of it.

[ginayeh]

Great point. I added this as an open question in the GEP. Please take a look.

[robscott]

Thanks @ginayeh! Will defer to @gcs278 or @youngnick for final LGTM.

/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ginayeh, robscott

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

The pull request process is described here

Needs approval from an approver in each of these files:

• geps/OWNERS [robscott]

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

[gcs278]

Thanks @ginayeh! I will take a look at it early next week.

[gcs278]

Thanks! Looking good to me, just some minor nit picks.

[gcs278]

Since we dropped the weight 0 scenario, I think we should still place a call out for weight 0, as it could be a ambiguous situation. I think the Traffic Splitting section makes the most sense. You can use own judgement if you disagree. I can't suggest for this line, so commenting this nearby:

When a
persistent session is established and traffic splitting is configured across services, the persistence to a single
backend MUST be maintained across services, **even if the weight is set to 0.**

[ginayeh]

Thanks for pointing out. I forgot to add more context about why I removed the weight 0 example and also want to confirm I'm not missing anything critical.

1. Curl to /a which establishes a persistent session with servicev1
2. Curl to /b routes to servicev1 due to route persistence despite weight: 0 configuration

The previous example we had is doing two route rules with path /a and /b, and path /b has traffic split with weight 0. Since each route rule should have its own persistent session, so applying cookies from persistent session /a to servicev1 should not affact /b traffic routing with servicev1. As a result, /b should be routed to servicev2 with weight: 100. Does it make sense?

Then, I was thinking about how a persistent session can be established with a weight: 0 backend? Maybe servicev1 had a non-zero weight and a persistent session established, and then route resource is re-deployed and servicev1 has a new weight: 0 configuration, but I am not sure if we expect session persistence to work after deployment, so I stopped adding an example with weight: 0. Is there other example with weight: 0 that we can include?

[gcs278]

Since each route rule should have its own persistent session, so applying cookies from persistent session /a to servicev1 should not affact /b traffic routing with servicev1.

So, to be clear, even if the session persistence is attached to the Service via BackendLBPolicy, each route rule should have different cookies / persistent sessions? Hmm. I was originally thinking that the cookie would be associated with the service when attached via BackendLBPolicy, so that it could be shared among route rules (in the weight 0 example).

If it isn't shared among route rules when using BackendLBPolicy, would that be problematic for setting the cookie name? For instance, ServiceA with cookie named "foo". There's two route rules for /x and /y, but both go just to ServiceA. The cookie "foo" will encode the backendID for ServiceA. Won't the cookie be re-used for /x and /y (two route paths)?

I think regardless, you bring up a good point that I think we should clarify in the GEP: does attaching to Service mean cookies are reused across route rules?

[ginayeh]

I think attaching BackendLBPolicy to a Service should NOT mean cookies are resued across route rules referenceing to the same service. Let me update PR with a clarification on this.

[ginayeh]

Another commit was pushed for this. PTAL @gcs278

[gcs278]

Thanks for the clarification @ginayeh. LGTM

[gcs278]

/lgtm

[robscott]

Thanks @ginayeh and @gcs278!

/hold cancel