diff --git a/changelog/v1.14.30/docs-rm-wasm.yaml b/changelog/v1.14.30/docs-rm-wasm.yaml new file mode 100644 index 00000000000..a2a3e15e57c --- /dev/null +++ b/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 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 ee7e096480f..09125dbd123 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 @@ -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 >}} diff --git a/docs/content/installation/advanced_configuration/wasm.md b/docs/content/installation/advanced_configuration/wasm.md index a6368cc3917..98d6b6fde54 100644 --- a/docs/content/installation/advanced_configuration/wasm.md +++ b/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//:`. - * **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 `/.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 `/.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. diff --git a/docs/content/reference/api/github.com/solo-io/gloo/projects/gloo/api/v1/settings.proto.sk.md b/docs/content/reference/api/github.com/solo-io/gloo/projects/gloo/api/v1/settings.proto.sk.md index 54fa55a3a19..187fc23816e 100644 --- a/docs/content/reference/api/github.com/solo-io/gloo/projects/gloo/api/v1/settings.proto.sk.md +++ b/docs/content/reference/api/github.com/solo-io/gloo/projects/gloo/api/v1/settings.proto.sk.md @@ -710,7 +710,7 @@ Settings specific to the gloo (Envoy xDS server) controller | `endpointsWarmingTimeout` | [.google.protobuf.Duration](https://developers.google.com/protocol-buffers/docs/reference/csharp/class/google/protobuf/well-known-types/duration) | Timeout to get initial snapshot of resources. If set to zero, Gloo will not wait for initial snapshot - if nonzero and gloo could not fetch it's initial snapshot before the timeout reached, gloo will panic. If unset, Gloo defaults to 5 minutes. | | `awsOptions` | [.gloo.solo.io.GlooOptions.AWSOptions](../settings.proto.sk/#awsoptions) | | | `invalidConfigPolicy` | [.gloo.solo.io.GlooOptions.InvalidConfigPolicy](../settings.proto.sk/#invalidconfigpolicy) | set these options to fine-tune the way Gloo handles invalid user configuration. | -| `disableKubernetesDestinations` | `bool` | Gloo allows you to directly reference a Kubernetes service as a routing destination. To enable this feature, Gloo 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 is watching, this can result in significant overhead. If you do not plan on using this feature, you can use this flag to turn it off. | +| `disableKubernetesDestinations` | `bool` | 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/). | | `disableGrpcWeb` | [.google.protobuf.BoolValue](https://developers.google.com/protocol-buffers/docs/reference/csharp/class/google/protobuf/well-known-types/bool-value) | Default policy for grpc-web. set to true if you do not wish grpc-web to be automatically enabled. set to false if you wish grpc-web enabled unless disabled on the listener level. If not specified, defaults to `false`. | | `disableProxyGarbageCollection` | [.google.protobuf.BoolValue](https://developers.google.com/protocol-buffers/docs/reference/csharp/class/google/protobuf/well-known-types/bool-value) | Set this option to determine the state of the envoy configuration when a virtual service is deleted, resulting in a proxy with no configured routes. set to true if you wish to keep envoy serving the routes from the latest valid configuration. set to false if you wish to reset the envoy configuration to a clean slate with no routes. If not specified, defaults to `false`. | | `regexMaxProgramSize` | [.google.protobuf.UInt32Value](https://developers.google.com/protocol-buffers/docs/reference/csharp/class/google/protobuf/well-known-types/u-int-32-value) | Set this option to specify the default max program size for regexes. If not specified, defaults to 100. | diff --git a/docs/content/reference/values.txt b/docs/content/reference/values.txt index de71a0f9cd1..c38b200a9f2 100644 --- a/docs/content/reference/values.txt +++ b/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.| diff --git a/install/helm/gloo/generate/values.go b/install/helm/gloo/generate/values.go index c7e2fbf0abd..71e772ca72c 100644 --- a/install/helm/gloo/generate/values.go +++ b/install/helm/gloo/generate/values.go @@ -201,7 +201,7 @@ type Settings struct { Linkerd *bool `json:"linkerd,omitempty" desc:"Enable automatic Linkerd integration in Gloo Edge"` DisableProxyGarbageCollection *bool `json:"disableProxyGarbageCollection,omitempty" desc:"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."` RegexMaxProgramSize *uint32 `json:"regexMaxProgramSize,omitempty" desc:"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."` - DisableKubernetesDestinations *bool `json:"disableKubernetesDestinations,omitempty" desc:"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."` + DisableKubernetesDestinations *bool `json:"disableKubernetesDestinations,omitempty" desc:"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/)."` Aws AwsSettings `json:"aws,omitempty"` RateLimit interface{} `json:"rateLimit,omitempty" desc:"Partial config for Gloo Edge Enterprise’s rate-limiting service, based on Envoy’s rate-limit service; supports Envoy’s rate-limit service API. (reference here: https://github.com/lyft/ratelimit#configuration) Configure rate-limit descriptors here, which define the limits for requests based on their descriptors. Configure rate-limits (composed of actions, which define how request characteristics get translated into descriptors) on the VirtualHost or its routes."` RatelimitServer interface{} `json:"ratelimitServer,omitempty" desc:"External Ratelimit Server configuration for Gloo Edge Open Sources’s rate-limiting service, based on Envoy’s rate-limit service; supports Envoy’s rate-limit service API. (reference here: https://docs.solo.io/gloo-edge/master/guides/security/rate_limiting/)"` diff --git a/projects/gloo/api/v1/settings.proto b/projects/gloo/api/v1/settings.proto index 0a0de70370f..1377d96a52d 100644 --- a/projects/gloo/api/v1/settings.proto +++ b/projects/gloo/api/v1/settings.proto @@ -647,10 +647,16 @@ message GlooOptions { // set these options to fine-tune the way Gloo handles invalid user configuration InvalidConfigPolicy invalid_config_policy = 6; - // Gloo allows you to directly reference a Kubernetes service as a routing destination. To enable this feature, - // Gloo 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 is watching, this can result - // in significant overhead. If you do not plan on using this feature, you can use this flag to turn it off. + // 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/). bool disable_kubernetes_destinations = 7; // Default policy for grpc-web. diff --git a/projects/gloo/pkg/api/v1/settings.pb.go b/projects/gloo/pkg/api/v1/settings.pb.go index e1682209d58..ae5bcd152dc 100644 --- a/projects/gloo/pkg/api/v1/settings.pb.go +++ b/projects/gloo/pkg/api/v1/settings.pb.go @@ -709,10 +709,16 @@ type GlooOptions struct { AwsOptions *GlooOptions_AWSOptions `protobuf:"bytes,5,opt,name=aws_options,json=awsOptions,proto3" json:"aws_options,omitempty"` // set these options to fine-tune the way Gloo handles invalid user configuration InvalidConfigPolicy *GlooOptions_InvalidConfigPolicy `protobuf:"bytes,6,opt,name=invalid_config_policy,json=invalidConfigPolicy,proto3" json:"invalid_config_policy,omitempty"` - // Gloo allows you to directly reference a Kubernetes service as a routing destination. To enable this feature, - // Gloo 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 is watching, this can result - // in significant overhead. If you do not plan on using this feature, you can use this flag to turn it off. + // 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/). DisableKubernetesDestinations bool `protobuf:"varint,7,opt,name=disable_kubernetes_destinations,json=disableKubernetesDestinations,proto3" json:"disable_kubernetes_destinations,omitempty"` // Default policy for grpc-web. // set to true if you do not wish grpc-web to be automatically enabled. diff --git a/test/kube2e/helm/artifacts/helm.yaml b/test/kube2e/helm/artifacts/helm.yaml index b479841753a..c3867c8125a 100644 --- a/test/kube2e/helm/artifacts/helm.yaml +++ b/test/kube2e/helm/artifacts/helm.yaml @@ -34,4 +34,4 @@ gloo: livenessProbeEnabled: true gatewayProxies: gatewayProxy: - healthyPanicThreshold: 0 \ No newline at end of file + healthyPanicThreshold: 0