/remove-lifecycle stale /lifecycle frozen
Pinned
kubernetes-sigs/gateway-api
528
⚡ Repository for the next iteration of composite service (e.g. Ingress) and load balancing APIs.
kubernetes/kubernetes
8.86w
⚡ Production-Grade Container Scheduling and Management
robscott/kube-capacity
1k
⚡ A simple CLI that provides an overview of the resource requests, limits, and utilization in a Kubernetes cluster
FairwindsOps/polaris
2.6k
⚡ Validation of best practices in your Kubernetes clusters
FairwindsOps/rbac-manager
1.1k
⚡ A Kubernetes operator that simplifies the management of Role Bindings and Service Accounts.
FairwindsOps/rbac-lookup
624
⚡ Easily find roles and cluster roles attached to any user, service account, or group name in your Kubernetes cluster
Activity
May
23
11 hours ago
May
19
4 days ago
robscott wants to merge kubernetes-sigs/gateway-api
robscott
robscott
CONTRIBUTOR
createdAt 4 days ago
[WIP] Add HTTP Rewrite and Redirect Filter guide
What type of PR is this? /kind documentation
What this PR does / why we need it: Adds a guide for GEP-726 features, including the changes currently under review in #1124
It is a WIP for two reasons:
- For HTTP->HTTPS redirects, are implementations expected to not redirect requests that are already HTTPS, or does the spec allow misconfigurations that result in redirect loops? If so, how should users properly set up their HTTPRoutes and Gateway Listener configuration to only match these redirect rules on HTTP requests? I expect this generalizes to path/hostname/etc. also, but this was the most prominent case I could think of.
- Do we care about path types for path modifiers? It seems that you can use prefix modifiers for exact paths, though it's probably pointless (if harmless), and I'm not sure whether RegularExpression paths would be considered prefixes here (i.e. ReplacePrefixMatch changes only the path segment matching the regex).
- I added the text suggested in #928 mostly as-is, but it raises the question "what status must we set?". It seems like we need a new
RouteConditionTypefor filter-related statuses if we want this, or a newRouteConditionReason(it doesn't seem like it'd fit under any of the existing types unless we reject routes with invalid filters entirely, and I wouldn't expect to since they're per-rule and since the text indicates this should just be a warning, not an error).
As a side note, I have bad timing and will be out from 5/18-5/28, so it may make sense to use this as a starting point for someone else if review takes time or it needs significant changes. Edit: then I forgot this is the week that a bunch of people are at Kubecon :slightly_smiling_face: I should actually be able to check things on the 26th even though I'm still technically out.
Which issue(s) this PR fixes: Fixes #1038 Fixes #928
Does this PR introduce a user-facing change?:
NONE
robscott
This should be included from a separate yaml file so we can ensure that it stays valid. You can see some of the other guides for examples, but in general, the inclusion should look like this:
{% include 'v1alpha2/http-routing/gateway.yaml' %}
robscott wants to merge kubernetes-sigs/gateway-api
robscott
robscott
CONTRIBUTOR
createdAt 4 days ago
[WIP] Add HTTP Rewrite and Redirect Filter guide
What type of PR is this? /kind documentation
What this PR does / why we need it: Adds a guide for GEP-726 features, including the changes currently under review in #1124
It is a WIP for two reasons:
- For HTTP->HTTPS redirects, are implementations expected to not redirect requests that are already HTTPS, or does the spec allow misconfigurations that result in redirect loops? If so, how should users properly set up their HTTPRoutes and Gateway Listener configuration to only match these redirect rules on HTTP requests? I expect this generalizes to path/hostname/etc. also, but this was the most prominent case I could think of.
- Do we care about path types for path modifiers? It seems that you can use prefix modifiers for exact paths, though it's probably pointless (if harmless), and I'm not sure whether RegularExpression paths would be considered prefixes here (i.e. ReplacePrefixMatch changes only the path segment matching the regex).
- I added the text suggested in #928 mostly as-is, but it raises the question "what status must we set?". It seems like we need a new
RouteConditionTypefor filter-related statuses if we want this, or a newRouteConditionReason(it doesn't seem like it'd fit under any of the existing types unless we reject routes with invalid filters entirely, and I wouldn't expect to since they're per-rule and since the text indicates this should just be a warning, not an error).
As a side note, I have bad timing and will be out from 5/18-5/28, so it may make sense to use this as a starting point for someone else if review takes time or it needs significant changes. Edit: then I forgot this is the week that a bunch of people are at Kubecon :slightly_smiling_face: I should actually be able to check things on the 26th even though I'm still technically out.
Which issue(s) this PR fixes: Fixes #1038 Fixes #928
Does this PR introduce a user-facing change?:
NONE
robscott
Same comment as above - move to separate file.
robscott wants to merge kubernetes-sigs/gateway-api
robscott
robscott
CONTRIBUTOR
createdAt 4 days ago
[WIP] Add HTTP Rewrite and Redirect Filter guide
What type of PR is this? /kind documentation
What this PR does / why we need it: Adds a guide for GEP-726 features, including the changes currently under review in #1124
It is a WIP for two reasons:
- For HTTP->HTTPS redirects, are implementations expected to not redirect requests that are already HTTPS, or does the spec allow misconfigurations that result in redirect loops? If so, how should users properly set up their HTTPRoutes and Gateway Listener configuration to only match these redirect rules on HTTP requests? I expect this generalizes to path/hostname/etc. also, but this was the most prominent case I could think of.
- Do we care about path types for path modifiers? It seems that you can use prefix modifiers for exact paths, though it's probably pointless (if harmless), and I'm not sure whether RegularExpression paths would be considered prefixes here (i.e. ReplacePrefixMatch changes only the path segment matching the regex).
- I added the text suggested in #928 mostly as-is, but it raises the question "what status must we set?". It seems like we need a new
RouteConditionTypefor filter-related statuses if we want this, or a newRouteConditionReason(it doesn't seem like it'd fit under any of the existing types unless we reject routes with invalid filters entirely, and I wouldn't expect to since they're per-rule and since the text indicates this should just be a warning, not an error).
As a side note, I have bad timing and will be out from 5/18-5/28, so it may make sense to use this as a starting point for someone else if review takes time or it needs significant changes. Edit: then I forgot this is the week that a bunch of people are at Kubecon :slightly_smiling_face: I should actually be able to check things on the 26th even though I'm still technically out.
Which issue(s) this PR fixes: Fixes #1038 Fixes #928
Does this PR introduce a user-facing change?:
NONE
robscott
Same comment as above about needing a separate file.
robscott wants to merge kubernetes-sigs/gateway-api
robscott
robscott
CONTRIBUTOR
createdAt 4 days ago
[WIP] Add HTTP Rewrite and Redirect Filter guide
What type of PR is this? /kind documentation
What this PR does / why we need it: Adds a guide for GEP-726 features, including the changes currently under review in #1124
It is a WIP for two reasons:
- For HTTP->HTTPS redirects, are implementations expected to not redirect requests that are already HTTPS, or does the spec allow misconfigurations that result in redirect loops? If so, how should users properly set up their HTTPRoutes and Gateway Listener configuration to only match these redirect rules on HTTP requests? I expect this generalizes to path/hostname/etc. also, but this was the most prominent case I could think of.
- Do we care about path types for path modifiers? It seems that you can use prefix modifiers for exact paths, though it's probably pointless (if harmless), and I'm not sure whether RegularExpression paths would be considered prefixes here (i.e. ReplacePrefixMatch changes only the path segment matching the regex).
- I added the text suggested in #928 mostly as-is, but it raises the question "what status must we set?". It seems like we need a new
RouteConditionTypefor filter-related statuses if we want this, or a newRouteConditionReason(it doesn't seem like it'd fit under any of the existing types unless we reject routes with invalid filters entirely, and I wouldn't expect to since they're per-rule and since the text indicates this should just be a warning, not an error).
As a side note, I have bad timing and will be out from 5/18-5/28, so it may make sense to use this as a starting point for someone else if review takes time or it needs significant changes. Edit: then I forgot this is the week that a bunch of people are at Kubecon :slightly_smiling_face: I should actually be able to check things on the 26th even though I'm still technically out.
Which issue(s) this PR fixes: Fixes #1038 Fixes #928
Does this PR introduce a user-facing change?:
NONE
robscott
Same comment as above.
robscott wants to merge kubernetes-sigs/gateway-api
robscott
robscott
CONTRIBUTOR
createdAt 4 days ago
[WIP] Add HTTP Rewrite and Redirect Filter guide
What type of PR is this? /kind documentation
What this PR does / why we need it: Adds a guide for GEP-726 features, including the changes currently under review in #1124
It is a WIP for two reasons:
- For HTTP->HTTPS redirects, are implementations expected to not redirect requests that are already HTTPS, or does the spec allow misconfigurations that result in redirect loops? If so, how should users properly set up their HTTPRoutes and Gateway Listener configuration to only match these redirect rules on HTTP requests? I expect this generalizes to path/hostname/etc. also, but this was the most prominent case I could think of.
- Do we care about path types for path modifiers? It seems that you can use prefix modifiers for exact paths, though it's probably pointless (if harmless), and I'm not sure whether RegularExpression paths would be considered prefixes here (i.e. ReplacePrefixMatch changes only the path segment matching the regex).
- I added the text suggested in #928 mostly as-is, but it raises the question "what status must we set?". It seems like we need a new
RouteConditionTypefor filter-related statuses if we want this, or a newRouteConditionReason(it doesn't seem like it'd fit under any of the existing types unless we reject routes with invalid filters entirely, and I wouldn't expect to since they're per-rule and since the text indicates this should just be a warning, not an error).
As a side note, I have bad timing and will be out from 5/18-5/28, so it may make sense to use this as a starting point for someone else if review takes time or it needs significant changes. Edit: then I forgot this is the week that a bunch of people are at Kubecon :slightly_smiling_face: I should actually be able to check things on the 26th even though I'm still technically out.
Which issue(s) this PR fixes: Fixes #1038 Fixes #928
Does this PR introduce a user-facing change?:
NONE
robscott
Indentation looks off here, maybe a combination of tabs and spaces going on here?
robscott wants to merge kubernetes-sigs/gateway-api
robscott
robscott
CONTRIBUTOR
createdAt 4 days ago
[WIP] Add HTTP Rewrite and Redirect Filter guide
What type of PR is this? /kind documentation
What this PR does / why we need it: Adds a guide for GEP-726 features, including the changes currently under review in #1124
It is a WIP for two reasons:
- For HTTP->HTTPS redirects, are implementations expected to not redirect requests that are already HTTPS, or does the spec allow misconfigurations that result in redirect loops? If so, how should users properly set up their HTTPRoutes and Gateway Listener configuration to only match these redirect rules on HTTP requests? I expect this generalizes to path/hostname/etc. also, but this was the most prominent case I could think of.
- Do we care about path types for path modifiers? It seems that you can use prefix modifiers for exact paths, though it's probably pointless (if harmless), and I'm not sure whether RegularExpression paths would be considered prefixes here (i.e. ReplacePrefixMatch changes only the path segment matching the regex).
- I added the text suggested in #928 mostly as-is, but it raises the question "what status must we set?". It seems like we need a new
RouteConditionTypefor filter-related statuses if we want this, or a newRouteConditionReason(it doesn't seem like it'd fit under any of the existing types unless we reject routes with invalid filters entirely, and I wouldn't expect to since they're per-rule and since the text indicates this should just be a warning, not an error).
As a side note, I have bad timing and will be out from 5/18-5/28, so it may make sense to use this as a starting point for someone else if review takes time or it needs significant changes. Edit: then I forgot this is the week that a bunch of people are at Kubecon :slightly_smiling_face: I should actually be able to check things on the 26th even though I'm still technically out.
Which issue(s) this PR fixes: Fixes #1038 Fixes #928
Does this PR introduce a user-facing change?:
NONE
robscott
I think we do need to provide some kind of guidance here. Ideally we would make it very difficult to write config that would result in a redirect loop. I'm not sure how broadly implementable this is, but could we interpret this as a "redirect if not already at this destination/scheme/etc"?
robscott wants to merge kubernetes-sigs/gateway-api
robscott
robscott
CONTRIBUTOR
createdAt 4 days ago
[WIP] Add HTTP Rewrite and Redirect Filter guide
What type of PR is this? /kind documentation
What this PR does / why we need it: Adds a guide for GEP-726 features, including the changes currently under review in #1124
It is a WIP for two reasons:
- For HTTP->HTTPS redirects, are implementations expected to not redirect requests that are already HTTPS, or does the spec allow misconfigurations that result in redirect loops? If so, how should users properly set up their HTTPRoutes and Gateway Listener configuration to only match these redirect rules on HTTP requests? I expect this generalizes to path/hostname/etc. also, but this was the most prominent case I could think of.
- Do we care about path types for path modifiers? It seems that you can use prefix modifiers for exact paths, though it's probably pointless (if harmless), and I'm not sure whether RegularExpression paths would be considered prefixes here (i.e. ReplacePrefixMatch changes only the path segment matching the regex).
- I added the text suggested in #928 mostly as-is, but it raises the question "what status must we set?". It seems like we need a new
RouteConditionTypefor filter-related statuses if we want this, or a newRouteConditionReason(it doesn't seem like it'd fit under any of the existing types unless we reject routes with invalid filters entirely, and I wouldn't expect to since they're per-rule and since the text indicates this should just be a warning, not an error).
As a side note, I have bad timing and will be out from 5/18-5/28, so it may make sense to use this as a starting point for someone else if review takes time or it needs significant changes. Edit: then I forgot this is the week that a bunch of people are at Kubecon :slightly_smiling_face: I should actually be able to check things on the 26th even though I'm still technically out.
Which issue(s) this PR fixes: Fixes #1038 Fixes #928
Does this PR introduce a user-facing change?:
NONE
robscott wants to merge kubernetes-sigs/gateway-api
robscott
robscott
CONTRIBUTOR
createdAt 4 days ago
[WIP] Add HTTP Rewrite and Redirect Filter guide
What type of PR is this? /kind documentation
What this PR does / why we need it: Adds a guide for GEP-726 features, including the changes currently under review in #1124
It is a WIP for two reasons:
- For HTTP->HTTPS redirects, are implementations expected to not redirect requests that are already HTTPS, or does the spec allow misconfigurations that result in redirect loops? If so, how should users properly set up their HTTPRoutes and Gateway Listener configuration to only match these redirect rules on HTTP requests? I expect this generalizes to path/hostname/etc. also, but this was the most prominent case I could think of.
- Do we care about path types for path modifiers? It seems that you can use prefix modifiers for exact paths, though it's probably pointless (if harmless), and I'm not sure whether RegularExpression paths would be considered prefixes here (i.e. ReplacePrefixMatch changes only the path segment matching the regex).
- I added the text suggested in #928 mostly as-is, but it raises the question "what status must we set?". It seems like we need a new
RouteConditionTypefor filter-related statuses if we want this, or a newRouteConditionReason(it doesn't seem like it'd fit under any of the existing types unless we reject routes with invalid filters entirely, and I wouldn't expect to since they're per-rule and since the text indicates this should just be a warning, not an error).
As a side note, I have bad timing and will be out from 5/18-5/28, so it may make sense to use this as a starting point for someone else if review takes time or it needs significant changes. Edit: then I forgot this is the week that a bunch of people are at Kubecon :slightly_smiling_face: I should actually be able to check things on the 26th even though I'm still technically out.
Which issue(s) this PR fixes: Fixes #1038 Fixes #928
Does this PR introduce a user-facing change?:
NONE
robscott
I think this might read better if you merged the content from before and after the example, something like this:
can change the upstream request hostname and/or path. For example, the following HTTPRoute will accept...
Same comment applies elsewhere.
robscott wants to merge kubernetes-sigs/gateway-api
robscott
robscott
CONTRIBUTOR
createdAt 4 days ago
[WIP] Add HTTP Rewrite and Redirect Filter guide
What type of PR is this? /kind documentation
What this PR does / why we need it: Adds a guide for GEP-726 features, including the changes currently under review in #1124
It is a WIP for two reasons:
- For HTTP->HTTPS redirects, are implementations expected to not redirect requests that are already HTTPS, or does the spec allow misconfigurations that result in redirect loops? If so, how should users properly set up their HTTPRoutes and Gateway Listener configuration to only match these redirect rules on HTTP requests? I expect this generalizes to path/hostname/etc. also, but this was the most prominent case I could think of.
- Do we care about path types for path modifiers? It seems that you can use prefix modifiers for exact paths, though it's probably pointless (if harmless), and I'm not sure whether RegularExpression paths would be considered prefixes here (i.e. ReplacePrefixMatch changes only the path segment matching the regex).
- I added the text suggested in #928 mostly as-is, but it raises the question "what status must we set?". It seems like we need a new
RouteConditionTypefor filter-related statuses if we want this, or a newRouteConditionReason(it doesn't seem like it'd fit under any of the existing types unless we reject routes with invalid filters entirely, and I wouldn't expect to since they're per-rule and since the text indicates this should just be a warning, not an error).
As a side note, I have bad timing and will be out from 5/18-5/28, so it may make sense to use this as a starting point for someone else if review takes time or it needs significant changes. Edit: then I forgot this is the week that a bunch of people are at Kubecon :slightly_smiling_face: I should actually be able to check things on the 26th even though I'm still technically out.
Which issue(s) this PR fixes: Fixes #1038 Fixes #928
Does this PR introduce a user-facing change?:
NONE
robscott
Good point, I think https://github.com/kubernetes-sigs/gateway-api/issues/1166 will resolve this.
robscott merge to kubernetes-sigs/gateway-api
robscott
robscott
CONTRIBUTOR
createdAt 4 days ago
[WIP] Add HTTP Rewrite and Redirect Filter guide
What type of PR is this? /kind documentation
What this PR does / why we need it: Adds a guide for GEP-726 features, including the changes currently under review in #1124
It is a WIP for two reasons:
- For HTTP->HTTPS redirects, are implementations expected to not redirect requests that are already HTTPS, or does the spec allow misconfigurations that result in redirect loops? If so, how should users properly set up their HTTPRoutes and Gateway Listener configuration to only match these redirect rules on HTTP requests? I expect this generalizes to path/hostname/etc. also, but this was the most prominent case I could think of.
- Do we care about path types for path modifiers? It seems that you can use prefix modifiers for exact paths, though it's probably pointless (if harmless), and I'm not sure whether RegularExpression paths would be considered prefixes here (i.e. ReplacePrefixMatch changes only the path segment matching the regex).
- I added the text suggested in #928 mostly as-is, but it raises the question "what status must we set?". It seems like we need a new
RouteConditionTypefor filter-related statuses if we want this, or a newRouteConditionReason(it doesn't seem like it'd fit under any of the existing types unless we reject routes with invalid filters entirely, and I wouldn't expect to since they're per-rule and since the text indicates this should just be a warning, not an error).
As a side note, I have bad timing and will be out from 5/18-5/28, so it may make sense to use this as a starting point for someone else if review takes time or it needs significant changes. Edit: then I forgot this is the week that a bunch of people are at Kubecon :slightly_smiling_face: I should actually be able to check things on the 26th even though I'm still technically out.
Which issue(s) this PR fixes: Fixes #1038 Fixes #928
Does this PR introduce a user-facing change?:
NONE
robscott
robscott
CONTRIBUTOR
submittedAt 4 days ago
Thanks @rainest, this is really great!
robscott merge to kubernetes-sigs/gateway-api
robscott
robscott
CONTRIBUTOR
createdAt 4 days ago
[WIP] Add HTTP Rewrite and Redirect Filter guide
What type of PR is this? /kind documentation
What this PR does / why we need it: Adds a guide for GEP-726 features, including the changes currently under review in #1124
It is a WIP for two reasons:
- For HTTP->HTTPS redirects, are implementations expected to not redirect requests that are already HTTPS, or does the spec allow misconfigurations that result in redirect loops? If so, how should users properly set up their HTTPRoutes and Gateway Listener configuration to only match these redirect rules on HTTP requests? I expect this generalizes to path/hostname/etc. also, but this was the most prominent case I could think of.
- Do we care about path types for path modifiers? It seems that you can use prefix modifiers for exact paths, though it's probably pointless (if harmless), and I'm not sure whether RegularExpression paths would be considered prefixes here (i.e. ReplacePrefixMatch changes only the path segment matching the regex).
- I added the text suggested in #928 mostly as-is, but it raises the question "what status must we set?". It seems like we need a new
RouteConditionTypefor filter-related statuses if we want this, or a newRouteConditionReason(it doesn't seem like it'd fit under any of the existing types unless we reject routes with invalid filters entirely, and I wouldn't expect to since they're per-rule and since the text indicates this should just be a warning, not an error).
As a side note, I have bad timing and will be out from 5/18-5/28, so it may make sense to use this as a starting point for someone else if review takes time or it needs significant changes. Edit: then I forgot this is the week that a bunch of people are at Kubecon :slightly_smiling_face: I should actually be able to check things on the 26th even though I'm still technically out.
Which issue(s) this PR fixes: Fixes #1038 Fixes #928
Does this PR introduce a user-facing change?:
NONE
robscott
robscott
CONTRIBUTOR
submittedAt 4 days ago
Thanks @rainest, this is really great!
robscott issue comment kubernetes-sigs/gateway-api
robscott
robscott
CONTRIBUTOR
createdAt 4 days ago
Wildcard hostname matching behavior is not clearly specified
What would you like to be added:
As @howardjohn noted in Slack, our hostname matching behavior is not clearly specified. Other than saying "exact matches must be processed before wildcard matches", we don't really cover how wildcard matches should be implemented. Specifically, which of the following should *.example.com match?
-
a.example.com -
a.b.example.com
We recently added a conformance test that stated that only 1 should match. On further thought, I'm not sure that's what we want.
Here's my understanding of the default behavior for a variety of different products:
- nginx defaults to match 1 and 2 ref
- envoy defaults to match 1 and 2 ref
- haproxy can definitely support suffix matching (hdr_end), I'm not sure about the other ref
- GCP can only support suffix matching (not well documented yet)
Given the above, it seems that most underlying implementations treat wildcard host matching as suffix matching as the default, and some may only be able to support that approach. My suggestion would be to adjust the spec and conformance tests to reflect that.
Why this is needed: This is an important gap in our spec today.
robscott
I agree that this was at one point specified in the API, and I'm not actually sure how it ended up being removed from the spec - I think it must have been part of a larger restructuring or rewording. With that said, my strong bias here is to use the most broadly supportable interpretation of this, which is essentially a suffix match.
From what I can tell, both GCP and Azure are only able to interpret a wildcard match as a suffix match. That also matches the default behavior of nginx and envoy. Although this would differ from the Ingress spec, I think it would be more in line with how wildcard matches are interpreted across different providers.
Because this is a critical decision, I'm going to add it to the v0.5.0 milestone. I think there are two possible actions that could be sufficient to unblock the v0.5.0 for this:
- Remove the conformance tests that require single label matching as an interpretation of wildcard matching.
- Add guidance to the spec on how wildcard matching should be implemented.
I would prefer 2, but if we can't easily reach consensus on this, I think 1 may be sufficient.
robscott issue comment kubernetes-sigs/gateway-api
robscott
robscott
CONTRIBUTOR
createdAt 4 days ago
test: fix skip format
/kind cleanup
Does this PR introduce a user-facing change?:
NONE
robscott
I think this was fixed by #1167. Feel free to reopen if not.
/close
robscott pull request kubernetes-sigs/gateway-api
robscott
robscott
CONTRIBUTOR
createdAt 4 days ago
Bumping golangci-lint, making related fixes
What type of PR is this? /kind bug /kind failing-test
What this PR does / why we need it: This fixes golangci-lint and the related presubmit.
Does this PR introduce a user-facing change?:
NONE
May
18
5 days ago
robscott issue comment kubernetes-sigs/gateway-api
robscott
robscott
CONTRIBUTOR
createdAt 4 days ago
Add webhook validation to ensure that ReplacePathPrefix in rewrites has corresponding prefix match
When a URLRewrite filter is specified on a Route rule and it includes ReplacePathPrefix configuration, we should verify that exactly one path prefix match is specified on the same Route rule. We should also verify that no other path matches are specified as part of this.
robscott
This work should probably be based on https://github.com/kubernetes-sigs/gateway-api/pull/1124, or just wait for that PR to merge.
robscott issue comment kubernetes-sigs/gateway-api
robscott
robscott
MEMBER
createdAt 4 days ago
Confusing of HTTPPathModifier
How could i rewrite url like /foo/bar prefixed with foo to /bar , it does not allow setting match value
robscott issue kubernetes-sigs/gateway-api
robscott
robscott
CONTRIBUTOR
createdAt 4 days ago
Add webhook validation to ensure that ReplacePathPrefix in rewrites has corresponding prefix match
When a URLRewrite filter is specified on a Route rule and it includes ReplacePathPrefix configuration, we should verify that exactly one path prefix match is specified on the same Route rule. We should also verify that no other path matches are specified as part of this.
robscott issue comment kubernetes-sigs/gateway-api
robscott
robscott
MEMBER
createdAt 4 days ago
Confusing of HTTPPathModifier
How could i rewrite url like /foo/bar prefixed with foo to /bar , it does not allow setting match value
robscott
Good question. That would be an invalid configuration. We should probably add some webhook validation to prevent that from happening.
robscott issue comment kubernetes-sigs/gateway-api
robscott
robscott
MEMBER
createdAt 5 days ago
Confusing of HTTPPathModifier
How could i rewrite url like /foo/bar prefixed with foo to /bar , it does not allow setting match value
robscott
Thanks for the question @hzxuzhonghu! I think #1124 and #1162 will help make this a bit clearer. The value that is being replaced is from the path match. So if you want to use a prefix match to rewrite requests starting with /foo/bar to /bar, you could use config like this:
apiVersion: gateway.networking.k8s.io/v1alpha2
kind: HTTPRoute
metadata:
name: http-filter-rewrite
spec:
rules:
- matches:
- path:
type: PathPrefix
value: /foo/bar
filters:
- type: URLRewrite
urlRewrite:
path:
type: ReplacePathPrefix
replacePathPrefix: /bar
backendRefs:
- name: example-svc
weight: 1
port: 80
May
17
6 days ago
robscott issue comment kubernetes-sigs/gateway-api
robscott
robscott
CONTRIBUTOR
createdAt 5 days ago
[WIP] Add HTTP Rewrite and Redirect Filter guide
What type of PR is this? /kind documentation
What this PR does / why we need it: Adds a guide for GEP-726 features, including the changes currently under review in #1124
It is a WIP for two reasons:
- For HTTP->HTTPS redirects, are implementations expected to not redirect requests that are already HTTPS, or does the spec allow misconfigurations that result in redirect loops? If so, how should users properly set up their HTTPRoutes and Gateway Listener configuration to only match these redirect rules on HTTP requests? I expect this generalizes to path/hostname/etc. also, but this was the most prominent case I could think of.
- Do we care about path types for path modifiers? It seems that you can use prefix modifiers for exact paths, though it's probably pointless (if harmless), and I'm not sure whether RegularExpression paths would be considered prefixes here (i.e. ReplacePrefixMatch changes only the path segment matching the regex).
- I added the text suggested in #928 mostly as-is, but it raises the question "what status must we set?". It seems like we need a new
RouteConditionTypefor filter-related statuses if we want this, or a newRouteConditionReason(it doesn't seem like it'd fit under any of the existing types unless we reject routes with invalid filters entirely, and I wouldn't expect to since they're per-rule and since the text indicates this should just be a warning, not an error).
As a side note, I have bad timing and will be out from 5/18-5/28, so it may make sense to use this as a starting point for someone else if review takes time or it needs significant changes.
Which issue(s) this PR fixes: Fixes #1038 Fixes #928
Does this PR introduce a user-facing change?:
NONE
robscott
/ok-to-test
robscott wants to merge kubernetes-sigs/gateway-api
robscott
robscott
CONTRIBUTOR
createdAt 5 days ago
conformance: add hostname intersection test
What type of PR is this? /area conformance
What this PR does / why we need it: Adds a conformance test that validates hostname intersection between HTTPRoutes and Listeners.
Also updates the "WaitsForConsistency" helper to retry immediately after a successful request, to speed up test execution.
Which issue(s) this PR fixes: Updates #1104
Does this PR introduce a user-facing change?:
NONE
robscott merge to kubernetes-sigs/gateway-api
robscott
robscott
CONTRIBUTOR
createdAt 5 days ago
conformance: add hostname intersection test
What type of PR is this? /area conformance
What this PR does / why we need it: Adds a conformance test that validates hostname intersection between HTTPRoutes and Listeners.
Also updates the "WaitsForConsistency" helper to retry immediately after a successful request, to speed up test execution.
Which issue(s) this PR fixes: Updates #1104
Does this PR introduce a user-facing change?:
NONE
robscott
robscott
CONTRIBUTOR
submittedAt 5 days ago
robscott merge to kubernetes-sigs/gateway-api
robscott
robscott
CONTRIBUTOR
createdAt 5 days ago
conformance: add hostname intersection test
What type of PR is this? /area conformance
What this PR does / why we need it: Adds a conformance test that validates hostname intersection between HTTPRoutes and Listeners.
Also updates the "WaitsForConsistency" helper to retry immediately after a successful request, to speed up test execution.
Which issue(s) this PR fixes: Updates #1104
Does this PR introduce a user-facing change?:
NONE
robscott
robscott
CONTRIBUTOR
submittedAt 5 days ago
robscott wants to merge kubernetes-sigs/gateway-api
robscott
robscott
CONTRIBUTOR
createdAt 5 days ago
conformance: add hostname intersection test
What type of PR is this? /area conformance
What this PR does / why we need it: Adds a conformance test that validates hostname intersection between HTTPRoutes and Listeners.
Also updates the "WaitsForConsistency" helper to retry immediately after a successful request, to speed up test execution.
Which issue(s) this PR fixes: Updates #1104
Does this PR introduce a user-facing change?:
NONE
robscott issue comment kubernetes-sigs/gateway-api
robscott
robscott
CONTRIBUTOR
createdAt 5 days ago
test: fix skip format
/kind cleanup
Does this PR introduce a user-facing change?:
NONE
robscott
Thanks!
/ok-to-test /lgtm /approve
May
13
1 week ago
robscott issue comment robscott/kube-capacity
robscott
incorrect data
in some cases, memory values for a node will not include the 'Mi' suffix:
10.145.197.168 42125m (75%) 148700m (265%) 221838Mi (82%) 416923Mi (154%)
10.145.197.169 45325m (80%) 121200m (216%) 62346Mi (23%) 180263Mi (66%)
10.145.197.170 14425m (25%) 37700m (67%) 45346Mi (16%) 100345Mi (37%)
162.150.14.214 13790m (24%) 45700m (81%) 39411368960000m (29%) 106336625408000m (78%)
162.150.14.215 13790m (24%) 39700m (70%) 38874498048000m (28%) 90767368960000m (67%)
162.150.14.216 16790m (29%) 42700m (76%) 46390690816000m (34%) 98283561728000m (72%)
162.150.14.217 12490m (22%) 39200m (70%) 38606062592000m (28%) 91841110784000m (68%)
In these cases, the report is wrong. need to change the logic here: https://github.com/robscott/kube-capacity/blob/master/pkg/capacity/resources.go#L356
for example, use more specific requestString and limitString so the code does not fall on the wrong unit: Example: add requestStringM() and limitStringM() that only converts Memory units to avoid the problem::
func (tp *tablePrinter) printClusterLine() {
tp.printLine(&tableLine{
node: "*",
namespace: "*",
pod: "*",
container: "*",
cpuRequests: tp.cm.cpu.requestString(tp.availableFormat),
cpuLimits: tp.cm.cpu.limitString(tp.availableFormat),
cpuUtil: tp.cm.cpu.utilString(tp.availableFormat),
memoryRequests: tp.cm.memory.requestStringM(tp.availableFormat),
memoryLimits: tp.cm.memory.limitStringM(tp.availableFormat),
memoryUtil: tp.cm.memory.utilString(tp.availableFormat),
podCount: tp.cm.podCount.podCountString(),
})
}
func (tp *tablePrinter) printNodeLine(nodeName string, nm *nodeMetric) {
tp.printLine(&tableLine{
node: nodeName,
namespace: "*",
pod: "*",
container: "*",
cpuRequests: nm.cpu.requestString(tp.availableFormat),
cpuLimits: nm.cpu.limitString(tp.availableFormat),
cpuUtil: nm.cpu.utilString(tp.availableFormat),
memoryRequests: nm.memory.requestStringM(tp.availableFormat),
memoryLimits: nm.memory.limitStringM(tp.availableFormat),
memoryUtil: nm.memory.utilString(tp.availableFormat),
podCount: nm.podCount.podCountString(),
})
}
robscott
Hey @christiancadieux, thanks for reporting this! I'm not sure how soon I'll be able to fix this, but very open to PRs.
robscott issue comment robscott/kube-capacity
robscott
Is possible to use the tool without listing nodes?
Hi community,
With my limited permissions, I have this error
kubectl resource-capacity --sort cpu.limit --util --pods
Error listing Nodes: nodes is forbidden: User "320144150" cannot list resource "nodes" in API group "" at the cluster scope
Is possible to use the tool with my limited RBAC permission?
Best regards, Jizu
robscott
Hey @jizusun, I think we could potentially add that as an option. I think it would take some refactoring to make it work. Open to any PRs if anyone can make it work.
Previous
Next
Topology Aware Hints
Enhancement Description
k/enhancements) update PR(s):k/k) update PR(s):k/website) update PR(s):/sig network