Skip to content

BackendTrafficPolicy init + design doc#1961

Closed
Alice-Lilith wants to merge 1 commit intomainfrom
alicewasko/backendpolicy-init
Closed

BackendTrafficPolicy init + design doc#1961
Alice-Lilith wants to merge 1 commit intomainfrom
alicewasko/backendpolicy-init

Conversation

@Alice-Lilith
Copy link
Copy Markdown
Member

@Alice-Lilith Alice-Lilith commented Oct 13, 2023

Initializes the BackendTrafficPolicy custom resource and API.

I added some extra CRD validation to catch a couple things early instead of waiting to get to the runtime condition checks.
Here's some screenshots from when I was working on that so you can get an idea of what a user might see when trying to apply and fix an invalid resource. I'm happy to open a PR tweaking the existing ClientTrafficPolicy CRD to have similar validation if we're good with it.

Screenshot from 2023-10-12 09-55-17

Screenshot from 2023-10-12 09-55-53

Screenshot from 2023-10-12 09-56-07

Signed-off-by: Alice Wasko <alicewasko@datawire.io>
@codecov
Copy link
Copy Markdown

codecov bot commented Oct 13, 2023

Codecov Report

Merging #1961 (5db9f43) into main (3827919) will increase coverage by 0.31%.
The diff coverage is 75.00%.

@@            Coverage Diff             @@
##             main    #1961      +/-   ##
==========================================
+ Coverage   65.37%   65.69%   +0.31%     
==========================================
  Files          90       92       +2     
  Lines       13377    13743     +366     
==========================================
+ Hits         8745     9028     +283     
- Misses       4092     4166      +74     
- Partials      540      549       +9     
Files Coverage Δ
internal/gatewayapi/clienttrafficpolicy.go 71.11% <100.00%> (ø)
internal/gatewayapi/translator.go 98.78% <100.00%> (+1.28%) ⬆️
internal/message/types.go 0.00% <ø> (ø)
internal/status/backendtrafficpolicy.go 0.00% <0.00%> (ø)
internal/gatewayapi/runner/runner.go 22.03% <0.00%> (-0.98%) ⬇️
internal/gatewayapi/zz_generated.deepcopy.go 0.00% <0.00%> (ø)
internal/provider/kubernetes/controller.go 53.13% <8.33%> (-1.00%) ⬇️
internal/gatewayapi/resource.go 62.00% <0.00%> (-1.27%) ⬇️
internal/gatewayapi/backendtrafficpolicy.go 78.96% <78.96%> (ø)

... and 2 files with indirect coverage changes

@zhaohuabing
Copy link
Copy Markdown
Member

zhaohuabing commented Oct 13, 2023

Initializes the BackendTrafficPolicy custom resource and API.

I added some extra CRD validation to catch a couple things early instead of waiting to get to the runtime condition checks.

It's awesome! I need similar validation for SecurityPolicy as well.

}

// Check if any policies that target xRoute resources are overriding this policy so we can set the status
if _, ok := overriddenPolicyTargets[*gatewayKey]; ok {
Copy link
Copy Markdown
Member

@zhaohuabing zhaohuabing Oct 13, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A policy targeting a xRoute does not always override a policy targeting a listener under the same gateway. For example, they may have different hostnames.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the sectionName of the parentReference is not being saved in L107 so we dont know for sure if this listener section is a parent of the xRoute which has a policy targeted to it

message,
)
}

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should also check if there are existing policies at the route level.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe this is happening on L109

Copy link
Copy Markdown
Member

@zhaohuabing zhaohuabing Oct 14, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

L109 overriddenPolicyTargets is only used to check conflicts with listeners at L152. Ideally, we should also check if there are existing policies at the route level that override the gateway-level(Policies targeting gateway without sectionname) policies.

)

// +kubebuilder:object:root=true
// +kubebuilder:resource:shortName=btpolicy
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

btp ?

