docs: update gatewayapi resources version and fix dead link (#2190)

* update doc gatewayapi resources version and fix dead link

Signed-off-by: sh2 <shawnhxh@outlook.com>

* update doc gatewayapi resources version for v0.6.0

Signed-off-by: sh2 <shawnhxh@outlook.com>

---------

Signed-off-by: sh2 <shawnhxh@outlook.com>

site/content/en/latest/design/accesslog.md

@@ -6,17 +6,17 @@ title: "Observability: Accesslog"
 
 Envoy supports extensible accesslog to different sinks, File, gRPC etc. Envoy supports customizable access log formats using predefined fields as well as arbitrary HTTP request and response headers. Envoy supports several built-in access log filters and extension filters that are registered at runtime.
 
-Envoy Gateway leverages [Gateway API](https://gateway-api.sigs.k8s.io/) for configuring managed Envoy proxies. Gateway API defines core, extended, and implementation-specific API [support levels](https://gateway-api.sigs.k8s.io/concepts/conformance/?h=extended#2-support-levels) for implementers such as Envoy Gateway to expose features. Since accesslog is not covered by `Core` or `Extended` APIs, EG should provide an easy to config access log formats and sinks per `EnvoyProxy`.
+Envoy Gateway leverages [Gateway API][] for configuring managed Envoy proxies. Gateway API defines core, extended, and implementation-specific API [support levels][] for implementers such as Envoy Gateway to expose features. Since accesslog is not covered by `Core` or `Extended` APIs, EG should provide an easy to config access log formats and sinks per `EnvoyProxy`.
 
 ## Goals
 
 - Support send accesslog to `File` or `OpenTelemetry` backend
-- TODO: Support access log filters base on [CEL](https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/access_loggers/filters/cel/v3/cel.proto#extension-envoy-access-loggers-extension-filters-cel) expression
+- TODO: Support access log filters base on [CEL][] expression
 
 ## Non-Goals
 
 - Support non-CEL filters, e.g. `status_code_filter`, `response_flag_filter`
-- Support [HttpGrpcAccessLogConfig](https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/access_loggers/grpc/v3/als.proto#extensions-access-loggers-grpc-v3-httpgrpcaccesslogconfig) or [TcpGrpcAccessLogConfig](https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/access_loggers/grpc/v3/als.proto#extensions-access-loggers-grpc-v3-tcpgrpcaccesslogconfig)
+- Support [HttpGrpcAccessLogConfig][] or [TcpGrpcAccessLogConfig][]
 
 ## Use-Cases
 
@@ -235,3 +235,9 @@ spec:
                 resources:
                   k8s.cluster.name: "cluster-1"
 ```
+
+[Gateway API]: https://gateway-api.sigs.k8s.io/
+[support levels]: https://gateway-api.sigs.k8s.io/concepts/conformance/?h=extended#2-support-levels
+[CEL]: https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/access_loggers/filters/cel/v3/cel.proto#extension-envoy-access-loggers-extension-filters-cel
+[HttpGrpcAccessLogConfig]: https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/access_loggers/grpc/v3/als.proto#extensions-access-loggers-grpc-v3-httpgrpcaccesslogconfig
+[TcpGrpcAccessLogConfig]: https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/access_loggers/grpc/v3/als.proto#extensions-access-loggers-grpc-v3-tcpgrpcaccesslogconfig

site/content/en/latest/design/backend-traffic-policy.md

@@ -29,14 +29,14 @@ then the configuration from the policy that is targeting the xRoute resource wil
 Here is an example highlighting how a user can configure this API.
 
 ```yaml
-apiVersion: gateway.networking.k8s.io/v1beta1
+apiVersion: gateway.networking.k8s.io/v1
 kind: GatewayClass
 metadata:
   name: eg
 spec:
   controllerName: gateway.envoyproxy.io/gatewayclass-controller
 ---
-apiVersion: gateway.networking.k8s.io/v1beta1
+apiVersion: gateway.networking.k8s.io/v1
 kind: Gateway
 metadata:
   name: eg
@@ -48,7 +48,7 @@ spec:
       protocol: HTTP
       port: 80
 ---
-apiVersion: gateway.networking.k8s.io/v1beta1
+apiVersion: gateway.networking.k8s.io/v1
 kind: HTTPRoute
 metadata:
   name: ipv4-route
@@ -70,7 +70,7 @@ spec:
             type: PathPrefix
             value: /
 ---
-apiVersion: gateway.networking.k8s.io/v1beta1
+apiVersion: gateway.networking.k8s.io/v1
 kind: HTTPRoute
 metadata:
   name: ipv6-route

site/content/en/latest/design/bootstrap.md

@@ -53,7 +53,7 @@ Here is an example where a user inputs a `GatewayClass` and the CLI generates th
 
 ```
 cat <<EOF | egctl x translate --from gateway-api --to gateway-api -f -
-apiVersion: gateway.networking.k8s.io/v1beta1
+apiVersion: gateway.networking.k8s.io/v1
 kind: GatewayClass
 metadata:
   name: eg
@@ -65,7 +65,7 @@ EOF
 ```
 
 ```
-apiVersion: gateway.networking.k8s.io/v1beta1
+apiVersion: gateway.networking.k8s.io/v1
 kind: GatewayClass
 metadata:
   name: eg
@@ -173,7 +173,7 @@ unmarshalled into the Bootstrap object as well as ensure the user can override c
 
 ```
 cat <<EOF | egctl x translate --from gateway-api --to gateway-api -f -
-apiVersion: gateway.networking.k8s.io/v1beta1
+apiVersion: gateway.networking.k8s.io/v1
 kind: GatewayClass
 metadata:
   name: eg
@@ -275,7 +275,7 @@ EOF
 ```
 
 ```
-apiVersion: gateway.networking.k8s.io/v1beta1
+apiVersion: gateway.networking.k8s.io/v1
 kind: GatewayClass
 metadata:
   name: eg
@@ -376,6 +376,6 @@ spec:
 ```
 
 [Issue 31]: https://github.com/envoyproxy/gateway/issues/31
-[EnvoyProxy]: https://gateway.envoyproxy.io/latest/api/config_types.html#envoyproxy
-[GatewayClass]: https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1beta1.GatewayClass
-[parametersRef]: https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1beta1.ParametersReference 
+[EnvoyProxy]: ../../api/extension_types#envoyproxy
+[GatewayClass]: https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1.GatewayClass
+[parametersRef]: https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1.ParametersReference 

site/content/en/latest/design/client-traffic-policy.md

@@ -26,14 +26,14 @@ to define configuration that affect the connection between the downstream client
 Here is an example highlighting how a user can configure this API.
 
 ```
-apiVersion: gateway.networking.k8s.io/v1beta1
+apiVersion: gateway.networking.k8s.io/v1
 kind: GatewayClass
 metadata:
   name: eg
 spec:
   controllerName: gateway.envoyproxy.io/gatewayclass-controller
 ---
-apiVersion: gateway.networking.k8s.io/v1beta1
+apiVersion: gateway.networking.k8s.io/v1
 kind: Gateway
 metadata:
   name: eg
@@ -45,7 +45,7 @@ spec:
       protocol: HTTP
       port: 80
 ---
-apiVersion: gateway.networking.k8s.io/v1beta1
+apiVersion: gateway.networking.k8s.io/v1
 kind: HTTPRoute
 metadata:
   name: backend

site/content/en/latest/design/config-api.md

@@ -285,14 +285,14 @@ GatewayClass and Gateway resources define the data plane infrastructure. Note th
 running with the Kubernetes provider.
 
 ```yaml
-apiVersion: gateway.networking.k8s.io/v1beta1
+apiVersion: gateway.networking.k8s.io/v1
 kind: GatewayClass
 metadata:
   name: example-class
 spec:
   controllerName: gateway.envoyproxy.io/gatewayclass-controller
 ---
-apiVersion: gateway.networking.k8s.io/v1beta1
+apiVersion: gateway.networking.k8s.io/v1
 kind: Gateway
 metadata:
   name: example-gateway
@@ -312,7 +312,7 @@ The following example will configure the data plane to use a ClusterIP service i
 service:
 
 ```yaml
-apiVersion: gateway.networking.k8s.io/v1beta1
+apiVersion: gateway.networking.k8s.io/v1
 kind: GatewayClass
 metadata:
   name: example-class
@@ -323,7 +323,7 @@ spec:
     group: gateway.envoyproxy.io
     kind: EnvoyProxy
 ---
-apiVersion: gateway.networking.k8s.io/v1beta1
+apiVersion: gateway.networking.k8s.io/v1
 kind: Gateway
 metadata:
   name: example-gateway
@@ -346,8 +346,8 @@ spec:
 __Note:__ The NetworkPublishing API is currently undefined and is provided here for illustration purposes only.
 
 [issue_51]: https://github.com/envoyproxy/gateway/issues/51
-[design_doc]: https://github.com/envoyproxy/gateway/blob/main/docs/design/SYSTEM_DESIGN.md
+[design_doc]: ../system-design/
 [gw_api]: https://gateway-api.sigs.k8s.io/
-[gc]: https://gateway-api.sigs.k8s.io/v1alpha2/references/spec/#gateway.networking.k8s.io/v1alpha2.GatewayClass
+[gc]: https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1.GatewayClass
 [cr]: https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/
 [union]: https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#unions

site/content/en/latest/design/eg-metrics.md

@@ -37,13 +37,13 @@ The use-cases include:
 
 ### Standards
 
-Our metrics, will be built upon the [OpenTelemetry](https://opentelemetry.io/) standards. All metrics will be configured via the [OpenTelemetry SDK](https://opentelemetry.io/docs/specs/otel/metrics/sdk/), which offers neutral libraries that can be connected to various backends.
+Our metrics, will be built upon the [OpenTelemetry][] standards. All metrics will be configured via the [OpenTelemetry SDK][], which offers neutral libraries that can be connected to various backends.
 
 This approach allows the Envoy Gateway code to concentrate on the crucial aspect - generating the metrics - and delegate all other tasks to systems designed for telemetry ingestion.
 
 ### Attributes
 
-OpenTelemetry defines a set of [Semantic Conventions](https://opentelemetry.io/docs/concepts/semantic-conventions/), including [Kubernetes specific ones](https://opentelemetry.io/docs/specs/otel/resource/semantic_conventions/k8s/).
+OpenTelemetry defines a set of [Semantic Conventions][], including [Kubernetes specific ones][].
 
 These attributes can be expressed in logs (as keys of structured logs), traces (as attributes), and metrics (as labels).
 
@@ -53,7 +53,7 @@ We aim to use attributes consistently where applicable. Where possible, these sh
 
 Envoy Gateway supports both **PULL/PUSH** mode metrics, with Metrics exported via Prometheus by default.
 
-Additionally, Envoy Gateway can export metrics using both the [OTEL gRPC metrics exporter](https://opentelemetry.io/docs/specs/otel/metrics/sdk_exporters/otlp/#general) and [OTEL HTTP metrics exporter](https://opentelemetry.io/docs/specs/otel/metrics/sdk_exporters/otlp/#general), which pushes metrics by grpc/http to a remote OTEL collector.
+Additionally, Envoy Gateway can export metrics using both the [OTEL gRPC metrics exporter][] and [OTEL HTTP metrics exporter][], which pushes metrics by grpc/http to a remote OTEL collector.
 
 Users can extend these in two ways:
 
@@ -84,7 +84,7 @@ I propose the following:
 
 Metrics offer the greatest potential for providing guarantees. They often directly influence alerts and dashboards, making changes highly impactful. This contrasts with traces and logs, which are often used for ad-hoc analysis, where minor changes to information can be easily understood by a human.
 
-Moreover, there is precedent for this: [Kubernetes Metrics Lifecycle](https://kubernetes.io/docs/concepts/cluster-administration/system-metrics/#metric-lifecycle) has well-defined processes, and Envoy Gateway's dataplane (Envoy Proxy) metrics are de facto stable.
+Moreover, there is precedent for this: [Kubernetes Metrics Lifecycle][] has well-defined processes, and Envoy Gateway's dataplane (Envoy Proxy) metrics are de facto stable.
 
 Currently, all Envoy Gateway metrics lack defined stability. I suggest we categorize all existing metrics as either:
 
@@ -223,3 +223,11 @@ telemetry:
           port: 4318
           protocol: http
 ```
+
+[OpenTelemetry]: https://opentelemetry.io/
+[OpenTelemetry SDK]: https://opentelemetry.io/docs/specs/otel/metrics/sdk/
+[Semantic Conventions]: https://opentelemetry.io/docs/concepts/semantic-conventions/
+[Kubernetes specific ones]: https://opentelemetry.io/docs/specs/otel/resource/semantic_conventions/k8s/
+[OTEL gRPC metrics exporter]: https://opentelemetry.io/docs/specs/otel/metrics/sdk_exporters/otlp/#general
+[OTEL HTTP metrics exporter]: https://opentelemetry.io/docs/specs/otel/metrics/sdk_exporters/otlp/#general
+[Kubernetes Metrics Lifecycle]: https://kubernetes.io/docs/concepts/cluster-administration/system-metrics/#metric-lifecycle

site/content/en/latest/design/envoy-patch-policy.md

@@ -32,14 +32,14 @@ resource objects.
 Here is an example highlighting how a user can configure global ratelimiting using an external rate limit service using this API.
 
 ```
-apiVersion: gateway.networking.k8s.io/v1beta1
+apiVersion: gateway.networking.k8s.io/v1
 kind: GatewayClass
 metadata:
   name: eg
 spec:
   controllerName: gateway.envoyproxy.io/gatewayclass-controller
 ---
-apiVersion: gateway.networking.k8s.io/v1beta1
+apiVersion: gateway.networking.k8s.io/v1
 kind: Gateway
 metadata:
   name: eg
@@ -51,7 +51,7 @@ spec:
       protocol: HTTP
       port: 80
 ---
-apiVersion: gateway.networking.k8s.io/v1beta1
+apiVersion: gateway.networking.k8s.io/v1
 kind: HTTPRoute
 metadata:
   name: backend
@@ -167,10 +167,10 @@ patches will work.
 [Gateway API]: https://gateway-api.sigs.k8s.io/
 [Kubernetes]: https://kubernetes.io/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/
 [Kustomize]: https://github.com/kubernetes-sigs/kustomize/blob/master/examples/jsonpatch.md
-[Extension APIs]: https://gateway.envoyproxy.io/latest/api/extension_types.html
-[RateLimit]: https://gateway.envoyproxy.io/latest/user/rate-limit.html
-[EnvoyGateway]: https://gateway.envoyproxy.io/latest/api/config_types.html#envoygateway
-[Extending the Control Plane]: https://gateway.envoyproxy.io/latest/design/extending-envoy-gateway.html
+[Extension APIs]: ../../api/extension_types/
+[RateLimit]: ../../user/rate-limit/
+[EnvoyGateway]: ../../api/extension_types/#envoygateway
+[Extending the Control Plane]: ../extending-envoy-gateway
 [EnvoyFilter]: https://istio.io/latest/docs/reference/config/networking/envoy-filter
-[egctl x translate]: https://gateway.envoyproxy.io/latest/user/egctl.html#egctl-experimental-translate
-[Bootstrap configuration using EnvoyProxy API]: https://gateway.envoyproxy.io/latest/user/customize-envoyproxy.html#customize-envoyproxy-bootstrap-config
+[egctl x translate]: ../../user/egctl#egctl-experimental-translate
+[Bootstrap configuration using EnvoyProxy API]: ../../user/customize-envoyproxy#customize-envoyproxy-bootstrap-config

site/content/en/latest/design/extending-envoy-gateway.md

@@ -110,7 +110,7 @@ spec:
   ...
 
 ---
-apiVersion: gateway.networking.k8s.io/v1beta1
+apiVersion: gateway.networking.k8s.io/v1
 kind: HTTPRoute
 metadata:
   name: example
@@ -140,7 +140,7 @@ if they specify an `group` that matches the `group` of an `ExtensionRef` filter.
 modified configuration. If an extension is not registered or if the registered extension does not specify support for the `group` of an `ExtensionRef` filter then Envoy Gateway will treat it as an unknown resource
 and provide an error to the user.
 
-**Note:** Currently (as of [v1beta1][]) Gateway API does not provide a means to specify the namespace or version of an object referenced as an `ExtensionRef`. The extension mechanism will assume that
+**Note:** Currently (as of [v1][]) Gateway API does not provide a means to specify the namespace or version of an object referenced as an `ExtensionRef`. The extension mechanism will assume that
 the namespace of any `ExtensionRef` is the same as the namespace of the `HTTPRoute` or `GRPCRoute` it is attached to rather than treating the `name` field of an `ExtensionRef` as a `name.namespace` string.
 If Gateway API adds support for these fields then the design of the Envoy Gateway extensions will be updated to support them.
 
@@ -305,21 +305,21 @@ whenever Envoy Gateway creates an instance of Envoy Proxy. An extension develope
 Extending Envoy Gateway by using an external extension server which makes use of hook points in Envoy Gateway does comes with a few trade-offs. One known trade-off is the impact of the time that it takes for the hook calls to be executed. Since an extension would make use of hook points in Envoy Gateway that use gRPC for communication, the time it takes to perform these requests could become a concern for some extension developers. One way to minimize the request time of the hook calls is to load the extension server as a sidecar to Envoy Gateway to minimize the impact of networking on the hook calls.
 
 [official goals]: https://github.com/envoyproxy/gateway/blob/main/GOALS.md#extensibility
-[ExtensionRef filters]: https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1beta1.LocalObjectReference
-[ExtensionRef]: https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1beta1.LocalObjectReference
-[ExtensionRefs]: https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1beta1.LocalObjectReference
-[backendRefs]: https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1beta1.BackendObjectReference
+[ExtensionRef filters]: https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1.LocalObjectReference
+[ExtensionRef]: https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1.LocalObjectReference
+[ExtensionRefs]: https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1.LocalObjectReference
+[backendRefs]: https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1.BackendObjectReference
 [Gateway API Policy attachments]: https://gateway-api.sigs.k8s.io/references/policy-attachment/?h=policy
 [Policy Attachments]: https://gateway-api.sigs.k8s.io/references/policy-attachment/?h=policy
 [policyAttachments]: https://gateway-api.sigs.k8s.io/references/policy-attachment/?h=policy
 [Envoy]: https://www.envoyproxy.io/
 [Envoy specific configuration (xDS)]: https://www.envoyproxy.io/docs/envoy/v1.25.1/configuration/configuration
-[v1beta1]: https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io%2fv1beta1
-[rate limiting]: https://gateway.envoyproxy.io/v0.3.0/user/rate-limit.html
-[authentication]: https://gateway.envoyproxy.io/v0.3.0/user/authn.html
-[HTTPRoute]: https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1beta1.HTTPRoute
-[GRPCRoute]: https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1alpha2.GRPCRoute
-[EnvoyGateway config]: https://gateway.envoyproxy.io/v0.3.0/api/config_types.html#envoygateway
+[v1]: https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1
+[rate limiting]: ../../user/rate-limit/
+[authentication]: ../../user/jwt-authentication/
+[HTTPRoute]: https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1.HTTPRoute
+[GRPCRoute]: https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1alpha2.GRPCRoute
+[EnvoyGateway config]: ../../api/extension_types/#envoygateway
 [controller-runtime]: https://github.com/kubernetes-sigs/controller-runtime
 [Unstructured]: https://pkg.go.dev/k8s.io/apimachinery/pkg/apis/meta/v1/unstructured
 [Listener]: https://www.envoyproxy.io/docs/envoy/v1.23.0/api-v3/config/listener/v3/listener.proto#config-listener-v3-listener

site/content/en/latest/design/gatewayapi-translator.md

@@ -38,7 +38,7 @@ __Note:__ Envoy Gateway does not collapse listeners across multiple Gateways.
 
 ```yaml
 kind: Gateway
-apiVersion: gateway.networking.k8s.io/v1beta1
+apiVersion: gateway.networking.k8s.io/v1
 metadata:
   name: gateway-1
   namespace: envoy-gateway
@@ -65,7 +65,7 @@ spec:
 
 ```yaml
 kind: Gateway
-apiVersion: gateway.networking.k8s.io/v1beta1
+apiVersion: gateway.networking.k8s.io/v1
 metadata:
   name: gateway-1
   namespace: envoy-gateway
@@ -91,7 +91,7 @@ spec:
 
 ```yaml
 kind: Gateway
-apiVersion: gateway.networking.k8s.io/v1beta1
+apiVersion: gateway.networking.k8s.io/v1
 metadata:
   name: gateway-1
   namespace: envoy-gateway
@@ -118,7 +118,7 @@ spec:
 
 ```yaml
 kind: Gateway
-apiVersion: gateway.networking.k8s.io/v1beta1
+apiVersion: gateway.networking.k8s.io/v1
 metadata:
   name: gateway-1
   namespace: envoy-gateway
@@ -250,4 +250,4 @@ type RouteContext interface {
 }
 ```
 
-[message bus]: watching.md
+[message bus]: ../watching/