RegionURLMap is the Schema for the RegionURLMaps 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
apiVersion: compute.gcp.upbound.io/v1beta1
kind: RegionURLMap
RegionURLMapSpec defines the desired state of RegionURLMap
No description provided.
defaultRouteAction takes effect when none of the hostRules match. The load balancer performs advanced routing actions, such as URL rewrites and header transformations, before 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. URL maps for Classic external HTTP(S) load balancers only support the urlRewrite action within defaultRouteAction. defaultRouteAction has no effect when the URL map is bound to a target gRPC proxy that has the validateForProxyless field set to true. 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 a load balancer on a percentage of requests before sending those requests to the backend service. Similarly requests from clients can be aborted by the load balancer for a percentage of requests. timeout and retryPolicy is ignored by clients that are configured with a faultInjectionPolicy if: 1. The traffic is generated by fault injection AND 2. The fault injection is not a delay fault injection. Fault injection is not supported with the global external HTTP(S) load balancer (classic). To see which load balancers support fault injection, see Load balancing: Routing and traffic management features. 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. The load balancer does not wait for responses from the shadow service. Before sending traffic to the shadow service, the host / authority header is suffixed with -shadow. Not supported when the URL map is bound to a target gRPC proxy that has the validateForProxyless field set to true. Structure is documented below.
Reference to a RegionBackendService in compute to populate backendService.
Policies for referencing.
Selector for a RegionBackendService 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 has been fully processed (known as end-of-stream) up until the response has been processed. Timeout includes all retries. If not specified, this field uses the largest timeout among all backend services associated with the route. Not supported when the URL map is bound to a target gRPC proxy that has validateForProxyless field set to true. Structure is documented below.
The spec to modify the URL of the request, before forwarding the request to the matched service. urlRewrite is the only action supported in UrlMaps for external HTTP(S) load balancers. Not supported when the URL map is bound to a target gRPC proxy that has the validateForProxyless field set to true. 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-zero number. After a backend service is identified and before forwarding the request to the backend service, advanced routing actions such as URL rewrites and header transformations are applied depending on additional settings specified in this HttpRouteAction. Structure is documented below.
Reference to a RegionBackendService in compute to populate backendService.
Policies for referencing.
Selector for a RegionBackendService 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 RegionBackendService in compute to populate defaultService.
Policies for referencing.
Selector for a RegionBackendService 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.
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.
Reference to a RegionBackendService in compute to populate defaultService.
Policies for referencing.
Selector for a RegionBackendService 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.
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
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 RegionBackendService in compute to populate backendService.
Policies for referencing.
Selector for a RegionBackendService 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 RegionBackendService in compute to populate backendService.
Policies for referencing.
Selector for a RegionBackendService 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 RegionBackendService in compute to populate service.
Policies for referencing.
Selector for a RegionBackendService 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]
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 RegionBackendService in compute to populate service.
Policies for referencing.
Selector for a RegionBackendService 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 mappings. Requests to update this UrlMap will succeed only if all of the test cases pass. Structure is documented below.
Reference to a RegionBackendService in compute to populate service.
Policies for referencing.
Selector for a RegionBackendService in compute to populate service.
Policies for selection.
THIS IS A BETA FIELD. It will be honored unless the Management Policies feature flag is disabled. 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, such as URL rewrites and header transformations, before 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. URL maps for Classic external HTTP(S) load balancers only support the urlRewrite action within defaultRouteAction. defaultRouteAction has no effect when the URL map is bound to a target gRPC proxy that has the validateForProxyless field set to true. 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 a load balancer on a percentage of requests before sending those requests to the backend service. Similarly requests from clients can be aborted by the load balancer for a percentage of requests. timeout and retryPolicy is ignored by clients that are configured with a faultInjectionPolicy if: 1. The traffic is generated by fault injection AND 2. The fault injection is not a delay fault injection. Fault injection is not supported with the global external HTTP(S) load balancer (classic). To see which load balancers support fault injection, see Load balancing: Routing and traffic management features. 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. The load balancer does not wait for responses from the shadow service. Before sending traffic to the shadow service, the host / authority header is suffixed with -shadow. Not supported when the URL map is bound to a target gRPC proxy that has the validateForProxyless field set to true. Structure is documented below.
Reference to a RegionBackendService in compute to populate backendService.
Policies for referencing.
Selector for a RegionBackendService 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 has been fully processed (known as end-of-stream) up until the response has been processed. Timeout includes all retries. If not specified, this field uses the largest timeout among all backend services associated with the route. Not supported when the URL map is bound to a target gRPC proxy that has validateForProxyless field set to true. Structure is documented below.
The spec to modify the URL of the request, before forwarding the request to the matched service. urlRewrite is the only action supported in UrlMaps for external HTTP(S) load balancers. Not supported when the URL map is bound to a target gRPC proxy that has the validateForProxyless field set to true. 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-zero number. After a backend service is identified and before forwarding the request to the backend service, advanced routing actions such as URL rewrites and header transformations are applied depending on additional settings specified in this HttpRouteAction. Structure is documented below.
Reference to a RegionBackendService in compute to populate backendService.
Policies for referencing.
Selector for a RegionBackendService 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 RegionBackendService in compute to populate defaultService.
Policies for referencing.
Selector for a RegionBackendService 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.
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.
Reference to a RegionBackendService in compute to populate defaultService.
Policies for referencing.
Selector for a RegionBackendService 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.
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
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 RegionBackendService in compute to populate backendService.
Policies for referencing.
Selector for a RegionBackendService 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 RegionBackendService in compute to populate backendService.
Policies for referencing.
Selector for a RegionBackendService 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 RegionBackendService in compute to populate service.
Policies for referencing.
Selector for a RegionBackendService 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]
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 RegionBackendService in compute to populate service.
Policies for referencing.
Selector for a RegionBackendService 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 mappings. Requests to update this UrlMap will succeed only if all of the test cases pass. Structure is documented below.
Reference to a RegionBackendService in compute to populate service.
Policies for referencing.
Selector for a RegionBackendService in compute to populate service.
Policies for selection.
THIS IS A BETA FIELD. It is on by default but can be opted out through a Crossplane feature flag. 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.
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.
RegionURLMapStatus defines the observed state of RegionURLMap.
No description provided.
defaultRouteAction takes effect when none of the hostRules match. The load balancer performs advanced routing actions, such as URL rewrites and header transformations, before 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. URL maps for Classic external HTTP(S) load balancers only support the urlRewrite action within defaultRouteAction. defaultRouteAction has no effect when the URL map is bound to a target gRPC proxy that has the validateForProxyless field set to true. 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 a load balancer on a percentage of requests before sending those requests to the backend service. Similarly requests from clients can be aborted by the load balancer for a percentage of requests. timeout and retryPolicy is ignored by clients that are configured with a faultInjectionPolicy if: 1. The traffic is generated by fault injection AND 2. The fault injection is not a delay fault injection. Fault injection is not supported with the global external HTTP(S) load balancer (classic). To see which load balancers support fault injection, see Load balancing: Routing and traffic management features. 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. The load balancer does not wait for responses from the shadow service. Before sending traffic to the shadow service, the host / authority header is suffixed with -shadow. Not supported when the URL map is bound to a target gRPC proxy that has the validateForProxyless field set to true. 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 (known as end-of-stream) up until the response has been processed. Timeout includes all retries. If not specified, this field uses the largest timeout among all backend services associated with the route. Not supported when the URL map is bound to a target gRPC proxy that has validateForProxyless field set to true. Structure is documented below.
The spec to modify the URL of the request, before forwarding the request to the matched service. urlRewrite is the only action supported in UrlMaps for external HTTP(S) load balancers. Not supported when the URL map is bound to a target gRPC proxy that has the validateForProxyless field set to true. 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-zero number. After a backend service is identified and before forwarding the request to the backend service, advanced routing actions such as 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.
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.
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.
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
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]
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 mappings. Requests to update this UrlMap will succeed only if all of the test cases pass. Structure is documented below.
Conditions of the resource.
region-url-map
apiVersion: compute.gcp.upbound.io/v1beta1
kind: RegionURLMap
metadata:
annotations:
meta.upbound.io/example-id: compute/v1beta1/regionurlmap
labels:
testing.upbound.io/example-name: region-url-map
name: region-url-map
spec:
forProvider:
defaultServiceSelector:
matchLabels:
testing.upbound.io/example-name: region-url-map-home
description: a description
hostRule:
- hosts:
- mysite.com
pathMatcher: allpaths
pathMatcher:
- defaultServiceSelector:
matchLabels:
testing.upbound.io/example-name: region-url-map-home
name: allpaths
pathRule:
- paths:
- /home
serviceSelector:
matchLabels:
testing.upbound.io/example-name: region-url-map-home
- paths:
- /login
serviceSelector:
matchLabels:
testing.upbound.io/example-name: region-url-map-login
region: us-central1
test:
- host: hi.com
path: /home
serviceSelector:
matchLabels:
testing.upbound.io/example-name: region-url-map-home
region-target-https-proxy
apiVersion: compute.gcp.upbound.io/v1beta1
kind: RegionURLMap
metadata:
annotations:
meta.upbound.io/example-id: compute/v1beta1/regiontargethttpproxy
labels:
testing.upbound.io/example-name: region-target-https-proxy
name: region-target-https-proxy
spec:
forProvider:
defaultServiceSelector:
matchLabels:
testing.upbound.io/example-name: region-target-https-proxy
description: a description
hostRule:
- hosts:
- mysite.com
pathMatcher: allpaths
pathMatcher:
- defaultServiceSelector:
matchLabels:
testing.upbound.io/example-name: region-target-https-proxy
name: allpaths
pathRule:
- paths:
- /*
serviceSelector:
matchLabels:
testing.upbound.io/example-name: region-target-https-proxy
region: us-central1
forwarding-rule
apiVersion: compute.gcp.upbound.io/v1beta1
kind: RegionURLMap
metadata:
annotations:
meta.upbound.io/example-id: compute/v1beta1/forwardingrule
labels:
testing.upbound.io/example-name: forwarding-rule
name: forwarding-rule
spec:
forProvider:
defaultServiceSelector:
matchLabels:
testing.upbound.io/example-name: forwarding-rule
region: us-central1
region-target-http-proxy
apiVersion: compute.gcp.upbound.io/v1beta1
kind: RegionURLMap
metadata:
annotations:
meta.upbound.io/example-id: compute/v1beta1/regiontargethttpproxy
labels:
testing.upbound.io/example-name: region-target-http-proxy
name: region-target-http-proxy
spec:
forProvider:
defaultServiceSelector:
matchLabels:
testing.upbound.io/example-name: region-target-http-proxy
hostRule:
- hosts:
- mysite.com
pathMatcher: allpaths
pathMatcher:
- defaultServiceSelector:
matchLabels:
testing.upbound.io/example-name: region-target-http-proxy
name: allpaths
pathRule:
- paths:
- /*
serviceSelector:
matchLabels:
testing.upbound.io/example-name: region-target-http-proxy
region: us-central1
© 2022 Upbound, Inc.
Discover the building blocksfor your internal cloud platform.