Doc updates for Backends

content/docs/about/architecture.md

@@ -29,7 +29,7 @@ The config watcher component is part of the {{< reuse "docs/snippets/product-nam
 
 ### Secret watcher
 
-The secret watcher component is part of the {{< reuse "docs/snippets/product-name.md" >}} control plane and watches a secret store for updates to secrets. For example, you might use a Kubernetes Secret to store the AWS access key and secret key credentials for an Backend to access an AWS Lambda. However, you can configure {{< reuse "docs/snippets/product-name.md" >}} to also watch other secret stores.
+The secret watcher component is part of the {{< reuse "docs/snippets/product-name.md" >}} control plane and watches a secret store for updates to secrets. For example, you might use a Kubernetes Secret to store the AWS access key and secret key credentials for a Backend to access an AWS Lambda. However, you can configure {{< reuse "docs/snippets/product-name.md" >}} to also watch other secret stores.
 
 
 ### Endpoint discovery 

content/docs/about/custom-resources.md

@@ -46,7 +46,7 @@ If traffic matches the conditions that are defined in the HTTPRoute, the Gateway
 A [ReferenceGrant](https://gateway-api.sigs.k8s.io/api-types/referencegrant/) allows a Kubernetes Gateway API resource, such as an HTTPRoute, to reference resources that exist in other namespaces. For example, if you create an HTTPRoute resource in `namespace1`, but the Kubernetes Service or Backend that you want to route to is in `namespace2`, you must create a ReferenceGrant to allow communication between these resources.
 
 {{% callout type="info" %}}
-{{< reuse "docs/snippets/product-name-caps.md" >}} custom resources do not follow the same cross-namespace restrictions as the resources in the {{< reuse "docs/snippets/k8s-gateway-api-name.md" >}}. For example, access between a RouteOption resource in `namespace1` and an Backend resource in `namespace2` is allowed by default and does not require a ReferenceGrant. However, if you need to reference a {{< reuse "docs/snippets/product-name.md" >}} resource from a {{< reuse "docs/snippets/k8s-gateway-api-name.md" >}} resource, you must create a ReferenceGrant. 
+{{< reuse "docs/snippets/product-name-caps.md" >}} custom resources do not follow the same cross-namespace restrictions as the resources in the {{< reuse "docs/snippets/k8s-gateway-api-name.md" >}}. For example, access between a RouteOption resource in `namespace1` and a Backend resource in `namespace2` is allowed by default and does not require a ReferenceGrant. However, if you need to reference a {{< reuse "docs/snippets/product-name.md" >}} resource from a {{< reuse "docs/snippets/k8s-gateway-api-name.md" >}} resource, you must create a ReferenceGrant. 
 {{% /callout %}}
 
 ## Kgateway resources {#kgateway}
@@ -74,7 +74,7 @@ While the {{< reuse "docs/snippets/k8s-gateway-api-name.md" >}} allows you to do
 
 ### Backends
 
-While you can route incoming traffic to a Kubernetes Service directly by referencing the Service in your HTTPRoute, you might want to add additional configuration to your service or point to endpoints outside your cluster. For example, you might want to route traffic to an AWS Lambda instance. You might also want to add settings to a Kubernetes Service, such as HTTP/2, traffic shadowing, or health check capabilities. 
+For workloads within your cluster, you can can route incoming traffic to their Kubernetes Service. But what if you have external services such as static hostnames or AWS Lambda functions that you want to route traffic to?
 
-You can use an [Backend](/docs/traffic-management/destination-types/backends/) resource to accomplish these tasks. Similar to using Kubernetes Services, you reference the Backend in your HTTPRoute resource. For more information about Backends, see [Backends](/docs/traffic-management/destination-types/backends/). 
+You can use a {{< reuse "docs/snippets/product-name.md" >}} Backend resource to accomplish this task. Similar to using Kubernetes Services, you reference the Backend in your HTTPRoute resource. For more information about Backends, see [Backends](/docs/traffic-management/destination-types/backends/). 
 

content/docs/integrations/istio.md

@@ -157,7 +157,7 @@ Upgrade your {{< reuse "docs/snippets/product-name.md" >}} installation to enabl
 
    Example output: 
    ```console {hl_lines=[17,18,19]}
-   apiVersion: gloo.solo.io/v1
+   apiVersion: gateway.kgateway.dev/v1alpha1
    kind: Settings
    metadata:
      annotations:
@@ -258,10 +258,10 @@ Upgrade your {{< reuse "docs/snippets/product-name.md" >}} installation to enabl
 
 You can exclude a service from requiring to communicate with the gateway proxy via mTLS by adding the `disableIstioAutoMtls` option to the Backend that represents your service. 
 
-1. Create an Backend resource that represents the httpbin app and add the `disableIstioAutoMtls: true` option to it. This option excludes the httpbin Backend from communicating with the gateway proxy via mTLS. 
+1. Create a Backend resource that represents the httpbin app and add the `disableIstioAutoMtls: true` option to it. This option excludes the httpbin Backend from communicating with the gateway proxy via mTLS. 
    ```yaml
    kubectl apply -f- <<EOF
-   apiVersion: gloo.solo.io/v1
+   apiVersion: gateway.kgateway.dev/v1alpha1
    kind: Backend
    metadata:
      name: httpbin
@@ -293,7 +293,7 @@ You can exclude a service from requiring to communicate with the gateway proxy v
        - backendRefs:
          - name: httpbin
            kind: Backend
-           group: gloo.solo.io
+           group: gateway.kgateway.dev
    EOF
    ```
 

content/docs/operations/debug.md

@@ -100,7 +100,7 @@ Make sure to use the version of `{{< reuse "docs/snippets/cli-name.md" >}}` that
    | Component | Command |
    | ------------- | ------------- |
    | Gloo control plane | `kubectl logs -f -n {{< reuse "docs/snippets/ns-system.md" >}} -l kgateway=kgateway` |
-   | Gloo gateway proxy {{< callout type="info" >}}To view logs for incoming requests to your gateway proxy, be sure to <a href="/docs/security/access-logging/" >enable access logging</a> first.{{< /callout >}}| `kubectl logs -f -n {{< reuse "docs/snippets/ns-system.md" >}} -l gloo=kube-gateway` |
+   | {{< reuse "docs/snippets/product-name.md" >}} proxy {{< callout type="info" >}}To view logs for incoming requests to your gateway proxy, be sure to <a href="/docs/security/access-logging/" >enable access logging</a> first.{{< /callout >}}| `kubectl logs -f -n {{< reuse "docs/snippets/ns-system.md" >}} -l gloo=kube-gateway` |
    | Redis | `kubectl logs -f -n {{< reuse "docs/snippets/ns-system.md" >}} -l gloo=redis` |
 
 7. If you still cannot troubleshoot the issue, capture the logs and the state of {{< reuse "docs/snippets/product-name.md" >}} in a file. 

content/docs/resiliency/retry.md

@@ -8,7 +8,7 @@ Specify the number of times and duration you want {{< reuse "docs/snippets/produ
 
 ## About retries
 
-A retry specifies the maximum number of times {{< reuse "docs/snippets/product-name.md" >}} attempts to connect to an backend service if the initial call fails. Retries can enhance service availability and application performance by making sure that calls don’t fail permanently because of transient problems such as a temporarily overloaded service or network.
+A retry specifies the maximum number of times {{< reuse "docs/snippets/product-name.md" >}} attempts to connect to a backend service if the initial call fails. Retries can enhance service availability and application performance by making sure that calls don’t fail permanently because of transient problems such as a temporarily overloaded service or network.
 
 To configure retries, you can use the following settings in the RouteOption resource: 
 - `options.retries.retryOn` : The condition under which to retry forwarding the request to the backend service. This setting exposes the [`x-envoy-retry-on` Envoy header](https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/router_filter#x-envoy-retry-on). 

content/docs/resiliency/shadowing.md

@@ -42,10 +42,10 @@ To enable traffic shadowing, you must set up an [Backend](/docs/traffic-manageme
    kubectl -n shadow get pods
    ```
 
-4. Create an Backend resource for the httpbin shadow app. 
+4. Create a Backend resource for the httpbin shadow app. 
    ```yaml
    kubectl apply -f- <<EOF
-   apiVersion: gloo.solo.io/v1
+   apiVersion: gateway.kgateway.dev/v1alpha1
    kind: Backend
    metadata:
      name: shadow
@@ -61,7 +61,7 @@ To enable traffic shadowing, you must set up an [Backend](/docs/traffic-manageme
 5. Create another Backend resource for the httpbin app that you deployed as part of the [Get started](/docs/quickstart/}) guide. 
    ```yaml
    kubectl apply -f- <<EOF
-   apiVersion: gloo.solo.io/v1
+   apiVersion: gateway.kgateway.dev/v1alpha1
    kind: Backend
    metadata:
      name: httpbin
@@ -116,7 +116,7 @@ To enable traffic shadowing, you must set up an [Backend](/docs/traffic-manageme
          backendRefs:
            - name: httpbin
              kind: Backend
-             group: gloo.solo.io
+             group: gateway.kgateway.dev
              namespace: {{< reuse "docs/snippets/ns-system.md" >}}
    EOF
    ```
@@ -135,7 +135,7 @@ To enable traffic shadowing, you must set up an [Backend](/docs/traffic-manageme
          kind: HTTPRoute
          namespace: httpbin
      to:
-       - group: "gloo.solo.io"
+       - group: "gateway.kgateway.dev"
          kind: Backend
    EOF
    ```

content/docs/resiliency/timeouts.md

@@ -7,7 +7,7 @@ description: Set a maximum time for the gateway to handle a request, including e
 Set a maximum time for the gateway to handle a request, including error retries.
 
 ## About
-A timeout is the amount of time ([duration](https://protobuf.dev/reference/protobuf/google.protobuf/#duration)) that {{< reuse "docs/snippets/product-name.md" >}} waits for replies from an backend service before the service is considered unavailable. This setting can be useful to avoid your apps from hanging or fail if no response is returned in a specific timeframe. With timeouts, calls either succeed or fail within a predicatble timeframe.
+A timeout is the amount of time ([duration](https://protobuf.dev/reference/protobuf/google.protobuf/#duration)) that {{< reuse "docs/snippets/product-name.md" >}} waits for replies from a backend service before the service is considered unavailable. This setting can be useful to avoid your apps from hanging or fail if no response is returned in a specific timeframe. With timeouts, calls either succeed or fail within a predicatble timeframe.
 
 The time an app needs to process a request can vary a lot which is why applying the same timeout across services can cause a variety of issues. For example, a timeout that is too long can result in excessive latency from waiting for replies from failing services. On the other hand, a timeout that is too short can result in calls failing unnecessarily while waiting for an operation that needs responses from multiple services.
 

content/docs/security/local/_index.txt

@@ -14,7 +14,7 @@ For more information about local rate limiting, see the [Envoy documentation](ht
 
 ## Architecture
 
-The following image shows how local rate limiting works in {{< reuse "docs/snippets/product-name.md" >}}. As clients send requests to an backend destination, they first reach the Envoy instance that represents your gateway. Local rate limiting settings are applied to an Envoy pod or process. Note that limits are applied to each pod or process. For example, if you have 5 Envoy instances that are configured with a local rate limit of 10 requests per second, the total number of allowed requests per second is 50 (5*10). In a global rate limiting setup, this limit is shared between all Envoy instances, so the total number of allowed requests per second is 10. 
+The following image shows how local rate limiting works in {{< reuse "docs/snippets/product-name.md" >}}. As clients send requests to a backend destination, they first reach the Envoy instance that represents your gateway. Local rate limiting settings are applied to an Envoy pod or process. Note that limits are applied to each pod or process. For example, if you have 5 Envoy instances that are configured with a local rate limit of 10 requests per second, the total number of allowed requests per second is 50 (5*10). In a global rate limiting setup, this limit is shared between all Envoy instances, so the total number of allowed requests per second is 10. 
 
 Depending on your setup, each Envoy instance or pod is configured with a number of tokens in a token bucket. To allow a request, a token must be available in the bucket so that it can be assigned to a downstream connection. Token buckets are refilled occasionally as defined in the refill setting of the local rate limiting configuration. If no token is available, the connection is closed immediately, and a 429 HTTP response code is returned to the client. 
 

content/docs/setup/default.md

@@ -63,7 +63,7 @@ kubectl get settings default -n {{< reuse "docs/snippets/ns-system.md" >}} -o ya
 
 When you follow the [Get started](/docs/quickstart/) guide, the following Settings resource is created for you. To understand each setting, check out the [Settings custom resource documentation](/docs/reference/api/top-level/settings.proto.sk/). 
 ```yaml
-apiVersion: gloo.solo.io/v1
+apiVersion: gateway.kgateway.dev/v1alpha1
 kind: Settings
 metadata:
   annotations:

content/docs/traffic-management/destination-types/backends/_index.md

@@ -4,89 +4,20 @@ weight: 20
 prev: /docs/traffic-management/destination-types/kube-services
 ---
 
-
-Use Backend resources to define a backing destination for a route that you want {{< reuse "docs/snippets/product-name.md" >}} to route to.
-
-Backends can be compared to a [cluster](https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/cluster/v3/cluster.proto) in Envoy terminology. Each Backend must define a type. Supported types include `static` and `kubernetes`. Each type is handled by a different plugin in {{< reuse "docs/snippets/product-name.md" >}}. For more information, see [Types](#types). 
-
-Backends allow you to add additional configuration to instruct {{< reuse "docs/snippets/product-name.md" >}} how to handle the request to the backing destination. For example, you can define that the destination requires the requests to be sent with the HTTP/2 protocol or that you want requests to be load balanced by using a specific load balancing algorithm. To route to an Backend resource, you reference the Backend in the `backendRefs` section of your HTTPRoute, just like you do when routing to a Kubernetes service directly. For more information, see [Routing](#routing). 
-
-You can manually create Backends or enable Backend discovery in {{< reuse "docs/snippets/product-name.md" >}} to automatically create Backends for any Kubernetes service that is created and discovered in the cluster. 
-
-For more information, see the [Backend API reference](/docs/reference/api/upstream). 
+Use a Backend resource to define a backing destination that you want {{< reuse "docs/snippets/product-name.md" >}} to route to. A Backend destination is external to the cluster and, as such, cannot be represented as a Kubernetes Service. For more information, see the [Backend API docs](/docs/reference/api/upstream). 
 
 ## Types
 
 Check out the following guides for examples on how to use the supported Backends types with {{< reuse "docs/snippets/product-name.md" >}}. 
 
 {{< cards >}}
   {{< card link="static" title="Static IP address or hostname" >}}
-  {{< card link="kubernetes" title="Kubernetes Service" >}}
   {{< card link="lambda" title="AWS Lambda" >}}
-  {{< card link="ec2" title="AWS EC2 instance" >}}
-  {{< card link="http2" title="HTTP/2" >}}
 {{< /cards >}}
 
-<!-- TODO supported backends
-
-You can create Backends of type `static`, `kube`, `aws`, and `gcp`. 
-
-{{% callout type="info" %}}
-Backends of type `azure`, `consul`, `grpc`, `rest`, or `awsEc2` are not supported in {{< reuse "docs/snippets/product-name.md" >}} when using the {{< reuse "docs/snippets/k8s-gateway-api-name.md" >}}. You can use these types of Backends when using a gateway proxy that is configured for the {{< reuse "docs/snippets/product-name.md" >}} API. For more information, see [Destination types in the {{< reuse "docs/snippets/product-name.md" >}} ({{< reuse "docs/snippets/product-name.md" >}} API) documentation](https://docs.solo.io/gloo-edge/latest/guides/traffic_management/destination_types/).
-{{% /callout %}}
-
-Check out the following guides for examples on how to use Backends with {{< reuse "docs/snippets/product-name.md" >}}:  
-* [Static](/traffic-management/destination-types/backends/static/)
-* [Kubernetes service](/traffic-management/destination-types/backends/kubernetes/)
-* [Google Cloud Run](/traffic-management/destination-types/backends/cloud-run/)
-* [AWS Lambda](/traffic-management/destination-types/backends/lambda/)
-* [HTTP/2](/traffic-management/destination-types/backends/http2/)
-
--->
-
-<!--
-
-### Static
-
-Static Backends are the 
-
-### Kubernetes
--->
-
-## Discovery
-
-{{< reuse "docs/snippets/discovery-about.md" >}}
-
-To enable service discovery: 
-
-1. Get the current values for your Helm chart. 
-   ```sh
-   helm get values kgateway -n {{< reuse "docs/snippets/ns-system.md" >}} -o yaml > kgateway.yaml
-   open kgateway.yaml
-   ```
-
-2. In your Helm values file, enable service discovery. 
-   ```yaml
-   gloo:
-     discovery:
-       enabled: true
-   ```
-
-3. Upgrade your {{< reuse "docs/snippets/product-name.md" >}} installation to enable service discovery. 
-   ```sh
-   helm upgrade -n {{< reuse "docs/snippets/ns-system.md" >}} kgateway kgateway/kgateway\
-   --values kgateway.yaml \
-   --version {{< reuse "docs/versions/n-patch.md" >}} 
-   ```
-
-4. Review the Backend resources that are automatically created for the Kubernetes services that you have in your cluster. 
-   ```sh
-   kubectl get backends -n {{< reuse "docs/snippets/ns-system.md" >}}
-   ```
-
 ## Routing
 
-You can route to an Backend by simply referencing that Backend in the `backendRefs` section of your HTTPRoute resource as shown in the following example. Note that if your Backend and HTTPRoute resources exist in different namespaces, you must create a Kubernetes ReferenceGrant resource to allow the HTTPRoute to access the Backend.
+You can route to a Backend by simply referencing that Backend in the `backendRefs` section of your HTTPRoute resource as shown in the following example. Note that if your Backend and HTTPRoute resources exist in different namespaces, you must create a Kubernetes ReferenceGrant resource to allow the HTTPRoute to access the Backend.
 
 {{< callout type="warning" >}}
 Do not specify a port in the `spec.backendRefs.port` field when referencing your Backend. The port is defined in your Backend resource and ignored if set on the HTTPRoute resource.
@@ -104,17 +35,16 @@ spec:
     namespace: {{< reuse "docs/snippets/ns-system.md" >}}
   hostnames:
     - static.example
-  rules:
-    - backendRefs:
-      - name: json-backend
-        kind: Backend
-        group: gloo.solo.io
-      filters:
-      - type: ExtensionRef
-        extensionRef:
-          group: gateway.solo.io
-          kind: RouteOption
-          name: rewrite
+     rules:
+       - backendRefs:
+         - name: json-backend
+           kind: Backend
+           group: gateway.kgateway.dev
+         filters:
+         - type: URLRewrite
+           urlRewrite:
+             hostname: jsonplaceholder.typicode.com
+   EOF
 ```
 
 For an example, see the [Static](/docs/traffic-management/destination-types/backends/static/) Backend guide.