// spec defines the desired state of BackendTrafficPolicy.
type BackendTrafficPolicySpec struct {

// +kubebuilder:validation:XValidation:rule="has(self.sectionName) ? self.kind == 'Gateway': true", message="sectionName can only be set when kind is 'Gateway'."
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks for adding these !

raised #1964 to add validation tests

// is being attached to.
// This Policy and the TargetRef MUST be in the same namespace
// for this Policy to have effect and be applied to the Gateway.
TargetRef gwapiv1a2.PolicyTargetReferenceWithSectionName `json:"targetRef"`
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we should add a line here about policy hierarchy as well as policy override i.e.

  • Only one policy can be successfully attached to a specific target
  • Since multiple policies can be indirectly applied to the same target e.g. a policy targeting a Gateway as well as a policy targeting a xRoute attached to the same Gateway, the policy with the most specific target will always have higher precedence (in this case the policy targeting the xRoute) over the less specific one (the policy targeting the Gateway)

if parentRef.Namespace != nil {
namespace = string(*parentRef.Namespace)
}
overriddenPolicyTargets[types.NamespacedName{
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you explain this logic ?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nvm, looks like we are proactively making sure the parent gateways are overridden, a comment here would be great


// Process the policies targeting Gateways with a section name
for _, policy := range backendTrafficPolicies {
if policy.Spec.TargetRef.SectionName != nil {
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in theory a route will never reach here because of the CEL validation in the CRD, but this maybe hard for the next dev looking at this to figure that out
can we add an extra checking in here

policy.Spec.TargetRef.Kind == KindGateway &&  .....

targetNs = ptr.To(gwv1b1.Namespace(policy.Namespace))
}

// Ensure Policy and target are in the same namespace
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

curious if this can be moved to CEL Validation, not a blocker, we can raise a GH issue to track this

for _, parentGW := range httpRoute.Spec.ParentRefs {
key := types.NamespacedName{Name: string(parentGW.Name)}
if parentGW.Namespace != nil {
key.Namespace = string(*parentGW.Namespace)
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

when parentGW.Namespace == nil , key.Namespace = httpRoute.Namespace and the same is true for all other route types

gateways := t.GetRelevantGateways(resources.Gateways)

// Get Routes belonging to our GatewayClass.
routes := t.GetRelevantRoutes(gateways,
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I dont think this is needed, L160-L170 already compute the relevant routes today e.g.

return relevantHTTPRoutes

we just need to append it into a list and pass it over

return relevant
}

func (t *Translator) GetRelevantRoutes(relevantGateways []*GatewayContext,
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as shared above, dont think this func is needed

name: default-ipv-policy
namespace: default
spec:
protocols:
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can we use a different feature as an example, maybe load balancing
ipv6 routing is tied to L3 which EG cannot really control, it can only make sure that if ipv6 endpoints exist, it can successfully fetch it and program it

- Policy A will be applied/attached to the specific Listener defined in the `targetRef.SectionName`
- Policy B will be applied to the remaining Listeners within the Gateway. Policy B will have an additional
status condition `Overridden=True`.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

needs another line about policy hierarchy/precendance ( Route > Listener > Gateway)

targetedRoutes[routeKey] = true
route := routeMap[*target]
for _, parentRef := range GetParentReferences(route) {
namespace := ""
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should default to namespace of the route

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@arkodg
Copy link
Copy Markdown
Contributor

arkodg commented Oct 13, 2023

this PR is close to the finish line, thanks for complementing the policy hierarchy complexity with test cases, added some comments, ptal

@arkodg
Copy link
Copy Markdown
Contributor

arkodg commented Oct 13, 2023

also 2 more things needed in this PR is

arkodg pushed a commit to arkodg/gateway that referenced this pull request Oct 23, 2023
Takes PR envoyproxy#1961 forward

Signed-off-by: Arko Dasgupta <arko@tetrate.io>
@arkodg
Copy link
Copy Markdown
Contributor

arkodg commented Oct 23, 2023

closed in favor of #2053

@arkodg arkodg closed this Oct 23, 2023
zirain added a commit that referenced this pull request Oct 24, 2023
* feat BackendTrafficPolicy

Takes PR #1961 forward

Signed-off-by: Arko Dasgupta <arko@tetrate.io>

* lint

Signed-off-by: Arko Dasgupta <arko@tetrate.io>

* k8s status

Signed-off-by: Arko Dasgupta <arko@tetrate.io>

* k8s watch

Signed-off-by: Arko Dasgupta <arko@tetrate.io>

* Update site/content/en/latest/design/backend-traffic-policy.md

Co-authored-by: zirain <zirain2009@gmail.com>
Signed-off-by: Arko Dasgupta <arkodg@users.noreply.github.com>

* Update site/content/en/latest/design/backend-traffic-policy.md

Co-authored-by: zirain <zirain2009@gmail.com>
Signed-off-by: Arko Dasgupta <arkodg@users.noreply.github.com>

---------

Signed-off-by: Arko Dasgupta <arko@tetrate.io>
Signed-off-by: Arko Dasgupta <arkodg@users.noreply.github.com>
Co-authored-by: zirain <zirain2009@gmail.com>
@zirain zirain deleted the alicewasko/backendpolicy-init branch March 7, 2024 14:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants