diff --git a/site/content/en/latest/tasks/extensibility/envoy-patch-policy.md b/site/content/en/latest/tasks/extensibility/envoy-patch-policy.md index 83b95065a82..e32c447e750 100644 --- a/site/content/en/latest/tasks/extensibility/envoy-patch-policy.md +++ b/site/content/en/latest/tasks/extensibility/envoy-patch-policy.md @@ -32,7 +32,8 @@ Before proceeding, you should be able to query the example backend using HTTP. * The default installation of Envoy Gateway installs a default [EnvoyGateway][] configuration and attaches it using a `ConfigMap`. In the next step, we will update this resource to enable EnvoyPatchPolicy. - +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} * After updating the `ConfigMap`, you will need to restart the `envoy-gateway` deployment so the configuration kicks in @@ -68,6 +93,8 @@ the status code is `404` * Apply the configuration +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <// + name: default/eg/http + operation: + op: add + path: "/default_filter_chain/filters/0/typed_config/local_reply_config" + value: + mappers: + - filter: + status_code_filter: + comparison: + op: EQ + value: + default_value: 404 + runtime_key: key_b + status_code: 406 + body: + inline_string: "could not find what you are looking for" +``` +{{% /tab %}} +{{< /tabpane >}} When mergeGateways is enabled, there will be one Envoy deployment for all Gateways in the cluster. Then the EnvoyPatchPolicy should target a specific GatewayClass. +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <// + name: default/eg/http + operation: + op: add + path: "/default_filter_chain/filters/0/typed_config/local_reply_config" + value: + mappers: + - filter: + status_code_filter: + comparison: + op: EQ + value: + default_value: 404 + runtime_key: key_b + status_code: 406 + body: + inline_string: "could not find what you are looking for" +``` +{{% /tab %}} +{{< /tabpane >}} * Edit the HTTPRoute resource from the Quickstart to only match on paths with value `/get` diff --git a/site/content/en/latest/tasks/observability/rate-limit-observability.md b/site/content/en/latest/tasks/observability/rate-limit-observability.md index 350be4dc4b1..26ffe24a9b1 100644 --- a/site/content/en/latest/tasks/observability/rate-limit-observability.md +++ b/site/content/en/latest/tasks/observability/rate-limit-observability.md @@ -35,6 +35,8 @@ You can configure a collector that supports the OTLP protocol, which includes bu Assuming the OpenTelemetry Collector is running in the `observability` namespace, and it has a service named `otel-svc`, we only want to sample `50%` of the trace data. We would configure it as follows: +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} After updating the ConfigMap, you will need to restart the envoy-gateway deployment so the configuration kicks in: diff --git a/site/content/en/latest/tasks/operations/customize-envoyproxy.md b/site/content/en/latest/tasks/operations/customize-envoyproxy.md index 76004a83676..50c2cc26118 100644 --- a/site/content/en/latest/tasks/operations/customize-envoyproxy.md +++ b/site/content/en/latest/tasks/operations/customize-envoyproxy.md @@ -15,6 +15,8 @@ Before proceeding, you should be able to query the example backend using HTTP. First, you need to add ParametersRef in GatewayClass, and refer to EnvoyProxy Config: +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} ## Customize EnvoyProxy Deployment Replicas You can customize the EnvoyProxy Deployment Replicas via EnvoyProxy Config like: +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} After you apply the config, you should see the replicas of envoyproxy changes to 2. And also you can dynamically change the value. @@ -62,6 +106,8 @@ kubectl get deployment -l gateway.envoyproxy.io/owning-gateway-name=eg -n envoy- You can customize the EnvoyProxy Image via EnvoyProxy Config like: +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} After applying the config, you can get the deployment image, and see it has changed. @@ -85,6 +152,8 @@ After applying the config, you can get the deployment image, and see it has chan You can customize the EnvoyProxy Pod Annotations via EnvoyProxy Config like: +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} After applying the config, you can get the envoyproxy pods, and see new annotations has been added. @@ -110,6 +202,8 @@ After applying the config, you can get the envoyproxy pods, and see new annotati You can customize the EnvoyProxy Deployment Resources via EnvoyProxy Config like: +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} ## Customize EnvoyProxy Deployment Env You can customize the EnvoyProxy Deployment Env via EnvoyProxy Config like: +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} > Envoy Gateway has provided two initial `env` `ENVOY_GATEWAY_NAMESPACE` and `ENVOY_POD_NAME` for envoyproxy container. @@ -166,6 +314,8 @@ After applying the config, you can get the envoyproxy deployment, and see resour You can customize the EnvoyProxy Deployment Volumes or VolumeMounts via EnvoyProxy Config like: +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} After applying the config, you can get the envoyproxy deployment, and see resources has been changed. @@ -197,6 +376,8 @@ After applying the config, you can get the envoyproxy deployment, and see resour You can customize the EnvoyProxy Service Annotations via EnvoyProxy Config like: +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} After applying the config, you can get the envoyproxy service, and see annotations has been added. @@ -226,6 +428,8 @@ There are two ways to customize it: * Replace: the whole bootstrap config will be replaced by the config you provided. * Merge: the config you provided will be merged into the default bootstrap config. +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} You can use [egctl translate][] to get the default xDS Bootstrap configuration used by Envoy Gateway. @@ -323,6 +615,8 @@ You can enable [Horizontal Pod Autoscaler](https://github.com/envoyproxy/gateway Once confirmed, you can apply it via EnvoyProxy Config as shown below: +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} After applying the config, the EnvoyProxy HPA (Horizontal Pod Autoscaler) is generated. However, upon activating the EnvoyProxy's HPA, the Envoy Gateway will no longer reference the `replicas` field specified in the `envoyDeployment`, as outlined [here](#customize-envoyproxy-deployment-replicas). @@ -354,6 +676,8 @@ After applying the config, the EnvoyProxy HPA (Horizontal Pod Autoscaler) is gen You can customize the EnvoyProxy Command line options via `spec.extraArgs` in EnvoyProxy Config. For example, the following configuration will add `--disable-extensions` arg in order to disable `envoy.access_loggers/envoy.access_loggers.wasm` extension: +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} ## Customize EnvoyProxy with Patches @@ -373,6 +714,8 @@ You can customize the EnvoyProxy using patches. For example, the following configuration will add resource limits to the `envoy` and the `shutdown-manager` containers in the `envoyproxy` deployment: +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} After applying the configuration, you will see the change in both containers in the `envoyproxy` deployment. diff --git a/site/content/en/latest/tasks/operations/deployment-mode.md b/site/content/en/latest/tasks/operations/deployment-mode.md index dd3ea9ea6f8..300c828120a 100644 --- a/site/content/en/latest/tasks/operations/deployment-mode.md +++ b/site/content/en/latest/tasks/operations/deployment-mode.md @@ -57,6 +57,8 @@ eg-marketing oci://docker.io/envoyproxy/gateway-helm \ Lets create a `GatewayClass` linked to the marketing team's Envoy Gateway controller, and as well other resources linked to it, so the `backend` application operated by this team can be exposed to external clients. +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} Lets port forward to the generated envoy proxy service in the `marketing` namespace and send a request to it. @@ -235,6 +342,8 @@ eg-product oci://docker.io/envoyproxy/gateway-helm \ Lets create a `GatewayClass` linked to the product team's Envoy Gateway controller, and as well other resources linked to it, so the `backend` application operated by this team can be exposed to external clients. +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} Lets port forward to the generated envoy proxy service in the `product` namespace and send a request to it. @@ -608,6 +822,8 @@ kubectl apply -f https://github.com/envoyproxy/gateway/releases/download/latest/ Lets create also and additional `Gateway` linked to the GatewayClass and `backend` application from Quickstart example. +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} Verify that Gateways are deployed and programmed diff --git a/site/content/en/latest/tasks/security/backend-tls.md b/site/content/en/latest/tasks/security/backend-tls.md index 9eadf4dd9d8..80ed3593305 100644 --- a/site/content/en/latest/tasks/security/backend-tls.md +++ b/site/content/en/latest/tasks/security/backend-tls.md @@ -81,6 +81,8 @@ kubectl patch deployment backend --type=json --patch ' Create a service that exposes port 443 on the backend service. +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} Create a [BackendTLSPolicy][] instructing Envoy Gateway to establish a TLS connection with the backend and validate the backend certificate is issued by a trusted CA and contains an appropriate DNS SAN. +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} Patch the HTTPRoute's backend reference, so that it refers to the new TLS-enabled service: diff --git a/site/content/en/latest/tasks/security/basic-auth.md b/site/content/en/latest/tasks/security/basic-auth.md index 3061ec90918..c9560f56f88 100644 --- a/site/content/en/latest/tasks/security/basic-auth.md +++ b/site/content/en/latest/tasks/security/basic-auth.md @@ -100,6 +100,8 @@ kubectl create secret generic basic-auth --from-file=.htpasswd The below example defines a SecurityPolicy that authenticates requests against the user list in the kubernetes secret generated in the previous step. +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} Verify the SecurityPolicy configuration: diff --git a/site/content/en/latest/tasks/security/cors.md b/site/content/en/latest/tasks/security/cors.md index aa2994200a5..9243d6a5905 100644 --- a/site/content/en/latest/tasks/security/cors.md +++ b/site/content/en/latest/tasks/security/cors.md @@ -22,6 +22,8 @@ In addition to that the entire origin (with or without specifying a scheme) can The below example defines a SecurityPolicy that allows CORS for all HTTP requests originating from `www.foo.com`. +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} Verify the SecurityPolicy configuration: diff --git a/site/content/en/latest/tasks/security/ext-auth.md b/site/content/en/latest/tasks/security/ext-auth.md index 223d3b53c4b..455b986283f 100644 --- a/site/content/en/latest/tasks/security/ext-auth.md +++ b/site/content/en/latest/tasks/security/ext-auth.md @@ -34,6 +34,8 @@ kubectl apply -f https://raw.githubusercontent.com/envoyproxy/gateway/latest/exa Create a new HTTPRoute resource to route traffic on the path `/myapp` to the backend service. +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} Verify the HTTPRoute status: @@ -69,6 +97,8 @@ Create a new SecurityPolicy resource to configure the external authorization. Th authorization. The `headersToBackend` field specifies the headers that will be sent to the backend service if the request is successfully authorized. +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} Verify the SecurityPolicy configuration: @@ -162,6 +216,8 @@ not created the HTTPRoute, you can create it now. Create a new HTTPRoute resource to route traffic on the path `/myapp` to the backend service. +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} Verify the HTTPRoute status: @@ -195,6 +277,8 @@ kubectl get httproute/myapp -o yaml Update the SecurityPolicy that was created in the previous section to use the gRPC external authorization service. It calls the gRPC external authorization service "grpc-ext-auth" on port 9002 for authorization. +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} Verify the SecurityPolicy configuration: @@ -223,6 +330,8 @@ kubectl get securitypolicy/ext-auth-example -o yaml Because the gRPC external authorization service is enabled with TLS, a BackendTLSConfig needs to be created to configure the communication between the Envoy proxy and the gRPC auth service. +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} Verify the BackendTLSPolicy configuration: diff --git a/site/content/en/latest/tasks/security/mutual-tls.md b/site/content/en/latest/tasks/security/mutual-tls.md index 1a68174e6fe..769f3bd4535 100644 --- a/site/content/en/latest/tasks/security/mutual-tls.md +++ b/site/content/en/latest/tasks/security/mutual-tls.md @@ -78,6 +78,8 @@ kubectl get gateway/eg -o yaml Create a [ClientTrafficPolicy][] to enforce client validation using the CA Certificate as a trusted anchor. +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} ## Testing diff --git a/site/content/en/latest/tasks/security/oidc.md b/site/content/en/latest/tasks/security/oidc.md index 7fce6f9257e..b754d35163d 100644 --- a/site/content/en/latest/tasks/security/oidc.md +++ b/site/content/en/latest/tasks/security/oidc.md @@ -29,6 +29,8 @@ This task demonstrates the configuration of OIDC at the HTTPRoute level. Let's create an HTTPRoute that represents an application protected by OIDC. +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} Verify the HTTPRoute status: @@ -93,6 +120,8 @@ by the OAuth2 filter on that HTTPRoute. Note: please replace the ${CLIENT_ID} in the below yaml snippet with the actual Client ID that you got from the OIDC provider. +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} Verify the SecurityPolicy configuration: diff --git a/site/content/en/latest/tasks/security/private-key-provider.md b/site/content/en/latest/tasks/security/private-key-provider.md index 447e61cb353..18d3afc5fd0 100644 --- a/site/content/en/latest/tasks/security/private-key-provider.md +++ b/site/content/en/latest/tasks/security/private-key-provider.md @@ -114,25 +114,49 @@ It required the node with 3rd generation Intel Xeon Scalable processor server pr * Follow the steps from the [Quickstart](../quickstart) to install Envoy Gateway. -* Lets enable the EnvoyPatchPolicy feature, which will allow us to directly configure the Private Key Provider Envoy Filter, since Envoy Gateway does not directly expose this functionality. +* Enable the EnvoyPatchPolicy feature, which will allow us to directly configure the Private Key Provider Envoy Filter, since Envoy Gateway does not directly expose this functionality. - ```shell - cat <}} +{{% tab header="Apply from stdin" %}} +```shell +cat <}} * After updating the `ConfigMap`, you will need to restart the `envoy-gateway` deployment so the configuration kicks in @@ -146,26 +170,50 @@ It required the node with 3rd generation Intel Xeon Scalable processor server pr * Update GatewayClass for using the envoyproxy image with contrib extensions and requests required resources. - ```shell - cat <}} +{{% tab header="Apply from stdin" %}} +```shell +cat <}} ### Change EnvoyProxy configuration for QAT Using the envoyproxy image with contrib extensions and add qat resources requesting, ensure the k8s scheduler find out a machine with required resource. +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} ### Change EnvoyProxy configuration for CryptoMB Using the envoyproxy image with contrib extensions and add the node affinity to scheduling the Envoy Gateway pod on the machine with required CPU instructions. +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} Or using `preferredDuringSchedulingIgnoredDuringExecution` for best effort scheduling, or not doing any node affinity, just doing the random scheduling. The CryptoMB private key provider supports software fallback if the required CPU instructions aren't here. @@ -276,6 +406,8 @@ fortio load -c 10 -k -qps 0 -t 30s -keepalive=false https://www.example.com:${NO ### For QAT +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} ### For CryptoMB +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} ### Benchmark after enabling private key provider diff --git a/site/content/en/latest/tasks/security/secure-gateways.md b/site/content/en/latest/tasks/security/secure-gateways.md index e56a496e022..199ac976005 100644 --- a/site/content/en/latest/tasks/security/secure-gateways.md +++ b/site/content/en/latest/tasks/security/secure-gateways.md @@ -165,6 +165,8 @@ Before proceeding, ensure you can query the HTTPS backend service from the [Test To demonstrate cross namespace certificate references, create a ReferenceGrant that allows Gateways from the "default" namespace to reference Secrets in the "envoy-gateway-system" namespace: +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} Delete the previously created Secret: @@ -204,6 +228,8 @@ kubectl create secret tls example-cert -n envoy-gateway-system --key=www.example Update the Gateway HTTPS listener with `namespace: envoy-gateway-system`, for example: +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} The Gateway HTTPS listener status should now surface the `Ready: True` condition and you should once again be able to query the HTTPS backend through the Gateway. diff --git a/site/content/en/latest/tasks/traffic/circuit-breaker.md b/site/content/en/latest/tasks/traffic/circuit-breaker.md index cf00d926a2c..1d3a2e85bbf 100644 --- a/site/content/en/latest/tasks/traffic/circuit-breaker.md +++ b/site/content/en/latest/tasks/traffic/circuit-breaker.md @@ -62,6 +62,8 @@ The default circuit breaker threshold (1024) is not met. As a result, requests d In order to fail fast, apply a `BackendTrafficPolicy` that limits concurrent requests to 10 and pending requests to 0. +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} Execute the load simulation again. diff --git a/site/content/en/latest/tasks/traffic/client-traffic-policy.md b/site/content/en/latest/tasks/traffic/client-traffic-policy.md index 98659941f72..dc461d7c702 100644 --- a/site/content/en/latest/tasks/traffic/client-traffic-policy.md +++ b/site/content/en/latest/tasks/traffic/client-traffic-policy.md @@ -23,6 +23,8 @@ Before proceeding, you should be able to query the example backend using HTTP. ### Support TCP keepalive for downstream client +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} Verify that ClientTrafficPolicy is Accepted: @@ -176,6 +202,8 @@ You can see keepalive connection marked by the output in: This example configures Proxy Protocol for downstream clients. +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} Verify that ClientTrafficPolicy is Accepted: @@ -289,6 +338,8 @@ You should now expect 200 response status and also see that source IP was preser This example configures the number of additional ingress proxy hops from the right side of XFF HTTP headers to trust when determining the origin client's IP address and determines whether or not `x-forwarded-proto` headers will be trusted. Refer to https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_conn_man/headers#x-forwarded-for for details. +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} Verify that ClientTrafficPolicy is Accepted: @@ -415,6 +489,8 @@ Handling connection for 8888 This feature allows you to limit the take taken by the Envoy Proxy fleet to receive the entire request from the client, which is useful in preventing certain clients from consuming too much memory in Envoy This example configures the HTTP request timeout for the client, please check out the details [here](https://www.envoyproxy.io/docs/envoy/latest/faq/configuration/timeouts#stream-timeouts). +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} Curl the example app through Envoy proxy: diff --git a/site/content/en/latest/tasks/traffic/connection-limit.md b/site/content/en/latest/tasks/traffic/connection-limit.md index 138e620bf9b..20bce016805 100644 --- a/site/content/en/latest/tasks/traffic/connection-limit.md +++ b/site/content/en/latest/tasks/traffic/connection-limit.md @@ -57,6 +57,8 @@ There are no connection limits, and so all 100 requests succeed. Next, we apply a limit of 5 connections. +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} Execute the load simulation again. diff --git a/site/content/en/latest/tasks/traffic/fault-injection.md b/site/content/en/latest/tasks/traffic/fault-injection.md index 657b3e1453d..cc8bea6f6fe 100644 --- a/site/content/en/latest/tasks/traffic/fault-injection.md +++ b/site/content/en/latest/tasks/traffic/fault-injection.md @@ -26,6 +26,8 @@ Allow requests with a valid faultInjection by creating an [BackendTrafficPolicy] ### HTTPRoute +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} -Two HTTPRoute has been created, one for `/foo` and another for `/bar`. `fault-injection-abort` BackendTrafficPolicy has been created and targeted HTTPRoute foo to abort requests for `/foo`. `fault-injection-delay` BackendTrafficPolicy has been created and targeted HTTPRoute foo to delay `2s` requests for `/bar`. + +Two HTTPRoute resources were created, one for `/foo` and another for `/bar`. `fault-injection-abort` BackendTrafficPolicy has been created and targeted HTTPRoute foo to abort requests for `/foo`. `fault-injection-delay` BackendTrafficPolicy has been created and targeted HTTPRoute foo to delay `2s` requests for `/bar`. Verify the HTTPRoute configuration and status: @@ -118,6 +197,8 @@ kubectl get backendtrafficpolicy/fault-injection-delay -o yaml ### GRPCRoute +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} A BackendTrafficPolicy has been created and targeted GRPCRoute yages to abort requests for `yages` service.. diff --git a/site/content/en/latest/tasks/traffic/global-rate-limit.md b/site/content/en/latest/tasks/traffic/global-rate-limit.md index a0734928bd7..97cda03a4a5 100644 --- a/site/content/en/latest/tasks/traffic/global-rate-limit.md +++ b/site/content/en/latest/tasks/traffic/global-rate-limit.md @@ -35,6 +35,8 @@ Before proceeding, you should be able to query the example backend using HTTP. * The global rate limit feature is based on [Envoy Ratelimit][] which requires a Redis instance as its caching layer. Lets install a Redis deployment in the `redis-system` namespce. +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} ### Enable Global Rate limit in Envoy Gateway @@ -98,7 +157,8 @@ EOF using a `ConfigMap`. In the next step, we will update this resource to enable rate limit in Envoy Gateway as well as configure the URL for the Redis instance used for Global rate limiting. - +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} * After updating the `ConfigMap`, you will need to restart the `envoy-gateway` deployment so the configuration kicks in @@ -128,12 +215,13 @@ EOF kubectl rollout restart deployment envoy-gateway -n envoy-gateway-system ``` - ## Rate Limit Specific User Here is an example of a rate limit implemented by the application developer to limit a specific user by matching on a custom `x-user-id` header with a value set to `one`. +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} ### HTTPRoute +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} The HTTPRoute status should indicate that it has been accepted and is bound to the example Gateway. @@ -286,6 +434,8 @@ Here is an example of a rate limit implemented by the application developer to l value in the `x-user-id` header. Here, user `one` (recognised from the traffic flow using the header `x-user-id` and value `one`) will be rate limited at 3 requests/hour and so will user `two` (recognised from the traffic flow using the header `x-user-id` and value `two`). +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} ### HTTPRoute +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} Lets run the same command again with the header `x-user-id` and value `one` set in the request. We should the first 3 requests succeeding and the 4th request being rate limited. @@ -421,6 +631,8 @@ transfer-encoding: chunked This example shows you how to rate limit all requests matching the HTTPRoute rule at 3 requests/Hour by leaving the `clientSelectors` field unset. +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} ### HTTPRoute +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} ```shell for i in {1..4}; do curl -I --header "Host: ratelimit.example" http://${GATEWAY_HOST}/get ; sleep 1; done @@ -515,6 +783,8 @@ Note: EG supports two kinds of rate limit for the IP address: exact and distinct * exact means that all IP addresses within the specified Source IP CIDR share the same rate limit bucket. * distinct means that each IP address within the specified Source IP CIDR has its own rate limit bucket. +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} ```shell for i in {1..4}; do curl -I --header "Host: ratelimit.example" http://${GATEWAY_HOST}/get ; sleep 1; done @@ -602,6 +922,8 @@ transfer-encoding: chunked Here is an example of a rate limit implemented by the application developer to limit distinct users who can be differentiated based on the value of the Jwt claims carried. +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} Get the JWT used for testing request authentication: @@ -767,6 +1157,8 @@ like container `image`, `securityContext`, `env` and pod `annotations` and `secu * `tls.certificateRef` set the client certificate for redis server TLS connections. +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} * After updating the `ConfigMap`, you will need to restart the `envoy-gateway` deployment so the configuration kicks in diff --git a/site/content/en/latest/tasks/traffic/grpc-routing.md b/site/content/en/latest/tasks/traffic/grpc-routing.md index 4c27ef993cc..3165405aad5 100644 --- a/site/content/en/latest/tasks/traffic/grpc-routing.md +++ b/site/content/en/latest/tasks/traffic/grpc-routing.md @@ -95,6 +95,8 @@ It supports two match types: `Exact` and `RegularExpression`. The following example shows how to match a request based on the service and method names for `grpc.reflection.v1alpha.ServerReflection/ServerReflectionInfo`, as well as a match for all services with a method name `Ping` which matches `yages.Echo/Ping` in our deployment. +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} Verify the GRPCRoute status: @@ -142,6 +177,8 @@ The following example shows how to match a request based on the service and meth with match type `RegularExpression`. It matches all the services and methods with pattern `/.*.Echo/Pin.+`, which matches `yages.Echo/Ping` in our deployment. +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} Verify the GRPCRoute status: diff --git a/site/content/en/latest/tasks/traffic/http-redirect.md b/site/content/en/latest/tasks/traffic/http-redirect.md index 8639c2c9d7c..a8fc7d2e82c 100644 --- a/site/content/en/latest/tasks/traffic/http-redirect.md +++ b/site/content/en/latest/tasks/traffic/http-redirect.md @@ -19,6 +19,8 @@ Redirects return HTTP 3XX responses to a client, instructing it to retrieve a di For example, to issue a permanent redirect (301) from HTTP to HTTPS, configure `requestRedirect.statusCode=301` and `requestRedirect.scheme="https"`: +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} __Note:__ `301` (default) and `302` are the only supported statusCodes. @@ -104,8 +132,10 @@ kubectl create secret tls example-com --key=tls.key --cert=tls.crt Define a https listener on the existing gateway +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell -cat <}} Check for any TLS certificate issues on the gateway. @@ -137,9 +196,10 @@ kubectl -n default describe gateway eg Create two HTTPRoutes and attach them to the HTTP and HTTPS listeners using the [sectionName][] field. - +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell -cat <}} Curl the example app through http listener: @@ -200,6 +307,8 @@ curl -v -H 'Host:www.example.com' --resolve "www.example.com:443:$GATEWAY_HOST" Path redirects use an HTTP Path Modifier to replace either entire paths or path prefixes. For example, the HTTPRoute below will issue a 302 redirect to all `path.redirect.example` requests whose path begins with `/get` to `/status/200`. +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} The HTTPRoute status should indicate that it has been accepted and is bound to the example Gateway. diff --git a/site/content/en/latest/tasks/traffic/http-request-mirroring.md b/site/content/en/latest/tasks/traffic/http-request-mirroring.md index e5caa3fdc89..ed214ac8fc3 100644 --- a/site/content/en/latest/tasks/traffic/http-request-mirroring.md +++ b/site/content/en/latest/tasks/traffic/http-request-mirroring.md @@ -16,8 +16,10 @@ Before proceeding, you should be able to query the example backend using HTTP. Next, create a new `Deployment` and `Service` to mirror requests to. The following example will use a second instance of the application deployed in the quickstart. +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell -kubectl apply -f - <}} Then create an `HTTPRoute` that uses a `HTTPRequestMirrorFilter` to send requests to the original service from the quickstart, and mirror request to the service that was just deployed. +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell -kubectl apply -f - <}} The HTTPRoute status should indicate that it has been accepted and is bound to the example Gateway. @@ -142,6 +241,7 @@ $ curl -v --header "Host: backends.example" "http://${GATEWAY_HOST}/get" < server: envoy < ... + "namespace": "default", "ingress": "", "service": "", @@ -164,6 +264,8 @@ Echoing back request made to /get to client (10.42.0.10:45096) When an `HTTPRoute` has multiple `backendRefs` and an `HTTPRequestMirrorFilter`, traffic splitting will still behave the same as it normally would for the main `backendRefs` while the `backendRef` of the `HTTPRequestMirrorFilter` will continue receiving mirrored copies of the incoming requests. +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} ## Multiple HTTPRequestMirrorFilters Multiple `HTTPRequestMirrorFilters` are not supported on the same `HTTPRoute` `rule`. When attempting to do so, the admission webhook will reject the configuration. +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} ```console Error from server: error when creating "STDIN": admission webhook "validate.gateway.networking.k8s.io" denied the request: spec.rules[0].filters: Invalid value: "RequestMirror": cannot be used multiple times in the same rule diff --git a/site/content/en/latest/tasks/traffic/http-response-headers.md b/site/content/en/latest/tasks/traffic/http-response-headers.md index 8e13f146493..df6f4369fd2 100644 --- a/site/content/en/latest/tasks/traffic/http-response-headers.md +++ b/site/content/en/latest/tasks/traffic/http-response-headers.md @@ -22,6 +22,8 @@ does not have the header configured by the filter, then that header will be adde already has the header configured by the filter, then the value of the header in the filter will be appended to the value of the header in the response. +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} The HTTPRoute status should indicate that it has been accepted and is bound to the example Gateway. @@ -105,6 +142,8 @@ will be added, but unlike [adding response headers](#adding-response-headers) wh if the response already contains it, setting a header will cause the value to be replaced by the value configured in the filter. +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} Querying `headers.example/get` should result in a `200` response from the example Gateway and the output from the example app should indicate that the downstream client received the header `set-header` with the original value `value1` @@ -177,6 +251,8 @@ will be added, but unlike [adding response headers](#adding-response-headers) wh if the response already contains it, setting a header will cause the value to be replaced by the value configured in the filter. +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} Querying `headers.example/get` should result in a `200` response from the example Gateway and the output from the example app should indicate that the header `remove-header` that was sent by curl was removed before the upstream @@ -242,6 +351,8 @@ $ curl -vvv --header "Host: headers.example" "http://${GATEWAY_HOST}/get" -H 'X- Headers can be added/set/removed in a single filter on the same HTTPRoute and they will all perform as expected +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} [HTTPRoute]: https://gateway-api.sigs.k8s.io/api-types/httproute/ [Gateway API documentation]: https://gateway-api.sigs.k8s.io/ diff --git a/site/content/en/latest/tasks/traffic/http-routing.md b/site/content/en/latest/tasks/traffic/http-routing.md index 4f4ed06e588..94a492d51da 100644 --- a/site/content/en/latest/tasks/traffic/http-routing.md +++ b/site/content/en/latest/tasks/traffic/http-routing.md @@ -131,6 +131,8 @@ For this feature to work please make sure * you have a fallback route rule defined, the backend for this route rule can be invalid. * The SecurityPolicy is applied to both the fallback route as well as the route with the claim header matches, to avoid spoofing. +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} Get the JWT used for testing request authentication: diff --git a/site/content/en/latest/tasks/traffic/http-timeouts.md b/site/content/en/latest/tasks/traffic/http-timeouts.md index 01e166fe87e..322707d823d 100644 --- a/site/content/en/latest/tasks/traffic/http-timeouts.md +++ b/site/content/en/latest/tasks/traffic/http-timeouts.md @@ -22,6 +22,8 @@ backend has the ability to delay responses; we use it as the backend to control ### request timeout We configure the backend to delay responses by 3 seconds, then we set the request timeout to 4 seconds. Envoy Gateway will successfully respond to the request. +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} ```shell curl --header "Host: timeout.example.com" http://${GATEWAY_HOST}/?delay=3s -I @@ -65,6 +100,8 @@ content-length: 480 Then we set the request timeout to 2 seconds. In this case, Envoy Gateway will respond with a timeout. +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} ```shell curl --header "Host: timeout.example.com" http://${GATEWAY_HOST}/?delay=3s -v diff --git a/site/content/en/latest/tasks/traffic/http-traffic-splitting.md b/site/content/en/latest/tasks/traffic/http-traffic-splitting.md index 924d36970e9..e2ec77dd3ab 100644 --- a/site/content/en/latest/tasks/traffic/http-traffic-splitting.md +++ b/site/content/en/latest/tasks/traffic/http-traffic-splitting.md @@ -15,6 +15,8 @@ Before proceeding, you should be able to query the example backend using HTTP. When a single backendRef is configured in a HTTPRoute, it will receive 100% of the traffic. +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} The HTTPRoute status should indicate that it has been accepted and is bound to the example Gateway. @@ -87,6 +117,8 @@ configured. First, create a second instance of the example app from the quickstart: +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} Then create an HTTPRoute that uses both the app from the quickstart and the second instance that was just created +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} Querying `backends.example/get` should result in `200` responses from the example Gateway and the output from the example app that indicates which pod handled the request should switch between the first pod and the second one from the @@ -217,6 +344,8 @@ HTTPRoute. The weight is not a percentage and the sum of all weights does not ne The HTTPRoute below will configure the gateway to send 80% of the traffic to the backend service, and 20% to the backend-2 service. +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} ## Invalid backendRefs @@ -263,6 +426,8 @@ Modifying the above example to make the backend-2 backendRef invalid by using a will result in 80% of the traffic being sent to the backend service, and 20% of the traffic receiving an HTTP response with status code `500`. +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} Querying `backends.example/get` should result in `200` responses 80% of the time, and `500` responses 20% of the time. diff --git a/site/content/en/latest/tasks/traffic/http-urlrewrite.md b/site/content/en/latest/tasks/traffic/http-urlrewrite.md index 5acca036714..2e6ec3f0612 100644 --- a/site/content/en/latest/tasks/traffic/http-urlrewrite.md +++ b/site/content/en/latest/tasks/traffic/http-urlrewrite.md @@ -15,6 +15,8 @@ Before proceeding, you should be able to query the example backend using HTTP. You can configure to rewrite the prefix in the url like below. In this example, any curls to `http://${GATEWAY_HOST}/get/xxx` will be rewritten to `http://${GATEWAY_HOST}/replace/xxx`. +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} The HTTPRoute status should indicate that it has been accepted and is bound to the example Gateway. @@ -114,6 +147,8 @@ You can configure to rewrite the fullpath in the url like below. In this example `http://${GATEWAY_HOST}/get/origin/path/xxxx` will be rewritten to `http://${GATEWAY_HOST}/force/replace/fullpath`. +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} The HTTPRoute status should indicate that it has been accepted and is bound to the example Gateway. @@ -208,6 +275,8 @@ You can see that the `X-Envoy-Original-Path` is `/get/origin/path/extra`, but th You can configure to rewrite the hostname like below. In this example, any requests sent to `http://${GATEWAY_HOST}/get` with `--header "Host: path.rewrite.example"` will rewrite host into `envoygateway.io`. +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} The HTTPRoute status should indicate that it has been accepted and is bound to the example Gateway. diff --git a/site/content/en/latest/tasks/traffic/http3.md b/site/content/en/latest/tasks/traffic/http3.md index 702a3e3716f..a55e6c58e24 100644 --- a/site/content/en/latest/tasks/traffic/http3.md +++ b/site/content/en/latest/tasks/traffic/http3.md @@ -59,8 +59,10 @@ kubectl patch gateway eg --type=json --patch ' Apply the following ClientTrafficPolicy to enable HTTP3 +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell -kubectl apply -f - <}} Verify the Gateway status: diff --git a/site/content/en/latest/tasks/traffic/local-rate-limit.md b/site/content/en/latest/tasks/traffic/local-rate-limit.md index 067756b3109..afda7d125a6 100644 --- a/site/content/en/latest/tasks/traffic/local-rate-limit.md +++ b/site/content/en/latest/tasks/traffic/local-rate-limit.md @@ -36,6 +36,8 @@ Before proceeding, you should be able to query the example backend using HTTP. Here is an example of a rate limit implemented by the application developer to limit a specific user by matching on a custom `x-user-id` header with a value set to `one`. +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} ### HTTPRoute +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} The HTTPRoute status should indicate that it has been accepted and is bound to the example Gateway. @@ -186,6 +248,8 @@ server: envoy This example shows you how to rate limit all requests matching the HTTPRoute rule at 3 requests/Hour by leaving the `clientSelectors` field unset. +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} ### HTTPRoute +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} ```shell for i in {1..4}; do curl -I --header "Host: ratelimit.example" http://${GATEWAY_HOST}/get ; sleep 1; done diff --git a/site/content/en/latest/tasks/traffic/retry.md b/site/content/en/latest/tasks/traffic/retry.md index cde27f5c2bf..d5ab467a38b 100644 --- a/site/content/en/latest/tasks/traffic/retry.md +++ b/site/content/en/latest/tasks/traffic/retry.md @@ -46,6 +46,8 @@ Let's create a `BackendTrafficPolicy` with a retry setting. The request will be retried 5 times with a 100ms base interval and a 10s maximum interval. +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} Execute the test again. diff --git a/site/content/en/latest/tasks/traffic/routing-outside-kubernetes.md b/site/content/en/latest/tasks/traffic/routing-outside-kubernetes.md index e43052073cb..e2acfbfc393 100644 --- a/site/content/en/latest/tasks/traffic/routing-outside-kubernetes.md +++ b/site/content/en/latest/tasks/traffic/routing-outside-kubernetes.md @@ -14,6 +14,8 @@ Before proceeding, you should be able to query the example backend using HTTP. Define a Service and EndpointSlice that represents https://httpbin.org +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} Update the [Gateway][] to include a TLS Listener on port 443 @@ -63,6 +101,8 @@ kubectl patch gateway eg --type=json --patch ' Add a [TLSRoute][] that can route incoming traffic to the above backend that we created +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} Get the Gateway address: diff --git a/site/content/en/latest/tasks/traffic/tcp-routing.md b/site/content/en/latest/tasks/traffic/tcp-routing.md index 4eea863f5f8..878ed917e50 100644 --- a/site/content/en/latest/tasks/traffic/tcp-routing.md +++ b/site/content/en/latest/tasks/traffic/tcp-routing.md @@ -23,6 +23,8 @@ TCPRoutes, note that the protocol set for the listeners on the Gateway is TCP: Install the GatewayClass and a `tcp-gateway` Gateway first. +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} +Install two services `foo` and `bar`, which are bound to `backend-1` and `backend-2`. + +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} Install two TCPRoutes `tcp-app-1` and `tcp-app-2` with different `sectionName`: +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} In the above example we separate the traffic for the two separate backend TCP Services by using the sectionName field in the parentRefs: diff --git a/site/content/en/latest/tasks/traffic/udp-routing.md b/site/content/en/latest/tasks/traffic/udp-routing.md index 497d0781b98..d20287476b9 100644 --- a/site/content/en/latest/tasks/traffic/udp-routing.md +++ b/site/content/en/latest/tasks/traffic/udp-routing.md @@ -56,6 +56,8 @@ kubectl get gateway/eg -o yaml Create a UDPRoute resource to route UDP traffic received on Gateway port 5300 to the CoredDNS backend. +{{< tabpane text=true >}} +{{% tab header="Apply from stdin" %}} ```shell cat <}} Verify the UDPRoute status: