Doc fixes v1.14

changelog/v1.14.30/docs-rm-wasm.yaml

@@ -0,0 +1,13 @@
+changelog:
+- type: NON_USER_FACING  
+  description: >- 
+    Removes references to WebAssembly Hub and `wasme` CLI.
+    Updates the old WAH image to one stored in GCR.
+    skipCI-kube-tests:true
+  issueLink: https://github.com/solo-io/doctopus/issues/79
+  resolvesIssue: false
+- type: NON_USER_FACING  
+  description: >- 
+    Adds docs for why to use upstreams over Kube services.
+    skipCI-kube-tests:true
+  resolvesIssue: false

docs/content/guides/traffic_management/destination_types/kubernetes_services/_index.md

@@ -4,17 +4,28 @@ weight: 80
 description: Routing to services registered as Kubernetes Services through the API
 ---
 
-If you are running Gloo Edge in a Kubernetes cluster, it is possible to directly specify 
-[Kubernetes Services](https://kubernetes.io/docs/concepts/services-networking/service/) as routing destinations. 
-The `kube` destination type has two required fields:
+To allow for optimal performance in Gloo Edge, it is recommended to use Gloo [static]({{% versioned_link_path fromRoot="/guides/traffic_management/destination_types/static_upstream/" %}}) and [discovered]({{% versioned_link_path fromRoot="/guides/traffic_management/destination_types/discovered_upstream/" %}}) Upstreams as your routing destination. However, if you run Gloo Edge in a Kubernetes cluster, you can choose between the following options to route to a Kubernetes service: 
 
-* `ref` is a {{< protobuf name="core.solo.io.ResourceRef">}} to the service that should receive traffic
-* `port` is an `int` which represents the port on which the service is listening. This must be one of the ports defined in the Kubernetes service spec
+## Option 1: Route to a Kubernetes service directly
 
-The following configuration will forward all requests to `/petstore` to port `8080` on the Kubernetes service named 
-`petstore` in the `default` namespace.
+You can configure your VirtualService to route to a Kubernetes service instead of a Gloo Upstream. 
 
-{{< highlight yaml "hl_lines=6-10" >}}
+{{% notice note %}}
+Consider the following information before choosing a Kubernetes service as your routing destination: 
+- For Gloo Edge to route traffic to a Kubernetes service directly, Gloo Edge requires scanning of all services in the cluster to create in-memory Upstream resources to represent them. Gloo uses these resources to validate that the upstream destination is valid and returns an error if the specified Kubernetes service cannot be found. Note that the in-memory Upstream resources are included in the API snapshot. If you have a large number of services in your cluster, the API snapshot increases which can have a negative impact on the Gloo Edge translation time.
+- When using Kubernetes services as a routing destination, Gloo Edge relies on `kube-proxy` to perform load balancing which can have further performance impacts. Routing to Gloo Upstreams bypasses `kube-proxy` as the request is routed to the pod directly. 
+- Some Gloo Edge functionality, such as policies, might not be available when using Kubernetes services as a routing destination. 
+{{% /notice %}}
+
+To use Kubernetes services as a routing destination: 
+
+1. Get the default Gloo Edge settings and verify that `spec.gloo.disableKubernetesDestinations` is set to `false`. This setting is required to allow Gloo Edge to scan all Kubernetes services in the cluster and to create in-memory Upstream resources to represent them. If it is set to `true`, follow the [upgrade guide]({{% versioned_link_path fromRoot="/operations/upgrading/" %}}) and set `settings.disableKubernetesDestinations: false` in your Helm chart. 
+   ```sh
+   kubectl get settings default -n gloo-system -o yaml
+   ```
+2. Configure the Kubernetes service as a routing destination in your VirtualService. The following example configuration forwards all requests to `/petstore` to port `8080` on the `petstore` Kubernetes service in the `default` namespace.
+
+   {{< highlight yaml "hl_lines=6-10" >}}
 routes:
 - matchers:
    - prefix: /petstore
@@ -25,4 +36,43 @@ routes:
           name: petstore
           namespace: default
         port: 8080
-{{< /highlight >}}
+   {{< /highlight >}}
+
+   The `kube` destination type has two required fields:
+
+   * `ref` is a {{< protobuf name="core.solo.io.ResourceRef">}} to the service that receives the traffic. 
+   * `port` is an integer (`int`) and represents the port the service listens on. Note that this port must be defined in the Kubernetes service.
+
+
+## Option 2: Use Kubernetes Upstream resources
+
+Instead of routing to a Kubernetes service directly, you can create [Gloo Kubernetes Upstream]({{% versioned_link_path fromRoot="/reference/api/github.com/solo-io/gloo/projects/gloo/api/v1/options/kubernetes/kubernetes.proto.sk/" %}}) resources that represent your Kubernetes workload. With Kubernetes Upstream resources, you can route requests to a specific pod in the cluster. This process bypasses `kube-proxy` which improves load balancing times for your workloads. 
+
+To use Kubernetes Upstream resources: 
+
+1. Create a Kubernetes Upstream resource for your workload. The following configuration creates an upstream resource for the Petstore app that listens on port 8080 in the default namespace. 
+   ```yaml
+   apiVersion: gloo.solo.io/v1
+   kind: Upstream
+   metadata:
+     name: petstore
+     namespace: gloo-system
+   spec:
+     kube:
+       serviceName: petstore
+       serviceNamespace: default
+       servicePort: 8080
+   ```
+
+2. Configure the Kubernetes Upstream as a routing destination in your VirtualService. The following example configuration forwards all requests to `/petstore` to the Petstore upstream in the `gloo-system` namespace.
+
+   {{< highlight yaml "hl_lines=6-8" >}}
+routes:
+- matchers:
+   - prefix: /petstore
+  routeAction:
+    single:
+      upstream:
+        name: petstore
+        namespace: gloo-system
+   {{< /highlight >}}

docs/content/installation/advanced_configuration/wasm.md

@@ -20,36 +20,24 @@ The [upstream Envoy Wasm filter](https://www.envoyproxy.io/docs/envoy/latest/con
 
 WebAssembly provides a safe, secure, and dynamic way of extending infrastructure with the programming language of your choice.
 
-1. Get a Wasm image. Review the following resources to help.
-   * [WebAssembly Hub](https://webassemblyhub.io/repositories/) to use an existing Wasm image repository.
-   * [WebAssembly Developer's Guide](https://webassembly.org/getting-started/developers-guide/) for more information on building your own Wasm image.
-   * [Solo's `wasme` CLI tool](https://docs.solo.io/web-assembly-hub/latest/tutorial_code/getting_started/) with starter kits that makes it easy to build and push Wasm modules to WebAssembly Hub.
-
-   Example steps with `wasme` CLI: For more information, see the [Build tutorial](https://docs.solo.io/web-assembly-hub/latest/tutorial_code/build_tutorials/building_cpp_filters/).
-   1. Start a C++ filter for Gloo.
-      ```sh
-      wasme init --language cpp --platform gloo --platform-version 1.13.x ./my-filter
-      ```
-   2. Build the filter into a Wasm image.
-      ```sh
-      cd my-filter
-      wasme build cpp --store ./wasmstore . -t my-wasm-filter:v1.0
-      ```
+1. Get a Wasm image. For more information on building your own Wasm image, see the [WebAssembly Developer's Guide](https://webassembly.org/getting-started/developers-guide/). 
 
 2. Prepare your Wasm image for use with Gloo Edge Enterprise. Review the following options.
-   * **Store in an image repository like WebAssembly Hub**: Solo provides [WebAssembly Hub](https://webassemblyhub.io/) as the simplest way to share and consume Wasm Envoy repositories. When you use the `wasme` CLI tool, you can push the image directly to your WebAssembly Hub repository. The resulting image repository is in a format similar to the following: `webassemblyhub.io/<username>/<filter-name>:<tag>`.
-   * **Load the Wasm file directly into the filter**: If your filter is not hosted in an image repository such as WebAssembly Hub, you can refer to the filepath directly, such as `<directory>/<filter-name>.wasm`.
-   * **Use an init container**: In some circumstances, you might not be able to use an image repository due to enterprise networking restrictions. Instead, you can use an `initContainer` on the Gloo Edge `gatewayProxy` deployment to load a `.wasm` file into a shared `volume`.
+
+   * Store in an OCI-compliant image repository. This guide uses an example Wasm image from Solo's public Google Container Registry.
+   * Load the Wasm file directly into the filter. If your filter is not hosted in an image repository, you can refer to the filepath directly, such as `<directory>/<filter-name>.wasm`.
+   * Use an init container. In some circumstances, you might not be able to use an image repository due to enterprise networking restrictions. Instead, you can use an `initContainer` on the Gloo Edge `gatewayProxy` deployment to load a `.wasm` file into a shared `volume`.
 
 ## Configure Gloo Edge to use a Wasm filter {#configuration}
 
 Now that Gloo Edge Enterprise is installed and you have your Wasm image, you are ready to configure Gloo Edge to use the Wasm filter. You add the filter to your gateway proxy configuration. For more information, check out the {{% protobuf name="wasm.options.gloo.solo.io.PluginSource" display="API docs"%}}.
 
 {{< tabs >}} 
-{{% tab name="From WebAssembly Hub" %}}
+{{% tab name="From an image registry" %}}
 1. Get the configuration for your `gateway-proxy` gateway.
    ```shell
    kubectl get -n gloo-system gateways.gateway.solo.io gateway-proxy -o yaml > gateway-proxy.yaml
+   open gateway-proxy.yaml
    ```
 2. Add the reference to your Wasm filter in the `httpGateway` section as follows.
    ```yaml
@@ -60,7 +48,7 @@ Now that Gloo Edge Enterprise is installed and you have your Wasm image, you are
            - config:
                '@type': type.googleapis.com/google.protobuf.StringValue
                value: "world"
-             image: webassemblyhub.io/yuval/add-header:v0.1
+             image: gcr.io/solo-public/docs/assemblyscript-test:istio-1.8
              name: add-header
              rootId: add_header
    ```
@@ -241,9 +229,3 @@ Now that your `gateway-proxy` gateway is updated, the hard work has been done. A
    < 
    [{"id":1,"name":"Dog","status":"available"},{"id":2,"name":"Cat","status":"pending"}]
    {{< /highlight >}}
-
-## References
-
-* [WebAssembly Hub](https://webassemblyhub.io/) for sharing and reusing Wasm filters.
-* [Solo's `wasme` CLI tool](https://docs.solo.io/web-assembly-hub/latest/installation/) for building and deploying Wasm filters for Gloo Edge Enterprise, Istio, and Envoy.
-* [Solo's `wasm` GitHub repo](https://github.com/solo-io/wasm) for the `wasme` tool.

docs/content/reference/values.txt

@@ -102,7 +102,7 @@
 |settings.linkerd|bool|false|Enable automatic Linkerd integration in Gloo Edge|
 |settings.disableProxyGarbageCollection|bool|false|Set this option to determine the state of an Envoy listener when the corresponding Proxy resource has no routes. If false (default), Gloo Edge will propagate the state of the Proxy to Envoy, resetting the listener to a clean slate with no routes. If true, Gloo Edge will keep serving the routes from the last applied valid configuration.|
 |settings.regexMaxProgramSize|uint32||Set this field to specify the RE2 default max program size which is a rough estimate of how complex the compiled regex is to evaluate. If not specified, this defaults to 100.|
-|settings.disableKubernetesDestinations|bool|false|Gloo Edge allows you to directly reference a Kubernetes service as a routing destination. To enable this feature, Gloo Edge scans the cluster for Kubernetes services and creates a special type of in-memory Upstream to represent them. If the cluster contains a lot of services and you do not restrict the namespaces Gloo Edge is watching, this can result in significant overhead. If you do not plan on using this feature, you can set this flag to true to turn it off.|
+|settings.disableKubernetesDestinations|bool|false|Enable or disable Gloo Edge to scan Kubernetes services in the cluster and create in-memory Upstream resources to represent them. These resources enable Gloo Edge to route requests to a Kubernetes service. Note that if you have a large number of services in your cluster and you do not restrict the namespaces that Gloo Edge watches, the API snapshot increases which can have a negative impact on the Gloo Edge translation time. In addition, load balancing is done in kube-proxy which can have further performance impacts. Using Gloo Upstreams as a routing destination bypasses kube-proxy as the request is routed to the pod directly. Alternatively, you can use [Kubernetes](https://docs.solo.io/gloo-edge/latest/reference/api/github.com/solo-io/gloo/projects/gloo/api/v1/options/kubernetes/kubernetes.proto.sk/) Upstream resources as a routing destination to forward requests to the pod directly. For more information, see the [docs](https://docs.solo.io/gloo-edge/latest/guides/traffic_management/destination_types/kubernetes_services/).|
 |settings.aws.enableCredentialsDiscovery|bool||Enable AWS credentials discovery in Envoy for lambda requests. If enableServiceAccountCredentials is also set, it will take precedence as only one may be enabled in Gloo Edge|
 |settings.aws.enableServiceAccountCredentials|bool||Use ServiceAccount credentials to authenticate lambda requests. If enableCredentialsDiscovery is also set, this will take precedence as only one may be enabled in Gloo Edge|
 |settings.aws.stsCredentialsRegion|string||Regional endpoint to use for AWS STS requests. If empty will default to global sts endpoint.|