You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
## Configuring retries for unresponsive passthrough services
214
+
215
+
You can configure the Gloo ExtAuth server to retry the connection to the passthrough service in the case that the passthrough service becomes unavailable. Consider the following two scenarios to learn more about how retries to the passthrough service are executed:
216
+
217
+
218
+
* **Passthrough service becomes unavailable after initial connection**: In this scenario, the Gloo ExtAuth server successfully established an initial connection to the passthrough service. However later on, the passthrough service becomes unavailable. You can add a retry policy to your AuthConfig to retry the connection to the passthrough service if the service becomes unavailable. In the following AuthConfig, the Gloo ExtAuth server is configured to retry the connection to the passthrough service 10 times. To not overload the passthrough service, an optional exponential backoff strategy is defined. The backoff strategy configures the ExtAuth server to start retries after 1 second (`baseInterval`). Retries are then executed exponentially, such as after 2 seconds, 4 seconds, 8 seconds, etc up to the `maxInterval` that defaults to 10 times the `baseInterval`. In this example, the `maxInterval` configures a maximum delay of 2 seconds between retries. Note that the global settings `global.extensions.extAuth.requestTimeout` must be greater than the `retryPolicy.numRetries` * `retryPolicy.retryBackOff.baseInterval` to ensure that the failed gRPC call has sufficient time to retry.
219
+
220
+
For more information, see the [API docs]({{< versioned_link_path fromRoot="/reference/api/github.com/solo-io/gloo/projects/gloo/api/v1/enterprise/options/extauth/v1/extauth.proto.sk/#retrypolicy" >}}).
# Set a connection timeout to external service, default is 5 seconds
235
+
connectionTimeout: 3s
236
+
retryPolicy:
237
+
numRetries: 10
238
+
retryBackOff:
239
+
baseInterval: 1s
240
+
maxInterval: 2s
241
+
{{< /highlight >}}
242
+
243
+
244
+
***Passthrough service is unavailable during the initial connection**: When you configure your AuthConfig with a retry policy, auth requests are retried only after the initial connection between the Gloo auth server and passthrough service is established successfully. If establishing the initial connection fails, the ExtAuth server retries the connection up to the defined `connectionTimeout` in the AuthConfig. The settings in the retry policy are ignored and any auth requests that are sent to the ExtAuth server during that time fail immediately. Auth requests continue to fail when the `connectionTimeout` is reached, even if the passthrough service becomes available afterwards. To mitigate this issue, you can try increasing the `connectionTimeout` setting if you think that your passthrough service can recover and become available within the specified connection timeout.
245
+
246
+
213
247
## Sharing state with other auth steps
214
248
215
249
{{% notice note %}}
@@ -260,4 +294,4 @@ This config is accessible via the [CheckRequest FilterMetadata](https://github.c
260
294
261
295
## Summary
262
296
263
-
In this guide, we installed Gloo Edge Enterprise and created an unauthenticated Virtual Service that routes requests to a static upstream. We spun up an example gRPC authentication service that uses a simple header for authentication. We then created an `AuthConfig` and configured it to use Passthrough Auth, pointing it to the IP of our example gRPC service. In doing so, we instructed gloo to pass through requests from the external authentication server to the grpc authentication service provided by the user.
297
+
In this guide, we installed Gloo Edge Enterprise and created an unauthenticated Virtual Service that routes requests to a static upstream. We spun up an example gRPC authentication service that uses a simple header for authentication. We then created an `AuthConfig` and configured it to use Passthrough Auth, pointing it to the IP of our example gRPC service. In doing so, we instructed gloo to pass through requests from the external authentication server to the grpc authentication service provided by the user.
Copy file name to clipboardexpand all lines: docs/content/guides/traffic_management/destination_types/kubernetes_services/_index.md
+59-9
Original file line number
Diff line number
Diff line change
@@ -4,17 +4,28 @@ weight: 80
4
4
description: Routing to services registered as Kubernetes Services through the API
5
5
---
6
6
7
-
If you are running Gloo Edge in a Kubernetes cluster, it is possible to directly specify
8
-
[Kubernetes Services](https://kubernetes.io/docs/concepts/services-networking/service/) as routing destinations.
9
-
The `kube` destination type has two required fields:
7
+
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:
10
8
11
-
*`ref` is a {{< protobuf name="core.solo.io.ResourceRef">}} to the service that should receive traffic
12
-
*`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
9
+
## Option 1: Route to a Kubernetes service directly
13
10
14
-
The following configuration will forward all requests to `/petstore` to port `8080` on the Kubernetes service named
15
-
`petstore` in the `default` namespace.
11
+
You can configure your VirtualService to route to a Kubernetes service instead of a Gloo Upstream.
16
12
17
-
{{< highlight yaml "hl_lines=6-10" >}}
13
+
{{% notice note %}}
14
+
Consider the following information before choosing a Kubernetes service as your routing destination:
15
+
- 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.
16
+
- 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.
17
+
- Some Gloo Edge functionality, such as policies, might not be available when using Kubernetes services as a routing destination.
18
+
{{% /notice %}}
19
+
20
+
To use Kubernetes services as a routing destination:
21
+
22
+
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.
23
+
```sh
24
+
kubectl get settings default -n gloo-system -o yaml
25
+
```
26
+
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.
27
+
28
+
{{< highlight yaml "hl_lines=6-10" >}}
18
29
routes:
19
30
- matchers:
20
31
- prefix: /petstore
@@ -25,4 +36,43 @@ routes:
25
36
name: petstore
26
37
namespace: default
27
38
port: 8080
28
-
{{< /highlight >}}
39
+
{{< /highlight >}}
40
+
41
+
The `kube` destination type has two required fields:
42
+
43
+
*`ref` is a {{< protobuf name="core.solo.io.ResourceRef">}} to the service that receives the traffic.
44
+
*`port` is an integer (`int`) and represents the port the service listens on. Note that this port must be defined in the Kubernetes service.
45
+
46
+
47
+
## Option 2: Use Kubernetes Upstream resources
48
+
49
+
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.
50
+
51
+
To use Kubernetes Upstream resources:
52
+
53
+
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.
54
+
```yaml
55
+
apiVersion: gloo.solo.io/v1
56
+
kind: Upstream
57
+
metadata:
58
+
name: petstore
59
+
namespace: gloo-system
60
+
spec:
61
+
kube:
62
+
serviceName: petstore
63
+
serviceNamespace: default
64
+
servicePort: 8080
65
+
```
66
+
67
+
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.
Copy file name to clipboardexpand all lines: docs/content/installation/advanced_configuration/wasm.md
+8-26
Original file line number
Diff line number
Diff line change
@@ -20,36 +20,24 @@ The [upstream Envoy Wasm filter](https://www.envoyproxy.io/docs/envoy/latest/con
20
20
21
21
WebAssembly provides a safe, secure, and dynamic way of extending infrastructure with the programming language of your choice.
22
22
23
-
1. Get a Wasm image. Review the following resources to help.
24
-
*[WebAssembly Hub](https://webassemblyhub.io/repositories/) to use an existing Wasm image repository.
25
-
*[WebAssembly Developer's Guide](https://webassembly.org/getting-started/developers-guide/) for more information on building your own Wasm image.
26
-
*[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.
27
-
28
-
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. 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/).
38
24
39
25
2. Prepare your Wasm image for use with Gloo Edge Enterprise. Review the following options.
40
-
***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>`.
41
-
***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`.
42
-
***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`.
26
+
27
+
* Store in an OCI-compliant image repository. This guide uses an example Wasm image from Solo's public Google Container Registry.
28
+
* 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`.
29
+
* 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`.
43
30
44
31
## Configure Gloo Edge to use a Wasm filter {#configuration}
45
32
46
33
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"%}}.
47
34
48
35
{{< tabs >}}
49
-
{{% tab name="From WebAssembly Hub" %}}
36
+
{{% tab name="From an image registry" %}}
50
37
1. Get the configuration for your `gateway-proxy` gateway.
51
38
```shell
52
39
kubectl get -n gloo-system gateways.gateway.solo.io gateway-proxy -o yaml > gateway-proxy.yaml
40
+
open gateway-proxy.yaml
53
41
```
54
42
2. Add the reference to your Wasm filter in the `httpGateway` section as follows.
55
43
```yaml
@@ -60,7 +48,7 @@ Now that Gloo Edge Enterprise is installed and you have your Wasm image, you are
*[WebAssembly Hub](https://webassemblyhub.io/) for sharing and reusing Wasm filters.
248
-
*[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.
249
-
*[Solo's `wasm` GitHub repo](https://github.com/solo-io/wasm) for the `wasme` tool.
0 commit comments