diff --git a/site-src/guides/getting-started/simple-gateway.md b/site-src/guides/getting-started/simple-gateway.md index 53445b901e..dcc46562b1 100644 --- a/site-src/guides/getting-started/simple-gateway.md +++ b/site-src/guides/getting-started/simple-gateway.md @@ -8,8 +8,8 @@ This guide is a great place to start if you are new to Gateway API. It shows the {% include 'standard/simple-gateway/gateway.yaml' %} ``` -The Gateway represents the instantiation of a logical load balancer and the -GatewayClass defines the load balancer template when users create a Gateway. +The [Gateway](../../../reference/spec/#gateway) represents the instantiation of a logical load balancer and the +[GatewayClass](../../../reference/spec/#gatewayclass) defines the load balancer template when users create a Gateway. The example Gateway is templated from a hypothetical `example` GatewayClass, which is meant to be a placeholder and substituted by users. Here is a list of available @@ -21,10 +21,10 @@ The Gateway listens for HTTP traffic on port 80. This particular GatewayClass automatically assigns an IP address which will be shown in the `Gateway.status` after it has been deployed. -Route resources specify the Gateways they want to attach to using `ParentRefs`. As long as +Route resources specify the Gateways they want to attach to using [`ParentRefs`](../../../reference/spec/#parentreference). As long as the Gateway allows this attachment (by default Routes from the same namespace are trusted), this will allow the Route to receive traffic from the parent Gateway. -`BackendRefs` define the backends that traffic will be sent to. More complex +[`BackendRefs`](../../../reference/spec/#httpbackendref) define the backends that traffic will be sent to. More complex bi-directional matching and permissions are possible and explained in other guides. The following HTTPRoute defines how traffic from the Gateway listener is routed diff --git a/site-src/guides/grpc-routing.md b/site-src/guides/grpc-routing.md index d65282a535..bf5874f469 100644 --- a/site-src/guides/grpc-routing.md +++ b/site-src/guides/grpc-routing.md @@ -1,7 +1,7 @@ # gRPC routing The [GRPCRoute resource](../api-types/grpcroute.md) allows you to match on gRPC traffic and -direct it to Kubernetes backends. This guide shows how the GRPCRoute matches +direct it to Kubernetes backends. This guide shows how the [GRPCRoute](../../reference/spec/#grpcroute) matches traffic on host, header, and service, and method fields and forwards it to different Kubernetes Services. @@ -74,6 +74,6 @@ been considered. {% include 'standard/grpc-routing/reflection-grpcroute.yaml' %} ``` -[gateway]: ../reference/spec.md#gateway -[spec]: ../reference/spec.md#grpcroutespec +[gateway]: ../../reference/spec/#gateway +[spec]: ../../reference/spec/#grpcroutespec [svc]:https://kubernetes.io/docs/concepts/services-networking/service/ diff --git a/site-src/guides/http-cors.md b/site-src/guides/http-cors.md index 3ca7078310..c5da1ab264 100644 --- a/site-src/guides/http-cors.md +++ b/site-src/guides/http-cors.md @@ -8,7 +8,7 @@ Cross-Origin Resource Sharing (CORS). CORS is a security feature that allows or denies web applications running at one domain to make requests for resources from a different domain. -The `CORS` filter in an `HTTPRouteRule` can be used to specify the CORS policy. +The [`CORS` filter](../../reference/spec/#httpcorsfilter) in an `HTTPRouteRule` can be used to specify the CORS policy. ## Allowing requests from a specific origin diff --git a/site-src/guides/http-header-modifier.md b/site-src/guides/http-header-modifier.md index 170da1832f..7b66561a9e 100644 --- a/site-src/guides/http-header-modifier.md +++ b/site-src/guides/http-header-modifier.md @@ -1,7 +1,7 @@ # HTTP Header Modifiers [HTTPRoute resources](../api-types/httproute.md) can modify the headers of HTTP requests and the HTTP responses from clients. -There are two types of [filters](../api-types/httproute.md#filters-optional) available to meet these requirements: `RequestHeaderModifier` and `ResponseHeaderModifier`. +There are two types of [filters](../api-types/httproute.md#filters-optional) available to meet these requirements: [`RequestHeaderModifier`](../../reference/spec/#httpheaderfilter) and [`ResponseHeaderModifier`](../../reference/spec/#httpheaderfilter). This guide shows how to use these features. diff --git a/site-src/guides/http-method-matching.md b/site-src/guides/http-method-matching.md index 17391c7ec4..6dd17b879e 100644 --- a/site-src/guides/http-method-matching.md +++ b/site-src/guides/http-method-matching.md @@ -4,7 +4,7 @@ This feature is part of extended support. For more information on release channels, refer to our [versioning guide](../concepts/versioning.md). The [HTTPRoute resource](../api-types/httproute.md) can be used to match -requests based on the HTTP method. This guide shows how to use this +requests based on the [HTTP method](../../reference/spec/#httproutematch). This guide shows how to use this functionality. ## Matching requests based on the HTTP method diff --git a/site-src/guides/http-query-param-matching.md b/site-src/guides/http-query-param-matching.md index faa3cef6aa..9d6c718e1d 100644 --- a/site-src/guides/http-query-param-matching.md +++ b/site-src/guides/http-query-param-matching.md @@ -4,7 +4,7 @@ This feature is part of extended support. For more information on release channels, refer to our [versioning guide](../concepts/versioning.md). The [HTTPRoute resource](../api-types/httproute.md) can be used to match -requests based on query parameters. This guide shows how to use this +requests based on [query parameters](../../reference/spec/#httpqueryparammatch). This guide shows how to use this functionality. ## Matching requests based on a single query parameter diff --git a/site-src/guides/http-request-mirroring.md b/site-src/guides/http-request-mirroring.md index ebc0e1bd21..0779f1b8f4 100644 --- a/site-src/guides/http-request-mirroring.md +++ b/site-src/guides/http-request-mirroring.md @@ -3,8 +3,7 @@ ???+ info "Extended Support Feature: HTTPRouteRequestMirror" This feature is part of extended support. For more information on release channels, refer to our [versioning guide](../concepts/versioning.md). -The [HTTPRoute resource](../api-types/httproute.md) can be used to mirror -requests to multiple backends. This is useful for testing new services with +The [HTTPRoute resource](../api-types/httproute.md) can be used to [mirror requests](../../reference/spec/#httprequestmirrorfilter) to multiple backends. This is useful for testing new services with production traffic. Mirrored requests will only be sent to one single destination endpoint diff --git a/site-src/guides/http-routing.md b/site-src/guides/http-routing.md index 4c95e8d377..0230800beb 100644 --- a/site-src/guides/http-routing.md +++ b/site-src/guides/http-routing.md @@ -57,6 +57,6 @@ missing or not `canary` then it'll be forwarded to `bar-svc`. {% include 'standard/http-routing/bar-httproute.yaml' %} ``` -[gateway]: ../reference/spec.md#gateway -[spec]: ../reference/spec.md#httproutespec +[gateway]: ../../reference/spec/#gateway +[spec]: ../../reference/spec/#httproutespec [svc]:https://kubernetes.io/docs/concepts/services-networking/service/ diff --git a/site-src/guides/http-timeouts.md b/site-src/guides/http-timeouts.md index 973bf66f3b..93bb96daf3 100644 --- a/site-src/guides/http-timeouts.md +++ b/site-src/guides/http-timeouts.md @@ -4,7 +4,7 @@ This feature is part of extended support. For more information on release channels, refer to our [versioning guide](../concepts/versioning.md). The [HTTPRoute resource](../api-types/httproute.md) can be used to configure -timeouts for HTTP requests. This is useful for preventing long-running requests +[timeouts](../../reference/spec/#httproutetimeouts) for HTTP requests. This is useful for preventing long-running requests from consuming resources and for providing a better user experience. The `timeouts` field in an `HTTPRouteRule` can be used to specify a request diff --git a/site-src/guides/tls.md b/site-src/guides/tls.md index fc43c4835f..8ab02a56f1 100644 --- a/site-src/guides/tls.md +++ b/site-src/guides/tls.md @@ -54,11 +54,11 @@ The use of `Terminate` on `TLSRoute` is available on `Extended` [Support Level]. ## Downstream TLS -Downstream TLS settings are configured using listeners at the Gateway level. +Downstream TLS settings are configured using [listeners](../../reference/spec/#listener) at the Gateway level. ### Listeners and TLS -Listeners expose the TLS setting on a per domain or subdomain basis. +Listeners expose the [TLS setting](../../reference/spec/#gatewaytlsconfig) on a per domain or subdomain basis. TLS settings of a listener are applied to all domains that satisfy the `hostname` criteria. @@ -116,7 +116,7 @@ would be invalid. ## Upstream TLS -Upstream TLS settings are configured using the `BackendTLSPolicy` attached to a +Upstream TLS settings are configured using the [`BackendTLSPolicy`](../../reference/spec/#backendtlspolicy) attached to a `Service` via a target reference. This resource can be used to describe the SNI the Gateway should use to connect to the diff --git a/site-src/guides/traffic-splitting.md b/site-src/guides/traffic-splitting.md index 9dccbd744a..9d4d1f6a1f 100644 --- a/site-src/guides/traffic-splitting.md +++ b/site-src/guides/traffic-splitting.md @@ -1,7 +1,7 @@ # HTTP traffic splitting The [HTTPRoute resource](../api-types/httproute.md) allows you to specify -weights to shift traffic between different backends. This is useful for +[weights](../../reference/spec/#httpbackendref) to shift traffic between different backends. This is useful for splitting traffic during rollouts, canarying changes, or for emergencies. The HTTPRoute`spec.rules.backendRefs` accepts a list of backends that a route rule will send traffic to. The relative weights of these backends define @@ -41,7 +41,7 @@ production user traffic for `foo.example.com`. The following HTTPRoute has no receive 100% of the traffic matched by each of their route rules. A canary route rule is used (matching the header `traffic=test`) to send synthetic test traffic before splitting any production user traffic to `foo-v2`. -[Routing precedence](../reference/spec.md#httprouterule) +[Routing precedence](../../reference/spec/#httprouterule) ensures that all traffic with the matching host and header (the most specific match) will be sent to `foo-v2`.