From b179801349ba57a422f0d105d16be9add5f558a9 Mon Sep 17 00:00:00 2001 From: Nadine Spies Date: Thu, 23 May 2024 14:16:07 -0400 Subject: [PATCH 01/11] doc fixes for the week --- changelog/v1.17.0-beta32/doc-fixes.yaml | 5 +++++ .../destination_types/kubernetes_services/_index.md | 7 ++++--- .../installation/advanced_configuration/vault_secrets.md | 8 +++++++- 3 files changed, 16 insertions(+), 4 deletions(-) create mode 100644 changelog/v1.17.0-beta32/doc-fixes.yaml diff --git a/changelog/v1.17.0-beta32/doc-fixes.yaml b/changelog/v1.17.0-beta32/doc-fixes.yaml new file mode 100644 index 00000000000..3a6038e1f8e --- /dev/null +++ b/changelog/v1.17.0-beta32/doc-fixes.yaml @@ -0,0 +1,5 @@ +changelog: + - type: NON_USER_FACING + description: >- + Weekly doc fixes such as links, grammar, typos, and version updates. + skipCI-kube-tests:true \ No newline at end of file diff --git a/docs/content/guides/traffic_management/destination_types/kubernetes_services/_index.md b/docs/content/guides/traffic_management/destination_types/kubernetes_services/_index.md index 09125dbd123..95ff970b8b8 100644 --- a/docs/content/guides/traffic_management/destination_types/kubernetes_services/_index.md +++ b/docs/content/guides/traffic_management/destination_types/kubernetes_services/_index.md @@ -8,18 +8,19 @@ To allow for optimal performance in Gloo Edge, it is recommended to use Gloo [st ## Option 1: Route to a Kubernetes service directly -You can configure your VirtualService to route to a Kubernetes service instead of a Gloo Upstream. +You can configure your VirtualService to route to a Kubernetes service (`routeAction.kube`) instead of a Gloo Upstream. {{% 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. +- 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. Creating in-memory Upstream resources is automatically done if you set `disableKubernetesDestinations: false` in your Settings resource. +- 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 as each Kubernetes destination is added as an Envoy cluster to the proxy. In addition, each Kubernetes endpoint and cluster is synced to all the proxies in the cluster. Because of that, the API snapshot and proxy size increase, which can have a negative impact on the Gloo Edge translation and reconciliation 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. +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`, you cannot route to a Kubernetes service directly as the in-memory Upstream resources do not exist in your cluster. Follow the [upgrade guide]({{% versioned_link_path fromRoot="/operations/upgrading/" %}}) and set `settings.disableKubernetesDestinations: false` in your Helm chart to let Gloo Edge create the resources for you. ```sh kubectl get settings default -n gloo-system -o yaml ``` diff --git a/docs/content/installation/advanced_configuration/vault_secrets.md b/docs/content/installation/advanced_configuration/vault_secrets.md index 4e737b2e50e..4f390490770 100644 --- a/docs/content/installation/advanced_configuration/vault_secrets.md +++ b/docs/content/installation/advanced_configuration/vault_secrets.md @@ -27,6 +27,11 @@ Edit the `default` settings resource so Gloo Edge reads and writes secrets using * Remove the existing `kubernetesSecretSource`, `vaultSecretSource`, or `directorySecretSource` field, which directs the gateway to use secret stores other than Vault. * Add the `secretOptions` section with a Kubernetes source and a Vault source specified to enable secrets to be read from both Kubernetes and Vault. * Add the `refreshRate` field to configure the polling rate at which we watch for changes in Vault secrets and the local filesystem of where Gloo Edge runs. + + {{< notice note >}} + If you specify both a Kubernetes and Vault secret source in your Settings resource, the Kubernetes secret is looked up first. Keep in mind that when you specify multiple secret sources, the name and namespace of each secret must be unique to avoid unanticipated behavior. + {{< /notice >}} + {{< highlight yaml "hl_lines=16-27" >}} apiVersion: gloo.solo.io/v1 kind: Settings @@ -52,12 +57,13 @@ Edit the `default` settings resource so Gloo Edge reads and writes secrets using # Add the address that your Vault instance is routeable on address: http://vault:8200 accessToken: root + - kubernetesSecrets: {} # Add the refresh rate for polling config backends for changes # This setting is used for watching vault secrets and by other resource clients refreshRate: 15s requestTimeout: 0.5s {{< /highlight >}} - + For the full list of options for Gloo Edge Settings, including the ability to set auth/TLS parameters for Vault, see the {{< protobuf name="gloo.solo.io.Settings" display="v1.Settings API reference">}}. An example using AWS IAM auth might look like the following: From 97c3f957cca4b3a6e92f370b335e8cf5ae22b61b Mon Sep 17 00:00:00 2001 From: Nadine Spies Date: Fri, 24 May 2024 10:00:40 -0400 Subject: [PATCH 02/11] clarification for kube services --- .../kubernetes_services/_index.md | 11 ++++---- .../production_deployment/_index.md | 27 ++++++++++++++++--- 2 files changed, 29 insertions(+), 9 deletions(-) diff --git a/docs/content/guides/traffic_management/destination_types/kubernetes_services/_index.md b/docs/content/guides/traffic_management/destination_types/kubernetes_services/_index.md index 95ff970b8b8..d548eb9d395 100644 --- a/docs/content/guides/traffic_management/destination_types/kubernetes_services/_index.md +++ b/docs/content/guides/traffic_management/destination_types/kubernetes_services/_index.md @@ -8,14 +8,13 @@ To allow for optimal performance in Gloo Edge, it is recommended to use Gloo [st ## Option 1: Route to a Kubernetes service directly -You can configure your VirtualService to route to a Kubernetes service (`routeAction.kube`) instead of a Gloo Upstream. +You can configure your VirtualService to route to a Kubernetes service (`routeAction.single.kube`) instead of a Gloo Upstream (`routeAction.single.upstream`). {{% 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. Creating in-memory Upstream resources is automatically done if you set `disableKubernetesDestinations: false` in your Settings resource. -- 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 as each Kubernetes destination is added as an Envoy cluster to the proxy. In addition, each Kubernetes endpoint and cluster is synced to all the proxies in the cluster. Because of that, the API snapshot and proxy size increase, which can have a negative impact on the Gloo Edge translation and reconciliation 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. +- 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. Creating in-memory Upstream resources is automatically done for you if you set `disableKubernetesDestinations: false` in your Settings resource. +- 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 as each Kubernetes destination is added as an Envoy cluster to each proxy in the cluster. Because of that, the API snapshot and proxy size increase, which can have a negative impact on the Gloo Edge translation and reconciliation time. In production deployments, it is therefore recommended to remove in-memory Upstream resources by setting `disableKubernetesDestinations: true`. For more information, see [Disable Kubernetes destinations]({{< versioned_link_path fromRoot="/operations/production_deployment/#disable-kubernetes-destinations" >}}). +- Some Gloo Edge functionality, such as outlier detection policies or customizing load balancing modes, might not be available when using Kubernetes services as a routing destination. {{% /notice %}} To use Kubernetes services as a routing destination: @@ -47,7 +46,7 @@ routes: ## 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. +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. To use Kubernetes Upstream resources: diff --git a/docs/content/operations/production_deployment/_index.md b/docs/content/operations/production_deployment/_index.md index 07a1b083b03..e3aa15a596b 100644 --- a/docs/content/operations/production_deployment/_index.md +++ b/docs/content/operations/production_deployment/_index.md @@ -52,9 +52,18 @@ When you use header manipulation to add headers to or from requests and response ## Performance tips ### Disable Kubernetes destinations -Gloo Edge routes to upstreams by default, but it can alternatively be configured to bypass upstreams and route directly to Kubernetes destinations. Because routing to upstreams is the recommended configuration, you can disable the option to route to the Kubernetes destinations with the `settings.disableKubernetesDestinations: true` setting. This setting saves memory because the Gloo Edge pod doesn't cache both upstreams and Kubernetes destinations. +When you install Gloo Edge, the Settings resource is configured with `disableKubernetesDestinations: false` by default. This setting allows you to use both a Kubernetes service (`routeAction.single.kube`) or Upstream (`routeAction.single.upstream`) as a routing destination in your VirtualService. To enable routing to a Kubernetes service destination, Gloo Edge must scan all services in the cluster to create in-memory Upstream resources to represent them. Gloo Edge uses these in-memory resources to validate that the destination is valid and returns an error if the specified Kubernetes service cannot be found. -You can set this value in the default `Settings` CR by adding the following content: +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 as each Kubernetes destination is added as an Envoy cluster to each proxy in the cluster. Because of that, the API snapshot and proxy size increase, which can have a negative impact on the Gloo Edge translation and reconciliation time. + +In production deployments, it is therefore recommended to remove in-memory Upstream resources by setting `disableKubernetesDestinations: true` in your Gloo Edge deployment. This setting decreases the size of the API snapshot and proxy, and improves translation and reciliation time in Gloo Edge. + +{{% notice note %}} +When setting `disableKubernetesDestinations: true`, Kubernetes service destinations (`routeAction.single.kube`) cannot be used as the in-memory Upstream resources that represent the Kubernetes service do not exist in your cluster. You must use Upstream destinations in your VirtualService instead (`routeAction.single.upstream`). +{{% /notice %}} + + +You can set `disableKubernetesDestinations: true` in the default `Settings` CR by adding the following content: ```yaml apiVersion: gloo.solo.io/v1 kind: Settings @@ -67,12 +76,24 @@ spec: ... ``` -You can set this value in your Helm overrides file by adding the following setting: +You can set `disableKubernetesDestinations: true` in your Helm overrides file by adding the following setting: ```yaml settings: disableKubernetesDestinations: true ``` +In your VirtualService make sure to use Upstreams as your routing destination: +{{< highlight yaml "hl_lines=4-8" >}} +routes: +- matchers: + - prefix: /petstore + routeAction: + single: + upstream: + name: petstore + namespace: gloo-system +{{< /highlight >}} + ### Configure appropriate resource usage From ef3ef4043d45684c28231ded5dffc5f6ecb2c202 Mon Sep 17 00:00:00 2001 From: Nadine Spies Date: Fri, 24 May 2024 10:13:50 -0400 Subject: [PATCH 03/11] remove note --- docs/content/_index.md | 1 - 1 file changed, 1 deletion(-) diff --git a/docs/content/_index.md b/docs/content/_index.md index 03aae44a7cb..0dcab2060f6 100644 --- a/docs/content/_index.md +++ b/docs/content/_index.md @@ -5,7 +5,6 @@ title: Gloo Edge # An Envoy-Powered API Gateway -{{% notice note %}}[Gloo Gateway](https://docs.solo.io/gloo-gateway) is the latest open source-based, API gateway product by Solo.io. As part of Gloo Platform, you get observability, multitenancy, and multicluster support from Day 1, alongside seamless integration with Gloo Mesh and Gloo Network. Still want the Envoy-based Gloo Edge API gateway? Continue reading these docs!{{% /notice %}} ## What is Gloo Edge From 67915d4d2d446ff0f791e14786d0e7e7836256b3 Mon Sep 17 00:00:00 2001 From: Nadine Spies Date: Fri, 24 May 2024 10:20:36 -0400 Subject: [PATCH 04/11] version bumps --- docs/content/static/content/version_geoss_latest.md | 2 +- docs/content/static/content/version_geoss_n+1.md | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/content/static/content/version_geoss_latest.md b/docs/content/static/content/version_geoss_latest.md index be8bdd470c9..3b29464e91c 100644 --- a/docs/content/static/content/version_geoss_latest.md +++ b/docs/content/static/content/version_geoss_latest.md @@ -1 +1 @@ -1.16.13 \ No newline at end of file +1.16.14 \ No newline at end of file diff --git a/docs/content/static/content/version_geoss_n+1.md b/docs/content/static/content/version_geoss_n+1.md index 8f42e2c3769..24db66130c9 100644 --- a/docs/content/static/content/version_geoss_n+1.md +++ b/docs/content/static/content/version_geoss_n+1.md @@ -1 +1 @@ -1.17.0-beta28 \ No newline at end of file +1.17.0-beta32 \ No newline at end of file From f2b442ab1bb0a71d6689a02b9e38e72c11153e51 Mon Sep 17 00:00:00 2001 From: Nadine Spies <17709352+Nadine2016@users.noreply.github.com> Date: Fri, 24 May 2024 10:57:07 -0400 Subject: [PATCH 05/11] Rename doc-fixes.yaml to doc-fixes.yaml --- changelog/{v1.17.0-beta32 => v1.17.0-beta33}/doc-fixes.yaml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename changelog/{v1.17.0-beta32 => v1.17.0-beta33}/doc-fixes.yaml (82%) diff --git a/changelog/v1.17.0-beta32/doc-fixes.yaml b/changelog/v1.17.0-beta33/doc-fixes.yaml similarity index 82% rename from changelog/v1.17.0-beta32/doc-fixes.yaml rename to changelog/v1.17.0-beta33/doc-fixes.yaml index 3a6038e1f8e..bd16bb945c5 100644 --- a/changelog/v1.17.0-beta32/doc-fixes.yaml +++ b/changelog/v1.17.0-beta33/doc-fixes.yaml @@ -2,4 +2,4 @@ changelog: - type: NON_USER_FACING description: >- Weekly doc fixes such as links, grammar, typos, and version updates. - skipCI-kube-tests:true \ No newline at end of file + skipCI-kube-tests:true From 969c6172fca17fe297bbb26d460c15199844e8f1 Mon Sep 17 00:00:00 2001 From: Nadine Spies Date: Fri, 24 May 2024 16:38:02 -0400 Subject: [PATCH 06/11] update vault secrets --- .../advanced_configuration/vault_secrets.md | 41 ++++++++++++++++--- 1 file changed, 36 insertions(+), 5 deletions(-) diff --git a/docs/content/installation/advanced_configuration/vault_secrets.md b/docs/content/installation/advanced_configuration/vault_secrets.md index 4f390490770..78a6bff829b 100644 --- a/docs/content/installation/advanced_configuration/vault_secrets.md +++ b/docs/content/installation/advanced_configuration/vault_secrets.md @@ -25,14 +25,16 @@ Edit the `default` settings resource so Gloo Edge reads and writes secrets using 2. Make the following changes to the resource. * Remove the existing `kubernetesSecretSource`, `vaultSecretSource`, or `directorySecretSource` field, which directs the gateway to use secret stores other than Vault. - * Add the `secretOptions` section with a Kubernetes source and a Vault source specified to enable secrets to be read from both Kubernetes and Vault. + * Add the `secretOptions` section and define either a Kubernetes or Vault secret source. + {{< notice note >}} + If you specify both a Kubernetes and Vault secret source in your Settings resource, the Kubernetes secret is looked up first. Keep in mind that when you specify multiple secret sources, the name and namespace of each secret must be unique to avoid unanticipated behavior. + {{< /notice >}} * Add the `refreshRate` field to configure the polling rate at which we watch for changes in Vault secrets and the local filesystem of where Gloo Edge runs. - {{< notice note >}} - If you specify both a Kubernetes and Vault secret source in your Settings resource, the Kubernetes secret is looked up first. Keep in mind that when you specify multiple secret sources, the name and namespace of each secret must be unique to avoid unanticipated behavior. - {{< /notice >}} + {{< tabs >}} + {{% tab name="Vault" %}} - {{< highlight yaml "hl_lines=16-27" >}} + {{< highlight yaml "hl_lines=18-24" >}} apiVersion: gloo.solo.io/v1 kind: Settings metadata: @@ -57,12 +59,41 @@ Edit the `default` settings resource so Gloo Edge reads and writes secrets using # Add the address that your Vault instance is routeable on address: http://vault:8200 accessToken: root + # Add the refresh rate for polling config backends for changes + # This setting is used for watching vault secrets and by other resource clients + refreshRate: 15s + requestTimeout: 0.5s + {{< /highlight >}} + {{% /tab %}} + {{% tab name="Kubernetes secret" %}} + {{< highlight yaml "hl_lines=18-20" >}} + apiVersion: gloo.solo.io/v1 + kind: Settings + metadata: + name: default + namespace: gloo-system + spec: + discoveryNamespace: gloo-system + gateway: + validation: + alwaysAccept: true + proxyValidationServerAddr: gloo:9988 + gloo: + xdsBindAddr: 0.0.0.0:9977 + kubernetesArtifactSource: {} + kubernetesConfigSource: {} + # Delete or comment out the existing *SecretSource field + #kubernetesSecretSource: {} + secretOptions: + sources: - kubernetesSecrets: {} # Add the refresh rate for polling config backends for changes # This setting is used for watching vault secrets and by other resource clients refreshRate: 15s requestTimeout: 0.5s {{< /highlight >}} + {{% /tab %}} + {{< /tabs >}} For the full list of options for Gloo Edge Settings, including the ability to set auth/TLS parameters for Vault, see the {{< protobuf name="gloo.solo.io.Settings" display="v1.Settings API reference">}}. From 2760f2131b8c401b4b0a309823ea71144b16b06d Mon Sep 17 00:00:00 2001 From: Nadine Spies Date: Fri, 24 May 2024 16:57:18 -0400 Subject: [PATCH 07/11] kube services clarifications --- .../kubernetes_services/_index.md | 8 ++++---- .../static_upstream/_index.md | 18 ++++++++++++++++++ 2 files changed, 22 insertions(+), 4 deletions(-) diff --git a/docs/content/guides/traffic_management/destination_types/kubernetes_services/_index.md b/docs/content/guides/traffic_management/destination_types/kubernetes_services/_index.md index d548eb9d395..51e79a22b6b 100644 --- a/docs/content/guides/traffic_management/destination_types/kubernetes_services/_index.md +++ b/docs/content/guides/traffic_management/destination_types/kubernetes_services/_index.md @@ -8,12 +8,12 @@ To allow for optimal performance in Gloo Edge, it is recommended to use Gloo [st ## Option 1: Route to a Kubernetes service directly -You can configure your VirtualService to route to a Kubernetes service (`routeAction.single.kube`) instead of a Gloo Upstream (`routeAction.single.upstream`). +You can configure your VirtualService to route to a Kubernetes service (`routeAction.single.kube`) directly instead of using Upstream resources. {{% 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. Creating in-memory Upstream resources is automatically done for you if you set `disableKubernetesDestinations: false` in your Settings resource. -- 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 as each Kubernetes destination is added as an Envoy cluster to each proxy in the cluster. Because of that, the API snapshot and proxy size increase, which can have a negative impact on the Gloo Edge translation and reconciliation time. In production deployments, it is therefore recommended to remove in-memory Upstream resources by setting `disableKubernetesDestinations: true`. For more information, see [Disable Kubernetes destinations]({{< versioned_link_path fromRoot="/operations/production_deployment/#disable-kubernetes-destinations" >}}). +- Gloo Edge uses these resources to validate that the 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 as each Kubernetes destination is added as an Envoy cluster to each proxy in the cluster. Because of that, the API snapshot and proxy size increase, which can have a negative impact on the Gloo Edge translation and reconciliation time. In production deployments, it is therefore recommended to remove in-memory Upstream resources by setting `disableKubernetesDestinations: true`. For more information, see [Disable Kubernetes destinations]({{< versioned_link_path fromRoot="/operations/production_deployment/#disable-kubernetes-destinations" >}}). - Some Gloo Edge functionality, such as outlier detection policies or customizing load balancing modes, might not be available when using Kubernetes services as a routing destination. {{% /notice %}} @@ -50,7 +50,7 @@ Instead of routing to a Kubernetes service directly, you can create [Gloo Kubern 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. +1. Create an upstream resource for your Kubernetes 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 @@ -64,7 +64,7 @@ To use Kubernetes Upstream resources: 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. +2. Configure the 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: diff --git a/docs/content/guides/traffic_management/destination_types/static_upstream/_index.md b/docs/content/guides/traffic_management/destination_types/static_upstream/_index.md index a41b0fa5778..e33cfa58e35 100644 --- a/docs/content/guides/traffic_management/destination_types/static_upstream/_index.md +++ b/docs/content/guides/traffic_management/destination_types/static_upstream/_index.md @@ -6,6 +6,24 @@ description: Routing to explicitly and statically defined Upstreams Let's configure Gloo Edge to route to a single, static Upstream. In this case, we'll route requests through Gloo Edge to the JSON testing API available at `http://jsonplaceholder.typicode.com/`. +{{% notice note %}} +When you create a static upstream resource that points to a Kubernetes service address, such as in the following example, Gloo Edge relies on `kube-proxy` to perform load balancing which might impact performance. To avoid performance impacts, you can use [dynamic Upstreams]({{% versioned_link_path fromRoot="/guides/traffic_management/destination_types/discovered_upstream/" %}}) or manually create upstream resources that use label selectors to find the backing destination. + +```yaml +apiVersion: gloo.solo.io/v1 +kind: Upstream +metadata: + name: httpbin-httpbin-static-8000 + namespace: gloo-deployments +spec: + static: + hosts: + - addr: httpbin.httpbin.svc.cluster.local + port: 8000 +``` +{{% /notice %}} + + {{< readfile file="/static/content/setup_notes" markdown="true">}} ## Create Upstream From 47f87ff9c14c4c78ad029d5decb121c002847ef9 Mon Sep 17 00:00:00 2001 From: Nadine Spies <17709352+Nadine2016@users.noreply.github.com> Date: Tue, 28 May 2024 09:14:26 -0400 Subject: [PATCH 08/11] Update docs/content/installation/advanced_configuration/vault_secrets.md Co-authored-by: Jacob Bohanon --- .../installation/advanced_configuration/vault_secrets.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/content/installation/advanced_configuration/vault_secrets.md b/docs/content/installation/advanced_configuration/vault_secrets.md index 78a6bff829b..3a0c743c990 100644 --- a/docs/content/installation/advanced_configuration/vault_secrets.md +++ b/docs/content/installation/advanced_configuration/vault_secrets.md @@ -86,7 +86,7 @@ Edit the `default` settings resource so Gloo Edge reads and writes secrets using #kubernetesSecretSource: {} secretOptions: sources: - - kubernetesSecrets: {} + - kubernetes: {} # Add the refresh rate for polling config backends for changes # This setting is used for watching vault secrets and by other resource clients refreshRate: 15s From 40ff2c145c6e8d218378912e18fa38f9b150098b Mon Sep 17 00:00:00 2001 From: Nadine Spies <17709352+Nadine2016@users.noreply.github.com> Date: Tue, 28 May 2024 09:14:55 -0400 Subject: [PATCH 09/11] Update docs/content/guides/traffic_management/destination_types/kubernetes_services/_index.md Co-authored-by: Jacob Bohanon --- .../destination_types/kubernetes_services/_index.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/content/guides/traffic_management/destination_types/kubernetes_services/_index.md b/docs/content/guides/traffic_management/destination_types/kubernetes_services/_index.md index 51e79a22b6b..1280b3e5ff2 100644 --- a/docs/content/guides/traffic_management/destination_types/kubernetes_services/_index.md +++ b/docs/content/guides/traffic_management/destination_types/kubernetes_services/_index.md @@ -50,7 +50,7 @@ Instead of routing to a Kubernetes service directly, you can create [Gloo Kubern To use Kubernetes Upstream resources: -1. Create an upstream resource for your Kubernetes workload. The following configuration creates an upstream resource for the Petstore app that listens on port 8080 in the default namespace. +1. Create an Upstream resource for your Kubernetes 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 From d07d7612d3cb41ab76b3f8b5d71de90f990c61e0 Mon Sep 17 00:00:00 2001 From: Nadine Spies <17709352+Nadine2016@users.noreply.github.com> Date: Tue, 28 May 2024 09:16:52 -0400 Subject: [PATCH 10/11] Update docs/content/installation/advanced_configuration/vault_secrets.md Co-authored-by: Jacob Bohanon --- .../installation/advanced_configuration/vault_secrets.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/content/installation/advanced_configuration/vault_secrets.md b/docs/content/installation/advanced_configuration/vault_secrets.md index 3a0c743c990..99a05c768ca 100644 --- a/docs/content/installation/advanced_configuration/vault_secrets.md +++ b/docs/content/installation/advanced_configuration/vault_secrets.md @@ -25,7 +25,7 @@ Edit the `default` settings resource so Gloo Edge reads and writes secrets using 2. Make the following changes to the resource. * Remove the existing `kubernetesSecretSource`, `vaultSecretSource`, or `directorySecretSource` field, which directs the gateway to use secret stores other than Vault. - * Add the `secretOptions` section and define either a Kubernetes or Vault secret source. + * Add the `secretOptions` section and define a Vault secret source. Optionally, a Kubernetes and/or a Directory secret source can also be specified. {{< notice note >}} If you specify both a Kubernetes and Vault secret source in your Settings resource, the Kubernetes secret is looked up first. Keep in mind that when you specify multiple secret sources, the name and namespace of each secret must be unique to avoid unanticipated behavior. {{< /notice >}} From 5333d5301192417652aedccfefc274e8557a2ce5 Mon Sep 17 00:00:00 2001 From: Nadine Spies <17709352+Nadine2016@users.noreply.github.com> Date: Tue, 28 May 2024 09:20:43 -0400 Subject: [PATCH 11/11] Update vault_secrets.md --- .../advanced_configuration/vault_secrets.md | 37 +------------------ 1 file changed, 2 insertions(+), 35 deletions(-) diff --git a/docs/content/installation/advanced_configuration/vault_secrets.md b/docs/content/installation/advanced_configuration/vault_secrets.md index 99a05c768ca..aa2bbb0137a 100644 --- a/docs/content/installation/advanced_configuration/vault_secrets.md +++ b/docs/content/installation/advanced_configuration/vault_secrets.md @@ -25,15 +25,12 @@ Edit the `default` settings resource so Gloo Edge reads and writes secrets using 2. Make the following changes to the resource. * Remove the existing `kubernetesSecretSource`, `vaultSecretSource`, or `directorySecretSource` field, which directs the gateway to use secret stores other than Vault. - * Add the `secretOptions` section and define a Vault secret source. Optionally, a Kubernetes and/or a Directory secret source can also be specified. + * Add the `secretOptions` section and define a Vault secret source as shown in this guide. Optionally, a Kubernetes and/or a Directory secret source can also be specified. {{< notice note >}} If you specify both a Kubernetes and Vault secret source in your Settings resource, the Kubernetes secret is looked up first. Keep in mind that when you specify multiple secret sources, the name and namespace of each secret must be unique to avoid unanticipated behavior. {{< /notice >}} * Add the `refreshRate` field to configure the polling rate at which we watch for changes in Vault secrets and the local filesystem of where Gloo Edge runs. - {{< tabs >}} - {{% tab name="Vault" %}} - {{< highlight yaml "hl_lines=18-24" >}} apiVersion: gloo.solo.io/v1 kind: Settings @@ -62,38 +59,8 @@ Edit the `default` settings resource so Gloo Edge reads and writes secrets using # Add the refresh rate for polling config backends for changes # This setting is used for watching vault secrets and by other resource clients refreshRate: 15s - requestTimeout: 0.5s - {{< /highlight >}} - {{% /tab %}} - {{% tab name="Kubernetes secret" %}} - {{< highlight yaml "hl_lines=18-20" >}} - apiVersion: gloo.solo.io/v1 - kind: Settings - metadata: - name: default - namespace: gloo-system - spec: - discoveryNamespace: gloo-system - gateway: - validation: - alwaysAccept: true - proxyValidationServerAddr: gloo:9988 - gloo: - xdsBindAddr: 0.0.0.0:9977 - kubernetesArtifactSource: {} - kubernetesConfigSource: {} - # Delete or comment out the existing *SecretSource field - #kubernetesSecretSource: {} - secretOptions: - sources: - - kubernetes: {} - # Add the refresh rate for polling config backends for changes - # This setting is used for watching vault secrets and by other resource clients - refreshRate: 15s - requestTimeout: 0.5s + {{< /highlight >}} - {{% /tab %}} - {{< /tabs >}} For the full list of options for Gloo Edge Settings, including the ability to set auth/TLS parameters for Vault, see the {{< protobuf name="gloo.solo.io.Settings" display="v1.Settings API reference">}}.