URLMap is the Schema for the URLMaps API. UrlMaps are used to route requests to a backend service based on rules that you define for the host and path of an incoming URL.
Type
CRD
Group
compute.gcp.upbound.io
Version
v1beta1
apiVersion: compute.gcp.upbound.io/v1beta1
kind: URLMap
URLMapSpec defines the desired state of URLMap
No description provided.
defaultRouteAction takes effect when none of the hostRules match. The load balancer performs advanced routing actions like URL rewrites, header transformations, etc. prior to forwarding the request to the selected backend. If defaultRouteAction specifies any weightedBackendServices, defaultService must not be set. Conversely if defaultService is set, defaultRouteAction cannot contain any weightedBackendServices. Only one of defaultRouteAction or defaultUrlRedirect must be set. Structure is documented below.
The specification for allowing client side cross-origin requests. Please see W3C Recommendation for Cross Origin Resource Sharing Structure is documented below.
Specifies the content for the Access-Control-Allow-Headers header.
Specifies the content for the Access-Control-Allow-Methods header.
Specifies the regular expression patterns that match allowed origins. For regular expression grammar please see en.cppreference.com/w/cpp/regex/ecmascript An origin is allowed if it matches either allow_origins or allow_origin_regex.
Specifies the list of origins that will be allowed to do CORS requests. An origin is allowed if it matches either allow_origins or allow_origin_regex.
Specifies the content for the Access-Control-Expose-Headers header.
The specification for fault injection introduced into traffic to test the resiliency of clients to backend service failure. As part of fault injection, when clients send requests to a backend service, delays can be introduced by Loadbalancer on a percentage of requests before sending those request to the backend service. Similarly requests from clients can be aborted by the Loadbalancer for a percentage of requests. timeout and retryPolicy will be ignored by clients that are configured with a faultInjectionPolicy. Structure is documented below.
The specification for how client requests are aborted as part of fault injection. Structure is documented below.
The specification for how client requests are delayed as part of fault injection, before being sent to a backend service. Structure is documented below.
Specifies the policy on how requests intended for the route's backends are shadowed to a separate mirrored backend service. Loadbalancer does not wait for responses from the shadow service. Prior to sending traffic to the shadow service, the host / authority header is suffixed with -shadow. Structure is documented below.
Specifies the retry policy associated with this route. Structure is documented below.
Specifies one or more conditions when this retry rule applies. Valid values are:
Specifies the timeout for the selected route. Timeout is computed from the time the request has been fully processed (i.e. end-of-stream) up until the response has been completely processed. Timeout includes all retries. If not specified, will use the largest timeout among all backend services associated with the route. Structure is documented below.
The spec to modify the URL of the request, prior to forwarding the request to the matched service. Structure is documented below.
A list of weighted backend services to send traffic to when a route match occurs. The weights determine the fraction of traffic that flows to their corresponding backend service. If all traffic needs to go to a single backend service, there must be one weightedBackendService with weight set to a non 0 number. Once a backendService is identified and before forwarding the request to the backend service, advanced routing actions like Url rewrites and header transformations are applied depending on additional settings specified in this HttpRouteAction. Structure is documented below.
Specifies changes to request and response headers that need to take effect for the selected backendService. headerAction specified here take effect before headerAction in the enclosing HttpRouteRule, PathMatcher and UrlMap. Structure is documented below.
Headers to add to a matching request prior to forwarding the request to the backendService. Structure is documented below.
A list of header names for headers that need to be removed from the request prior to forwarding the request to the backendService.
Headers to add the response prior to sending the response back to the client. Structure is documented below.
A list of header names for headers that need to be removed from the response prior to sending the response back to the client.
Reference to a BackendBucket in compute to populate defaultService.
Policies for referencing.
Selector for a BackendBucket in compute to populate defaultService.
Policies for selection.
When none of the specified hostRules match, the request is redirected to a URL specified by defaultUrlRedirect. If defaultUrlRedirect is specified, defaultService or defaultRouteAction must not be set. Structure is documented below.
Specifies changes to request and response headers that need to take effect for the selected backendService. The headerAction specified here take effect after headerAction specified under pathMatcher. Structure is documented below.
Headers to add to a matching request prior to forwarding the request to the backendService. Structure is documented below.
A list of header names for headers that need to be removed from the request prior to forwarding the request to the backendService.
Headers to add the response prior to sending the response back to the client. Structure is documented below.
A list of header names for headers that need to be removed from the response prior to sending the response back to the client.
The list of HostRules to use against the URL. Structure is documented below.
The list of host patterns to match. They must be valid hostnames, except * will match any string of ([a-z0-9-.]*). In that case, * must be the first character and must be followed in the pattern by either - or ..
The list of named PathMatchers to use against the URL. Structure is documented below.
defaultRouteAction takes effect when none of the pathRules or routeRules match. The load balancer performs advanced routing actions like URL rewrites, header transformations, etc. prior to forwarding the request to the selected backend. If defaultRouteAction specifies any weightedBackendServices, defaultService must not be set. Conversely if defaultService is set, defaultRouteAction cannot contain any weightedBackendServices. Only one of defaultRouteAction or defaultUrlRedirect must be set. Structure is documented below.
The specification for allowing client side cross-origin requests. Please see W3C Recommendation for Cross Origin Resource Sharing Structure is documented below.
Specifies the content for the Access-Control-Allow-Headers header.
Specifies the content for the Access-Control-Allow-Methods header.
Specifies the regular expression patterns that match allowed origins. For regular expression grammar please see en.cppreference.com/w/cpp/regex/ecmascript An origin is allowed if it matches either allow_origins or allow_origin_regex.
Specifies the list of origins that will be allowed to do CORS requests. An origin is allowed if it matches either allow_origins or allow_origin_regex.
Specifies the content for the Access-Control-Expose-Headers header.
The specification for fault injection introduced into traffic to test the resiliency of clients to backend service failure. As part of fault injection, when clients send requests to a backend service, delays can be introduced by Loadbalancer on a percentage of requests before sending those request to the backend service. Similarly requests from clients can be aborted by the Loadbalancer for a percentage of requests. timeout and retry_policy will be ignored by clients that are configured with a fault_injection_policy. Structure is documented below.
The specification for how client requests are aborted as part of fault injection. Structure is documented below.
The specification for how client requests are delayed as part of fault injection, before being sent to a backend service. Structure is documented below.
Specifies the policy on how requests intended for the route's backends are shadowed to a separate mirrored backend service. Loadbalancer does not wait for responses from the shadow service. Prior to sending traffic to the shadow service, the host / authority header is suffixed with -shadow. Structure is documented below.
Specifies the retry policy associated with this route. Structure is documented below.
Specifies one or more conditions when this retry rule applies. Valid values are:
Specifies the timeout for the selected route. Timeout is computed from the time the request is has been fully processed (i.e. end-of-stream) up until the response has been completely processed. Timeout includes all retries. If not specified, the default value is 15 seconds. Structure is documented below.
The spec to modify the URL of the request, prior to forwarding the request to the matched service Structure is documented below.
A list of weighted backend services to send traffic to when a route match occurs. The weights determine the fraction of traffic that flows to their corresponding backend service. If all traffic needs to go to a single backend service, there must be one weightedBackendService with weight set to a non 0 number. Once a backendService is identified and before forwarding the request to the backend service, advanced routing actions like Url rewrites and header transformations are applied depending on additional settings specified in this HttpRouteAction. Structure is documented below.
Specifies changes to request and response headers that need to take effect for the selected backendService. headerAction specified here take effect before headerAction in the enclosing HttpRouteRule, PathMatcher and UrlMap. Structure is documented below.
Headers to add to a matching request prior to forwarding the request to the backendService. Structure is documented below.
A list of header names for headers that need to be removed from the request prior to forwarding the request to the backendService.
Headers to add the response prior to sending the response back to the client. Structure is documented below.
A list of header names for headers that need to be removed from the response prior to sending the response back to the client.
Reference to a BackendBucket in compute to populate defaultService.
Policies for referencing.
Selector for a BackendBucket in compute to populate defaultService.
Policies for selection.
When none of the specified hostRules match, the request is redirected to a URL specified by defaultUrlRedirect. If defaultUrlRedirect is specified, defaultService or defaultRouteAction must not be set. Structure is documented below.
Specifies changes to request and response headers that need to take effect for the selected backendService. HeaderAction specified here are applied after the matching HttpRouteRule HeaderAction and before the HeaderAction in the UrlMap Structure is documented below.
Headers to add to a matching request prior to forwarding the request to the backendService. Structure is documented below.
A list of header names for headers that need to be removed from the request prior to forwarding the request to the backendService.
Headers to add the response prior to sending the response back to the client. Structure is documented below.
A list of header names for headers that need to be removed from the response prior to sending the response back to the client.
The list of path rules. Use this list instead of routeRules when routing based on simple path matching is all that's required. The order by which path rules are specified does not matter. Matches are always done on the longest-path-first basis. For example: a pathRule with a path /a/b/c/* will match before /a/b/* irrespective of the order in which those paths appear in this list. Within a given pathMatcher, only one of pathRules or routeRules must be set. Structure is documented below.
The list of path patterns to match. Each must start with / and the only place a * is allowed is at the end following a /. The string fed to the path matcher does not include any text after the first ? or #, and those chars are not allowed here.
In response to a matching matchRule, the load balancer performs advanced routing actions like URL rewrites, header transformations, etc. prior to forwarding the request to the selected backend. If routeAction specifies any weightedBackendServices, service must not be set. Conversely if service is set, routeAction cannot contain any weightedBackendServices. Only one of routeAction or urlRedirect must be set. Structure is documented below.
The specification for allowing client side cross-origin requests. Please see W3C Recommendation for Cross Origin Resource Sharing Structure is documented below.
Specifies the content for the Access-Control-Allow-Headers header.
Specifies the content for the Access-Control-Allow-Methods header.
Specifies the regular expression patterns that match allowed origins. For regular expression grammar please see en.cppreference.com/w/cpp/regex/ecmascript An origin is allowed if it matches either allow_origins or allow_origin_regex.
Specifies the list of origins that will be allowed to do CORS requests. An origin is allowed if it matches either allow_origins or allow_origin_regex.
Specifies the content for the Access-Control-Expose-Headers header.
The specification for fault injection introduced into traffic to test the resiliency of clients to backend service failure. As part of fault injection, when clients send requests to a backend service, delays can be introduced by Loadbalancer on a percentage of requests before sending those request to the backend service. Similarly requests from clients can be aborted by the Loadbalancer for a percentage of requests. timeout and retry_policy will be ignored by clients that are configured with a fault_injection_policy. Structure is documented below.
The specification for how client requests are aborted as part of fault injection. Structure is documented below.
The specification for how client requests are delayed as part of fault injection, before being sent to a backend service. Structure is documented below.
Specifies the policy on how requests intended for the route's backends are shadowed to a separate mirrored backend service. Loadbalancer does not wait for responses from the shadow service. Prior to sending traffic to the shadow service, the host / authority header is suffixed with -shadow. Structure is documented below.
Reference to a BackendService in compute to populate backendService.
Policies for referencing.
Selector for a BackendService in compute to populate backendService.
Policies for selection.
Specifies the retry policy associated with this route. Structure is documented below.
Specifies one or more conditions when this retry rule applies. Valid values are:
Specifies the timeout for the selected route. Timeout is computed from the time the request is has been fully processed (i.e. end-of-stream) up until the response has been completely processed. Timeout includes all retries. If not specified, the default value is 15 seconds. Structure is documented below.
The spec to modify the URL of the request, prior to forwarding the request to the matched service Structure is documented below.
A list of weighted backend services to send traffic to when a route match occurs. The weights determine the fraction of traffic that flows to their corresponding backend service. If all traffic needs to go to a single backend service, there must be one weightedBackendService with weight set to a non 0 number. Once a backendService is identified and before forwarding the request to the backend service, advanced routing actions like Url rewrites and header transformations are applied depending on additional settings specified in this HttpRouteAction. Structure is documented below.
Reference to a BackendService in compute to populate backendService.
Policies for referencing.
Selector for a BackendService in compute to populate backendService.
Policies for selection.
Specifies changes to request and response headers that need to take effect for the selected backendService. headerAction specified here take effect before headerAction in the enclosing HttpRouteRule, PathMatcher and UrlMap. Structure is documented below.
Headers to add to a matching request prior to forwarding the request to the backendService. Structure is documented below.
A list of header names for headers that need to be removed from the request prior to forwarding the request to the backendService.
Headers to add the response prior to sending the response back to the client. Structure is documented below.
A list of header names for headers that need to be removed from the response prior to sending the response back to the client.
Reference to a BackendBucket in compute to populate service.
Policies for referencing.
Selector for a BackendBucket in compute to populate service.
Policies for selection.
When this rule is matched, the request is redirected to a URL specified by urlRedirect. If urlRedirect is specified, service or routeAction must not be set. Structure is documented below.
The list of ordered HTTP route rules. Use this list instead of pathRules when advanced route matching and routing actions are desired. The order of specifying routeRules matters: the first rule that matches will cause its specified routing action to take effect. Within a given pathMatcher, only one of pathRules or routeRules must be set. routeRules are not supported in UrlMaps intended for External load balancers. Structure is documented below.
Specifies changes to request and response headers that need to take effect for the selected backendService. headerAction specified here take effect before headerAction in the enclosing HttpRouteRule, PathMatcher and UrlMap. Structure is documented below.
Headers to add to a matching request prior to forwarding the request to the backendService. Structure is documented below.
A list of header names for headers that need to be removed from the request prior to forwarding the request to the backendService.
Headers to add the response prior to sending the response back to the client. Structure is documented below.
A list of header names for headers that need to be removed from the response prior to sending the response back to the client.
The rules for determining a match. Structure is documented below.
Specifies a list of header match criteria, all of which must match corresponding headers in the request. Structure is documented below.
The header value must be an integer and its value must be in the range specified in rangeMatch. If the header does not contain an integer, number or is empty, the match fails. For example for a range [-5, 0] - -3 will match. - 0 will not match. - 0.25 will not match. - -3someString will not match. Only one of exactMatch, prefixMatch, suffixMatch, regexMatch, presentMatch or rangeMatch must be set. Structure is documented below.
Opaque filter criteria used by Loadbalancer to restrict routing configuration to a limited set xDS compliant clients. In their xDS requests to Loadbalancer, xDS clients present node metadata. If a match takes place, the relevant routing configuration is made available to those proxies. For each metadataFilter in this list, if its filterMatchCriteria is set to MATCH_ANY, at least one of the filterLabels must match the corresponding label provided in the metadata. If its filterMatchCriteria is set to MATCH_ALL, then all of its filterLabels must match with corresponding labels in the provided metadata. metadataFilters specified here can be overrides those specified in ForwardingRule that refers to this UrlMap. metadataFilters only applies to Loadbalancers that have their loadBalancingScheme set to INTERNAL_SELF_MANAGED. Structure is documented below.
Specifies a list of query parameter match criteria, all of which must match corresponding query parameters in the request. Structure is documented below.
In response to a matching matchRule, the load balancer performs advanced routing actions like URL rewrites, header transformations, etc. prior to forwarding the request to the selected backend. If routeAction specifies any weightedBackendServices, service must not be set. Conversely if service is set, routeAction cannot contain any weightedBackendServices. Only one of routeAction or urlRedirect must be set. Structure is documented below.
The specification for allowing client side cross-origin requests. Please see W3C Recommendation for Cross Origin Resource Sharing Structure is documented below.
Specifies the content for the Access-Control-Allow-Headers header.
Specifies the content for the Access-Control-Allow-Methods header.
Specifies the regular expression patterns that match allowed origins. For regular expression grammar please see en.cppreference.com/w/cpp/regex/ecmascript An origin is allowed if it matches either allow_origins or allow_origin_regex.
Specifies the list of origins that will be allowed to do CORS requests. An origin is allowed if it matches either allow_origins or allow_origin_regex.
Specifies the content for the Access-Control-Expose-Headers header.
The specification for fault injection introduced into traffic to test the resiliency of clients to backend service failure. As part of fault injection, when clients send requests to a backend service, delays can be introduced by Loadbalancer on a percentage of requests before sending those request to the backend service. Similarly requests from clients can be aborted by the Loadbalancer for a percentage of requests. timeout and retry_policy will be ignored by clients that are configured with a fault_injection_policy. Structure is documented below.
The specification for how client requests are aborted as part of fault injection. Structure is documented below.
The specification for how client requests are delayed as part of fault injection, before being sent to a backend service. Structure is documented below.
Specifies the policy on how requests intended for the route's backends are shadowed to a separate mirrored backend service. Loadbalancer does not wait for responses from the shadow service. Prior to sending traffic to the shadow service, the host / authority header is suffixed with -shadow. Structure is documented below.
Specifies the retry policy associated with this route. Structure is documented below.
Specifies one or more conditions when this retry rule applies. Valid values are:
Specifies the timeout for the selected route. Timeout is computed from the time the request is has been fully processed (i.e. end-of-stream) up until the response has been completely processed. Timeout includes all retries. If not specified, the default value is 15 seconds. Structure is documented below.
The spec to modify the URL of the request, prior to forwarding the request to the matched service Structure is documented below.
A list of weighted backend services to send traffic to when a route match occurs. The weights determine the fraction of traffic that flows to their corresponding backend service. If all traffic needs to go to a single backend service, there must be one weightedBackendService with weight set to a non 0 number. Once a backendService is identified and before forwarding the request to the backend service, advanced routing actions like Url rewrites and header transformations are applied depending on additional settings specified in this HttpRouteAction. Structure is documented below.
Specifies changes to request and response headers that need to take effect for the selected backendService. headerAction specified here take effect before headerAction in the enclosing HttpRouteRule, PathMatcher and UrlMap. Structure is documented below.
Headers to add to a matching request prior to forwarding the request to the backendService. Structure is documented below.
A list of header names for headers that need to be removed from the request prior to forwarding the request to the backendService.
Headers to add the response prior to sending the response back to the client. Structure is documented below.
A list of header names for headers that need to be removed from the response prior to sending the response back to the client.
Reference to a BackendService in compute to populate service.
Policies for referencing.
Selector for a BackendService in compute to populate service.
Policies for selection.
When this rule is matched, the request is redirected to a URL specified by urlRedirect. If urlRedirect is specified, service or routeAction must not be set. Structure is documented below.
The list of expected URL mapping tests. Request to update this UrlMap will succeed only if all of the test cases pass. You can specify a maximum of 100 tests per UrlMap. Structure is documented below.
Reference to a BackendBucket in compute to populate service.
Policies for referencing.
Selector for a BackendBucket in compute to populate service.
Policies for selection.
THIS IS AN ALPHA FIELD. Do not use it in production. It is not honored unless the relevant Crossplane feature flag is enabled, and may be changed or removed without notice. InitProvider holds the same fields as ForProvider, with the exception of Identifier and other resource reference fields. The fields that are in InitProvider are merged into ForProvider when the resource is created. The same fields are also added to the terraform ignore_changes hook, to avoid updating them after creation. This is useful for fields that are required on creation, but we do not desire to update them after creation, for example because of an external controller is managing them, like an autoscaler.
defaultRouteAction takes effect when none of the hostRules match. The load balancer performs advanced routing actions like URL rewrites, header transformations, etc. prior to forwarding the request to the selected backend. If defaultRouteAction specifies any weightedBackendServices, defaultService must not be set. Conversely if defaultService is set, defaultRouteAction cannot contain any weightedBackendServices. Only one of defaultRouteAction or defaultUrlRedirect must be set. Structure is documented below.
The specification for allowing client side cross-origin requests. Please see W3C Recommendation for Cross Origin Resource Sharing Structure is documented below.
Specifies the content for the Access-Control-Allow-Headers header.
Specifies the content for the Access-Control-Allow-Methods header.
Specifies the regular expression patterns that match allowed origins. For regular expression grammar please see en.cppreference.com/w/cpp/regex/ecmascript An origin is allowed if it matches either allow_origins or allow_origin_regex.
Specifies the list of origins that will be allowed to do CORS requests. An origin is allowed if it matches either allow_origins or allow_origin_regex.
Specifies the content for the Access-Control-Expose-Headers header.
The specification for fault injection introduced into traffic to test the resiliency of clients to backend service failure. As part of fault injection, when clients send requests to a backend service, delays can be introduced by Loadbalancer on a percentage of requests before sending those request to the backend service. Similarly requests from clients can be aborted by the Loadbalancer for a percentage of requests. timeout and retryPolicy will be ignored by clients that are configured with a faultInjectionPolicy. Structure is documented below.
The specification for how client requests are aborted as part of fault injection. Structure is documented below.
The specification for how client requests are delayed as part of fault injection, before being sent to a backend service. Structure is documented below.
Specifies the policy on how requests intended for the route's backends are shadowed to a separate mirrored backend service. Loadbalancer does not wait for responses from the shadow service. Prior to sending traffic to the shadow service, the host / authority header is suffixed with -shadow. Structure is documented below.
Specifies the retry policy associated with this route. Structure is documented below.
Specifies one or more conditions when this retry rule applies. Valid values are:
Specifies the timeout for the selected route. Timeout is computed from the time the request has been fully processed (i.e. end-of-stream) up until the response has been completely processed. Timeout includes all retries. If not specified, will use the largest timeout among all backend services associated with the route. Structure is documented below.
The spec to modify the URL of the request, prior to forwarding the request to the matched service. Structure is documented below.
A list of weighted backend services to send traffic to when a route match occurs. The weights determine the fraction of traffic that flows to their corresponding backend service. If all traffic needs to go to a single backend service, there must be one weightedBackendService with weight set to a non 0 number. Once a backendService is identified and before forwarding the request to the backend service, advanced routing actions like Url rewrites and header transformations are applied depending on additional settings specified in this HttpRouteAction. Structure is documented below.
Specifies changes to request and response headers that need to take effect for the selected backendService. headerAction specified here take effect before headerAction in the enclosing HttpRouteRule, PathMatcher and UrlMap. Structure is documented below.
Headers to add to a matching request prior to forwarding the request to the backendService. Structure is documented below.
A list of header names for headers that need to be removed from the request prior to forwarding the request to the backendService.
Headers to add the response prior to sending the response back to the client. Structure is documented below.
A list of header names for headers that need to be removed from the response prior to sending the response back to the client.
When none of the specified hostRules match, the request is redirected to a URL specified by defaultUrlRedirect. If defaultUrlRedirect is specified, defaultService or defaultRouteAction must not be set. Structure is documented below.
Specifies changes to request and response headers that need to take effect for the selected backendService. The headerAction specified here take effect after headerAction specified under pathMatcher. Structure is documented below.
Headers to add to a matching request prior to forwarding the request to the backendService. Structure is documented below.
A list of header names for headers that need to be removed from the request prior to forwarding the request to the backendService.
Headers to add the response prior to sending the response back to the client. Structure is documented below.
A list of header names for headers that need to be removed from the response prior to sending the response back to the client.
The list of HostRules to use against the URL. Structure is documented below.
The list of host patterns to match. They must be valid hostnames, except * will match any string of ([a-z0-9-.]*). In that case, * must be the first character and must be followed in the pattern by either - or ..
The list of named PathMatchers to use against the URL. Structure is documented below.
defaultRouteAction takes effect when none of the pathRules or routeRules match. The load balancer performs advanced routing actions like URL rewrites, header transformations, etc. prior to forwarding the request to the selected backend. If defaultRouteAction specifies any weightedBackendServices, defaultService must not be set. Conversely if defaultService is set, defaultRouteAction cannot contain any weightedBackendServices. Only one of defaultRouteAction or defaultUrlRedirect must be set. Structure is documented below.
The specification for allowing client side cross-origin requests. Please see W3C Recommendation for Cross Origin Resource Sharing Structure is documented below.
Specifies the content for the Access-Control-Allow-Headers header.
Specifies the content for the Access-Control-Allow-Methods header.
Specifies the regular expression patterns that match allowed origins. For regular expression grammar please see en.cppreference.com/w/cpp/regex/ecmascript An origin is allowed if it matches either allow_origins or allow_origin_regex.
Specifies the list of origins that will be allowed to do CORS requests. An origin is allowed if it matches either allow_origins or allow_origin_regex.
Specifies the content for the Access-Control-Expose-Headers header.
The specification for fault injection introduced into traffic to test the resiliency of clients to backend service failure. As part of fault injection, when clients send requests to a backend service, delays can be introduced by Loadbalancer on a percentage of requests before sending those request to the backend service. Similarly requests from clients can be aborted by the Loadbalancer for a percentage of requests. timeout and retry_policy will be ignored by clients that are configured with a fault_injection_policy. Structure is documented below.
The specification for how client requests are aborted as part of fault injection. Structure is documented below.
The specification for how client requests are delayed as part of fault injection, before being sent to a backend service. Structure is documented below.
Specifies the policy on how requests intended for the route's backends are shadowed to a separate mirrored backend service. Loadbalancer does not wait for responses from the shadow service. Prior to sending traffic to the shadow service, the host / authority header is suffixed with -shadow. Structure is documented below.
Specifies the retry policy associated with this route. Structure is documented below.
Specifies one or more conditions when this retry rule applies. Valid values are:
Specifies the timeout for the selected route. Timeout is computed from the time the request is has been fully processed (i.e. end-of-stream) up until the response has been completely processed. Timeout includes all retries. If not specified, the default value is 15 seconds. Structure is documented below.
The spec to modify the URL of the request, prior to forwarding the request to the matched service Structure is documented below.
A list of weighted backend services to send traffic to when a route match occurs. The weights determine the fraction of traffic that flows to their corresponding backend service. If all traffic needs to go to a single backend service, there must be one weightedBackendService with weight set to a non 0 number. Once a backendService is identified and before forwarding the request to the backend service, advanced routing actions like Url rewrites and header transformations are applied depending on additional settings specified in this HttpRouteAction. Structure is documented below.
Specifies changes to request and response headers that need to take effect for the selected backendService. headerAction specified here take effect before headerAction in the enclosing HttpRouteRule, PathMatcher and UrlMap. Structure is documented below.
Headers to add to a matching request prior to forwarding the request to the backendService. Structure is documented below.
A list of header names for headers that need to be removed from the request prior to forwarding the request to the backendService.
Headers to add the response prior to sending the response back to the client. Structure is documented below.
A list of header names for headers that need to be removed from the response prior to sending the response back to the client.
When none of the specified hostRules match, the request is redirected to a URL specified by defaultUrlRedirect. If defaultUrlRedirect is specified, defaultService or defaultRouteAction must not be set. Structure is documented below.
Specifies changes to request and response headers that need to take effect for the selected backendService. HeaderAction specified here are applied after the matching HttpRouteRule HeaderAction and before the HeaderAction in the UrlMap Structure is documented below.
Headers to add to a matching request prior to forwarding the request to the backendService. Structure is documented below.
A list of header names for headers that need to be removed from the request prior to forwarding the request to the backendService.
Headers to add the response prior to sending the response back to the client. Structure is documented below.
A list of header names for headers that need to be removed from the response prior to sending the response back to the client.
The list of path rules. Use this list instead of routeRules when routing based on simple path matching is all that's required. The order by which path rules are specified does not matter. Matches are always done on the longest-path-first basis. For example: a pathRule with a path /a/b/c/* will match before /a/b/* irrespective of the order in which those paths appear in this list. Within a given pathMatcher, only one of pathRules or routeRules must be set. Structure is documented below.
The list of path patterns to match. Each must start with / and the only place a * is allowed is at the end following a /. The string fed to the path matcher does not include any text after the first ? or #, and those chars are not allowed here.
In response to a matching matchRule, the load balancer performs advanced routing actions like URL rewrites, header transformations, etc. prior to forwarding the request to the selected backend. If routeAction specifies any weightedBackendServices, service must not be set. Conversely if service is set, routeAction cannot contain any weightedBackendServices. Only one of routeAction or urlRedirect must be set. Structure is documented below.
The specification for allowing client side cross-origin requests. Please see W3C Recommendation for Cross Origin Resource Sharing Structure is documented below.
Specifies the content for the Access-Control-Allow-Headers header.
Specifies the content for the Access-Control-Allow-Methods header.
Specifies the regular expression patterns that match allowed origins. For regular expression grammar please see en.cppreference.com/w/cpp/regex/ecmascript An origin is allowed if it matches either allow_origins or allow_origin_regex.
Specifies the list of origins that will be allowed to do CORS requests. An origin is allowed if it matches either allow_origins or allow_origin_regex.
Specifies the content for the Access-Control-Expose-Headers header.
The specification for fault injection introduced into traffic to test the resiliency of clients to backend service failure. As part of fault injection, when clients send requests to a backend service, delays can be introduced by Loadbalancer on a percentage of requests before sending those request to the backend service. Similarly requests from clients can be aborted by the Loadbalancer for a percentage of requests. timeout and retry_policy will be ignored by clients that are configured with a fault_injection_policy. Structure is documented below.
The specification for how client requests are aborted as part of fault injection. Structure is documented below.
The specification for how client requests are delayed as part of fault injection, before being sent to a backend service. Structure is documented below.
Specifies the policy on how requests intended for the route's backends are shadowed to a separate mirrored backend service. Loadbalancer does not wait for responses from the shadow service. Prior to sending traffic to the shadow service, the host / authority header is suffixed with -shadow. Structure is documented below.
Specifies the retry policy associated with this route. Structure is documented below.
Specifies one or more conditions when this retry rule applies. Valid values are:
Specifies the timeout for the selected route. Timeout is computed from the time the request is has been fully processed (i.e. end-of-stream) up until the response has been completely processed. Timeout includes all retries. If not specified, the default value is 15 seconds. Structure is documented below.
The spec to modify the URL of the request, prior to forwarding the request to the matched service Structure is documented below.
A list of weighted backend services to send traffic to when a route match occurs. The weights determine the fraction of traffic that flows to their corresponding backend service. If all traffic needs to go to a single backend service, there must be one weightedBackendService with weight set to a non 0 number. Once a backendService is identified and before forwarding the request to the backend service, advanced routing actions like Url rewrites and header transformations are applied depending on additional settings specified in this HttpRouteAction. Structure is documented below.
Specifies changes to request and response headers that need to take effect for the selected backendService. headerAction specified here take effect before headerAction in the enclosing HttpRouteRule, PathMatcher and UrlMap. Structure is documented below.
Headers to add to a matching request prior to forwarding the request to the backendService. Structure is documented below.
A list of header names for headers that need to be removed from the request prior to forwarding the request to the backendService.
Headers to add the response prior to sending the response back to the client. Structure is documented below.
A list of header names for headers that need to be removed from the response prior to sending the response back to the client.
When this rule is matched, the request is redirected to a URL specified by urlRedirect. If urlRedirect is specified, service or routeAction must not be set. Structure is documented below.
The list of ordered HTTP route rules. Use this list instead of pathRules when advanced route matching and routing actions are desired. The order of specifying routeRules matters: the first rule that matches will cause its specified routing action to take effect. Within a given pathMatcher, only one of pathRules or routeRules must be set. routeRules are not supported in UrlMaps intended for External load balancers. Structure is documented below.
Specifies changes to request and response headers that need to take effect for the selected backendService. headerAction specified here take effect before headerAction in the enclosing HttpRouteRule, PathMatcher and UrlMap. Structure is documented below.
Headers to add to a matching request prior to forwarding the request to the backendService. Structure is documented below.
A list of header names for headers that need to be removed from the request prior to forwarding the request to the backendService.
Headers to add the response prior to sending the response back to the client. Structure is documented below.
A list of header names for headers that need to be removed from the response prior to sending the response back to the client.
The rules for determining a match. Structure is documented below.
Specifies a list of header match criteria, all of which must match corresponding headers in the request. Structure is documented below.
The header value must be an integer and its value must be in the range specified in rangeMatch. If the header does not contain an integer, number or is empty, the match fails. For example for a range [-5, 0] - -3 will match. - 0 will not match. - 0.25 will not match. - -3someString will not match. Only one of exactMatch, prefixMatch, suffixMatch, regexMatch, presentMatch or rangeMatch must be set. Structure is documented below.
Opaque filter criteria used by Loadbalancer to restrict routing configuration to a limited set xDS compliant clients. In their xDS requests to Loadbalancer, xDS clients present node metadata. If a match takes place, the relevant routing configuration is made available to those proxies. For each metadataFilter in this list, if its filterMatchCriteria is set to MATCH_ANY, at least one of the filterLabels must match the corresponding label provided in the metadata. If its filterMatchCriteria is set to MATCH_ALL, then all of its filterLabels must match with corresponding labels in the provided metadata. metadataFilters specified here can be overrides those specified in ForwardingRule that refers to this UrlMap. metadataFilters only applies to Loadbalancers that have their loadBalancingScheme set to INTERNAL_SELF_MANAGED. Structure is documented below.
Specifies a list of query parameter match criteria, all of which must match corresponding query parameters in the request. Structure is documented below.
In response to a matching matchRule, the load balancer performs advanced routing actions like URL rewrites, header transformations, etc. prior to forwarding the request to the selected backend. If routeAction specifies any weightedBackendServices, service must not be set. Conversely if service is set, routeAction cannot contain any weightedBackendServices. Only one of routeAction or urlRedirect must be set. Structure is documented below.
The specification for allowing client side cross-origin requests. Please see W3C Recommendation for Cross Origin Resource Sharing Structure is documented below.
Specifies the content for the Access-Control-Allow-Headers header.
Specifies the content for the Access-Control-Allow-Methods header.
Specifies the regular expression patterns that match allowed origins. For regular expression grammar please see en.cppreference.com/w/cpp/regex/ecmascript An origin is allowed if it matches either allow_origins or allow_origin_regex.
Specifies the list of origins that will be allowed to do CORS requests. An origin is allowed if it matches either allow_origins or allow_origin_regex.
Specifies the content for the Access-Control-Expose-Headers header.
The specification for fault injection introduced into traffic to test the resiliency of clients to backend service failure. As part of fault injection, when clients send requests to a backend service, delays can be introduced by Loadbalancer on a percentage of requests before sending those request to the backend service. Similarly requests from clients can be aborted by the Loadbalancer for a percentage of requests. timeout and retry_policy will be ignored by clients that are configured with a fault_injection_policy. Structure is documented below.
The specification for how client requests are aborted as part of fault injection. Structure is documented below.
The specification for how client requests are delayed as part of fault injection, before being sent to a backend service. Structure is documented below.
Specifies the policy on how requests intended for the route's backends are shadowed to a separate mirrored backend service. Loadbalancer does not wait for responses from the shadow service. Prior to sending traffic to the shadow service, the host / authority header is suffixed with -shadow. Structure is documented below.
Specifies the retry policy associated with this route. Structure is documented below.
Specifies one or more conditions when this retry rule applies. Valid values are:
Specifies the timeout for the selected route. Timeout is computed from the time the request is has been fully processed (i.e. end-of-stream) up until the response has been completely processed. Timeout includes all retries. If not specified, the default value is 15 seconds. Structure is documented below.
The spec to modify the URL of the request, prior to forwarding the request to the matched service Structure is documented below.
A list of weighted backend services to send traffic to when a route match occurs. The weights determine the fraction of traffic that flows to their corresponding backend service. If all traffic needs to go to a single backend service, there must be one weightedBackendService with weight set to a non 0 number. Once a backendService is identified and before forwarding the request to the backend service, advanced routing actions like Url rewrites and header transformations are applied depending on additional settings specified in this HttpRouteAction. Structure is documented below.
Specifies changes to request and response headers that need to take effect for the selected backendService. headerAction specified here take effect before headerAction in the enclosing HttpRouteRule, PathMatcher and UrlMap. Structure is documented below.
Headers to add to a matching request prior to forwarding the request to the backendService. Structure is documented below.
A list of header names for headers that need to be removed from the request prior to forwarding the request to the backendService.
Headers to add the response prior to sending the response back to the client. Structure is documented below.
A list of header names for headers that need to be removed from the response prior to sending the response back to the client.
When this rule is matched, the request is redirected to a URL specified by urlRedirect. If urlRedirect is specified, service or routeAction must not be set. Structure is documented below.
The list of expected URL mapping tests. Request to update this UrlMap will succeed only if all of the test cases pass. You can specify a maximum of 100 tests per UrlMap. Structure is documented below.
THIS IS AN ALPHA FIELD. Do not use it in production. It is not honored unless the relevant Crossplane feature flag is enabled, and may be changed or removed without notice. ManagementPolicies specify the array of actions Crossplane is allowed to take on the managed and external resources. This field is planned to replace the DeletionPolicy field in a future release. Currently, both could be set independently and non-default values would be honored if the feature flag is enabled. If both are custom, the DeletionPolicy field will be ignored. See the design doc for more information: https://github.com/crossplane/crossplane/blob/499895a25d1a1a0ba1604944ef98ac7a1a71f197/design/design-doc-observe-only-resources.md?plain=1#L223 and this one: https://github.com/crossplane/crossplane/blob/444267e84783136daa93568b364a5f01228cacbe/design/one-pager-ignore-changes.md
ProviderConfigReference specifies how the provider that will be used to create, observe, update, and delete this managed resource should be configured.
Policies for referencing.
ProviderReference specifies the provider that will be used to create, observe, update, and delete this managed resource. Deprecated: Please use ProviderConfigReference, i.e. providerConfigRef
Policies for referencing.
PublishConnectionDetailsTo specifies the connection secret config which contains a name, metadata and a reference to secret store config to which any connection details for this managed resource should be written. Connection details frequently include the endpoint, username, and password required to connect to the managed resource.
WriteConnectionSecretToReference specifies the namespace and name of a Secret to which any connection details for this managed resource should be written. Connection details frequently include the endpoint, username, and password required to connect to the managed resource. This field is planned to be replaced in a future release in favor of PublishConnectionDetailsTo. Currently, both could be set independently and connection details would be published to both without affecting each other.
URLMapStatus defines the observed state of URLMap.
No description provided.
defaultRouteAction takes effect when none of the hostRules match. The load balancer performs advanced routing actions like URL rewrites, header transformations, etc. prior to forwarding the request to the selected backend. If defaultRouteAction specifies any weightedBackendServices, defaultService must not be set. Conversely if defaultService is set, defaultRouteAction cannot contain any weightedBackendServices. Only one of defaultRouteAction or defaultUrlRedirect must be set. Structure is documented below.
The specification for allowing client side cross-origin requests. Please see W3C Recommendation for Cross Origin Resource Sharing Structure is documented below.
Specifies the content for the Access-Control-Allow-Headers header.
Specifies the content for the Access-Control-Allow-Methods header.
Specifies the regular expression patterns that match allowed origins. For regular expression grammar please see en.cppreference.com/w/cpp/regex/ecmascript An origin is allowed if it matches either allow_origins or allow_origin_regex.
Specifies the list of origins that will be allowed to do CORS requests. An origin is allowed if it matches either allow_origins or allow_origin_regex.
Specifies the content for the Access-Control-Expose-Headers header.
The specification for fault injection introduced into traffic to test the resiliency of clients to backend service failure. As part of fault injection, when clients send requests to a backend service, delays can be introduced by Loadbalancer on a percentage of requests before sending those request to the backend service. Similarly requests from clients can be aborted by the Loadbalancer for a percentage of requests. timeout and retryPolicy will be ignored by clients that are configured with a faultInjectionPolicy. Structure is documented below.
The specification for how client requests are aborted as part of fault injection. Structure is documented below.
The specification for how client requests are delayed as part of fault injection, before being sent to a backend service. Structure is documented below.
Specifies the policy on how requests intended for the route's backends are shadowed to a separate mirrored backend service. Loadbalancer does not wait for responses from the shadow service. Prior to sending traffic to the shadow service, the host / authority header is suffixed with -shadow. Structure is documented below.
Specifies the retry policy associated with this route. Structure is documented below.
Specifies one or more conditions when this retry rule applies. Valid values are:
Specifies the timeout for the selected route. Timeout is computed from the time the request has been fully processed (i.e. end-of-stream) up until the response has been completely processed. Timeout includes all retries. If not specified, will use the largest timeout among all backend services associated with the route. Structure is documented below.
The spec to modify the URL of the request, prior to forwarding the request to the matched service. Structure is documented below.
A list of weighted backend services to send traffic to when a route match occurs. The weights determine the fraction of traffic that flows to their corresponding backend service. If all traffic needs to go to a single backend service, there must be one weightedBackendService with weight set to a non 0 number. Once a backendService is identified and before forwarding the request to the backend service, advanced routing actions like Url rewrites and header transformations are applied depending on additional settings specified in this HttpRouteAction. Structure is documented below.
Specifies changes to request and response headers that need to take effect for the selected backendService. headerAction specified here take effect before headerAction in the enclosing HttpRouteRule, PathMatcher and UrlMap. Structure is documented below.
Headers to add to a matching request prior to forwarding the request to the backendService. Structure is documented below.
A list of header names for headers that need to be removed from the request prior to forwarding the request to the backendService.
Headers to add the response prior to sending the response back to the client. Structure is documented below.
A list of header names for headers that need to be removed from the response prior to sending the response back to the client.
When none of the specified hostRules match, the request is redirected to a URL specified by defaultUrlRedirect. If defaultUrlRedirect is specified, defaultService or defaultRouteAction must not be set. Structure is documented below.
Specifies changes to request and response headers that need to take effect for the selected backendService. The headerAction specified here take effect after headerAction specified under pathMatcher. Structure is documented below.
Headers to add to a matching request prior to forwarding the request to the backendService. Structure is documented below.
A list of header names for headers that need to be removed from the request prior to forwarding the request to the backendService.
Headers to add the response prior to sending the response back to the client. Structure is documented below.
A list of header names for headers that need to be removed from the response prior to sending the response back to the client.
The list of HostRules to use against the URL. Structure is documented below.
The list of host patterns to match. They must be valid hostnames, except * will match any string of ([a-z0-9-.]*). In that case, * must be the first character and must be followed in the pattern by either - or ..
The list of named PathMatchers to use against the URL. Structure is documented below.
defaultRouteAction takes effect when none of the pathRules or routeRules match. The load balancer performs advanced routing actions like URL rewrites, header transformations, etc. prior to forwarding the request to the selected backend. If defaultRouteAction specifies any weightedBackendServices, defaultService must not be set. Conversely if defaultService is set, defaultRouteAction cannot contain any weightedBackendServices. Only one of defaultRouteAction or defaultUrlRedirect must be set. Structure is documented below.
The specification for allowing client side cross-origin requests. Please see W3C Recommendation for Cross Origin Resource Sharing Structure is documented below.
Specifies the content for the Access-Control-Allow-Headers header.
Specifies the content for the Access-Control-Allow-Methods header.
Specifies the regular expression patterns that match allowed origins. For regular expression grammar please see en.cppreference.com/w/cpp/regex/ecmascript An origin is allowed if it matches either allow_origins or allow_origin_regex.
Specifies the list of origins that will be allowed to do CORS requests. An origin is allowed if it matches either allow_origins or allow_origin_regex.
Specifies the content for the Access-Control-Expose-Headers header.
The specification for fault injection introduced into traffic to test the resiliency of clients to backend service failure. As part of fault injection, when clients send requests to a backend service, delays can be introduced by Loadbalancer on a percentage of requests before sending those request to the backend service. Similarly requests from clients can be aborted by the Loadbalancer for a percentage of requests. timeout and retry_policy will be ignored by clients that are configured with a fault_injection_policy. Structure is documented below.
The specification for how client requests are aborted as part of fault injection. Structure is documented below.
The specification for how client requests are delayed as part of fault injection, before being sent to a backend service. Structure is documented below.
Specifies the policy on how requests intended for the route's backends are shadowed to a separate mirrored backend service. Loadbalancer does not wait for responses from the shadow service. Prior to sending traffic to the shadow service, the host / authority header is suffixed with -shadow. Structure is documented below.
Specifies the retry policy associated with this route. Structure is documented below.
Specifies one or more conditions when this retry rule applies. Valid values are:
Specifies the timeout for the selected route. Timeout is computed from the time the request is has been fully processed (i.e. end-of-stream) up until the response has been completely processed. Timeout includes all retries. If not specified, the default value is 15 seconds. Structure is documented below.
The spec to modify the URL of the request, prior to forwarding the request to the matched service Structure is documented below.
A list of weighted backend services to send traffic to when a route match occurs. The weights determine the fraction of traffic that flows to their corresponding backend service. If all traffic needs to go to a single backend service, there must be one weightedBackendService with weight set to a non 0 number. Once a backendService is identified and before forwarding the request to the backend service, advanced routing actions like Url rewrites and header transformations are applied depending on additional settings specified in this HttpRouteAction. Structure is documented below.
Specifies changes to request and response headers that need to take effect for the selected backendService. headerAction specified here take effect before headerAction in the enclosing HttpRouteRule, PathMatcher and UrlMap. Structure is documented below.
Headers to add to a matching request prior to forwarding the request to the backendService. Structure is documented below.
A list of header names for headers that need to be removed from the request prior to forwarding the request to the backendService.
Headers to add the response prior to sending the response back to the client. Structure is documented below.
A list of header names for headers that need to be removed from the response prior to sending the response back to the client.
When none of the specified hostRules match, the request is redirected to a URL specified by defaultUrlRedirect. If defaultUrlRedirect is specified, defaultService or defaultRouteAction must not be set. Structure is documented below.
Specifies changes to request and response headers that need to take effect for the selected backendService. HeaderAction specified here are applied after the matching HttpRouteRule HeaderAction and before the HeaderAction in the UrlMap Structure is documented below.
Headers to add to a matching request prior to forwarding the request to the backendService. Structure is documented below.
A list of header names for headers that need to be removed from the request prior to forwarding the request to the backendService.
Headers to add the response prior to sending the response back to the client. Structure is documented below.
A list of header names for headers that need to be removed from the response prior to sending the response back to the client.
The list of path rules. Use this list instead of routeRules when routing based on simple path matching is all that's required. The order by which path rules are specified does not matter. Matches are always done on the longest-path-first basis. For example: a pathRule with a path /a/b/c/* will match before /a/b/* irrespective of the order in which those paths appear in this list. Within a given pathMatcher, only one of pathRules or routeRules must be set. Structure is documented below.
The list of path patterns to match. Each must start with / and the only place a * is allowed is at the end following a /. The string fed to the path matcher does not include any text after the first ? or #, and those chars are not allowed here.
In response to a matching matchRule, the load balancer performs advanced routing actions like URL rewrites, header transformations, etc. prior to forwarding the request to the selected backend. If routeAction specifies any weightedBackendServices, service must not be set. Conversely if service is set, routeAction cannot contain any weightedBackendServices. Only one of routeAction or urlRedirect must be set. Structure is documented below.
The specification for allowing client side cross-origin requests. Please see W3C Recommendation for Cross Origin Resource Sharing Structure is documented below.
Specifies the content for the Access-Control-Allow-Headers header.
Specifies the content for the Access-Control-Allow-Methods header.
Specifies the regular expression patterns that match allowed origins. For regular expression grammar please see en.cppreference.com/w/cpp/regex/ecmascript An origin is allowed if it matches either allow_origins or allow_origin_regex.
Specifies the list of origins that will be allowed to do CORS requests. An origin is allowed if it matches either allow_origins or allow_origin_regex.
Specifies the content for the Access-Control-Expose-Headers header.
The specification for fault injection introduced into traffic to test the resiliency of clients to backend service failure. As part of fault injection, when clients send requests to a backend service, delays can be introduced by Loadbalancer on a percentage of requests before sending those request to the backend service. Similarly requests from clients can be aborted by the Loadbalancer for a percentage of requests. timeout and retry_policy will be ignored by clients that are configured with a fault_injection_policy. Structure is documented below.
The specification for how client requests are aborted as part of fault injection. Structure is documented below.
The specification for how client requests are delayed as part of fault injection, before being sent to a backend service. Structure is documented below.
Specifies the policy on how requests intended for the route's backends are shadowed to a separate mirrored backend service. Loadbalancer does not wait for responses from the shadow service. Prior to sending traffic to the shadow service, the host / authority header is suffixed with -shadow. Structure is documented below.
Specifies the retry policy associated with this route. Structure is documented below.
Specifies one or more conditions when this retry rule applies. Valid values are:
Specifies the timeout for the selected route. Timeout is computed from the time the request is has been fully processed (i.e. end-of-stream) up until the response has been completely processed. Timeout includes all retries. If not specified, the default value is 15 seconds. Structure is documented below.
The spec to modify the URL of the request, prior to forwarding the request to the matched service Structure is documented below.
A list of weighted backend services to send traffic to when a route match occurs. The weights determine the fraction of traffic that flows to their corresponding backend service. If all traffic needs to go to a single backend service, there must be one weightedBackendService with weight set to a non 0 number. Once a backendService is identified and before forwarding the request to the backend service, advanced routing actions like Url rewrites and header transformations are applied depending on additional settings specified in this HttpRouteAction. Structure is documented below.
Specifies changes to request and response headers that need to take effect for the selected backendService. headerAction specified here take effect before headerAction in the enclosing HttpRouteRule, PathMatcher and UrlMap. Structure is documented below.
Headers to add to a matching request prior to forwarding the request to the backendService. Structure is documented below.
A list of header names for headers that need to be removed from the request prior to forwarding the request to the backendService.
Headers to add the response prior to sending the response back to the client. Structure is documented below.
A list of header names for headers that need to be removed from the response prior to sending the response back to the client.
When this rule is matched, the request is redirected to a URL specified by urlRedirect. If urlRedirect is specified, service or routeAction must not be set. Structure is documented below.
The list of ordered HTTP route rules. Use this list instead of pathRules when advanced route matching and routing actions are desired. The order of specifying routeRules matters: the first rule that matches will cause its specified routing action to take effect. Within a given pathMatcher, only one of pathRules or routeRules must be set. routeRules are not supported in UrlMaps intended for External load balancers. Structure is documented below.
Specifies changes to request and response headers that need to take effect for the selected backendService. headerAction specified here take effect before headerAction in the enclosing HttpRouteRule, PathMatcher and UrlMap. Structure is documented below.
Headers to add to a matching request prior to forwarding the request to the backendService. Structure is documented below.
A list of header names for headers that need to be removed from the request prior to forwarding the request to the backendService.
Headers to add the response prior to sending the response back to the client. Structure is documented below.
A list of header names for headers that need to be removed from the response prior to sending the response back to the client.
The rules for determining a match. Structure is documented below.
Specifies a list of header match criteria, all of which must match corresponding headers in the request. Structure is documented below.
The header value must be an integer and its value must be in the range specified in rangeMatch. If the header does not contain an integer, number or is empty, the match fails. For example for a range [-5, 0] - -3 will match. - 0 will not match. - 0.25 will not match. - -3someString will not match. Only one of exactMatch, prefixMatch, suffixMatch, regexMatch, presentMatch or rangeMatch must be set. Structure is documented below.
Opaque filter criteria used by Loadbalancer to restrict routing configuration to a limited set xDS compliant clients. In their xDS requests to Loadbalancer, xDS clients present node metadata. If a match takes place, the relevant routing configuration is made available to those proxies. For each metadataFilter in this list, if its filterMatchCriteria is set to MATCH_ANY, at least one of the filterLabels must match the corresponding label provided in the metadata. If its filterMatchCriteria is set to MATCH_ALL, then all of its filterLabels must match with corresponding labels in the provided metadata. metadataFilters specified here can be overrides those specified in ForwardingRule that refers to this UrlMap. metadataFilters only applies to Loadbalancers that have their loadBalancingScheme set to INTERNAL_SELF_MANAGED. Structure is documented below.
Specifies a list of query parameter match criteria, all of which must match corresponding query parameters in the request. Structure is documented below.
In response to a matching matchRule, the load balancer performs advanced routing actions like URL rewrites, header transformations, etc. prior to forwarding the request to the selected backend. If routeAction specifies any weightedBackendServices, service must not be set. Conversely if service is set, routeAction cannot contain any weightedBackendServices. Only one of routeAction or urlRedirect must be set. Structure is documented below.
The specification for allowing client side cross-origin requests. Please see W3C Recommendation for Cross Origin Resource Sharing Structure is documented below.
Specifies the content for the Access-Control-Allow-Headers header.
Specifies the content for the Access-Control-Allow-Methods header.
Specifies the regular expression patterns that match allowed origins. For regular expression grammar please see en.cppreference.com/w/cpp/regex/ecmascript An origin is allowed if it matches either allow_origins or allow_origin_regex.
Specifies the list of origins that will be allowed to do CORS requests. An origin is allowed if it matches either allow_origins or allow_origin_regex.
Specifies the content for the Access-Control-Expose-Headers header.
The specification for fault injection introduced into traffic to test the resiliency of clients to backend service failure. As part of fault injection, when clients send requests to a backend service, delays can be introduced by Loadbalancer on a percentage of requests before sending those request to the backend service. Similarly requests from clients can be aborted by the Loadbalancer for a percentage of requests. timeout and retry_policy will be ignored by clients that are configured with a fault_injection_policy. Structure is documented below.
The specification for how client requests are aborted as part of fault injection. Structure is documented below.
The specification for how client requests are delayed as part of fault injection, before being sent to a backend service. Structure is documented below.
Specifies the policy on how requests intended for the route's backends are shadowed to a separate mirrored backend service. Loadbalancer does not wait for responses from the shadow service. Prior to sending traffic to the shadow service, the host / authority header is suffixed with -shadow. Structure is documented below.
Specifies the retry policy associated with this route. Structure is documented below.
Specifies one or more conditions when this retry rule applies. Valid values are:
Specifies the timeout for the selected route. Timeout is computed from the time the request is has been fully processed (i.e. end-of-stream) up until the response has been completely processed. Timeout includes all retries. If not specified, the default value is 15 seconds. Structure is documented below.
The spec to modify the URL of the request, prior to forwarding the request to the matched service Structure is documented below.
A list of weighted backend services to send traffic to when a route match occurs. The weights determine the fraction of traffic that flows to their corresponding backend service. If all traffic needs to go to a single backend service, there must be one weightedBackendService with weight set to a non 0 number. Once a backendService is identified and before forwarding the request to the backend service, advanced routing actions like Url rewrites and header transformations are applied depending on additional settings specified in this HttpRouteAction. Structure is documented below.
Specifies changes to request and response headers that need to take effect for the selected backendService. headerAction specified here take effect before headerAction in the enclosing HttpRouteRule, PathMatcher and UrlMap. Structure is documented below.
Headers to add to a matching request prior to forwarding the request to the backendService. Structure is documented below.
A list of header names for headers that need to be removed from the request prior to forwarding the request to the backendService.
Headers to add the response prior to sending the response back to the client. Structure is documented below.
A list of header names for headers that need to be removed from the response prior to sending the response back to the client.
When this rule is matched, the request is redirected to a URL specified by urlRedirect. If urlRedirect is specified, service or routeAction must not be set. Structure is documented below.
The list of expected URL mapping tests. Request to update this UrlMap will succeed only if all of the test cases pass. You can specify a maximum of 100 tests per UrlMap. Structure is documented below.
Conditions of the resource.
target-http-proxy
apiVersion: compute.gcp.upbound.io/v1beta1
kind: URLMap
metadata:
annotations:
meta.upbound.io/example-id: compute/v1beta1/targethttpproxy
labels:
testing.upbound.io/example-name: target-http-proxy
name: target-http-proxy
spec:
forProvider:
defaultServiceSelector:
matchLabels:
testing.upbound.io/example-name: target-http-proxy
hostRule:
- hosts:
- mysite.com
pathMatcher: allpaths
pathMatcher:
- defaultServiceSelector:
matchLabels:
testing.upbound.io/example-name: target-http-proxy
name: allpaths
pathRule:
- paths:
- /*
serviceSelector:
matchLabels:
testing.upbound.io/example-name: target-http-proxy
target-grpc-proxy
apiVersion: compute.gcp.upbound.io/v1beta1
kind: URLMap
metadata:
annotations:
meta.upbound.io/example-id: compute/v1beta1/targetgrpcproxy
labels:
testing.upbound.io/example-name: target-grpc-proxy
name: target-grpc-proxy
spec:
forProvider:
defaultServiceSelector:
matchLabels:
testing.upbound.io/example-name: target-grpc-proxy
description: a description
hostRule:
- hosts:
- mysite.com
pathMatcher: allpaths
pathMatcher:
- defaultServiceSelector:
matchLabels:
testing.upbound.io/example-name: target-grpc-proxy
name: allpaths
routeRules:
- headerAction:
- requestHeadersToAdd:
- headerName: AddSomethingElse
headerValue: MyOtherValue
replace: true
requestHeadersToRemove:
- RemoveMe2
responseHeadersToAdd:
- headerName: AddMe
headerValue: MyValue
replace: false
responseHeadersToRemove:
- RemoveMe3
matchRules:
- fullPathMatch: a full path
headerMatches:
- exactMatch: match this exactly
headerName: someheader
invertMatch: true
ignoreCase: true
metadataFilters:
- filterLabels:
- name: PLANET
value: MARS
filterMatchCriteria: MATCH_ANY
queryParameterMatches:
- name: a query parameter
presentMatch: true
priority: 1
urlRedirect:
- hostRedirect: A host
httpsRedirect: false
pathRedirect: some/path
redirectResponseCode: TEMPORARY_REDIRECT
stripQuery: true
test:
- host: hi.com
path: /home
serviceSelector:
matchLabels:
testing.upbound.io/example-name: target-grpc-proxy
urlmap
apiVersion: compute.gcp.upbound.io/v1beta1
kind: URLMap
metadata:
annotations:
meta.upbound.io/example-id: compute/v1beta1/urlmap
labels:
testing.upbound.io/example-name: urlmap
name: urlmap
spec:
forProvider:
defaultServiceSelector:
matchLabels:
testing.upbound.io/example-name: urlmap
description: a description
hostRule:
- hosts:
- mysite.com
pathMatcher: mysite
- hosts:
- myothersite.com
pathMatcher: otherpaths
pathMatcher:
- defaultServiceSelector:
matchLabels:
testing.upbound.io/example-name: urlmap
name: mysite
pathRule:
- paths:
- /home
serviceSelector:
matchLabels:
testing.upbound.io/example-name: urlmap
- paths:
- /login
serviceSelector:
matchLabels:
testing.upbound.io/example-name: urlmap
- paths:
- /static
serviceSelector:
matchLabels:
testing.upbound.io/example-name: urlmap
- defaultServiceSelector:
matchLabels:
testing.upbound.io/example-name: urlmap
name: otherpaths
test:
- host: hi.com
path: /home
serviceSelector:
matchLabels:
testing.upbound.io/example-name: urlmap
target-https-proxy
apiVersion: compute.gcp.upbound.io/v1beta1
kind: URLMap
metadata:
annotations:
meta.upbound.io/example-id: compute/v1beta1/targethttpsproxy
labels:
testing.upbound.io/example-name: target-https-proxy
name: target-https-proxy
spec:
forProvider:
defaultServiceSelector:
matchLabels:
testing.upbound.io/example-name: target-https-proxy
description: a description
hostRule:
- hosts:
- mysite.com
pathMatcher: allpaths
pathMatcher:
- defaultServiceSelector:
matchLabels:
testing.upbound.io/example-name: target-https-proxy
name: allpaths
pathRule:
- paths:
- /*
serviceSelector:
matchLabels:
testing.upbound.io/example-name: target-https-proxy