From 072cf3ac02621c5e3babc3366da35a942a1373ec Mon Sep 17 00:00:00 2001 From: Frank Budinsky Date: Fri, 16 Feb 2024 10:54:08 -0500 Subject: [PATCH] Fix broken doc links --- geps/gep-1426/index.md | 8 ++++---- site-src/api-types/backendtlspolicy.md | 2 +- site-src/api-types/gatewayclass.md | 2 +- site-src/api-types/grpcroute.md | 4 ++-- site-src/api-types/httproute.md | 14 +++++++------- site-src/guides/grpc-routing.md | 2 +- site-src/guides/http-redirect-rewrite.md | 4 ++-- site-src/guides/http-routing.md | 4 ++-- site-src/guides/migrating-from-ingress.md | 22 +++++++++++----------- site-src/guides/multiple-ns.md | 2 +- site-src/guides/traffic-splitting.md | 2 +- 11 files changed, 33 insertions(+), 33 deletions(-) diff --git a/geps/gep-1426/index.md b/geps/gep-1426/index.md index 0f340807a2..277476202d 100644 --- a/geps/gep-1426/index.md +++ b/geps/gep-1426/index.md @@ -240,7 +240,7 @@ A controller could create a matching selector-less `Service` (i.e. no endpoints) Ownership/trust would remain based on naming pattern: `serviceName.namespace.svc.[USER_DOMAIN]` -Separate `HttpService`, `TlsService` and `TcpService` resources could have the benefit of allowing us to define protocol specific elements to the spec along with an embedded `CommonServiceSpec`, similar to [`CommonRouteSpec`](https://gateway-api.sigs.k8s.io/v1alpha2/reference/spec/#gateway.networking.k8s.io/v1beta1.CommonRouteSpec), and keep similar patterns as `Service`. +Separate `HttpService`, `TlsService` and `TcpService` resources could have the benefit of allowing us to define protocol specific elements to the spec along with an embedded `CommonServiceSpec`, similar to [`CommonRouteSpec`](https://gateway-api.sigs.k8s.io/v1alpha2/reference/spec/#gateway.networking.k8s.io/v1.CommonRouteSpec), and keep similar patterns as `Service`. ##### Drawbacks @@ -298,7 +298,7 @@ spec: name: cool-mesh ``` -It is currently undefined how this approach may interact with either explicitly configured [`hostnames`](https://gateway-api.sigs.k8s.io/v1alpha2/reference/spec/#gateway.networking.k8s.io/v1beta1.HTTPRouteSpec) or implicit "transparent proxy" routing for Kubernetes `Services` to determine how traffic should be intercepted and redirected. +It is currently undefined how this approach may interact with either explicitly configured [`hostnames`](https://gateway-api.sigs.k8s.io/v1alpha2/reference/spec/#gateway.networking.k8s.io/v1.HTTPRouteSpec) or implicit "transparent proxy" routing for Kubernetes `Services` to determine how traffic should be intercepted and redirected. This approach is not entirely abandoned, as it could supplement the proposed approach if explicit attachment to a specific mesh is deemed necessary. Additionally, this approach may offer a future option for attaching an `HTTPRoute` to a mesh, but not a specific service (e.g. to implement mesh-wide egress functionality for all requests to a specific hostname). @@ -319,7 +319,7 @@ spec: * Would require separate `HTTPRoute` resources to explicitly define _different_ traffic routing rules for the same service on different meshes. -#### Nested `services` and `hostnames` fields in [`ParentReference`](https://gateway-api.sigs.k8s.io/v1alpha2/reference/spec/#gateway.networking.k8s.io/v1beta1.ParentReference) +#### Nested `services` and `hostnames` fields in [`ParentReference`](https://gateway-api.sigs.k8s.io/v1alpha2/reference/spec/#gateway.networking.k8s.io/v1.ParentReference) In core conformance, the `services` would only be valid for `Mesh` types, and `hostnames` field only for `Gateway`. Mesh implementations could still use a `Host` header match if they wanted limit rules to specific hostnames. @@ -359,7 +359,7 @@ This is done by configuring the `parentRef`, to point to the `istio` `Mesh`. Thi ### New field on `HTTPRoute` for `Service` binding -A new field `serviceBinding` would be added to `HTTPRoute` to attach to the `Service`. Alternatively, this could be a new field in [`HTTPRouteMatch`](https://gateway-api.sigs.k8s.io/v1alpha2/reference/spec/#gateway.networking.k8s.io/v1beta1.HTTPRouteMatch). As with the proposed implementation, this approach could be combined with a `Mesh` resource or similar as the `parentRef`, which would just define that the route would be applied to a mesh. +A new field `serviceBinding` would be added to `HTTPRoute` to attach to the `Service`. Alternatively, this could be a new field in [`HTTPRouteMatch`](https://gateway-api.sigs.k8s.io/v1alpha2/reference/spec/#gateway.networking.k8s.io/v1.HTTPRouteMatch). As with the proposed implementation, this approach could be combined with a `Mesh` resource or similar as the `parentRef`, which would just define that the route would be applied to a mesh. ``` spec: diff --git a/site-src/api-types/backendtlspolicy.md b/site-src/api-types/backendtlspolicy.md index 6c1d9ac082..2de89b9f3b 100644 --- a/site-src/api-types/backendtlspolicy.md +++ b/site-src/api-types/backendtlspolicy.md @@ -140,5 +140,5 @@ uses `PolicyAncestorStatus` to allow you to know which parentReference set that [tls]: /references/spec/#gateway.networking.k8s.io/v1alpha2.BackendTLSPolicy.TLS [caCertRefs]: /references/spec/#gateway.networking.k8s.io/v1alpha2.BackendTLSPolicyConfig.CACertRefs [wellKnownCACerts]: /references/spec/#gateway.networking.k8s.io/v1alpha2.BackendTLSPolicyConfig.WellKnownCACerts -[hostname]: /references/spec/#gateway.networking.k8s.io/v1beta1.PreciseHostname +[hostname]: /references/spec/#gateway.networking.k8s.io/v1.PreciseHostname [targetRef]: /references/spec/#gateway.networking.k8s.io/v1alpha2.PolicyTargetReference diff --git a/site-src/api-types/gatewayclass.md b/site-src/api-types/gatewayclass.md index 4fa585bf02..d30368b072 100644 --- a/site-src/api-types/gatewayclass.md +++ b/site-src/api-types/gatewayclass.md @@ -139,5 +139,5 @@ example.net/gateway/v2.1 // Use version 2.1 example.net/gateway // Use the default version ``` -[gatewayclass]: /reference/spec/#gateway.networking.k8s.io/v1beta1.GatewayClass +[gatewayclass]: /reference/spec/#gateway.networking.k8s.io/v1.GatewayClass [ingress-class-api]: https://kubernetes.io/docs/concepts/services-networking/ingress/#ingress-class diff --git a/site-src/api-types/grpcroute.md b/site-src/api-types/grpcroute.md index bbe66740f1..1cb81da0e2 100644 --- a/site-src/api-types/grpcroute.md +++ b/site-src/api-types/grpcroute.md @@ -260,10 +260,10 @@ resolution applies to merging, refer to the [API specification][grpcrouterule]. [grpcroute]: /reference/spec/#gateway.networking.k8s.io/v1alpha2.GRPCPRoute [grpcrouterule]: /reference/spec/#gateway.networking.k8s.io/v1alpha2.GRPCRouteRule -[hostname]: /reference/spec/#gateway.networking.k8s.io/v1beta1.Hostname +[hostname]: /reference/spec/#gateway.networking.k8s.io/v1.Hostname [rfc-3986]: https://tools.ietf.org/html/rfc3986 [matches]: /reference/spec/#gateway.networking.k8s.io/v1alpha2.GRPCRouteMatch [filters]: /reference/spec/#gateway.networking.k8s.io/v1alpha2.GRPCRouteFilter [backendRef]: /reference/spec/#gateway.networking.k8s.io/v1alpha2.GRPCBackendRef -[parentRef]: /reference/spec/#gateway.networking.k8s.io/v1beta1.ParentRef +[parentRef]: /reference/spec/#gateway.networking.k8s.io/v1.ParentRef diff --git a/site-src/api-types/httproute.md b/site-src/api-types/httproute.md index 6b04c431e1..8de0ebd9b5 100644 --- a/site-src/api-types/httproute.md +++ b/site-src/api-types/httproute.md @@ -302,13 +302,13 @@ only one Route rule may match each request. For more information on how conflict resolution applies to merging, refer to the [API specification][httprouterule]. -[httproute]: /reference/spec/#gateway.networking.k8s.io/v1beta1.HTTPRoute -[httprouterule]: /reference/spec/#gateway.networking.k8s.io/v1beta1.HTTPRouteRule -[hostname]: /reference/spec/#gateway.networking.k8s.io/v1beta1.Hostname +[httproute]: /reference/spec/#gateway.networking.k8s.io/v1.HTTPRoute +[httprouterule]: /reference/spec/#gateway.networking.k8s.io/v1.HTTPRouteRule +[hostname]: /reference/spec/#gateway.networking.k8s.io/v1.Hostname [rfc-3986]: https://tools.ietf.org/html/rfc3986 -[matches]: /reference/spec/#gateway.networking.k8s.io/v1beta1.HTTPRouteMatch -[filters]: /reference/spec/#gateway.networking.k8s.io/v1beta1.HTTPRouteFilter -[backendRef]: /reference/spec/#gateway.networking.k8s.io/v1beta1.HTTPBackendRef -[parentRef]: /reference/spec/#gateway.networking.k8s.io/v1beta1.ParentRef +[matches]: /reference/spec/#gateway.networking.k8s.io/v1.HTTPRouteMatch +[filters]: /reference/spec/#gateway.networking.k8s.io/v1.HTTPRouteFilter +[backendRef]: /reference/spec/#gateway.networking.k8s.io/v1.HTTPBackendRef +[parentRef]: /reference/spec/#gateway.networking.k8s.io/v1.ParentRef [timeouts]: /reference/spec/#gateway.networking.k8s.io/v1.HTTPRouteTimeouts [appProtocol]: https://kubernetes.io/docs/concepts/services-networking/service/#application-protocol diff --git a/site-src/guides/grpc-routing.md b/site-src/guides/grpc-routing.md index ac1b063f7b..4ed7992dd5 100644 --- a/site-src/guides/grpc-routing.md +++ b/site-src/guides/grpc-routing.md @@ -80,6 +80,6 @@ been considered. {% include 'experimental/v1alpha2/grpc-routing/reflection-grpcroute.yaml' %} ``` -[gateway]: /reference/spec/#gateway.networking.k8s.io/v1beta1.Gateway +[gateway]: /reference/spec/#gateway.networking.k8s.io/v1.Gateway [spec]: /reference/spec/#gateway.networking.k8s.io%2fv1alpha2.GRPCRouteSpec [svc]:https://kubernetes.io/docs/concepts/services-networking/service/ diff --git a/site-src/guides/http-redirect-rewrite.md b/site-src/guides/http-redirect-rewrite.md index 69fa044406..3872e06cb7 100644 --- a/site-src/guides/http-redirect-rewrite.md +++ b/site-src/guides/http-redirect-rewrite.md @@ -12,7 +12,7 @@ use both filter types at once. Redirects return HTTP 3XX responses to a client, instructing it to retrieve a different resource. [`RequestRedirect` rule -filters](/reference/spec/#gateway.networking.k8s.io/v1beta1.HTTPRequestRedirectFilter) +filters](/reference/spec/#gateway.networking.k8s.io/v1.HTTPRequestRedirectFilter) instruct Gateways to emit a redirect response to requests matching a filtered HTTPRoute rule. @@ -87,7 +87,7 @@ https://redirect.example/paprika/teaspoon` response headers. Rewrites modify components of a client request before proxying it upstream. A [`URLRewrite` -filter](/reference/spec/#gateway.networking.k8s.io/v1beta1.HTTPURLRewriteFilter) +filter](/reference/spec/#gateway.networking.k8s.io/v1.HTTPURLRewriteFilter) can change the upstream request hostname and/or path. For example, the following HTTPRoute will accept a request for `https://rewrite.example/cardamom` and send it upstream to `example-svc` with diff --git a/site-src/guides/http-routing.md b/site-src/guides/http-routing.md index 0a2533f01e..2f5331a963 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/#gateway.networking.k8s.io/v1beta1.Gateway -[spec]: /reference/spec/#gateway.networking.k8s.io/v1beta1.HTTPRouteSpec +[gateway]: /reference/spec/#gateway.networking.k8s.io/v1.Gateway +[spec]: /reference/spec/#gateway.networking.k8s.io/v1.HTTPRouteSpec [svc]:https://kubernetes.io/docs/concepts/services-networking/service/ diff --git a/site-src/guides/migrating-from-ingress.md b/site-src/guides/migrating-from-ingress.md index 71aecbda40..94f207726e 100644 --- a/site-src/guides/migrating-from-ingress.md +++ b/site-src/guides/migrating-from-ingress.md @@ -147,12 +147,12 @@ Gateway API has the following primary extension points: * *External references.* A feature (field) of a Gateway API resource can reference a custom resource specific to the Gateway implementation that configures that feature. For example: - * [HTTPRouteFilter](/reference/spec/#gateway.networking.k8s.io/v1beta1.HTTPRouteFilter) + * [HTTPRouteFilter](/reference/spec/#gateway.networking.k8s.io/v1.HTTPRouteFilter) can reference an external resource via the `extensionRef` field, thus configuring an implementation-specific filter. - * [BackendObjectReference](/reference/spec/#gateway.networking.k8s.io/v1beta1.BackendObjectReference) + * [BackendObjectReference](/reference/spec/#gateway.networking.k8s.io/v1.BackendObjectReference) supports resources other than Services. - * [SecretObjectReference](/reference/spec/#gateway.networking.k8s.io/v1beta1.SecretObjectReference) + * [SecretObjectReference](/reference/spec/#gateway.networking.k8s.io/v1.SecretObjectReference) supports resources other than Secrets. * *Custom implementations*. For some features, it is left up to an implementation to define how to support them. Those features correspond to the @@ -160,7 +160,7 @@ Gateway API has the following primary extension points: (custom) [conformance level](/concepts/conformance/#2-support-levels). For example: * The `RegularExpression` type of - the [HTTPPathMatch](/reference/spec/#gateway.networking.k8s.io/v1beta1.HTTPPathMatch). + the [HTTPPathMatch](/reference/spec/#gateway.networking.k8s.io/v1.HTTPPathMatch). * *Policies.* A Gateway implementation can define custom resources called Policies for exposing data plane features like authentication. Gateway API does not prescribe the details of those resources. However, it prescribes a @@ -194,7 +194,7 @@ resource will get dedicated entry points. In Gateway API, entry points must be explicitly defined in a [Gateway](/api-types/gateway/) resource. For example, if you want the data plane to handle HTTP traffic on port 80, you need to define -a [listener](/reference/spec/#gateway.networking.k8s.io/v1beta1.Listener) for +a [listener](/reference/spec/#gateway.networking.k8s.io/v1.Listener) for that traffic. Typically, a Gateway implementation provides a dedicated data plane for each Gateway resource. @@ -207,7 +207,7 @@ the [TLS section](https://kubernetes.io/docs/concepts/services-networking/ingres where the TLS certificate and key are stored in a Secret. In Gateway API, TLS termination is a property of -the [Gateway listener](/reference/spec/#gateway.networking.k8s.io/v1beta1.Listener), +the [Gateway listener](/reference/spec/#gateway.networking.k8s.io/v1.Listener), and similarly to the Ingress, a TLS certificate and key are also stored in a Secret. @@ -218,21 +218,21 @@ application admin own TLS termination. The [path-based routing rules](https://kubernetes.io/docs/concepts/services-networking/ingress/#path-types) of the Ingress resource map directly to -the [routing rules](/reference/spec/#gateway.networking.k8s.io/v1beta1.HTTPRouteRule) +the [routing rules](/reference/spec/#gateway.networking.k8s.io/v1.HTTPRouteRule) of the [HTTPRoute](/api-types/httproute/). The [host-header-based routing rules](https://kubernetes.io/docs/concepts/services-networking/ingress/#name-based-virtual-hosting) map to -the [hostnames](/reference/spec/#gateway.networking.k8s.io/v1beta1.Hostname) of +the [hostnames](/reference/spec/#gateway.networking.k8s.io/v1.Hostname) of the HTTPRoute. However, note that in the Ingress, each hostname has separate routing rules, while in the HTTPRoute the routing rules apply to all hostnames. > The Ingress API uses the term host while Gateway API uses the hostname. > This guide will use Gateway API term to refer to the Ingress host. -> The `hostnames` of an HTTPRoute must match the `hostname` of the [Gateway listener](/reference/spec/#gateway.networking.k8s.io/v1beta1.Listener). +> The `hostnames` of an HTTPRoute must match the `hostname` of the [Gateway listener](/reference/spec/#gateway.networking.k8s.io/v1.Listener). > Otherwise, the listener will ignore the routing rules for the unmatched -> hostnames. See the [HTTPRoute documentation](/reference/spec/#gateway.networking.k8s.io/v1beta1.HTTPRouteSpec). +> hostnames. See the [HTTPRoute documentation](/reference/spec/#gateway.networking.k8s.io/v1.HTTPRouteSpec). HTTPRoutes are owned by the application developer. @@ -270,7 +270,7 @@ An Ingress resource must specify a [class](https://kubernetes.io/docs/concepts/services-networking/ingress/#ingress-class) to select which Ingress controller to use. An HTTPRoute must specify which Gateway (or Gateways) to attach to via -a [parentRef](/reference/spec/#gateway.networking.k8s.io/v1beta1.ParentRef). +a [parentRef](/reference/spec/#gateway.networking.k8s.io/v1.ParentRef). ### Implementation-Specific Ingress Features (Annotations) diff --git a/site-src/guides/multiple-ns.md b/site-src/guides/multiple-ns.md index 7f52d56981..1bb521760f 100644 --- a/site-src/guides/multiple-ns.md +++ b/site-src/guides/multiple-ns.md @@ -155,7 +155,7 @@ Gateway that these Routes want to attach to. After these three Routes are deployed, they will all be attached to the `shared-gateway` Gateway. The Gateway merges these Routes into a single flat -list of routing rules. [Routing precedence](/reference/spec/#gateway.networking.k8s.io/v1beta1.HTTPRouteRule) +list of routing rules. [Routing precedence](/reference/spec/#gateway.networking.k8s.io/v1.HTTPRouteRule) between these routing rules is determined by most specific match and conflicts are handled according to [conflict resolution](/concepts/guidelines#conflicts). This provides predictable and diff --git a/site-src/guides/traffic-splitting.md b/site-src/guides/traffic-splitting.md index ac97c5adf5..e55183d3cf 100644 --- a/site-src/guides/traffic-splitting.md +++ b/site-src/guides/traffic-splitting.md @@ -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/#gateway.networking.k8s.io/v1beta1.HTTPRouteRule) +[Routing precedence](/reference/spec/#gateway.networking.k8s.io/v1.HTTPRouteRule) ensures that all traffic with the matching host and header (the most specific match) will be sent to `foo-v2`.