Backend allows the user to configure the endpoints of a backend and the behavior of the connection from Envoy Proxy to the backend.
Last changed in Envoy Gateway v1.9.0
APIVersion defines the versioned schema of this representation of an object. Servers should convert recognized schemas to the latest internal value, and may reject unrecognized values. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources
Kind is a string value representing the REST resource this object represents. Servers may infer this from the endpoint the client submits requests to. Cannot be updated. In CamelCase. More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
Spec defines the desired state of Backend.
AppProtocols defines the application protocols to be supported when connecting to the backend.
Endpoints defines the endpoints to be used when connecting to the backend.
FQDN defines a FQDN endpoint
Hostname defines the FQDN hostname of the backend endpoint.
Port defines the port of the backend endpoint.
Hostname defines an optional hostname for the backend endpoint.
IP defines an IP endpoint. Supports both IPv4 and IPv6 addresses.
Address defines the IP address of the backend endpoint. Supports both IPv4 and IPv6 addresses.
Port defines the port of the backend endpoint.
Unix defines the unix domain socket endpoint
Path defines the unix domain socket path of the backend endpoint. The path length must not exceed 108 characters.
Zone defines the service zone of the backend endpoint.
Fallback indicates whether the backend is designated as a fallback. It is highly recommended to configure active or passive health checks to ensure that failover can be detected when the active backends become unhealthy and to automatically readjust once the primary backends are healthy again. The overprovisioning factor is set to 1.4, meaning the fallback backends will only start receiving traffic when the health of the active backends falls below 72%.
TLS defines the TLS settings for the backend. If TLS is specified here and a BackendTLSPolicy is also configured for the backend, the final TLS settings will be a merge of both configurations. In case of overlapping fields, the values defined in the BackendTLSPolicy will take precedence.
ALPNProtocols supplies the list of ALPN protocols that should be exposed by the listener or used by the proxy to connect to the backend. Defaults: 1. HTTPS Routes: h2 and http/1.1 are enabled in listener context. 2. Other Routes: ALPN is disabled. 3. Backends: proxy uses the appropriate ALPN options for the backend protocol. When an empty list is provided, the ALPN TLS extension is disabled. Defaults to [h2, http/1.1] if not specified. Typical Supported values are: - http/1.0 - http/1.1 - h2
AutoSNIFromEndpointHostname indicates whether the upstream endpoint's hostname should be used as the SNI value when establishing a TLS connection to the backend. This uses the resolved hostname of the upstream endpoint (e.g., from the Backend Endpoints list), rather than a static value. Mutually exclusive with SNI. When a BackendTLSPolicy is attached, its Hostname value takes precedence and AutoSNIFromEndpointHostname is ignored.
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 backend. A single reference to a Kubernetes ConfigMap or a Kubernetes Secret, with the CA certificate in a key named `ca.crt` is currently supported. If CACertificateRefs is empty or unspecified, then WellKnownCACertificates must be specified. Only one of CACertificateRefs or WellKnownCACertificates may be specified, not both.
Group is the group of the referent. For example, "gateway.networking.k8s.io". When unspecified or empty string, core API group is inferred.
Kind is kind of the referent. For example "HTTPRoute" or "Service".
Name is the name of the referent.
Ciphers specifies the set of cipher suites supported when negotiating TLS 1.0 - 1.2. This setting has no effect for TLS 1.3. For Envoy TLS cipher suite configuration semantics and default cipher lists, see the Envoy documentation: https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/transport_sockets/tls/v3/common.proto#extensions-transport-sockets-tls-v3-tlsparameters Supported cipher suite names: - ECDHE-ECDSA-AES128-GCM-SHA256 - ECDHE-RSA-AES128-GCM-SHA256 - ECDHE-ECDSA-AES256-GCM-SHA384 - ECDHE-RSA-AES256-GCM-SHA384 - ECDHE-ECDSA-CHACHA20-POLY1305 - ECDHE-RSA-CHACHA20-POLY1305 - ECDHE-ECDSA-AES128-SHA - ECDHE-RSA-AES128-SHA - AES128-GCM-SHA256 - AES128-SHA - ECDHE-ECDSA-AES256-SHA - ECDHE-RSA-AES256-SHA - AES256-GCM-SHA384 - AES256-SHA Supported IANA/RFC aliases: - TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 - TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 - TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 - TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA - TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA - TLS_RSA_WITH_AES_128_GCM_SHA256 - TLS_RSA_WITH_AES_128_CBC_SHA - TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA - TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA - TLS_RSA_WITH_AES_256_GCM_SHA384 - TLS_RSA_WITH_AES_256_CBC_SHA 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
ClientCertificateRef defines the reference to a Kubernetes Secret that contains the client certificate and private key for Envoy to use when connecting to backend services and external services, such as ExtAuth, ALS, OpenTelemetry, etc. This secret should be located within the same namespace as the Envoy proxy resource that references it.
Group is the group of the referent. For example, "gateway.networking.k8s.io". When unspecified or empty string, core API group is inferred.
Kind is kind of the referent. For example "Secret".
Name is the name of the referent.
Namespace is the namespace of the referenced object. When unspecified, the local namespace is inferred. Note that when a namespace different than the local namespace is specified, a ReferenceGrant object is required in the referent namespace to allow that namespace's owner to accept the reference. See the ReferenceGrant documentation for details. Support: Core
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
Fingerprints specifies TLS client fingerprinting. When specified, a JAX fingerprint derived from the client’s TLS handshake is generated. The fingerprint can be logged in access logs or forwarded to upstream services using request headers. Fingerprinting is disabled if not specified. Supported values are: - JA3 - JA4
InsecureSkipVerify indicates whether the upstream's certificate verification should be skipped. Defaults to "false".
Max specifies the maximal TLS protocol version to allow The default is TLS 1.3 if this is not specified.
Min specifies the minimal TLS protocol version to allow. The default is TLS 1.2 if this is not specified.
SignatureAlgorithms specifies which signature algorithms the listener should support.
SNI specifies the fixed SNI value used when establishing an upstream TLS connection to the backend. Envoy Gateway will use the HTTP host header value for SNI, when all resources referenced in BackendRefs are: 1. Backend resources that do not set SNI, or 2. Service/ServiceImport resources that do not have a BackendTLSPolicy attached to them If a BackendTLSPolicy is attached to the Backend resource, the BackendTLSPolicy's validation.hostname value takes precedence over this field. If no BackendTLSPolicy validation.hostname applies and both this field and AutoSNIFromEndpointHostname are unset, Envoy Gateway configures Envoy to set the upstream SNI from the downstream HTTP host/authority header.
WellKnownCACertificates specifies whether system CA certificates may be used in the TLS handshake between the gateway and backend pod. If WellKnownCACertificates is unspecified or empty (""), then CACertificateRefs must be specified with at least one entry for a valid configuration. Only one of CACertificateRefs or WellKnownCACertificates may be specified, not both.
Type defines the type of the backend. Defaults to "Endpoints"
Status defines the current status of Backend.
Conditions describe the current conditions of the Backend.
lastTransitionTime is the last time the condition transitioned from one status to another. This should be when the underlying condition changed. If that is not known, then using the time when the API field changed is acceptable.
message is a human readable message indicating details about the transition. This may be an empty string.
observedGeneration represents the .metadata.generation that the condition was set based upon. For instance, if .metadata.generation is currently 12, but the .status.conditions[x].observedGeneration is 9, the condition is out of date with respect to the current state of the instance.
reason contains a programmatic identifier indicating the reason for the condition's last transition. Producers of specific condition types may define expected values and meanings for this field, and whether the values are considered a guaranteed API. The value should be a CamelCase string. This field may not be empty.
status of the condition, one of True, False, Unknown.
type of condition in CamelCase or in foo.example.com/CamelCase.
Source: gateway.envoyproxy.io_backends.yaml
Changes to Backend (gateway.envoyproxy.io/v1alpha1) in each Envoy Gateway version, compared to the version before it.
1 property has changed the description
Released · View Backend in v1.8.1
Backend was already present in this version of Envoy Gateway, the oldest one on kubespec.dev
Released · View Backend in v1.8.0
No examples of Backend yet. Contribute one on GitHub.
kubespec.dev