diff --git a/VERSION b/VERSION index 6dc938c1692..0ec25f7505c 100644 --- a/VERSION +++ b/VERSION @@ -1 +1 @@ -v1.0.0-rc.1 +v1.0.0 diff --git a/release-notes/v1.0.0.yaml b/release-notes/v1.0.0.yaml new file mode 100644 index 00000000000..2444e87604b --- /dev/null +++ b/release-notes/v1.0.0.yaml @@ -0,0 +1,180 @@ +date: Nov 1, 2023 + +changes: + - area: documentation + change: | + Added User Guide for Local Ratelimit + Added User Guide for Circuit Breaker + Added User Guide for fault injection + Added User Guide for EnvoyProxy extraArgs + Added User Guide for Timeouts in ClientTrafficPolicy + Added User Guide for JWT claim base routing + Added User Guide for HTTP Timeout + Added User Guide for Retry in BackendTrafficPolicy + Added User Guide for Basic Auth + Added User Guide for OIDC + Added User Guide for ClientTrafficPolicy + Added User Guide for BackendTrafficPolicy + Added User Guide for Basic Auth using HTTPS + Added User Guide for External Authorization + Added User Guide for Routing Outside Kubernetes + Added User Guide for BackendTLSPolicy + Added User Guide for Mutual TLS from External Clients to the Gateway + Added User Guide for Control Plane Authentication using custom certs + Added User Guide for Multiple Gatewayclass and Merge Gateways Deployment Mode + Added `Type` and `required` for CRD API doc + Refactored Structure of User Guide docs + Refactored Move Design docs under "Get Involved" + Updated crd-ref-docs to 0.0.10 + Updated Envoy proxy image to envoy:distroless-dev in main + + + - area: installation + change: | + Added Support for Pulling envoyGateway image from a private registry + Added Support for Configuring resources for certgen job + Added Support for Configuring affinity for EnvoyGateway pod + + - area: api + change: | + Added Support for Downstream QUIC/HTTP3 in ClientTrafficPolicy CRD + Added Support for Downstream MTLS in ClientTrafficPolicy CRD + Added Support for Enabling EnvoyHeaders in ClientTrafficPolicy CRD + Added Support for DisableMergeSlash and escapedSlashesAction in ClientTrafficPolicy CRD + Added Support for EnableTrailers in HTTP/1.1 in ClientTrafficPolicy CRD + Added Support for Preserving header letter-case on HTTP/1 in ClientTrafficPolicy CRD + Added Support for Enabling HTTP/1.0 and HTTP/0.9 in ClientTrafficPolicy CRD + Added Support for Client IP Detection using XFF in ClientTrafficPolicy CRD + Added Support for Client IP Detection using Custom Header in ClientTrafficPolicy CRD + Added Support for Connection Timeouts in ClientTrafficPolicy CRD + Added Support for Common TLS configuration properties in ClientTrafficPolicy CRD + Added Support for Proxy protocol in ClientTrafficPolicy CRD + Added Support for TCPKeepAlive in ClientTrafficPolicy CRD + Added Support for Local rate limit in BackendTrafficPolicy CRD + Added Support for CircuitBreaker in BackendTrafficPolicy CRD + Added Support for Fault injection in BackendTrafficPolicy CRD + Added Support for Passive Health Checks in BackendTrafficPolicy CRD + Added Support for Active Health Checks in BackendTrafficPolicy CRD + Added Support for Connection Timeouts in BackendTrafficPolicy CRD + Added Support for Compressor/Decompressor in BackendTrafficPolicy CRD + Added Support for Retry in BackendTrafficPolicy CRD + Added Support for Slow start mode in BackendTrafficPolicy CRD + Added Support for Proxy protocol in BackendTrafficPolicy CRD + Added Support for TCPKeepAlive in BackendTrafficPolicy CRD + Added Support for PolicyStatus in BackendTrafficPolicy CRD + Added Support for PolicyStatus in ClientTrafficPolicy CRD + Added Support for PolicyStatus in SecurityPolicy CRD + Added Support for OIDC in SecurityPolicy CRD + Added Support for Basic Auth in SecurityPolicy CRD + Added Support for RedirectURL and signoutPath to OIDC in SecurityPolicy CRD + Added Support for ExtractFrom headers and params to JWT in SecurityPolicy CRD + Added Support for External Authorization in SecurityPolicy CRD + Added Support for RecomputeRoute field to JWT in SecurityPolicy CRD + Added Support for AllowCredentials knob to CORS setting in SecurityPolicy CRD + Added Support for Extract from different identifier to JWT in SecurityPolicy CRD + Added Support for Secret resource in EnvoyPatchPolicy CRD + Added Support for Making the value optional for JSONPatchOperation in EnvoyPatchPolicy CRD + Added Support for `From` field to JSONPatchOperation in EnvoyPatchPolicy CRD + Added Support for MergeGateways in EnvoyPatchPolicy CRD + Added Support for Upstream TLS by implementing BackendTLSPolicy CRD + Added Support for LabelSelector type for NamespaceSelectors in EnvoyGateway Configuration + Added Support for Ratelimit prometheus in EnvoyGateway Configuration + Added Support for Gracefully drain listeners before envoy shutdown on pod termination in EnvoyProxy CRD + Added Support for Configuring externalTrafficPolicy to the envoy service in EnvoyProxy CRD + Added Support for Envoy extra args in EnvoyProxy CRD + Added Support for Mergepatch to envoyproxy/ratelimit deployment in EnvoyProxy CRD + Added Support for Mergepatch to envoyproxy service in EnvoyProxy CRD + Added Support for NodeSelector to PodSpec in EnvoyProxy CRD + Added Support for HorizontalPodAutoscaler in EnvoyProxy CRD + Added Support for TopologySpreadConstraints to PodSpec in EnvoyProxy CRD + Added Support for ImagePullSecrets to PodSpec in EnvoyProxy CRD + + breaking-change: | + Use wildcard to match AllowOrigins to CORS in SecurityPolicy CRD + Remove Hostnetwork support in EnvoyProxy CRD + + - area: conformance + change: | + Replaced backend image from gcr.io/k8s-staging-ingressconformance/echoserver to gcr.io/k8s-staging-gateway-api/echo-basic + + + - area: testing + change: | + Added e2e test for Header Case-Preserving + Added e2e test for Timeout in ClientTrafficPolicy + Added e2e test for JWT claim base routing + Added e2e test for OIDC + Added e2e test for BackendTrafficPolicy Retry + Added e2e test for Backend Upgrade + Added e2e test for External Authorization + Added e2e test for Backend TLS policy + Added e2e test for Envoy Gateway Release Upgrade + Added e2e test for Weighted backend + Added validation for LoadBalancerIP to prevent trailing period + + + - area: translator + change: | + Fixed Prefix match to prevent mismatching routes with the same prefix + Fixed Multiple reconciling by implementing comparable interface for ir.Infra + Fixed EndpointSlice with empty conditions {} + Fixed Error handling when parsing the http request timeout + Fixed No status when EnvoyPatchPolicy is disabled + Fixed Printable for xds and infra IRs + Fixed Skip backendRefs with weight set to 0 + Fixed AND Header matches in ratelimiting not working + Fixed Deletion logics when no gatewayclasses exist + Fixed Match mergedGateways irKey for ClientTrafficPolicy + Fixed Policies should apply only to gateways they were attached to when mergeGateways is true + Fixed Listener status is not surfaced for gateways when MergeGateways enabled + Fixed GRPCroute websocket not working by moving web socket upgrade config from hcm to route + Fixed Configure idle timeout when timeout is set on HTTPRoute + Fixed Relaxing HTTPS restriction for OIDC token endpoint + Fixed Panic when translating routes with empty backends + Fixed Xds translation should be done in a best-effort manner + Fixed Delete unused status keys from watchable + Fixed Ignoring finalizers when comparing envoy proxy service + Fixed Don't override the ALPN array if HTTP/3 is enabled + Fixed Add h3 ALPN by default if HTTP/3 is enabled + Fixed Change the Merge behavior to Replace for SecurityPolicy/BackendTrafficPolicy + Fixed Use service port in alt-svc header if HTTP/3 is enabled + Fixed Prevent policies targeting non-TLS listeners on the same port from conflicting + Fixed Skip the ReasonTargetNotFound for all policies + Fixed Skip publishing empty status for all policies + Added Support for validating regex before sending to Envoy + Added Support for setting spec.addresses.value into ClusterIP when Service Type is ClusterIP + Added Unsupported status condition for filters within BackendRef + Added List instead of map for Provider Resources for order stability + Added Suffix for oauth cookies to prevent multiple oauth filters from overwriting each other's cookies + Added Support for overriding condition to BackendTrafficPolicy and SecurityPolicy + Added Support for default retry budget and retry host predicate + Added Support for implementing gateway.spec.infrastructure + Added Support for Upstream TLS to multiple Backends + Added Validation for CA Cert in ClientTrafficPolicy + + + - area: providers + change: | + Added Support for multiple GatewayClass per controller + Added SecurityPolicyIndexers in Kubernetes Provider + Added Support for generating HMAC secret in CertGen Job + Fixed Finalizer logic when deleting Gatewayclasses + Fixed MergeGateways panics when restarting control plane + + + - area: xds + change: | + Added Support for EDS cache + Added Support for ADS cache to ensure the rule order + Fixed Deprecated field error when using RequestHeaderModifier filter + Fixed Envoy rejects XDS at runtime losing all routes on restart + Fixed Requests not matching defined routes trigger per-route filters + Bumped go-control-plane to v0.12.0 + + + - area: cli + change: | + Added Support for egctl x status + Added Support for egctl experimental dashboard envoy-proxy + Added Support for egctl config ratelimit + Added Support for egctl translate from gateway-api resources to IR diff --git a/site/content/en/_index.md b/site/content/en/_index.md index e724ec80a57..69fbf5e612c 100644 --- a/site/content/en/_index.md +++ b/site/content/en/_index.md @@ -3,10 +3,10 @@ title: Envoy Gateway --- {{< blocks/cover title="Welcome to Envoy Gateway!" image_anchor="top" height="full" >}} - + GET STARTED - + CONTRIBUTING

Manages Envoy Proxy as a Standalone or Kubernetes-based Application Gateway

diff --git a/site/content/en/announcements/v0.5.md b/site/content/en/announcements/v0.5.md index e23ae419231..71c10a89f3f 100644 --- a/site/content/en/announcements/v0.5.md +++ b/site/content/en/announcements/v0.5.md @@ -10,7 +10,7 @@ skip_list: true We are pleased to announce the release of Envoy Gateway v0.5! -This is the third functional release of Envoy Gateway. We would like to thank the entire Envoy Gateway community for +This is the fourth functional release of Envoy Gateway. We would like to thank the entire Envoy Gateway community for helping publish the release. | [Release Notes][] | [Docs][docs] | [Compatibility Matrix][matrix] | [Download][] | diff --git a/site/content/en/announcements/v1.0.md b/site/content/en/announcements/v1.0.md new file mode 100644 index 00000000000..4a60c1eba29 --- /dev/null +++ b/site/content/en/announcements/v1.0.md @@ -0,0 +1,200 @@ +--- +title: Announcing Envoy Gateway v1.0 +subtitle: GA version +linktitle: Release v1.0 +description: Envoy Gateway v1.0 release announcement. +publishdate: 2024-03-13 +release: v1.0.0 +skip_list: true +--- + +We are thrilled to announce the arrival of Envoy Gateway v1.0.0, marking the official General Availability (GA) milestone for the project! + +This release represents a significant achievement, and we extend our heartfelt gratitude to the entire Envoy Gateway community for their contributions, dedication, and support. Your collaborative efforts have been instrumental in reaching this pivotal release. + +Thank you for being an integral part of this journey. We are excited to see how Envoy Gateway v1.0.0 will empower your operations and look forward to continuing our work together to drive the future of Cloud Native API Gateway. + +| [Release Notes][] | [Docs][docs] | [Compatibility Matrix][matrix] | [Download][] | +|-------------------|--------------|--------------------------------|--------------| + +## What's New + +The release adds a ton of features and functionality. Here are some highlights: + +### Documentation + +- Added User Guide for Local Ratelimit +- Added User Guide for Circuit Breaker +- Added User Guide for fault injection +- Added User Guide for EnvoyProxy extraArgs +- Added User Guide for Timeouts in ClientTrafficPolicy +- Added User Guide for JWT claim base routing +- Added User Guide for HTTP Timeout +- Added User Guide for Retry in BackendTrafficPolicy +- Added User Guide for Basic Auth +- Added User Guide for OIDC +- Added User Guide for ClientTrafficPolicy +- Added User Guide for BackendTrafficPolicy +- Added User Guide for Basic Auth using HTTPS +- Added User Guide for External Authorization +- Added User Guide for Routing Outside Kubernetes +- Added User Guide for BackendTLSPolicy +- Added User Guide for Mutual TLS from External Clients to the Gateway +- Added User Guide for Control Plane Authentication using custom certs +- Added User Guide for Multiple Gatewayclass and Merge Gateways Deployment Mode +- Added `Type` and `required` for CRD API doc +- Refactored Structure of User Guide docs +- Refactored Move Design docs under "Get Involved" +- Updated crd-ref-docs to 0.0.10 +- Updated Envoy proxy image to envoy:distroless-dev in main + +### Installation + +- Added Support for Pulling envoyGateway image from a private registry +- Added Support for Configuring resources for certgen job +- Added Support for Configuring affinity for EnvoyGateway pod + +### API + +- Added Support for Downstream QUIC/HTTP3 in ClientTrafficPolicy CRD +- Added Support for Downstream MTLS in ClientTrafficPolicy CRD +- Added Support for Enabling EnvoyHeaders in ClientTrafficPolicy CRD +- Added Support for DisableMergeSlash and escapedSlashesAction in ClientTrafficPolicy CRD +- Added Support for EnableTrailers in HTTP/1.1 in ClientTrafficPolicy CRD +- Added Support for Preserving header letter-case on HTTP/1 in ClientTrafficPolicy CRD +- Added Support for Enabling HTTP/1.0 and HTTP/0.9 in ClientTrafficPolicy CRD +- Added Support for Client IP Detection using XFF in ClientTrafficPolicy CRD +- Added Support for Client IP Detection using Custom Header in ClientTrafficPolicy CRD +- Added Support for Connection Timeouts in ClientTrafficPolicy CRD +- Added Support for Common TLS configuration properties in ClientTrafficPolicy CRD +- Added Support for Proxy protocol in ClientTrafficPolicy CRD +- Added Support for TCPKeepAlive in ClientTrafficPolicy CRD +- Added Support for Local rate limit in BackendTrafficPolicy CRD +- Added Support for CircuitBreaker in BackendTrafficPolicy CRD +- Added Support for Fault injection in BackendTrafficPolicy CRD +- Added Support for Passive Health Checks in BackendTrafficPolicy CRD +- Added Support for Active Health Checks in BackendTrafficPolicy CRD +- Added Support for Connection Timeouts in BackendTrafficPolicy CRD +- Added Support for Compressor/Decompressor in BackendTrafficPolicy CRD +- Added Support for Retry in BackendTrafficPolicy CRD +- Added Support for Slow start mode in BackendTrafficPolicy CRD +- Added Support for Proxy protocol in BackendTrafficPolicy CRD +- Added Support for TCPKeepAlive in BackendTrafficPolicy CRD +- Added Support for PolicyStatus in BackendTrafficPolicy CRD +- Added Support for PolicyStatus in ClientTrafficPolicy CRD +- Added Support for PolicyStatus in SecurityPolicy CRD +- Added Support for OIDC in SecurityPolicy CRD +- Added Support for Basic Auth in SecurityPolicy CRD +- Added Support for RedirectURL and signoutPath to OIDC in SecurityPolicy CRD +- Added Support for ExtractFrom headers and params to JWT in SecurityPolicy CRD +- Added Support for External Authorization in SecurityPolicy CRD +- Added Support for RecomputeRoute field to JWT in SecurityPolicy CRD +- Added Support for AllowCredentials knob to CORS setting in SecurityPolicy CRD +- Added Support for Extract from different identifier to JWT in SecurityPolicy CRD +- Added Support for Secret resource in EnvoyPatchPolicy CRD +- Added Support for Making the value optional for JSONPatchOperation in EnvoyPatchPolicy CRD +- Added Support for `From` field to JSONPatchOperation in EnvoyPatchPolicy CRD +- Added Support for MergeGateways in EnvoyPatchPolicy CRD +- Added Support for Upstream TLS by implementing BackendTLSPolicy CRD +- Added Support for LabelSelector type for NamespaceSelectors in EnvoyGateway Configuration +- Added Support for Ratelimit prometheus in EnvoyGateway Configuration +- Added Support for Gracefully drain listeners before envoy shutdown on pod termination in EnvoyProxy CRD +- Added Support for Configuring externalTrafficPolicy to the envoy service in EnvoyProxy CRD +- Added Support for Envoy extra args in EnvoyProxy CRD +- Added Support for Mergepatch to envoyproxy/ratelimit deployment in EnvoyProxy CRD +- Added Support for Mergepatch to envoyproxy service in EnvoyProxy CRD +- Added Support for NodeSelector to PodSpec in EnvoyProxy CRD +- Added Support for HorizontalPodAutoscaler in EnvoyProxy CRD +- Added Support for TopologySpreadConstraints to PodSpec in EnvoyProxy CRD +- Added Support for ImagePullSecrets to PodSpec in EnvoyProxy CRD + +### Breaking Changes + +- Use wildcard to match AllowOrigins to CORS in SecurityPolicy CRD +- Remove Hostnetwork support in EnvoyProxy CRD + +### Conformance + +- Replaced backend image from gcr.io/k8s-staging-ingressconformance/echoserver to gcr.io/k8s-staging-gateway-api/echo-basic + +### Testing + +- Added e2e test for Header Case-Preserving +- Added e2e test for Timeout in ClientTrafficPolicy +- Added e2e test for JWT claim base routing +- Added e2e test for OIDC +- Added e2e test for BackendTrafficPolicy Retry +- Added e2e test for Backend Upgrade +- Added e2e test for External Authorization +- Added e2e test for Backend TLS policy +- Added e2e test for Envoy Gateway Release Upgrade +- Added e2e test for Weighted backend +- Added validation for LoadBalancerIP to prevent trailing period + +### Translator + +- Fixed Prefix match to prevent mismatching routes with the same prefix +- Fixed Multiple reconciling by implementing comparable interface for ir.Infra +- Fixed EndpointSlice with empty conditions {} +- Fixed Error handling when parsing the http request timeout +- Fixed No status when EnvoyPatchPolicy is disabled +- Fixed Printable for xds and infra IRs +- Fixed Skip backendRefs with weight set to 0 +- Fixed AND Header matches in ratelimiting not working +- Fixed Deletion logics when no gatewayclasses exist +- Fixed Match mergedGateways irKey for ClientTrafficPolicy +- Fixed Policies should apply only to gateways they were attached to when mergeGateways is true +- Fixed Listener status is not surfaced for gateways when MergeGateways enabled +- Fixed GRPCroute websocket not working by moving web socket upgrade config from hcm to route +- Fixed Configure idle timeout when timeout is set on HTTPRoute +- Fixed Relaxing HTTPS restriction for OIDC token endpoint +- Fixed Panic when translating routes with empty backends +- Fixed Xds translation should be done in a best-effort manner +- Fixed Delete unused status keys from watchable +- Fixed Ignoring finalizers when comparing envoy proxy service +- Fixed Don't override the ALPN array if HTTP/3 is enabled +- Fixed Add h3 ALPN by default if HTTP/3 is enabled +- Fixed Change the Merge behavior to Replace for SecurityPolicy/BackendTrafficPolicy +- Fixed Use service port in alt-svc header if HTTP/3 is enabled +- Fixed Prevent policies targeting non-TLS listeners on the same port from conflicting +- Fixed Skip the ReasonTargetNotFound for all policies +- Fixed Skip publishing empty status for all policies +- Added Support for validating regex before sending to Envoy +- Added Support for setting spec.addresses.value into ClusterIP when Service Type is ClusterIP +- Added Unsupported status condition for filters within BackendRef +- Added List instead of map for Provider Resources for order stability +- Added Suffix for oauth cookies to prevent multiple oauth filters from overwriting each other's cookies +- Added Support for overriding condition to BackendTrafficPolicy and SecurityPolicy +- Added Support for default retry budget and retry host predicate +- Added Support for implementing gateway.spec.infrastructure +- Added Support for Upstream TLS to multiple Backends +- Added Validation for CA Cert in ClientTrafficPolicy + +### Providers + +- Added Support for multiple GatewayClass per controller +- Added SecurityPolicyIndexers in Kubernetes Provider +- Added Support for generating HMAC secret in CertGen Job +- Fixed Finalizer logic when deleting Gatewayclasses +- Fixed MergeGateways panics when restarting control plane + +### XDS + +- Added Support for EDS cache +- Added Support for ADS cache to ensure the rule order +- Fixed Deprecated field error when using RequestHeaderModifier filter +- Fixed Envoy rejects XDS at runtime losing all routes on restart +- Fixed Requests not matching defined routes trigger per-route filters +- Bumped go-control-plane to v0.12.0 + +### CLI + +- Added Support for egctl x status +- Added Support for egctl experimental dashboard envoy-proxy +- Added Support for egctl config ratelimit +- Added Support for egctl translate from gateway-api resources to IR + +[Release Notes]: https://github.com/envoyproxy/gateway/blob/main/release-notes/v1.0.0.yaml +[matrix]: https://gateway.envoyproxy.io/v1.0.0/install/matrix/ +[docs]: https://gateway.envoyproxy.io/v1.0.0/index.html +[Download]: https://github.com/envoyproxy/gateway/releases/tag/v1.0.0 diff --git a/site/content/en/latest/contributions/_index.md b/site/content/en/latest/contributions/_index.md index 3255d996472..1d3037e609e 100644 --- a/site/content/en/latest/contributions/_index.md +++ b/site/content/en/latest/contributions/_index.md @@ -1,5 +1,5 @@ --- title: Get Involved -description: "This section includes contents related to **Contributions**" +description: "This section includes contents related to Contributions" weight: 100 --- diff --git a/site/content/en/latest/contributions/design/_index.md b/site/content/en/latest/contributions/design/_index.md index 2820db4c216..5cacb86df70 100644 --- a/site/content/en/latest/contributions/design/_index.md +++ b/site/content/en/latest/contributions/design/_index.md @@ -1,5 +1,5 @@ --- title: "Design" -weight: 1 +weight: -100 description: This section includes Designs of Envoy Gateway. --- diff --git a/site/content/en/latest/releases/v1.0.0.md b/site/content/en/latest/releases/v1.0.0.md new file mode 100644 index 00000000000..134a7f23071 --- /dev/null +++ b/site/content/en/latest/releases/v1.0.0.md @@ -0,0 +1,170 @@ +--- +title: "v1.0.0" +publishdate: 2023-11-01 +--- + +Date: Nov 1, 2023 + +## Documentation +- Added User Guide for Local Ratelimit +- Added User Guide for Circuit Breaker +- Added User Guide for fault injection +- Added User Guide for EnvoyProxy extraArgs +- Added User Guide for Timeouts in ClientTrafficPolicy +- Added User Guide for JWT claim base routing +- Added User Guide for HTTP Timeout +- Added User Guide for Retry in BackendTrafficPolicy +- Added User Guide for Basic Auth +- Added User Guide for OIDC +- Added User Guide for ClientTrafficPolicy +- Added User Guide for BackendTrafficPolicy +- Added User Guide for Basic Auth using HTTPS +- Added User Guide for External Authorization +- Added User Guide for Routing Outside Kubernetes +- Added User Guide for BackendTLSPolicy +- Added User Guide for Mutual TLS from External Clients to the Gateway +- Added User Guide for Control Plane Authentication using custom certs +- Added User Guide for Multiple Gatewayclass and Merge Gateways Deployment Mode +- Added `Type` and `required` for CRD API doc +- Refactored Structure of User Guide docs +- Refactored Move Design docs under "Get Involved" +- Updated crd-ref-docs to 0.0.10 +- Updated Envoy proxy image to envoy:distroless-dev in main + +## Installation +- Added Support for Pulling envoyGateway image from a private registry +- Added Support for Configuring resources for certgen job +- Added Support for Configuring affinity for EnvoyGateway pod + +## API +- Added Support for Downstream QUIC/HTTP3 in ClientTrafficPolicy CRD +- Added Support for Downstream MTLS in ClientTrafficPolicy CRD +- Added Support for Enabling EnvoyHeaders in ClientTrafficPolicy CRD +- Added Support for DisableMergeSlash and escapedSlashesAction in ClientTrafficPolicy CRD +- Added Support for EnableTrailers in HTTP/1.1 in ClientTrafficPolicy CRD +- Added Support for Preserving header letter-case on HTTP/1 in ClientTrafficPolicy CRD +- Added Support for Enabling HTTP/1.0 and HTTP/0.9 in ClientTrafficPolicy CRD +- Added Support for Client IP Detection using XFF in ClientTrafficPolicy CRD +- Added Support for Client IP Detection using Custom Header in ClientTrafficPolicy CRD +- Added Support for Connection Timeouts in ClientTrafficPolicy CRD +- Added Support for Common TLS configuration properties in ClientTrafficPolicy CRD +- Added Support for Proxy protocol in ClientTrafficPolicy CRD +- Added Support for TCPKeepAlive in ClientTrafficPolicy CRD +- Added Support for Local rate limit in BackendTrafficPolicy CRD +- Added Support for CircuitBreaker in BackendTrafficPolicy CRD +- Added Support for Fault injection in BackendTrafficPolicy CRD +- Added Support for Passive Health Checks in BackendTrafficPolicy CRD +- Added Support for Active Health Checks in BackendTrafficPolicy CRD +- Added Support for Connection Timeouts in BackendTrafficPolicy CRD +- Added Support for Compressor/Decompressor in BackendTrafficPolicy CRD +- Added Support for Retry in BackendTrafficPolicy CRD +- Added Support for Slow start mode in BackendTrafficPolicy CRD +- Added Support for Proxy protocol in BackendTrafficPolicy CRD +- Added Support for TCPKeepAlive in BackendTrafficPolicy CRD +- Added Support for PolicyStatus in BackendTrafficPolicy CRD +- Added Support for PolicyStatus in ClientTrafficPolicy CRD +- Added Support for PolicyStatus in SecurityPolicy CRD +- Added Support for OIDC in SecurityPolicy CRD +- Added Support for Basic Auth in SecurityPolicy CRD +- Added Support for RedirectURL and signoutPath to OIDC in SecurityPolicy CRD +- Added Support for ExtractFrom headers and params to JWT in SecurityPolicy CRD +- Added Support for External Authorization in SecurityPolicy CRD +- Added Support for RecomputeRoute field to JWT in SecurityPolicy CRD +- Added Support for AllowCredentials knob to CORS setting in SecurityPolicy CRD +- Added Support for Extract from different identifier to JWT in SecurityPolicy CRD +- Added Support for Secret resource in EnvoyPatchPolicy CRD +- Added Support for Making the value optional for JSONPatchOperation in EnvoyPatchPolicy CRD +- Added Support for `From` field to JSONPatchOperation in EnvoyPatchPolicy CRD +- Added Support for MergeGateways in EnvoyPatchPolicy CRD +- Added Support for Upstream TLS by implementing BackendTLSPolicy CRD +- Added Support for LabelSelector type for NamespaceSelectors in EnvoyGateway Configuration +- Added Support for Ratelimit prometheus in EnvoyGateway Configuration +- Added Support for Gracefully drain listeners before envoy shutdown on pod termination in EnvoyProxy CRD +- Added Support for Configuring externalTrafficPolicy to the envoy service in EnvoyProxy CRD +- Added Support for Envoy extra args in EnvoyProxy CRD +- Added Support for Mergepatch to envoyproxy/ratelimit deployment in EnvoyProxy CRD +- Added Support for Mergepatch to envoyproxy service in EnvoyProxy CRD +- Added Support for NodeSelector to PodSpec in EnvoyProxy CRD +- Added Support for HorizontalPodAutoscaler in EnvoyProxy CRD +- Added Support for TopologySpreadConstraints to PodSpec in EnvoyProxy CRD +- Added Support for ImagePullSecrets to PodSpec in EnvoyProxy CRD + +### Breaking Changes +- Use wildcard to match AllowOrigins to CORS in SecurityPolicy CRD +- Remove Hostnetwork support in EnvoyProxy CRD + +## Conformance +- Replaced backend image from gcr.io/k8s-staging-ingressconformance/echoserver to gcr.io/k8s-staging-gateway-api/echo-basic + +## Testing +- Added e2e test for Header Case-Preserving +- Added e2e test for Timeout in ClientTrafficPolicy +- Added e2e test for JWT claim base routing +- Added e2e test for OIDC +- Added e2e test for BackendTrafficPolicy Retry +- Added e2e test for Backend Upgrade +- Added e2e test for External Authorization +- Added e2e test for Backend TLS policy +- Added e2e test for Envoy Gateway Release Upgrade +- Added e2e test for Weighted backend +- Added validation for LoadBalancerIP to prevent trailing period + +## Translator +- Fixed Prefix match to prevent mismatching routes with the same prefix +- Fixed Multiple reconciling by implementing comparable interface for ir.Infra +- Fixed EndpointSlice with empty conditions {} +- Fixed Error handling when parsing the http request timeout +- Fixed No status when EnvoyPatchPolicy is disabled +- Fixed Printable for xds and infra IRs +- Fixed Skip backendRefs with weight set to 0 +- Fixed AND Header matches in ratelimiting not working +- Fixed Deletion logics when no gatewayclasses exist +- Fixed Match mergedGateways irKey for ClientTrafficPolicy +- Fixed Policies should apply only to gateways they were attached to when mergeGateways is true +- Fixed Listener status is not surfaced for gateways when MergeGateways enabled +- Fixed GRPCroute websocket not working by moving web socket upgrade config from hcm to route +- Fixed Configure idle timeout when timeout is set on HTTPRoute +- Fixed Relaxing HTTPS restriction for OIDC token endpoint +- Fixed Panic when translating routes with empty backends +- Fixed Xds translation should be done in a best-effort manner +- Fixed Delete unused status keys from watchable +- Fixed Ignoring finalizers when comparing envoy proxy service +- Fixed Don't override the ALPN array if HTTP/3 is enabled +- Fixed Add h3 ALPN by default if HTTP/3 is enabled +- Fixed Change the Merge behavior to Replace for SecurityPolicy/BackendTrafficPolicy +- Fixed Use service port in alt-svc header if HTTP/3 is enabled +- Fixed Prevent policies targeting non-TLS listeners on the same port from conflicting +- Fixed Skip the ReasonTargetNotFound for all policies +- Fixed Skip publishing empty status for all policies +- Added Support for validating regex before sending to Envoy +- Added Support for setting spec.addresses.value into ClusterIP when Service Type is ClusterIP +- Added Unsupported status condition for filters within BackendRef +- Added List instead of map for Provider Resources for order stability +- Added Suffix for oauth cookies to prevent multiple oauth filters from overwriting each other's cookies +- Added Support for overriding condition to BackendTrafficPolicy and SecurityPolicy +- Added Support for default retry budget and retry host predicate +- Added Support for implementing gateway.spec.infrastructure +- Added Support for Upstream TLS to multiple Backends +- Added Validation for CA Cert in ClientTrafficPolicy + +## Providers +- Added Support for multiple GatewayClass per controller +- Added SecurityPolicyIndexers in Kubernetes Provider +- Added Support for generating HMAC secret in CertGen Job +- Fixed Finalizer logic when deleting Gatewayclasses +- Fixed MergeGateways panics when restarting control plane + +## xDS +- Added Support for EDS cache +- Added Support for ADS cache to ensure the rule order +- Fixed Deprecated field error when using RequestHeaderModifier filter +- Fixed Envoy rejects XDS at runtime losing all routes on restart +- Fixed Requests not matching defined routes trigger per-route filters +- Bumped go-control-plane to v0.12.0 + +## Cli +- Added Support for egctl x status +- Added Support for egctl experimental dashboard envoy-proxy +- Added Support for egctl config ratelimit +- Added Support for egctl translate from gateway-api resources to IR + diff --git a/site/content/en/v1.0.0/_index.md b/site/content/en/v1.0.0/_index.md new file mode 100644 index 00000000000..567b43bfe36 --- /dev/null +++ b/site/content/en/v1.0.0/_index.md @@ -0,0 +1,21 @@ ++++ +title = "Welcome to Envoy Gateway" +linktitle = "Documentation" +description = "Envoy Gateway Documents" + +[[cascade]] +type = "docs" ++++ + +{{% alert title="Note" color="primary" %}} + +This project is under **active** development. Many features are not complete. We would love for you to [Get Involved](contributions/)! + +{{% /alert %}} + +Envoy Gateway is an open source project for managing [Envoy Proxy](https://www.envoyproxy.io/) as a standalone or Kubernetes-based application +gateway. [Gateway API](https://gateway-api.sigs.k8s.io/) resources are used to dynamically provision and configure the managed Envoy Proxies. + +![architecture](/img/traffic.png) + +## Ready to get started? diff --git a/site/content/en/v1.0.0/api/_index.md b/site/content/en/v1.0.0/api/_index.md new file mode 100644 index 00000000000..396d9ffcefc --- /dev/null +++ b/site/content/en/v1.0.0/api/_index.md @@ -0,0 +1,5 @@ +--- +title: "API" +description: This section includes APIs of Envoy Gateway. +weight: 80 +--- diff --git a/site/content/en/v1.0.0/api/extension_types.md b/site/content/en/v1.0.0/api/extension_types.md new file mode 100644 index 00000000000..e1e68576a66 --- /dev/null +++ b/site/content/en/v1.0.0/api/extension_types.md @@ -0,0 +1,2573 @@ ++++ +title = "API Reference" ++++ + + +## Packages +- [gateway.envoyproxy.io/v1alpha1](#gatewayenvoyproxyiov1alpha1) + + +## gateway.envoyproxy.io/v1alpha1 + +Package v1alpha1 contains API schema definitions for the gateway.envoyproxy.io +API group. + + +### Resource Types +- [BackendTrafficPolicy](#backendtrafficpolicy) +- [BackendTrafficPolicyList](#backendtrafficpolicylist) +- [ClientTrafficPolicy](#clienttrafficpolicy) +- [ClientTrafficPolicyList](#clienttrafficpolicylist) +- [EnvoyGateway](#envoygateway) +- [EnvoyPatchPolicy](#envoypatchpolicy) +- [EnvoyPatchPolicyList](#envoypatchpolicylist) +- [EnvoyProxy](#envoyproxy) +- [SecurityPolicy](#securitypolicy) +- [SecurityPolicyList](#securitypolicylist) + + + +#### ALPNProtocol + +_Underlying type:_ _string_ + +ALPNProtocol specifies the protocol to be negotiated using ALPN + +_Appears in:_ +- [TLSSettings](#tlssettings) + + + +#### ActiveHealthCheck + + + +ActiveHealthCheck defines the active health check configuration. EG supports various types of active health checking including HTTP, TCP. + +_Appears in:_ +- [HealthCheck](#healthcheck) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `timeout` | _[Duration](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.26/#duration-v1-meta)_ | false | Timeout defines the time to wait for a health check response. | +| `interval` | _[Duration](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.26/#duration-v1-meta)_ | false | Interval defines the time between active health checks. | +| `unhealthyThreshold` | _integer_ | false | UnhealthyThreshold defines the number of unhealthy health checks required before a backend host is marked unhealthy. | +| `healthyThreshold` | _integer_ | false | HealthyThreshold defines the number of healthy health checks required before a backend host is marked healthy. | +| `type` | _[ActiveHealthCheckerType](#activehealthcheckertype)_ | true | Type defines the type of health checker. | +| `http` | _[HTTPActiveHealthChecker](#httpactivehealthchecker)_ | false | HTTP defines the configuration of http health checker. It's required while the health checker type is HTTP. | +| `tcp` | _[TCPActiveHealthChecker](#tcpactivehealthchecker)_ | false | TCP defines the configuration of tcp health checker. It's required while the health checker type is TCP. | + + +#### ActiveHealthCheckPayload + + + +ActiveHealthCheckPayload defines the encoding of the payload bytes in the payload. + +_Appears in:_ +- [HTTPActiveHealthChecker](#httpactivehealthchecker) +- [TCPActiveHealthChecker](#tcpactivehealthchecker) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `type` | _[ActiveHealthCheckPayloadType](#activehealthcheckpayloadtype)_ | true | Type defines the type of the payload. | +| `text` | _string_ | false | Text payload in plain text. | +| `binary` | _integer array_ | false | Binary payload base64 encoded. | + + +#### ActiveHealthCheckPayloadType + +_Underlying type:_ _string_ + +ActiveHealthCheckPayloadType is the type of the payload. + +_Appears in:_ +- [ActiveHealthCheckPayload](#activehealthcheckpayload) + + + +#### ActiveHealthCheckerType + +_Underlying type:_ _string_ + +ActiveHealthCheckerType is the type of health checker. + +_Appears in:_ +- [ActiveHealthCheck](#activehealthcheck) + + + +#### BackOffPolicy + + + + + +_Appears in:_ +- [PerRetryPolicy](#perretrypolicy) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `baseInterval` | _[Duration](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.26/#duration-v1-meta)_ | true | BaseInterval is the base interval between retries. | +| `maxInterval` | _[Duration](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.26/#duration-v1-meta)_ | false | MaxInterval is the maximum interval between retries. This parameter is optional, but must be greater than or equal to the base_interval if set. The default is 10 times the base_interval | + + +#### BackendTrafficPolicy + + + +BackendTrafficPolicy allows the user to configure the behavior of the connection between the Envoy Proxy listener and the backend service. + +_Appears in:_ +- [BackendTrafficPolicyList](#backendtrafficpolicylist) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `apiVersion` | _string_ | |`gateway.envoyproxy.io/v1alpha1` +| `kind` | _string_ | |`BackendTrafficPolicy` +| `metadata` | _[ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.26/#objectmeta-v1-meta)_ | true | Refer to Kubernetes API documentation for fields of `metadata`. | +| `spec` | _[BackendTrafficPolicySpec](#backendtrafficpolicyspec)_ | true | spec defines the desired state of BackendTrafficPolicy. | + + +#### BackendTrafficPolicyList + + + +BackendTrafficPolicyList contains a list of BackendTrafficPolicy resources. + + + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `apiVersion` | _string_ | |`gateway.envoyproxy.io/v1alpha1` +| `kind` | _string_ | |`BackendTrafficPolicyList` +| `metadata` | _[ListMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.26/#listmeta-v1-meta)_ | true | Refer to Kubernetes API documentation for fields of `metadata`. | +| `items` | _[BackendTrafficPolicy](#backendtrafficpolicy) array_ | true | | + + +#### BackendTrafficPolicySpec + + + +spec defines the desired state of BackendTrafficPolicy. + +_Appears in:_ +- [BackendTrafficPolicy](#backendtrafficpolicy) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `targetRef` | _[PolicyTargetReferenceWithSectionName](https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1alpha2.PolicyTargetReferenceWithSectionName)_ | true | targetRef is the name of the resource this policy is being attached to. This Policy and the TargetRef MUST be in the same namespace for this Policy to have effect and be applied to the Gateway. | +| `rateLimit` | _[RateLimitSpec](#ratelimitspec)_ | false | RateLimit allows the user to limit the number of incoming requests to a predefined value based on attributes within the traffic flow. | +| `loadBalancer` | _[LoadBalancer](#loadbalancer)_ | false | LoadBalancer policy to apply when routing traffic from the gateway to the backend endpoints | +| `proxyProtocol` | _[ProxyProtocol](#proxyprotocol)_ | false | ProxyProtocol enables the Proxy Protocol when communicating with the backend. | +| `tcpKeepalive` | _[TCPKeepalive](#tcpkeepalive)_ | false | TcpKeepalive settings associated with the upstream client connection. Disabled by default. | +| `healthCheck` | _[HealthCheck](#healthcheck)_ | false | HealthCheck allows gateway to perform active health checking on backends. | +| `faultInjection` | _[FaultInjection](#faultinjection)_ | false | FaultInjection defines the fault injection policy to be applied. This configuration can be used to inject delays and abort requests to mimic failure scenarios such as service failures and overloads | +| `circuitBreaker` | _[CircuitBreaker](#circuitbreaker)_ | false | Circuit Breaker settings for the upstream connections and requests. If not set, circuit breakers will be enabled with the default thresholds | +| `retry` | _[Retry](#retry)_ | false | Retry provides more advanced usage, allowing users to customize the number of retries, retry fallback strategy, and retry triggering conditions. If not set, retry will be disabled. | +| `timeout` | _[Timeout](#timeout)_ | false | Timeout settings for the backend connections. | +| `compression` | _[Compression](#compression) array_ | false | The compression config for the http streams. | + + +#### BasicAuth + + + +BasicAuth defines the configuration for the HTTP Basic Authentication. + +_Appears in:_ +- [SecurityPolicySpec](#securitypolicyspec) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `users` | _[SecretObjectReference](https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1.SecretObjectReference)_ | true | The Kubernetes secret which contains the username-password pairs in htpasswd format, used to verify user credentials in the "Authorization" header.

This is an Opaque secret. The username-password pairs should be stored in the key ".htpasswd". As the key name indicates, the value needs to be the htpasswd format, for example: "user1:{SHA}hashed_user1_password". Right now, only SHA hash algorithm is supported. Reference to https://httpd.apache.org/docs/2.4/programs/htpasswd.html for more details.

Note: The secret must be in the same namespace as the SecurityPolicy. | + + +#### BootstrapType + +_Underlying type:_ _string_ + +BootstrapType defines the types of bootstrap supported by Envoy Gateway. + +_Appears in:_ +- [ProxyBootstrap](#proxybootstrap) + + + +#### CORS + + + +CORS defines the configuration for Cross-Origin Resource Sharing (CORS). + +_Appears in:_ +- [SecurityPolicySpec](#securitypolicyspec) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `allowOrigins` | _[Origin](#origin) array_ | true | AllowOrigins defines the origins that are allowed to make requests. | +| `allowMethods` | _string array_ | true | AllowMethods defines the methods that are allowed to make requests. | +| `allowHeaders` | _string array_ | true | AllowHeaders defines the headers that are allowed to be sent with requests. | +| `exposeHeaders` | _string array_ | true | ExposeHeaders defines the headers that can be exposed in the responses. | +| `maxAge` | _[Duration](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.26/#duration-v1-meta)_ | true | MaxAge defines how long the results of a preflight request can be cached. | +| `allowCredentials` | _boolean_ | true | AllowCredentials indicates whether a request can include user credentials like cookies, authentication headers, or TLS client certificates. | + + +#### CircuitBreaker + + + +CircuitBreaker defines the Circuit Breaker configuration. + +_Appears in:_ +- [BackendTrafficPolicySpec](#backendtrafficpolicyspec) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `maxConnections` | _integer_ | false | The maximum number of connections that Envoy will establish to the referenced backend defined within a xRoute rule. | +| `maxPendingRequests` | _integer_ | false | The maximum number of pending requests that Envoy will queue to the referenced backend defined within a xRoute rule. | +| `maxParallelRequests` | _integer_ | false | The maximum number of parallel requests that Envoy will make to the referenced backend defined within a xRoute rule. | +| `maxParallelRetries` | _integer_ | false | The maximum number of parallel retries that Envoy will make to the referenced backend defined within a xRoute rule. | +| `maxRequestsPerConnection` | _integer_ | false | The maximum number of requests that Envoy will make over a single connection to the referenced backend defined within a xRoute rule. Default: unlimited. | + + +#### ClaimToHeader + + + +ClaimToHeader defines a configuration to convert JWT claims into HTTP headers + +_Appears in:_ +- [JWTProvider](#jwtprovider) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `header` | _string_ | true | Header defines the name of the HTTP request header that the JWT Claim will be saved into. | +| `claim` | _string_ | true | Claim is the JWT Claim that should be saved into the header : it can be a nested claim of type (eg. "claim.nested.key", "sub"). The nested claim name must use dot "." to separate the JSON name path. | + + +#### ClientIPDetectionSettings + + + +ClientIPDetectionSettings provides configuration for determining the original client IP address for requests. + +_Appears in:_ +- [ClientTrafficPolicySpec](#clienttrafficpolicyspec) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `xForwardedFor` | _[XForwardedForSettings](#xforwardedforsettings)_ | false | XForwardedForSettings provides configuration for using X-Forwarded-For headers for determining the client IP address. | +| `customHeader` | _[CustomHeaderExtensionSettings](#customheaderextensionsettings)_ | false | CustomHeader provides configuration for determining the client IP address for a request based on a trusted custom HTTP header. This uses the the custom_header original IP detection extension. Refer to https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/http/original_ip_detection/custom_header/v3/custom_header.proto for more details. | + + +#### ClientTimeout + + + + + +_Appears in:_ +- [ClientTrafficPolicySpec](#clienttrafficpolicyspec) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `http` | _[HTTPClientTimeout](#httpclienttimeout)_ | false | Timeout settings for HTTP. | + + +#### ClientTrafficPolicy + + + +ClientTrafficPolicy allows the user to configure the behavior of the connection between the downstream client and Envoy Proxy listener. + +_Appears in:_ +- [ClientTrafficPolicyList](#clienttrafficpolicylist) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `apiVersion` | _string_ | |`gateway.envoyproxy.io/v1alpha1` +| `kind` | _string_ | |`ClientTrafficPolicy` +| `metadata` | _[ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.26/#objectmeta-v1-meta)_ | true | Refer to Kubernetes API documentation for fields of `metadata`. | +| `spec` | _[ClientTrafficPolicySpec](#clienttrafficpolicyspec)_ | true | Spec defines the desired state of ClientTrafficPolicy. | + + +#### ClientTrafficPolicyList + + + +ClientTrafficPolicyList contains a list of ClientTrafficPolicy resources. + + + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `apiVersion` | _string_ | |`gateway.envoyproxy.io/v1alpha1` +| `kind` | _string_ | |`ClientTrafficPolicyList` +| `metadata` | _[ListMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.26/#listmeta-v1-meta)_ | true | Refer to Kubernetes API documentation for fields of `metadata`. | +| `items` | _[ClientTrafficPolicy](#clienttrafficpolicy) array_ | true | | + + +#### ClientTrafficPolicySpec + + + +ClientTrafficPolicySpec defines the desired state of ClientTrafficPolicy. + +_Appears in:_ +- [ClientTrafficPolicy](#clienttrafficpolicy) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `targetRef` | _[PolicyTargetReferenceWithSectionName](https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1alpha2.PolicyTargetReferenceWithSectionName)_ | true | TargetRef is the name of the Gateway resource this policy is being attached to. This Policy and the TargetRef MUST be in the same namespace for this Policy to have effect and be applied to the Gateway. TargetRef | +| `tcpKeepalive` | _[TCPKeepalive](#tcpkeepalive)_ | false | TcpKeepalive settings associated with the downstream client connection. If defined, sets SO_KEEPALIVE on the listener socket to enable TCP Keepalives. Disabled by default. | +| `enableProxyProtocol` | _boolean_ | false | EnableProxyProtocol interprets the ProxyProtocol header and adds the Client Address into the X-Forwarded-For header. Note Proxy Protocol must be present when this field is set, else the connection is closed. | +| `clientIPDetection` | _[ClientIPDetectionSettings](#clientipdetectionsettings)_ | false | ClientIPDetectionSettings provides configuration for determining the original client IP address for requests. | +| `http3` | _[HTTP3Settings](#http3settings)_ | false | HTTP3 provides HTTP/3 configuration on the listener. | +| `tls` | _[TLSSettings](#tlssettings)_ | false | TLS settings configure TLS termination settings with the downstream client. | +| `path` | _[PathSettings](#pathsettings)_ | false | Path enables managing how the incoming path set by clients can be normalized. | +| `http1` | _[HTTP1Settings](#http1settings)_ | false | HTTP1 provides HTTP/1 configuration on the listener. | +| `headers` | _[HeaderSettings](#headersettings)_ | false | HeaderSettings provides configuration for header management. | +| `timeout` | _[ClientTimeout](#clienttimeout)_ | false | Timeout settings for the client connections. | + + +#### ClientValidationContext + + + +ClientValidationContext holds configuration that can be used to validate the client initiating the TLS connection to the Gateway. By default, no client specific configuration is validated. + +_Appears in:_ +- [TLSSettings](#tlssettings) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `caCertificateRefs` | _[SecretObjectReference](https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1.SecretObjectReference) array_ | false | CACertificateRefs contains one or more references to Kubernetes objects that contain TLS certificates of the Certificate Authorities that can be used as a trust anchor to validate the certificates presented by the client.

A single reference to a Kubernetes ConfigMap or a Kubernetes Secret, with the CA certificate in a key named `ca.crt` is currently supported.

References to a resource in different namespace are invalid UNLESS there is a ReferenceGrant in the target namespace that allows the certificate to be attached. | + + +#### Compression + + + +Compression defines the config of enabling compression. This can help reduce the bandwidth at the expense of higher CPU. + +_Appears in:_ +- [BackendTrafficPolicySpec](#backendtrafficpolicyspec) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `type` | _[CompressorType](#compressortype)_ | true | CompressorType defines the compressor type to use for compression. | +| `gzip` | _[GzipCompressor](#gzipcompressor)_ | false | The configuration for GZIP compressor. | + + +#### CompressorType + +_Underlying type:_ _string_ + +CompressorType defines the types of compressor library supported by Envoy Gateway. + +_Appears in:_ +- [Compression](#compression) + + + +#### ConsistentHash + + + +ConsistentHash defines the configuration related to the consistent hash load balancer policy + +_Appears in:_ +- [LoadBalancer](#loadbalancer) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `type` | _[ConsistentHashType](#consistenthashtype)_ | true | | + + +#### ConsistentHashType + +_Underlying type:_ _string_ + +ConsistentHashType defines the type of input to hash on. + +_Appears in:_ +- [ConsistentHash](#consistenthash) + + + +#### CustomHeaderExtensionSettings + + + +CustomHeader provides configuration for determining the client IP address for a request based on a trusted custom HTTP header. This uses the the custom_header original IP detection extension. Refer to https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/http/original_ip_detection/custom_header/v3/custom_header.proto for more details. + +_Appears in:_ +- [ClientIPDetectionSettings](#clientipdetectionsettings) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `name` | _string_ | true | Name of the header containing the original downstream remote address, if present. | +| `failClosed` | _boolean_ | false | FailClosed is a switch used to control the flow of traffic when client IP detection fails. If set to true, the listener will respond with 403 Forbidden when the client IP address cannot be determined. | + + +#### CustomTag + + + + + +_Appears in:_ +- [ProxyTracing](#proxytracing) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `type` | _[CustomTagType](#customtagtype)_ | true | Type defines the type of custom tag. | +| `literal` | _[LiteralCustomTag](#literalcustomtag)_ | true | Literal adds hard-coded value to each span. It's required when the type is "Literal". | +| `environment` | _[EnvironmentCustomTag](#environmentcustomtag)_ | true | Environment adds value from environment variable to each span. It's required when the type is "Environment". | +| `requestHeader` | _[RequestHeaderCustomTag](#requestheadercustomtag)_ | true | RequestHeader adds value from request header to each span. It's required when the type is "RequestHeader". | + + +#### CustomTagType + +_Underlying type:_ _string_ + + + +_Appears in:_ +- [CustomTag](#customtag) + + + +#### EnvironmentCustomTag + + + +EnvironmentCustomTag adds value from environment variable to each span. + +_Appears in:_ +- [CustomTag](#customtag) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `name` | _string_ | true | Name defines the name of the environment variable which to extract the value from. | +| `defaultValue` | _string_ | false | DefaultValue defines the default value to use if the environment variable is not set. | + + +#### EnvoyGateway + + + +EnvoyGateway is the schema for the envoygateways API. + + + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `apiVersion` | _string_ | |`gateway.envoyproxy.io/v1alpha1` +| `kind` | _string_ | |`EnvoyGateway` +| `gateway` | _[Gateway](#gateway)_ | false | Gateway defines desired Gateway API specific configuration. If unset, default configuration parameters will apply. | +| `provider` | _[EnvoyGatewayProvider](#envoygatewayprovider)_ | false | Provider defines the desired provider and provider-specific configuration. If unspecified, the Kubernetes provider is used with default configuration parameters. | +| `logging` | _[EnvoyGatewayLogging](#envoygatewaylogging)_ | false | Logging defines logging parameters for Envoy Gateway. | +| `admin` | _[EnvoyGatewayAdmin](#envoygatewayadmin)_ | false | Admin defines the desired admin related abilities. If unspecified, the Admin is used with default configuration parameters. | +| `telemetry` | _[EnvoyGatewayTelemetry](#envoygatewaytelemetry)_ | false | Telemetry defines the desired control plane telemetry related abilities. If unspecified, the telemetry is used with default configuration. | +| `rateLimit` | _[RateLimit](#ratelimit)_ | false | RateLimit defines the configuration associated with the Rate Limit service deployed by Envoy Gateway required to implement the Global Rate limiting functionality. The specific rate limit service used here is the reference implementation in Envoy. For more details visit https://github.com/envoyproxy/ratelimit. This configuration is unneeded for "Local" rate limiting. | +| `extensionManager` | _[ExtensionManager](#extensionmanager)_ | false | ExtensionManager defines an extension manager to register for the Envoy Gateway Control Plane. | +| `extensionApis` | _[ExtensionAPISettings](#extensionapisettings)_ | false | ExtensionAPIs defines the settings related to specific Gateway API Extensions implemented by Envoy Gateway | + + +#### EnvoyGatewayAdmin + + + +EnvoyGatewayAdmin defines the Envoy Gateway Admin configuration. + +_Appears in:_ +- [EnvoyGateway](#envoygateway) +- [EnvoyGatewaySpec](#envoygatewayspec) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `address` | _[EnvoyGatewayAdminAddress](#envoygatewayadminaddress)_ | false | Address defines the address of Envoy Gateway Admin Server. | +| `enableDumpConfig` | _boolean_ | false | EnableDumpConfig defines if enable dump config in Envoy Gateway logs. | +| `enablePprof` | _boolean_ | false | EnablePprof defines if enable pprof in Envoy Gateway Admin Server. | + + +#### EnvoyGatewayAdminAddress + + + +EnvoyGatewayAdminAddress defines the Envoy Gateway Admin Address configuration. + +_Appears in:_ +- [EnvoyGatewayAdmin](#envoygatewayadmin) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `port` | _integer_ | false | Port defines the port the admin server is exposed on. | +| `host` | _string_ | false | Host defines the admin server hostname. | + + +#### EnvoyGatewayCustomProvider + + + +EnvoyGatewayCustomProvider defines configuration for the Custom provider. + +_Appears in:_ +- [EnvoyGatewayProvider](#envoygatewayprovider) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `resource` | _[EnvoyGatewayResourceProvider](#envoygatewayresourceprovider)_ | true | Resource defines the desired resource provider. This provider is used to specify the provider to be used to retrieve the resource configurations such as Gateway API resources | +| `infrastructure` | _[EnvoyGatewayInfrastructureProvider](#envoygatewayinfrastructureprovider)_ | true | Infrastructure defines the desired infrastructure provider. This provider is used to specify the provider to be used to provide an environment to deploy the out resources like the Envoy Proxy data plane. | + + +#### EnvoyGatewayFileResourceProvider + + + +EnvoyGatewayFileResourceProvider defines configuration for the File Resource provider. + +_Appears in:_ +- [EnvoyGatewayResourceProvider](#envoygatewayresourceprovider) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `paths` | _string array_ | true | Paths are the paths to a directory or file containing the resource configuration. Recursive sub directories are not currently supported. | + + +#### EnvoyGatewayHostInfrastructureProvider + + + +EnvoyGatewayHostInfrastructureProvider defines configuration for the Host Infrastructure provider. + +_Appears in:_ +- [EnvoyGatewayInfrastructureProvider](#envoygatewayinfrastructureprovider) + + + +#### EnvoyGatewayInfrastructureProvider + + + +EnvoyGatewayInfrastructureProvider defines configuration for the Custom Infrastructure provider. + +_Appears in:_ +- [EnvoyGatewayCustomProvider](#envoygatewaycustomprovider) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `type` | _[InfrastructureProviderType](#infrastructureprovidertype)_ | true | Type is the type of infrastructure providers to use. Supported types are "Host". | +| `host` | _[EnvoyGatewayHostInfrastructureProvider](#envoygatewayhostinfrastructureprovider)_ | false | Host defines the configuration of the Host provider. Host provides runtime deployment of the data plane as a child process on the host environment. | + + +#### EnvoyGatewayKubernetesProvider + + + +EnvoyGatewayKubernetesProvider defines configuration for the Kubernetes provider. + +_Appears in:_ +- [EnvoyGatewayProvider](#envoygatewayprovider) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `rateLimitDeployment` | _[KubernetesDeploymentSpec](#kubernetesdeploymentspec)_ | false | RateLimitDeployment defines the desired state of the Envoy ratelimit deployment resource. If unspecified, default settings for the managed Envoy ratelimit deployment resource are applied. | +| `watch` | _[KubernetesWatchMode](#kuberneteswatchmode)_ | false | Watch holds configuration of which input resources should be watched and reconciled. | +| `deploy` | _[KubernetesDeployMode](#kubernetesdeploymode)_ | false | Deploy holds configuration of how output managed resources such as the Envoy Proxy data plane should be deployed | +| `overwriteControlPlaneCerts` | _boolean_ | false | OverwriteControlPlaneCerts updates the secrets containing the control plane certs, when set. | + + +#### EnvoyGatewayLogComponent + +_Underlying type:_ _string_ + +EnvoyGatewayLogComponent defines a component that supports a configured logging level. + +_Appears in:_ +- [EnvoyGatewayLogging](#envoygatewaylogging) + + + +#### EnvoyGatewayLogging + + + +EnvoyGatewayLogging defines logging for Envoy Gateway. + +_Appears in:_ +- [EnvoyGateway](#envoygateway) +- [EnvoyGatewaySpec](#envoygatewayspec) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `level` | _object (keys:[EnvoyGatewayLogComponent](#envoygatewaylogcomponent), values:[LogLevel](#loglevel))_ | true | Level is the logging level. If unspecified, defaults to "info". EnvoyGatewayLogComponent options: default/provider/gateway-api/xds-translator/xds-server/infrastructure/global-ratelimit. LogLevel options: debug/info/error/warn. | + + +#### EnvoyGatewayMetricSink + + + +EnvoyGatewayMetricSink defines control plane metric sinks where metrics are sent to. + +_Appears in:_ +- [EnvoyGatewayMetrics](#envoygatewaymetrics) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `type` | _[MetricSinkType](#metricsinktype)_ | true | Type defines the metric sink type. EG control plane currently supports OpenTelemetry. | +| `openTelemetry` | _[EnvoyGatewayOpenTelemetrySink](#envoygatewayopentelemetrysink)_ | true | OpenTelemetry defines the configuration for OpenTelemetry sink. It's required if the sink type is OpenTelemetry. | + + +#### EnvoyGatewayMetrics + + + +EnvoyGatewayMetrics defines control plane push/pull metrics configurations. + +_Appears in:_ +- [EnvoyGatewayTelemetry](#envoygatewaytelemetry) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `sinks` | _[EnvoyGatewayMetricSink](#envoygatewaymetricsink) array_ | true | Sinks defines the metric sinks where metrics are sent to. | +| `prometheus` | _[EnvoyGatewayPrometheusProvider](#envoygatewayprometheusprovider)_ | true | Prometheus defines the configuration for prometheus endpoint. | + + +#### EnvoyGatewayOpenTelemetrySink + + + + + +_Appears in:_ +- [EnvoyGatewayMetricSink](#envoygatewaymetricsink) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `host` | _string_ | true | Host define the sink service hostname. | +| `protocol` | _string_ | true | Protocol define the sink service protocol. | +| `port` | _integer_ | false | Port defines the port the sink service is exposed on. | + + +#### EnvoyGatewayPrometheusProvider + + + +EnvoyGatewayPrometheusProvider will expose prometheus endpoint in pull mode. + +_Appears in:_ +- [EnvoyGatewayMetrics](#envoygatewaymetrics) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `disable` | _boolean_ | true | Disable defines if disables the prometheus metrics in pull mode. | + + +#### EnvoyGatewayProvider + + + +EnvoyGatewayProvider defines the desired configuration of a provider. + +_Appears in:_ +- [EnvoyGateway](#envoygateway) +- [EnvoyGatewaySpec](#envoygatewayspec) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `type` | _[ProviderType](#providertype)_ | true | Type is the type of provider to use. Supported types are "Kubernetes". | +| `kubernetes` | _[EnvoyGatewayKubernetesProvider](#envoygatewaykubernetesprovider)_ | false | Kubernetes defines the configuration of the Kubernetes provider. Kubernetes provides runtime configuration via the Kubernetes API. | +| `custom` | _[EnvoyGatewayCustomProvider](#envoygatewaycustomprovider)_ | false | Custom defines the configuration for the Custom provider. This provider allows you to define a specific resource provider and a infrastructure provider. | + + +#### EnvoyGatewayResourceProvider + + + +EnvoyGatewayResourceProvider defines configuration for the Custom Resource provider. + +_Appears in:_ +- [EnvoyGatewayCustomProvider](#envoygatewaycustomprovider) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `type` | _[ResourceProviderType](#resourceprovidertype)_ | true | Type is the type of resource provider to use. Supported types are "File". | +| `file` | _[EnvoyGatewayFileResourceProvider](#envoygatewayfileresourceprovider)_ | false | File defines the configuration of the File provider. File provides runtime configuration defined by one or more files. | + + +#### EnvoyGatewaySpec + + + +EnvoyGatewaySpec defines the desired state of Envoy Gateway. + +_Appears in:_ +- [EnvoyGateway](#envoygateway) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `gateway` | _[Gateway](#gateway)_ | false | Gateway defines desired Gateway API specific configuration. If unset, default configuration parameters will apply. | +| `provider` | _[EnvoyGatewayProvider](#envoygatewayprovider)_ | false | Provider defines the desired provider and provider-specific configuration. If unspecified, the Kubernetes provider is used with default configuration parameters. | +| `logging` | _[EnvoyGatewayLogging](#envoygatewaylogging)_ | false | Logging defines logging parameters for Envoy Gateway. | +| `admin` | _[EnvoyGatewayAdmin](#envoygatewayadmin)_ | false | Admin defines the desired admin related abilities. If unspecified, the Admin is used with default configuration parameters. | +| `telemetry` | _[EnvoyGatewayTelemetry](#envoygatewaytelemetry)_ | false | Telemetry defines the desired control plane telemetry related abilities. If unspecified, the telemetry is used with default configuration. | +| `rateLimit` | _[RateLimit](#ratelimit)_ | false | RateLimit defines the configuration associated with the Rate Limit service deployed by Envoy Gateway required to implement the Global Rate limiting functionality. The specific rate limit service used here is the reference implementation in Envoy. For more details visit https://github.com/envoyproxy/ratelimit. This configuration is unneeded for "Local" rate limiting. | +| `extensionManager` | _[ExtensionManager](#extensionmanager)_ | false | ExtensionManager defines an extension manager to register for the Envoy Gateway Control Plane. | +| `extensionApis` | _[ExtensionAPISettings](#extensionapisettings)_ | false | ExtensionAPIs defines the settings related to specific Gateway API Extensions implemented by Envoy Gateway | + + +#### EnvoyGatewayTelemetry + + + +EnvoyGatewayTelemetry defines telemetry configurations for envoy gateway control plane. Control plane will focus on metrics observability telemetry and tracing telemetry later. + +_Appears in:_ +- [EnvoyGateway](#envoygateway) +- [EnvoyGatewaySpec](#envoygatewayspec) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `metrics` | _[EnvoyGatewayMetrics](#envoygatewaymetrics)_ | true | Metrics defines metrics configuration for envoy gateway. | + + +#### EnvoyJSONPatchConfig + + + +EnvoyJSONPatchConfig defines the configuration for patching a Envoy xDS Resource using JSONPatch semantic + +_Appears in:_ +- [EnvoyPatchPolicySpec](#envoypatchpolicyspec) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `type` | _[EnvoyResourceType](#envoyresourcetype)_ | true | Type is the typed URL of the Envoy xDS Resource | +| `name` | _string_ | true | Name is the name of the resource | +| `operation` | _[JSONPatchOperation](#jsonpatchoperation)_ | true | Patch defines the JSON Patch Operation | + + +#### EnvoyPatchPolicy + + + +EnvoyPatchPolicy allows the user to modify the generated Envoy xDS resources by Envoy Gateway using this patch API + +_Appears in:_ +- [EnvoyPatchPolicyList](#envoypatchpolicylist) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `apiVersion` | _string_ | |`gateway.envoyproxy.io/v1alpha1` +| `kind` | _string_ | |`EnvoyPatchPolicy` +| `metadata` | _[ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.26/#objectmeta-v1-meta)_ | true | Refer to Kubernetes API documentation for fields of `metadata`. | +| `spec` | _[EnvoyPatchPolicySpec](#envoypatchpolicyspec)_ | true | Spec defines the desired state of EnvoyPatchPolicy. | + + +#### EnvoyPatchPolicyList + + + +EnvoyPatchPolicyList contains a list of EnvoyPatchPolicy resources. + + + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `apiVersion` | _string_ | |`gateway.envoyproxy.io/v1alpha1` +| `kind` | _string_ | |`EnvoyPatchPolicyList` +| `metadata` | _[ListMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.26/#listmeta-v1-meta)_ | true | Refer to Kubernetes API documentation for fields of `metadata`. | +| `items` | _[EnvoyPatchPolicy](#envoypatchpolicy) array_ | true | | + + +#### EnvoyPatchPolicySpec + + + +EnvoyPatchPolicySpec defines the desired state of EnvoyPatchPolicy. + +_Appears in:_ +- [EnvoyPatchPolicy](#envoypatchpolicy) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `type` | _[EnvoyPatchType](#envoypatchtype)_ | true | Type decides the type of patch. Valid EnvoyPatchType values are "JSONPatch". | +| `jsonPatches` | _[EnvoyJSONPatchConfig](#envoyjsonpatchconfig) array_ | false | JSONPatch defines the JSONPatch configuration. | +| `targetRef` | _[PolicyTargetReference](#policytargetreference)_ | true | TargetRef is the name of the Gateway API resource this policy is being attached to. By default attaching to Gateway is supported and when mergeGateways is enabled it should attach to GatewayClass. This Policy and the TargetRef MUST be in the same namespace for this Policy to have effect and be applied to the Gateway TargetRef | +| `priority` | _integer_ | true | Priority of the EnvoyPatchPolicy. If multiple EnvoyPatchPolicies are applied to the same TargetRef, they will be applied in the ascending order of the priority i.e. int32.min has the highest priority and int32.max has the lowest priority. Defaults to 0. | + + + + +#### EnvoyPatchType + +_Underlying type:_ _string_ + +EnvoyPatchType specifies the types of Envoy patching mechanisms. + +_Appears in:_ +- [EnvoyPatchPolicySpec](#envoypatchpolicyspec) + + + +#### EnvoyProxy + + + +EnvoyProxy is the schema for the envoyproxies API. + + + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `apiVersion` | _string_ | |`gateway.envoyproxy.io/v1alpha1` +| `kind` | _string_ | |`EnvoyProxy` +| `metadata` | _[ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.26/#objectmeta-v1-meta)_ | true | Refer to Kubernetes API documentation for fields of `metadata`. | +| `spec` | _[EnvoyProxySpec](#envoyproxyspec)_ | true | EnvoyProxySpec defines the desired state of EnvoyProxy. | + + +#### EnvoyProxyKubernetesProvider + + + +EnvoyProxyKubernetesProvider defines configuration for the Kubernetes resource provider. + +_Appears in:_ +- [EnvoyProxyProvider](#envoyproxyprovider) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `envoyDeployment` | _[KubernetesDeploymentSpec](#kubernetesdeploymentspec)_ | false | EnvoyDeployment defines the desired state of the Envoy deployment resource. If unspecified, default settings for the managed Envoy deployment resource are applied. | +| `envoyService` | _[KubernetesServiceSpec](#kubernetesservicespec)_ | false | EnvoyService defines the desired state of the Envoy service resource. If unspecified, default settings for the managed Envoy service resource are applied. | +| `envoyHpa` | _[KubernetesHorizontalPodAutoscalerSpec](#kuberneteshorizontalpodautoscalerspec)_ | false | EnvoyHpa defines the Horizontal Pod Autoscaler settings for Envoy Proxy Deployment. Once the HPA is being set, Replicas field from EnvoyDeployment will be ignored. | + + +#### EnvoyProxyProvider + + + +EnvoyProxyProvider defines the desired state of a resource provider. + +_Appears in:_ +- [EnvoyProxySpec](#envoyproxyspec) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `type` | _[ProviderType](#providertype)_ | true | Type is the type of resource provider to use. A resource provider provides infrastructure resources for running the data plane, e.g. Envoy proxy, and optional auxiliary control planes. Supported types are "Kubernetes". | +| `kubernetes` | _[EnvoyProxyKubernetesProvider](#envoyproxykubernetesprovider)_ | false | Kubernetes defines the desired state of the Kubernetes resource provider. Kubernetes provides infrastructure resources for running the data plane, e.g. Envoy proxy. If unspecified and type is "Kubernetes", default settings for managed Kubernetes resources are applied. | + + +#### EnvoyProxySpec + + + +EnvoyProxySpec defines the desired state of EnvoyProxy. + +_Appears in:_ +- [EnvoyProxy](#envoyproxy) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `provider` | _[EnvoyProxyProvider](#envoyproxyprovider)_ | false | Provider defines the desired resource provider and provider-specific configuration. If unspecified, the "Kubernetes" resource provider is used with default configuration parameters. | +| `logging` | _[ProxyLogging](#proxylogging)_ | true | Logging defines logging parameters for managed proxies. | +| `telemetry` | _[ProxyTelemetry](#proxytelemetry)_ | false | Telemetry defines telemetry parameters for managed proxies. | +| `bootstrap` | _[ProxyBootstrap](#proxybootstrap)_ | false | Bootstrap defines the Envoy Bootstrap as a YAML string. Visit https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/bootstrap/v3/bootstrap.proto#envoy-v3-api-msg-config-bootstrap-v3-bootstrap to learn more about the syntax. If set, this is the Bootstrap configuration used for the managed Envoy Proxy fleet instead of the default Bootstrap configuration set by Envoy Gateway. Some fields within the Bootstrap that are required to communicate with the xDS Server (Envoy Gateway) and receive xDS resources from it are not configurable and will result in the `EnvoyProxy` resource being rejected. Backward compatibility across minor versions is not guaranteed. We strongly recommend using `egctl x translate` to generate a `EnvoyProxy` resource with the `Bootstrap` field set to the default Bootstrap configuration used. You can edit this configuration, and rerun `egctl x translate` to ensure there are no validation errors. | +| `concurrency` | _integer_ | false | Concurrency defines the number of worker threads to run. If unset, it defaults to the number of cpuset threads on the platform. | +| `extraArgs` | _string array_ | false | ExtraArgs defines additional command line options that are provided to Envoy. More info: https://www.envoyproxy.io/docs/envoy/latest/operations/cli#command-line-options Note: some command line options are used internally(e.g. --log-level) so they cannot be provided here. | +| `mergeGateways` | _boolean_ | false | MergeGateways defines if Gateway resources should be merged onto the same Envoy Proxy Infrastructure. Setting this field to true would merge all Gateway Listeners under the parent Gateway Class. This means that the port, protocol and hostname tuple must be unique for every listener. If a duplicate listener is detected, the newer listener (based on timestamp) will be rejected and its status will be updated with a "Accepted=False" condition. | +| `shutdown` | _[ShutdownConfig](#shutdownconfig)_ | false | Shutdown defines configuration for graceful envoy shutdown process. | + + + + +#### EnvoyResourceType + +_Underlying type:_ _string_ + +EnvoyResourceType specifies the type URL of the Envoy resource. + +_Appears in:_ +- [EnvoyJSONPatchConfig](#envoyjsonpatchconfig) + + + +#### ExtAuth + + + +ExtAuth defines the configuration for External Authorization. + +_Appears in:_ +- [SecurityPolicySpec](#securitypolicyspec) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `grpc` | _[GRPCExtAuthService](#grpcextauthservice)_ | true | GRPC defines the gRPC External Authorization service. Either GRPCService or HTTPService must be specified, and only one of them can be provided. | +| `http` | _[HTTPExtAuthService](#httpextauthservice)_ | true | HTTP defines the HTTP External Authorization service. Either GRPCService or HTTPService must be specified, and only one of them can be provided. | +| `headersToExtAuth` | _string array_ | false | HeadersToExtAuth defines the client request headers that will be included in the request to the external authorization service. Note: If not specified, the default behavior for gRPC and HTTP external authorization services is different due to backward compatibility reasons. All headers will be included in the check request to a gRPC authorization server. Only the following headers will be included in the check request to an HTTP authorization server: Host, Method, Path, Content-Length, and Authorization. And these headers will always be included to the check request to an HTTP authorization server by default, no matter whether they are specified in HeadersToExtAuth or not. | + + +#### ExtensionAPISettings + + + +ExtensionAPISettings defines the settings specific to Gateway API Extensions. + +_Appears in:_ +- [EnvoyGateway](#envoygateway) +- [EnvoyGatewaySpec](#envoygatewayspec) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `enableEnvoyPatchPolicy` | _boolean_ | true | EnableEnvoyPatchPolicy enables Envoy Gateway to reconcile and implement the EnvoyPatchPolicy resources. | + + +#### ExtensionHooks + + + +ExtensionHooks defines extension hooks across all supported runners + +_Appears in:_ +- [ExtensionManager](#extensionmanager) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `xdsTranslator` | _[XDSTranslatorHooks](#xdstranslatorhooks)_ | true | XDSTranslator defines all the supported extension hooks for the xds-translator runner | + + +#### ExtensionManager + + + +ExtensionManager defines the configuration for registering an extension manager to the Envoy Gateway control plane. + +_Appears in:_ +- [EnvoyGateway](#envoygateway) +- [EnvoyGatewaySpec](#envoygatewayspec) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `resources` | _[GroupVersionKind](#groupversionkind) array_ | false | Resources defines the set of K8s resources the extension will handle. | +| `hooks` | _[ExtensionHooks](#extensionhooks)_ | true | Hooks defines the set of hooks the extension supports | +| `service` | _[ExtensionService](#extensionservice)_ | true | Service defines the configuration of the extension service that the Envoy Gateway Control Plane will call through extension hooks. | + + +#### ExtensionService + + + +ExtensionService defines the configuration for connecting to a registered extension service. + +_Appears in:_ +- [ExtensionManager](#extensionmanager) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `host` | _string_ | true | Host define the extension service hostname. | +| `port` | _integer_ | false | Port defines the port the extension service is exposed on. | +| `tls` | _[ExtensionTLS](#extensiontls)_ | false | TLS defines TLS configuration for communication between Envoy Gateway and the extension service. | + + +#### ExtensionTLS + + + +ExtensionTLS defines the TLS configuration when connecting to an extension service + +_Appears in:_ +- [ExtensionService](#extensionservice) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `certificateRef` | _[SecretObjectReference](https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1.SecretObjectReference)_ | true | CertificateRef contains a references to objects (Kubernetes objects or otherwise) that contains a TLS certificate and private keys. These certificates are used to establish a TLS handshake to the extension server.

CertificateRef can only reference a Kubernetes Secret at this time. | + + +#### FaultInjection + + + +FaultInjection defines the fault injection policy to be applied. This configuration can be used to inject delays and abort requests to mimic failure scenarios such as service failures and overloads + +_Appears in:_ +- [BackendTrafficPolicySpec](#backendtrafficpolicyspec) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `delay` | _[FaultInjectionDelay](#faultinjectiondelay)_ | false | If specified, a delay will be injected into the request. | +| `abort` | _[FaultInjectionAbort](#faultinjectionabort)_ | false | If specified, the request will be aborted if it meets the configuration criteria. | + + +#### FaultInjectionAbort + + + +FaultInjectionAbort defines the abort fault injection configuration + +_Appears in:_ +- [FaultInjection](#faultinjection) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `httpStatus` | _integer_ | false | StatusCode specifies the HTTP status code to be returned | +| `grpcStatus` | _integer_ | false | GrpcStatus specifies the GRPC status code to be returned | +| `percentage` | _float_ | false | Percentage specifies the percentage of requests to be aborted. Default 100%, if set 0, no requests will be aborted. Accuracy to 0.0001%. | + + +#### FaultInjectionDelay + + + +FaultInjectionDelay defines the delay fault injection configuration + +_Appears in:_ +- [FaultInjection](#faultinjection) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `fixedDelay` | _[Duration](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.26/#duration-v1-meta)_ | true | FixedDelay specifies the fixed delay duration | +| `percentage` | _float_ | false | Percentage specifies the percentage of requests to be delayed. Default 100%, if set 0, no requests will be delayed. Accuracy to 0.0001%. | + + +#### FileEnvoyProxyAccessLog + + + + + +_Appears in:_ +- [ProxyAccessLogSink](#proxyaccesslogsink) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `path` | _string_ | true | Path defines the file path used to expose envoy access log(e.g. /dev/stdout). | + + +#### GRPCExtAuthService + + + +GRPCExtAuthService defines the gRPC External Authorization service The authorization request message is defined in https://www.envoyproxy.io/docs/envoy/latest/api-v3/service/auth/v3/external_auth.proto + +_Appears in:_ +- [ExtAuth](#extauth) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `backendRef` | _[BackendObjectReference](#backendobjectreference)_ | true | BackendRef references a Kubernetes object that represents the backend server to which the authorization request will be sent. Only service Kind is supported for now. | + + +#### Gateway + + + +Gateway defines the desired Gateway API configuration of Envoy Gateway. + +_Appears in:_ +- [EnvoyGateway](#envoygateway) +- [EnvoyGatewaySpec](#envoygatewayspec) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `controllerName` | _string_ | false | ControllerName defines the name of the Gateway API controller. If unspecified, defaults to "gateway.envoyproxy.io/gatewayclass-controller". See the following for additional details: https://gateway-api.sigs.k8s.io/v1alpha2/references/spec/#gateway.networking.k8s.io/v1.GatewayClass | + + +#### GlobalRateLimit + + + +GlobalRateLimit defines global rate limit configuration. + +_Appears in:_ +- [RateLimitSpec](#ratelimitspec) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `rules` | _[RateLimitRule](#ratelimitrule) array_ | true | Rules are a list of RateLimit selectors and limits. Each rule and its associated limit is applied in a mutually exclusive way. If a request matches multiple rules, each of their associated limits get applied, so a single request might increase the rate limit counters for multiple rules if selected. The rate limit service will return a logical OR of the individual rate limit decisions of all matching rules. For example, if a request matches two rules, one rate limited and one not, the final decision will be to rate limit the request. | + + +#### GroupVersionKind + + + +GroupVersionKind unambiguously identifies a Kind. It can be converted to k8s.io/apimachinery/pkg/runtime/schema.GroupVersionKind + +_Appears in:_ +- [ExtensionManager](#extensionmanager) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `group` | _string_ | true | | +| `version` | _string_ | true | | +| `kind` | _string_ | true | | + + +#### GzipCompressor + + + +GzipCompressor defines the config for the Gzip compressor. The default values can be found here: https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/compression/gzip/compressor/v3/gzip.proto#extension-envoy-compression-gzip-compressor + +_Appears in:_ +- [Compression](#compression) + + + +#### HTTP10Settings + + + +HTTP10Settings provides HTTP/1.0 configuration on the listener. + +_Appears in:_ +- [HTTP1Settings](#http1settings) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `useDefaultHost` | _boolean_ | false | UseDefaultHost defines if the HTTP/1.0 request is missing the Host header, then the hostname associated with the listener should be injected into the request. If this is not set and an HTTP/1.0 request arrives without a host, then it will be rejected. | + + +#### HTTP1Settings + + + +HTTP1Settings provides HTTP/1 configuration on the listener. + +_Appears in:_ +- [ClientTrafficPolicySpec](#clienttrafficpolicyspec) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `enableTrailers` | _boolean_ | false | EnableTrailers defines if HTTP/1 trailers should be proxied by Envoy. | +| `preserveHeaderCase` | _boolean_ | false | PreserveHeaderCase defines if Envoy should preserve the letter case of headers. By default, Envoy will lowercase all the headers. | +| `http10` | _[HTTP10Settings](#http10settings)_ | false | HTTP10 turns on support for HTTP/1.0 and HTTP/0.9 requests. | + + +#### HTTP3Settings + + + +HTTP3Settings provides HTTP/3 configuration on the listener. + +_Appears in:_ +- [ClientTrafficPolicySpec](#clienttrafficpolicyspec) + + + +#### HTTPActiveHealthChecker + + + +HTTPActiveHealthChecker defines the settings of http health check. + +_Appears in:_ +- [ActiveHealthCheck](#activehealthcheck) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `path` | _string_ | true | Path defines the HTTP path that will be requested during health checking. | +| `method` | _string_ | false | Method defines the HTTP method used for health checking. Defaults to GET | +| `expectedStatuses` | _[HTTPStatus](#httpstatus) array_ | false | ExpectedStatuses defines a list of HTTP response statuses considered healthy. Defaults to 200 only | +| `expectedResponse` | _[ActiveHealthCheckPayload](#activehealthcheckpayload)_ | false | ExpectedResponse defines a list of HTTP expected responses to match. | + + +#### HTTPClientTimeout + + + + + +_Appears in:_ +- [ClientTimeout](#clienttimeout) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `requestReceivedTimeout` | _[Duration](#duration)_ | false | The duration envoy waits for the complete request reception. This timer starts upon request initiation and stops when either the last byte of the request is sent upstream or when the response begins. | + + +#### HTTPExtAuthService + + + +HTTPExtAuthService defines the HTTP External Authorization service + +_Appears in:_ +- [ExtAuth](#extauth) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `backendRef` | _[BackendObjectReference](#backendobjectreference)_ | true | BackendRef references a Kubernetes object that represents the backend server to which the authorization request will be sent. Only service Kind is supported for now. | +| `path` | _string_ | true | Path is the path of the HTTP External Authorization service. If path is specified, the authorization request will be sent to that path, or else the authorization request will be sent to the root path. | +| `headersToBackend` | _string array_ | false | HeadersToBackend are the authorization response headers that will be added to the original client request before sending it to the backend server. Note that coexisting headers will be overridden. If not specified, no authorization response headers will be added to the original client request. | + + +#### HTTPStatus + +_Underlying type:_ _integer_ + +HTTPStatus defines the http status code. + +_Appears in:_ +- [HTTPActiveHealthChecker](#httpactivehealthchecker) +- [RetryOn](#retryon) + + + +#### HTTPTimeout + + + + + +_Appears in:_ +- [Timeout](#timeout) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `connectionIdleTimeout` | _[Duration](#duration)_ | false | The idle timeout for an HTTP connection. Idle time is defined as a period in which there are no active requests in the connection. Default: 1 hour. | +| `maxConnectionDuration` | _[Duration](#duration)_ | false | The maximum duration of an HTTP connection. Default: unlimited. | + + + + +#### HeaderMatchType + +_Underlying type:_ _string_ + +HeaderMatchType specifies the semantics of how HTTP header values should be compared. Valid HeaderMatchType values are "Exact", "RegularExpression", and "Distinct". + +_Appears in:_ +- [HeaderMatch](#headermatch) + + + +#### HeaderSettings + + + +HeaderSettings providess configuration options for headers on the listener. + +_Appears in:_ +- [ClientTrafficPolicySpec](#clienttrafficpolicyspec) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `enableEnvoyHeaders` | _boolean_ | false | EnableEnvoyHeaders configures Envoy Proxy to add the "X-Envoy-" headers to requests and responses. | + + +#### HealthCheck + + + +HealthCheck configuration to decide which endpoints are healthy and can be used for routing. + +_Appears in:_ +- [BackendTrafficPolicySpec](#backendtrafficpolicyspec) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `active` | _[ActiveHealthCheck](#activehealthcheck)_ | false | Active health check configuration | +| `passive` | _[PassiveHealthCheck](#passivehealthcheck)_ | false | Passive passive check configuration | + + +#### InfrastructureProviderType + +_Underlying type:_ _string_ + +InfrastructureProviderType defines the types of custom infrastructure providers supported by Envoy Gateway. + +_Appears in:_ +- [EnvoyGatewayInfrastructureProvider](#envoygatewayinfrastructureprovider) + + + +#### JSONPatchOperation + + + +JSONPatchOperation defines the JSON Patch Operation as defined in https://datatracker.ietf.org/doc/html/rfc6902 + +_Appears in:_ +- [EnvoyJSONPatchConfig](#envoyjsonpatchconfig) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `op` | _[JSONPatchOperationType](#jsonpatchoperationtype)_ | true | Op is the type of operation to perform | +| `path` | _string_ | true | Path is the location of the target document/field where the operation will be performed Refer to https://datatracker.ietf.org/doc/html/rfc6901 for more details. | +| `from` | _string_ | false | From is the source location of the value to be copied or moved. Only valid for move or copy operations Refer to https://datatracker.ietf.org/doc/html/rfc6901 for more details. | +| `value` | _[JSON](#json)_ | false | Value is the new value of the path location. The value is only used by the `add` and `replace` operations. | + + +#### JSONPatchOperationType + +_Underlying type:_ _string_ + +JSONPatchOperationType specifies the JSON Patch operations that can be performed. + +_Appears in:_ +- [JSONPatchOperation](#jsonpatchoperation) + + + +#### JWT + + + +JWT defines the configuration for JSON Web Token (JWT) authentication. + +_Appears in:_ +- [SecurityPolicySpec](#securitypolicyspec) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `providers` | _[JWTProvider](#jwtprovider) array_ | true | Providers defines the JSON Web Token (JWT) authentication provider type. When multiple JWT providers are specified, the JWT is considered valid if any of the providers successfully validate the JWT. For additional details, see https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/jwt_authn_filter.html. | + + +#### JWTExtractor + + + +JWTExtractor defines a custom JWT token extraction from HTTP request. If specified, Envoy will extract the JWT token from the listed extractors (headers, cookies, or params) and validate each of them. If any value extracted is found to be an invalid JWT, a 401 error will be returned. + +_Appears in:_ +- [JWTProvider](#jwtprovider) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `headers` | _[JWTHeaderExtractor](#jwtheaderextractor) array_ | false | Headers represents a list of HTTP request headers to extract the JWT token from. | +| `cookies` | _string array_ | false | Cookies represents a list of cookie names to extract the JWT token from. | +| `params` | _string array_ | false | Params represents a list of query parameters to extract the JWT token from. | + + +#### JWTHeaderExtractor + + + +JWTHeaderExtractor defines an HTTP header location to extract JWT token + +_Appears in:_ +- [JWTExtractor](#jwtextractor) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `name` | _string_ | true | Name is the HTTP header name to retrieve the token | +| `valuePrefix` | _string_ | false | ValuePrefix is the prefix that should be stripped before extracting the token. The format would be used by Envoy like "{ValuePrefix}". For example, "Authorization: Bearer ", then the ValuePrefix="Bearer " with a space at the end. | + + +#### JWTProvider + + + +JWTProvider defines how a JSON Web Token (JWT) can be verified. + +_Appears in:_ +- [JWT](#jwt) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `name` | _string_ | true | Name defines a unique name for the JWT provider. A name can have a variety of forms, including RFC1123 subdomains, RFC 1123 labels, or RFC 1035 labels. | +| `issuer` | _string_ | false | Issuer is the principal that issued the JWT and takes the form of a URL or email address. For additional details, see https://tools.ietf.org/html/rfc7519#section-4.1.1 for URL format and https://rfc-editor.org/rfc/rfc5322.html for email format. If not provided, the JWT issuer is not checked. | +| `audiences` | _string array_ | false | Audiences is a list of JWT audiences allowed access. For additional details, see https://tools.ietf.org/html/rfc7519#section-4.1.3. If not provided, JWT audiences are not checked. | +| `remoteJWKS` | _[RemoteJWKS](#remotejwks)_ | true | RemoteJWKS defines how to fetch and cache JSON Web Key Sets (JWKS) from a remote HTTP/HTTPS endpoint. | +| `claimToHeaders` | _[ClaimToHeader](#claimtoheader) array_ | false | ClaimToHeaders is a list of JWT claims that must be extracted into HTTP request headers For examples, following config: The claim must be of type; string, int, double, bool. Array type claims are not supported | +| `recomputeRoute` | _boolean_ | false | RecomputeRoute clears the route cache and recalculates the routing decision. This field must be enabled if the headers generated from the claim are used for route matching decisions. If the recomputation selects a new route, features targeting the new matched route will be applied. | +| `extractFrom` | _[JWTExtractor](#jwtextractor)_ | false | ExtractFrom defines different ways to extract the JWT token from HTTP request. If empty, it defaults to extract JWT token from the Authorization HTTP request header using Bearer schema or access_token from query parameters. | + + +#### KubernetesContainerSpec + + + +KubernetesContainerSpec defines the desired state of the Kubernetes container resource. + +_Appears in:_ +- [KubernetesDeploymentSpec](#kubernetesdeploymentspec) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `env` | _[EnvVar](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.26/#envvar-v1-core) array_ | false | List of environment variables to set in the container. | +| `resources` | _[ResourceRequirements](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.26/#resourcerequirements-v1-core)_ | false | Resources required by this container. More info: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ | +| `securityContext` | _[SecurityContext](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.26/#securitycontext-v1-core)_ | false | SecurityContext defines the security options the container should be run with. If set, the fields of SecurityContext override the equivalent fields of PodSecurityContext. More info: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/ | +| `image` | _string_ | false | Image specifies the EnvoyProxy container image to be used, instead of the default image. | +| `volumeMounts` | _[VolumeMount](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.26/#volumemount-v1-core) array_ | false | VolumeMounts are volumes to mount into the container's filesystem. Cannot be updated. | + + +#### KubernetesDeployMode + + + +KubernetesDeployMode holds configuration for how to deploy managed resources such as the Envoy Proxy data plane fleet. + +_Appears in:_ +- [EnvoyGatewayKubernetesProvider](#envoygatewaykubernetesprovider) + + + +#### KubernetesDeploymentSpec + + + +KubernetesDeploymentSpec defines the desired state of the Kubernetes deployment resource. + +_Appears in:_ +- [EnvoyGatewayKubernetesProvider](#envoygatewaykubernetesprovider) +- [EnvoyProxyKubernetesProvider](#envoyproxykubernetesprovider) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `patch` | _[KubernetesPatchSpec](#kubernetespatchspec)_ | false | Patch defines how to perform the patch operation to deployment | +| `replicas` | _integer_ | false | Replicas is the number of desired pods. Defaults to 1. | +| `strategy` | _[DeploymentStrategy](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.26/#deploymentstrategy-v1-apps)_ | false | The deployment strategy to use to replace existing pods with new ones. | +| `pod` | _[KubernetesPodSpec](#kubernetespodspec)_ | false | Pod defines the desired specification of pod. | +| `container` | _[KubernetesContainerSpec](#kubernetescontainerspec)_ | false | Container defines the desired specification of main container. | +| `initContainers` | _[Container](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.26/#container-v1-core) array_ | false | List of initialization containers belonging to the pod. More info: https://kubernetes.io/docs/concepts/workloads/pods/init-containers/ | + + +#### KubernetesHorizontalPodAutoscalerSpec + + + +KubernetesHorizontalPodAutoscalerSpec defines Kubernetes Horizontal Pod Autoscaler settings of Envoy Proxy Deployment. When HPA is enabled, it is recommended that the value in `KubernetesDeploymentSpec.replicas` be removed, otherwise Envoy Gateway will revert back to this value every time reconciliation occurs. See k8s.io.autoscaling.v2.HorizontalPodAutoScalerSpec. + +_Appears in:_ +- [EnvoyProxyKubernetesProvider](#envoyproxykubernetesprovider) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `minReplicas` | _integer_ | false | minReplicas is the lower limit for the number of replicas to which the autoscaler can scale down. It defaults to 1 replica. | +| `maxReplicas` | _integer_ | true | maxReplicas is the upper limit for the number of replicas to which the autoscaler can scale up. It cannot be less that minReplicas. | +| `metrics` | _[MetricSpec](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.26/#metricspec-v2-autoscaling) array_ | false | metrics contains the specifications for which to use to calculate the desired replica count (the maximum replica count across all metrics will be used). If left empty, it defaults to being based on CPU utilization with average on 80% usage. | +| `behavior` | _[HorizontalPodAutoscalerBehavior](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.26/#horizontalpodautoscalerbehavior-v2-autoscaling)_ | false | behavior configures the scaling behavior of the target in both Up and Down directions (scaleUp and scaleDown fields respectively). If not set, the default HPAScalingRules for scale up and scale down are used. See k8s.io.autoscaling.v2.HorizontalPodAutoScalerBehavior. | + + +#### KubernetesPatchSpec + + + +KubernetesPatchSpec defines how to perform the patch operation + +_Appears in:_ +- [KubernetesDeploymentSpec](#kubernetesdeploymentspec) +- [KubernetesServiceSpec](#kubernetesservicespec) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `type` | _[MergeType](#mergetype)_ | false | Type is the type of merge operation to perform

By default, StrategicMerge is used as the patch type. | +| `value` | _[JSON](#json)_ | true | Object contains the raw configuration for merged object | + + +#### KubernetesPodSpec + + + +KubernetesPodSpec defines the desired state of the Kubernetes pod resource. + +_Appears in:_ +- [KubernetesDeploymentSpec](#kubernetesdeploymentspec) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `annotations` | _object (keys:string, values:string)_ | false | Annotations are the annotations that should be appended to the pods. By default, no pod annotations are appended. | +| `labels` | _object (keys:string, values:string)_ | false | Labels are the additional labels that should be tagged to the pods. By default, no additional pod labels are tagged. | +| `securityContext` | _[PodSecurityContext](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.26/#podsecuritycontext-v1-core)_ | false | SecurityContext holds pod-level security attributes and common container settings. Optional: Defaults to empty. See type description for default values of each field. | +| `affinity` | _[Affinity](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.26/#affinity-v1-core)_ | false | If specified, the pod's scheduling constraints. | +| `tolerations` | _[Toleration](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.26/#toleration-v1-core) array_ | false | If specified, the pod's tolerations. | +| `volumes` | _[Volume](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.26/#volume-v1-core) array_ | false | Volumes that can be mounted by containers belonging to the pod. More info: https://kubernetes.io/docs/concepts/storage/volumes | +| `imagePullSecrets` | _[LocalObjectReference](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.26/#localobjectreference-v1-core) array_ | false | ImagePullSecrets is an optional list of references to secrets in the same namespace to use for pulling any of the images used by this PodSpec. If specified, these secrets will be passed to individual puller implementations for them to use. More info: https://kubernetes.io/docs/concepts/containers/images#specifying-imagepullsecrets-on-a-pod | +| `nodeSelector` | _object (keys:string, values:string)_ | false | NodeSelector is a selector which must be true for the pod to fit on a node. Selector which must match a node's labels for the pod to be scheduled on that node. More info: https://kubernetes.io/docs/concepts/configuration/assign-pod-node/ | +| `topologySpreadConstraints` | _[TopologySpreadConstraint](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.26/#topologyspreadconstraint-v1-core) array_ | false | TopologySpreadConstraints describes how a group of pods ought to spread across topology domains. Scheduler will schedule pods in a way which abides by the constraints. All topologySpreadConstraints are ANDed. | + + +#### KubernetesServiceSpec + + + +KubernetesServiceSpec defines the desired state of the Kubernetes service resource. + +_Appears in:_ +- [EnvoyProxyKubernetesProvider](#envoyproxykubernetesprovider) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `annotations` | _object (keys:string, values:string)_ | false | Annotations that should be appended to the service. By default, no annotations are appended. | +| `type` | _[ServiceType](#servicetype)_ | false | Type determines how the Service is exposed. Defaults to LoadBalancer. Valid options are ClusterIP, LoadBalancer and NodePort. "LoadBalancer" means a service will be exposed via an external load balancer (if the cloud provider supports it). "ClusterIP" means a service will only be accessible inside the cluster, via the cluster IP. "NodePort" means a service will be exposed on a static Port on all Nodes of the cluster. | +| `loadBalancerClass` | _string_ | false | LoadBalancerClass, when specified, allows for choosing the LoadBalancer provider implementation if more than one are available or is otherwise expected to be specified | +| `allocateLoadBalancerNodePorts` | _boolean_ | false | AllocateLoadBalancerNodePorts defines if NodePorts will be automatically allocated for services with type LoadBalancer. Default is "true". It may be set to "false" if the cluster load-balancer does not rely on NodePorts. If the caller requests specific NodePorts (by specifying a value), those requests will be respected, regardless of this field. This field may only be set for services with type LoadBalancer and will be cleared if the type is changed to any other type. | +| `loadBalancerIP` | _string_ | false | LoadBalancerIP defines the IP Address of the underlying load balancer service. This field may be ignored if the load balancer provider does not support this feature. This field has been deprecated in Kubernetes, but it is still used for setting the IP Address in some cloud providers such as GCP. | +| `externalTrafficPolicy` | _[ServiceExternalTrafficPolicy](#serviceexternaltrafficpolicy)_ | false | ExternalTrafficPolicy determines the externalTrafficPolicy for the Envoy Service. Valid options are Local and Cluster. Default is "Local". "Local" means traffic will only go to pods on the node receiving the traffic. "Cluster" means connections are loadbalanced to all pods in the cluster. | +| `patch` | _[KubernetesPatchSpec](#kubernetespatchspec)_ | false | Patch defines how to perform the patch operation to the service | + + +#### KubernetesWatchMode + + + +KubernetesWatchMode holds the configuration for which input resources to watch and reconcile. + +_Appears in:_ +- [EnvoyGatewayKubernetesProvider](#envoygatewaykubernetesprovider) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `type` | _[KubernetesWatchModeType](#kuberneteswatchmodetype)_ | true | Type indicates what watch mode to use. KubernetesWatchModeTypeNamespaces and KubernetesWatchModeTypeNamespaceSelector are currently supported By default, when this field is unset or empty, Envoy Gateway will watch for input namespaced resources from all namespaces. | +| `namespaces` | _string array_ | true | Namespaces holds the list of namespaces that Envoy Gateway will watch for namespaced scoped resources such as Gateway, HTTPRoute and Service. Note that Envoy Gateway will continue to reconcile relevant cluster scoped resources such as GatewayClass that it is linked to. Precisely one of Namespaces and NamespaceSelector must be set. | +| `namespaceSelector` | _[LabelSelector](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.26/#labelselector-v1-meta)_ | true | NamespaceSelector holds the label selector used to dynamically select namespaces. Envoy Gateway will watch for namespaces matching the specified label selector. Precisely one of Namespaces and NamespaceSelector must be set. | + + +#### KubernetesWatchModeType + +_Underlying type:_ _string_ + +KubernetesWatchModeType defines the type of KubernetesWatchMode + +_Appears in:_ +- [KubernetesWatchMode](#kuberneteswatchmode) + + + +#### LiteralCustomTag + + + +LiteralCustomTag adds hard-coded value to each span. + +_Appears in:_ +- [CustomTag](#customtag) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `value` | _string_ | true | Value defines the hard-coded value to add to each span. | + + +#### LoadBalancer + + + +LoadBalancer defines the load balancer policy to be applied. + +_Appears in:_ +- [BackendTrafficPolicySpec](#backendtrafficpolicyspec) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `type` | _[LoadBalancerType](#loadbalancertype)_ | true | Type decides the type of Load Balancer policy. Valid LoadBalancerType values are "ConsistentHash", "LeastRequest", "Random", "RoundRobin", | +| `consistentHash` | _[ConsistentHash](#consistenthash)_ | false | ConsistentHash defines the configuration when the load balancer type is set to ConsistentHash | +| `slowStart` | _[SlowStart](#slowstart)_ | false | SlowStart defines the configuration related to the slow start load balancer policy. If set, during slow start window, traffic sent to the newly added hosts will gradually increase. Currently this is only supported for RoundRobin and LeastRequest load balancers | + + +#### LoadBalancerType + +_Underlying type:_ _string_ + +LoadBalancerType specifies the types of LoadBalancer. + +_Appears in:_ +- [LoadBalancer](#loadbalancer) + + + +#### LocalRateLimit + + + +LocalRateLimit defines local rate limit configuration. + +_Appears in:_ +- [RateLimitSpec](#ratelimitspec) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `rules` | _[RateLimitRule](#ratelimitrule) array_ | false | Rules are a list of RateLimit selectors and limits. If a request matches multiple rules, the strictest limit is applied. For example, if a request matches two rules, one with 10rps and one with 20rps, the final limit will be based on the rule with 10rps. | + + +#### LogLevel + +_Underlying type:_ _string_ + +LogLevel defines a log level for Envoy Gateway and EnvoyProxy system logs. + +_Appears in:_ +- [EnvoyGatewayLogging](#envoygatewaylogging) +- [ProxyLogging](#proxylogging) + + + + + +#### MetricSinkType + +_Underlying type:_ _string_ + + + +_Appears in:_ +- [EnvoyGatewayMetricSink](#envoygatewaymetricsink) +- [ProxyMetricSink](#proxymetricsink) + + + +#### OIDC + + + +OIDC defines the configuration for the OpenID Connect (OIDC) authentication. + +_Appears in:_ +- [SecurityPolicySpec](#securitypolicyspec) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `provider` | _[OIDCProvider](#oidcprovider)_ | true | The OIDC Provider configuration. | +| `clientID` | _string_ | true | The client ID to be used in the OIDC [Authentication Request](https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest). | +| `clientSecret` | _[SecretObjectReference](https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1.SecretObjectReference)_ | true | The Kubernetes secret which contains the OIDC client secret to be used in the [Authentication Request](https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest).

This is an Opaque secret. The client secret should be stored in the key "client-secret". | +| `scopes` | _string array_ | false | The OIDC scopes to be used in the [Authentication Request](https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest). The "openid" scope is always added to the list of scopes if not already specified. | +| `redirectURL` | _string_ | true | The redirect URL to be used in the OIDC [Authentication Request](https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest). If not specified, uses the default redirect URI "%REQ(x-forwarded-proto)%://%REQ(:authority)%/oauth2/callback" | +| `logoutPath` | _string_ | true | The path to log a user out, clearing their credential cookies. If not specified, uses a default logout path "/logout" | + + +#### OIDCProvider + + + +OIDCProvider defines the OIDC Provider configuration. + +_Appears in:_ +- [OIDC](#oidc) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `issuer` | _string_ | true | The OIDC Provider's [issuer identifier](https://openid.net/specs/openid-connect-discovery-1_0.html#IssuerDiscovery). Issuer MUST be a URI RFC 3986 [RFC3986] with a scheme component that MUST be https, a host component, and optionally, port and path components and no query or fragment components. | +| `authorizationEndpoint` | _string_ | false | The OIDC Provider's [authorization endpoint](https://openid.net/specs/openid-connect-core-1_0.html#AuthorizationEndpoint). If not provided, EG will try to discover it from the provider's [Well-Known Configuration Endpoint](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfigurationResponse). | +| `tokenEndpoint` | _string_ | false | The OIDC Provider's [token endpoint](https://openid.net/specs/openid-connect-core-1_0.html#TokenEndpoint). If not provided, EG will try to discover it from the provider's [Well-Known Configuration Endpoint](https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfigurationResponse). | + + +#### OpenTelemetryEnvoyProxyAccessLog + + + +TODO: consider reuse ExtensionService? + +_Appears in:_ +- [ProxyAccessLogSink](#proxyaccesslogsink) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `host` | _string_ | true | Host define the extension service hostname. | +| `port` | _integer_ | false | Port defines the port the extension service is exposed on. | +| `resources` | _object (keys:string, values:string)_ | false | Resources is a set of labels that describe the source of a log entry, including envoy node info. It's recommended to follow [semantic conventions](https://opentelemetry.io/docs/reference/specification/resource/semantic_conventions/). | + + +#### Origin + +_Underlying type:_ _string_ + +Origin is defined by the scheme (protocol), hostname (domain), and port of the URL used to access it. The hostname can be "precise" which is just the domain name or "wildcard" which is a domain name prefixed with a single wildcard label such as "*.example.com". In addition to that a single wildcard (with or without scheme) can be configured to match any origin. + For example, the following are valid origins: - https://foo.example.com - https://*.example.com - http://foo.example.com:8080 - http://*.example.com:8080 - https://* + +_Appears in:_ +- [CORS](#cors) + + + +#### PassiveHealthCheck + + + +PassiveHealthCheck defines the configuration for passive health checks in the context of Envoy's Outlier Detection, see https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/outlier + +_Appears in:_ +- [HealthCheck](#healthcheck) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `splitExternalLocalOriginErrors` | _boolean_ | false | SplitExternalLocalOriginErrors enables splitting of errors between external and local origin. | +| `interval` | _[Duration](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.26/#duration-v1-meta)_ | false | Interval defines the time between passive health checks. | +| `consecutiveLocalOriginFailures` | _integer_ | false | ConsecutiveLocalOriginFailures sets the number of consecutive local origin failures triggering ejection. Parameter takes effect only when split_external_local_origin_errors is set to true. | +| `consecutiveGatewayErrors` | _integer_ | false | ConsecutiveGatewayErrors sets the number of consecutive gateway errors triggering ejection. | +| `consecutive5XxErrors` | _integer_ | false | Consecutive5xxErrors sets the number of consecutive 5xx errors triggering ejection. | +| `baseEjectionTime` | _[Duration](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.26/#duration-v1-meta)_ | false | BaseEjectionTime defines the base duration for which a host will be ejected on consecutive failures. | +| `maxEjectionPercent` | _integer_ | false | MaxEjectionPercent sets the maximum percentage of hosts in a cluster that can be ejected. | + + +#### PathEscapedSlashAction + +_Underlying type:_ _string_ + +PathEscapedSlashAction determines the action for requests that contain %2F, %2f, %5C, or %5c sequences in the URI path. + +_Appears in:_ +- [PathSettings](#pathsettings) + + + +#### PathSettings + + + +PathSettings provides settings that managing how the incoming path set by clients is handled. + +_Appears in:_ +- [ClientTrafficPolicySpec](#clienttrafficpolicyspec) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `escapedSlashesAction` | _[PathEscapedSlashAction](#pathescapedslashaction)_ | false | EscapedSlashesAction determines how %2f, %2F, %5c, or %5C sequences in the path URI should be handled. The default is UnescapeAndRedirect. | +| `disableMergeSlashes` | _boolean_ | false | DisableMergeSlashes allows disabling the default configuration of merging adjacent slashes in the path. Note that slash merging is not part of the HTTP spec and is provided for convenience. | + + +#### PerRetryPolicy + + + + + +_Appears in:_ +- [Retry](#retry) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `timeout` | _[Duration](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.26/#duration-v1-meta)_ | false | Timeout is the timeout per retry attempt. | +| `backOff` | _[BackOffPolicy](#backoffpolicy)_ | false | Backoff is the backoff policy to be applied per retry attempt. gateway uses a fully jittered exponential back-off algorithm for retries. For additional details, see https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/router_filter#config-http-filters-router-x-envoy-max-retries | + + +#### ProviderType + +_Underlying type:_ _string_ + +ProviderType defines the types of providers supported by Envoy Gateway. + +_Appears in:_ +- [EnvoyGatewayProvider](#envoygatewayprovider) +- [EnvoyProxyProvider](#envoyproxyprovider) + + + +#### ProxyAccessLog + + + + + +_Appears in:_ +- [ProxyTelemetry](#proxytelemetry) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `disable` | _boolean_ | true | Disable disables access logging for managed proxies if set to true. | +| `settings` | _[ProxyAccessLogSetting](#proxyaccesslogsetting) array_ | false | Settings defines accesslog settings for managed proxies. If unspecified, will send default format to stdout. | + + +#### ProxyAccessLogFormat + + + +ProxyAccessLogFormat defines the format of accesslog. By default accesslogs are written to standard output. + +_Appears in:_ +- [ProxyAccessLogSetting](#proxyaccesslogsetting) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `type` | _[ProxyAccessLogFormatType](#proxyaccesslogformattype)_ | true | Type defines the type of accesslog format. | +| `text` | _string_ | false | Text defines the text accesslog format, following Envoy accesslog formatting, It's required when the format type is "Text". Envoy [command operators](https://www.envoyproxy.io/docs/envoy/latest/configuration/observability/access_log/usage#command-operators) may be used in the format. The [format string documentation](https://www.envoyproxy.io/docs/envoy/latest/configuration/observability/access_log/usage#config-access-log-format-strings) provides more information. | +| `json` | _object (keys:string, values:string)_ | false | JSON is additional attributes that describe the specific event occurrence. Structured format for the envoy access logs. Envoy [command operators](https://www.envoyproxy.io/docs/envoy/latest/configuration/observability/access_log/usage#command-operators) can be used as values for fields within the Struct. It's required when the format type is "JSON". | + + +#### ProxyAccessLogFormatType + +_Underlying type:_ _string_ + + + +_Appears in:_ +- [ProxyAccessLogFormat](#proxyaccesslogformat) + + + +#### ProxyAccessLogSetting + + + + + +_Appears in:_ +- [ProxyAccessLog](#proxyaccesslog) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `format` | _[ProxyAccessLogFormat](#proxyaccesslogformat)_ | true | Format defines the format of accesslog. | +| `sinks` | _[ProxyAccessLogSink](#proxyaccesslogsink) array_ | true | Sinks defines the sinks of accesslog. | + + +#### ProxyAccessLogSink + + + +ProxyAccessLogSink defines the sink of accesslog. + +_Appears in:_ +- [ProxyAccessLogSetting](#proxyaccesslogsetting) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `type` | _[ProxyAccessLogSinkType](#proxyaccesslogsinktype)_ | true | Type defines the type of accesslog sink. | +| `file` | _[FileEnvoyProxyAccessLog](#fileenvoyproxyaccesslog)_ | false | File defines the file accesslog sink. | +| `openTelemetry` | _[OpenTelemetryEnvoyProxyAccessLog](#opentelemetryenvoyproxyaccesslog)_ | false | OpenTelemetry defines the OpenTelemetry accesslog sink. | + + +#### ProxyAccessLogSinkType + +_Underlying type:_ _string_ + + + +_Appears in:_ +- [ProxyAccessLogSink](#proxyaccesslogsink) + + + +#### ProxyBootstrap + + + +ProxyBootstrap defines Envoy Bootstrap configuration. + +_Appears in:_ +- [EnvoyProxySpec](#envoyproxyspec) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `type` | _[BootstrapType](#bootstraptype)_ | false | Type is the type of the bootstrap configuration, it should be either Replace or Merge. If unspecified, it defaults to Replace. | +| `value` | _string_ | true | Value is a YAML string of the bootstrap. | + + +#### ProxyLogComponent + +_Underlying type:_ _string_ + +ProxyLogComponent defines a component that supports a configured logging level. + +_Appears in:_ +- [ProxyLogging](#proxylogging) + + + +#### ProxyLogging + + + +ProxyLogging defines logging parameters for managed proxies. + +_Appears in:_ +- [EnvoyProxySpec](#envoyproxyspec) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `level` | _object (keys:[ProxyLogComponent](#proxylogcomponent), values:[LogLevel](#loglevel))_ | true | Level is a map of logging level per component, where the component is the key and the log level is the value. If unspecified, defaults to "default: warn". | + + +#### ProxyMetricSink + + + +ProxyMetricSink defines the sink of metrics. Default metrics sink is OpenTelemetry. + +_Appears in:_ +- [ProxyMetrics](#proxymetrics) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `type` | _[MetricSinkType](#metricsinktype)_ | true | Type defines the metric sink type. EG currently only supports OpenTelemetry. | +| `openTelemetry` | _[ProxyOpenTelemetrySink](#proxyopentelemetrysink)_ | false | OpenTelemetry defines the configuration for OpenTelemetry sink. It's required if the sink type is OpenTelemetry. | + + +#### ProxyMetrics + + + + + +_Appears in:_ +- [ProxyTelemetry](#proxytelemetry) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `prometheus` | _[ProxyPrometheusProvider](#proxyprometheusprovider)_ | true | Prometheus defines the configuration for Admin endpoint `/stats/prometheus`. | +| `sinks` | _[ProxyMetricSink](#proxymetricsink) array_ | true | Sinks defines the metric sinks where metrics are sent to. | +| `matches` | _[StringMatch](#stringmatch) array_ | true | Matches defines configuration for selecting specific metrics instead of generating all metrics stats that are enabled by default. This helps reduce CPU and memory overhead in Envoy, but eliminating some stats may after critical functionality. Here are the stats that we strongly recommend not disabling: `cluster_manager.warming_clusters`, `cluster..membership_total`,`cluster..membership_healthy`, `cluster..membership_degraded`，reference https://github.com/envoyproxy/envoy/issues/9856, https://github.com/envoyproxy/envoy/issues/14610 | +| `enableVirtualHostStats` | _boolean_ | true | EnableVirtualHostStats enables envoy stat metrics for virtual hosts. | + + +#### ProxyOpenTelemetrySink + + + + + +_Appears in:_ +- [ProxyMetricSink](#proxymetricsink) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `host` | _string_ | true | Host define the service hostname. | +| `port` | _integer_ | false | Port defines the port the service is exposed on. | + + +#### ProxyPrometheusProvider + + + + + +_Appears in:_ +- [ProxyMetrics](#proxymetrics) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `disable` | _boolean_ | true | Disable the Prometheus endpoint. | + + +#### ProxyProtocol + + + +ProxyProtocol defines the configuration related to the proxy protocol when communicating with the backend. + +_Appears in:_ +- [BackendTrafficPolicySpec](#backendtrafficpolicyspec) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `version` | _[ProxyProtocolVersion](#proxyprotocolversion)_ | true | Version of ProxyProtol Valid ProxyProtocolVersion values are "V1" "V2" | + + +#### ProxyProtocolVersion + +_Underlying type:_ _string_ + +ProxyProtocolVersion defines the version of the Proxy Protocol to use. + +_Appears in:_ +- [ProxyProtocol](#proxyprotocol) + + + +#### ProxyTelemetry + + + + + +_Appears in:_ +- [EnvoyProxySpec](#envoyproxyspec) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `accessLog` | _[ProxyAccessLog](#proxyaccesslog)_ | false | AccessLogs defines accesslog parameters for managed proxies. If unspecified, will send default format to stdout. | +| `tracing` | _[ProxyTracing](#proxytracing)_ | false | Tracing defines tracing configuration for managed proxies. If unspecified, will not send tracing data. | +| `metrics` | _[ProxyMetrics](#proxymetrics)_ | true | Metrics defines metrics configuration for managed proxies. | + + +#### ProxyTracing + + + + + +_Appears in:_ +- [ProxyTelemetry](#proxytelemetry) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `samplingRate` | _integer_ | false | SamplingRate controls the rate at which traffic will be selected for tracing if no prior sampling decision has been made. Defaults to 100, valid values [0-100]. 100 indicates 100% sampling. | +| `customTags` | _object (keys:string, values:[CustomTag](#customtag))_ | true | CustomTags defines the custom tags to add to each span. If provider is kubernetes, pod name and namespace are added by default. | +| `provider` | _[TracingProvider](#tracingprovider)_ | true | Provider defines the tracing provider. Only OpenTelemetry is supported currently. | + + +#### RateLimit + + + +RateLimit defines the configuration associated with the Rate Limit Service used for Global Rate Limiting. + +_Appears in:_ +- [EnvoyGateway](#envoygateway) +- [EnvoyGatewaySpec](#envoygatewayspec) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `backend` | _[RateLimitDatabaseBackend](#ratelimitdatabasebackend)_ | true | Backend holds the configuration associated with the database backend used by the rate limit service to store state associated with global ratelimiting. | +| `timeout` | _[Duration](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.26/#duration-v1-meta)_ | false | Timeout specifies the timeout period for the proxy to access the ratelimit server If not set, timeout is 20ms. | +| `failClosed` | _boolean_ | true | FailClosed is a switch used to control the flow of traffic when the response from the ratelimit server cannot be obtained. If FailClosed is false, let the traffic pass, otherwise, don't let the traffic pass and return 500. If not set, FailClosed is False. | +| `telemetry` | _[RateLimitTelemetry](#ratelimittelemetry)_ | false | Telemetry defines telemetry configuration for RateLimit. | + + +#### RateLimitDatabaseBackend + + + +RateLimitDatabaseBackend defines the configuration associated with the database backend used by the rate limit service. + +_Appears in:_ +- [RateLimit](#ratelimit) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `type` | _[RateLimitDatabaseBackendType](#ratelimitdatabasebackendtype)_ | true | Type is the type of database backend to use. Supported types are: * Redis: Connects to a Redis database. | +| `redis` | _[RateLimitRedisSettings](#ratelimitredissettings)_ | false | Redis defines the settings needed to connect to a Redis database. | + + +#### RateLimitDatabaseBackendType + +_Underlying type:_ _string_ + +RateLimitDatabaseBackendType specifies the types of database backend to be used by the rate limit service. + +_Appears in:_ +- [RateLimitDatabaseBackend](#ratelimitdatabasebackend) + + + +#### RateLimitMetrics + + + + + +_Appears in:_ +- [RateLimitTelemetry](#ratelimittelemetry) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `prometheus` | _[RateLimitMetricsPrometheusProvider](#ratelimitmetricsprometheusprovider)_ | true | Prometheus defines the configuration for prometheus endpoint. | + + +#### RateLimitMetricsPrometheusProvider + + + + + +_Appears in:_ +- [RateLimitMetrics](#ratelimitmetrics) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `disable` | _boolean_ | true | Disable the Prometheus endpoint. | + + +#### RateLimitRedisSettings + + + +RateLimitRedisSettings defines the configuration for connecting to redis database. + +_Appears in:_ +- [RateLimitDatabaseBackend](#ratelimitdatabasebackend) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `url` | _string_ | true | URL of the Redis Database. | +| `tls` | _[RedisTLSSettings](#redistlssettings)_ | false | TLS defines TLS configuration for connecting to redis database. | + + +#### RateLimitRule + + + +RateLimitRule defines the semantics for matching attributes from the incoming requests, and setting limits for them. + +_Appears in:_ +- [GlobalRateLimit](#globalratelimit) +- [LocalRateLimit](#localratelimit) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `clientSelectors` | _[RateLimitSelectCondition](#ratelimitselectcondition) array_ | false | ClientSelectors holds the list of select conditions to select specific clients using attributes from the traffic flow. All individual select conditions must hold True for this rule and its limit to be applied.

If no client selectors are specified, the rule applies to all traffic of the targeted Route.

If the policy targets a Gateway, the rule applies to each Route of the Gateway. Please note that each Route has its own rate limit counters. For example, if a Gateway has two Routes, and the policy has a rule with limit 10rps, each Route will have its own 10rps limit. | +| `limit` | _[RateLimitValue](#ratelimitvalue)_ | true | Limit holds the rate limit values. This limit is applied for traffic flows when the selectors compute to True, causing the request to be counted towards the limit. The limit is enforced and the request is ratelimited, i.e. a response with 429 HTTP status code is sent back to the client when the selected requests have reached the limit. | + + +#### RateLimitSelectCondition + + + +RateLimitSelectCondition specifies the attributes within the traffic flow that can be used to select a subset of clients to be ratelimited. All the individual conditions must hold True for the overall condition to hold True. + +_Appears in:_ +- [RateLimitRule](#ratelimitrule) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `headers` | _[HeaderMatch](#headermatch) array_ | false | Headers is a list of request headers to match. Multiple header values are ANDed together, meaning, a request MUST match all the specified headers. At least one of headers or sourceCIDR condition must be specified. | +| `sourceCIDR` | _[SourceMatch](#sourcematch)_ | false | SourceCIDR is the client IP Address range to match on. At least one of headers or sourceCIDR condition must be specified. | + + +#### RateLimitSpec + + + +RateLimitSpec defines the desired state of RateLimitSpec. + +_Appears in:_ +- [BackendTrafficPolicySpec](#backendtrafficpolicyspec) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `type` | _[RateLimitType](#ratelimittype)_ | true | Type decides the scope for the RateLimits. Valid RateLimitType values are "Global" or "Local". | +| `global` | _[GlobalRateLimit](#globalratelimit)_ | false | Global defines global rate limit configuration. | +| `local` | _[LocalRateLimit](#localratelimit)_ | false | Local defines local rate limit configuration. | + + +#### RateLimitTelemetry + + + + + +_Appears in:_ +- [RateLimit](#ratelimit) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `metrics` | _[RateLimitMetrics](#ratelimitmetrics)_ | true | Metrics defines metrics configuration for RateLimit. | + + +#### RateLimitType + +_Underlying type:_ _string_ + +RateLimitType specifies the types of RateLimiting. + +_Appears in:_ +- [RateLimitSpec](#ratelimitspec) + + + +#### RateLimitUnit + +_Underlying type:_ _string_ + +RateLimitUnit specifies the intervals for setting rate limits. Valid RateLimitUnit values are "Second", "Minute", "Hour", and "Day". + +_Appears in:_ +- [RateLimitValue](#ratelimitvalue) + + + +#### RateLimitValue + + + +RateLimitValue defines the limits for rate limiting. + +_Appears in:_ +- [RateLimitRule](#ratelimitrule) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `requests` | _integer_ | true | | +| `unit` | _[RateLimitUnit](#ratelimitunit)_ | true | | + + +#### RedisTLSSettings + + + +RedisTLSSettings defines the TLS configuration for connecting to redis database. + +_Appears in:_ +- [RateLimitRedisSettings](#ratelimitredissettings) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `certificateRef` | _[SecretObjectReference](https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1.SecretObjectReference)_ | false | CertificateRef defines the client certificate reference for TLS connections. Currently only a Kubernetes Secret of type TLS is supported. | + + +#### RemoteJWKS + + + +RemoteJWKS defines how to fetch and cache JSON Web Key Sets (JWKS) from a remote HTTP/HTTPS endpoint. + +_Appears in:_ +- [JWTProvider](#jwtprovider) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `uri` | _string_ | true | URI is the HTTPS URI to fetch the JWKS. Envoy's system trust bundle is used to validate the server certificate. | + + +#### RequestHeaderCustomTag + + + +RequestHeaderCustomTag adds value from request header to each span. + +_Appears in:_ +- [CustomTag](#customtag) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `name` | _string_ | true | Name defines the name of the request header which to extract the value from. | +| `defaultValue` | _string_ | false | DefaultValue defines the default value to use if the request header is not set. | + + +#### ResourceProviderType + +_Underlying type:_ _string_ + +ResourceProviderType defines the types of custom resource providers supported by Envoy Gateway. + +_Appears in:_ +- [EnvoyGatewayResourceProvider](#envoygatewayresourceprovider) + + + +#### Retry + + + +Retry defines the retry strategy to be applied. + +_Appears in:_ +- [BackendTrafficPolicySpec](#backendtrafficpolicyspec) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `numRetries` | _integer_ | false | NumRetries is the number of retries to be attempted. Defaults to 2. | +| `retryOn` | _[RetryOn](#retryon)_ | false | RetryOn specifies the retry trigger condition.

If not specified, the default is to retry on connect-failure,refused-stream,unavailable,cancelled,retriable-status-codes(503). | +| `perRetry` | _[PerRetryPolicy](#perretrypolicy)_ | false | PerRetry is the retry policy to be applied per retry attempt. | + + +#### RetryOn + + + + + +_Appears in:_ +- [Retry](#retry) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `triggers` | _[TriggerEnum](#triggerenum) array_ | false | Triggers specifies the retry trigger condition(Http/Grpc). | +| `httpStatusCodes` | _[HTTPStatus](#httpstatus) array_ | false | HttpStatusCodes specifies the http status codes to be retried. The retriable-status-codes trigger must also be configured for these status codes to trigger a retry. | + + +#### SecurityPolicy + + + +SecurityPolicy allows the user to configure various security settings for a Gateway. + +_Appears in:_ +- [SecurityPolicyList](#securitypolicylist) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `apiVersion` | _string_ | |`gateway.envoyproxy.io/v1alpha1` +| `kind` | _string_ | |`SecurityPolicy` +| `metadata` | _[ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.26/#objectmeta-v1-meta)_ | true | Refer to Kubernetes API documentation for fields of `metadata`. | +| `spec` | _[SecurityPolicySpec](#securitypolicyspec)_ | true | Spec defines the desired state of SecurityPolicy. | + + +#### SecurityPolicyList + + + +SecurityPolicyList contains a list of SecurityPolicy resources. + + + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `apiVersion` | _string_ | |`gateway.envoyproxy.io/v1alpha1` +| `kind` | _string_ | |`SecurityPolicyList` +| `metadata` | _[ListMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.26/#listmeta-v1-meta)_ | true | Refer to Kubernetes API documentation for fields of `metadata`. | +| `items` | _[SecurityPolicy](#securitypolicy) array_ | true | | + + +#### SecurityPolicySpec + + + +SecurityPolicySpec defines the desired state of SecurityPolicy. + +_Appears in:_ +- [SecurityPolicy](#securitypolicy) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `targetRef` | _[PolicyTargetReferenceWithSectionName](https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1alpha2.PolicyTargetReferenceWithSectionName)_ | true | TargetRef is the name of the Gateway resource this policy is being attached to. This Policy and the TargetRef MUST be in the same namespace for this Policy to have effect and be applied to the Gateway. | +| `cors` | _[CORS](#cors)_ | false | CORS defines the configuration for Cross-Origin Resource Sharing (CORS). | +| `basicAuth` | _[BasicAuth](#basicauth)_ | false | BasicAuth defines the configuration for the HTTP Basic Authentication. | +| `jwt` | _[JWT](#jwt)_ | false | JWT defines the configuration for JSON Web Token (JWT) authentication. | +| `oidc` | _[OIDC](#oidc)_ | false | OIDC defines the configuration for the OpenID Connect (OIDC) authentication. | +| `extAuth` | _[ExtAuth](#extauth)_ | false | ExtAuth defines the configuration for External Authorization. | + + + + +#### ServiceExternalTrafficPolicy + +_Underlying type:_ _string_ + +ServiceExternalTrafficPolicy describes how nodes distribute service traffic they receive on one of the Service's "externally-facing" addresses (NodePorts, ExternalIPs, and LoadBalancer IPs. + +_Appears in:_ +- [KubernetesServiceSpec](#kubernetesservicespec) + + + +#### ServiceType + +_Underlying type:_ _string_ + +ServiceType string describes ingress methods for a service + +_Appears in:_ +- [KubernetesServiceSpec](#kubernetesservicespec) + + + +#### ShutdownConfig + + + +ShutdownConfig defines configuration for graceful envoy shutdown process. + +_Appears in:_ +- [EnvoyProxySpec](#envoyproxyspec) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `drainTimeout` | _[Duration](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.26/#duration-v1-meta)_ | false | DrainTimeout defines the graceful drain timeout. This should be less than the pod's terminationGracePeriodSeconds. If unspecified, defaults to 600 seconds. | +| `minDrainDuration` | _[Duration](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.26/#duration-v1-meta)_ | false | MinDrainDuration defines the minimum drain duration allowing time for endpoint deprogramming to complete. If unspecified, defaults to 5 seconds. | + + +#### SlowStart + + + +SlowStart defines the configuration related to the slow start load balancer policy. + +_Appears in:_ +- [LoadBalancer](#loadbalancer) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `window` | _[Duration](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.26/#duration-v1-meta)_ | true | Window defines the duration of the warm up period for newly added host. During slow start window, traffic sent to the newly added hosts will gradually increase. Currently only supports linear growth of traffic. For additional details, see https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/cluster/v3/cluster.proto#config-cluster-v3-cluster-slowstartconfig | + + + + +#### SourceMatchType + +_Underlying type:_ _string_ + + + +_Appears in:_ +- [SourceMatch](#sourcematch) + + + +#### StringMatch + + + +StringMatch defines how to match any strings. This is a general purpose match condition that can be used by other EG APIs that need to match against a string. + +_Appears in:_ +- [ProxyMetrics](#proxymetrics) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `type` | _[StringMatchType](#stringmatchtype)_ | false | Type specifies how to match against a string. | +| `value` | _string_ | true | Value specifies the string value that the match must have. | + + +#### StringMatchType + +_Underlying type:_ _string_ + +StringMatchType specifies the semantics of how a string value should be compared. Valid MatchType values are "Exact", "Prefix", "Suffix", "RegularExpression". + +_Appears in:_ +- [StringMatch](#stringmatch) + + + +#### TCPActiveHealthChecker + + + +TCPActiveHealthChecker defines the settings of tcp health check. + +_Appears in:_ +- [ActiveHealthCheck](#activehealthcheck) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `send` | _[ActiveHealthCheckPayload](#activehealthcheckpayload)_ | false | Send defines the request payload. | +| `receive` | _[ActiveHealthCheckPayload](#activehealthcheckpayload)_ | false | Receive defines the expected response payload. | + + +#### TCPKeepalive + + + +TCPKeepalive define the TCP Keepalive configuration. + +_Appears in:_ +- [BackendTrafficPolicySpec](#backendtrafficpolicyspec) +- [ClientTrafficPolicySpec](#clienttrafficpolicyspec) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `probes` | _integer_ | false | The total number of unacknowledged probes to send before deciding the connection is dead. Defaults to 9. | +| `idleTime` | _[Duration](#duration)_ | false | The duration a connection needs to be idle before keep-alive probes start being sent. The duration format is Defaults to `7200s`. | +| `interval` | _[Duration](#duration)_ | false | The duration between keep-alive probes. Defaults to `75s`. | + + +#### TCPTimeout + + + + + +_Appears in:_ +- [Timeout](#timeout) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `connectTimeout` | _[Duration](#duration)_ | false | The timeout for network connection establishment, including TCP and TLS handshakes. Default: 10 seconds. | + + +#### TLSSettings + + + + + +_Appears in:_ +- [ClientTrafficPolicySpec](#clienttrafficpolicyspec) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `minVersion` | _[TLSVersion](#tlsversion)_ | false | Min specifies the minimal TLS protocol version to allow. The default is TLS 1.2 if this is not specified. | +| `maxVersion` | _[TLSVersion](#tlsversion)_ | false | Max specifies the maximal TLS protocol version to allow The default is TLS 1.3 if this is not specified. | +| `ciphers` | _string array_ | false | Ciphers specifies the set of cipher suites supported when negotiating TLS 1.0 - 1.2. This setting has no effect for TLS 1.3. In non-FIPS Envoy Proxy builds the default cipher list is: - [ECDHE-ECDSA-AES128-GCM-SHA256\|ECDHE-ECDSA-CHACHA20-POLY1305] - [ECDHE-RSA-AES128-GCM-SHA256\|ECDHE-RSA-CHACHA20-POLY1305] - ECDHE-ECDSA-AES256-GCM-SHA384 - ECDHE-RSA-AES256-GCM-SHA384 In builds using BoringSSL FIPS the default cipher list is: - ECDHE-ECDSA-AES128-GCM-SHA256 - ECDHE-RSA-AES128-GCM-SHA256 - ECDHE-ECDSA-AES256-GCM-SHA384 - ECDHE-RSA-AES256-GCM-SHA384 | +| `ecdhCurves` | _string array_ | false | ECDHCurves specifies the set of supported ECDH curves. In non-FIPS Envoy Proxy builds the default curves are: - X25519 - P-256 In builds using BoringSSL FIPS the default curve is: - P-256 | +| `signatureAlgorithms` | _string array_ | false | SignatureAlgorithms specifies which signature algorithms the listener should support. | +| `alpnProtocols` | _[ALPNProtocol](#alpnprotocol) array_ | false | ALPNProtocols supplies the list of ALPN protocols that should be exposed by the listener. By default h2 and http/1.1 are enabled. Supported values are: - http/1.0 - http/1.1 - h2 | +| `clientValidation` | _[ClientValidationContext](#clientvalidationcontext)_ | false | ClientValidation specifies the configuration to validate the client initiating the TLS connection to the Gateway listener. | + + +#### TLSVersion + +_Underlying type:_ _string_ + +TLSVersion specifies the TLS version + +_Appears in:_ +- [TLSSettings](#tlssettings) + + + +#### Timeout + + + +Timeout defines configuration for timeouts related to connections. + +_Appears in:_ +- [BackendTrafficPolicySpec](#backendtrafficpolicyspec) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `tcp` | _[TCPTimeout](#tcptimeout)_ | false | Timeout settings for TCP. | +| `http` | _[HTTPTimeout](#httptimeout)_ | false | Timeout settings for HTTP. | + + +#### TracingProvider + + + + + +_Appears in:_ +- [ProxyTracing](#proxytracing) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `type` | _[TracingProviderType](#tracingprovidertype)_ | true | Type defines the tracing provider type. EG currently only supports OpenTelemetry. | +| `host` | _string_ | true | Host define the provider service hostname. | +| `port` | _integer_ | false | Port defines the port the provider service is exposed on. | + + +#### TracingProviderType + +_Underlying type:_ _string_ + + + +_Appears in:_ +- [TracingProvider](#tracingprovider) + + + +#### TriggerEnum + +_Underlying type:_ _string_ + +TriggerEnum specifies the conditions that trigger retries. + +_Appears in:_ +- [RetryOn](#retryon) + + + +#### XDSTranslatorHook + +_Underlying type:_ _string_ + +XDSTranslatorHook defines the types of hooks that an Envoy Gateway extension may support for the xds-translator + +_Appears in:_ +- [XDSTranslatorHooks](#xdstranslatorhooks) + + + +#### XDSTranslatorHooks + + + +XDSTranslatorHooks contains all the pre and post hooks for the xds-translator runner. + +_Appears in:_ +- [ExtensionHooks](#extensionhooks) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `pre` | _[XDSTranslatorHook](#xdstranslatorhook) array_ | true | | +| `post` | _[XDSTranslatorHook](#xdstranslatorhook) array_ | true | | + + +#### XForwardedForSettings + + + +XForwardedForSettings provides configuration for using X-Forwarded-For headers for determining the client IP address. + +_Appears in:_ +- [ClientIPDetectionSettings](#clientipdetectionsettings) + +| Field | Type | Required | Description | +| --- | --- | --- | --- | +| `numTrustedHops` | _integer_ | false | NumTrustedHops controls 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. Refer to https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_conn_man/headers#x-forwarded-for for more details. | + + diff --git a/site/content/en/v1.0.0/contributions/CODEOWNERS.md b/site/content/en/v1.0.0/contributions/CODEOWNERS.md new file mode 100644 index 00000000000..aeec0b7439b --- /dev/null +++ b/site/content/en/v1.0.0/contributions/CODEOWNERS.md @@ -0,0 +1,21 @@ +--- +title: "Maintainers" +description: "This section includes Maintainers of Envoy Gateway." +--- + +## The following maintainers, listed in alphabetical order, own everything + +- @AliceProxy +- @arkodg +- @qicz +- @Xunzhuo +- @zirain +- @zhaohuabing + +## Emeritus Maintainers + +- @alexgervais +- @danehans +- @LukeShu +- @skriss +- @youngnick diff --git a/site/content/en/v1.0.0/contributions/CODE_OF_CONDUCT.md b/site/content/en/v1.0.0/contributions/CODE_OF_CONDUCT.md new file mode 100644 index 00000000000..e19da050dff --- /dev/null +++ b/site/content/en/v1.0.0/contributions/CODE_OF_CONDUCT.md @@ -0,0 +1,6 @@ +--- +title: "Code of Conduct" +description: "This section includes Code of Conduct of Envoy Gateway." +--- + +Envoy Gateway follows the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/main/code-of-conduct.md). diff --git a/site/content/en/v1.0.0/contributions/CONTRIBUTING.md b/site/content/en/v1.0.0/contributions/CONTRIBUTING.md new file mode 100644 index 00000000000..f94b2c940e9 --- /dev/null +++ b/site/content/en/v1.0.0/contributions/CONTRIBUTING.md @@ -0,0 +1,190 @@ +--- +title: "Contributing" +description: "This section tells how to contribute to Envoy Gateway." +weight: 3 +--- + +We welcome contributions from the community. Please carefully review the [project goals](/about) +and following guidelines to streamline your contributions. + +## Communication + +* Before starting work on a major feature, please contact us via GitHub or Slack. We will ensure no + one else is working on it and ask you to open a GitHub issue. +* A "major feature" is defined as any change that is > 100 LOC altered (not including tests), or + changes any user-facing behavior. We will use the GitHub issue to discuss the feature and come to + agreement. This is to prevent your time being wasted, as well as ours. The GitHub review process + for major features is also important so that [affiliations with commit access](../codeowners) can + come to agreement on the design. If it's appropriate to write a design document, the document must + be hosted either in the GitHub issue, or linked to from the issue and hosted in a world-readable + location. +* Small patches and bug fixes don't need prior communication. + +## Inclusivity + +The Envoy Gateway community has an explicit goal to be inclusive to all. As such, all PRs must adhere +to the following guidelines for all code, APIs, and documentation: + +* The following words and phrases are not allowed: + * *Whitelist*: use allowlist instead. + * *Blacklist*: use denylist or blocklist instead. + * *Master*: use primary instead. + * *Slave*: use secondary or replica instead. +* Documentation should be written in an inclusive style. The [Google developer + documentation](https://developers.google.com/style/inclusive-documentation) contains an excellent + reference on this topic. +* The above policy is not considered definitive and may be amended in the future as industry best + practices evolve. Additional comments on this topic may be provided by maintainers during code + review. + +## Submitting a PR + +* Fork the repo. +* Hack +* DCO sign-off each commit. This can be done with `git commit -s`. +* Submit your PR. +* Tests will automatically run for you. +* We will **not** merge any PR that is not passing tests. +* PRs are expected to have 100% test coverage for added code. This can be verified with a coverage + build. If your PR cannot have 100% coverage for some reason please clearly explain why when you + open it. +* Any PR that changes user-facing behavior **must** have associated documentation in the [docs](https://github.com/envoyproxy/gateway/tree/main/site) folder of the repo as + well as the [changelog](/blog/releases). +* All code comments and documentation are expected to have proper English grammar and punctuation. + If you are not a fluent English speaker (or a bad writer ;-)) please let us know and we will try + to find some help but there are no guarantees. +* Your PR title should be descriptive, and generally start with type that contains a subsystem name with `()` if necessary + and summary followed by a colon. format `chore/docs/feat/fix/refactor/style/test: summary`. + Examples: + * "docs: fix grammar error" + * "feat(translator): add new feature" + * "fix: fix xx bug" + * "chore: change ci & build tools etc" +* Your PR commit message will be used as the commit message when your PR is merged. You should + update this field if your PR diverges during review. +* Your PR description should have details on what the PR does. If it fixes an existing issue it + should end with "Fixes #XXX". +* If your PR is co-authored or based on an earlier PR from another contributor, + please attribute them with `Co-authored-by: name `. See + GitHub's [multiple author + guidance](https://help.github.com/en/github/committing-changes-to-your-project/creating-a-commit-with-multiple-authors) + for further details. +* When all tests are passing and all other conditions described herein are satisfied, a maintainer + will be assigned to review and merge the PR. +* Once you submit a PR, *please do not rebase it*. It's much easier to review if subsequent commits + are new commits and/or merges. We squash and merge so the number of commits you have in the PR + doesn't matter. +* We expect that once a PR is opened, it will be actively worked on until it is merged or closed. + We reserve the right to close PRs that are not making progress. This is generally defined as no + changes for 7 days. Obviously PRs that are closed due to lack of activity can be reopened later. + Closing stale PRs helps us to keep on top of all the work currently in flight. + +## Maintainer PR Review Policy + +* See [CODEOWNERS.md](../codeowners) for the current list of maintainers. +* A maintainer representing a different affiliation from the PR owner is required to review and + approve the PR. +* When the project matures, it is expected that a "domain expert" for the code the PR touches should + review the PR. This person does not require commit access, just domain knowledge. +* The above rules may be waived for PRs which only update docs or comments, or trivial changes to + tests and tools (where trivial is decided by the maintainer in question). +* If there is a question on who should review a PR please discuss in Slack. +* Anyone is welcome to review any PR that they want, whether they are a maintainer or not. +* Please make sure that the PR title, commit message, and description are updated if the PR changes + significantly during review. +* Please **clean up the title and body** before merging. By default, GitHub fills the squash merge + title with the original title, and the commit body with every individual commit from the PR. + The maintainer doing the merge should make sure the title follows the guidelines above and should + overwrite the body with the original commit message from the PR (cleaning it up if necessary) + while preserving the PR author's final DCO sign-off. + +## Decision making + +This is a new and complex project, and we need to make a lot of decisions very quickly. +To this end, we've settled on this process for making (possibly contentious) decisions: + +* For decisions that need a record, we create an issue. +* In that issue, we discuss opinions, then a maintainer can call for a vote in a comment. +* Maintainers can cast binding votes on that comment by reacting or replying in another comment. +* Non-maintainer community members are welcome to cast non-binding votes by either of these methods. +* Voting will be resolved by simple majority. +* In the event of deadlocks, the question will be put to steering instead. + +## DCO: Sign your work + +The sign-off is a simple line at the end of the explanation for the +patch, which certifies that you wrote it or otherwise have the right to +pass it on as an open-source patch. The rules are pretty simple: if you +can certify the below (from +[developercertificate.org](https://developercertificate.org/)): + +``` +Developer Certificate of Origin +Version 1.1 + +Copyright (C) 2004, 2006 The Linux Foundation and its contributors. +660 York Street, Suite 102, +San Francisco, CA 94110 USA + +Everyone is permitted to copy and distribute verbatim copies of this +license document, but changing it is not allowed. + + +Developer's Certificate of Origin 1.1 + +By making a contribution to this project, I certify that: + +(a) The contribution was created in whole or in part by me and I + have the right to submit it under the open source license + indicated in the file; or + +(b) The contribution is based upon previous work that, to the best + of my knowledge, is covered under an appropriate open source + license and I have the right under that license to submit that + work with modifications, whether created in whole or in part + by me, under the same open source license (unless I am + permitted to submit under a different license), as indicated + in the file; or + +(c) The contribution was provided directly to me by some other + person who certified (a), (b) or (c) and I have not modified + it. + +(d) I understand and agree that this project and the contribution + are public and that a record of the contribution (including all + personal information I submit with it, including my sign-off) is + maintained indefinitely and may be redistributed consistent with + this project or the open source license(s) involved. +``` + +then you just add a line to every git commit message: + + Signed-off-by: Joe Smith + +using your real name (sorry, no pseudonyms or anonymous contributions.) + +You can add the sign-off when creating the git commit via `git commit -s`. + +If you want this to be automatic you can set up some aliases: + +```bash +git config --add alias.amend "commit -s --amend" +git config --add alias.c "commit -s" +``` + +## Fixing DCO + +If your PR fails the DCO check, it's necessary to fix the entire commit history in the PR. Best +practice is to [squash](https://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html) +the commit history to a single commit, append the DCO sign-off as described above, and [force +push](https://git-scm.com/docs/git-push#git-push---force). For example, if you have 2 commits in +your history: + +```bash +git rebase -i HEAD^^ +(interactive squash + DCO append) +git push origin -f +``` + +Note, that in general rewriting history in this way is a hindrance to the review process and this +should only be done to correct a DCO mistake. diff --git a/site/content/en/v1.0.0/contributions/DEVELOP.md b/site/content/en/v1.0.0/contributions/DEVELOP.md new file mode 100644 index 00000000000..6f82c4a411f --- /dev/null +++ b/site/content/en/v1.0.0/contributions/DEVELOP.md @@ -0,0 +1,163 @@ +--- +title: "Developer Guide" +description: "This section tells how to develop Envoy Gateway." +weight: 2 +--- + +Envoy Gateway is built using a [make][]-based build system. Our CI is based on [Github Actions][] using [workflows][]. + +## Prerequisites + +### go + +* Version: 1.20 +* Installation Guide: https://go.dev/doc/install + +### make + +* Recommended Version: 4.0 or later +* Installation Guide: https://www.gnu.org/software/make + +### docker + +* Optional when you want to build a Docker image or run `make` inside Docker. +* Recommended Version: 20.10.16 +* Installation Guide: https://docs.docker.com/engine/install + +### python3 + +* Need a `python3` program +* Must have a functioning `venv` module; this is part of the standard + library, but some distributions (such as Debian and Ubuntu) replace + it with a stub and require you to install a `python3-venv` package + separately. + +## Quickstart + +* Run `make help` to see all the available targets to build, test and run Envoy Gateway. + +### Building + +* Run `make build` to build all the binaries. +* Run `make build BINS="envoy-gateway"` to build the Envoy Gateway binary. +* Run `make build BINS="egctl"` to build the egctl binary. + +__Note:__ The binaries get generated in the `bin/$OS/$ARCH` directory, for example, `bin/linux/amd64/`. + +### Testing + +* Run `make test` to run the golang tests. + +* Run `make testdata` to generate the golden YAML testdata files. + +### Running Linters + +* Run `make lint` to make sure your code passes all the linter checks. +__Note:__ The `golangci-lint` configuration resides [here](https://github.com/envoyproxy/gateway/blob/main/tools/linter/golangci-lint/.golangci.yml). + +### Building and Pushing the Image + +* Run `IMAGE=docker.io/you/gateway-dev make image` to build the docker image. +* Run `IMAGE=docker.io/you/gateway-dev make push-multiarch` to build and push the multi-arch docker image. + +__Note:__ Replace `IMAGE` with your registry's image name. + +### Deploying Envoy Gateway for Test/Dev + +* Run `make create-cluster` to create a [Kind][] cluster. + +#### Option 1: Use the Latest [gateway-dev][] Image + +* Run `TAG=latest make kube-deploy` to deploy Envoy Gateway in the Kind cluster using the latest image. Replace `latest` + to use a different image tag. + +#### Option 2: Use a Custom Image + +* Run `make kube-install-image` to build an image from the tip of your current branch and load it in the Kind cluster. +* Run `IMAGE_PULL_POLICY=IfNotPresent make kube-deploy` to install Envoy Gateway into the Kind cluster using your custom image. + +### Deploying Envoy Gateway in Kubernetes + +* Run `TAG=latest make kube-deploy` to deploy Envoy Gateway using the latest image into a Kubernetes cluster (linked to + the current kube context). Preface the command with `IMAGE` or replace `TAG` to use a different Envoy Gateway image or + tag. +* Run `make kube-undeploy` to uninstall Envoy Gateway from the cluster. + +__Note:__ Envoy Gateway is tested against Kubernetes v1.24.0. + +### Demo Setup + +* Run `make kube-demo` to deploy a demo backend service, gatewayclass, gateway and httproute resource +(similar to steps outlined in the [Quickstart][] docs) and test the configuration. +* Run `make kube-demo-undeploy` to delete the resources created by the `make kube-demo` command. + +### Run Gateway API Conformance Tests + +The commands below deploy Envoy Gateway to a Kubernetes cluster and run the Gateway API conformance tests. Refer to the +Gateway API [conformance homepage][] to learn more about the tests. If Envoy Gateway is already installed, run +`TAG=latest make run-conformance` to run the conformance tests. + +#### On a Linux Host + +* Run `TAG=latest make conformance` to create a Kind cluster, install Envoy Gateway using the latest [gateway-dev][] + image, and run Gateway API conformance tests. + +#### On a Mac Host + +Since Mac doesn't support [directly exposing][] the Docker network to the Mac host, use one of the following +workarounds to run conformance tests: + +* Deploy your own Kubernetes cluster or use Docker Desktop with [Kubernetes support][] and then run + `TAG=latest make kube-deploy run-conformance`. This will install Envoy Gateway using the latest [gateway-dev][] image + to the Kubernetes cluster using the current kubectl context and run the conformance tests. Use `make kube-undeploy` to + uninstall Envoy Gateway. +* Install and run [Docker Mac Net Connect][mac_connect] and then run `TAG=latest make conformance`. + +__Note:__ Preface commands with `IMAGE` or replace `TAG` to use a different Envoy Gateway image or tag. If `TAG` +is unspecified, the short SHA of your current branch is used. + +### Debugging the Envoy Config + +An easy way to view the envoy config that Envoy Gateway is using is to port-forward to the admin interface port +(currently `19000`) on the Envoy deployment that corresponds to a Gateway so that it can be accessed locally. + +Get the name of the Envoy deployment. The following example is for Gateway `eg` in the `default` namespace: + +```shell +export ENVOY_DEPLOYMENT=$(kubectl get deploy -n envoy-gateway-system --selector=gateway.envoyproxy.io/owning-gateway-namespace=default,gateway.envoyproxy.io/owning-gateway-name=eg -o jsonpath='{.items[0].metadata.name}') +``` + +Port forward the admin interface port: + +```shell +kubectl port-forward deploy/${ENVOY_DEPLOYMENT} -n envoy-gateway-system 19000:19000 +``` + +Now you are able to view the running Envoy configuration by navigating to `127.0.0.1:19000/config_dump`. + +There are many other endpoints on the [Envoy admin interface][] that may be helpful when debugging. + +### JWT Testing + +An example [JSON Web Token (JWT)][jwt] and [JSON Web Key Set (JWKS)][jwks] are used for the [request authentication][] +user guide. The JWT was created by the [JWT Debugger][], using the `RS256` algorithm. The public key from the JWTs +verify signature was copied to [JWK Creator][] for generating the JWK. The JWK Creator was configured with matching +settings, i.e. `Signing` public key use and the `RS256` algorithm. The generated JWK was wrapped in a JWKS structure +and is hosted in the repo. + +[Quickstart]: https://github.com/envoyproxy/gateway/blob/main/docs/latest/user/quickstart.md +[make]: https://www.gnu.org/software/make/ +[Github Actions]: https://docs.github.com/en/actions +[workflows]: https://github.com/envoyproxy/gateway/tree/main/.github/workflows +[Kind]: https://kind.sigs.k8s.io/ +[conformance homepage]: https://gateway-api.sigs.k8s.io/concepts/conformance/ +[directly exposing]: https://kind.sigs.k8s.io/docs/user/loadbalancer/ +[Kubernetes support]: https://docs.docker.com/desktop/kubernetes/ +[gateway-dev]: https://hub.docker.com/r/envoyproxy/gateway-dev/tags +[mac_connect]: https://github.com/chipmk/docker-mac-net-connect +[Envoy admin interface]: https://www.envoyproxy.io/docs/envoy/latest/operations/admin#operations-admin-interface +[jwt]: https://tools.ietf.org/html/rfc7519 +[jwks]: https://tools.ietf.org/html/rfc7517 +[request authentication]: https://gateway.envoyproxy.io/latest/user/authn.html +[JWT Debugger]: https://jwt.io/ +[JWK Creator]: https://russelldavies.github.io/jwk-creator/ diff --git a/site/content/en/v1.0.0/contributions/DOCS.md b/site/content/en/v1.0.0/contributions/DOCS.md new file mode 100644 index 00000000000..ae19953a8b5 --- /dev/null +++ b/site/content/en/v1.0.0/contributions/DOCS.md @@ -0,0 +1,69 @@ +--- +title: "Working on Envoy Gateway Docs" +description: "This section tells the development of + Envoy Gateway Documents." +--- + +{{% alert title="Note" color="warning" %}} +We migrated from ***Sphinx*** to ***Hugo*** for Envoy Gateway Documents. + +Read blog: [Welcome to new website!](/blog/2023/10/08/welcome-to-new-website/) +{{% /alert %}} + +The documentation for the Envoy Gateway lives in the `site/content/en` directory. Any +individual document can be written using [Markdown]. + +## Documentation Structure + +We supported the versioned Docs now, the directory name under docs represents +the version of docs. The root of the latest site is in `site/content/en/latest`. +This is probably where to start if you're trying to understand how things fit together. + +Note that the new contents should be added to `site/content/en/latest` and will be cut off at +the next release. The contents under `site/content/en/v0.5.0` are auto-generated, +and usually do not need to make changes to them, unless if you find the current release pages have +some incorrect contents. If so, you should send a PR to update contents both of `site/content/en/latest` +and `site/content/en/v0.5.0`. + +You can access the website which represents the current release in default, +and you can access the website which contains the latest version changes in +[Here][latest-website] or at the footer of the pages. + +## Documentation Workflow + +To work with the docs, just edit Markdown files in `site/content/en/latest`, +then run + +```bash +make docs +``` + +This will create `site/public` with the built HTML pages. You can preview it +by running: + +``` shell +make docs-serve +``` + +If you want to generate a new release version of the docs, like `v0.6.0`, then run + +```bash +make docs-release TAG=v0.6.0 +``` + +This will update the VERSION file at the project root, which records current release version, +and it will be used in the pages version context and binary version output. Also, this will generate +new dir `site/content/en/v0.6.0`, which contains docs at v0.6.0 and updates artifact links to `v0.6.0` +in all files under `site/content/en/v0.6.0/user`, like `quickstart.md`, `http-routing.md` and etc. + +## Publishing Docs + +Whenever docs are pushed to `main`, CI will publish the built docs to GitHub +Pages. For more details, see `.github/workflows/docs.yaml`. + +## Reference + +Go to [Hugo](https://gohugo.io) and [Docsy](https://www.docsy.dev/docs) to learn more. + +[Markdown]: https://daringfireball.net/projects/markdown/syntax +[latest-website]: /latest diff --git a/site/content/en/v1.0.0/contributions/RELEASING.md b/site/content/en/v1.0.0/contributions/RELEASING.md new file mode 100644 index 00000000000..50d2db76abd --- /dev/null +++ b/site/content/en/v1.0.0/contributions/RELEASING.md @@ -0,0 +1,252 @@ +--- +title: "Release Process" +description: "This section tells the release process of Envoy Gateway." +--- + +This document guides maintainers through the process of creating an Envoy Gateway release. + +- [Release Candidate](#release-candidate) +- [Minor Release](#minor-release) +- [Announce the Release](#announce-the-release) + +## Release Candidate + +The following steps should be used for creating a release candidate. + +### Prerequisites + +- Permissions to push to the Envoy Gateway repository. + +Set environment variables for use in subsequent steps: + +```shell +export MAJOR_VERSION=0 +export MINOR_VERSION=3 +export RELEASE_CANDIDATE_NUMBER=1 +export GITHUB_REMOTE=origin +``` + +1. Clone the repo, checkout the `main` branch, ensure it’s up-to-date, and your local branch is clean. +2. Create a topic branch for adding the release notes and updating the [VERSION][] file with the release version. Refer to previous [release notes][] and [VERSION][] for additional details. +3. Sign, commit, and push your changes to your fork. +4. Submit a [Pull Request][] to merge the changes into the `main` branch. Do not proceed until your PR has merged and + the [Build and Test][] has successfully completed. +5. Create a new release branch from `main`. The release branch should be named + `release/v${MAJOR_VERSION}.${MINOR_VERSION}`, e.g. `release/v0.3`. + + ```shell + git checkout -b release/v${MAJOR_VERSION}.${MINOR_VERSION} + ``` + +6. Push the branch to the Envoy Gateway repo. + + ```shell + git push ${GITHUB_REMOTE} release/v${MAJOR_VERSION}.${MINOR_VERSION} + ``` + +7. Create a topic branch for updating the Envoy proxy image and Envoy Ratelimit image to the tag supported by the release. Reference [PR #2098][] + for additional details on updating the image tag. +8. Sign, commit, and push your changes to your fork. +9. Submit a [Pull Request][] to merge the changes into the `release/v${MAJOR_VERSION}.${MINOR_VERSION}` branch. Do not + proceed until your PR has merged into the release branch and the [Build and Test][] has completed for your PR. +10. Ensure your release branch is up-to-date and tag the head of your release branch with the release candidate number. + + ```shell + git tag -a v${MAJOR_VERSION}.${MINOR_VERSION}.0-rc.${RELEASE_CANDIDATE_NUMBER} -m 'Envoy Gateway v${MAJOR_VERSION}.${MINOR_VERSION}.0-rc.${RELEASE_CANDIDATE_NUMBER} Release Candidate' + ``` + +11. Push the tag to the Envoy Gateway repository. + + ```shell + git push ${GITHUB_REMOTE} v${MAJOR_VERSION}.${MINOR_VERSION}.0-rc.${RELEASE_CANDIDATE_NUMBER} + ``` + +12. This will trigger the [release GitHub action][] that generates the release, release artifacts, etc. +13. Confirm that the [release workflow][] completed successfully. +14. Confirm that the Envoy Gateway [image][] with the correct release tag was published to Docker Hub. +15. Confirm that the [release][] was created. +16. Note that the [Quickstart Guide][] references are __not__ updated for release candidates. However, test + the quickstart steps using the release candidate by manually updating the links. +17. [Generate][] the GitHub changelog. +18. Ensure you check the "This is a pre-release" checkbox when editing the GitHub release. +19. If you find any bugs in this process, please create an issue. + +### Setup cherry picker action + +After release branch cut, RM (Release Manager) should add job [cherrypick action](../../../.github/workflows/cherrypick.yaml) for target release. + +Configuration looks like following: + +```yaml + cherry_pick_release_v0_4: + runs-on: ubuntu-latest + name: Cherry pick into release-v0.4 + if: ${{ contains(github.event.pull_request.labels.*.name, 'cherrypick/release-v0.4') && github.event.pull_request.merged == true }} + steps: + - name: Checkout + uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1 + with: + fetch-depth: 0 + - name: Cherry pick into release/v0.4 + uses: carloscastrojumo/github-cherry-pick-action@a145da1b8142e752d3cbc11aaaa46a535690f0c5 # v1.0.9 + with: + branch: release/v0.4 + title: "[release/v0.4] {old_title}" + body: "Cherry picking #{old_pull_request_id} onto release/v0.4" + labels: | + cherrypick/release-v0.4 + # put release manager here + reviewers: | + AliceProxy +``` + +Replace `v0.4` with real branch name, and `AliceProxy` with the real name of RM. + +## Minor Release + +The following steps should be used for creating a minor release. + +### Prerequisites + +- Permissions to push to the Envoy Gateway repository. +- A release branch that has been cut from the corresponding release candidate. Refer to the + [Release Candidate](#release-candidate) section for additional details on cutting a release candidate. + +Set environment variables for use in subsequent steps: + +```shell +export MAJOR_VERSION=0 +export MINOR_VERSION=3 +export GITHUB_REMOTE=origin +``` + +1. Clone the repo, checkout the `main` branch, ensure it’s up-to-date, and your local branch is clean. +2. Create a topic branch for adding the release notes, release announcement, and versioned release docs. + + 1. Create the release notes. Reference previous [release notes][] for additional details. __Note:__ The release + notes should be an accumulation of the release candidate release notes and any changes since the release + candidate. + 2. Create a release announcement. Refer to [PR #635] as an example release announcement. + 3. Include the release in the compatibility matrix. Refer to [PR #1002] as an example. + 4. Generate the versioned release docs: + + ``` shell + make docs-release TAG=v${MAJOR_VERSION}.${MINOR_VERSION}.0 + ``` + + 5. Update the `Get Started` and `Contributing` button referred link in `site/content/en/_index.md`: + + ```shell + + Get Started + + + Contributing + + ``` + + 6. Uodate the `Documentation` referred link on the menu in `site/hugo.toml`: + + ```shell + [[menu.main]] + name = "Documentation" + weight = -101 + pre = "" + url = "/v0.5.0" + ``` + +3. Sign, commit, and push your changes to your fork. +4. Submit a [Pull Request][] to merge the changes into the `main` branch. Do not proceed until all your PRs have merged + and the [Build and Test][] has completed for your final PR. + +5. Checkout the release branch. + + ```shell + git checkout -b release/v${MAJOR_VERSION}.${MINOR_VERSION} $GITHUB_REMOTE/release/v${MAJOR_VERSION}.${MINOR_VERSION} + ``` + +6. If the tip of the release branch does not match the tip of `main`, perform the following: + + 1. Create a topic branch from the release branch. + 2. Cherry-pick the commits from `main` that differ from the release branch. + 3. Run tests locally, e.g. `make lint`. + 4. Sign, commit, and push your topic branch to your Envoy Gateway fork. + 5. Submit a PR to merge the topic from of your fork into the Envoy Gateway release branch. + 6. Do not proceed until the PR has merged and CI passes for the merged PR. + 7. If you are still on your topic branch, change to the release branch: + + ```shell + git checkout release/v${MAJOR_VERSION}.${MINOR_VERSION} + ``` + + 8. Ensure your local release branch is up-to-date: + + ```shell + git pull $GITHUB_REMOTE release/v${MAJOR_VERSION}.${MINOR_VERSION} + ``` + +7. Tag the head of your release branch with the release tag. For example: + + ```shell + git tag -a v${MAJOR_VERSION}.${MINOR_VERSION}.0 -m 'Envoy Gateway v${MAJOR_VERSION}.${MINOR_VERSION}.0 Release' + ``` + + __Note:__ The tag version differs from the release branch by including the `.0` patch version. + +8. Push the tag to the Envoy Gateway repository. + + ```shell + git push origin v${MAJOR_VERSION}.${MINOR_VERSION}.0 + ``` + +9. This will trigger the [release GitHub action][] that generates the release, release artifacts, etc. +10. Confirm that the [release workflow][] completed successfully. +11. Confirm that the Envoy Gateway [image][] with the correct release tag was published to Docker Hub. +12. Confirm that the [release][] was created. +13. Confirm that the steps in the [Quickstart Guide][] work as expected. +14. [Generate][] the GitHub changelog and include the following text at the beginning of the release page: + + ```console + # Release Announcement + + Check out the [v${MAJOR_VERSION}.${MINOR_VERSION} release announcement] + (https://gateway.envoyproxy.io/releases/v${MAJOR_VERSION}.${MINOR_VERSION}.html) to learn more about the release. + ``` + +If you find any bugs in this process, please create an issue. + +## Announce the Release + +It's important that the world knows about the release. Use the following steps to announce the release. + +1. Set the release information in the Envoy Gateway Slack channel. For example: + + ```shell + Envoy Gateway v${MAJOR_VERSION}.${MINOR_VERSION} has been released: https://github.com/envoyproxy/gateway/releases/tag/v${MAJOR_VERSION}.${MINOR_VERSION}.0 + ``` + +2. Send a message to the Envoy Gateway Slack channel. For example: + + ```shell + On behalf of the entire Envoy Gateway community, I am pleased to announce the release of Envoy Gateway + v${MAJOR_VERSION}.${MINOR_VERSION}. A big thank you to all the contributors that made this release possible. + Refer to the official v${MAJOR_VERSION}.${MINOR_VERSION} announcement for release details and the project docs + to start using Envoy Gateway. + ... + ``` + + Link to the GitHub release and release announcement page that highlights the release. + +[release notes]: https://github.com/envoyproxy/gateway/tree/main/release-notes +[Pull Request]: https://github.com/envoyproxy/gateway/pulls +[Quickstart Guide]: https://github.com/envoyproxy/gateway/blob/main/docs/user/quickstart.md +[Build and Test]: https://github.com/envoyproxy/gateway/blob/main/.github/workflows/build_and_test.yaml +[release GitHub action]: https://github.com/envoyproxy/gateway/blob/main/.github/workflows/release.yaml +[release workflow]: https://github.com/envoyproxy/gateway/actions/workflows/release.yaml +[image]: https://hub.docker.com/r/envoyproxy/gateway/tags +[release]: https://github.com/envoyproxy/gateway/releases +[Generate]: https://docs.github.com/en/repositories/releasing-projects-on-github/automatically-generated-release-notes +[PR #635]: https://github.com/envoyproxy/gateway/pull/635 +[PR #2098]: https://github.com/envoyproxy/gateway/pull/2098 +[PR #1002]: https://github.com/envoyproxy/gateway/pull/1002 +[VERSION]: https://github.com/envoyproxy/gateway/blob/main/VERSION diff --git a/site/content/en/v1.0.0/contributions/_index.md b/site/content/en/v1.0.0/contributions/_index.md new file mode 100644 index 00000000000..1d3037e609e --- /dev/null +++ b/site/content/en/v1.0.0/contributions/_index.md @@ -0,0 +1,5 @@ +--- +title: Get Involved +description: "This section includes contents related to Contributions" +weight: 100 +--- diff --git a/site/content/en/v1.0.0/contributions/design/_index.md b/site/content/en/v1.0.0/contributions/design/_index.md new file mode 100644 index 00000000000..5cacb86df70 --- /dev/null +++ b/site/content/en/v1.0.0/contributions/design/_index.md @@ -0,0 +1,5 @@ +--- +title: "Design" +weight: -100 +description: This section includes Designs of Envoy Gateway. +--- diff --git a/site/content/en/v1.0.0/contributions/design/accesslog.md b/site/content/en/v1.0.0/contributions/design/accesslog.md new file mode 100644 index 00000000000..a229d5f6eff --- /dev/null +++ b/site/content/en/v1.0.0/contributions/design/accesslog.md @@ -0,0 +1,243 @@ +--- +title: "Observability: Accesslog" +--- + +## Overview + +Envoy supports extensible accesslog to different sinks, File, gRPC etc. Envoy supports customizable access log formats using predefined fields as well as arbitrary HTTP request and response headers. Envoy supports several built-in access log filters and extension filters that are registered at runtime. + +Envoy Gateway leverages [Gateway API][] for configuring managed Envoy proxies. Gateway API defines core, extended, and implementation-specific API [support levels][] for implementers such as Envoy Gateway to expose features. Since accesslog is not covered by `Core` or `Extended` APIs, EG should provide an easy to config access log formats and sinks per `EnvoyProxy`. + +## Goals + +- Support send accesslog to `File` or `OpenTelemetry` backend +- TODO: Support access log filters base on [CEL][] expression + +## Non-Goals + +- Support non-CEL filters, e.g. `status_code_filter`, `response_flag_filter` +- Support [HttpGrpcAccessLogConfig][] or [TcpGrpcAccessLogConfig][] + +## Use-Cases + +- Configure accesslog for a `EnvoyProxy` to `File` +- Configure accesslog for a `EnvoyProxy` to `OpenTelemetry` backend +- Configure multi accesslog providers for a `EnvoyProxy` + +### ProxyAccessLog API Type + +```golang mdox-exec="sed '1,7d' api/config/v1alpha1/accesslogging_types.go" +type ProxyAccessLog struct { + // Disable disables access logging for managed proxies if set to true. + Disable bool `json:"disable,omitempty"` + // Settings defines accesslog settings for managed proxies. + // If unspecified, will send default format to stdout. + // +optional + Settings []ProxyAccessLogSetting `json:"settings,omitempty"` +} + +type ProxyAccessLogSetting struct { + // Format defines the format of accesslog. + Format ProxyAccessLogFormat `json:"format"` + // Sinks defines the sinks of accesslog. + // +kubebuilder:validation:MinItems=1 + Sinks []ProxyAccessLogSink `json:"sinks"` +} + +type ProxyAccessLogFormatType string + +const ( + // ProxyAccessLogFormatTypeText defines the text accesslog format. + ProxyAccessLogFormatTypeText ProxyAccessLogFormatType = "Text" + // ProxyAccessLogFormatTypeJSON defines the JSON accesslog format. + ProxyAccessLogFormatTypeJSON ProxyAccessLogFormatType = "JSON" + // TODO: support format type "mix" in the future. +) + +// ProxyAccessLogFormat defines the format of accesslog. +// +union +type ProxyAccessLogFormat struct { + // Type defines the type of accesslog format. + // +kubebuilder:validation:Enum=Text;JSON + // +unionDiscriminator + Type ProxyAccessLogFormatType `json:"type,omitempty"` + // Text defines the text accesslog format, following Envoy accesslog formatting, + // empty value results in proxy's default access log format. + // It's required when the format type is "Text". + // Envoy [command operators](https://www.envoyproxy.io/docs/envoy/latest/configuration/observability/access_log/usage#command-operators) may be used in the format. + // The [format string documentation](https://www.envoyproxy.io/docs/envoy/latest/configuration/observability/access_log/usage#config-access-log-format-strings) provides more information. + // +optional + Text *string `json:"text,omitempty"` + // JSON is additional attributes that describe the specific event occurrence. + // Structured format for the envoy access logs. Envoy [command operators](https://www.envoyproxy.io/docs/envoy/latest/configuration/observability/access_log/usage#command-operators) + // can be used as values for fields within the Struct. + // It's required when the format type is "JSON". + // +optional + JSON map[string]string `json:"json,omitempty"` +} + +type ProxyAccessLogSinkType string + +const ( + // ProxyAccessLogSinkTypeFile defines the file accesslog sink. + ProxyAccessLogSinkTypeFile ProxyAccessLogSinkType = "File" + // ProxyAccessLogSinkTypeOpenTelemetry defines the OpenTelemetry accesslog sink. + ProxyAccessLogSinkTypeOpenTelemetry ProxyAccessLogSinkType = "OpenTelemetry" +) + +type ProxyAccessLogSink struct { + // Type defines the type of accesslog sink. + // +kubebuilder:validation:Enum=File;OpenTelemetry + Type ProxyAccessLogSinkType `json:"type,omitempty"` + // File defines the file accesslog sink. + // +optional + File *FileEnvoyProxyAccessLog `json:"file,omitempty"` + // OpenTelemetry defines the OpenTelemetry accesslog sink. + // +optional + OpenTelemetry *OpenTelemetryEnvoyProxyAccessLog `json:"openTelemetry,omitempty"` +} + +type FileEnvoyProxyAccessLog struct { + // Path defines the file path used to expose envoy access log(e.g. /dev/stdout). + // Empty value disables accesslog. + Path string `json:"path,omitempty"` +} + +// TODO: consider reuse ExtensionService? +type OpenTelemetryEnvoyProxyAccessLog struct { + // Host define the extension service hostname. + Host string `json:"host"` + // Port defines the port the extension service is exposed on. + // + // +optional + // +kubebuilder:validation:Minimum=0 + // +kubebuilder:default=4317 + Port int32 `json:"port,omitempty"` + // Resources is a set of labels that describe the source of a log entry, including envoy node info. + // It's recommended to follow [semantic conventions](https://opentelemetry.io/docs/reference/specification/resource/semantic_conventions/). + // +optional + Resources map[string]string `json:"resources,omitempty"` + + // TODO: support more OpenTelemetry accesslog options(e.g. TLS, auth etc.) in the future. +} +``` + +### Example + +- The following is an example to disable access log. + +```yaml mdox-exec="sed '1,12d' examples/kubernetes/accesslog/disable-accesslog.yaml" +apiVersion: gateway.envoyproxy.io/v1alpha1 +kind: EnvoyProxy +metadata: + name: disable-accesslog + namespace: envoy-gateway-system +spec: + telemetry: + accessLog: + disable: true +``` + +- The following is an example with text format access log. + +```yaml mdox-exec="sed '1,12d' examples/kubernetes/accesslog/text-accesslog.yaml" +apiVersion: gateway.envoyproxy.io/v1alpha1 +kind: EnvoyProxy +metadata: + name: text-access-logging + namespace: envoy-gateway-system +spec: + telemetry: + accessLog: + settings: + - format: + type: Text + text: | + [%START_TIME%] "%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%" %RESPONSE_CODE% %RESPONSE_FLAGS% %BYTES_RECEIVED% %BYTES_SENT% %DURATION% "%REQ(X-FORWARDED-FOR)%" "%REQ(USER-AGENT)%" "%REQ(X-REQUEST-ID)%" "%REQ(:AUTHORITY)%" "%UPSTREAM_HOST%" + sinks: + - type: File + file: + path: /dev/stdout +``` + +- The following is an example with json format access log. + +```yaml mdox-exec="sed '1,12d' examples/kubernetes/accesslog/json-accesslog.yaml" +apiVersion: gateway.envoyproxy.io/v1alpha1 +kind: EnvoyProxy +metadata: + name: json-access-logging + namespace: envoy-gateway-system +spec: + telemetry: + accessLog: + settings: + - format: + type: JSON + json: + status: "%RESPONSE_CODE%" + message: "%LOCAL_REPLY_BODY%" + sinks: + - type: File + file: + path: /dev/stdout +``` + +- The following is an example with OpenTelemetry format access log. + +```yaml mdox-exec="sed '1,12d' examples/kubernetes/accesslog/otel-accesslog.yaml" +apiVersion: gateway.envoyproxy.io/v1alpha1 +kind: EnvoyProxy +metadata: + name: otel-access-logging + namespace: envoy-gateway-system +spec: + telemetry: + accessLog: + settings: + - format: + type: Text + text: | + [%START_TIME%] "%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%" %RESPONSE_CODE% %RESPONSE_FLAGS% %BYTES_RECEIVED% %BYTES_SENT% %DURATION% "%REQ(X-FORWARDED-FOR)%" "%REQ(USER-AGENT)%" "%REQ(X-REQUEST-ID)%" "%REQ(:AUTHORITY)%" "%UPSTREAM_HOST%" + sinks: + - type: OpenTelemetry + openTelemetry: + host: otel-collector.monitoring.svc.cluster.local + port: 4317 + resources: + k8s.cluster.name: "cluster-1" +``` + +- The following is an example of sending same format to different sinks. + +```yaml mdox-exec="sed '1,12d' examples/kubernetes/accesslog/multi-sinks.yaml" +apiVersion: gateway.envoyproxy.io/v1alpha1 +kind: EnvoyProxy +metadata: + name: multi-sinks + namespace: envoy-gateway-system +spec: + telemetry: + accessLog: + settings: + - format: + type: Text + text: | + [%START_TIME%] "%REQ(:METHOD)% %REQ(X-ENVOY-ORIGINAL-PATH?:PATH)% %PROTOCOL%" %RESPONSE_CODE% %RESPONSE_FLAGS% %BYTES_RECEIVED% %BYTES_SENT% %DURATION% "%REQ(X-FORWARDED-FOR)%" "%REQ(USER-AGENT)%" "%REQ(X-REQUEST-ID)%" "%REQ(:AUTHORITY)%" "%UPSTREAM_HOST%" + sinks: + - type: File + file: + path: /dev/stdout + - type: OpenTelemetry + openTelemetry: + host: otel-collector.monitoring.svc.cluster.local + port: 4317 + resources: + k8s.cluster.name: "cluster-1" +``` + +[Gateway API]: https://gateway-api.sigs.k8s.io/ +[support levels]: https://gateway-api.sigs.k8s.io/concepts/conformance/?h=extended#2-support-levels +[CEL]: https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/access_loggers/filters/cel/v3/cel.proto#extension-envoy-access-loggers-extension-filters-cel +[HttpGrpcAccessLogConfig]: https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/access_loggers/grpc/v3/als.proto#extensions-access-loggers-grpc-v3-httpgrpcaccesslogconfig +[TcpGrpcAccessLogConfig]: https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/access_loggers/grpc/v3/als.proto#extensions-access-loggers-grpc-v3-tcpgrpcaccesslogconfig diff --git a/site/content/en/v1.0.0/contributions/design/backend-traffic-policy.md b/site/content/en/v1.0.0/contributions/design/backend-traffic-policy.md new file mode 100644 index 00000000000..9411ef20978 --- /dev/null +++ b/site/content/en/v1.0.0/contributions/design/backend-traffic-policy.md @@ -0,0 +1,156 @@ +--- +title: "BackendTrafficPolicy" +--- + +## Overview + +This design document introduces the `BackendTrafficPolicy` API allowing users to configure +the behavior for how the Envoy Proxy server communicates with upstream backend services/endpoints. + +## Goals + +- Add an API definition to hold settings for configuring behavior of the connection between the backend services +and Envoy Proxy listener. + +## Non Goals + +- Define the API configuration fields in this API. + +## Implementation + +`BackendTrafficPolicy` is an implied hierarchy type API that can be used to extend [Gateway API][]. +It can target either a `Gateway`, or an xRoute (`HTTPRoute`/`GRPCRoute`/etc.). When targeting a `Gateway`, +it will apply the configured settings within ght `BackendTrafficPolicy` to all children xRoute resources of that `Gateway`. +If a `BackendTrafficPolicy` targets an xRoute and a different `BackendTrafficPolicy` targets the `Gateway` that route belongs to, +then the configuration from the policy that is targeting the xRoute resource will win in a conflict. + +### Example + +Here is an example highlighting how a user can configure this API. + +```yaml +apiVersion: gateway.networking.k8s.io/v1 +kind: GatewayClass +metadata: + name: eg +spec: + controllerName: gateway.envoyproxy.io/gatewayclass-controller +--- +apiVersion: gateway.networking.k8s.io/v1 +kind: Gateway +metadata: + name: eg + namespace: default +spec: + gatewayClassName: eg + listeners: + - name: http + protocol: HTTP + port: 80 +--- +apiVersion: gateway.networking.k8s.io/v1 +kind: HTTPRoute +metadata: + name: ipv4-route + namespace: default +spec: + parentRefs: + - name: eg + hostnames: + - "www.foo.example.com" + rules: + - backendRefs: + - group: "" + kind: Service + name: ipv4-service + port: 3000 + weight: 1 + matches: + - path: + type: PathPrefix + value: / +--- +apiVersion: gateway.networking.k8s.io/v1 +kind: HTTPRoute +metadata: + name: ipv6-route + namespace: default +spec: + parentRefs: + - name: eg + hostnames: + - "www.bar.example.com" + rules: + - backendRefs: + - group: "" + kind: Service + name: ipv6-service + port: 3000 + weight: 1 + matches: + - path: + type: PathPrefix + value: / +--- +apiVersion: gateway.envoyproxy.io/v1alpha1 +kind: BackendTrafficPolicy +metadata: + name: default-ipv-policy + namespace: default +spec: + protocols: + enableIPv6: false + targetRef: + group: gateway.networking.k8s.io + kind: Gateway + name: eg + namespace: default +--- +apiVersion: gateway.envoyproxy.io/v1alpha1 +kind: BackendTrafficPolicy +metadata: + name: ipv6-support-policy + namespace: default +spec: + protocols: + enableIPv6: true + targetRef: + group: gateway.networking.k8s.io + kind: HTTPRoute + name: ipv6-route + namespace: default +``` + +## Features / API Fields + +Here is a list of some features that can be included in this API. Note that this list is not exhaustive. + +- Protocol configuration +- Circuit breaking +- Retries +- Keep alive probes +- Health checking +- Load balancing +- Rate limit + +## Design Decisions + +- This API will only support a single `targetRef` and can bind to only a `Gateway` or xRoute (`HTTPRoute`/`GRPCRoute`/etc.) resource. +- This API resource MUST be part of same namespace as the resource it targets. +- There can be only be ONE policy resource attached to a specific `Listener` (section) within a `Gateway` +- If the policy targets a resource but cannot attach to it, this information should be reflected +in the Policy Status field using the `Conflicted=True` condition. +- If multiple polices target the same resource, the oldest resource (based on creation timestamp) will +attach to the Gateway Listeners, the others will not. +- If Policy A has a `targetRef` that includes a `sectionName` i.e. +it targets a specific Listener within a `Gateway` and Policy B has a `targetRef` that targets the same +entire Gateway then + - Policy A will be applied/attached to the specific Listener defined in the `targetRef.SectionName` + - Policy B will be applied to the remaining Listeners within the Gateway. Policy B will have an additional + status condition `Overridden=True`. + +## Alternatives + +- The project can indefintely wait for these configuration parameters to be part of the [Gateway API][]. + +[Gateway API]: https://gateway-api.sigs.k8s.io/ diff --git a/site/content/en/v1.0.0/contributions/design/bootstrap.md b/site/content/en/v1.0.0/contributions/design/bootstrap.md new file mode 100644 index 00000000000..c0581347a24 --- /dev/null +++ b/site/content/en/v1.0.0/contributions/design/bootstrap.md @@ -0,0 +1,381 @@ +--- +title: "Bootstrap Design" +--- + +## Overview + +[Issue 31][] specifies the need for allowing advanced users to specify their custom +Envoy Bootstrap configuration rather than using the default Bootstrap configuration +defined in Envoy Gateway. This allows advanced users to extend Envoy Gateway and +support their custom use cases such setting up tracing and stats configuration +that is not supported by Envoy Gateway. + +## Goals + +* Define an API field to allow a user to specify a custom Bootstrap +* Provide tooling to allow the user to generate the default Bootstrap configuration + as well as validate their custom Bootstrap. + +## Non Goals + +* Allow user to configure only a section of the Bootstrap + +## API + +Leverage the existing [EnvoyProxy][] resource which can be attached to the [GatewayClass][] using +the [parametersRef][] field, and define a `Bootstrap` field within the resource. If this field is set, +the value is used as the Bootstrap configuration for all managed Envoy Proxies created by Envoy Gateway. + +```go +// EnvoyProxySpec defines the desired state of EnvoyProxy. +type EnvoyProxySpec struct { + ...... + // Bootstrap defines the Envoy Bootstrap as a YAML string. + // Visit https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/bootstrap/v3/bootstrap.proto#envoy-v3-api-msg-config-bootstrap-v3-bootstrap + // to learn more about the syntax. + // If set, this is the Bootstrap configuration used for the managed Envoy Proxy fleet instead of the default Bootstrap configuration + // set by Envoy Gateway. + // Some fields within the Bootstrap that are required to communicate with the xDS Server (Envoy Gateway) and receive xDS resources + // from it are not configurable and will result in the `EnvoyProxy` resource being rejected. + // Backward compatibility across minor versions is not guaranteed. + // We strongly recommend using `egctl x translate` to generate a `EnvoyProxy` resource with the `Bootstrap` field set to the default + // Bootstrap configuration used. You can edit this configuration, and rerun `egctl x translate` to ensure there are no validation errors. + // + // +optional + Bootstrap *string `json:"bootstrap,omitempty"` +} +``` + +## Tooling + +A CLI tool `egctl x translate` will be provided to the user to help generate a working Bootstrap configuration. +Here is an example where a user inputs a `GatewayClass` and the CLI generates the `EnvoyProxy` resource with the `Bootstrap` field populated. + +``` +cat < /etc/envoy-gateway/config.yaml +apiVersion: gateway.envoyproxy.io/v1alpha1 +kind: EnvoyGateway +provider: + type: Kubernetes + kubernetes: {} +EOF +``` + +This configuration will cause Envoy Gateway to use the Kubernetes provider with default configuration parameters. + +The Kubernetes provider can be configured using the `provider` field. For example, the `foo` field can be set to "bar": + +```yaml +$ cat << EOF > /etc/envoy-gateway/config.yaml +apiVersion: gateway.envoyproxy.io/v1alpha1 +kind: EnvoyGateway +provider: + type: Kubernetes + kubernetes: + foo: bar +EOF +``` + +__Note:__ The Provider API from the Kubernetes package is currently undefined and `foo: bar` is provided for +illustration purposes only. + +The same API structure is followed for each supported provider. The following example causes Envoy Gateway to use the +File provider: + +```yaml +$ cat << EOF > /etc/envoy-gateway/config.yaml +apiVersion: gateway.envoyproxy.io/v1alpha1 +kind: EnvoyGateway +provider: + type: File + file: + foo: bar +EOF +``` + +__Note:__ The Provider API from the File package is currently undefined and `foo: bar` is provided for illustration +purposes only. + +Gateway API-related configuration is expressed through the `gateway` field. If unspecified, Envoy Gateway will use +default configuration parameters for `gateway`. The following example causes the [GatewayClass][gc] controller to +manage GatewayClasses with controllerName `foo` instead of the default `gateway.envoyproxy.io/gatewayclass-controller`: + +```yaml +$ cat << EOF > /etc/envoy-gateway/config.yaml +apiVersion: gateway.envoyproxy.io/v1alpha1 +kind: EnvoyGateway +gateway: + controllerName: foo +EOF +``` + +With any of the above configuration examples, Envoy Gateway can be started without any additional arguments: + +```shell +$ ./envoy-gateway +``` + +## Data Plane API + +The data plane is configured dynamically through Kubernetes resources, primarily [Gateway API][gw_api] objects. +Optionally, the data plane infrastructure can be configured by referencing a [custom resource (CR)][cr] through +`spec.parametersRef` of the managed GatewayClass. The `EnvoyProxy` API defines the data plane infrastructure +configuration and is represented as the CR referenced by the managed GatewayClass. Key points of this API are: + +* If unreferenced by `gatewayclass.spec.parametersRef`, default parameters will be used to configure the data plane + infrastructure, e.g. expose Envoy network endpoints using a LoadBalancer service. +* Envoy Gateway will follow Gateway API [recommendations][gc] regarding updates to the EnvoyProxy CR: + > It is recommended that this resource be used as a template for Gateways. This means that a Gateway is based on the + > state of the GatewayClass at the time it was created and changes to the GatewayClass or associated parameters are + > not propagated down to existing Gateways. + +The initial `EnvoyProxy` API: + +```go +// gateway/api/config/v1alpha1/envoyproxy.go + +package v1alpha1 + +import ( + metav1 "k8s.io/apimachinery/pkg/apis/meta/v1" +) + +// EnvoyProxy is the Schema for the envoyproxies API. +type EnvoyProxy struct { + metav1.TypeMeta `json:",inline"` + metav1.ObjectMeta `json:"metadata,omitempty"` + + Spec EnvoyProxySpec `json:"spec,omitempty"` + Status EnvoyProxyStatus `json:"status,omitempty"` +} + +// EnvoyProxySpec defines the desired state of Envoy Proxy infrastructure +// configuration. +type EnvoyProxySpec struct { + // Undefined by this design spec. +} + +// EnvoyProxyStatus defines the observed state of EnvoyProxy. +type EnvoyProxyStatus struct { + // Undefined by this design spec. +} +``` + +The EnvoyProxySpec and EnvoyProxyStatus fields will be defined in the future as proxy infrastructure configuration use +cases are better understood. + +### Data Plane Configuration + +GatewayClass and Gateway resources define the data plane infrastructure. Note that all examples assume Envoy Gateway is +running with the Kubernetes provider. + +```yaml +apiVersion: gateway.networking.k8s.io/v1 +kind: GatewayClass +metadata: + name: example-class +spec: + controllerName: gateway.envoyproxy.io/gatewayclass-controller +--- +apiVersion: gateway.networking.k8s.io/v1 +kind: Gateway +metadata: + name: example-gateway +spec: + gatewayClassName: example-class + listeners: + - name: http + protocol: HTTP + port: 80 +``` + +Since the GatewayClass does not define `spec.parametersRef`, the data plane is provisioned using default configuration +parameters. The Envoy proxies will be configured with a http listener and a Kubernetes LoadBalancer service listening +on port 80. + +The following example will configure the data plane to use a ClusterIP service instead of the default LoadBalancer +service: + +```yaml +apiVersion: gateway.networking.k8s.io/v1 +kind: GatewayClass +metadata: + name: example-class +spec: + controllerName: gateway.envoyproxy.io/gatewayclass-controller + parametersRef: + name: example-config + group: gateway.envoyproxy.io + kind: EnvoyProxy +--- +apiVersion: gateway.networking.k8s.io/v1 +kind: Gateway +metadata: + name: example-gateway +spec: + gatewayClassName: example-class + listeners: + - name: http + protocol: HTTP + port: 80 +--- +apiVersion: gateway.envoyproxy.io/v1alpha1 +kind: EnvoyProxy +metadata: + name: example-config +spec: + networkPublishing: + type: ClusterIPService +``` + +__Note:__ The NetworkPublishing API is currently undefined and is provided here for illustration purposes only. + +[issue_51]: https://github.com/envoyproxy/gateway/issues/51 +[design_doc]: ../system-design/ +[gw_api]: https://gateway-api.sigs.k8s.io/ +[gc]: https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1.GatewayClass +[cr]: https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/ +[union]: https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#unions diff --git a/site/content/en/v1.0.0/contributions/design/eg-metrics.md b/site/content/en/v1.0.0/contributions/design/eg-metrics.md new file mode 100644 index 00000000000..0ca0e7229ec --- /dev/null +++ b/site/content/en/v1.0.0/contributions/design/eg-metrics.md @@ -0,0 +1,233 @@ +--- +date: 2023-10-10 +title: "Control Plane Observability: Metrics" +--- + +This document aims to cover all aspects of envoy gateway control plane metrics observability. + +{{% alert title="Note" color="secondary" %}} +**Data plane** observability (while important) is outside of scope for this document. For dataplane observability, refer to [here](../metrics). +{{% /alert %}} + +## Current State + +At present, the Envoy Gateway control plane provides logs and controller-runtime metrics, without traces. Logs are managed through our proprietary library (`internal/logging`, a shim to `zap`) and are written to `/dev/stdout`. + +## Goals + +Our objectives include: + ++ Supporting **PULL** mode for Prometheus metrics and exposing these metrics on the admin address. ++ Supporting **PUSH** mode for Prometheus metrics, thereby sending metrics to the Open Telemetry Stats sink via gRPC or HTTP. + +## Non-Goals + +Our non-goals include: + ++ Supporting other stats sinks. + +## Use-Cases + +The use-cases include: + ++ Exposing Prometheus metrics in the Envoy Gateway Control Plane. ++ Pushing Envoy Gateway Control Plane metrics via the Open Telemetry Sink. + +## Design + +### Standards + +Our metrics, will be built upon the [OpenTelemetry][] standards. All metrics will be configured via the [OpenTelemetry SDK][], which offers neutral libraries that can be connected to various backends. + +This approach allows the Envoy Gateway code to concentrate on the crucial aspect - generating the metrics - and delegate all other tasks to systems designed for telemetry ingestion. + +### Attributes + +OpenTelemetry defines a set of [Semantic Conventions][], including [Kubernetes specific ones][]. + +These attributes can be expressed in logs (as keys of structured logs), traces (as attributes), and metrics (as labels). + +We aim to use attributes consistently where applicable. Where possible, these should adhere to codified Semantic Conventions; when not possible, they should maintain consistency across the project. + +### Extensibility + +Envoy Gateway supports both **PULL/PUSH** mode metrics, with Metrics exported via Prometheus by default. + +Additionally, Envoy Gateway can export metrics using both the [OTEL gRPC metrics exporter][] and [OTEL HTTP metrics exporter][], which pushes metrics by grpc/http to a remote OTEL collector. + +Users can extend these in two ways: + +#### Downstream Collection + +Based on the exported data, other tools can collect, process, and export telemetry as needed. Some examples include: + ++ Metrics in **PULL** mode: The OTEL collector can scrape Prometheus and export to X. ++ Metrics in **PUSH** mode: The OTEL collector can receive OTEL gRPC/HTTP exporter metrics and export to X. + +While the examples above involve OTEL collectors, there are numerous other systems available. + +#### Vendor extensions + +The OTEL libraries allow for the registration of Providers/Handlers. While we will offer the default ones (PULL via Prometheus, PUSH via OTEL HTTP metrics exporter) mentioned in Envoy Gateway's extensibility, we can easily allow custom builds of Envoy Gateway to plug in alternatives if the default options don't meet their needs. + +For instance, users may prefer to write metrics over the OTLP gRPC metrics exporter instead of the HTTP metrics exporter. This is perfectly acceptable -- and almost impossible to prevent. The OTEL has ways to register their providers/exporters, and Envoy Gateway can ensure its usage is such that it's not overly difficult to swap out a different provider/exporter. + +### Stability + +Observability is, in essence, a user-facing API. Its primary purpose is to be consumed - by both humans and tooling. Therefore, having well-defined guarantees around their formats is crucial. + +Please note that this refers only to the contents of the telemetry - what we emit, the names of things, semantics, etc. Other settings like Prometheus vs OTLP, JSON vs plaintext, logging levels, etc., are not considered. + +I propose the following: + +#### Metrics + +Metrics offer the greatest potential for providing guarantees. They often directly influence alerts and dashboards, making changes highly impactful. This contrasts with traces and logs, which are often used for ad-hoc analysis, where minor changes to information can be easily understood by a human. + +Moreover, there is precedent for this: [Kubernetes Metrics Lifecycle][] has well-defined processes, and Envoy Gateway's dataplane (Envoy Proxy) metrics are de facto stable. + +Currently, all Envoy Gateway metrics lack defined stability. I suggest we categorize all existing metrics as either: + ++ ***Deprecated***: a metric that is intended to be phased out. ++ ***Experimental***: a metric that is off by default. ++ ***Alpha***: a metric that is on by default. + +We should aim to promote a core set of metrics to **Stable** within a few releases. + +## Envoy Gateway API Types + +New APIs will be added to Envoy Gateway config, which are used to manage Control Plane Telemetry bootstrap configs. + +### EnvoyGatewayTelemetry + +``` go +// EnvoyGatewayTelemetry defines telemetry configurations for envoy gateway control plane. +// Control plane will focus on metrics observability telemetry and tracing telemetry later. +type EnvoyGatewayTelemetry struct { + // Metrics defines metrics configuration for envoy gateway. + Metrics *EnvoyGatewayMetrics `json:"metrics,omitempty"` +} +``` + +### EnvoyGatewayMetrics + +> Prometheus will be exposed on 0.0.0.0:19001, which is not supported to be configured yet. + +``` go +// EnvoyGatewayMetrics defines control plane push/pull metrics configurations. +type EnvoyGatewayMetrics struct { + // Sinks defines the metric sinks where metrics are sent to. + Sinks []EnvoyGatewayMetricSink `json:"sinks,omitempty"` + // Prometheus defines the configuration for prometheus endpoint. + Prometheus *EnvoyGatewayPrometheusProvider `json:"prometheus,omitempty"` +} + +// EnvoyGatewayMetricSink defines control plane +// metric sinks where metrics are sent to. +type EnvoyGatewayMetricSink struct { + // Type defines the metric sink type. + // EG control plane currently supports OpenTelemetry. + // +kubebuilder:validation:Enum=OpenTelemetry + // +kubebuilder:default=OpenTelemetry + Type MetricSinkType `json:"type"` + // OpenTelemetry defines the configuration for OpenTelemetry sink. + // It's required if the sink type is OpenTelemetry. + OpenTelemetry *EnvoyGatewayOpenTelemetrySink `json:"openTelemetry,omitempty"` +} + +type EnvoyGatewayOpenTelemetrySink struct { + // Host define the sink service hostname. + Host string `json:"host"` + // Protocol define the sink service protocol. + // +kubebuilder:validation:Enum=grpc;http + Protocol string `json:"protocol"` + // Port defines the port the sink service is exposed on. + // + // +optional + // +kubebuilder:validation:Minimum=0 + // +kubebuilder:default=4317 + Port int32 `json:"port,omitempty"` +} + +// EnvoyGatewayPrometheusProvider will expose prometheus endpoint in pull mode. +type EnvoyGatewayPrometheusProvider struct { + // Disable defines if disables the prometheus metrics in pull mode. + // + Disable bool `json:"disable,omitempty"` +} + +``` + +#### Example + ++ The following is an example to disable prometheus metric. + +``` yaml +apiVersion: gateway.envoyproxy.io/v1alpha1 +kind: EnvoyGateway +gateway: + controllerName: gateway.envoyproxy.io/gatewayclass-controller +logging: + level: null + default: info +provider: + type: Kubernetes +telemetry: + metrics: + prometheus: + disable: true +``` + ++ The following is an example to send metric via Open Telemetry sink to OTEL gRPC Collector. + +``` yaml +apiVersion: gateway.envoyproxy.io/v1alpha1 +kind: EnvoyGateway +gateway: + controllerName: gateway.envoyproxy.io/gatewayclass-controller +logging: + level: null + default: info +provider: + type: Kubernetes +telemetry: + metrics: + sinks: + - type: OpenTelemetry + openTelemetry: + host: otel-collector.monitoring.svc.cluster.local + port: 4317 + protocol: grpc +``` + ++ The following is an example to disable prometheus metric and send metric via Open Telemetry sink to OTEL HTTP Collector at the same time. + +``` yaml +apiVersion: gateway.envoyproxy.io/v1alpha1 +kind: EnvoyGateway +gateway: + controllerName: gateway.envoyproxy.io/gatewayclass-controller +logging: + level: null + default: info +provider: + type: Kubernetes +telemetry: + metrics: + prometheus: + disable: false + sinks: + - type: OpenTelemetry + openTelemetry: + host: otel-collector.monitoring.svc.cluster.local + port: 4318 + protocol: http +``` + +[OpenTelemetry]: https://opentelemetry.io/ +[OpenTelemetry SDK]: https://opentelemetry.io/docs/specs/otel/metrics/sdk/ +[Semantic Conventions]: https://opentelemetry.io/docs/concepts/semantic-conventions/ +[Kubernetes specific ones]: https://opentelemetry.io/docs/specs/otel/resource/semantic_conventions/k8s/ +[OTEL gRPC metrics exporter]: https://opentelemetry.io/docs/specs/otel/metrics/sdk_exporters/otlp/#general +[OTEL HTTP metrics exporter]: https://opentelemetry.io/docs/specs/otel/metrics/sdk_exporters/otlp/#general +[Kubernetes Metrics Lifecycle]: https://kubernetes.io/docs/concepts/cluster-administration/system-metrics/#metric-lifecycle diff --git a/site/content/en/v1.0.0/contributions/design/egctl.md b/site/content/en/v1.0.0/contributions/design/egctl.md new file mode 100644 index 00000000000..4bc8876092d --- /dev/null +++ b/site/content/en/v1.0.0/contributions/design/egctl.md @@ -0,0 +1,59 @@ +--- +title: "egctl Design" +--- + +## Motivation + +EG should provide a command line tool with following capabilities: + +- Collect configuration from envoy proxy and gateway +- Analyse system configuration to diagnose any issues in envoy gateway + +This tool is named `egctl`. + +## Syntax + +Use the following syntax to run `egctl` commands from your terminal window: + +```console +egctl [command] [entity] [name] [flags] +``` + +where `command`, `name`, and `flags` are: + +* `command`: Specifies the operation that you want to perform on one or more resources, + for example `config`, `version`. + +* `entity`: Specifies the entity the operation is being performed on such as `envoy-proxy` or `envoy-gateway`. + +* `name`: Specifies the name of the specified instance. + +* `flags`: Specifies optional flags. For example, you can use the `-c` or `--config` flags to specify the values for installing. + +If you need help, run `egctl help` from the terminal window. + +## Operation + +The following table includes short descriptions and the general syntax for all the `egctl` operations: + +| Operation | Syntax | Description | +| --------------| -------------------------------- | -------------------------------------------------------------------------------------| +| `version` | `egctl version` | Prints out build version information. | +| `config` | `egctl config ENTITY` | Retrieve information about proxy configuration from envoy proxy and gateway | +| `analyze` | `egctl analyze` | Analyze EG configuration and print validation messages | +| `experimental`| `egctl experimental` | Subcommand for experimental features. These do not guarantee backwards compatibility | + +## Examples + +Use the following set of examples to help you familiarize yourself with running the commonly used `egctl` operations: + +```console +# Retrieve all information about proxy configuration from envoy +egctl config envoy-proxy all + +# Retrieve listener information about proxy configuration from envoy +egctl config envoy-proxy listener + +# Retrieve the relevant rate limit configuration from the Rate Limit instance +egctl config envoy-ratelimit +``` diff --git a/site/content/en/v1.0.0/contributions/design/envoy-patch-policy.md b/site/content/en/v1.0.0/contributions/design/envoy-patch-policy.md new file mode 100644 index 00000000000..94d9389fc61 --- /dev/null +++ b/site/content/en/v1.0.0/contributions/design/envoy-patch-policy.md @@ -0,0 +1,176 @@ +--- +title: "EnvoyPatchPolicy" +--- + +## Overview + +This design introduces the `EnvoyPatchPolicy` API allowing users to modify the generated Envoy xDS Configuration +that Envoy Gateway generates before sending it to Envoy Proxy. + +Envoy Gateway allows users to configure networking and security intent using the +upstream [Gateway API][] as well as implementation specific [Extension APIs][] defined in this project +to provide a more batteries included experience for application developers. +* These APIs are an abstracted version of the underlying Envoy xDS API to provide a better user experience for the application developer, exposing and setting only a subset of the fields for a specific feature, sometimes in a opinionated way (e.g [RateLimit][]) +* These APIs do not expose all the features capabilities that Envoy has either because these features are desired but the API +is not defined yet or the project cannot support such an extensive list of features. +To alleviate this problem, and provide an interim solution for a small section of advanced users who are well versed in +Envoy xDS API and its capabilities, this API is being introduced. + +## Goals +* Add an API allowing users to modify the generated xDS Configuration + +## Non Goals +* Support multiple patch mechanisims + +## Implementation +`EnvoyPatchPolicy` is a [Direct Policy Attachment][] type API that can be used to extend [Gateway API][] +Modifications to the generated xDS configuration can be provided as a JSON Patch which is defined in +[RFC 6902][]. This patching mechanism has been adopted in [Kubernetes][] as well as [Kustomize][] to update +resource objects. + +### Example +Here is an example highlighting how a user can configure global ratelimiting using an external rate limit service using this API. + +``` +apiVersion: gateway.networking.k8s.io/v1 +kind: GatewayClass +metadata: + name: eg +spec: + controllerName: gateway.envoyproxy.io/gatewayclass-controller +--- +apiVersion: gateway.networking.k8s.io/v1 +kind: Gateway +metadata: + name: eg + namespace: default +spec: + gatewayClassName: eg + listeners: + - name: http + protocol: HTTP + port: 80 +--- +apiVersion: gateway.networking.k8s.io/v1 +kind: HTTPRoute +metadata: + name: backend + namespace: default +spec: + parentRefs: + - name: eg + hostnames: + - "www.example.com" + rules: + - backendRefs: + - group: "" + kind: Service + name: backend + port: 3000 + weight: 1 + matches: + - path: + type: PathPrefix + value: / +--- +apiVersion: gateway.envoyproxy.io/v1alpha1 +kind: EnvoyPatchPolicy +metadata: + name: ratelimit-patch-policy + namespace: default +spec: + targetRef: + group: gateway.networking.k8s.io + kind: Gateway + name: eg + namespace: default + type: JSONPatch + jsonPatches: + - type: "type.googleapis.com/envoy.config.listener.v3.Listener" + # The listener name is of the form // + name: default/eg/http + operation: + op: add + path: "/default_filter_chain/filters/0/typed_config/http_filters/0" + value: + name: "envoy.filters.http.ratelimit" + typed_config: + "@type": "type.googleapis.com/envoy.extensions.filters.http.ratelimit.v3.RateLimit" + domain: "eag-ratelimit" + failure_mode_deny: true + timeout: 1s + rate_limit_service: + grpc_service: + envoy_grpc: + cluster_name: rate-limit-cluster + transport_api_version: V3 + - type: "type.googleapis.com/envoy.config.route.v3.RouteConfiguration" + # The route name is of the form // + name: default/eg/http + operation: + op: add + path: "/virtual_hosts/0/rate_limits" + value: + - actions: + - remote_address: {} + - type: "type.googleapis.com/envoy.config.cluster.v3.Cluster" + name: rate-limit-cluster + operation: + op: add + path: "" + value: + name: rate-limit-cluster + type: STRICT_DNS + connect_timeout: 10s + lb_policy: ROUND_ROBIN + http2_protocol_options: {} + load_assignment: + cluster_name: rate-limit-cluster + endpoints: + - lb_endpoints: + - endpoint: + address: + socket_address: + address: ratelimit.svc.cluster.local + port_value: 8081 +``` + + +## Verification +* Offline - Leverage [egctl x translate][] to ensure that the `EnvoyPatchPolicy` can be successfully applied and the desired +output xDS is created. +* Runtime - Use the `Status` field within `EnvoyPatchPolicy` to highlight whether the patch was applied successfully or not. + +## State of the World +* Istio - Supports the [EnvoyFilter][] API which allows users to customize the output xDS using patches and proto based merge +semantics. + +## Design Decisions +* This API will only support a single `targetRef` and can bind to only a `Gateway` or `GatewayClass` resource. This simplifies reasoning of how +patches will work. +* This API will always be an experimental API and cannot be graduated into a stable API because Envoy Gateway cannot garuntee + * that the naming scheme for the generated resources names will not change across releases + * that the underlying Envoy Proxy API will not change across releases +* This API needs to be explicitly enabled using the [EnvoyGateway][] API + +## Open Questions +* Should the value only support JSON or YAML as well (which is a JSON superset) ? + +## Alternatives +* Users can customize the Envoy [Bootstrap configuration using EnvoyProxy API][] and provide static xDS configuration. +* Users can extend functionality by [Extending the Control Plane][] and adding gRPC hooks to modify the generated xDS configuration. + + + +[Direct Policy Attachment]: https://gateway-api.sigs.k8s.io/references/policy-attachment/#direct-policy-attachment +[RFC 6902]: https://datatracker.ietf.org/doc/html/rfc6902 +[Gateway API]: https://gateway-api.sigs.k8s.io/ +[Kubernetes]: https://kubernetes.io/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/ +[Kustomize]: https://github.com/kubernetes-sigs/kustomize/blob/master/examples/jsonpatch.md +[Extension APIs]: ../../api/extension_types/ +[RateLimit]: ../../user/rate-limit/ +[EnvoyGateway]: ../../api/extension_types/#envoygateway +[Extending the Control Plane]: ../extending-envoy-gateway +[EnvoyFilter]: https://istio.io/latest/docs/reference/config/networking/envoy-filter +[egctl x translate]: ../../user/egctl#egctl-experimental-translate +[Bootstrap configuration using EnvoyProxy API]: ../../user/customize-envoyproxy#customize-envoyproxy-bootstrap-config diff --git a/site/content/en/v1.0.0/contributions/design/extending-envoy-gateway.md b/site/content/en/v1.0.0/contributions/design/extending-envoy-gateway.md new file mode 100644 index 00000000000..cb2127f3869 --- /dev/null +++ b/site/content/en/v1.0.0/contributions/design/extending-envoy-gateway.md @@ -0,0 +1,327 @@ +--- +title: "Envoy Gateway Extensions Design" +--- + +As outlined in the [official goals][] for the Envoy Gateway project, one of the main goals is to "provide a common foundation for vendors to build value-added products +without having to re-engineer fundamental interactions". Development of the Envoy Gateway project has been focused on developing the core features for the project and +Kubernetes Gateway API conformance. This system focuses on the “common foundation for vendors” component by introducing a way for vendors to extend Envoy Gateway. + +To meaningfully extend Envoy Gateway and provide additional features, Extensions need to be able to introduce their own custom resources and have a high level of control +over the configuration generated by Envoy Gateway. Simply applying some static xDS configuration patches or relying on the existing Gateway API resources are both insufficient on their own +as means to add larger features that require dynamic user-configuration. + +As an example, an extension developer may wish to provide their own out-of-the-box authentication filters that require configuration from the end-user. This is a scenario where the ability to introduce +custom resources and attach them to [HTTPRoute][]s as an [ExtensionRef][] is necessary. Providing the same feature through a series of xDS patch resources would be too cumbersome for many end-users that want to avoid +that level of complexity when managing their clusters. + +## Goals + +- Provide a foundation for extending the Envoy Gateway control plane +- Allow Extension Developers to introduce their own custom resources for extending the Gateway-API via [ExtensionRefs][], [policyAttachments][] (future) and [backendRefs][] (future). +- Extension developers should **NOT** have to maintain a custom fork of Envoy Gateway +- Provide a system for extending Envoy Gateway which allows extension projects to ship updates independent of Envoy Gateway's release schedule +- Modify the generated Envoy xDS config +- Setup a foundation for the initial iteration of Extending Envoy Gateway +- Allow an Extension to hook into the infra manager pipeline (future) + +## Non-Goals + +- The initial design does not capture every hook that Envoy Gateway will eventually support. +- Extend [Gateway API Policy Attachments][]. At some point, these will be addressed using this extension system, but the initial implementation omits these. +- Support multiple extensions at the same time. Due to the fact that extensions will be modifying xDS resources after they are generated, handling the order of extension execution for each individual hook point is a challenge. Additionally, there is no +real way to prevent one extension from overwriting or breaking modifications to xDS resources that were made by another extension that was executed first. + +## Overview + +Envoy Gateway can be extended by vendors by means of an extension server developed by the vendor and deployed alongside Envoy Gateway. +An extension server can make use of one or more pre/post hooks inside Envoy Gateway before and after its major components (translator, etc.) to allow the extension to modify the data going into or coming out of these components. +An extension can be created external to Envoy Gateway as its own Kubernetes deployment or loaded as a sidecar. gRPC is used for the calls between Envoy Gateway and an extension. In the hook call, Envoy Gateway sends data as well +as context information to the extension and expects a reply with a modified version of the data that was sent to the extension. Since extensions fundamentally alter the logic and data that Envoy Gateway provides, Extension projects assume responsibility for any bugs and issues +they create as a direct result of their modification of Envoy Gateway. + +## Diagram + +![Architecture](/img/extension-example.png) + +## Registering Extensions in Envoy Gateway + +Information about the extension that Envoy Gateway needs to load is configured in the Envoy Gateway config. + +An example configuration: + +```yaml +apiVersion: gateway.envoyproxy.io/v1alpha1 +kind: EnvoyGateway +extensionManager: + resources: + - group: example.myextension.io + version: v2 + kind: OAuth2Filter + hooks: + xdsTranslator: + post: + - Route + - VirtualHost + - HTTPListener + - Translation + service: + host: my-extension.example + port: 443 + tls: + certificateRef: + name: my-secret + namespace: default +``` + +An extension must supply connection information in the `extension.service` field so that Envoy Gateway can communicate with the extension. The `tls` configuration is optional. + +If the extension wants Envoy Gateway to watch resources for it then the extension must configure the optional `extension.resources` field and supply a list of: + +- `group`: the API group of the resource +- `version`: the API version of the resource +- `kind`: the Kind of resource + +The extension can configure the `extensionManager.hooks` field to specify which hook points it would like to support. If a given hook is not listed here then it will not be executed even +if the extension is configured properly. This allows extension developers to only opt-in to the hook points they want to make use of. + +This configuration is required to be provided at bootstrap and modifying the registered extension during runtime is not currently supported. +Envoy Gateway will keep track of the registered extension and its API `groups` and `kinds` when processing Gateway API resources. + +## Extending Gateway API and the Data Plane + +Envoy Gateway manages [Envoy][] deployments, which act as the data plane that handles actual user traffic. Users configure the data plane using the K8s Gateway API resources which Envoy +Gateway converts into [Envoy specific configuration (xDS)][] to send over to Envoy. + +Gateway API offers [ExtensionRef filters][] and [Policy Attachments][] as extension points for implementers to use. Envoy Gateway extends the Gateway API using these extension points to provide support for [rate limiting][] +and [authentication][] native to the project. The initial design of Envoy Gateway extensions will primarily focus on ExtensionRef filters so that extension developers can reference their own resources as HTTP Filters in the same way +that Envoy Gateway has native support for rate limiting and authentication filters. + +When Envoy Gateway encounters an [HTTPRoute][] or [GRPCRoute][] that has an `ExtensionRef` `filter` with a `group` and `kind` that Envoy Gateway does not support, it will first +check the registered extension to determine if it supports the referenced object before considering it a configuration error. + +This allows users to be able to reference additional filters provided by their Envoy Gateway Extension, in their `HTTPRoute`s / `GRPCRoute`s: + +```yaml +apiVersion: example.myextension.io/v1alpha1 +kind: OAuth2Filter +metadata: + name: oauth2-filter +spec: + ... + +--- +apiVersion: gateway.networking.k8s.io/v1 +kind: HTTPRoute +metadata: + name: example +spec: + parentRefs: + - name: eg + hostnames: + - www.example.com + rules: + - clientSelectors: + - path: + type: PathPrefix + value: / + filters: + - type: ExtensionRef + extensionRef: + group: example.myextension.io + kind: OAuth2Filter + name: oauth2-filter + backendRefs: + - name: backend + port: 3000 +``` + +In order to enable the usage of new resources introduced by an extension for translation and xDS modification, Envoy Gateway provides hook points within the translation pipeline, where it calls out to the extension service registered in the [EnvoyGateway config][] +if they specify an `group` that matches the `group` of an `ExtensionRef` filter. The extension will then be able to modify the xDS that Envoy Gateway generated and send back the +modified configuration. If an extension is not registered or if the registered extension does not specify support for the `group` of an `ExtensionRef` filter then Envoy Gateway will treat it as an unknown resource +and provide an error to the user. + +**Note:** Currently (as of [v1][]) Gateway API does not provide a means to specify the namespace or version of an object referenced as an `ExtensionRef`. The extension mechanism will assume that +the namespace of any `ExtensionRef` is the same as the namespace of the `HTTPRoute` or `GRPCRoute` it is attached to rather than treating the `name` field of an `ExtensionRef` as a `name.namespace` string. +If Gateway API adds support for these fields then the design of the Envoy Gateway extensions will be updated to support them. + +## Watching New Resources + +Envoy Gateway will dynamically create new watches on resources introduced by the registered Extension. It does so by using the [controller-runtime][] to create new watches on [Unstructured][] resources that match the `version`s, `group`s, and `kind`s that the +registered extension configured. When communicating with an extension, Envoy Gateway sends these Unstructured resources over to the extension. This eliminates the need for the extension to create its own watches which would have a strong chance of creating race conditions and reconciliation loops when resources change. When an extension receives the Unstructured resources from Envoy Gateway it can perform its own type validation on them. Currently we make the simplifying assumption that the registered extension's `Kinds` are filters referenced by `extensionRef` in `HTTPRouteFilter`s . Support for Policy attachments will be introduced at a later time. + +## xDS Hooks API + +Envoy Gateway supports the following hooks as the initial foundation of the Extension system. Additional hooks can be developed using this extension system at a later point as new use-cases and needs are discovered. The primary iteration of the extension hooks +focuses solely on the modification of xDS resources. + +### Route Modification Hook + +The [Route][] level Hook provides a way for extensions to modify a route generated by Envoy Gateway before it is finalized. +Doing so allows extensions to configure/modify route fields configured by Envoy Gateway and also to configure the +Route's TypedPerFilterConfig which may be desirable to do things such as pass settings and information to ext_authz filters. +The Post Route Modify hook also passes a list of Unstructured data for the externalRefs owned by the extension on the HTTPRoute that created this xDS route +This hook is always executed when an extension is loaded that has added `Route` to the `EnvoyProxy.extensionManager.hooks.xdsTranslator.post`, and only on Routes which were generated from an HTTPRoute that uses extension resources as externalRef filters. + +```go +// PostRouteModifyRequest sends a Route that was generated by Envoy Gateway along with context information to an extension so that the Route can be modified +message PostRouteModifyRequest { + envoy.config.route.v3.Route route = 1; + PostRouteExtensionContext post_route_context = 2; +} + +// RouteExtensionContext provides resources introduced by an extension and watched by Envoy Gateway +// additional context information can be added to this message as more use-cases are discovered +message PostRouteExtensionContext { + // Resources introduced by the extension that were used as extensionRefs in an HTTPRoute/GRPCRoute + repeated ExtensionResource extension_resources = 1; + + // hostnames are the fully qualified domain names attached to the HTTPRoute + repeated string hostnames = 2; +} + +// ExtensionResource stores the data for a K8s API object referenced in an HTTPRouteFilter +// extensionRef. It is constructed from an unstructured.Unstructured marshalled to JSON. An extension +// can marshal the bytes from this resource back into an unstructured.Unstructured and then +// perform type checking to obtain the resource. +message ExtensionResource { + bytes unstructured_bytes = 1; +} + +// PostRouteModifyResponse is the expected response from an extension and contains a modified version of the Route that was sent +// If an extension returns a nil Route then it will not be modified +message PostRouteModifyResponse { + envoy.config.route.v3.Route route = 1; +} +``` + +### VirtualHost Modification Hook + +The [VirtualHost][] Hook provides a way for extensions to modify a VirtualHost generated by Envoy Gateway before it is finalized. +An extension can also make use of this hook to generate and insert entirely new Routes not generated by Envoy Gateway. +This hook is always executed when an extension is loaded that has added `VirtualHost` to the `EnvoyProxy.extensionManager.hooks.xdsTranslator.post`. +An extension may return nil to not make any changes to the VirtualHost. + +```protobuf +// PostVirtualHostModifyRequest sends a VirtualHost that was generated by Envoy Gateway along with context information to an extension so that the VirtualHost can be modified +message PostVirtualHostModifyRequest { + envoy.config.route.v3.VirtualHost virtual_host = 1; + PostVirtualHostExtensionContext post_virtual_host_context = 2; +} + +// Empty for now but we can add fields to the context as use-cases are discovered without +// breaking any clients that use the API +// additional context information can be added to this message as more use-cases are discovered +message PostVirtualHostExtensionContext {} + +// PostVirtualHostModifyResponse is the expected response from an extension and contains a modified version of the VirtualHost that was sent +// If an extension returns a nil Virtual Host then it will not be modified +message PostVirtualHostModifyResponse { + envoy.config.route.v3.VirtualHost virtual_host = 1; +} +``` + +### HTTP Listener Modification Hook + +The HTTP [Listener][] modification hook is the broadest xDS modification Hook available and allows an extension to make changes to a Listener generated by Envoy Gateway before it is finalized. +This hook is always executed when an extension is loaded that has added `HTTPListener` to the `EnvoyProxy.extensionManager.hooks.xdsTranslator.post`. An extension may return nil +in order to not make any changes to the Listener. + +```protobuf +// PostVirtualHostModifyRequest sends a Listener that was generated by Envoy Gateway along with context information to an extension so that the Listener can be modified +message PostHTTPListenerModifyRequest { + envoy.config.listener.v3.Listener listener = 1; + PostHTTPListenerExtensionContext post_listener_context = 2; +} + +// Empty for now but we can add fields to the context as use-cases are discovered without +// breaking any clients that use the API +// additional context information can be added to this message as more use-cases are discovered +message PostHTTPListenerExtensionContext {} + +// PostHTTPListenerModifyResponse is the expected response from an extension and contains a modified version of the Listener that was sent +// If an extension returns a nil Listener then it will not be modified +message PostHTTPListenerModifyResponse { + envoy.config.listener.v3.Listener listener = 1; +} +``` + +### Post xDS Translation Modify Hook + +The Post Translate Modify hook allows an extension to modify the clusters and secrets in the xDS config. +This allows for inserting clusters that may change along with extension specific configuration to be dynamically created rather than +using custom bootstrap config which would be sufficient for clusters that are static and not prone to have their configurations changed. +An example of how this may be used is to inject a cluster that will be used by an ext_authz http filter created by the extension. +The list of clusters and secrets returned by the extension are used as the final list of all clusters and secrets +This hook is always executed when an extension is loaded that has added `Translation` to the `EnvoyProxy.extensionManager.hooks.xdsTranslator.post`. + +```protobuf +// PostTranslateModifyRequest currently sends only clusters and secrets to an extension. +// The extension is free to add/modify/remove the resources it received. +message PostTranslateModifyRequest { + PostTranslateExtensionContext post_translate_context = 1; + repeated envoy.config.cluster.v3.Cluster clusters = 2; + repeated envoy.extensions.transport_sockets.tls.v3.Secret secrets = 3; +} + +// PostTranslateModifyResponse is the expected response from an extension and contains +// the full list of xDS clusters and secrets to be used for the xDS config. +message PostTranslateModifyResponse { + repeated envoy.config.cluster.v3.Cluster clusters = 1; + repeated envoy.extensions.transport_sockets.tls.v3.Secret secrets = 2; +} +``` + +### Extension Service + +Currently, an extension must implement all of the following hooks although it may return the input(s) it received +if no modification of the resource is desired. A future expansion of the extension hooks will allow an Extension to specify +with config which Hooks it would like to "subscribe" to and which Hooks it does not wish to support. These specific Hooks were chosen +in order to provide extensions with the ability to have both broad and specific control over xDS resources and to minimize the amount of data being sent. + +```protobuf +service EnvoyGatewayExtension { + rpc PostRouteModify (PostRouteModifyRequest) returns (PostRouteModifyResponse) {}; + rpc PostVirtualHostModify(PostVirtualHostModifyRequest) returns (PostVirtualHostModifyResponse) {}; + rpc PostHTTPListenerModify(PostHTTPListenerModifyRequest) returns (PostHTTPListenerModifyResponse) {}; + rpc PostTranslateModify(PostTranslateModifyRequest) returns (PostTranslateModifyResponse) {}; +} +``` + +## Design Decisions + +- Envoy Gateway watches new custom resources introduced by a loaded extension and passes the resources back to the extension when they are used. + - This decision was made to solve the problem about how resources introduced by an extension get watched. If an extension server watches its own resources then it would need some way to trigger an Envoy Gateway reconfigure when a resource that Envoy Gateway is not watching gets updated. Having Envoy Gateway watch all resources removes any concern about creating race confitions or reconcile loops that would result from Envoy Gateway and the extension server both having so much separate state that needs to be synchronized. +- The Extension Server takes ownership of producing the correct xDS configuration in the hook responses +- The Extension Server will be responsible for ensuring the performance of the hook processing time +- The Post xDS level gRPC hooks all currently send a context field even though it contains nothing for several hooks. These fields exist so that they can be updadated in the future to pass +additional information to extensions as new use-cases and needs are discovered. +- The initial design supplies the scaffolding for both "pre xDS" and "post xDS" hooks. Only the post hooks are currently implemented which operate on xDS resources after they have been generated. +The pre hooks will be implemented at a later date along with one or more hooks in the infra manager. The infra manager level hook(s) will exist to power use-cases such as dynamically creating Deployments/Services for the extension the +whenever Envoy Gateway creates an instance of Envoy Proxy. An extension developer might want to take advantage of this functionality to inject a new authorization service as a sidecar on the Envoy Proxy deployment for reduced latency. +- Multiple extensions are not be supported at the same time. Preventing conflict between multiple extensions that are mangling xDS resources is too difficult to ensure compatibility with and is likely to only generate issues. + +## Known Challenges + +Extending Envoy Gateway by using an external extension server which makes use of hook points in Envoy Gateway does comes with a few trade-offs. One known trade-off is the impact of the time that it takes for the hook calls to be executed. Since an extension would make use of hook points in Envoy Gateway that use gRPC for communication, the time it takes to perform these requests could become a concern for some extension developers. One way to minimize the request time of the hook calls is to load the extension server as a sidecar to Envoy Gateway to minimize the impact of networking on the hook calls. + +[official goals]: https://github.com/envoyproxy/gateway/blob/main/GOALS.md#extensibility +[ExtensionRef filters]: https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1.LocalObjectReference +[ExtensionRef]: https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1.LocalObjectReference +[ExtensionRefs]: https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1.LocalObjectReference +[backendRefs]: https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1.BackendObjectReference +[Gateway API Policy attachments]: https://gateway-api.sigs.k8s.io/references/policy-attachment/?h=policy +[Policy Attachments]: https://gateway-api.sigs.k8s.io/references/policy-attachment/?h=policy +[policyAttachments]: https://gateway-api.sigs.k8s.io/references/policy-attachment/?h=policy +[Envoy]: https://www.envoyproxy.io/ +[Envoy specific configuration (xDS)]: https://www.envoyproxy.io/docs/envoy/v1.25.1/configuration/configuration +[v1]: https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1 +[rate limiting]: ../../user/rate-limit/ +[authentication]: ../../user/jwt-authentication/ +[HTTPRoute]: https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1.HTTPRoute +[GRPCRoute]: https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1alpha2.GRPCRoute +[EnvoyGateway config]: ../../api/extension_types/#envoygateway +[controller-runtime]: https://github.com/kubernetes-sigs/controller-runtime +[Unstructured]: https://pkg.go.dev/k8s.io/apimachinery/pkg/apis/meta/v1/unstructured +[Listener]: https://www.envoyproxy.io/docs/envoy/v1.23.0/api-v3/config/listener/v3/listener.proto#config-listener-v3-listener +[VirtualHost]: https://www.envoyproxy.io/docs/envoy/v1.23.0/api-v3/config/route/v3/route_components.proto#config-route-v3-virtualhost +[Route]: https://www.envoyproxy.io/docs/envoy/v1.23.0/api-v3/config/route/v3/route_components.proto#config-route-v3-route diff --git a/site/content/en/v1.0.0/contributions/design/gatewayapi-translator.md b/site/content/en/v1.0.0/contributions/design/gatewayapi-translator.md new file mode 100644 index 00000000000..a086b80bfee --- /dev/null +++ b/site/content/en/v1.0.0/contributions/design/gatewayapi-translator.md @@ -0,0 +1,253 @@ +--- +title: "Gateway API Translator Design" +weight: 4 +--- + +The Gateway API translates external resources, e.g. GatewayClass, from the configured Provider to the Intermediate +Representation (IR). + +## Assumptions + +Initially target core conformance features only, to be followed by extended conformance features. + +## Inputs and Outputs + +The main inputs to the Gateway API translator are: + +- GatewayClass, Gateway, HTTPRoute, TLSRoute, Service, ReferenceGrant, Namespace, and Secret resources. + +__Note:__ ReferenceGrant is not fully implemented as of v0.2. + +The outputs of the Gateway API translator are: + +- Xds and Infra Internal Representations (IRs). +- Status updates for GatewayClass, Gateways, HTTPRoutes + +## Listener Compatibility + +Envoy Gateway follows Gateway API listener compatibility spec: +> Each listener in a Gateway must have a unique combination of Hostname, Port, and Protocol. An implementation MAY group +> Listeners by Port and then collapse each group of Listeners into a single Listener if the implementation determines +> that the Listeners in the group are “compatible”. + +__Note:__ Envoy Gateway does not collapse listeners across multiple Gateways. + +### Listener Compatibility Examples + +#### Example 1: Gateway with compatible Listeners (same port & protocol, different hostnames) + +```yaml +kind: Gateway +apiVersion: gateway.networking.k8s.io/v1 +metadata: + name: gateway-1 + namespace: envoy-gateway +spec: + gatewayClassName: envoy-gateway + listeners: + - name: http + protocol: HTTP + port: 80 + allowedRoutes: + namespaces: + from: All + hostname: "*.envoygateway.io" + - name: http + protocol: HTTP + port: 80 + allowedRoutes: + namespaces: + from: All + hostname: whales.envoygateway.io +``` + +#### Example 2: Gateway with compatible Listeners (same port & protocol, one hostname specified, one not) + +```yaml +kind: Gateway +apiVersion: gateway.networking.k8s.io/v1 +metadata: + name: gateway-1 + namespace: envoy-gateway +spec: + gatewayClassName: envoy-gateway + listeners: + - name: http + protocol: HTTP + port: 80 + allowedRoutes: + namespaces: + from: All + hostname: "*.envoygateway.io" + - name: http + protocol: HTTP + port: 80 + allowedRoutes: + namespaces: + from: All +``` + +#### Example 3: Gateway with incompatible Listeners (same port, protocol and hostname) + +```yaml +kind: Gateway +apiVersion: gateway.networking.k8s.io/v1 +metadata: + name: gateway-1 + namespace: envoy-gateway +spec: + gatewayClassName: envoy-gateway + listeners: + - name: http + protocol: HTTP + port: 80 + allowedRoutes: + namespaces: + from: All + hostname: whales.envoygateway.io + - name: http + protocol: HTTP + port: 80 + allowedRoutes: + namespaces: + from: All + hostname: whales.envoygateway.io +``` + +#### Example 4: Gateway with incompatible Listeners (neither specify a hostname) + +```yaml +kind: Gateway +apiVersion: gateway.networking.k8s.io/v1 +metadata: + name: gateway-1 + namespace: envoy-gateway +spec: + gatewayClassName: envoy-gateway + listeners: + - name: http + protocol: HTTP + port: 80 + allowedRoutes: + namespaces: + from: All + - name: http + protocol: HTTP + port: 80 + allowedRoutes: + namespaces: + from: All +``` + +## Computing Status + +Gateway API specifies a rich set of status fields & conditions for each resource. To achieve conformance, Envoy Gateway +must compute the appropriate status fields and conditions for managed resources. + +Status is computed and set for: + +- The managed GatewayClass (`gatewayclass.status.conditions`). +- Each managed Gateway, based on its Listeners' status (`gateway.status.conditions`). For the Kubernetes provider, the + Envoy Deployment and Service status are also included to calculate Gateway status. +- Listeners for each Gateway (`gateway.status.listeners`). +- The ParentRef for each Route (`route.status.parents`). + +The Gateway API translator is responsible for calculating status conditions while translating Gateway API resources to +the IR and publishing status over the [message bus][]. The Status Manager subscribes to these status messages and +updates the resource status using the configured provider. For example, the Status Manager uses a Kubernetes client to +update resource status on the Kubernetes API server. + +## Outline + +The following roughly outlines the translation process. Each step may produce (1) IR; and (2) status updates on Gateway +API resources. + +1. Process Gateway Listeners + - Validate unique hostnames, ports, and protocols. + - Validate and compute supported kinds. + - Validate allowed namespaces (validate selector if specified). + - Validate TLS fields if specified, including resolving referenced Secrets. + +2. Process HTTPRoutes + - foreach route rule: + - compute matches + - [core] path exact, path prefix + - [core] header exact + - [extended] query param exact + - [extended] HTTP method + - compute filters + - [core] request header modifier (set/add/remove) + - [core] request redirect (hostname, statuscode) + - [extended] request mirror + - compute backends + - [core] Kubernetes services + - foreach route parent ref: + - get matching listeners (check Gateway, section name, listener validation status, listener allowed routes, hostname intersection) + - foreach matching listener: + - foreach hostname intersection with route: + - add each computed route rule to host + +## Context Structs + +To help store, access and manipulate information as it's processed during the translation process, a set of context +structs are used. These structs wrap a given Gateway API type, and add additional fields and methods to support +processing. + +`GatewayContext` wraps a Gateway and provides helper methods for setting conditions, accessing Listeners, etc. + +```go +type GatewayContext struct { + // The managed Gateway + *v1beta1.Gateway + + // A list of Gateway ListenerContexts. + listeners []*ListenerContext +} +``` + +`ListenerContext` wraps a Listener and provides helper methods for setting conditions and other status information on +the associated Gateway. + +```go +type ListenerContext struct { + // The Gateway listener. + *v1beta1.Listener + + // The Gateway this Listener belongs to. + gateway *v1beta1.Gateway + + // An index used for managing this listener in the list of Gateway listeners. + listenerStatusIdx int + + // Only Routes in namespaces selected by the selector may be attached + // to the Gateway this listener belongs to. + namespaceSelector labels.Selector + + // The TLS Secret for this Listener, if applicable. + tlsSecret *v1.Secret +} +``` + +`RouteContext` represents a generic Route object (HTTPRoute, TLSRoute, etc.) that can reference Gateway objects. + +```go +type RouteContext interface { + client.Object + + // GetRouteType returns the Kind of the Route object, HTTPRoute, + // TLSRoute, TCPRoute, UDPRoute etc. + GetRouteType() string + + // GetHostnames returns the hosts targeted by the Route object. + GetHostnames() []string + + // GetParentReferences returns the ParentReference of the Route object. + GetParentReferences() []v1beta1.ParentReference + + // GetRouteParentContext returns RouteParentContext by using the Route + // objects' ParentReference. + GetRouteParentContext(forParentRef v1beta1.ParentReference) *RouteParentContext +} +``` + +[message bus]: ../watching/ diff --git a/site/content/en/v1.0.0/contributions/design/goals.md b/site/content/en/v1.0.0/contributions/design/goals.md new file mode 100644 index 00000000000..fd38b2004c6 --- /dev/null +++ b/site/content/en/v1.0.0/contributions/design/goals.md @@ -0,0 +1,91 @@ +--- +title: "Goals" +weight: 1 +--- + +The high-level goal of the Envoy Gateway project is to attract more users to Envoy by lowering barriers to adoption +through expressive, extensible, role-oriented APIs that support a multitude of ingress and L7/L4 traffic routing +use cases; and provide a common foundation for vendors to build value-added products without having to re-engineer +fundamental interactions. + +## Objectives + +### Expressive API + +The Envoy Gateway project will expose a simple and expressive API, with defaults set for many capabilities. + +The API will be the Kubernetes-native [Gateway API][], plus Envoy-specific extensions and extension points. This +expressive and familiar API will make Envoy accessible to more users, especially application developers, and make Envoy +a stronger option for "getting started" as compared to other proxies. Application developers will use the API out of +the box without needing to understand in-depth concepts of Envoy Proxy or use OSS wrappers. The API will use familiar +nouns that [users](#personas) understand. + +The core full-featured Envoy xDS APIs will remain available for those who need more capability and for those who +add functionality on top of Envoy Gateway, such as commercial API gateway products. + +This expressive API will not be implemented by Envoy Proxy, but rather an officially supported translation layer +on top. + +### Batteries included + +Envoy Gateway will simplify how Envoy is deployed and managed, allowing application developers to focus on +delivering core business value. + +The project plans to include additional infrastructure components required by users to fulfill their Ingress and API +gateway needs: It will handle Envoy infrastructure provisioning (e.g. Kubernetes Service, Deployment, et cetera), and +possibly infrastructure provisioning of related sidecar services. It will include sensible defaults with the ability to +override. It will include channels for improving ops by exposing status through API conditions and Kubernetes status +sub-resources. + +Making an application accessible needs to be a trivial task for any developer. Similarly, infrastructure administrators +will enjoy a simplified management model that doesn't require extensive knowledge of the solution's architecture to +operate. + +### All environments + +Envoy Gateway will support running natively in Kubernetes environments as well as non-Kubernetes deployments. + +Initially, Kubernetes will receive the most focus, with the aim of having Envoy Gateway become the de facto +standard for Kubernetes ingress supporting the [Gateway API][]. +Additional goals include multi-cluster support and various runtime environments. + +### Extensibility + +Vendors will have the ability to provide value-added products built on the Envoy Gateway foundation. + +It will remain easy for end-users to leverage common Envoy Proxy extension points such as providing an implementation +for authentication methods and rate-limiting. For advanced use cases, users will have the ability to use the full power +of xDS. + +Since a general-purpose API cannot address all use cases, Envoy Gateway will provide additional extension points +for flexibility. As such, Envoy Gateway will form the base of vendor-provided managed control plane solutions, +allowing vendors to shift to a higher management plane layer. + +## Non-objectives + +### Cannibalize vendor models + +Vendors need to have the ability to drive commercial value, so the goal is not to cannibalize any existing vendor +monetization model, though some vendors may be affected by it. + +### Disrupt current Envoy usage patterns + +Envoy Gateway is purely an additive convenience layer and is not meant to disrupt any usage pattern of any user +with Envoy Proxy, xDS, or go-control-plane. + +## Personas + +_In order of priority_ + +### 1. Application developer + +The application developer spends the majority of their time developing business logic code. They require the ability to +manage access to their application. + +### 2. Infrastructure administrators + +The infrastructure administrators are responsible for the installation, maintenance, and operation of +API gateways appliances in infrastructure, such as CRDs, roles, service accounts, certificates, etc. +Infrastructure administrators support the needs of application developers by managing instances of Envoy Gateway. + +[Gateway API]: https://gateway-api.sigs.k8s.io/ diff --git a/site/content/en/v1.0.0/contributions/design/local-envoy-gateway.md b/site/content/en/v1.0.0/contributions/design/local-envoy-gateway.md new file mode 100644 index 00000000000..aad0dc5f6f2 --- /dev/null +++ b/site/content/en/v1.0.0/contributions/design/local-envoy-gateway.md @@ -0,0 +1,52 @@ +--- +title: "Running Envoy Gateway locally" +--- + +## Overview + +Today, Envoy Gateway runs only on Kubernetes. This is an ideal solution +when the applications are running in Kubernetes. +However there might be cases when the applications are running on the host which would +require Envoy Gateway to run locally. + +## Goals + +* Define an API to allow Envoy Gateway to retrieve configuration while running locally. +* Define an API to allow Envoy Gateway to deploy the managed Envoy Proxy fleet on the host +machine. + +## Non Goals + +* Support multiple ways to retrieve configuration while running locally. +* Support multiple ways to deploy the Envoy Proxy fleet locally on the host. + +## API + +* The `provider` field within the `EnvoyGateway` configuration only supports +`Kubernetes` today which provides two features - the ability to retrieve +resources from the Kubernetes API Server as well as deploy the managed +Envoy Proxy fleet on Kubernetes. +* This document proposes adding a new top level `provider` type called `Custom` +with two fields called `resource` and `infrastructure` to allow the user to configure +the sub providers for providing resource configuration and an infrastructure to deploy +the Envoy Proxy data plane in. +* A `File` resource provider will be introduced to enable retrieveing configuration locally +by reading from the configuration from a file. +* A `Host` infrastructure provider will be introduced to allow Envoy Gateway to spawn a +Envoy Proxy child process on the host. + +Here is an example configuration + +``` +provider: + type: Custom + custom: + resource: + type: File + file: + paths: + - "config.yaml" + infrastructure: + type: Host + host: {} +``` diff --git a/site/content/en/v1.0.0/contributions/design/metrics.md b/site/content/en/v1.0.0/contributions/design/metrics.md new file mode 100644 index 00000000000..78b05eea98e --- /dev/null +++ b/site/content/en/v1.0.0/contributions/design/metrics.md @@ -0,0 +1,117 @@ +--- +title: "Observability: Metrics" +--- + +## Overview + +Envoy provide robust platform for metrics, Envoy support three different kinds of stats: counter, gauges, histograms. + +Envoy enables prometheus format output via the `/stats/prometheus` [admin endpoint][]. + +Envoy support different kinds of sinks, but EG will only support [Open Telemetry sink][]. + +Envoy Gateway leverages [Gateway API][] for configuring managed Envoy proxies. Gateway API defines core, extended, and implementation-specific API [support levels][] for implementers such as Envoy Gateway to expose features. Since metrics is not covered by `Core` or `Extended` APIs, EG should provide an easy to config metrics per `EnvoyProxy`. + +## Goals + +- Support expose metrics in prometheus way(reuse probe port). +- Support Open Telemetry stats sink. + +## Non-Goals + +- Support other stats sink. + +## Use-Cases + +- Enable prometheus metric by default +- Disable prometheus metric +- Push metrics via Open Telemetry Sink +- TODO: Customize histogram buckets of target metric +- TODO: Support stats matcher + +### ProxyMetric API Type + +```golang mdox-exec="sed '1,7d' api/v1alpha1/metric_types.go" +type ProxyMetrics struct { + // Prometheus defines the configuration for Admin endpoint `/stats/prometheus`. + Prometheus *PrometheusProvider `json:"prometheus,omitempty"` + // Sinks defines the metric sinks where metrics are sent to. + Sinks []MetricSink `json:"sinks,omitempty"` +} + +type MetricSinkType string + +const ( + MetricSinkTypeOpenTelemetry MetricSinkType = "OpenTelemetry" +) + +type MetricSink struct { + // Type defines the metric sink type. + // EG currently only supports OpenTelemetry. + // +kubebuilder:validation:Enum=OpenTelemetry + // +kubebuilder:default=OpenTelemetry + Type MetricSinkType `json:"type"` + // OpenTelemetry defines the configuration for OpenTelemetry sink. + // It's required if the sink type is OpenTelemetry. + OpenTelemetry *OpenTelemetrySink `json:"openTelemetry,omitempty"` +} + +type OpenTelemetrySink struct { + // Host define the service hostname. + Host string `json:"host"` + // Port defines the port the service is exposed on. + // + // +optional + // +kubebuilder:validation:Minimum=0 + // +kubebuilder:validation:Maximum=65535 + // +kubebuilder:default=4317 + Port int32 `json:"port,omitempty"` + + // TODO: add support for customizing OpenTelemetry sink in https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/stat_sinks/open_telemetry/v3/open_telemetry.proto#envoy-v3-api-msg-extensions-stat-sinks-open-telemetry-v3-sinkconfig +} + +type PrometheusProvider struct { + // Disable the Prometheus endpoint. + Disable bool `json:"disable,omitempty"` +} +``` + +### Example + +- The following is an example to disable prometheus metric. + +```yaml mdox-exec="sed '1,12d' examples/kubernetes/metric/disable-prometheus.yaml" +apiVersion: gateway.envoyproxy.io/v1alpha1 +kind: EnvoyProxy +metadata: + name: prometheus + namespace: envoy-gateway-system +spec: + telemetry: + metrics: + prometheus: + disable: true +``` + +- The following is an example to send metric via Open Telemetry sink. + +```yaml mdox-exec="sed '1,12d' examples/kubernetes/metric/otel-sink.yaml" +apiVersion: gateway.envoyproxy.io/v1alpha1 +kind: EnvoyProxy +metadata: + name: otel-sink + namespace: envoy-gateway-system +spec: + telemetry: + metrics: + sinks: + - type: OpenTelemetry + openTelemetry: + host: otel-collector.monitoring.svc.cluster.local + port: 4317 +``` + +[admin endpoint]: https://www.envoyproxy.io/docs/envoy/latest/operations/admin +[Open Telemetry sink]: https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/stat_sinks/open_telemetry/v3/open_telemetry.proto +[Gateway API]: https://gateway-api.sigs.k8s.io/ +[support levels]: https://gateway-api.sigs.k8s.io/concepts/conformance/?h=extended#2-support-levels diff --git a/site/content/en/v1.0.0/contributions/design/pprof.md b/site/content/en/v1.0.0/contributions/design/pprof.md new file mode 100644 index 00000000000..40d75ea8f83 --- /dev/null +++ b/site/content/en/v1.0.0/contributions/design/pprof.md @@ -0,0 +1,70 @@ +--- +title: "Debug support in Envoy Gateway" +--- + +## Overview + +Envoy Gateway exposes endpoints at `localhost:19000/debug/pprof` to run Golang profiles to aid in live debugging. + +The endpoints are equivalent to those found in the http/pprof package. `/debug/pprof/` returns an HTML page listing the available profiles. + +## Goals + +* Add admin server to Envoy Gateway control plane, separated with admin server. +* Add pprof support to Envoy Gateway control plane. +* Define an API to allow Envoy Gateway to custom admin server configuration. +* Define an API to allow Envoy Gateway to open envoy gateway config dump in logs. + +The following are the different types of profiles end-user can run: + +PROFILE | FUNCTION +-- | -- +/debug/pprof/allocs | Returns a sampling of all past memory allocations. +/debug/pprof/block | Returns stack traces of goroutines that led to blocking on synchronization primitives. +/debug/pprof/cmdline | Returns the command line that was invoked by the current program. +/debug/pprof/goroutine | Returns stack traces of all current goroutines. +/debug/pprof/heap | Returns a sampling of memory allocations of live objects. +/debug/pprof/mutex | Returns stack traces of goroutines holding contended mutexes. +/debug/pprof/profile | Returns pprof-formatted cpu profile. You can specify the duration using the seconds GET parameter. The default duration is 30 seconds. +/debug/pprof/symbol | Returns the program counters listed in the request. +/debug/pprof/threadcreate | Returns stack traces that led to creation of new OS threads. +/debug/pprof/trace | Returns the execution trace in binary form. You can specify the duration using the seconds GET parameter. The default duration is 1 second. + +## Non Goals + +## API + +* Add `admin` field in EnvoyGateway config. +* Add `address` field under `admin` field. +* Add `port` and `host` under `address` field. +* Add `enableDumpConfig` field under `admin field. +* Add `enablePprof` field under `admin field. + +Here is an example configuration to open admin server and enable Pprof: + +```yaml +apiVersion: gateway.envoyproxy.io/v1alpha1 +gateway: + controllerName: "gateway.envoyproxy.io/gatewayclass-controller" +kind: EnvoyGateway +provider: + type: "Kubernetes" +admin: + enablePprof: true + address: + host: 127.0.0.1 + port: 19000 +``` + +Here is an example configuration to open envoy gateway config dump in logs: + +```yaml +apiVersion: gateway.envoyproxy.io/v1alpha1 +gateway: + controllerName: "gateway.envoyproxy.io/gatewayclass-controller" +kind: EnvoyGateway +provider: + type: "Kubernetes" +admin: + enableDumpConfig: true +``` diff --git a/site/content/en/v1.0.0/contributions/design/rate-limit.md b/site/content/en/v1.0.0/contributions/design/rate-limit.md new file mode 100644 index 00000000000..8dfda7680e8 --- /dev/null +++ b/site/content/en/v1.0.0/contributions/design/rate-limit.md @@ -0,0 +1,447 @@ +--- +title: "Rate Limit Design" +--- + +## Overview + +Rate limit is a feature that allows the user to limit the number of incoming requests +to a predefined value based on attributes within the traffic flow. + +Here are some reasons why a user may want to implement Rate limits + +* To prevent malicious activity such as DDoS attacks. +* To prevent applications and its resources (such as a database) from getting overloaded. +* To create API limits based on user entitlements. + +## Scope Types + +The rate limit type here describes the scope of rate limits. + +* Global - In this case, the rate limit is common across all the instances of Envoy proxies +where its applied i.e. if the data plane has 2 replicas of Envoy running, and the rate limit is +10 requests/second, this limit is common and will be hit if 5 requests pass through the first replica +and 5 requests pass through the second replica within the same second. + +* Local - In this case, the rate limits are specific to each instance/replica of Envoy running. +Note - This is not part of the initial design and will be added as a future enhancement. + +## Match Types + +### Rate limit a specific traffic flow + +* Here is an example of a ratelimit 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` + +```yaml +apiVersion: gateway.envoyproxy.io/v1alpha1 +kind: BackendTrafficPolicy +metadata: + name: ratelimit-specific-user +spec: + targetRef: + group: gateway.networking.k8s.io + kind: HTTPRoute + name: example + rateLimit: + type: Global + global: + rules: + - clientSelectors: + - headers: + - name: x-user-id + value: one + limit: + requests: 10 + unit: Hour +--- +apiVersion: gateway.networking.k8s.io/v1 +kind: HTTPRoute +metadata: + name: example +spec: + parentRefs: + - name: eg + hostnames: + - www.example.com + rules: + - matches: + - path: + type: PathPrefix + value: /foo + filters: + - type: ExtensionRef + extensionRef: + group: gateway.envoyproxy.io + kind: RateLimitFilter + name: ratelimit-specific-user + backendRefs: + - name: backend + port: 3000 +``` + +### Rate limit all traffic flows + +* Here is an example of a rate limit implemented by the application developer that limits the total requests made +to a specific route to safeguard health of internal application components. In this case, no specific `headers` match +is specified, and the rate limit is applied to all traffic flows accepted by this `HTTPRoute`. + +```yaml +apiVersion: gateway.envoyproxy.io/v1alpha1 +kind: BackendTrafficPolicy +metadata: + name: ratelimit-all-requests +spec: + targetRef: + group: gateway.networking.k8s.io + kind: HTTPRoute + name: example + rateLimit: + type: Global + global: + rules: + - limit: + requests: 1000 + unit: Second +--- +apiVersion: gateway.networking.k8s.io/v1 +kind: HTTPRoute +metadata: + name: example +spec: + parentRefs: + - name: eg + hostnames: + - www.example.com + rules: + - matches: + - path: + type: PathPrefix + value: /foo + filters: + - type: ExtensionRef + extensionRef: + group: gateway.envoyproxy.io + kind: RateLimitFilter + name: ratelimit-all-requests + backendRefs: + - name: backend + port: 3000 +``` + +### Rate limit per distinct value + +* Here is an example of a rate limit implemented by the application developer to limit any unique user +by matching on a custom `x-user-id` header. Here, user A (recognised from the traffic flow using the header +`x-user-id` and value `a`) will be rate limited at 10 requests/hour and so will user B +(recognised from the traffic flow using the header `x-user-id` and value `b`). + +```yaml +apiVersion: gateway.envoyproxy.io/v1alpha1 +kind: BackendTrafficPolicy +metadata: + name: ratelimit-per-user +spec: + targetRef: + group: gateway.networking.k8s.io + kind: HTTPRoute + name: example + rateLimit: + type: Global + global: + rules: + - clientSelectors: + - headers: + - type: Distinct + name: x-user-id + limit: + requests: 10 + unit: Hour +--- +apiVersion: gateway.networking.k8s.io/v1 +kind: HTTPRoute +metadata: + name: example +spec: + parentRefs: + - name: eg + hostnames: + - www.example.com + rules: + - matches: + - path: + type: PathPrefix + value: /foo + filters: + - type: ExtensionRef + extensionRef: + group: gateway.envoyproxy.io + kind: RateLimitFilter + name: ratelimit-per-user + backendRefs: + - name: backend + port: 3000 +``` + +### Rate limit per source IP + +* Here is an example of a rate limit implemented by the application developer that limits the total requests made +to a specific route by matching on source IP. In this case, requests from `x.x.x.x` will be rate limited at 10 requests/hour. + +```yaml +apiVersion: gateway.envoyproxy.io/v1alpha1 +kind: BackendTrafficPolicy +metadata: + name: ratelimit-per-ip +spec: + targetRef: + group: gateway.networking.k8s.io + kind: HTTPRoute + name: example + rateLimit: + type: Global + global: + rules: + - clientSelectors: + - sourceIP: x.x.x.x/32 + limit: + requests: 10 + unit: Hour +--- +apiVersion: gateway.networking.k8s.io/v1 +kind: HTTPRoute +metadata: + name: example +spec: + parentRefs: + - name: eg + hostnames: + - www.example.com + rules: + - matches: + - path: + type: PathPrefix + value: /foo + filters: + - type: ExtensionRef + extensionRef: + group: gateway.envoyproxy.io + kind: RateLimitFilter + name: ratelimit-per-user + backendRefs: + - name: backend + port: 3000 +``` + +### Rate limit based on JWT claims + +* Here is an example of rate limit implemented by the application developer that limits the total requests made +to a specific route by matching on the jwt claim. In this case, requests with jwt claim information of `{"name":"John Doe"}` +will be rate limited at 10 requests/hour. + +```yaml +apiVersion: gateway.envoyproxy.io/v1alpha1 +kind: SecurityPolicy +metadata: + name: jwt-example +spec: + targetRef: + group: gateway.networking.k8s.io + kind: HTTPRoute + name: example + jwt: + providers: + - name: example + remoteJWKS: + uri: https://raw.githubusercontent.com/envoyproxy/gateway/main/examples/kubernetes/jwt/jwks.json + claimToHeaders: + - claim: name + header: custom-request-header +--- +apiVersion: gateway.envoyproxy.io/v1alpha1 +kind: BackendTrafficPolicy +metadata: + name: ratelimit-specific-user +spec: + targetRef: + group: gateway.networking.k8s.io + kind: HTTPRoute + name: example + rateLimit: + type: Global + global: + rules: + - clientSelectors: + - headers: + - name: custom-request-header + value: John Doe + limit: + requests: 10 + unit: Hour +--- +apiVersion: gateway.networking.k8s.io/v1 +kind: HTTPRoute +metadata: + name: example +spec: + parentRefs: + - name: eg + hostnames: + - "www.example.com" + rules: + - backendRefs: + - group: "" + kind: Service + name: backend + port: 3000 + weight: 1 + matches: + - path: + type: PathPrefix + value: /foo +``` + + +## Multiple RateLimitFilters, rules and clientSelectors +* Users can create multiple `RateLimitFilter`s and apply it to the same `HTTPRoute`. In such a case each +`RateLimitFilter` will be applied to the route and matched (and limited) in a mutually exclusive way, independent of each other. +* Rate limits are applied for each `RateLimitFilter` `rule` when ALL the conditions under `clientSelectors` hold true. + +Here's an example highlighting this - + +```yaml +apiVersion: gateway.envoyproxy.io/v1alpha1 +kind: BackendTrafficPolicy +metadata: + name: ratelimit-all-safeguard-app +spec: + targetRef: + group: gateway.networking.k8s.io + kind: HTTPRoute + name: example + rateLimit: + type: Global + global: + rules: + - limit: + requests: 100 + unit: Hour +--- +apiVersion: gateway.envoyproxy.io/v1alpha1 +kind: BackendTrafficPolicy +metadata: + name: ratelimit-per-user +spec: + targetRef: + group: gateway.networking.k8s.io + kind: HTTPRoute + name: example + rateLimit: + type: Global + global: + rules: + - clientSelectors: + - headers: + - type: Distinct + name: x-user-id + limit: + requests: 100 + unit: Hour +--- +apiVersion: gateway.networking.k8s.io/v1 +kind: HTTPRoute +metadata: + name: example +spec: + parentRefs: + - name: eg + hostnames: + - www.example.com + rules: + - matches: + - path: + type: PathPrefix + value: /foo + filters: + - type: ExtensionRef + extensionRef: + group: gateway.envoyproxy.io + kind: RateLimitFilter + name: ratelimit-per-user + - type: ExtensionRef + extensionRef: + group: gateway.envoyproxy.io + kind: RateLimitFilter + name: ratelimit-all-safeguard-app + backendRefs: + - name: backend + port: 3000 +``` + +* The user has created two `RateLimitFilter`s and has attached it to a `HTTPRoute` - one(`ratelimit-all-safeguard-app`) to +ensure that the backend does not get overwhelmed with requests, any excess requests are rate limited irrespective of +the attributes within the traffic flow, and another(`ratelimit-per-user`) to rate limit each distinct user client +who can be differentiated using the `x-user-id` header, to ensure that each client does not make exessive requests to the backend. +* If user `baz` (identified with the header and value of `x-user-id: baz`) sends 90 requests within the first second, and +user `bar` sends 11 more requests during that same interval of 1 second, and user `bar` sends the 101th request within that second, +the rule defined in `ratelimit-all-safeguard-app` gets activated and Envoy Gateway will ratelimit the request sent by `bar` (and any other +request sent within that 1 second). After 1 second, the rate limit counter associated with the `ratelimit-all-safeguard-app` rule +is reset and again evaluated. +* If user `bar` also ends up sending 90 more requests within the hour, summing up `bar`'s total request count to 101, the rate limit rule +defined within `ratelimit-per-user` will get activated, and `bar`'s requests will be rate limited again until the hour interval ends. +* Within the same above hour, if `baz` sends 991 more requests, summing up `baz`'s total request count to 1001, the rate limit rule defined +within `ratelimit-per-user` will get activated for `baz`, and `baz`'s requests will also be rate limited until the hour interval ends. + +## Design Decisions + +* The initial design uses an Extension filter to apply the Rate Limit functionality on a specific [HTTPRoute][]. +This was preferred over the [PolicyAttachment][] extension mechanism, because it is unclear whether Rate Limit +will be required to be enforced or overridden by the platform administrator or not. +* The RateLimitFilter can only be applied as a filter to a [HTTPRouteRule][], applying it across all backends within a [HTTPRoute][] +and cannot be applied a filter within a [HTTPBackendRef][] for a specific backend. +* The [HTTPRoute][] API has a [matches][] field within each [rule][] to select a specific traffic flow to be routed to +the destination backend. The RateLimitFilter API that can be attached to an HTTPRoute via an [extensionRef][] filter, +also has a `clientSelectors` field within each `rule` to select attributes within the traffic flow to rate limit specific clients. +The two levels of selectors/matches allow for flexibility and aim to hold match information specific to its use, allowing the author/owner +of each configuration to be different. It also allows the `clientSelectors` field within the RateLimitFilter to be enhanced with other matchable +attribute such as [IP subnet][] in the future that are not relevant in the [HTTPRoute][] API. + +## Implementation Details + +### Global Rate limiting + +* [Global rate limiting][] in Envoy Proxy can be achieved using the following - + * [Actions][] can be configured per [xDS Route][]. + * If the match criteria defined within these actions is met for a specific HTTP Request, a set of key value pairs called [descriptors][] + defined within the above actions is sent to a remote [rate limit service][], whose configuration (such as the URL for the rate limit service) is defined + using a [rate limit filter][]. + * Based on information received by the rate limit service and its programmed configuration, a decision is computed, whether to rate limit + the HTTP Request or not, and is sent back to Envoy, which enforces this decision on the data plane. +* Envoy Gateway will leverage this Envoy Proxy feature by - + * Translating the user facing RateLimitFilter API into Rate limit [Actions][] as well as Rate limit service configuration to implement + the desired API intent. + * Envoy Gateway will use the existing [reference implementation][] of the rate limit service. + * The Infrastructure administrator will need to enable the rate limit service using new settings that will be defined in the [EnvoyGateway][] config API. + * The xDS IR will be enhanced to hold the user facing rate limit intent. + * The xDS Translator will be enhanced to translate the rate limit field within the xDS IR into Rate limit [Actions][] as well as instantiate the [rate limit filter][]. + * A new runner called `rate-limit` will be added that subscribes to the xDS IR messages and translates it into a new Rate Limit Infra IR which contains + the [rate limit service configuration][] as well as other information needed to deploy the rate limit service. + * The infrastructure service will be enhanced to subscribe to the Rate Limit Infra IR and deploy a provider specific rate limit service runnable entity. + * A Status field within the RateLimitFilter API will be added to reflect whether the specific configuration was programmed correctly in these multiple locations or not. + +[PolicyAttachment]: https://gateway-api.sigs.k8s.io/references/policy-attachment/ +[HTTPRoute]: https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1.HTTPRoute +[HTTPRouteRule]: https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1.HTTPRouteRule +[HTTPBackendRef]: https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1.HTTPBackendRef +[matches]: https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1.HTTPRouteMatch +[rule]: https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1.HTTPRouteMatch +[extensionRef]: https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1.HTTPRouteFilterType +[IP subnet]: https://en.wikipedia.org/wiki/Subnetwork +[Actions]: https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/route/v3/route_components.proto#envoy-v3-api-msg-config-route-v3-ratelimit-action +[descriptors]: https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/rate_limit_filter.html?highlight=descriptor#example-1 +[Global rate limiting]: https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/other_features/global_rate_limiting +[xDS Route]: https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/route/v3/route_components.proto#envoy-v3-api-msg-config-route-v3-routeaction +[rate limit filter]: https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/http/ratelimit/v3/rate_limit.proto#envoy-v3-api-msg-extensions-filters-http-ratelimit-v3-ratelimit +[rate limit service]: https://www.envoyproxy.io/docs/envoy/latest/configuration/other_features/rate_limit#config-rate-limit-service +[reference implementation]: https://github.com/envoyproxy/ratelimit +[EnvoyGateway]: https://github.com/envoyproxy/gateway/blob/main/api/v1alpha1/envoygateway_types.go +[rate limit service configuration]: https://github.com/envoyproxy/ratelimit#configuration diff --git a/site/content/en/v1.0.0/contributions/design/security-policy.md b/site/content/en/v1.0.0/contributions/design/security-policy.md new file mode 100644 index 00000000000..b39165feb03 --- /dev/null +++ b/site/content/en/v1.0.0/contributions/design/security-policy.md @@ -0,0 +1,115 @@ +--- +title: "SecurityPolicy " +--- + +## Overview + +This design document introduces the `SecurityPolicy` API allowing system administrators to configure +authentication and authorization policies to the traffic entering the gateway. + +## Goals +* Add an API definition to hold settings for configuring authentication and authorization rules +on the traffic entering the gateway. + +## Non Goals +* Define the API configuration fields in this API. + +## Implementation +`SecurityPolicy` is a [Policy Attachment][] type API that can be used to extend [Gateway API][] +to define authentication and authorization rules. + +### Example +Here is an example highlighting how a user can configure this API. + +``` +apiVersion: gateway.networking.k8s.io/v1 +kind: GatewayClass +metadata: + name: eg +spec: + controllerName: gateway.envoyproxy.io/gatewayclass-controller +--- +apiVersion: gateway.networking.k8s.io/v1 +kind: Gateway +metadata: + name: eg + namespace: default +spec: + gatewayClassName: eg + listeners: + - name: https + protocol: HTTPS + port: 443 +--- +apiVersion: gateway.networking.k8s.io/v1 +kind: HTTPRoute +metadata: + name: backend + namespace: default +spec: + parentRefs: + - name: eg + hostnames: + - "www.example.com" + rules: + - backendRefs: + - group: "" + kind: Service + name: backend + port: 3000 + weight: 1 + matches: + - path: + type: PathPrefix + value: / +--- +apiVersion: gateway.envoyproxy.io/v1alpha1 +kind: SecurityPolicy +metadata: + name: jwt-authn-policy + namespace: default +spec: + jwt: + providers: + - name: example + remoteJWKS: + uri: https://raw.githubusercontent.com/envoyproxy/gateway/main/examples/kubernetes/jwt/jwks.json + targetRef: + group: gateway.networking.k8s.io + kind: Gateway + name: eg + namespace: default +``` + +## Features / API Fields +Here is a list of features that can be included in this API +* JWT based authentication +* OIDC Authentication +* External Authorization +* Basic Auth +* API Key Auth +* CORS + +## Design Decisions +* This API will only support a single `targetRef` and can bind to a `Gateway` resource or a `HTTPRoute` or `GRPCRoute`. +* This API resource MUST be part of same namespace as the targetRef resource +* There can be only be ONE policy resource attached to a specific targetRef e.g. a `Listener` (section) within a `Gateway` +* If the policy targets a resource but cannot attach to it, this information should be reflected +in the Policy Status field using the `Conflicted=True` condition. +* If multiple polices target the same resource, the oldest resource (based on creation timestamp) will +attach to the Gateway Listeners, the others will not. +* If Policy A has a `targetRef` that includes a `sectionName` i.e. +it targets a specific Listener within a `Gateway` and Policy B has a `targetRef` that targets the same +entire Gateway then + * Policy A will be applied/attached to the specific Listener defined in the `targetRef.SectionName` + * Policy B will be applied to the remaining Listeners within the Gateway. Policy B will have an additional + status condition `Overridden=True`. +* A Policy targeting the most specific scope wins over a policy targeting a lesser specific scope. + i.e. A Policy targeting a xRoute (`HTTPRoute` or `GRPCRoute`) overrides a Policy targeting a Listener that is +this route's parentRef which in turn overrides a Policy targeting the Gateway the listener/section is a part of. + +## Alternatives +* The project can indefinitely wait for these configuration parameters to be part of the [Gateway API][]. + +[Policy Attachment]: https://gateway-api.sigs.k8s.io/references/policy-attachment +[Gateway API]: https://gateway-api.sigs.k8s.io/ diff --git a/site/content/en/v1.0.0/contributions/design/system-design.md b/site/content/en/v1.0.0/contributions/design/system-design.md new file mode 100644 index 00000000000..fe24f628f9d --- /dev/null +++ b/site/content/en/v1.0.0/contributions/design/system-design.md @@ -0,0 +1,173 @@ +--- +title: "System Design" +weight: 2 +--- + +## Goals + +* Define the system components needed to satisfy the requirements of Envoy Gateway. + +## Non-Goals + +* Create a detailed design and interface specification for each system component. + +## Terminology + +* Control Plane- A collection of inter-related software components for providing application gateway and routing + functionality. The control plane is implemented by Envoy Gateway and provides services for managing the data plane. + These services are detailed in the [components](#components) section. +* Data Plane- Provides intelligent application-level traffic routing and is implemented as one or more Envoy proxies. + +## Architecture + +![Architecture](/img/architecture.png) + +## Configuration + +Envoy Gateway is configured statically at startup and the managed data plane is configured dynamically through +Kubernetes resources, primarily [Gateway API][gw_api] objects. + +### Static Configuration + +Static configuration is used to configure Envoy Gateway at startup, i.e. change the GatewayClass controllerName, +configure a Provider, etc. Currently, Envoy Gateway only supports configuration through a configuration file. If the +configuration file is not provided, Envoy Gateway starts-up with default configuration parameters. + +### Dynamic Configuration + +Dynamic configuration is based on the concept of a declaring the desired state of the data plane and using +reconciliation loops to drive the actual state toward the desired state. The desired state of the data plane is +defined as Kubernetes resources that provide the following services: + +* Infrastructure Management- Manage the data plane infrastructure, i.e. deploy, upgrade, etc. This configuration is + expressed through [GatewayClass][gc] and [Gateway][gw] resources. The `EnvoyProxy` [Custom Resource][cr] can be + referenced by `gatewayclass.spec.parametersRef` to modify data plane infrastructure default parameters, + e.g. expose Envoy network endpoints using a `ClusterIP` service instead of a `LoadBalancer` service. +* Traffic Routing- Define how to handle application-level requests to backend services. For example, route all HTTP + requests for "www.example.com" to a backend service running a web server. This configuration is expressed through + [HTTPRoute][hroute] and [TLSRoute][troute] resources that match, filter, and route traffic to a [backend][be]. + Although a backend can be any valid Kubernetes Group/Kind resource, Envoy Gateway only supports a [Service][svc] + reference. + +## Components + +Envoy Gateway is made up of several components that communicate in-process; how this communication happens is described +in the [Watching Components Design][wcd]. + +### Provider + +A Provider is an infrastructure component that Envoy Gateway calls to establish its runtime configuration, resolve +services, persist data, etc. As of v0.2, Kubernetes is the only implemented provider. A file provider is on the roadmap +via [Issue #37][]. Other providers can be added in the future as Envoy Gateway use cases are better understood. A +provider is configured at start up through Envoy Gateway's [static configuration](#static-configuration). + +#### Kubernetes Provider + +* Uses Kubernetes-style controllers to reconcile Kubernetes resources that comprise the + [dynamic configuration](#dynamic-configuration). +* Manages the data plane through Kubernetes API CRUD operations. +* Uses Kubernetes for Service discovery. +* Uses etcd (via Kubernetes API) to persist data. + +#### File Provider + +* Uses a file watcher to watch files in a directory that define the data plane configuration. +* Manages the data plane by calling internal APIs, e.g. `CreateDataPlane()`. +* Uses the host's DNS for Service discovery. +* If needed, the local filesystem is used to persist data. + +### Resource Watcher + +The Resource Watcher watches resources used to establish and maintain Envoy Gateway's dynamic configuration. The +mechanics for watching resources is provider-specific, e.g. informers, caches, etc. are used for the Kubernetes +provider. The Resource Watcher uses the configured provider for input and provides resources to the Resource Translator +as output. + +### Resource Translator + +The Resource Translator translates external resources, e.g. GatewayClass, from the Resource Watcher to the Intermediate +Representation (IR). It is responsible for: + +* Translating infrastructure-specific resources/fields from the Resource Watcher to the Infra IR. +* Translating proxy configuration resources/fields from the Resource Watcher to the xDS IR. + +__Note:__ The Resource Translator is implemented as the `Translator` API type in the `gatewayapi` package. + +### Intermediate Representation (IR) + +The Intermediate Representation defines internal data models that external resources are translated into. This allows +Envoy Gateway to be decoupled from the external resources used for dynamic configuration. The IR consists of an Infra IR +used as input for the Infra Manager and an xDS IR used as input for the xDS Translator. + +* Infra IR- Used as the internal definition of the managed data plane infrastructure. +* xDS IR- Used as the internal definition of the managed data plane xDS configuration. + +### xDS Translator + +The xDS Translator translates the xDS IR into xDS Resources that are consumed by the xDS server. + +### xDS Server + +The xDS Server is a xDS gRPC Server based on [Go Control Plane][go_cp]. Go Control Plane implements the Delta xDS Server +Protocol and is responsible for using xDS to configure the data plane. + +### Infra Manager + +The Infra Manager is a provider-specific component responsible for managing the following infrastructure: + +* Data Plane - Manages all the infrastructure required to run the managed Envoy proxies. For example, CRUD Deployment, + Service, etc. resources to run Envoy in a Kubernetes cluster. +* Auxiliary Control Planes - Optional infrastructure needed to implement application Gateway features that require + external integrations with the managed Envoy proxies. For example, [Global Rate Limiting][grl] requires provisioning + and configuring the [Envoy Rate Limit Service][rls] and the [Rate Limit filter][rlf]. Such features are exposed to + users through the [Custom Route Filters][crf] extension. + +The Infra Manager consumes the Infra IR as input to manage the data plane infrastructure. + +## Design Decisions + +* Envoy Gateway can consume multiple [GatewayClass][gc] by comparing its configured controller name with + `spec.controllerName` of a GatewayClass. + `gatewayclass.spec.parametersRef` refers to the `EnvoyProxy` custom resource for configuring the managed proxy + infrastructure. If unspecified, default configuration parameters are used for the managed proxy infrastructure. +* Envoy Gateway manages [Gateways][gw] that reference its GatewayClass. + * A Gateway resource causes Envoy Gateway to provision managed Envoy proxy infrastructure. + * Envoy Gateway groups Listeners by Port and collapses each group of Listeners into a single Listener if the Listeners + in the group are compatible. Envoy Gateway considers Listeners to be compatible if all the following conditions are + met: + * Either each Listener within the group specifies the “HTTP” Protocol or each Listener within the group specifies + either the “HTTPS” or “TLS” Protocol. + * Each Listener within the group specifies a unique "Hostname". + * As a special case, one Listener within a group may omit "Hostname", in which case this Listener matches when no + other Listener matches. + * Envoy Gateway does __not__ merge listeners across multiple Gateways. +* Envoy Gateway follows Gateway API [guidelines][gwapi_conflicts] to resolve any conflicts. + * A Gateway `listener` corresponds to an Envoy proxy [Listener][listener]. +* An [HTTPRoute][hroute] resource corresponds to an Envoy proxy [Route][route]. + * Each [backendRef][be_ref] corresponds to an Envoy proxy [Cluster][cluster]. +* The goal is to make Envoy Gateway components extensible in the future. See the [roadmap][] for additional details. + +The draft for this document is [here][draft_design]. + +[gw_api]: https://gateway-api.sigs.k8s.io +[gc]: https://gateway-api.sigs.k8s.io/concepts/api-overview/#gatewayclass +[gw]: https://gateway-api.sigs.k8s.io/concepts/api-overview/#gateway +[hroute]: https://gateway-api.sigs.k8s.io/concepts/api-overview/#httproute +[troute]: https://gateway-api.sigs.k8s.io/concepts/api-overview/#tlsroute +[go_cp]: https://github.com/envoyproxy/go-control-plane +[grl]: https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/other_features/global_rate_limiting +[rls]: https://github.com/envoyproxy/ratelimit +[rlf]: https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/http/ratelimit/v3/rate_limit.proto#envoy-v3-api-msg-extensions-filters-http-ratelimit-v3-ratelimit +[crf]: https://gateway-api.sigs.k8s.io/api-types/httproute/#filters-optional +[gwapi_conflicts]: https://gateway-api.sigs.k8s.io/concepts/guidelines/#conflicts +[listener]: https://www.envoyproxy.io/docs/envoy/latest/configuration/listeners/listeners#config-listeners +[route]: https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/route/v3/route_components.proto#envoy-v3-api-msg-config-route-v3-route +[be_ref]: https://gateway-api.sigs.k8s.io/api-types/httproute/#backendrefs-optional +[cluster]: https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/cluster/v3/cluster.proto#config-cluster-v3-cluster +[draft_design]: https://docs.google.com/document/d/1riyTPPYuvNzIhBdrAX8dpfxTmcobWZDSYTTB5NeybuY/edit +[cr]: https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/ +[be]: https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1.BackendObjectReference +[svc]: https://kubernetes.io/docs/concepts/services-networking/service/ +[wcd]: ../watching +[Issue #37]: https://github.com/envoyproxy/gateway/issues/37 +[roadmap]: ../../contributions/roadmap/ diff --git a/site/content/en/v1.0.0/contributions/design/tcp-udp-design.md b/site/content/en/v1.0.0/contributions/design/tcp-udp-design.md new file mode 100644 index 00000000000..8dc29830164 --- /dev/null +++ b/site/content/en/v1.0.0/contributions/design/tcp-udp-design.md @@ -0,0 +1,52 @@ +--- +title: "TCP and UDP Proxy Design " +--- + +Even though most of the use cases for Envoy Gateway are at Layer-7, Envoy Gateway can also work at Layer-4 to proxy TCP +and UDP traffic. This document will explore the options we have when operating Envoy Gateway at Layer-4 and explain the +design decision. + +Envoy can work as a non-transparent proxy or a transparent proxy for both [TCP][] + and [UDP][] +, so ideally, Envoy Gateway should also be able to work in these two modes: + +## Non-transparent Proxy Mode +For TCP, Envoy terminates the downstream connection, connects the upstream with its own IP address, and proxies the +TCP traffic from the downstream to the upstream. + +For UDP, Envoy receives UDP datagrams from the downstream, and uses its own IP address as the sender IP address when +proxying the UDP datagrams to the upstream. + +In this mode, the upstream will see Envoy's IP address and port. + +## Transparent Proxy Mode +For TCP, Envoy terminates the downstream connection, connects the upstream with the downstream IP address, and proxies +the TCP traffic from the downstream to the upstream. + +For UDP, Envoy receives UDP datagrams from the downstream, and uses the downstream IP address as the sender IP address +when proxying the UDP datagrams to the upstream. + +In this mode, the upstream will see the original downstream IP address and Envoy's mac address. + +Note: Even in transparent mode, the upstream can't see the port number of the downstream because Envoy doesn't forward +the port number. + +## The Implications of Transparent Proxy Mode + +### Escalated Privilege +Envoy needs to bind to the downstream IP when connecting to the upstream, which means Envoy requires escalated +CAP_NET_ADMIN privileges. This is often considered as a bad security practice and not allowed in some sensitive deployments. + +### Routing +The upstream can see the original source IP, but the original port number won't be passed, so the return +traffic from the upstream must be routed back to Envoy because only Envoy knows how to send the return traffic back +to the right port number of the downstream, which requires routing at the upstream side to be set up. +In a Kubernetes cluster, Envoy Gateway will have to carefully cooperate with CNI plugins to get the routing right. + +## The Design Decision (For Now) + +The implementation will only support proxying in non-transparent mode i.e. the backend will see the source IP and +port of the deployed Envoy instance instead of the client. + +[TCP]: https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/other_features/ip_transparency#arch-overview-ip-transparency-original-src-listener +[UDP]: https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/udp/udp_proxy/v3/udp_proxy.proto#envoy-v3-api-msg-extensions-filters-udp-udp-proxy-v3-udpproxyconfig diff --git a/site/content/en/v1.0.0/contributions/design/tracing.md b/site/content/en/v1.0.0/contributions/design/tracing.md new file mode 100644 index 00000000000..a2790690fa6 --- /dev/null +++ b/site/content/en/v1.0.0/contributions/design/tracing.md @@ -0,0 +1,166 @@ +--- +title: "Observability: Tracing" +--- + +## Overview + +Envoy supports extensible tracing to different sinks, Zipkin, OpenTelemetry etc. Overview of Envoy tracing can be found [here][tracing]. + +Envoy Gateway leverages [Gateway API][] for configuring managed Envoy proxies. Gateway API defines core, extended, and implementation-specific API [support levels][] for implementers such as Envoy Gateway to expose features. Since tracing is not covered by `Core` or `Extended` APIs, EG should provide an easy to config tracing per `EnvoyProxy`. + +Only OpenTelemetry sink can be configured currently, you can use [OpenTelemetry Collector][] to export to other tracing backends. + +## Goals + +- Support send tracing to `OpenTelemetry` backend +- Support configurable sampling rate +- Support propagate tag from `Literal`, `Environment` and `Request Header` + +## Non-Goals + +- Support other tracing backend, e.g. `Zipkin`, `Jaeger` + +## Use-Cases + +- Configure accesslog for a `EnvoyProxy` to `File` + +### ProxyAccessLog API Type + +```golang mdox-exec="sed '1,7d' api/config/v1alpha1/tracing_types.go" +type ProxyTracing struct { + // SamplingRate controls the rate at which traffic will be + // selected for tracing if no prior sampling decision has been made. + // Defaults to 100, valid values [0-100]. 100 indicates 100% sampling. + // +kubebuilder:validation:Minimum=0 + // +kubebuilder:validation:Maximum=100 + // +kubebuilder:default=100 + // +optional + SamplingRate *uint32 `json:"samplingRate,omitempty"` + // CustomTags defines the custom tags to add to each span. + // If provider is kubernetes, pod name and namespace are added by default. + CustomTags map[string]CustomTag `json:"customTags,omitempty"` + // Provider defines the tracing provider. + // Only OpenTelemetry is supported currently. + Provider TracingProvider `json:"provider"` +} + +type TracingProviderType string + +const ( + TracingProviderTypeOpenTelemetry TracingProviderType = "OpenTelemetry" +) + +type TracingProvider struct { + // Type defines the tracing provider type. + // EG currently only supports OpenTelemetry. + // +kubebuilder:validation:Enum=OpenTelemetry + // +kubebuilder:default=OpenTelemetry + Type TracingProviderType `json:"type"` + // Host define the provider service hostname. + Host string `json:"host"` + // Port defines the port the provider service is exposed on. + // + // +optional + // +kubebuilder:validation:Minimum=0 + // +kubebuilder:default=4317 + Port int32 `json:"port,omitempty"` +} + +type CustomTagType string + +const ( + // CustomTagTypeLiteral adds hard-coded value to each span. + CustomTagTypeLiteral CustomTagType = "Literal" + // CustomTagTypeEnvironment adds value from environment variable to each span. + CustomTagTypeEnvironment CustomTagType = "Environment" + // CustomTagTypeRequestHeader adds value from request header to each span. + CustomTagTypeRequestHeader CustomTagType = "RequestHeader" +) + +type CustomTag struct { + // Type defines the type of custom tag. + // +kubebuilder:validation:Enum=Literal;Environment;RequestHeader + // +unionDiscriminator + // +kubebuilder:default=Literal + Type CustomTagType `json:"type"` + // Literal adds hard-coded value to each span. + // It's required when the type is "Literal". + Literal *LiteralCustomTag `json:"literal,omitempty"` + // Environment adds value from environment variable to each span. + // It's required when the type is "Environment". + Environment *EnvironmentCustomTag `json:"environment,omitempty"` + // RequestHeader adds value from request header to each span. + // It's required when the type is "RequestHeader". + RequestHeader *RequestHeaderCustomTag `json:"requestHeader,omitempty"` + + // TODO: add support for Metadata tags in the future. + // EG currently doesn't support metadata for route or cluster. +} + +// LiteralCustomTag adds hard-coded value to each span. +type LiteralCustomTag struct { + // Value defines the hard-coded value to add to each span. + Value string `json:"value"` +} + +// EnvironmentCustomTag adds value from environment variable to each span. +type EnvironmentCustomTag struct { + // Name defines the name of the environment variable which to extract the value from. + Name string `json:"name"` + // DefaultValue defines the default value to use if the environment variable is not set. + // +optional + DefaultValue *string `json:"defaultValue,omitempty"` +} + +// RequestHeaderCustomTag adds value from request header to each span. +type RequestHeaderCustomTag struct { + // Name defines the name of the request header which to extract the value from. + Name string `json:"name"` + // DefaultValue defines the default value to use if the request header is not set. + // +optional + DefaultValue *string `json:"defaultValue,omitempty"` +} +``` + +### Example + +1. The following is an example to config tracing. + +```yaml mdox-exec="sed '1,12d' examples/kubernetes/tracing/default.yaml" +apiVersion: gateway.envoyproxy.io/v1alpha1 +kind: EnvoyProxy +metadata: + name: tracing + namespace: envoy-gateway-system +spec: + telemetry: + tracing: + # sample 100% of requests + samplingRate: 100 + provider: + host: otel-collector.monitoring.svc.cluster.local + port: 4317 + customTags: + # This is an example of using a literal as a tag value + key1: + type: Literal + literal: + value: "val1" + # This is an example of using an environment variable as a tag value + env1: + type: Environment + environment: + name: ENV1 + defaultValue: "-" + # This is an example of using a header value as a tag value + header1: + type: RequestHeader + requestHeader: + name: X-Header-1 + defaultValue: "-" +``` + +[tracing]: https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/observability/tracing +[Gateway API]: https://gateway-api.sigs.k8s.io/ +[support levels]: https://gateway-api.sigs.k8s.io/concepts/conformance/?h=extended#2-support-levels +[OpenTelemetry Collector]: https://opentelemetry.io/docs/collector/ diff --git a/site/content/en/v1.0.0/contributions/design/watching.md b/site/content/en/v1.0.0/contributions/design/watching.md new file mode 100644 index 00000000000..5eabad7b3f9 --- /dev/null +++ b/site/content/en/v1.0.0/contributions/design/watching.md @@ -0,0 +1,120 @@ +--- +title: "Watching Components Design" +weight: 3 +--- + +Envoy Gateway is made up of several components that communicate in-process. Some of them (namely Providers) watch +external resources, and "publish" what they see for other components to consume; others watch what another publishes and +act on it (such as the resource translator watches what the providers publish, and then publishes its own results that +are watched by another component). Some of these internally published results are consumed by multiple components. + +To facilitate this communication use the [watchable][] library. The `watchable.Map` type is very similar to the +standard library's `sync.Map` type, but supports a `.Subscribe` (and `.SubscribeSubset`) method that promotes a pub/sub +pattern. + +## Pub + +Many of the things we communicate around are naturally named, either by a bare "name" string or by a "name"/"namespace" +tuple. And because `watchable.Map` is typed, it makes sense to have one map for each type of thing (very similar to if +we were using native Go `map`s). For example, a struct that might be written to by the Kubernetes provider, and read by +the IR translator: + + ```go + type ResourceTable struct { + // gateway classes are cluster-scoped; no namespace + GatewayClasses watchable.Map[string, *gwapiv1.GatewayClass] + + // gateways are namespace-scoped, so use a k8s.io/apimachinery/pkg/types.NamespacedName as the map key. + Gateways watchable.Map[types.NamespacedName, *gwapiv1.Gateway] + + HTTPRoutes watchable.Map[types.NamespacedName, *gwapiv1.HTTPRoute] + } + ``` + +The Kubernetes provider updates the table by calling `table.Thing.Store(name, val)` and `table.Thing.Delete(name)`; +updating a map key with a value that is deep-equal (usually `reflect.DeepEqual`, but you can implement your own `.Equal` +method) the current value is a no-op; it won't trigger an event for subscribers. This is handy so that the publisher +doesn't have as much state to keep track of; it doesn't need to know "did I already publish this thing", it can just +`.Store` its data and `watchable` will do the right thing. + +## Sub + +Meanwhile, the translator and other interested components subscribe to it with `table.Thing.Subscribe` (or +`table.Thing.SubscribeSubset` if they only care about a few "Thing"s). So the translator goroutine might look like: + + ```go + func(ctx context.Context) error { + for snapshot := range k8sTable.HTTPRoutes.Subscribe(ctx) { + fullState := irInput{ + GatewayClasses: k8sTable.GatewayClasses.LoadAll(), + Gateways: k8sTable.Gateways.LoadAll(), + HTTPRoutes: snapshot.State, + } + translate(irInput) + } + } + ``` + +Or, to watch multiple maps in the same loop: + + ```go + func worker(ctx context.Context) error { + classCh := k8sTable.GatewayClasses.Subscribe(ctx) + gwCh := k8sTable.Gateways.Subscribe(ctx) + routeCh := k8sTable.HTTPRoutes.Subscribe(ctx) + for ctx.Err() == nil { + var arg irInput + select { + case snapshot := <-classCh: + arg.GatewayClasses = snapshot.State + case snapshot := <-gwCh: + arg.Gateways = snapshot.State + case snapshot := <-routeCh: + arg.Routes = snapshot.State + } + if arg.GateWayClasses == nil { + arg.GatewayClasses = k8sTable.GateWayClasses.LoadAll() + } + if arg.GateWays == nil { + arg.Gateways = k8sTable.GateWays.LoadAll() + } + if arg.HTTPRoutes == nil { + arg.HTTPRoutes = k8sTable.HTTPRoutes.LoadAll() + } + translate(irInput) + } + } + ``` + +From the updates it gets from `.Subscribe`, it can get a full view of the map being subscribed to via `snapshot.State`; +but it must read the other maps explicitly. Like `sync.Map`, `watchable.Map`s are thread-safe; while `.Subscribe` is a +handy way to know when to run, `.Load` and friends can be used without subscribing. + +There can be any number of subscribers. For that matter, there can be any number of publishers `.Store`ing things, but +it's probably wise to just have one publisher for each map. + +The channel returned from `.Subscribe` **is immediately readable** with a snapshot of the map as it existed when +`.Subscribe` was called; and becomes readable again whenever `.Store` or `.Delete` mutates the map. If multiple +mutations happen between reads (or if mutations happen between `.Subscribe` and the first read), they are coalesced in +to one snapshot to be read; the `snapshot.State` is the most-recent full state, and `snapshot.Updates` is a listing of +each of the mutations that cause this snapshot to be different than the last-read one. This way subscribers don't need +to worry about a backlog accumulating if they can't keep up with the rate of changes from the publisher. + +If the map contains anything before `.Subscribe` is called, that very first read won't include `snapshot.Updates` +entries for those pre-existing items; if you are working with `snapshot.Update` instead of `snapshot.State`, then you +must add special handling for your first read. We have a utility function `./internal/message.HandleSubscription` to +help with this. + +## Other Notes + +The common pattern will likely be that the entrypoint that launches the goroutines for each component instantiates the +map, and passes them to the appropriate publishers and subscribers; same as if they were communicating via a dumb +`chan`. + +A limitation of `watchable.Map` is that in order to ensure safety between goroutines, it does require that value types +be deep-copiable; either by having a `DeepCopy` method, being a `proto.Message`, or by containing no reference types and +so can be deep-copied by naive assignment. Fortunately, we're using `controller-gen` anyway, and `controller-gen` can +generate `DeepCopy` methods for us: just stick a `// +k8s:deepcopy-gen=true` on the types that you want it to generate +methods for. + +[watchable]: https://pkg.go.dev/github.com/telepresenceio/watchable diff --git a/site/content/en/v1.0.0/contributions/roadmap.md b/site/content/en/v1.0.0/contributions/roadmap.md new file mode 100644 index 00000000000..955af2a9623 --- /dev/null +++ b/site/content/en/v1.0.0/contributions/roadmap.md @@ -0,0 +1,96 @@ +--- +title: "Roadmap" +weight: -1 +description: "This section records the roadmap of Envoy Gateway." +--- + +This document serves as a high-level reference for Envoy Gateway users and contributors to understand the direction of +the project. + +## Contributing to the Roadmap + +- To add a feature to the roadmap, create an [issue][issue] or join a [community meeting][meeting] to discuss your use + case. If your feature is accepted, a maintainer will assign your issue to a [release milestone][milestones] and update + this document accordingly. +- To help with an existing roadmap item, comment on or assign yourself to the associated issue. +- If a roadmap item doesn't have an issue, create one, assign yourself to the issue, and reference this document. A + maintainer will submit a [pull request][PR] to add the feature to the roadmap. __Note:__ The feature should be + discussed in an issue or a community meeting before implementing it. + +If you don't know where to start contributing, help is needed to reduce technical, automation, and documentation debt. +Look for issues with the `help wanted` label to get started. + +## Details + +Roadmap features and timelines may change based on feedback, community contributions, etc. If you depend on a specific +roadmap item, you're encouraged to attend a community meeting to discuss the details, or help us deliver the feature by +contributing to the project. + +`Last Updated: April 2023` + +### [v0.2.0][v0.2.0]: Establish a Solid Foundation + +- Complete the core Envoy Gateway implementation- [Issue #60][60]. +- Establish initial testing, e2e, integration, etc- [Issue #64][64]. +- Establish user and developer project documentation- [Issue #17][17]. +- Achieve Gateway API conformance (e.g. routing, LB, Header transformation, etc.)- [Issue #65][65]. +- Setup a CI/CD pipeline- [Issue #63][63]. + +### [v0.3.0][v0.3.0]: Drive Advanced Features through Extension Mechanisms + +- Support extended Gateway API fields [Issue #707][707]. +- Support experimental Gateway APIs such as TCPRoute [Issue #643][643], UDPRoute [Issue #641][641] and GRPCRoute [Issue #642][642]. +- Establish guidelines for leveragaing Gateway API extensions [Issue #675][675]. +- Rate Limiting [Issue #670][670]. +- Authentication [Issue #336][336]. + +### [v0.4.0][v0.4.0]: Customizing Envoy Gateway + +- Extending Envoy Gateway control plane [Issue #20][20] +- Helm based installation for Envoy Gateway [Issue #650][650] +- Customizing managed Envoy Proxy Kubernetes resource fields [Issue #648][648] +- Configuring xDS Bootstrap [Issue #31][31] + +### [v0.5.0][v0.5.0]: Observability and Scale + +- Observability for data plane [Issue #699][699]. +- Allow users to configure xDS Resources [Issue #24][24]. + +### [v0.6.0][v0.6.0]: Preparation for GA + +- Observability for control plane [Issue #700][700]. +- Compute and document Envoy Gateway performance [Issue #1365][1365]. +- Add TrafficPolicy APIs for advanced features [Issue #1492][1492]. +- Envoy Gateway meets readiness criteria [Issue #1160][1160]. + +[issue]: https://github.com/envoyproxy/gateway/issues +[meeting]: https://docs.google.com/document/d/1leqwsHX8N-XxNEyTflYjRur462ukFxd19Rnk3Uzy55I/edit?usp=sharing +[pr]: https://github.com/envoyproxy/gateway/compare +[milestones]: https://github.com/envoyproxy/gateway/milestones +[v0.2.0]: https://github.com/envoyproxy/gateway/milestone/1 +[v0.3.0]: https://github.com/envoyproxy/gateway/milestone/7 +[v0.4.0]: https://github.com/envoyproxy/gateway/milestone/12 +[v0.5.0]: https://github.com/envoyproxy/gateway/milestone/13 +[v0.6.0]: https://github.com/envoyproxy/gateway/milestone/15 +[17]: https://github.com/envoyproxy/gateway/issues/17 +[20]: https://github.com/envoyproxy/gateway/issues/20 +[24]: https://github.com/envoyproxy/gateway/issues/24 +[31]: https://github.com/envoyproxy/gateway/issues/31 +[60]: https://github.com/envoyproxy/gateway/issues/60 +[63]: https://github.com/envoyproxy/gateway/issues/63 +[64]: https://github.com/envoyproxy/gateway/issues/64 +[65]: https://github.com/envoyproxy/gateway/issues/65 +[336]: https://github.com/envoyproxy/gateway/issues/336 +[641]: https://github.com/envoyproxy/gateway/issues/641 +[642]: https://github.com/envoyproxy/gateway/issues/642 +[648]: https://github.com/envoyproxy/gateway/issues/648 +[650]: https://github.com/envoyproxy/gateway/issues/650 +[643]: https://github.com/envoyproxy/gateway/issues/643 +[670]: https://github.com/envoyproxy/gateway/issues/670 +[675]: https://github.com/envoyproxy/gateway/issues/675 +[699]: https://github.com/envoyproxy/gateway/issues/699 +[700]: https://github.com/envoyproxy/gateway/issues/700 +[707]: https://github.com/envoyproxy/gateway/issues/707 +[1160]: https://github.com/envoyproxy/gateway/issues/1160 +[1365]: https://github.com/envoyproxy/gateway/issues/1365 +[1492]: https://github.com/envoyproxy/gateway/issues/1492 diff --git a/site/content/en/v1.0.0/install/_index.md b/site/content/en/v1.0.0/install/_index.md new file mode 100644 index 00000000000..b4c6f79c6fd --- /dev/null +++ b/site/content/en/v1.0.0/install/_index.md @@ -0,0 +1,5 @@ +--- +title: "Installation" +description: This section includes installation related contents of Envoy Gateway. +weight: 70 +--- diff --git a/site/content/en/v1.0.0/install/api.md b/site/content/en/v1.0.0/install/api.md new file mode 100644 index 00000000000..165a91d01e6 --- /dev/null +++ b/site/content/en/v1.0.0/install/api.md @@ -0,0 +1,56 @@ ++++ +title = "gateway-helm" ++++ + + +![Version: v0.0.0-latest](https://img.shields.io/badge/Version-v0.0.0--latest-informational?style=flat-square) ![Type: application](https://img.shields.io/badge/Type-application-informational?style=flat-square) ![AppVersion: latest](https://img.shields.io/badge/AppVersion-latest-informational?style=flat-square) + +The Helm chart for Envoy Gateway + +**Homepage:** + +## Maintainers + +| Name | Email | Url | +| ---- | ------ | --- | +| envoy-gateway-steering-committee | | | +| envoy-gateway-maintainers | | | + +## Source Code + +* + +## Values + +| Key | Type | Default | Description | +|-----|------|---------|-------------| +| certgen.job.annotations | object | `{}` | | +| certgen.job.resources | object | `{}` | | +| certgen.job.ttlSecondsAfterFinished | int | `0` | | +| certgen.rbac.annotations | object | `{}` | | +| certgen.rbac.labels | object | `{}` | | +| config.envoyGateway.gateway.controllerName | string | `"gateway.envoyproxy.io/gatewayclass-controller"` | | +| config.envoyGateway.logging.level.default | string | `"info"` | | +| config.envoyGateway.provider.type | string | `"Kubernetes"` | | +| createNamespace | bool | `false` | | +| deployment.envoyGateway.image.repository | string | `"${ImageRepository}"` | | +| deployment.envoyGateway.image.tag | string | `"${ImageTag}"` | | +| deployment.envoyGateway.imagePullPolicy | string | `"Always"` | | +| deployment.envoyGateway.imagePullSecrets | list | `[]` | | +| deployment.envoyGateway.resources.limits.cpu | string | `"500m"` | | +| deployment.envoyGateway.resources.limits.memory | string | `"1024Mi"` | | +| deployment.envoyGateway.resources.requests.cpu | string | `"100m"` | | +| deployment.envoyGateway.resources.requests.memory | string | `"256Mi"` | | +| deployment.pod.affinity | object | `{}` | | +| deployment.pod.annotations | object | `{}` | | +| deployment.pod.labels | object | `{}` | | +| deployment.ports[0].name | string | `"grpc"` | | +| deployment.ports[0].port | int | `18000` | | +| deployment.ports[0].targetPort | int | `18000` | | +| deployment.ports[1].name | string | `"ratelimit"` | | +| deployment.ports[1].port | int | `18001` | | +| deployment.ports[1].targetPort | int | `18001` | | +| deployment.replicas | int | `1` | | +| envoyGatewayMetricsService.port | int | `19001` | | +| kubernetesClusterDomain | string | `"cluster.local"` | | + diff --git a/site/content/en/v1.0.0/install/custom-cert.md b/site/content/en/v1.0.0/install/custom-cert.md new file mode 100644 index 00000000000..c521e61d27d --- /dev/null +++ b/site/content/en/v1.0.0/install/custom-cert.md @@ -0,0 +1,146 @@ +--- +title: Control Plane Authentication using custom certs +weight: -70 +--- + +Envoy Gateway establishes a secure TLS connection for control plane communication between Envoy Gateway pods and the Envoy Proxy fleet. The TLS Certificates used here are self signed and generated using a job that runs before envoy gateway is created, and these certs and mounted on to the envoy gateway and envoy proxy pods. + +In this guide, we'll walk you through configuring custom certs for control plane auth. + +## Before you begin + +We use Cert-Manager to manage the certificates. You can install it by following the [official guide](https://cert-manager.io/docs/installation/kubernetes/). + +## Configure custom certs for control plane + +1. First you need to set up the CA issuer, in this guide, we use the `selfsigned-issuer` as an example. + + *You should not use the self-signed issuer in production, you should use a real CA issuer.* + + ```shell + cat < +``` + +**Note**: Above are some of the ways we can directly use for customization of our installation. But if you are looking for more complex changes [values.yaml](https://helm.sh/docs/chart_template_guide/values_files/) comes to rescue. + +### Using values.yaml file for complex installation + +```yaml +deployment: + envoyGateway: + resources: + limits: + cpu: 700m + memory: 128Mi + requests: + cpu: 10m + memory: 64Mi + ports: + - name: grpc + port: 18005 + targetPort: 18000 + - name: ratelimit + port: 18006 + targetPort: 18001 + +config: + envoyGateway: + logging: + level: + default: debug +``` + +Here we have made three changes to our values.yaml file. Increase the resources limit for cpu to `700m`, changed the port for grpc to `18005` and for ratelimit to `18006` and also updated the logging level to `debug`. + +You can use the below command to install the envoy gateway using values.yaml file. + +```shell +helm install eg oci://docker.io/envoyproxy/gateway-helm --version v0.0.0-latest -n envoy-gateway-system --create-namespace -f values.yaml +``` + +{{% alert title="Helm Chart Values" color="primary" %}} +If you want to know all the available fields inside the values.yaml file, please see the [Helm Chart Values](../api). +{{% /alert %}} + +## Open Ports + +These are the ports used by Envoy Gateway and the managed Envoy Proxy. + +### Envoy Gateway + +| Envoy Gateway | Address | Port | Configurable | +|:----------------------:|:---------:|:------:| :------: | +| Xds EnvoyProxy Server | 0.0.0.0 | 18000 | No | +| Xds RateLimit Server | 0.0.0.0 | 18001 | No | +| Admin Server | 127.0.0.1 | 19000 | Yes | +| Metrics Server | 0.0.0.0 | 19001 | No | +| Health Check | 127.0.0.1 | 8081 | No | + +### EnvoyProxy + +| Envoy Proxy | Address | Port | +|:---------------------------------:|:-----------:| :-----: | +| Admin Server | 127.0.0.1 | 19000 | +| Heath Check | 0.0.0.0 | 19001 | + +{{% alert title="Next Steps" color="warning" %}} +Envoy Gateway should now be successfully installed and running, but in order to experience more abilities of Envoy Gateway, you can refer to [User Guides](../../user). +{{% /alert %}} diff --git a/site/content/en/v1.0.0/install/install-yaml.md b/site/content/en/v1.0.0/install/install-yaml.md new file mode 100644 index 00000000000..4b13529f000 --- /dev/null +++ b/site/content/en/v1.0.0/install/install-yaml.md @@ -0,0 +1,39 @@ ++++ +title = "Install with Kubernetes YAML" +weight = -99 ++++ + +In this guide, we'll walk you through installing Envoy Gateway in your Kubernetes cluster. + +The manual install process does not allow for as much control over configuration +as the [Helm install method](../install-helm), so if you need more control over your Envoy Gateway +installation, it is recommended that you use helm. + +## Before you begin + +Envoy Gateway is designed to run in Kubernetes for production. The most essential requirements are: + +* Kubernetes 1.25 or later +* The `kubectl` command-line tool + +{{% alert title="Compatibility Matrix" color="warning" %}} +Refer to the [Version Compatibility Matrix](/blog/2022/10/01/versions/) to learn more. +{{% /alert %}} + +## Install with YAML + +Envoy Gateway is typically deployed to Kubernetes from the command line. If you don't have Kubernetes, you should use `kind` to create one. + +{{% alert title="Developer Guide" color="primary" %}} +Refer to the [Developer Guide](/latest/contributions/develop) to learn more. +{{% /alert %}} + +1. In your terminal, run the following command: + + ```shell + kubectl apply -f https://github.com/envoyproxy/gateway/releases/download/latest/install.yaml + ``` + +2. Next Steps + + Envoy Gateway should now be successfully installed and running, but in order to experience more abilities of Envoy Gateway, you can refer to [User Guides](/latest/user). diff --git a/site/content/en/v1.0.0/install/matrix.md b/site/content/en/v1.0.0/install/matrix.md new file mode 100644 index 00000000000..c273631d105 --- /dev/null +++ b/site/content/en/v1.0.0/install/matrix.md @@ -0,0 +1,16 @@ +--- +title: Compatibility Matrix +description: This section includes Compatibility Matrix of Envoy Gateway. +--- + +Envoy Gateway relies on the Envoy Proxy and the Gateway API, and runs within a Kubernetes cluster. Not all versions of each of these products can function together for Envoy Gateway. Supported version combinations are listed below; **bold** type indicates the versions of the Envoy Proxy and the Gateway API actually compiled into each Envoy Gateway release. + +| Envoy Gateway version | Envoy Proxy version | Rate Limit version | Gateway API version | Kubernetes version | +|-----------------------|-----------------------------|--------------------|---------------------|----------------------------| +| v1.0.0 | **distroless-v1.29.2** | **19f2079f** | **v1.0.0** | v1.26, v1.27, v1.28, v1.29 | +| v0.6.0 | **distroless-v1.28-latest** | **b9796237** | **v1.0.0** | v1.26, v1.27, v1.28 | +| v0.5.0 | **v1.27-latest** | **e059638d** | **v0.7.1** | v1.25, v1.26, v1.27 | +| v0.4.0 | **v1.26-latest** | **542a6047** | **v0.6.2** | v1.25, v1.26, v1.27 | +| v0.3.0 | **v1.25-latest** | **f28024e3** | **v0.6.1** | v1.24, v1.25, v1.26 | +| v0.2.0 | **v1.23-latest** | | **v0.5.1** | v1.24 | +| latest | **dev-latest** | **master** | **v1.0.0** | v1.26, v1.27, v1.28, v1.29 | diff --git a/site/content/en/v1.0.0/releases/_index.md b/site/content/en/v1.0.0/releases/_index.md new file mode 100644 index 00000000000..382eb1dd20d --- /dev/null +++ b/site/content/en/v1.0.0/releases/_index.md @@ -0,0 +1,5 @@ +--- +title: "Releases" +weight: 90 +description: This section includes Releases of Envoy Gateway. +--- diff --git a/site/content/en/v1.0.0/releases/v0.1.0.md b/site/content/en/v1.0.0/releases/v0.1.0.md new file mode 100644 index 00000000000..3d55118a846 --- /dev/null +++ b/site/content/en/v1.0.0/releases/v0.1.0.md @@ -0,0 +1,9 @@ +--- +title: "v0.1.0" +publishdate: 2022-05-16 +--- + +Date: May 16, 2022 + +## Documentation +- The initial open source release describing project goals and high-level design. diff --git a/site/content/en/v1.0.0/releases/v0.2.0-rc1.md b/site/content/en/v1.0.0/releases/v0.2.0-rc1.md new file mode 100644 index 00000000000..59da2015f9d --- /dev/null +++ b/site/content/en/v1.0.0/releases/v0.2.0-rc1.md @@ -0,0 +1,37 @@ +--- +title: "v0.2.0-rc.1" +publishdate: 2022-08-31 +--- + +Date: August 31, 2022 + +## Documentation +- Added a quickstart guide for users to run and use Envoy Gateway. + +## API +- Added the EnvoyGateway API type for configuring Envoy Gateway. +- Added the EnvoyProxy API type for configuring managed Envoys. + +## CI +- Added tooling to build, run, etc. Envoy Gateway. + +## Providers +- Added the Kubernetes provider. + +## xDS +- Added xDS server to configure managed Envoys. + +## IR +- Added xds and infra IRs to decouple user-facing APIs from Envoy Gateway. +- Added IR validation. + +## Translator +- Added the gatewayapi translator to translate Gateway API and associated resources to the IR and manage +- Gateway API status. + +## Message Service +- Added infra and xds IR watchable map messages for inter-component communication. +- Added a Runner to each component to support pub/sub between components. + +## Infra Manager +- Added Kubernetes Infra Manager to manage Envoy infrastructure running in a Kubernetes cluster. diff --git a/site/content/en/v1.0.0/releases/v0.2.0-rc2.md b/site/content/en/v1.0.0/releases/v0.2.0-rc2.md new file mode 100644 index 00000000000..756ccfb18da --- /dev/null +++ b/site/content/en/v1.0.0/releases/v0.2.0-rc2.md @@ -0,0 +1,34 @@ +--- +title: "v0.2.0-rc.2" +publishdate: 2022-09-29 +--- + +Date: September 29, 2022 + +## Documentation +- Updated and expanded developer documentation. +- Added `kube-demo` target to demonstrate Envoy Gateway functionality. +- Added developer debugging documentation. + +## CI +- Added Gateway API conformance tests. + +## Providers +- Added watchers for dependent resources of managed Envoy infrastructure. +- Added Gateway namespace/name labels to managed resources. +- Added support for finalizing the managed GatewayClass. + +## xDS +- Updated xds server and Envoy bootstrap config to use Delta xDS. +- Added initial support for mTLS between the xDS server and Envoy. + +## Translator +- Expanded support for Gateway API status. +- Added support for request modifier and redirect filters. +- Added support to return 500 responses for invalid backends. + +## Message Service +- Updated IRs to support managing multiple Envoy fleets. + +## Infra Manager +- Separate Envoy infrastructure is created per Gateway. diff --git a/site/content/en/v1.0.0/releases/v0.2.0.md b/site/content/en/v1.0.0/releases/v0.2.0.md new file mode 100644 index 00000000000..6ebad0cf8f2 --- /dev/null +++ b/site/content/en/v1.0.0/releases/v0.2.0.md @@ -0,0 +1,53 @@ +--- +title: "v0.2.0" +publishdate: 2022-10-19 +--- + +Date: October 19, 2022 + +## Documentation +- Added Config API, translator, roadmap, and message bus design documentation. +- Added documentation for releasing Envoy Gateway. +- Added user guides for configuring common tasks, e.g. HTTP request routing. +- Added support for the Sphinx documentation generator. + +## API +- Added the EnvoyGateway API type for configuring Envoy Gateway. +- Added the EnvoyProxy API type for configuring managed Envoys. + +## CI Tooling Testing +- Added tooling to build, run, etc. Envoy Gateway. +- Added Gateway API conformance tests. +- Added Make-based tooling to fetch all tools so checks (code lint, spellchecks) and tests can be run locally. +- Added support for releasing latest artifacts to GitHub. +- Added code coverage with a minimum 60% threshold. + +## IR +- Added xds and infra IRs to decouple user-facing APIs from Envoy Gateway. +- Added IR validation. + +## Translator +- Added the gatewayapi translator to translate Gateway API and associated resources to the IR and manage the status of Gateway API resources. +- Added the xDS translator to translate the xds IR to xDS resources. + +## Message Service +- Added infra and xds IR watchable map messages for inter-component communication. +- Added a Runner to each Envoy Gateway component to support pub/sub between components. +- Added support for managing multiple separate Envoy proxy fleets. + +## Infra Manager +- Added Kubernetes Infra Manager to manage Envoy infrastructure running in a Kubernetes cluster. +- Added support for managing a separate Envoy infrastructure per Gateway. + +## Providers +- Added the Kubernetes provider with support for managing GatewayClass, Gateway, HTTPRoute, ReferenceGrant, and TLSRoute resources. +- Due to Issue #539, a ReferenceGrant is not removed from the system when unreferenced. +- Due to Issue #577, TLSRoute is not being tested for Gateway API conformance. +- Added watchers for dependent resources of managed Envoy infrastructure to trigger reconciliation. +- Added support for labeling managed infrastructure using Gateway namespace/name labels. +- Added support for finalizing the managed GatewayClass. + +## xDS +- Added xDS server support to configure managed Envoys using Delta xDS. +- Added initial support for mTLS between the xDS server and managed Envoys. +- Due to envoyproxy/go-control-plane Issue #599, Envoy Gateway logs the private key of HTTPS listeners. diff --git a/site/content/en/v1.0.0/releases/v0.3.0-rc.1.md b/site/content/en/v1.0.0/releases/v0.3.0-rc.1.md new file mode 100644 index 00000000000..4c50801e6f3 --- /dev/null +++ b/site/content/en/v1.0.0/releases/v0.3.0-rc.1.md @@ -0,0 +1,64 @@ +--- +title: "v0.3.0-rc.1" +publishdate: 2023-02-02 +--- + +Date: February 02, 2023 + +## Documentation +- Added Support for Multiple Release Versions +- Added Support for Versioned Docs +- Added Release Details Docs +- Refactored Layout for User Docs + +## API +- Upgraded to v0.6.0 Gateway API +- Added Support for the TCPRoute API +- Added Support for the UDPRoute API +- Added Support for the GRPCRoute API (Add to the ListenerStatus.SupportedKinds Field until https://github.com/envoyproxy/gateway/issues/950 is fixed.) +- Added Support for HTTPRoute URLRewrite Filter +- Added Support for HTTPRoute RequestMirror Filter +- Added Support for HTTPRoute ResponseHeaderModifier Filter +- Added APIs to Manage Envoy Deployment +- Added Support for Request Authentication +- Added Support for Global Rate Limiting +- Added Support for Routes ReferenceGrant +- Added Support for Namespace Server Config Type + +## CI Tooling Testing +- Fixes Make Image Failed in Darwin +- Fixes Wait for Job Succeeded before conformance test +- Upgraded Echoserver Image Tag +- Added Support for User-Facing Version +- Added Support for Testing EG against Multiple Kubernetes Versions + +## Conformance +- Enabled HTTPRouteInvalidParentRefNotMatchingListenerPort conformance test +- Enabled GatewayInvalidTLSConfiguration conformance test +- Enabled GatewayInvalidRouteKind conformance test +- Enabled HTTPRoutePartiallyInvalidViaInvalidReferenceGrant conformance test +- Enabled HTTPRouteReferenceGrant conformance test +- Enabled HTTPRouteMethodMatching conformance test + +## IR +- Added TCP Listener per TLSRoute + +## Translator +- Fixes Remove Stale Listener Condition +- Added Support for Suffix Matches for Headers +- Added Support for HTTP Method Matching to HTTPRoute +- Added Support for Regex Match Type +- Added Support for HTTPQueryParamMatch + +## Providers +- Refactored Kubernetes Provider to Single Reconciler +- Upgraded Kube Provider Test Data Manifests to v0.6.0 +- Removed Duplicate Settings from Bootstrap Config +- Updated Certgen to Use EG Namespace Env +- Added EnvoyProxy to Translator and Kube Infra Manager +- Upgraded Envoyproxy Image to envoy-dev latest in Main +- Removed EG Logs Private Key + +## xDS +- Fixed Start xDS Server Watchable Map Panics +- Enabled Access Logging for xDS Components diff --git a/site/content/en/v1.0.0/releases/v0.3.0.md b/site/content/en/v1.0.0/releases/v0.3.0.md new file mode 100644 index 00000000000..4eacf8c45c8 --- /dev/null +++ b/site/content/en/v1.0.0/releases/v0.3.0.md @@ -0,0 +1,77 @@ +--- +title: "v0.3.0" +publishdate: 2023-02-09 +--- + +Date: February 09, 2023 + +## Documentation +- Added Global Rate Limit User Docs +- Added Request Authentication User Docs +- Added TCP Routing User Docs +- Added UDP Routing User Docs +- Added GRPC Routing User Docs +- Added HTTP Response Headers User Docs +- Added TCP and UDP Proxy Design Docs +- Added egctl Design Docs +- Added Rate Limit Design Docs +- Added Request Authentication Design Docs +- Added Support for Versioned Docs +- Added Support for Multiple Release Versions +- Added Release Details Docs +- Added API Docs Generating Tooling +- Refactored Layout for User Docs + +## API +- Upgraded to v0.6.1 Gateway API +- Added Support for the TCPRoute API +- Added Support for the UDPRoute API +- Added Support for the GRPCRoute API +- Added Support for HTTPRoute URLRewrite Filter +- Added Support for HTTPRoute RequestMirror Filter +- Added Support for HTTPRoute ResponseHeaderModifier Filter +- Added Support for Request Authentication +- Added Support for Global Rate Limiting +- Added Support for Routes ReferenceGrant +- Added Support for Namespace Server Config Type +- Added initial management of Envoy Proxy deployment via EnvoyProxy API + +## CI Tooling Testing +- Fixed Make Image Failed in Darwin +- Fixed Wait for Job Succeeded before conformance test +- Upgraded Echoserver Image Tag +- Added Support for User-Facing Version +- Added Support for Testing EG against Multiple Kubernetes Versions + +## Conformance +- Enabled GatewayClassObservedGenerationBump conformance test +- Enabled GatewayInvalidTLSConfiguration conformance test +- Enabled GatewayInvalidRouteKind conformance test +- Enabled HTTPRouteReferenceGrant conformance test +- Enabled HTTPRouteMethodMatching conformance test +- Enabled HTTPRoutePartiallyInvalidViaInvalidReferenceGrant conformance test +- Enabled HTTPRouteInvalidParentRefNotMatchingListenerPort conformance test +- (Currently EG passes all conformance tests except redirect and gateway/httproute ObservedGenerationBump tests. Redirect tests are failing due to a possible issue with the way upstream conformance tests have made assumptions. Skip them for now until below issues #992 #993 #994 are resolved) + +## IR +- Added TCP Listener per TLSRoute + +## Translator +- Fixes Remove Stale Listener Condition +- Added Support for Suffix Matches for Headers +- Added Support for HTTP Method Matching to HTTPRoute +- Added Support for Regex Match Type +- Added Support for HTTPQueryParamMatch + +## Providers +- Refactored Kubernetes Provider to Single Reconciler +- Upgraded Kube Provider Test Data Manifests to v0.6.1 +- Removed Duplicate Settings from Bootstrap Config +- Updated Certgen to Use EG Namespace Env +- Added EnvoyProxy to Translator and Kube Infra Manager +- Upgraded Envoyproxy Image to envoy-dev latest in Main +- Removed EG Logs Private Key + +## xDS +- Fixed Start xDS Server Watchable Map Panics +- Enabled Access Logging for xDS Components diff --git a/site/content/en/v1.0.0/releases/v0.4.0-rc.1.md b/site/content/en/v1.0.0/releases/v0.4.0-rc.1.md new file mode 100644 index 00000000000..927069f641f --- /dev/null +++ b/site/content/en/v1.0.0/releases/v0.4.0-rc.1.md @@ -0,0 +1,56 @@ +--- +title: "v0.4.0-rc.1" +publishdate: 2023-04-13 +--- + +Date: April 13, 2023 + +## Documentation +- Added Docs for Installing and Using egctl + +## Installation +- Added Helm Installation Support +- Added Support for Ratelimiting Based On IP Subnet +- Added Gateway API Support Doc + +## API +- Upgraded to Gateway API v0.6.2 +- Added Support for Custom Envoy Proxy Bootstrap Config +- Added Support for Configuring the Envoy Proxy Image and Service +- Added Support for Configuring Annotations, Resources, and Securitycontext Settings on Ratelimit Infra and Envoy Proxy +- Added Support for Using Multiple Certificates on a Single Fully Qualified Domain Name +- Gateway Status Address is now Populated for ClusterIP type Envoy Services +- Envoy Proxy Pod and Container SecurityContext is now Configurable +- Added Custom Envoy Gateway Extensions Framework +- Added Support for Service Method Match in GRPCRoute + +## CI Tooling Testing +- Fixed CI Flakes During Helm Install +- Added Test To Ensure Static xDS Cluster Has Same Field Values as Dynamic Cluster +- Added egctl to Build and Test CI Workflow +- Code Coverage Thresholds are now Enforced by CI +- Fixed latest-release-check CI Job Failures +- Added Auto Release Tooling for Charts + +## Conformance +- Enabled GatewayWithAttachedRoutes Test +- Enabled Enable HTTPRouteInvalidParentRefNotMatchingSectionName Test +- Enabled Enable HTTPRouteDisallowedKind Test +- Re-Enabled Gateway/HTTPRouteObservedGenerationBump Test + +## Translator +- Added Support for Dynamic GatewayControllerName in Route Status + +## Providers +- Update GatewayClass Status Based on EnvoyProxy Config Validation + +## xDS +- Added EDS Support +- Fixed PathSeparatedPrefix and Optimized Logic for Prefixes Ending With Trailing Slash +- Updated Deprecated RegexMatcher +- Refactored Authn and Ratelimit Features to Reuse buildXdsCluster + +## Cli +- Added egctl CLI Tool +- Added egctl Support for Dry Runs of Gateway API Config +- Added egctl Support for Dumping Envoy Proxy xDS Resources diff --git a/site/content/en/v1.0.0/releases/v0.4.0.md b/site/content/en/v1.0.0/releases/v0.4.0.md new file mode 100644 index 00000000000..12c40904088 --- /dev/null +++ b/site/content/en/v1.0.0/releases/v0.4.0.md @@ -0,0 +1,59 @@ +--- +title: "v0.4.0" +publishdate: 2023-04-24 +--- + +Date: April 24, 2023 + +## Documentation +- Added Docs for Installing and Using egctl + +## Installation +- Added Helm Installation Support +- Added Support for Ratelimiting Based On IP Subnet +- Added Gateway API Support Doc +- Added Namespace Resource to Helm Templates +- Updated Installation Yaml to Use the envoy-gateway-system Namespace + +## API +- Upgraded to Gateway API v0.6.2 +- Added Support for Custom Envoy Proxy Bootstrap Config +- Added Support for Configuring the Envoy Proxy Image and Service +- Added Support for Configuring Annotations, Resources, and Securitycontext Settings on Ratelimit Infra and Envoy Proxy +- Added Support for Using Multiple Certificates on a Single Fully Qualified Domain Name +- Gateway Status Address is now Populated for ClusterIP type Envoy Services +- Envoy Proxy Pod and Container SecurityContext is now Configurable +- Added Custom Envoy Gateway Extensions Framework +- Added Support for Service Method Match in GRPCRoute +- Fixed a Bug in the Extension Hooks for xDS Virtual Hosts and Routes + +## CI Tooling Testing +- Fixed CI Flakes During Helm Install +- Added Test To Ensure Static xDS Cluster Has Same Field Values as Dynamic Cluster +- Added egctl to Build and Test CI Workflow +- Code Coverage Thresholds are now Enforced by CI +- Fixed latest-release-check CI Job Failures +- Added Auto Release Tooling for Charts + +## Conformance +- Enabled GatewayWithAttachedRoutes Test +- Enabled Enable HTTPRouteInvalidParentRefNotMatchingSectionName Test +- Enabled Enable HTTPRouteDisallowedKind Test +- Re-Enabled Gateway/HTTPRouteObservedGenerationBump Test + +## Translator +- Added Support for Dynamic GatewayControllerName in Route Status + +## Providers +- Update GatewayClass Status Based on EnvoyProxy Config Validation + +## xDS +- Added EDS Support +- Fixed PathSeparatedPrefix and Optimized Logic for Prefixes Ending With Trailing Slash +- Updated Deprecated RegexMatcher +- Refactored Authn and Ratelimit Features to Reuse buildXdsCluster + +## Cli +- Added egctl CLI Tool +- Added egctl Support for Dry Runs of Gateway API Config +- Added egctl Support for Dumping Envoy Proxy xDS Resources diff --git a/site/content/en/v1.0.0/releases/v0.5.0-rc.1.md b/site/content/en/v1.0.0/releases/v0.5.0-rc.1.md new file mode 100644 index 00000000000..bda070995c8 --- /dev/null +++ b/site/content/en/v1.0.0/releases/v0.5.0-rc.1.md @@ -0,0 +1,71 @@ +--- +title: "v0.5.0-rc.1" +publishdate: 2023-07-26 +--- + +Date: July 26, 2023 + +## Documentation +- Added Docs for Installation page using Helm +- Added Docs for Cert Manager Integration +- Added Docs for Presentation Links +- Added Docs for configuring multiple TLS Certificates per Listener + +## Installation +- Added Support for configuring Envoy Gateway Label and Annotations using Helm +- Increased default Resource defaults for Envoy Gateway to 100m CPU and 256Mi Memory +- Fixes Helm values for EnvoyGateway startup configuration +- Added opt-in field to skip creating control plane TLS Certificates allowing users to bring their own certificates. + +## API +- Upgraded to Gateway API v0.7.1 +- Added Support for EnvoyPatchPolicy +- Added Support for EnvoyProxy Telemetry - Access Logging, Traces and Metrics +- Added Support for configuring EnvoyProxy Pod Labels +- Added Support for configuring EnvoyProxy Deployment Strategy Settings, Volumes and Volume Mounts +- Added Support for configuring EnvoyProxy as a NodePort Type Service +- Added Support for Distinct RateLimiting for IP Addresses +- Added Support for converting JWT Claims to Headers, to be used for RateLimiting +- Added Admin Server for Envoy Gateway +- Added Pprof Debug Support for Envoy Gateway +- Added Support to Watch for Resources in Select Namespaces +### Breaking Changes +- Renamed field in EnvoyGateway API from Extension to ExtensionManager + +## CI Tooling Testing +- Added Retest Github Action +- Added CherryPick Github Action +- Added E2E Step in Github CI Workflow +- Added RateLimit E2E Tests +- Added JWT Claim based RateLimit E2E Tests +- Added Access Logging E2E tests +- Added Metrics E2E tests +- Added Tracing E2E tests + +## Conformance +- Enabled GatewayWithAttachedRoutes Test +- Enabled HttpRouteRequestMirror Test +- Skipped HTTPRouteRedirectPortAndScheme Test + +## Translator +### Breaking changes +- Renamed IR resources from - to / +- which also affects generated Xds Resources + +## Providers +- Reconcile Node resources to be able to compute Status Addresses for Gateway +- Discard Status before publishing Provider resources to reduce memory consumption + +## xDS +- Fix Init Race in Xds Runner when starting Xds Server and receiving Xds Input +- Switched to Xds SOTW Server for RateLimit Service Configuration +- Added Control Plane TLS between EnvoyProxy and RateLimit Service +- Enabled adding RateLimit Headers when RateLimit is set +- Allowed GRPCRoute and HTTPRoute to be linked to the same HTTPS Listener +- Set ALPN in the Xds Listener with TLS enabled. +- Added Best Practices Default Edge Settings to Xds Resources +- Compute and Publish EnvoyPatchPolicy status from xds-translator runner + +## Cli +- Added egctl x translate Support to generate default missing Resources +- Added egctl x translate Support for AuthenticationFilter and EnvoyPatchPolicy diff --git a/site/content/en/v1.0.0/releases/v0.5.0.md b/site/content/en/v1.0.0/releases/v0.5.0.md new file mode 100644 index 00000000000..ce1bd6b9188 --- /dev/null +++ b/site/content/en/v1.0.0/releases/v0.5.0.md @@ -0,0 +1,71 @@ +--- +title: "v0.5.0" +publishdate: 2023-07-26 +--- + +Date: July 26, 2023 + +## Documentation +- Added Docs for Installation page using Helm +- Added Docs for Cert Manager Integration +- Added Docs for Presentation Links +- Added Docs for configuring multiple TLS Certificates per Listener + +## Installation +- Added Support for configuring Envoy Gateway Label and Annotations using Helm +- Increased default Resource defaults for Envoy Gateway to 100m CPU and 256Mi Memory +- Fixes Helm values for EnvoyGateway startup configuration +- Added opt-in field to skip creating control plane TLS Certificates allowing users to bring their own certificates. + +## API +- Upgraded to Gateway API v0.7.1 +- Added Support for EnvoyPatchPolicy +- Added Support for EnvoyProxy Telemetry - Access Logging, Traces and Metrics +- Added Support for configuring EnvoyProxy Pod Labels +- Added Support for configuring EnvoyProxy Deployment Strategy Settings, Volumes and Volume Mounts +- Added Support for configuring EnvoyProxy as a NodePort Type Service +- Added Support for Distinct RateLimiting for IP Addresses +- Added Support for converting JWT Claims to Headers, to be used for RateLimiting +- Added Admin Server for Envoy Gateway +- Added Pprof Debug Support for Envoy Gateway +- Added Support to Watch for Resources in Select Namespaces +### Breaking Changes +- Renamed field in EnvoyGateway API from Extension to ExtensionManager + +## CI Tooling Testing +- Added Retest Github Action +- Added CherryPick Github Action +- Added E2E Step in Github CI Workflow +- Added RateLimit E2E Tests +- Added JWT Claim based RateLimit E2E Tests +- Added Access Logging E2E tests +- Added Metrics E2E tests +- Added Tracing E2E tests + +## Conformance +- Enabled GatewayWithAttachedRoutes Test +- Enabled HttpRouteRequestMirror Test +- Skipped HTTPRouteRedirectPortAndScheme Test + +## Translator +### Breaking Changes +- Renamed IR resources from - to / + which also affects generated Xds Resources + +## Providers +- Reconcile Node resources to be able to compute Status Addresses for Gateway +- Discard Status before publishing Provider resources to reduce memory consumption + +## xDS +- Fix Init Race in Xds Runner when starting Xds Server and receiving Xds Input +- Switched to Xds SOTW Server for RateLimit Service Configuration +- Added Control Plane TLS between EnvoyProxy and RateLimit Service +- Enabled adding RateLimit Headers when RateLimit is set +- Allowed GRPCRoute and HTTPRoute to be linked to the same HTTPS Listener +- Set ALPN in the Xds Listener with TLS enabled. +- Added Best Practices Default Edge Settings to Xds Resources +- Compute and Publish EnvoyPatchPolicy status from xds-translator runner + +## Cli +- Added egctl x translate Support to generate default missing Resources +- Added egctl x translate Support for AuthenticationFilter and EnvoyPatchPolicy diff --git a/site/content/en/v1.0.0/releases/v0.6.0-rc.1.md b/site/content/en/v1.0.0/releases/v0.6.0-rc.1.md new file mode 100644 index 00000000000..5141bc27966 --- /dev/null +++ b/site/content/en/v1.0.0/releases/v0.6.0-rc.1.md @@ -0,0 +1,64 @@ +--- +title: "v0.6.0-rc.1" +publishdate: 2023-10-27 +--- + +Date: Oct 27, 2023 + +## Documentation +- Introduced a new website based on Hugo +- Added Grafana dashboards and integration docs for EnvoyProxy metrics +- Added Grafana integration docs for Gateway API metrics + +## Installation +- Added Support for configuring Envoy Gateway Label and Annotations using Helm +- Increased default Resource defaults for Envoy Gateway to 100m CPU and 256Mi Memory +- Fixes Helm values for EnvoyGateway startup configuration +- Added opt-in field to skip creating control plane TLS Certificates allowing users to bring their own certificates. + +## API +- Upgraded to Gateway API v1.0.0 +- Added the ClientTrafficPolicy CRD with Keep Alive Support +- Added the BackendTrafficPolicy CRD with RateLimit and LoadBalancer Support +- Added the SecurityPolicy CRD with CORS and JWT Support +- Added EnvoyGateway Metrics with Prometheus and OpenTelemetry support +- Added Support for InitContainers in EnvoyProxy CRD +- Added Support for LoadBalancerIP in EnvoyProxy CRD +- Added Support for AllocateLoadBalancerNodePorts in EnvoyProxy CRD +- Added Support for LoadBalancerClass in EnvoyProxy CRD +- Added Support for selecting EnvoyProxy stats to be generated +- Added Support for enabling EnvoyProxy Virtual Host metrics +- Added Support for Merging Gateway resources onto the same infrastructure + +### Breaking changes +- Removed the AuthenticationFilter CRD +- Removed the RateLimitFilter CRD +- Enabled EnvoyProxy Prometheus Endpoint by default with an option to disable it +- Updated the Bootstrap field within the EnvoyProxy CRD with an additional value +- field to specify bootstrap config + +## watchable +- Improved caching of resource by implementing a compare function agnostic of resource order + +## Translator +### Breaking changes +- Added support for routing to EndpointSlice endpoints +- Added support for HTTPRoute Timeouts +- Added support for multiple RequestMirror filters per HTTPRoute rule +- Use / instead of - in IR Route Names +- Added Support to ignore ports in Host header + +## Providers +- Added the generationChangedPredicate to most resources to limit resource reconiliation +- Improved reconiliation by using the same enqueue request for all resources +- Added support for reconciling ServiceImport CRD +- Added support for selectively watching resources based on Namespace Selector + +## XDS +- Fixed Layered Runtime warnings +- Upgraded to the latest version of go-control-plane that fixed xDS Resource ordering issues for ADS. +- Added HTTP2 Keep Alives to the xds connection + +## Cli +- Added Support for egctl stats command + diff --git a/site/content/en/v1.0.0/releases/v0.6.0.md b/site/content/en/v1.0.0/releases/v0.6.0.md new file mode 100644 index 00000000000..2b8714030b0 --- /dev/null +++ b/site/content/en/v1.0.0/releases/v0.6.0.md @@ -0,0 +1,70 @@ +--- +title: "v0.6.0" +publishdate: 2023-11-01 +--- + +Date: Nov 1, 2023 + +## Documentation +- Introduced a new website based on Hugo +- Added Grafana dashboards and integration docs for EnvoyProxy metrics +- Added Grafana integration docs for Gateway API metrics + +## Installation +- Updated EnvoyProxy image to be a distroless variant. +- Removed resources around kube-rbac-proxy + +## API +- Upgraded to Gateway API v1.0.0 +- Added the ClientTrafficPolicy CRD with Keep Alive Support +- Added the BackendTrafficPolicy CRD with RateLimit and LoadBalancer Support +- Added the SecurityPolicy CRD with CORS and JWT Support +- Added EnvoyGateway Metrics with Prometheus and OpenTelemetry support +- Added Support for InitContainers in EnvoyProxy CRD +- Added Support for LoadBalancerIP in EnvoyProxy CRD +- Added Support for AllocateLoadBalancerNodePorts in EnvoyProxy CRD +- Added Support for LoadBalancerClass in EnvoyProxy CRD +- Added Support for selecting EnvoyProxy stats to be generated +- Added Support for enabling EnvoyProxy Virtual Host metrics +- Added Support for Merging Gateway resources onto the same infrastructure + +### Breaking changes +- Removed the AuthenticationFilter CRD +- Removed the RateLimitFilter CRD +- Moved EnvoyProxy CRD from `config.gateway.envoyproxy.io` to `gateway.envoyproxy.io` +- Enabled EnvoyProxy Prometheus Endpoint by default with an option to disable it +- Updated the Bootstrap field within the EnvoyProxy CRD with an additional value +- field to specify bootstrap config + +## Conformance +- Added Support for HTTPRouteBackendProtocolH2C Test +- Added Support for HTTPRouteBackendProtocolWebSocket Test +- Added Support for HTTPRouteRequestMultipleMirrors Test +- Added Support for HTTPRouteTimeoutRequest Test +- Added Support for HTTPRouteTimeoutBackendRequest Test +- Added Support for HTTPRouteRedirectPortAndScheme Test + +## Watchable +- Improved caching of resource by implementing a compare function agnostic of resource order + +## Translator +- Added support for routing to EndpointSlice endpoints +- Added support for HTTPRoute Timeouts +- Added support for multiple RequestMirror filters per HTTPRoute rule +- Use / instead of - in IR Route Names +- Added Support to ignore ports in Host header + +## Providers +- Added the generationChangedPredicate to most resources to limit resource reconiliation +- Improved reconiliation by using the same enqueue request for all resources +- Added support for reconciling ServiceImport CRD +- Added support for selectively watching resources based on Namespace Selector + + +## XDS +- Fixed Layered Runtime warnings +- Upgraded to the latest version of go-control-plane that fixed xDS Resource ordering issues for ADS. +- Added HTTP2 Keep Alives to the xds connection + +## Cli +- Added Support for egctl stats command diff --git a/site/content/en/v1.0.0/releases/v1.0.0.md b/site/content/en/v1.0.0/releases/v1.0.0.md new file mode 100644 index 00000000000..134a7f23071 --- /dev/null +++ b/site/content/en/v1.0.0/releases/v1.0.0.md @@ -0,0 +1,170 @@ +--- +title: "v1.0.0" +publishdate: 2023-11-01 +--- + +Date: Nov 1, 2023 + +## Documentation +- Added User Guide for Local Ratelimit +- Added User Guide for Circuit Breaker +- Added User Guide for fault injection +- Added User Guide for EnvoyProxy extraArgs +- Added User Guide for Timeouts in ClientTrafficPolicy +- Added User Guide for JWT claim base routing +- Added User Guide for HTTP Timeout +- Added User Guide for Retry in BackendTrafficPolicy +- Added User Guide for Basic Auth +- Added User Guide for OIDC +- Added User Guide for ClientTrafficPolicy +- Added User Guide for BackendTrafficPolicy +- Added User Guide for Basic Auth using HTTPS +- Added User Guide for External Authorization +- Added User Guide for Routing Outside Kubernetes +- Added User Guide for BackendTLSPolicy +- Added User Guide for Mutual TLS from External Clients to the Gateway +- Added User Guide for Control Plane Authentication using custom certs +- Added User Guide for Multiple Gatewayclass and Merge Gateways Deployment Mode +- Added `Type` and `required` for CRD API doc +- Refactored Structure of User Guide docs +- Refactored Move Design docs under "Get Involved" +- Updated crd-ref-docs to 0.0.10 +- Updated Envoy proxy image to envoy:distroless-dev in main + +## Installation +- Added Support for Pulling envoyGateway image from a private registry +- Added Support for Configuring resources for certgen job +- Added Support for Configuring affinity for EnvoyGateway pod + +## API +- Added Support for Downstream QUIC/HTTP3 in ClientTrafficPolicy CRD +- Added Support for Downstream MTLS in ClientTrafficPolicy CRD +- Added Support for Enabling EnvoyHeaders in ClientTrafficPolicy CRD +- Added Support for DisableMergeSlash and escapedSlashesAction in ClientTrafficPolicy CRD +- Added Support for EnableTrailers in HTTP/1.1 in ClientTrafficPolicy CRD +- Added Support for Preserving header letter-case on HTTP/1 in ClientTrafficPolicy CRD +- Added Support for Enabling HTTP/1.0 and HTTP/0.9 in ClientTrafficPolicy CRD +- Added Support for Client IP Detection using XFF in ClientTrafficPolicy CRD +- Added Support for Client IP Detection using Custom Header in ClientTrafficPolicy CRD +- Added Support for Connection Timeouts in ClientTrafficPolicy CRD +- Added Support for Common TLS configuration properties in ClientTrafficPolicy CRD +- Added Support for Proxy protocol in ClientTrafficPolicy CRD +- Added Support for TCPKeepAlive in ClientTrafficPolicy CRD +- Added Support for Local rate limit in BackendTrafficPolicy CRD +- Added Support for CircuitBreaker in BackendTrafficPolicy CRD +- Added Support for Fault injection in BackendTrafficPolicy CRD +- Added Support for Passive Health Checks in BackendTrafficPolicy CRD +- Added Support for Active Health Checks in BackendTrafficPolicy CRD +- Added Support for Connection Timeouts in BackendTrafficPolicy CRD +- Added Support for Compressor/Decompressor in BackendTrafficPolicy CRD +- Added Support for Retry in BackendTrafficPolicy CRD +- Added Support for Slow start mode in BackendTrafficPolicy CRD +- Added Support for Proxy protocol in BackendTrafficPolicy CRD +- Added Support for TCPKeepAlive in BackendTrafficPolicy CRD +- Added Support for PolicyStatus in BackendTrafficPolicy CRD +- Added Support for PolicyStatus in ClientTrafficPolicy CRD +- Added Support for PolicyStatus in SecurityPolicy CRD +- Added Support for OIDC in SecurityPolicy CRD +- Added Support for Basic Auth in SecurityPolicy CRD +- Added Support for RedirectURL and signoutPath to OIDC in SecurityPolicy CRD +- Added Support for ExtractFrom headers and params to JWT in SecurityPolicy CRD +- Added Support for External Authorization in SecurityPolicy CRD +- Added Support for RecomputeRoute field to JWT in SecurityPolicy CRD +- Added Support for AllowCredentials knob to CORS setting in SecurityPolicy CRD +- Added Support for Extract from different identifier to JWT in SecurityPolicy CRD +- Added Support for Secret resource in EnvoyPatchPolicy CRD +- Added Support for Making the value optional for JSONPatchOperation in EnvoyPatchPolicy CRD +- Added Support for `From` field to JSONPatchOperation in EnvoyPatchPolicy CRD +- Added Support for MergeGateways in EnvoyPatchPolicy CRD +- Added Support for Upstream TLS by implementing BackendTLSPolicy CRD +- Added Support for LabelSelector type for NamespaceSelectors in EnvoyGateway Configuration +- Added Support for Ratelimit prometheus in EnvoyGateway Configuration +- Added Support for Gracefully drain listeners before envoy shutdown on pod termination in EnvoyProxy CRD +- Added Support for Configuring externalTrafficPolicy to the envoy service in EnvoyProxy CRD +- Added Support for Envoy extra args in EnvoyProxy CRD +- Added Support for Mergepatch to envoyproxy/ratelimit deployment in EnvoyProxy CRD +- Added Support for Mergepatch to envoyproxy service in EnvoyProxy CRD +- Added Support for NodeSelector to PodSpec in EnvoyProxy CRD +- Added Support for HorizontalPodAutoscaler in EnvoyProxy CRD +- Added Support for TopologySpreadConstraints to PodSpec in EnvoyProxy CRD +- Added Support for ImagePullSecrets to PodSpec in EnvoyProxy CRD + +### Breaking Changes +- Use wildcard to match AllowOrigins to CORS in SecurityPolicy CRD +- Remove Hostnetwork support in EnvoyProxy CRD + +## Conformance +- Replaced backend image from gcr.io/k8s-staging-ingressconformance/echoserver to gcr.io/k8s-staging-gateway-api/echo-basic + +## Testing +- Added e2e test for Header Case-Preserving +- Added e2e test for Timeout in ClientTrafficPolicy +- Added e2e test for JWT claim base routing +- Added e2e test for OIDC +- Added e2e test for BackendTrafficPolicy Retry +- Added e2e test for Backend Upgrade +- Added e2e test for External Authorization +- Added e2e test for Backend TLS policy +- Added e2e test for Envoy Gateway Release Upgrade +- Added e2e test for Weighted backend +- Added validation for LoadBalancerIP to prevent trailing period + +## Translator +- Fixed Prefix match to prevent mismatching routes with the same prefix +- Fixed Multiple reconciling by implementing comparable interface for ir.Infra +- Fixed EndpointSlice with empty conditions {} +- Fixed Error handling when parsing the http request timeout +- Fixed No status when EnvoyPatchPolicy is disabled +- Fixed Printable for xds and infra IRs +- Fixed Skip backendRefs with weight set to 0 +- Fixed AND Header matches in ratelimiting not working +- Fixed Deletion logics when no gatewayclasses exist +- Fixed Match mergedGateways irKey for ClientTrafficPolicy +- Fixed Policies should apply only to gateways they were attached to when mergeGateways is true +- Fixed Listener status is not surfaced for gateways when MergeGateways enabled +- Fixed GRPCroute websocket not working by moving web socket upgrade config from hcm to route +- Fixed Configure idle timeout when timeout is set on HTTPRoute +- Fixed Relaxing HTTPS restriction for OIDC token endpoint +- Fixed Panic when translating routes with empty backends +- Fixed Xds translation should be done in a best-effort manner +- Fixed Delete unused status keys from watchable +- Fixed Ignoring finalizers when comparing envoy proxy service +- Fixed Don't override the ALPN array if HTTP/3 is enabled +- Fixed Add h3 ALPN by default if HTTP/3 is enabled +- Fixed Change the Merge behavior to Replace for SecurityPolicy/BackendTrafficPolicy +- Fixed Use service port in alt-svc header if HTTP/3 is enabled +- Fixed Prevent policies targeting non-TLS listeners on the same port from conflicting +- Fixed Skip the ReasonTargetNotFound for all policies +- Fixed Skip publishing empty status for all policies +- Added Support for validating regex before sending to Envoy +- Added Support for setting spec.addresses.value into ClusterIP when Service Type is ClusterIP +- Added Unsupported status condition for filters within BackendRef +- Added List instead of map for Provider Resources for order stability +- Added Suffix for oauth cookies to prevent multiple oauth filters from overwriting each other's cookies +- Added Support for overriding condition to BackendTrafficPolicy and SecurityPolicy +- Added Support for default retry budget and retry host predicate +- Added Support for implementing gateway.spec.infrastructure +- Added Support for Upstream TLS to multiple Backends +- Added Validation for CA Cert in ClientTrafficPolicy + +## Providers +- Added Support for multiple GatewayClass per controller +- Added SecurityPolicyIndexers in Kubernetes Provider +- Added Support for generating HMAC secret in CertGen Job +- Fixed Finalizer logic when deleting Gatewayclasses +- Fixed MergeGateways panics when restarting control plane + +## xDS +- Added Support for EDS cache +- Added Support for ADS cache to ensure the rule order +- Fixed Deprecated field error when using RequestHeaderModifier filter +- Fixed Envoy rejects XDS at runtime losing all routes on restart +- Fixed Requests not matching defined routes trigger per-route filters +- Bumped go-control-plane to v0.12.0 + +## Cli +- Added Support for egctl x status +- Added Support for egctl experimental dashboard envoy-proxy +- Added Support for egctl config ratelimit +- Added Support for egctl translate from gateway-api resources to IR + diff --git a/site/content/en/v1.0.0/user/_index.md b/site/content/en/v1.0.0/user/_index.md new file mode 100644 index 00000000000..e413578a6ca --- /dev/null +++ b/site/content/en/v1.0.0/user/_index.md @@ -0,0 +1,5 @@ +--- +title: "User Guides" +weight: 2 +description: This section includes User Guides of Envoy Gateway. +--- diff --git a/site/content/en/v1.0.0/user/extensibility/_index.md b/site/content/en/v1.0.0/user/extensibility/_index.md new file mode 100644 index 00000000000..9560b0dd241 --- /dev/null +++ b/site/content/en/v1.0.0/user/extensibility/_index.md @@ -0,0 +1,5 @@ +--- +title: "Extensibility" +weight: 4 +description: This section includes User Guides of Extensibility. +--- diff --git a/site/content/en/v1.0.0/user/extensibility/envoy-patch-policy.md b/site/content/en/v1.0.0/user/extensibility/envoy-patch-policy.md new file mode 100644 index 00000000000..994436c9473 --- /dev/null +++ b/site/content/en/v1.0.0/user/extensibility/envoy-patch-policy.md @@ -0,0 +1,241 @@ +--- +title: "Envoy Patch Policy" +--- + +This guide explains the usage of the [EnvoyPatchPolicy][] API. +__Note:__ This API is meant for users extremely familiar with Envoy [xDS][] semantics. +Also before considering this API for production use cases, please be aware that this API +is unstable and the outcome may change across versions. Use at your own risk. + +## Introduction + +The [EnvoyPatchPolicy][] API allows user to modify the output [xDS][] +configuration generated by Envoy Gateway intended for EnvoyProxy, +using [JSON Patch][] semantics. + +## Motivation + +This API was introduced to allow advanced users to be able to leverage Envoy Proxy functionality +not exposed by Envoy Gateway APIs today. + +## Quickstart + +### Prerequisites + +* Follow the steps from the [Quickstart](../../quickstart) guide to install Envoy Gateway and the example manifest. +Before proceeding, you should be able to query the example backend using HTTP. + +### Enable EnvoyPatchPolicy + +* By default [EnvoyPatchPolicy][] is disabled. Lets enable it in the [EnvoyGateway][] startup configuration + +* 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. + + +```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" +EOF +``` + +When mergeGateways is enabled, there will be one Envoy deployment for all Gateways in the cluster. +Then the EnvoyPatchPolicy should target a specific GatewayClass. + +```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" +EOF +``` + +* Lets edit the HTTPRoute resource from the Quickstart to only match on paths with value `/get` + +``` +kubectl patch httproute backend --type=json --patch '[{ + "op": "add", + "path": "/spec/rules/0/matches/0/path/value", + "value": "/get", +}]' +``` + +* Lets test it out by specifying a path apart from `/get` + +``` +$ curl --header "Host: www.example.com" http://localhost:8888/find +Handling connection for 8888 +could not find what you are looking for +``` + +## Debugging + +### Runtime + +* The `Status` subresource should have information about the status of the resource. Make sure +`Accepted=True` and `Programmed=True` conditions are set to ensure that the policy has been +applied to Envoy Proxy. + +``` +apiVersion: gateway.envoyproxy.io/v1alpha1 +kind: EnvoyPatchPolicy +metadata: + annotations: + kubectl.kubernetes.io/last-applied-configuration: | + {"apiVersion":"gateway.envoyproxy.io/v1alpha1","kind":"EnvoyPatchPolicy","metadata":{"annotations":{},"name":"custom-response-patch-policy","namespace":"default"},"spec":{"jsonPatches":[{"name":"default/eg/http","operation":{"op":"add","path":"/default_filter_chain/filters/0/typed_config/local_reply_config","value":{"mappers":[{"body":{"inline_string":"could not find what you are looking for"},"filter":{"status_code_filter":{"comparison":{"op":"EQ","value":{"default_value":404}}}}}]}},"type":"type.googleapis.com/envoy.config.listener.v3.Listener"}],"priority":0,"targetRef":{"group":"gateway.networking.k8s.io","kind":"Gateway","name":"eg","namespace":"default"},"type":"JSONPatch"}} + creationTimestamp: "2023-07-31T21:47:53Z" + generation: 1 + name: custom-response-patch-policy + namespace: default + resourceVersion: "10265" + uid: a35bda6e-a0cc-46d7-a63a-cee765174bc3 +spec: + jsonPatches: + - name: default/eg/http + operation: + op: add + path: /default_filter_chain/filters/0/typed_config/local_reply_config + value: + mappers: + - body: + inline_string: could not find what you are looking for + filter: + status_code_filter: + comparison: + op: EQ + value: + default_value: 404 + type: type.googleapis.com/envoy.config.listener.v3.Listener + priority: 0 + targetRef: + group: gateway.networking.k8s.io + kind: Gateway + name: eg + namespace: default + type: JSONPatch +status: + conditions: + - lastTransitionTime: "2023-07-31T21:48:19Z" + message: EnvoyPatchPolicy has been accepted. + observedGeneration: 1 + reason: Accepted + status: "True" + type: Accepted + - lastTransitionTime: "2023-07-31T21:48:19Z" + message: successfully applied patches. + reason: Programmed + status: "True" + type: Programmed +``` + +### Offline + +* You can use [egctl x translate][] to validate the translated xds output. + +## Caveats + +This API will always be an unstable API and the same outcome cannot be garunteed +across versions for these reasons +* The Envoy Proxy API might deprecate and remove API fields +* Envoy Gateway might alter the xDS translation creating a different xDS output +such as changing the `name` field of resources. + +[EnvoyPatchPolicy]: ../../../api/extension_types#envoypatchpolicy +[EnvoyGateway]: ../../../api/extension_types#envoygateway +[JSON Patch]: https://datatracker.ietf.org/doc/html/rfc6902 +[xDS]: https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/operations/dynamic_configuration +[Local Reply Modification]: https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_conn_man/local_reply +[egctl x translate]: ../egctl#egctl-experimental-translate diff --git a/site/content/en/v1.0.0/user/extensibility/v1.0.0-extensibility b/site/content/en/v1.0.0/user/extensibility/v1.0.0-extensibility new file mode 100644 index 00000000000..e69de29bb2d diff --git a/site/content/en/v1.0.0/user/observability/_index.md b/site/content/en/v1.0.0/user/observability/_index.md new file mode 100644 index 00000000000..ed877d4355b --- /dev/null +++ b/site/content/en/v1.0.0/user/observability/_index.md @@ -0,0 +1,5 @@ +--- +title: "Observability" +weight: 4 +description: This section includes User Guides of Observability. +--- diff --git a/site/content/en/v1.0.0/user/observability/gateway-api-metrics.md b/site/content/en/v1.0.0/user/observability/gateway-api-metrics.md new file mode 100644 index 00000000000..e99a8dee692 --- /dev/null +++ b/site/content/en/v1.0.0/user/observability/gateway-api-metrics.md @@ -0,0 +1,59 @@ +--- +title: "Gateway API Metrics" +--- + +Resource metrics for Gateway API objects are available using the [Gateway API State Metrics][gasm] project. +The project also provides example dashboard for visualising the metrics using Grafana, and example alerts using Prometheus & Alertmanager. + +## Prerequisites + +Follow the steps from the [Quickstart Guide](../../quickstart) to install Envoy Gateway and the example manifest. +Before proceeding, you should be able to query the example backend using HTTP. + +Run the following commands to install the metrics stack, with the Gateway API State Metrics configuration, on your kubernetes cluster: + +```shell +kubectl apply --server-side -f https://raw.githubusercontent.com/Kuadrant/gateway-api-state-metrics/main/config/examples/kube-prometheus/bundle_crd.yaml +kubectl apply -f https://raw.githubusercontent.com/Kuadrant/gateway-api-state-metrics/main/config/examples/kube-prometheus/bundle.yaml +``` + +## Metrics and Alerts + +To access the Prometheus UI, wait for the statefulset to be ready, then use the port-forward command: + +```shell +# This first command may fail if the statefulset has not been created yet. +# In that case, try again until you get a message like 'Waiting for 2 pods to be ready...' +# or 'statefulset rolling update complete 2 pods...' +kubectl -n monitoring rollout status --watch --timeout=5m statefulset/prometheus-k8s +kubectl -n monitoring port-forward service/prometheus-k8s 9090:9090 > /dev/null & +``` + +Navigate to [http://localhost:9090](http://localhost:9090). +Metrics can be queried from the 'Graph' tab e.g. `gatewayapi_gateway_created` +See the [Gateway API State Metrics README][gasm-readme] for the full list of Gateway API metrics available. + +Alerts can be seen in the 'Alerts' tab. +Gateway API specific alerts will be grouped under the 'gateway-api.rules' heading. + +***Note:*** Alerts are defined in a PrometheusRules custom resource in the 'monitoring' namespace. You can modify the alert rules by updating this resource. + +## Dashboards + +To view the dashboards in Grafana, wait for the deployment to be ready, then use the port-forward command: + +```shell +kubectl -n monitoring wait --timeout=5m deployment/grafana --for=condition=Available +kubectl -n monitoring port-forward service/grafana 3000:3000 > /dev/null & +``` + +Navigate to [http://localhost:3000](http://localhost:3000) and sign in with admin/admin. +The Gateway API State dashboards will be available in the 'Default' folder and tagged with 'gateway-api'. +See the [Gateway API State Metrics README][gasm-dashboards] for further information on available dashboards. + +***Note:*** Dashboards are loaded from configmaps. You can modify the dashboards in the Grafana UI, however you will need to export them from the UI and update the json in the configmaps to persist changes. + + +[gasm]: https://github.com/Kuadrant/gateway-api-state-metrics +[gasm-readme]: https://github.com/Kuadrant/gateway-api-state-metrics/tree/main#metrics +[gasm-dashboards]: https://github.com/Kuadrant/gateway-api-state-metrics/tree/main#dashboards diff --git a/site/content/en/v1.0.0/user/observability/grafana-integration.md b/site/content/en/v1.0.0/user/observability/grafana-integration.md new file mode 100644 index 00000000000..b7c58e0d582 --- /dev/null +++ b/site/content/en/v1.0.0/user/observability/grafana-integration.md @@ -0,0 +1,65 @@ +--- +title: "Visualising metrics using Grafana" +--- + +Envoy Gateway provides support for exposing Envoy Proxy metrics to a Prometheus instance. +This guide shows you how to visualise the metrics exposed to prometheus using grafana. + +## Prerequisites + +Follow the steps from the [Quickstart Guide](../../quickstart) to install Envoy Gateway and the example manifest. +Before proceeding, you should be able to query the example backend using HTTP. + +Follow the steps from the [Proxy Observability](../proxy-observability#Metrics) to enable prometheus metrics. + +[Prometheus](https://prometheus.io) is used to scrape metrics from the Envoy Proxy instances. Install Prometheus: + +```shell +helm repo add prometheus-community https://prometheus-community.github.io/helm-charts +helm repo update +helm upgrade --install prometheus prometheus-community/prometheus -n monitoring --create-namespace +``` + +[Grafana](https://grafana.com/grafana/) is used to visualise the metrics exposed by the envoy proxy instances. +Install Grafana: + +```shell +helm repo add grafana https://grafana.github.io/helm-charts +helm repo update +helm upgrade --install grafana grafana/grafana -f https://raw.githubusercontent.com/envoyproxy/gateway/latest/examples/grafana/helm-values.yaml -n monitoring --create-namespace +``` + +Expose endpoints: + +```shell +GRAFANA_IP=$(kubectl get svc grafana -n monitoring -o jsonpath='{.status.loadBalancer.ingress[0].ip}') +``` + +## Connecting Grafana with Prometheus datasource + +To visualise metrics from Prometheus, we have to connect Grafana with Prometheus. If you installed Grafana from the command +from prerequisites sections, the prometheus datasource should be already configured. + +You can also add the data source manually by following the instructions from [Grafana Docs](https://grafana.com/docs/grafana/latest/datasources/prometheus/configure-prometheus-data-source/). + +## Accessing Grafana + +You can access the Grafana instance by visiting `http://{GRAFANA_IP}`, derived in prerequisites. + +To log in to Grafana, use the credentials `admin:admin`. + +Envoy Gateway has examples of dashboard for you to get started: + +### [Envoy Global](https://raw.githubusercontent.com/envoyproxy/gateway/main/examples/grafana/dashboards/envoy-global.json) + +![Envoy Global](/img/envoy-global-dashboard.png) + +### [Envoy Clusters](https://raw.githubusercontent.com/envoyproxy/gateway/main/examples/grafana/dashboards/envoy-clusters.json) + +![Envoy Clusters](/img/envoy-clusters-dashboard.png) + +### [Envoy Pod Resources](https://raw.githubusercontent.com/envoyproxy/gateway/main/examples/grafana/dashboards/envoy-pod-resource.json) + +![Envoy Pod Resources](/img/envoy-pod-resources-dashboard.png) + +You can load the above dashboards in your Grafana to get started. Please refer to Grafana docs for [importing dashboards](https://grafana.com/docs/grafana/latest/dashboards/manage-dashboards/#import-a-dashboard). diff --git a/site/content/en/v1.0.0/user/observability/proxy-observability.md b/site/content/en/v1.0.0/user/observability/proxy-observability.md new file mode 100644 index 00000000000..9c443333ae8 --- /dev/null +++ b/site/content/en/v1.0.0/user/observability/proxy-observability.md @@ -0,0 +1,142 @@ +--- +title: "Proxy Observability" +--- + +Envoy Gateway provides observability for the ControlPlane and the underlying EnvoyProxy instances. +This guide show you how to config proxy observability, includes metrics, logs, and traces. + +## Prerequisites + +Follow the steps from the [Quickstart Guide](../../quickstart) to install Envoy Gateway and the example manifest. +Before proceeding, you should be able to query the example backend using HTTP. + +[FluentBit](https://fluentbit.io/) is used to collect logs from the EnvoyProxy instances and forward them to Loki. Install FluentBit: + +```shell +helm repo add fluent https://fluent.github.io/helm-charts +helm repo update +helm upgrade --install fluent-bit fluent/fluent-bit -f https://raw.githubusercontent.com/envoyproxy/gateway/latest/examples/fluent-bit/helm-values.yaml -n monitoring --create-namespace --version 0.30.4 +``` + +[Loki](https://grafana.com/oss/loki/) is used to store logs. Install Loki: + +```shell +kubectl apply -f https://raw.githubusercontent.com/envoyproxy/gateway/latest/examples/loki/loki.yaml -n monitoring +``` + +[Tempo](https://grafana.com/oss/tempo/) is used to store traces. Install Tempo: + +```shell +helm repo add grafana https://grafana.github.io/helm-charts +helm repo update +helm upgrade --install tempo grafana/tempo -f https://raw.githubusercontent.com/envoyproxy/gateway/latest/examples/tempo/helm-values.yaml -n monitoring --create-namespace --version 1.3.1 +``` + +[OpenTelemetry Collector](https://opentelemetry.io/docs/collector/) offers a vendor-agnostic implementation of how to receive, process and export telemetry data. +Install OTel-Collector: + +```shell +helm repo add open-telemetry https://open-telemetry.github.io/opentelemetry-helm-charts +helm repo update +helm upgrade --install otel-collector open-telemetry/opentelemetry-collector -f https://raw.githubusercontent.com/envoyproxy/gateway/latest/examples/otel-collector/helm-values.yaml -n monitoring --create-namespace --version 0.60.0 +``` + +Expose endpoints: + +```shell +LOKI_IP=$(kubectl get svc loki -n monitoring -o jsonpath='{.status.loadBalancer.ingress[0].ip}') +TEMPO_IP=$(kubectl get svc tempo -n monitoring -o jsonpath='{.status.loadBalancer.ingress[0].ip}') +``` + +## Metrics + +By default, Envoy Gateway expose metrics with prometheus endpoint. + +Verify metrics: + +```shell +export ENVOY_POD_NAME=$(kubectl get pod -n envoy-gateway-system --selector=gateway.envoyproxy.io/owning-gateway-namespace=default,gateway.envoyproxy.io/owning-gateway-name=eg -o jsonpath='{.items[0].metadata.name}') +kubectl port-forward pod/$ENVOY_POD_NAME -n envoy-gateway-system 19001:19001 + +# check metrics +curl localhost:19001/stats/prometheus | grep "default/backend/rule/0/match/0-www" +``` + +You can disable metrics by setting the `telemetry.metrics.prometheus.disable` to `true` in the `EnvoyProxy` CRD. + +```shell +kubectl apply -f https://raw.githubusercontent.com/envoyproxy/gateway/latest/examples/kubernetes/metric/disable-prometheus.yaml +``` + +Envoy Gateway can send metrics to OpenTelemetry Sink. +Send metrics to OTel-Collector: + +```shell +kubectl apply -f https://raw.githubusercontent.com/envoyproxy/gateway/latest/examples/kubernetes/metric/otel-sink.yaml +``` + +Verify OTel-Collector metrics: + +```shell +export OTEL_POD_NAME=$(kubectl get pod -n monitoring --selector=app.kubernetes.io/name=opentelemetry-collector -o jsonpath='{.items[0].metadata.name}') +kubectl port-forward pod/$OTEL_POD_NAME -n monitoring 19001:19001 + +# check metrics +curl localhost:19001/metrics | grep "default/backend/rule/0/match/0-www" +``` + +## Logs + +If custom format string is not specified, Envoy Gateway uses the following default format: + +```json +{"start_time":"%START_TIME%","method":"%REQ(:METHOD)%","x-envoy-origin-path":"%REQ(X-ENVOY-ORIGINAL-PATH?:PATH)%","protocol":"%PROTOCOL%","response_code":"%RESPONSE_CODE%","response_flags":"%RESPONSE_FLAGS%","response_code_details":"%RESPONSE_CODE_DETAILS%","connection_termination_details":"%CONNECTION_TERMINATION_DETAILS%","upstream_transport_failure_reason":"%UPSTREAM_TRANSPORT_FAILURE_REASON%","bytes_received":"%BYTES_RECEIVED%","bytes_sent":"%BYTES_SENT%","duration":"%DURATION%","x-envoy-upstream-service-time":"%RESP(X-ENVOY-UPSTREAM-SERVICE-TIME)%","x-forwarded-for":"%REQ(X-FORWARDED-FOR)%","user-agent":"%REQ(USER-AGENT)%","x-request-id":"%REQ(X-REQUEST-ID)%",":authority":"%REQ(:AUTHORITY)%","upstream_host":"%UPSTREAM_HOST%","upstream_cluster":"%UPSTREAM_CLUSTER%","upstream_local_address":"%UPSTREAM_LOCAL_ADDRESS%","downstream_local_address":"%DOWNSTREAM_LOCAL_ADDRESS%","downstream_remote_address":"%DOWNSTREAM_REMOTE_ADDRESS%","requested_server_name":"%REQUESTED_SERVER_NAME%","route_name":"%ROUTE_NAME%"} +``` + +> Note: Envoy Gateway disable envoy headers by default, you can enable it by setting `EnableEnvoyHeaders` to `true` in the [ClientTrafficPolicy](../../../api/extension_types/#backendtrafficpolicy) CRD. + + +Verify logs from loki: + +```shell +curl -s "http://$LOKI_IP:3100/loki/api/v1/query_range" --data-urlencode "query={job=\"fluentbit\"}" | jq '.data.result[0].values' +``` + +If you want to disable it, set the `telemetry.accesslog.disable` to `true` in the `EnvoyProxy` CRD. + +```shell +kubectl apply -f https://raw.githubusercontent.com/envoyproxy/gateway/latest/examples/kubernetes/accesslog/disable-accesslog.yaml +``` + +Envoy Gateway can send logs to OpenTelemetry Sink. + +```shell +kubectl apply -f https://raw.githubusercontent.com/envoyproxy/gateway/latest/examples/kubernetes/accesslog/otel-accesslog.yaml +``` + +Verify logs from loki: + +```shell +curl -s "http://$LOKI_IP:3100/loki/api/v1/query_range" --data-urlencode "query={exporter=\"OTLP\"}" | jq '.data.result[0].values' +``` + +## Traces + +By default, Envoy Gateway doesn't send traces to OpenTelemetry Sink. +You can enable traces by setting the `telemetry.tracing` in the `EnvoyProxy` CRD. + +***Note:*** Envoy Gateway use 100% sample rate, which means all requests will be traced. This may cause performance issues. + +```shell +kubectl apply -f https://raw.githubusercontent.com/envoyproxy/gateway/latest/examples/kubernetes/tracing/default.yaml +``` + +Verify traces from tempo: + +```shell +curl -s "http://$TEMPO_IP:3100/api/search" --data-urlencode "q={ component=envoy }" | jq .traces +``` + +```shell +curl -s "http://$TEMPO_IP:3100/api/traces/" | jq +``` diff --git a/site/content/en/v1.0.0/user/observability/v1.0.0-observability b/site/content/en/v1.0.0/user/observability/v1.0.0-observability new file mode 100644 index 00000000000..e69de29bb2d diff --git a/site/content/en/v1.0.0/user/operations/_index.md b/site/content/en/v1.0.0/user/operations/_index.md new file mode 100644 index 00000000000..0341d46ad0a --- /dev/null +++ b/site/content/en/v1.0.0/user/operations/_index.md @@ -0,0 +1,5 @@ +--- +title: "Operations" +weight: 4 +description: This section includes User Guides of Operations. +--- diff --git a/site/content/en/v1.0.0/user/operations/customize-envoyproxy.md b/site/content/en/v1.0.0/user/operations/customize-envoyproxy.md new file mode 100644 index 00000000000..5d78247fbbd --- /dev/null +++ b/site/content/en/v1.0.0/user/operations/customize-envoyproxy.md @@ -0,0 +1,372 @@ +--- +title: "Customize EnvoyProxy" +--- + +Envoy Gateway provides an [EnvoyProxy][] CRD that can be linked to the ParametersRef +in GatewayClass, allowing cluster admins to customize the managed EnvoyProxy Deployment and +Service. To learn more about GatewayClass and ParametersRef, please refer to [Gateway API documentation][]. + +## Installation + +Follow the steps from the [Quickstart Guide](../../quickstart) to install Envoy Gateway and the example manifest. +Before proceeding, you should be able to query the example backend using HTTP. + +## Add GatewayClass ParametersRef + +First, you need to add ParametersRef in GatewayClass, and refer to EnvoyProxy Config: + +```shell +cat < Envoy Gateway has provided two initial `env` `ENVOY_GATEWAY_NAMESPACE` and `ENVOY_POD_NAME` for envoyproxy container. + +After applying the config, you can get the envoyproxy deployment, and see resources has been changed. + +## Customize EnvoyProxy Deployment Volumes or VolumeMounts + +You can customize the EnvoyProxy Deployment Volumes or VolumeMounts via EnvoyProxy Config like: + +```shell +cat < GET /get HTTP/1.1 +> Host: www.marketing.example.com +> User-Agent: curl/7.86.0 +> Accept: */* +> +Handling connection for 8888 +* Mark bundle as not supporting multiuse +< HTTP/1.1 200 OK +< content-type: application/json +< x-content-type-options: nosniff +< date: Thu, 20 Apr 2023 19:19:42 GMT +< content-length: 521 +< x-envoy-upstream-service-time: 0 +< server: envoy +< +{ + "path": "/get", + "host": "www.marketing.example.com", + "method": "GET", + "proto": "HTTP/1.1", + "headers": { + "Accept": [ + "*/*" + ], + "User-Agent": [ + "curl/7.86.0" + ], + "X-Envoy-Expected-Rq-Timeout-Ms": [ + "15000" + ], + "X-Envoy-Internal": [ + "true" + ], + "X-Forwarded-For": [ + "10.1.0.157" + ], + "X-Forwarded-Proto": [ + "http" + ], + "X-Request-Id": [ + "c637977c-458a-48ae-92b3-f8c429849322" + ] + }, + "namespace": "marketing", + "ingress": "", + "service": "", + "pod": "backend-74888f465f-bcs8f" +* Connection #0 to host localhost left intact +``` + +* Lets deploy Envoy Gateway in the `product` namespace and also watch resources only in this namespace. + +```shell +helm install \ +--set config.envoyGateway.gateway.controllerName=gateway.envoyproxy.io/product-gatewayclass-controller \ +--set config.envoyGateway.provider.kubernetes.watch.type=Namespaces \ +--set config.envoyGateway.provider.kubernetes.watch.namespaces={product} \ +eg-product oci://docker.io/envoyproxy/gateway-helm \ +--version v0.0.0-latest -n product --create-namespace +``` + +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. + +```shell +cat < GET /get HTTP/1.1 +> Host: www.product.example.com +> User-Agent: curl/7.86.0 +> Accept: */* +> +Handling connection for 8889 +* Mark bundle as not supporting multiuse +< HTTP/1.1 200 OK +< content-type: application/json +< x-content-type-options: nosniff +< date: Thu, 20 Apr 2023 19:20:17 GMT +< content-length: 517 +< x-envoy-upstream-service-time: 0 +< server: envoy +< +{ + "path": "/get", + "host": "www.product.example.com", + "method": "GET", + "proto": "HTTP/1.1", + "headers": { + "Accept": [ + "*/*" + ], + "User-Agent": [ + "curl/7.86.0" + ], + "X-Envoy-Expected-Rq-Timeout-Ms": [ + "15000" + ], + "X-Envoy-Internal": [ + "true" + ], + "X-Forwarded-For": [ + "10.1.0.156" + ], + "X-Forwarded-Proto": [ + "http" + ], + "X-Request-Id": [ + "39196453-2250-4331-b756-54003b2853c2" + ] + }, + "namespace": "product", + "ingress": "", + "service": "", + "pod": "backend-74888f465f-64fjs" +* Connection #0 to host localhost left intact +``` + +With the below command you can ensure that you are no able to access the marketing team's backend exposed using the `www.marketing.example.com` hostname +and the product team's data plane. + +```shell +curl --verbose --header "Host: www.marketing.example.com" http://localhost:8889/get +``` + +```console +* Trying 127.0.0.1:8889... +* Connected to localhost (127.0.0.1) port 8889 (#0) +> GET /get HTTP/1.1 +> Host: www.marketing.example.com +> User-Agent: curl/7.86.0 +> Accept: */* +> +Handling connection for 8889 +* Mark bundle as not supporting multiuse +< HTTP/1.1 404 Not Found +< date: Thu, 20 Apr 2023 19:22:13 GMT +< server: envoy +< content-length: 0 +< +* Connection #0 to host localhost left intact +``` + +### Merged gateways deployment + +In this example, we will deploy GatewayClass + +```shell +apiVersion: gateway.networking.k8s.io/v1 +kind: GatewayClass +metadata: + name: merged-eg +spec: + controllerName: gateway.envoyproxy.io/gatewayclass-controller + parametersRef: + group: gateway.envoyproxy.io + kind: EnvoyProxy + name: custom-proxy-config + namespace: envoy-gateway-system +``` + +with a referenced [EnvoyProxy][] resource configured to enable merged Gateways deployment mode. + +```shell +apiVersion: gateway.envoyproxy.io/v1alpha1 +kind: EnvoyProxy +metadata: + name: custom-proxy-config + namespace: envoy-gateway-system +spec: + mergeGateways: true +``` + +#### Deploy merged-gateways example + +Deploy resources on your cluster from the example. + +```shell +kubectl apply -f https://raw.githubusercontent.com/envoyproxy/gateway/latest/examples/kubernetes/merged-gateways.yaml +``` + +Verify that Gateways are deployed and programmed + +```shell +kubectl get gateways -n default + +NAMESPACE NAME CLASS ADDRESS PROGRAMMED AGE +default merged-eg-1 merged-eg 172.18.255.202 True 2m4s +default merged-eg-2 merged-eg 172.18.255.202 True 2m4s +default merged-eg-3 merged-eg 172.18.255.202 True 2m4s +``` + +Verify that HTTPRoutes are deployed + +```shell +kubectl get httproute -n default +NAMESPACE NAME HOSTNAMES AGE +default hostname1-route ["www.merged1.com"] 2m4s +default hostname2-route ["www.merged2.com"] 2m4s +default hostname3-route ["www.merged3.com"] 2m4s +``` + +If you take a look at the deployed Envoy Proxy service you would notice that all of the Gateway listeners ports are added to that service. + +```shell +kubectl get service -n envoy-gateway-system +NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE +envoy-gateway ClusterIP 10.96.141.4 18000/TCP,18001/TCP 6m43s +envoy-gateway-metrics-service ClusterIP 10.96.113.191 19001/TCP 6m43s +envoy-merged-eg-668ac7ae LoadBalancer 10.96.48.255 172.18.255.202 8081:30467/TCP,8082:31793/TCP,8080:31153/TCP 3m17s +``` + +There should be also one deployment (envoy-merged-eg-668ac7ae-775f9865d-55zhs) for every Gateway and its name should reference the name of the GatewayClass. + +```shell +kubectl get pods -n envoy-gateway-system +NAME READY STATUS RESTARTS AGE +envoy-gateway-5d998778f6-wr6m9 1/1 Running 0 6m43s +envoy-merged-eg-668ac7ae-775f9865d-55zhs 2/2 Running 0 3m17s +``` + +#### Testing the Configuration + +Get the name of the merged gateways Envoy service: + +```shell +export ENVOY_SERVICE=$(kubectl get svc -n envoy-gateway-system --selector=gateway.envoyproxy.io/owning-gatewayclass=merged-eg -o jsonpath='{.items[0].metadata.name}') +``` + +Fetch external IP of the service: + +```shell +export GATEWAY_HOST=$(kubectl get svc/${ENVOY_SERVICE} -n envoy-gateway-system -o jsonpath='{.status.loadBalancer.ingress[0].ip}') +``` + +In certain environments, the load balancer may be exposed using a hostname, instead of an IP address. If so, replace +`ip` in the above command with `hostname`. + +Curl the route hostname-route2 through Envoy proxy: + +```shell +curl --header "Host: www.merged2.com" http://$GATEWAY_HOST:8081/example2 +``` + +```shell +{ + "path": "/example2", + "host": "www.merged2.com", + "method": "GET", + "proto": "HTTP/1.1", + "headers": { + "Accept": [ + "*/*" + ], + "User-Agent": [ + "curl/8.4.0" + ], + "X-Envoy-Internal": [ + "true" + ], + "X-Forwarded-For": [ + "172.18.0.2" + ], + "X-Forwarded-Proto": [ + "http" + ], + "X-Request-Id": [ + "deed2767-a483-4291-9429-0e256ab3a65f" + ] + }, + "namespace": "default", + "ingress": "", + "service": "", + "pod": "merged-backend-64ddb65fd7-ttv5z" +} +``` + +Curl the route hostname-route1 through Envoy proxy: + +```shell +curl --header "Host: www.merged1.com" http://$GATEWAY_HOST:8080/example +``` + +```shell +{ + "path": "/example", + "host": "www.merged1.com", + "method": "GET", + "proto": "HTTP/1.1", + "headers": { + "Accept": [ + "*/*" + ], + "User-Agent": [ + "curl/8.4.0" + ], + "X-Envoy-Internal": [ + "true" + ], + "X-Forwarded-For": [ + "172.18.0.2" + ], + "X-Forwarded-Proto": [ + "http" + ], + "X-Request-Id": [ + "20a53440-6327-4c3c-bc8b-8e79e7311043" + ] + }, + "namespace": "default", + "ingress": "", + "service": "", + "pod": "merged-backend-64ddb65fd7-ttv5z" +} +``` + +#### Verify deployment of multiple GatewayClass + +Install the GatewayClass, Gateway, HTTPRoute and example app from [Quickstart][] example: + +```shell +kubectl apply -f https://github.com/envoyproxy/gateway/releases/download/latest/quickstart.yaml -n default +``` + +Lets create also and additional `Gateway` linked to the GatewayClass and `backend` application from Quickstart example. + +```shell +cat < 18000/TCP,18001/TCP 14m25s +envoy-gateway-metrics-service ClusterIP 10.96.113.191 19001/TCP 14m25s +envoy-merged-eg-668ac7ae LoadBalancer 10.96.243.32 172.18.255.202 8082:31622/TCP,8080:32262/TCP,8081:32305/TCP 10m59s +``` + +There should be two deployments for each of newly deployed Gateway and its name should reference the name of the namespace and the Gateway. + +```shell +kubectl get pods -n envoy-gateway-system +``` + +```shell +NAME READY STATUS RESTARTS AGE +envoy-default-eg-2-7e515b2f-8c98fdf88-p6jhg 2/2 Running 0 3m27s +envoy-default-eg-e41e7b31-6f998d85d7-jpvmj 2/2 Running 0 2m26s +envoy-gateway-5d998778f6-wr6m9 1/1 Running 0 14m25s +envoy-merged-eg-668ac7ae-5958f7b7f6-9h9v2 2/2 Running 0 10m59s +``` + +#### Testing the Configuration + +Get the name of the merged gateways Envoy service: + +```shell +export DEFAULT_ENVOY_SERVICE=$(kubectl get svc -n envoy-gateway-system --selector=gateway.envoyproxy.io/owning-gateway-namespace=default,gateway.envoyproxy.io/owning-gateway-name=eg -o jsonpath='{.items[0].metadata.name}') +``` + +Fetch external IP of the service: + +```shell +export DEFAULT_GATEWAY_HOST=$(kubectl get svc/${DEFAULT_ENVOY_SERVICE} -n envoy-gateway-system -o jsonpath='{.status.loadBalancer.ingress[0].ip}') +``` + +Curl the route Quickstart backend route through Envoy proxy: + +```shell +curl --header "Host: www.example.com" http://$DEFAULT_GATEWAY_HOST +``` + +```shell +{ + "path": "/", + "host": "www.example.com", + "method": "GET", + "proto": "HTTP/1.1", + "headers": { + "Accept": [ + "*/*" + ], + "User-Agent": [ + "curl/8.4.0" + ], + "X-Envoy-Internal": [ + "true" + ], + "X-Forwarded-For": [ + "172.18.0.2" + ], + "X-Forwarded-Proto": [ + "http" + ], + "X-Request-Id": [ + "70a40595-67a1-4776-955b-2dee361baed7" + ] + }, + "namespace": "default", + "ingress": "", + "service": "", + "pod": "backend-96f75bbf-6w67z" +} +``` + +Curl the route hostname-route3 through Envoy proxy: + +```shell +curl --header "Host: www.merged3.com" http://$GATEWAY_HOST:8082/example3 +``` + +```shell +{ + "path": "/example3", + "host": "www.merged3.com", + "method": "GET", + "proto": "HTTP/1.1", + "headers": { + "Accept": [ + "*/*" + ], + "User-Agent": [ + "curl/8.4.0" + ], + "X-Envoy-Internal": [ + "true" + ], + "X-Forwarded-For": [ + "172.18.0.2" + ], + "X-Forwarded-Proto": [ + "http" + ], + "X-Request-Id": [ + "47aeaef3-abb5-481a-ab92-c2ae3d0862d6" + ] + }, + "namespace": "default", + "ingress": "", + "service": "", + "pod": "merged-backend-64ddb65fd7-k84gv" +} +``` + +[Quickstart]: quickstart.md +[EnvoyProxy]: ../../../api/extension_types#envoyproxy +[GatewayClass]: https://gateway-api.sigs.k8s.io/api-types/gatewayclass/ +[Namespaced deployment mode]: ../../../api/extension_types#kuberneteswatchmode +[issue1231]: https://github.com/envoyproxy/gateway/issues/1231 +[issue1117]: https://github.com/envoyproxy/gateway/issues/1117 diff --git a/site/content/en/v1.0.0/user/operations/egctl.md b/site/content/en/v1.0.0/user/operations/egctl.md new file mode 100644 index 00000000000..75855ad68d9 --- /dev/null +++ b/site/content/en/v1.0.0/user/operations/egctl.md @@ -0,0 +1,862 @@ +--- +title: "Use egctl" +--- + +`egctl` is a command line tool to provide additional functionality for Envoy Gateway users. + + + +## egctl experimental translate + +This subcommand allows users to translate from an input configuration type to an output configuration type. + +The `translate` subcommand can translate Kubernetes resources to: +* Gateway API resources + This is useful in order to see how validation would occur if these resources were applied to Kubernetes. + + Use the `--to gateway-api` parameter to translate to Gateway API resources. + +* Envoy Gateway intermediate representation (IR) + This represents Envoy Gateway's translation of the Gateway API resources. + + Use the `--to ir` parameter to translate to Envoy Gateway intermediate representation. + +* Envoy Proxy xDS + This is the xDS configuration provided to Envoy Proxy. + + Use the `--to xds` parameter to translate to Envoy Proxy xDS. + + +In the below example, we will translate the Kubernetes resources (including the Gateway API resources) into xDS +resources. + +```shell +cat < GET / HTTP/2 +> Host: www.example.com +> User-Agent: curl/8.6.0 +> Accept: */* +... +< HTTP/2 401 +< content-length: 58 +< content-type: text/plain +< date: Wed, 06 Mar 2024 15:59:36 GMT +< + +* Connection #0 to host 127.0.0.1 left intact +User authentication failed. Missing username and password. +``` + +Send a request to the backend service with `Authentication` header: + +```shell +curl -kv -H "Host: www.example.com" -u 'foo:bar' "https://${GATEWAY_HOST}/" +``` + +The request should be allowed and you should see the response from the backend service. + +```shell + +## Clean-Up + +Follow the steps from the [Quickstart](../../quickstart) guide to uninstall Envoy Gateway and the example manifest. + +Delete the SecurityPolicy and the secret + +```shell +kubectl delete securitypolicy/basic-auth-example +kubectl delete secret/basic-auth +kubectl delete secret/example-cert +``` + +## Next Steps + +Checkout the [Developer Guide](../../../contributions/develop/) to get involved in the project. + +[SecurityPolicy]: ../../contributions/design/security-policy/ +[http Basic authentication]: https://tools.ietf.org/html/rfc2617 +[Gateway]: https://gateway-api.sigs.k8s.io/api-types/gateway +[HTTPRoute]: https://gateway-api.sigs.k8s.io/api-types/httproute +[GRPCRoute]: https://gateway-api.sigs.k8s.io/api-types/grpcroute +[.htpasswd]: https://httpd.apache.org/docs/current/programs/htpasswd.html diff --git a/site/content/en/v1.0.0/user/security/cors.md b/site/content/en/v1.0.0/user/security/cors.md new file mode 100644 index 00000000000..dea4f04361d --- /dev/null +++ b/site/content/en/v1.0.0/user/security/cors.md @@ -0,0 +1,141 @@ +--- +title: "CORS" +--- + +This guide provides instructions for configuring [Cross-Origin Resource Sharing (CORS)][cors] on Envoy Gateway. +CORS defines a way for client web applications that are loaded in one domain to interact with resources in a different +domain. + +Envoy Gateway introduces a new CRD called [SecurityPolicy][SecurityPolicy] that allows the user to configure CORS. +This instantiated resource can be linked to a [Gateway][Gateway], [HTTPRoute][HTTPRoute] or [GRPCRoute][GRPCRoute] resource. + +## Prerequisites + +Follow the steps from the [Quickstart](../../quickstart) guide to install Envoy Gateway and the example manifest. +Before proceeding, you should be able to query the example backend using HTTP. + +## Configuration + +When configuring CORS either an origin with a precise hostname can be configured or an hostname containing a wildcard prefix, +allowing all subdomains of the specified hostname. +In addition to that the entire origin (with or without specifying a scheme) can be a wildcard to allow all origins. + +The below example defines a SecurityPolicy that allows CORS for all HTTP requests originating from `www.foo.com`. + +```shell +cat < /dev/null +``` + +You should see the below response, indicating that the request from `http://www.foo.com` is allowed: + +```shell +< access-control-allow-origin: http://www.foo.com +< access-control-allow-methods: GET, POST +< access-control-allow-headers: x-header-1, x-header-2 +< access-control-max-age: 86400 +< access-control-expose-headers: x-header-3, x-header-4 +``` + +If you try to send a request from `http://www.bar.com`, you should see the below response: + +```shell +curl -H "Origin: http://www.bar.com" \ + -H "Host: www.example.com" \ + -H "Access-Control-Request-Method: GET" \ + -X OPTIONS -v -s \ + http://$GATEWAY_HOST \ + 1> /dev/null +``` + +You won't see any CORS headers in the response, indicating that the request from `http://www.bar.com` was not allowed. + +If you try to send a request from `http://www.foo.com:8080`, you should also see similar response because the port number +`8080` is not included in the allowed origins. + +```shell +```shell +curl -H "Origin: http://www.foo.com:8080" \ + -H "Host: www.example.com" \ + -H "Access-Control-Request-Method: GET" \ + -X OPTIONS -v -s \ + http://$GATEWAY_HOST \ + 1> /dev/null +``` + +Note: +* CORS specification requires that the browsers to send a preflight request to the server to ask if it's allowed +to access the limited resource in another domains. The browsers are supposed to follow the response from the server to +determine whether to send the actual request or not. The CORS filter only response to the preflight requests according to +its configuration. It won't deny any requests. The browsers are responsible for enforcing the CORS policy. +* The targeted HTTPRoute or the HTTPRoutes that the targeted Gateway routes to must allow the OPTIONS method for the CORS +filter to work. Otherwise, the OPTIONS request won't match the routes and the CORS filter won't be invoked. + + +## Clean-Up + +Follow the steps from the [Quickstart](../../quickstart) guide to uninstall Envoy Gateway and the example manifest. + +Delete the SecurityPolicy: + +```shell +kubectl delete securitypolicy/cors-example +``` + +## Next Steps + +Checkout the [Developer Guide](../../../contributions/develop/) to get involved in the project. + +[SecurityPolicy]: ../../contributions/design/security-policy/ +[cors]: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS +[Gateway]: https://gateway-api.sigs.k8s.io/api-types/gateway +[HTTPRoute]: https://gateway-api.sigs.k8s.io/api-types/httproute +[GRPCRoute]: https://gateway-api.sigs.k8s.io/api-types/grpcroute diff --git a/site/content/en/v1.0.0/user/security/ext-auth.md b/site/content/en/v1.0.0/user/security/ext-auth.md new file mode 100644 index 00000000000..efcd8b62467 --- /dev/null +++ b/site/content/en/v1.0.0/user/security/ext-auth.md @@ -0,0 +1,311 @@ +--- +title: "External Authorization" +--- + +This guide provides instructions for configuring external authentication. + +External authorization calls an external HTTP or gRPC service to check whether an incoming HTTP request is authorized +or not. If the request is deemed unauthorized, then the request will be denied with a 403 (Forbidden) response. If the +request is authorized, then the request will be allowed to proceed to the backend service. + +Envoy Gateway introduces a new CRD called [SecurityPolicy][SecurityPolicy] that allows the user to configure external authorization. +This instantiated resource can be linked to a [Gateway][Gateway] and [HTTPRoute][HTTPRoute] resource. + +## Prerequisites + +Follow the steps from the [Quickstart](../../quickstart) guide to install Envoy Gateway and the example manifest. +Before proceeding, you should be able to query the example backend using HTTP. + +Verify the Gateway status: + +```shell +kubectl get gateway/eg -o yaml +``` + +## HTTP External Authorization Service + +### Installation + +Install a demo HTTP service that will be used as the external authorization service: + +```shell +kubectl apply -f https://raw.githubusercontent.com/envoyproxy/gateway/latest/examples/kubernetes/ext-auth-http-service.yaml +``` + +Create a new HTTPRoute resource to route traffic on the path `/myapp` to the backend service. + +```shell +cat < GET /myapp HTTP/1.1 +> Host: www.example.com +> User-Agent: curl/7.68.0 +> Accept: */* +... +< HTTP/1.1 403 Forbidden +< date: Mon, 11 Mar 2024 03:41:15 GMT +< x-envoy-upstream-service-time: 0 +< content-length: 0 +< +* Connection #0 to host 172.18.255.200 left intact +``` + +Send a request to the backend service with `Authentication` header: + +```shell +curl -v -H "Host: www.example.com" -H "Authorization: Bearer token1" "http://${GATEWAY_HOST}/myapp" +``` + +The request should be allowed and you should see the response from the backend service. +Because the `x-current-user` header from the auth response has been sent to the backend service, +you should see the `x-current-user` header in the response. + +``` +"X-Current-User": [ + "user1" + ], +``` + +## GRPC External Authorization Service + +### Installation + +Install a demo gRPC service that will be used as the external authorization service. The demo gRPC service is enabled +with TLS and a BackendTLSConfig is created to configure the communication between the Envoy proxy and the gRPC service. + +Note: TLS is optional for HTTP or gRPC external authorization services. However, enabling TLS is recommended for enhanced +security in production environments. + +```shell +kubectl apply -f https://raw.githubusercontent.com/envoyproxy/gateway/latest/examples/kubernetes/ext-auth-grpc-service.yaml +``` + +The HTTPRoute created in the previous section is still valid and can be used with the gRPC auth service, but if you have +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. + +```shell +cat < GET /myapp HTTP/1.1 +> Host: www.example.com +> User-Agent: curl/7.68.0 +> Accept: */* +... +< HTTP/1.1 403 Forbidden +< date: Mon, 11 Mar 2024 03:41:15 GMT +< x-envoy-upstream-service-time: 0 +< content-length: 0 +< +* Connection #0 to host 172.18.255.200 left intact +``` + +Send a request to the backend service with `Authentication` header: + +```shell +curl -v -H "Host: www.example.com" -H "Authorization: Bearer token1" "http://${GATEWAY_HOST}/myapp" +``` + +## Clean-Up + +Follow the steps from the [Quickstart](../../quickstart) guide to uninstall Envoy Gateway and the example manifest. + +Delete the demo auth services, HTTPRoute, SecurityPolicy and BackendTLSPolicy: + +```shell +kubectl delete -f https://raw.githubusercontent.com/envoyproxy/gateway/latest/examples/kubernetes/ext-auth-http-service.yaml +kubectl delete -f https://raw.githubusercontent.com/envoyproxy/gateway/latest/examples/kubernetes/ext-auth-grpc-service.yaml +kubectl delete httproute/myapp +kubectl delete securitypolicy/ext-auth-example +kubectl delete backendtlspolicy/grpc-ext-auth-btls +``` + +## Next Steps + +Checkout the [Developer Guide](../../../contributions/develop/) to get involved in the project. + +[SecurityPolicy]: ../../contributions/design/security-policy/ +[Gateway]: https://gateway-api.sigs.k8s.io/api-types/gateway +[HTTPRoute]: https://gateway-api.sigs.k8s.io/api-types/httproute diff --git a/site/content/en/v1.0.0/user/security/jwt-authentication.md b/site/content/en/v1.0.0/user/security/jwt-authentication.md new file mode 100644 index 00000000000..ad2ef5ab092 --- /dev/null +++ b/site/content/en/v1.0.0/user/security/jwt-authentication.md @@ -0,0 +1,170 @@ +--- +title: "JWT Authentication" +--- + +This guide provides instructions for configuring [JSON Web Token (JWT)][jwt] authentication. JWT authentication checks +if an incoming request has a valid JWT before routing the request to a backend service. Currently, Envoy Gateway only +supports validating a JWT from an HTTP header, e.g. `Authorization: Bearer `. + +Envoy Gateway introduces a new CRD called [SecurityPolicy][SecurityPolicy] that allows the user to configure JWT authentication. +This instantiated resource can be linked to a [Gateway][Gateway], [HTTPRoute][HTTPRoute] or [GRPCRoute][GRPCRoute] resource. + +## Prerequisites + +Follow the steps from the [Quickstart](../../quickstart) guide to install Envoy Gateway and the example manifest. +For GRPC - follow the steps from the [GRPC Routing](../grpc-routing) example. +Before proceeding, you should be able to query the example backend using HTTP or GRPC. + +## Configuration + +Allow requests with a valid JWT by creating an [SecurityPolicy][SecurityPolicy] and attaching it to the example +HTTPRoute or GRPCRoute. + +### HTTPRoute + +```shell +kubectl apply -f https://raw.githubusercontent.com/envoyproxy/gateway/latest/examples/kubernetes/jwt/jwt.yaml +``` + +Two HTTPRoute has been created, one for `/foo` and another for `/bar`. A SecurityPolicy has been created and targeted +HTTPRoute foo to authenticate requests for `/foo`. The HTTPRoute bar is not targeted by the SecurityPolicy and will allow +unauthenticated requests to `/bar`. + +Verify the HTTPRoute configuration and status: + +```shell +kubectl get httproute/foo -o yaml +kubectl get httproute/bar -o yaml +``` + +The SecurityPolicy is configured for JWT authentication and uses a single [JSON Web Key Set (JWKS)][jwks] +provider for authenticating the JWT. + +Verify the SecurityPolicy configuration: + +```shell +kubectl get securitypolicy/jwt-example -o yaml +``` + +### GRPCRoute + +```shell +kubectl apply -f https://raw.githubusercontent.com/envoyproxy/gateway/latest/examples/kubernetes/jwt/grpc-jwt.yaml +``` + +A SecurityPolicy has been created and targeted GRPCRoute yages to authenticate all requests for `yages` service.. + +Verify the GRPCRoute configuration and status: + +```shell +kubectl get grpcroute/yages -o yaml +``` + +The SecurityPolicy is configured for JWT authentication and uses a single [JSON Web Key Set (JWKS)][jwks] +provider for authenticating the JWT. + +Verify the SecurityPolicy configuration: + +```shell +kubectl get securitypolicy/jwt-example -o yaml +``` + +## Testing + +Ensure the `GATEWAY_HOST` environment variable from the [Quickstart](../../quickstart) guide is set. If not, follow the +Quickstart instructions to set the variable. + +```shell +echo $GATEWAY_HOST +``` + +### HTTPRoute + +Verify that requests to `/foo` are denied without a JWT: + +```shell +curl -sS -o /dev/null -H "Host: www.example.com" -w "%{http_code}\n" http://$GATEWAY_HOST/foo +``` + +A `401` HTTP response code should be returned. + +Get the JWT used for testing request authentication: + +```shell +TOKEN=$(curl https://raw.githubusercontent.com/envoyproxy/gateway/main/examples/kubernetes/jwt/test.jwt -s) && echo "$TOKEN" | cut -d '.' -f2 - | base64 --decode - +``` + +__Note:__ The above command decodes and returns the token's payload. You can replace `f2` with `f1` to view the token's +header. + +Verify that a request to `/foo` with a valid JWT is allowed: + +```shell +curl -sS -o /dev/null -H "Host: www.example.com" -H "Authorization: Bearer $TOKEN" -w "%{http_code}\n" http://$GATEWAY_HOST/foo +``` + +A `200` HTTP response code should be returned. + +Verify that requests to `/bar` are allowed __without__ a JWT: + +```shell +curl -sS -o /dev/null -H "Host: www.example.com" -w "%{http_code}\n" http://$GATEWAY_HOST/bar +``` + +### GRPCRoute + +Verify that requests to `yages`service are denied without a JWT: + +```shell +grpcurl -plaintext -authority=grpc-example.com ${GATEWAY_HOST}:80 yages.Echo/Ping +``` + +You should see the below response + +```shell +Error invoking method "yages.Echo/Ping": rpc error: code = Unauthenticated desc = failed to query for service descriptor "yages.Echo": Jwt is missing +``` + +Get the JWT used for testing request authentication: + +```shell +TOKEN=$(curl https://raw.githubusercontent.com/envoyproxy/gateway/main/examples/kubernetes/jwt/test.jwt -s) && echo "$TOKEN" | cut -d '.' -f2 - | base64 --decode - +``` + +__Note:__ The above command decodes and returns the token's payload. You can replace `f2` with `f1` to view the token's +header. + +Verify that a request to `yages` service with a valid JWT is allowed: + +```shell +grpcurl -plaintext -H "authorization: Bearer $TOKEN" -authority=grpc-example.com ${GATEWAY_HOST}:80 yages.Echo/Ping +``` + +You should see the below response + +```shell +{ + "text": "pong" +} +``` + +## Clean-Up + +Follow the steps from the [Quickstart](../../quickstart) guide to uninstall Envoy Gateway and the example manifest. + +Delete the SecurityPolicy: + +```shell +kubectl delete securitypolicy/jwt-example +``` + +## Next Steps + +Checkout the [Developer Guide](../../../contributions/develop/) to get involved in the project. + +[SecurityPolicy]: ../../contributions/design/security-policy/ +[jwt]: https://tools.ietf.org/html/rfc7519 +[jwks]: https://tools.ietf.org/html/rfc7517 +[Gateway]: https://gateway-api.sigs.k8s.io/api-types/gateway +[HTTPRoute]: https://gateway-api.sigs.k8s.io/api-types/httproute +[GRPCRoute]: https://gateway-api.sigs.k8s.io/api-types/grpcroute diff --git a/site/content/en/v1.0.0/user/security/mutual-tls.md b/site/content/en/v1.0.0/user/security/mutual-tls.md new file mode 100644 index 00000000000..e24562ca45e --- /dev/null +++ b/site/content/en/v1.0.0/user/security/mutual-tls.md @@ -0,0 +1,153 @@ +--- +title: "Mutual TLS: External Clients to the Gateway" +--- + +This guide demonstrates how mutual TLS can be achieved between external clients and the Gateway. The guide uses a self-signed CA, so it should be used for +testing and demonstration purposes only. + +## Prerequisites + +- OpenSSL to generate TLS assets. + +## Installation + +Follow the steps from the [Quickstart Guide](../../quickstart) to install Envoy Gateway and the example manifest. +Before proceeding, you should be able to query the example backend using HTTP. + +## TLS Certificates + +Generate the certificates and keys used by the Gateway to terminate client TLS connections. + +Create a root certificate and private key to sign certificates: + +```shell +openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -subj '/O=example Inc./CN=example.com' -keyout example.com.key -out example.com.crt +``` + +Create a certificate and a private key for `www.example.com`: + +```shell +openssl req -out www.example.com.csr -newkey rsa:2048 -nodes -keyout www.example.com.key -subj "/CN=www.example.com/O=example organization" +openssl x509 -req -days 365 -CA example.com.crt -CAkey example.com.key -set_serial 0 -in www.example.com.csr -out www.example.com.crt +``` + +Store the cert/key in a Secret: + +```shell +kubectl create secret tls example-cert --key=www.example.com.key --cert=www.example.com.crt --certificate-authority=example.com.crt +``` + +Store the CA Cert in another Secret: + +```shell +kubectl create secret generic example-ca-cert --from-file=ca.crt=example.com.crt +``` + +Create a certificate and a private key for the client `client.example.com`: + +```shell +openssl req -out client.example.com.csr -newkey rsa:2048 -nodes -keyout client.example.com.key -subj "/CN=client.example.com/O=example organization" +openssl x509 -req -days 365 -CA example.com.crt -CAkey example.com.key -set_serial 0 -in client.example.com.csr -out client.example.com.crt +``` + +Update the Gateway from the Quickstart guide to include an HTTPS listener that listens on port `443` and references the +`example-cert` Secret: + +```shell +kubectl patch gateway eg --type=json --patch '[{ + "op": "add", + "path": "/spec/listeners/-", + "value": { + "name": "https", + "protocol": "HTTPS", + "port": 443, + "tls": { + "mode": "Terminate", + "certificateRefs": [{ + "kind": "Secret", + "group": "", + "name": "example-cert", + }], + }, + }, +}]' +``` + +Verify the Gateway status: + +```shell +kubectl get gateway/eg -o yaml +``` + +Create a [ClientTrafficPolicy][] to enforce client validation using the CA Certificate as a trusted anchor. + +```shell +cat < GET /get HTTP/1.1 +> Host: www.example.com +> User-Agent: curl/8.1.2 +> Accept: */* +> +< HTTP/1.1 200 OK +< content-type: application/json +< x-content-type-options: nosniff +< date: Fri, 01 Dec 2023 10:17:04 GMT +< content-length: 507 +< x-envoy-upstream-service-time: 0 +< server: envoy +< +{ + "path": "/get", + "host": "www.example.com", + "method": "GET", + "proto": "HTTP/1.1", + "headers": { + "Accept": [ + "*/*" + ], + "User-Agent": [ + "curl/8.1.2" + ], + "X-Envoy-Expected-Rq-Timeout-Ms": [ + "15000" + ], + "X-Envoy-Internal": [ + "true" + ], + "X-Forwarded-For": [ + "172.18.0.2" + ], + "X-Forwarded-Proto": [ + "http" + ], + "X-Request-Id": [ + "4d0d33e8-d611-41f0-9da0-6458eec20fa5" + ] + }, + "namespace": "default", + "ingress": "", + "service": "", + "pod": "backend-58d58f745-2zwvn" +* Connection #0 to host 172.18.255.202 left intact +}* Found bundle for host: 0x7fb9f5204ea0 [serially] +* Can not multiplex, even if we wanted to +* Re-using existing connection #0 with host 172.18.255.202 +> GET /headers HTTP/1.1 +> Host: www.example.com +> User-Agent: curl/8.1.2 +> Accept: */* +> +< HTTP/1.1 200 OK +< content-type: application/json +< x-content-type-options: nosniff +< date: Fri, 01 Dec 2023 10:17:04 GMT +< content-length: 511 +< x-envoy-upstream-service-time: 0 +< server: envoy +< +{ + "path": "/headers", + "host": "www.example.com", + "method": "GET", + "proto": "HTTP/1.1", + "headers": { + "Accept": [ + "*/*" + ], + "User-Agent": [ + "curl/8.1.2" + ], + "X-Envoy-Expected-Rq-Timeout-Ms": [ + "15000" + ], + "X-Envoy-Internal": [ + "true" + ], + "X-Forwarded-For": [ + "172.18.0.2" + ], + "X-Forwarded-Proto": [ + "http" + ], + "X-Request-Id": [ + "9a8874c0-c117-481c-9b04-933571732ca5" + ] + }, + "namespace": "default", + "ingress": "", + "service": "", + "pod": "backend-58d58f745-2zwvn" +* Connection #0 to host 172.18.255.202 left intact +} +``` + +You can see keepalive connection marked by the output in: + +```shell +* Connection #0 to host 172.18.255.202 left intact +* Re-using existing connection #0 with host 172.18.255.202 +``` + +### Enable Proxy Protocol for downstream client + +This example configures Proxy Protocol for downstream clients. + +```shell +cat < GET /get HTTP/1.1 +> Host: www.example.com +> User-Agent: curl/8.1.2 +> Accept: */* +> +* Recv failure: Connection reset by peer +* Closing connection 0 +curl: (56) Recv failure: Connection reset by peer +``` + +Curl the example app through Envoy proxy once again, now sending HAProxy PROXY protocol header at the beginning of the connection with --haproxy-protocol flag: + +```shell +curl --verbose --haproxy-protocol --header "Host: www.example.com" http://$GATEWAY_HOST/get +``` + +You should now expect 200 response status and also see that source IP was preserved in the X-Forwarded-For header. + +```shell +* Trying 172.18.255.202:80... +* Connected to 172.18.255.202 (172.18.255.202) port 80 (#0) +> GET /get HTTP/1.1 +> Host: www.example.com +> User-Agent: curl/8.1.2 +> Accept: */* +> +< HTTP/1.1 200 OK +< content-type: application/json +< x-content-type-options: nosniff +< date: Mon, 04 Dec 2023 21:11:43 GMT +< content-length: 510 +< x-envoy-upstream-service-time: 0 +< server: envoy +< +{ + "path": "/get", + "host": "www.example.com", + "method": "GET", + "proto": "HTTP/1.1", + "headers": { + "Accept": [ + "*/*" + ], + "User-Agent": [ + "curl/8.1.2" + ], + "X-Envoy-Expected-Rq-Timeout-Ms": [ + "15000" + ], + "X-Envoy-Internal": [ + "true" + ], + "X-Forwarded-For": [ + "192.168.255.6" + ], + "X-Forwarded-Proto": [ + "http" + ], + "X-Request-Id": [ + "290e4b61-44b7-4e5c-a39c-0ec76784e897" + ] + }, + "namespace": "default", + "ingress": "", + "service": "", + "pod": "backend-58d58f745-2zwvn" +* Connection #0 to host 172.18.255.202 left intact +} +``` + +### Configure Client IP Detection + +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. + +```shell +cat < GET /get HTTP/1.1 +> Host: www.example.com +> User-Agent: curl/8.4.0 +> Accept: */* +> X-Forwarded-Proto: https +> X-Forwarded-For: 1.1.1.1,2.2.2.2 +> +Handling connection for 8888 +< HTTP/1.1 200 OK +< content-type: application/json +< x-content-type-options: nosniff +< date: Tue, 30 Jan 2024 15:19:22 GMT +< content-length: 535 +< x-envoy-upstream-service-time: 0 +< server: envoy +< +{ + "path": "/get", + "host": "www.example.com", + "method": "GET", + "proto": "HTTP/1.1", + "headers": { + "Accept": [ + "*/*" + ], + "User-Agent": [ + "curl/8.4.0" + ], + "X-Envoy-Expected-Rq-Timeout-Ms": [ + "15000" + ], + "X-Envoy-External-Address": [ + "1.1.1.1" + ], + "X-Forwarded-For": [ + "1.1.1.1,2.2.2.2,10.244.0.9" + ], + "X-Forwarded-Proto": [ + "https" + ], + "X-Request-Id": [ + "53ccfad7-1899-40fa-9322-ddb833aa1ac3" + ] + }, + "namespace": "default", + "ingress": "", + "service": "", + "pod": "backend-58d58f745-8psnc" +* Connection #0 to host localhost left intact +} +``` + +### Enable HTTP Request Received Timeout + +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). + +```shell +cat < GET /get HTTP/1.1 +> Host: www.example.com +> User-Agent: curl/8.4.0 +> Accept: */* +> Content-Length: 10000 +> +< HTTP/1.1 408 Request Timeout +< content-length: 15 +< content-type: text/plain +< date: Tue, 27 Feb 2024 07:38:27 GMT +< connection: close +< +* Closing connection +request timeout +``` + +[ClientTrafficPolicy]: ../../../api/extension_types#clienttrafficpolicy +[BackendTrafficPolicy]: ../../../api/extension_types#backendtrafficpolicy diff --git a/site/content/en/v1.0.0/user/traffic/fault-injection.md b/site/content/en/v1.0.0/user/traffic/fault-injection.md new file mode 100644 index 00000000000..c033d12aed3 --- /dev/null +++ b/site/content/en/v1.0.0/user/traffic/fault-injection.md @@ -0,0 +1,254 @@ +--- +title: "Fault Injection" +--- + +[Envoy fault injection] can be used to inject delays and abort requests to mimic failure scenarios such as service failures and overloads. + +Envoy Gateway supports the following fault scenarios: +- **delay fault**: inject a custom fixed delay into the request with a certain probability to simulate delay failures. +- **abort fault**: inject a custom response code into the response with a certain probability to simulate abort failures. + +Envoy Gateway introduces a new CRD called [BackendTrafficPolicy][] that allows the user to describe their desired fault scenarios. +This instantiated resource can be linked to a [Gateway][], [HTTPRoute][] or [GRPCRoute][] resource. + +## Prerequisites + +Follow the steps from the [Quickstart](../../quickstart) guide to install Envoy Gateway and the example manifest. +For GRPC - follow the steps from the [GRPC Routing](../grpc-routing) example. +Before proceeding, you should be able to query the example backend using HTTP or GRPC. + +### Install the hey load testing tool +* The `hey` CLI will be used to generate load and measure response times. Follow the installation instruction from the [Hey project] docs. + +## Configuration + +Allow requests with a valid faultInjection by creating an [BackendTrafficPolicy][BackendTrafficPolicy] and attaching it to the example HTTPRoute or GRPCRoute. + +### HTTPRoute + +```shell +cat < 18000/TCP 15m +envoy-gateway-metrics-service ClusterIP 10.96.124.73 8443/TCP 15m +``` + +__Note:__ If the `Gateway.Spec.Addresses` is explicitly set, it will be the only addresses that populates the Gateway status. + +## Cluster IP + +Using the addresses in `Gateway.Spec.Addresses` as the [Cluster IP][] of Envoy Proxy Service, +this will __require__ the address to be of type `IPAddress` and the [ServiceType][] to be of `ClusterIP`. + + +[Addresses]: https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1.GatewayAddress +[External IPs]: https://kubernetes.io/docs/concepts/services-networking/service/#external-ips +[Cluster IP]: https://kubernetes.io/docs/concepts/services-networking/service/#type-clusterip +[ServiceType]: ../../../api/extension_types#servicetype diff --git a/site/content/en/v1.0.0/user/traffic/gatewayapi-support.md b/site/content/en/v1.0.0/user/traffic/gatewayapi-support.md new file mode 100644 index 00000000000..66a32b11ea1 --- /dev/null +++ b/site/content/en/v1.0.0/user/traffic/gatewayapi-support.md @@ -0,0 +1,119 @@ +--- +title: "Gateway API Support" +--- + +As mentioned in the [system design][] document, Envoy Gateway's managed data plane is configured dynamically through +Kubernetes resources, primarily [Gateway API][] objects. Envoy Gateway supports configuration using the following Gateway API resources. + +## GatewayClass + +A [GatewayClass][] represents a "class" of gateways, i.e. which Gateways should be managed by Envoy Gateway. +Envoy Gateway supports managing __a single__ GatewayClass resource that matches its configured `controllerName` and +follows Gateway API guidelines for [resolving conflicts][] when multiple GatewayClasses exist with a matching +`controllerName`. + +__Note:__ If specifying GatewayClass [parameters reference][], it must refer to an [EnvoyProxy][] resource. + +## Gateway + +When a [Gateway][] resource is created that references the managed GatewayClass, Envoy Gateway will create and manage a +new Envoy Proxy deployment. Gateway API resources that reference this Gateway will configure this managed Envoy Proxy +deployment. + +## HTTPRoute + +A [HTTPRoute][] configures routing of HTTP traffic through one or more Gateways. The following HTTPRoute filters are +supported by Envoy Gateway: + +- `requestHeaderModifier`: [RequestHeaderModifiers][http-filter] + can be used to modify or add request headers before the request is proxied to its destination. +- `responseHeaderModifier`: [ResponseHeaderModifiers][http-filter] + can be used to modify or add response headers before the response is sent back to the client. +- `requestMirror`: [RequestMirrors][http-filter] + configure destinations where the requests should also be mirrored to. Responses to mirrored requests will be ignored. +- `requestRedirect`: [RequestRedirects][http-filter] + configure policied for how requests that match the HTTPRoute should be modified and then redirected. +- `urlRewrite`: [UrlRewrites][http-filter] + allow for modification of the request's hostname and path before it is proxied to its destination. +- `extensionRef`: [ExtensionRefs][] are used by Envoy Gateway to implement extended filters. Currently, Envoy Gateway + supports rate limiting and request authentication filters. For more information about these filters, refer to the + [rate limiting][] and [request authentication][] documentation. + +__Notes:__ +- The only [BackendRef][] kind supported by Envoy Gateway is a [Service][]. Routing traffic to other destinations such + as arbitrary URLs is not possible. +- The `filters` field within [HTTPBackendRef][] is not supported. + +## TCPRoute + +A [TCPRoute][] configures routing of raw TCP traffic through one or more Gateways. Traffic can be forwarded to the +desired BackendRefs based on a TCP port number. + +__Note:__ A TCPRoute only supports proxying in non-transparent mode, i.e. the backend will see the source IP and port of +the Envoy Proxy instance instead of the client. + +## UDPRoute + +A [UDPRoute][] configures routing of raw UDP traffic through one or more Gateways. Traffic can be forwarded to the +desired BackendRefs based on a UDP port number. + +__Note:__ Similar to TCPRoutes, UDPRoutes only support proxying in non-transparent mode i.e. the backend will see the +source IP and port of the Envoy Proxy instance instead of the client. + +## GRPCRoute + +A [GRPCRoute][] configures routing of [gRPC][] requests through one or more Gateways. They offer request matching by +hostname, gRPC service, gRPC method, or HTTP/2 Header. Envoy Gateway supports the following filters on GRPCRoutes to +provide additional traffic processing: + +- `requestHeaderModifier`: [RequestHeaderModifiers][grpc-filter] + can be used to modify or add request headers before the request is proxied to its destination. +- `responseHeaderModifier`: [ResponseHeaderModifiers][grpc-filter] + can be used to modify or add response headers before the response is sent back to the client. +- `requestMirror`: [RequestMirrors][grpc-filter] + configure destinations where the requests should also be mirrored to. Responses to mirrored requests will be ignored. + +__Notes:__ +- The only [BackendRef][grpc-filter] kind supported by Envoy Gateway is a [Service][]. Routing traffic to other + destinations such as arbitrary URLs is not currently possible. +- The `filters` field within [HTTPBackendRef][] is not supported. + +## TLSRoute + +A [TLSRoute][] configures routing of TCP traffic through one or more Gateways. However, unlike TCPRoutes, TLSRoutes +can match against TLS-specific metadata. + +## ReferenceGrant + +A [ReferenceGrant][] is used to allow a resource to reference another resource in a different namespace. Normally an +HTTPRoute created in namespace `foo` is not allowed to reference a Service in namespace `bar`. A ReferenceGrant permits +these types of cross-namespace references. Envoy Gateway supports the following ReferenceGrant use-cases: + +- Allowing an HTTPRoute, GRPCRoute, TLSRoute, UDPRoute, or TCPRoute to reference a Service in a different namespace. +- Allowing an HTTPRoute's `requestMirror` filter to include a BackendRef that references a Service in a different + namespace. +- Allowing a Gateway's [SecretObjectReference][] to reference a secret in a different namespace. + +[system design]: ../../contributions/design/system-design/ +[Gateway API]: https://gateway-api.sigs.k8s.io/ +[GatewayClass]: https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1.GatewayClass +[parameters reference]: https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1.ParametersReference +[Gateway]: https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1.Gateway +[HTTPRoute]: https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1.HTTPRoute +[Service]: https://kubernetes.io/docs/concepts/services-networking/service/ +[BackendRef]: https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1.BackendRef +[HTTPBackendRef]: https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1.HTTPBackendRef +[TCPRoute]: https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1alpha2.TCPRoute +[UDPRoute]: https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1alpha2.UDPRoute +[GRPCRoute]: https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1alpha2.GRPCRoute +[gRPC]: https://grpc.io/ +[TLSRoute]: https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1alpha2.TLSRoute +[ReferenceGrant]: https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1alpha2.ReferenceGrant +[SecretObjectReference]: https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1.SecretObjectReference +[rate limiting]: ../rate-limit/ +[request authentication]: ../jwt-authentication/ +[EnvoyProxy]: ../../../api/extension_types#envoyproxy +[resolving conflicts]: https://gateway-api.sigs.k8s.io/concepts/guidelines/?h=conflict#conflicts +[ExtensionRefs]: https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1.HTTPRouteFilterType +[grpc-filter]: https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1alpha2.GRPCRouteFilter +[http-filter]: https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1.HTTPRouteFilter diff --git a/site/content/en/v1.0.0/user/traffic/global-rate-limit.md b/site/content/en/v1.0.0/user/traffic/global-rate-limit.md new file mode 100644 index 00000000000..6a67a9573fe --- /dev/null +++ b/site/content/en/v1.0.0/user/traffic/global-rate-limit.md @@ -0,0 +1,833 @@ +--- +title: "Global Rate Limit" +--- + +Rate limit is a feature that allows the user to limit the number of incoming requests to a predefined value based on attributes within the traffic flow. + +Here are some reasons why you may want to implement Rate limits + +* To prevent malicious activity such as DDoS attacks. +* To prevent applications and its resources (such as a database) from getting overloaded. +* To create API limits based on user entitlements. + +Envoy Gateway supports two types of rate limiting: [Global rate limiting][] and [Local rate limiting][]. + +[Global rate limiting][] applies a shared rate limit to the traffic flowing through all the instances of Envoy proxies where it is configured. +i.e. if the data plane has 2 replicas of Envoy running, and the rate limit is 10 requests/second, this limit is shared and will be hit +if 5 requests pass through the first replica and 5 requests pass through the second replica within the same second. + +Envoy Gateway introduces a new CRD called [BackendTrafficPolicy][] that allows the user to describe their rate limit intent. This instantiated resource +can be linked to a [Gateway][], [HTTPRoute][] or [GRPCRoute][] resource. + +**Note:** Limit is applied per route. Even if a [BackendTrafficPolicy][] targets a gateway, each route in that gateway +still has a separate rate limit bucket. For example, if a gateway has 2 routes, and the limit is 100r/s, then each route +has its own 100r/s rate limit bucket. + +## Prerequisites + +### Install Envoy Gateway + +* Follow the steps from the [Quickstart Guide](../../quickstart) to install Envoy Gateway and the HTTPRoute example manifest. +Before proceeding, you should be able to query the example backend using HTTP. + +### Install Redis + +* 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. + +```shell +cat < HTTPS + +Listeners expose the TLS setting on a per domain or subdomain basis. TLS settings of a listener are applied to all domains that satisfy the hostname criteria. + +Create a root certificate and private key to sign certificates: + +```shell +openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -subj '/CN=example.com' -keyout CA.key -out CA.crt +openssl req -out example.com.csr -newkey rsa:2048 -nodes -keyout tls.key -subj "/CN=example.com" +``` + +Generate a self-signed wildcard certificate for `example.com` with `*.example.com` extension + +```shell +cat < GET /get HTTP/1.1 +> Host: headers.example +> User-Agent: curl/7.81.0 +> Accept: */* +> add-header: something +> +* Mark bundle as not supporting multiuse +< HTTP/1.1 200 OK +< content-type: application/json +< x-content-type-options: nosniff +< content-length: 474 +< x-envoy-upstream-service-time: 0 +< server: envoy +< +... + "headers": { + "Accept": [ + "*/*" + ], + "Add-Header": [ + "something", + "foo" + ], +... +``` + +## Setting Request Headers + +Setting headers is similar to adding headers. If the request does not have the header configured by the filter, then it +will be added, but unlike [adding request headers](#adding-request-headers) which will append the value of the header if +the request already contains it, setting a header will cause the value to be replaced by the value configured in the +filter. + +```shell +cat < GET /get HTTP/1.1 +> Host: headers.example +> User-Agent: curl/7.81.0 +> Accept: */* +> add-header: something +> +* Mark bundle as not supporting multiuse +< HTTP/1.1 200 OK +< content-type: application/json +< x-content-type-options: nosniff +< content-length: 474 +< x-envoy-upstream-service-time: 0 +< server: envoy +< + "headers": { + "Accept": [ + "*/*" + ], + "Set-Header": [ + "foo" + ], +... +``` + +## Removing Request Headers + +Headers can be removed from a request by simply supplying a list of header names. + +Setting headers is similar to adding headers. If the request does not have the header configured by the filter, then it +will be added, but unlike [adding request headers](#adding-request-headers) which will append the value of the header if +the request already contains it, setting a header will cause the value to be replaced by the value configured in the +filter. + +```shell +cat < GET /get HTTP/1.1 +> Host: headers.example +> User-Agent: curl/7.81.0 +> Accept: */* +> add-header: something +> +* Mark bundle as not supporting multiuse +< HTTP/1.1 200 OK +< content-type: application/json +< x-content-type-options: nosniff +< content-length: 474 +< x-envoy-upstream-service-time: 0 +< server: envoy +< + + "headers": { + "Accept": [ + "*/*" + ], + "Add-Header": [ + "something" + ], +... +``` + +## Combining Filters + +Headers can be added/set/removed in a single filter on the same HTTPRoute and they will all perform as expected + +```shell +cat < GET /get HTTP/1.1 +> Host: backends.example +> User-Agent: curl/7.81.0 +> Accept: */* +> add-header: something +> +* Mark bundle as not supporting multiuse +< HTTP/1.1 200 OK +< content-type: application/json +< x-content-type-options: nosniff +< content-length: 474 +< x-envoy-upstream-service-time: 0 +< server: envoy +< +... + "namespace": "default", + "ingress": "", + "service": "", + "pod": "backend-79665566f5-s589f" +... +``` + +Check the logs of the pods and you will see that the original deployment and the new deployment each got a request: + +```shell +$ kubectl logs deploy/backend && kubectl logs deploy/backend-2 +... +Starting server, listening on port 3000 (http) +Echoing back request made to /get to client (10.42.0.10:41566) +Starting server, listening on port 3000 (http) +Echoing back request made to /get to client (10.42.0.10:45096) +``` + +## Multiple BackendRefs + +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. + +```shell +cat < GET /get HTTP/1.1 +> Host: headers.example +> User-Agent: curl/7.81.0 +> Accept: */* +> X-Echo-Set-Header: X-Foo: value1 +> +* Mark bundle as not supporting multiuse +< HTTP/1.1 200 OK +< content-type: application/json +< x-content-type-options: nosniff +< content-length: 474 +< x-envoy-upstream-service-time: 0 +< server: envoy +< x-foo: value1 +< add-header: foo +< +... + "headers": { + "Accept": [ + "*/*" + ], + "X-Echo-Set-Header": [ + "X-Foo: value1" + ] +... +``` + +## Setting Response Headers + +Setting headers is similar to adding headers. If the response does not have the header configured by the filter, then it +will be added, but unlike [adding response headers](#adding-response-headers) which will append the value of the header +if the response already contains it, setting a header will cause the value to be replaced by the value configured in the +filter. + +```shell +cat < GET /get HTTP/1.1 +> Host: headers.example +> User-Agent: curl/7.81.0 +> Accept: */* +> X-Echo-Set-Header: set-header: value1 +> +* Mark bundle as not supporting multiuse +< HTTP/1.1 200 OK +< content-type: application/json +< x-content-type-options: nosniff +< content-length: 474 +< x-envoy-upstream-service-time: 0 +< server: envoy +< set-header: foo +< + "headers": { + "Accept": [ + "*/*" + ], + "X-Echo-Set-Header": [ + "set-header": value1" + ] +... +``` + +## Removing Response Headers + +Headers can be removed from a response by simply supplying a list of header names. + +Setting headers is similar to adding headers. If the response does not have the header configured by the filter, then it +will be added, but unlike [adding response headers](#adding-response-headers) which will append the value of the header +if the response already contains it, setting a header will cause the value to be replaced by the value configured in the +filter. + +```shell +cat < GET /get HTTP/1.1 +> Host: headers.example +> User-Agent: curl/7.81.0 +> Accept: */* +> X-Echo-Set-Header: remove-header: value1 +> +* Mark bundle as not supporting multiuse +< HTTP/1.1 200 OK +< content-type: application/json +< x-content-type-options: nosniff +< content-length: 474 +< x-envoy-upstream-service-time: 0 +< server: envoy +< + + "headers": { + "Accept": [ + "*/*" + ], + "X-Echo-Set-Header": [ + "remove-header": value1" + ] +... +``` + +## Combining Filters + +Headers can be added/set/removed in a single filter on the same HTTPRoute and they will all perform as expected + +```shell +cat <= BackendRequest duration + +## Installation + +Follow the steps from the [Quickstart Guide](../../quickstart) to install Envoy Gateway and the example manifest. +Before proceeding, you should be able to query the example backend using HTTP. + +## Verification + +backend has the ability to delay responses; we use it as the backend to control response time. + +### 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. + +```shell +cat < GET /?delay=3s HTTP/1.1 +> Host: timeout.example.com +> User-Agent: curl/8.6.0 +> Accept: */* +> + + +< HTTP/1.1 504 Gateway Timeout +< content-length: 24 +< content-type: text/plain +< date: Mon, 04 Mar 2024 02:35:03 GMT +< +* Connection #0 to host 127.0.0.1 left intact +upstream request timeout +``` + +[HTTPRouteTimeouts]: https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1.HTTPRouteTimeouts +[HTTPRouteRule]: https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1.HTTPRouteRule diff --git a/site/content/en/v1.0.0/user/traffic/http-traffic-splitting.md b/site/content/en/v1.0.0/user/traffic/http-traffic-splitting.md new file mode 100644 index 00000000000..ef240753ad8 --- /dev/null +++ b/site/content/en/v1.0.0/user/traffic/http-traffic-splitting.md @@ -0,0 +1,313 @@ +--- +title: "HTTPRoute Traffic Splitting" +--- + +The [HTTPRoute][] resource allows one or more [backendRefs][] to be provided. Requests will be routed to these upstreams +if they match the rules of the HTTPRoute. If an invalid backendRef is configured, then HTTP responses will be returned +with status code `500` for all requests that would have been sent to that backend. + +## Installation + +Follow the steps from the [Quickstart Guide](../../quickstart) to install Envoy Gateway and the example manifest. +Before proceeding, you should be able to query the example backend using HTTP. + +## Single backendRef + +When a single backendRef is configured in a HTTPRoute, it will receive 100% of the traffic. + +```shell +cat < GET /get HTTP/1.1 +> Host: backends.example +> User-Agent: curl/7.81.0 +> Accept: */* +> add-header: something +> +* Mark bundle as not supporting multiuse +< HTTP/1.1 200 OK +< content-type: application/json +< x-content-type-options: nosniff +< content-length: 474 +< x-envoy-upstream-service-time: 0 +< server: envoy +< +... + "namespace": "default", + "ingress": "", + "service": "", + "pod": "backend-79665566f5-s589f" +... +``` + +## Multiple backendRefs + +If multiple backendRefs are configured, then traffic will be split between the backendRefs equally unless a weight is +configured. + +First, create a second instance of the example app from the quickstart: + +```shell +cat < GET /get HTTP/1.1 +> Host: backends.example +> User-Agent: curl/7.81.0 +> Accept: */* +> add-header: something +> +* Mark bundle as not supporting multiuse +< HTTP/1.1 200 OK +< content-type: application/json +< x-content-type-options: nosniff +< content-length: 474 +< x-envoy-upstream-service-time: 0 +< server: envoy +< +... + "namespace": "default", + "ingress": "", + "service": "", + "pod": "backend-75bcd4c969-lsxpz" +... +``` + +## Weighted backendRefs + +If multiple backendRefs are configured and an un-even traffic split between the backends is desired, then the `weight` +field can be used to control the weight of requests to each backend. If weight is not configured for a backendRef it is +assumed to be `1`. + +The [weight field in a backendRef][backendRefs] controls the distribution of the traffic split. The proportion of +requests to a single backendRef is calculated by dividing its `weight` by the sum of all backendRef weights in the +HTTPRoute. The weight is not a percentage and the sum of all weights does not need to add up to 100. + +The HTTPRoute below will configure the gateway to send 80% of the traffic to the backend service, and 20% to the +backend-2 service. + +```shell +cat < GET /get HTTP/1.1 +> Host: backends.example +> User-Agent: curl/7.81.0 +> Accept: */* +> +* Mark bundle as not supporting multiuse +< HTTP/1.1 500 Internal Server Error +< server: envoy +< content-length: 0 +< +``` + +[HTTPRoute]: https://gateway-api.sigs.k8s.io/api-types/httproute/ +[backendRefs]: https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1.BackendRef diff --git a/site/content/en/v1.0.0/user/traffic/http-urlrewrite.md b/site/content/en/v1.0.0/user/traffic/http-urlrewrite.md new file mode 100644 index 00000000000..062f6086392 --- /dev/null +++ b/site/content/en/v1.0.0/user/traffic/http-urlrewrite.md @@ -0,0 +1,297 @@ +--- +title: "HTTP URL Rewrite" +--- + +[HTTPURLRewriteFilter][] defines a filter that modifies a request during forwarding. At most one of these filters may be +used on a Route rule. This MUST NOT be used on the same Route rule as a HTTPRequestRedirect filter. + +## Prerequisites + +Follow the steps from the [Quickstart Guide](../../quickstart) to install Envoy Gateway and the example manifest. +Before proceeding, you should be able to query the example backend using HTTP. + +## Rewrite URL Prefix Path + +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`. + +```shell +cat < GET /get/origin/path HTTP/1.1 +> Host: path.rewrite.example +> User-Agent: curl/7.85.0 +> Accept: */* +> + +< HTTP/1.1 200 OK +< content-type: application/json +< x-content-type-options: nosniff +< date: Wed, 21 Dec 2022 11:03:28 GMT +< content-length: 503 +< x-envoy-upstream-service-time: 0 +< server: envoy +< +{ + "path": "/replace/origin/path", + "host": "path.rewrite.example", + "method": "GET", + "proto": "HTTP/1.1", + "headers": { + "Accept": [ + "*/*" + ], + "User-Agent": [ + "curl/7.85.0" + ], + "X-Envoy-Expected-Rq-Timeout-Ms": [ + "15000" + ], + "X-Envoy-Original-Path": [ + "/get/origin/path" + ], + "X-Forwarded-Proto": [ + "http" + ], + "X-Request-Id": [ + "fd84b842-9937-4fb5-83c7-61470d854b90" + ] + }, + "namespace": "default", + "ingress": "", + "service": "", + "pod": "backend-6fdd4b9bd8-8vlc5" +... +``` + +You can see that the `X-Envoy-Original-Path` is `/get/origin/path`, but the actual path is `/replace/origin/path`. + +## Rewrite URL Full Path + +You can configure to rewrite the fullpath in the url like below. In this example, any request sent to +`http://${GATEWAY_HOST}/get/origin/path/xxxx` will be rewritten to +`http://${GATEWAY_HOST}/force/replace/fullpath`. + +```shell +cat < GET /get/origin/path/extra HTTP/1.1 +> Host: path.rewrite.example +> User-Agent: curl/7.85.0 +> Accept: */* +> +* Mark bundle as not supporting multiuse +< HTTP/1.1 200 OK +< content-type: application/json +< x-content-type-options: nosniff +< date: Wed, 21 Dec 2022 11:09:31 GMT +< content-length: 512 +< x-envoy-upstream-service-time: 0 +< server: envoy +< +{ + "path": "/force/replace/fullpath", + "host": "path.rewrite.example", + "method": "GET", + "proto": "HTTP/1.1", + "headers": { + "Accept": [ + "*/*" + ], + "User-Agent": [ + "curl/7.85.0" + ], + "X-Envoy-Expected-Rq-Timeout-Ms": [ + "15000" + ], + "X-Envoy-Original-Path": [ + "/get/origin/path/extra" + ], + "X-Forwarded-Proto": [ + "http" + ], + "X-Request-Id": [ + "8ab774d6-9ffa-4faa-abbb-f45b0db00895" + ] + }, + "namespace": "default", + "ingress": "", + "service": "", + "pod": "backend-6fdd4b9bd8-8vlc5" +... +``` + +You can see that the `X-Envoy-Original-Path` is `/get/origin/path/extra`, but the actual path is +`/force/replace/fullpath`. + +## Rewrite Host Name + +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`. + +```shell +cat < GET /get HTTP/1.1 +> Host: path.rewrite.example +> User-Agent: curl/7.85.0 +> Accept: */* +> +* Mark bundle as not supporting multiuse +< HTTP/1.1 200 OK +< content-type: application/json +< x-content-type-options: nosniff +< date: Wed, 21 Dec 2022 11:15:15 GMT +< content-length: 481 +< x-envoy-upstream-service-time: 0 +< server: envoy +< +{ + "path": "/get", + "host": "envoygateway.io", + "method": "GET", + "proto": "HTTP/1.1", + "headers": { + "Accept": [ + "*/*" + ], + "User-Agent": [ + "curl/7.85.0" + ], + "X-Envoy-Expected-Rq-Timeout-Ms": [ + "15000" + ], + "X-Forwarded-Host": [ + "path.rewrite.example" + ], + "X-Forwarded-Proto": [ + "http" + ], + "X-Request-Id": [ + "39aa447c-97b9-45a3-a675-9fb266ab1af0" + ] + }, + "namespace": "default", + "ingress": "", + "service": "", + "pod": "backend-6fdd4b9bd8-8vlc5" +... +``` + +You can see that the `X-Forwarded-Host` is `path.rewrite.example`, but the actual host is `envoygateway.io`. + +[HTTPURLRewriteFilter]: https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1.HTTPURLRewriteFilter diff --git a/site/content/en/v1.0.0/user/traffic/http3.md b/site/content/en/v1.0.0/user/traffic/http3.md new file mode 100644 index 00000000000..bafc274e746 --- /dev/null +++ b/site/content/en/v1.0.0/user/traffic/http3.md @@ -0,0 +1,109 @@ +--- +title: "HTTP3" +--- + +This guide will help you get started using HTTP3 using EG. The guide uses a self-signed CA, so it should be used for +testing and demonstration purposes only. + +## Prerequisites + +- OpenSSL to generate TLS assets. + +## Installation + +Follow the steps from the [Quickstart Guide](quickstart.md) to install Envoy Gateway and the example manifest. +Before proceeding, you should be able to query the example backend using HTTP. + +## TLS Certificates + +Generate the certificates and keys used by the Gateway to terminate client TLS connections. + +Create a root certificate and private key to sign certificates: + +```shell +openssl req -x509 -sha256 -nodes -days 365 -newkey rsa:2048 -subj '/O=example Inc./CN=example.com' -keyout example.com.key -out example.com.crt +``` + +Create a certificate and a private key for `www.example.com`: + +```shell +openssl req -out www.example.com.csr -newkey rsa:2048 -nodes -keyout www.example.com.key -subj "/CN=www.example.com/O=example organization" +openssl x509 -req -days 365 -CA example.com.crt -CAkey example.com.key -set_serial 0 -in www.example.com.csr -out www.example.com.crt +``` + +Store the cert/key in a Secret: + +```shell +kubectl create secret tls example-cert --key=www.example.com.key --cert=www.example.com.crt +``` + +Update the Gateway from the Quickstart guide to include an HTTPS listener that listens on port `443` and references the +`example-cert` Secret: + +```shell +kubectl patch gateway eg --type=json --patch '[{ + "op": "add", + "path": "/spec/listeners/-", + "value": { + "name": "https", + "protocol": "HTTPS", + "port": 443, + "tls": { + "mode": "Terminate", + "certificateRefs": [{ + "kind": "Secret", + "group": "", + "name": "example-cert", + }], + }, + }, +}]' +``` + +Apply the following ClientTrafficPolicy to enable HTTP3 + +```shell +kubectl apply -f - < GET /status/500 HTTP/1.1 +> Host: www.example.com +> User-Agent: curl/8.4.0 +> Accept: */* +> +< HTTP/1.1 500 Internal Server Error +< date: Fri, 01 Mar 2024 15:12:55 GMT +< content-length: 0 +< +* Connection #0 to host 172.18.255.200 left intact +``` + +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. + +```shell +cat < GET /status/500 HTTP/1.1 +> Host: www.example.com +> User-Agent: curl/8.4.0 +> Accept: */* +> +< HTTP/1.1 500 Internal Server Error +< date: Fri, 01 Mar 2024 15:15:53 GMT +< content-length: 0 +< +* Connection #0 to host 172.18.255.200 left intact +``` + +Let's check the stats to see the retry behavior. + +```shell +egctl x stats envoy-proxy -n envoy-gateway-system -l gateway.envoyproxy.io/owning-gateway-name=eg,gateway.envoyproxy.io/owning-gateway-namespace=default | grep "envoy_cluster_upstream_rq_retry{envoy_cluster_name=\"httproute/default/backend/rule/0\"}" +``` + +You will expect to see the stats. + +```console +envoy_cluster_upstream_rq_retry{envoy_cluster_name="httproute/default/backend/rule/0"} 5 +``` diff --git a/site/content/en/v1.0.0/user/traffic/routing-outside-kubernetes.md b/site/content/en/v1.0.0/user/traffic/routing-outside-kubernetes.md new file mode 100644 index 00000000000..6be1853570f --- /dev/null +++ b/site/content/en/v1.0.0/user/traffic/routing-outside-kubernetes.md @@ -0,0 +1,100 @@ +--- +title: "Routing outside Kubernetes" +--- + +Routing to endpoints outside the Kubernetes cluster where Envoy Gateway and its corresponding Envoy Proxy fleet is +running is a common use. This can be achieved by defining FQDN addresses in a [EndpointSlice][]. + +## Installation + +Follow the steps from the [Quickstart](../../quickstart) guide to install Envoy Gateway and the example manifest. +Before proceeding, you should be able to query the example backend using HTTP. + +## Configuration + +* Lets define a Service and EndpointSlice that represents https://httpbin.org + +```shell +cat <> DiG 9.18.1-1ubuntu1.1-Ubuntu <<>> @49.51.177.138 -p 5300 foo.bar.com +; (1 server found) +;; global options: +cmd +;; Got answer: +;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58125 +;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 3 +;; WARNING: recursion requested but not available + +;; OPT PSEUDOSECTION: +; EDNS: version: 0, flags:; udp: 1232 +; COOKIE: 24fb86eba96ebf62 (echoed) +;; QUESTION SECTION: +;foo.bar.com. IN A + +;; ADDITIONAL SECTION: +foo.bar.com. 0 IN A 10.244.0.19 +_udp.foo.bar.com. 0 IN SRV 0 0 42376 . + +;; Query time: 1 msec +;; SERVER: 49.51.177.138#5300(49.51.177.138) (UDP) +;; WHEN: Fri Jan 13 10:20:34 UTC 2023 +;; MSG SIZE rcvd: 114 +``` + +## Clean-Up + +Follow the steps from the [Quickstart Guide](../../quickstart) to uninstall Envoy Gateway. + +Delete the CoreDNS example manifest and the UDPRoute: + +```shell +kubectl delete deploy/coredns +kubectl delete service/coredns +kubectl delete cm/coredns +kubectl delete udproute/coredns +``` + +## Next Steps + +Checkout the [Developer Guide](../../../contributions/develop/) to get involved in the project. + +[UDPRoute]: https://gateway-api.sigs.k8s.io/references/spec/#gateway.networking.k8s.io/v1alpha2.UDPRoute +[UDP proxy documentation]: https://www.envoyproxy.io/docs/envoy/latest/configuration/listeners/udp_filters/udp_proxy diff --git a/site/content/en/v1.0.0/user/traffic/v1.0.0-traffic b/site/content/en/v1.0.0/user/traffic/v1.0.0-traffic new file mode 100644 index 00000000000..e69de29bb2d diff --git a/site/hugo.toml b/site/hugo.toml index 42b20f01c29..ca33d858ce5 100644 --- a/site/hugo.toml +++ b/site/hugo.toml @@ -225,7 +225,7 @@ enable = true name = "Documentation" weight = -102 pre = "" - url = "/v0.6.0" + url = "/v1.0.0" [[params.versions]] version = "latest" @@ -246,6 +246,11 @@ enable = true [[params.versions]] version = "v0.5.0" url = "/v0.5.0" + [[params.versions]] version = "v0.6.0" url = "/v0.6.0" + +[[params.versions]] + version = "v1.0.0" + url = "/v1.0.0"