Skip to content

Latest commit

 

History

History
3912 lines (3912 loc) · 96.2 KB

spec.md

File metadata and controls

3912 lines (3912 loc) · 96.2 KB

Packages:

networking.x-k8s.io/v1alpha1

Package v1alpha1 contains API Schema definitions for the networking.x-k8s.io API group.

Resource Types:

BackendPolicy

BackendPolicy defines policies associated with backends. For the purpose of this API, a backend is defined as any resource that a route can forward traffic to. A common example of a backend is a Service. Configuration that is implementation specific may be represented with similar implementation specific custom resources.

Field Description
apiVersion
string		 networking.x-k8s.io/v1alpha1
kind
string 		BackendPolicy
metadata
Kubernetes meta/v1.ObjectMeta 		Refer to the Kubernetes API documentation for the fields of the metadata field.
spec
BackendPolicySpec

backendRefs
[]BackendRef

BackendRefs define which backends this policy should be applied to. This policy can only apply to backends within the same namespace. If more than one BackendPolicy targets the same backend, precedence must be given to the oldest BackendPolicy.

Support: Core
tls
BackendTLSConfig 		(Optional)

TLS is the TLS configuration for these backends.

Support: Extended
status
BackendPolicyStatus

Gateway

Gateway represents an instantiation of a service-traffic handling infrastructure by binding Listeners to a set of IP addresses.

Implementations should add the gateway-exists-finalizer.networking.x-k8s.io finalizer on the associated GatewayClass whenever Gateway(s) is running. This ensures that a GatewayClass associated with a Gateway(s) is not deleted while in use.

Field Description
apiVersion
string		 networking.x-k8s.io/v1alpha1
kind
string 		Gateway
metadata
Kubernetes meta/v1.ObjectMeta 		Refer to the Kubernetes API documentation for the fields of the metadata field.
spec
GatewaySpec

gatewayClassName
string

GatewayClassName used for this Gateway. This is the name of a GatewayClass resource.
listeners
[]Listener

Listeners associated with this Gateway. Listeners define logical endpoints that are bound on this Gateway’s addresses. At least one Listener MUST be specified.

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”. An implementation MAY also group together and collapse compatible Listeners belonging to different Gateways.

For example, an implementation might consider Listeners to be compatible with each other if all of the following conditions are met:

  1. Either each Listener within the group specifies the “HTTP” Protocol or each Listener within the group specifies either the “HTTPS” or “TLS” Protocol.

  2. Each Listener within the group specifies a Hostname that is unique within the group.

  3. As a special case, one Listener within a group may omit Hostname, in which case this Listener matches when no other Listener matches.

If the implementation does collapse compatible Listeners, the hostname provided in the incoming client request MUST be matched to a Listener to find the correct set of Routes. The incoming hostname MUST be matched using the Hostname field for each Listener in order of most to least specific. That is, exact matches must be processed before wildcard matches.

If this field specifies multiple Listeners that have the same Port value but are not compatible, the implementation must raise a “Conflicted” condition in the Listener status.

Support: Core
addresses
[]GatewayAddress 		(Optional)

Addresses requested for this gateway. This is optional and behavior can depend on the GatewayClass. If a value is set in the spec and the requested address is invalid, the GatewayClass MUST indicate this in the associated entry in GatewayStatus.Addresses.

If no Addresses are specified, the GatewayClass may schedule the Gateway in an implementation-defined manner, assigning an appropriate set of Addresses.

The GatewayClass MUST bind all Listeners to every GatewayAddress that it assigns to the Gateway.

Support: Core
status
GatewayStatus

GatewayClass

GatewayClass describes a class of Gateways available to the user for creating Gateway resources.

GatewayClass is a Cluster level resource.

Support: Core.

Field Description
apiVersion
string		 networking.x-k8s.io/v1alpha1
kind
string 		GatewayClass
metadata
Kubernetes meta/v1.ObjectMeta 		Refer to the Kubernetes API documentation for the fields of the metadata field.
spec
GatewayClassSpec

Spec for this GatewayClass.



controller
string

Controller is a domain/path string that indicates the controller that is managing Gateways of this class.

Example: “acme.io/gateway-controller”.

This field is not mutable and cannot be empty.

The format of this field is DOMAIN “/” PATH, where DOMAIN and PATH are valid Kubernetes names (https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names).

Support: Core
parametersRef
LocalObjectReference 		(Optional)

ParametersRef is a controller-specific resource containing the configuration parameters corresponding to this class. This is optional if the controller does not require any additional configuration.

Parameters resources are implementation specific custom resources. These resources must be cluster-scoped.

If the referent cannot be found, the GatewayClass’s “InvalidParameters” status condition will be true.

Support: Custom
status
GatewayClassStatus

Status of the GatewayClass.

HTTPRoute

HTTPRoute is the Schema for the HTTPRoute resource.

Field Description
apiVersion
string		 networking.x-k8s.io/v1alpha1
kind
string 		HTTPRoute
metadata
Kubernetes meta/v1.ObjectMeta 		Refer to the Kubernetes API documentation for the fields of the metadata field.
spec
HTTPRouteSpec

gateways
RouteGateways

Gateways defines which Gateways can use this Route.
hostnames
[]Hostname 		(Optional)

Hostnames defines a set of hostname that should match against the HTTP Host header to select a HTTPRoute to process the request. Hostname is the fully qualified domain name of a network host, as defined by RFC 3986. Note the following deviations from the “host” part of the URI as defined in the RFC:

  1. IPs are not allowed.
  2. The : delimiter is not respected because ports are not allowed.

Incoming requests are matched against the hostnames before the HTTPRoute rules. If no hostname is specified, traffic is routed based on the HTTPRouteRules.

Hostname can be “precise” which is a domain name without the terminating dot of a network host (e.g. “foo.example.com”) or “wildcard”, which is a domain name prefixed with a single wildcard label (e.g. “.example.com”). The wildcard character ‘’ must appear by itself as the first DNS label and matches only a single label. You cannot have a wildcard label by itself (e.g. Host == “*”). Requests will be matched against the Host field in the following order: 1. If Host is precise, the request matches this rule if the http host header is equal to Host. 2. If Host is a wildcard, then the request matches this rule if the http host header is to equal to the suffix (removing the first label) of the wildcard rule.

Support: Core
tls
RouteTLSConfig 		(Optional)

TLS defines the TLS certificate to use for Hostnames defined in this Route. This configuration only takes effect if the AllowRouteOverride field is set to true in the associated Gateway resource.

Collisions can happen if multiple HTTPRoutes define a TLS certificate for the same hostname. In such a case, conflict resolution guiding principles apply, specificallly, if hostnames are same and two different certificates are specified then the certificate in the oldest resource wins.

Please note that HTTP Route-selection takes place after the TLS Handshake (ClientHello). Due to this, TLS certificate defined here will take precedence even if the request has the potential to match multiple routes (in case multiple HTTPRoutes share the same hostname).

Support: Core
rules
[]HTTPRouteRule

Rules are a list of HTTP matchers, filters and actions.
status
HTTPRouteStatus

TCPRoute

TCPRoute is the Schema for the TCPRoute resource.

Field Description
apiVersion
string		 networking.x-k8s.io/v1alpha1
kind
string 		TCPRoute
metadata
Kubernetes meta/v1.ObjectMeta 		Refer to the Kubernetes API documentation for the fields of the metadata field.
spec
TCPRouteSpec

rules
[]TCPRouteRule

Rules are a list of TCP matchers and actions.
gateways
RouteGateways

Gateways defines which Gateways can use this Route.
status
TCPRouteStatus

TLSRoute

TLSRoute is the Schema for the TLSRoute resource. TLSRoute is similar to TCPRoute but can be configured to match against TLS-specific metadata. This allows more flexibility in matching streams for a given TLS listener.

If you need to forward traffic to a single target for a TLS listener, you could chose to use a TCPRoute with a TLS listener.

Field Description
apiVersion
string		 networking.x-k8s.io/v1alpha1
kind
string 		TLSRoute
metadata
Kubernetes meta/v1.ObjectMeta 		Refer to the Kubernetes API documentation for the fields of the metadata field.
spec
TLSRouteSpec

rules
[]TLSRouteRule

Rules are a list of TLS matchers and actions.
gateways
RouteGateways

Gateways defines which Gateways can use this Route.
status
TLSRouteStatus

UDPRoute

UDPRoute is the Schema for the UDPRoute resource.

Field Description
apiVersion
string		 networking.x-k8s.io/v1alpha1
kind
string 		UDPRoute
metadata
Kubernetes meta/v1.ObjectMeta 		Refer to the Kubernetes API documentation for the fields of the metadata field.
spec
UDPRouteSpec

rules
[]UDPRouteRule

Rules are a list of UDP matchers and actions.
gateways
RouteGateways

Gateways defines which Gateways can use this Route.
status
UDPRouteStatus

AddressType (string alias)

(Appears on: GatewayAddress)

AddressType defines how a network address is represented as a text string. Valid AddressType values are:

  • “IPAddress”: an IPv4 or IPv6 address
  • “NamedAddress”: an opaque identifier. The interpretation of the name is dependent on the controller. If a NamedAddress is requested but unsupported by an implementation, the controller should raise the “Detached” listener status condition on the Gateway with the “UnsupportedAddress” reason.

A NamedAddress might be a cloud-dependent ID for a “static” or “elastic” IP

BackendPolicyConditionType (string alias)

BackendPolicyConditionType is a type of condition associated with a BackendPolicy.

BackendPolicySpec

(Appears on: BackendPolicy)

BackendPolicySpec defines desired policy for a backend.

Field Description
backendRefs
[]BackendRef

BackendRefs define which backends this policy should be applied to. This policy can only apply to backends within the same namespace. If more than one BackendPolicy targets the same backend, precedence must be given to the oldest BackendPolicy.

Support: Core
tls
BackendTLSConfig 		(Optional)

TLS is the TLS configuration for these backends.

Support: Extended

BackendPolicyStatus

(Appears on: BackendPolicy)

BackendPolicyStatus defines the observed state of BackendPolicy. Conditions that are related to a specific Route or Gateway should be placed on the Route(s) using backends configured by this BackendPolicy.

Field Description
conditions
[]Kubernetes meta/v1.Condition

Conditions describe the current conditions of the BackendPolicy.

BackendRef

(Appears on: BackendPolicySpec)

BackendRef identifies an API object within a known namespace that defaults group to core and resource to services if unspecified.

Field Description
group
string

Group is the group of the referent.
kind
string

Kind is the kind of the referent.
name
string

Name is the name of the referent.
port
PortNumber 		(Optional)

Port is the port of the referent. If unspecified, this policy applies to all ports on the backend.

BackendTLSConfig

(Appears on: BackendPolicySpec)

BackendTLSConfig describes TLS configuration for a backend.

Field Description
certificateAuthorityRef
LocalObjectReference 		(Optional)

CertificateAuthorityRef is a reference to a resource that includes trusted CA certificates for the associated backends. If an entry in this list omits or specifies the empty string for both the group and the resource, the resource defaults to “secrets”. An implementation may support other resources (for example, resource “mycertificates” in group “networking.acme.io”).

When stored in a Secret, certificates must be PEM encoded and specified within the “ca.crt” data field of the Secret. Multiple certificates can be specified, concatenated by new lines.

Support: Extended
options
map[string]string 		(Optional)

Options are a list of key/value pairs to give extended options to the provider.

Support: Implementation-specific.

GatewayAddress

(Appears on: GatewaySpec, GatewayStatus)

GatewayAddress describes an address that can be bound to a Gateway.

Field Description
type
AddressType

Type of the Address. This is either “IPAddress” or “NamedAddress”.

Support: Extended
value
string

Value. Examples: “1.2.3.4”, “128::1”, “my-ip-address”. Validity of the values will depend on Type and support by the controller.

GatewayAllowType (string alias)

(Appears on: RouteGateways)

GatewayAllowType specifies which Gateways should be allowed to use a Route.

GatewayClassConditionType (string alias)

GatewayClassConditionType is the type of status conditions. This type should be used with the GatewayClassStatus.Conditions field.

GatewayClassSpec

(Appears on: GatewayClass)

GatewayClassSpec reflects the configuration of a class of Gateways.

Field Description
controller
string

Controller is a domain/path string that indicates the controller that is managing Gateways of this class.

Example: “acme.io/gateway-controller”.

This field is not mutable and cannot be empty.

The format of this field is DOMAIN “/” PATH, where DOMAIN and PATH are valid Kubernetes names (https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names).

Support: Core
parametersRef
LocalObjectReference 		(Optional)

ParametersRef is a controller-specific resource containing the configuration parameters corresponding to this class. This is optional if the controller does not require any additional configuration.

Parameters resources are implementation specific custom resources. These resources must be cluster-scoped.

If the referent cannot be found, the GatewayClass’s “InvalidParameters” status condition will be true.

Support: Custom

GatewayClassStatus

(Appears on: GatewayClass)

GatewayClassStatus is the current status for the GatewayClass.

Field Description
conditions
[]Kubernetes meta/v1.Condition

Conditions is the current status from the controller for this GatewayClass.

GatewayConditionReason (string alias)

GatewayConditionReason defines the set of reasons that explain why a particular Gateway condition type has been raised.

GatewayConditionType (string alias)

GatewayConditionType is a type of condition associated with a Gateway. This type should be used with the GatewayStatus.Conditions field.

GatewayReference

(Appears on: RouteGatewayStatus, RouteGateways)

GatewayReference identifies a Gateway in a specified namespace.

Field Description
name
string

Name is the name of the referent.
namespace
string

Namespace is the namespace of the referent.

GatewaySpec

(Appears on: Gateway)

GatewaySpec defines the desired state of Gateway.

Not all possible combinations of options specified in the Spec are valid. Some invalid configurations can be caught synchronously via a webhook, but there are many cases that will require asynchronous signaling via the GatewayStatus block.

Field Description
gatewayClassName
string

GatewayClassName used for this Gateway. This is the name of a GatewayClass resource.
listeners
[]Listener

Listeners associated with this Gateway. Listeners define logical endpoints that are bound on this Gateway’s addresses. At least one Listener MUST be specified.

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”. An implementation MAY also group together and collapse compatible Listeners belonging to different Gateways.

For example, an implementation might consider Listeners to be compatible with each other if all of the following conditions are met:

  1. Either each Listener within the group specifies the “HTTP” Protocol or each Listener within the group specifies either the “HTTPS” or “TLS” Protocol.

  2. Each Listener within the group specifies a Hostname that is unique within the group.

  3. As a special case, one Listener within a group may omit Hostname, in which case this Listener matches when no other Listener matches.

If the implementation does collapse compatible Listeners, the hostname provided in the incoming client request MUST be matched to a Listener to find the correct set of Routes. The incoming hostname MUST be matched using the Hostname field for each Listener in order of most to least specific. That is, exact matches must be processed before wildcard matches.

If this field specifies multiple Listeners that have the same Port value but are not compatible, the implementation must raise a “Conflicted” condition in the Listener status.

Support: Core
addresses
[]GatewayAddress 		(Optional)

Addresses requested for this gateway. This is optional and behavior can depend on the GatewayClass. If a value is set in the spec and the requested address is invalid, the GatewayClass MUST indicate this in the associated entry in GatewayStatus.Addresses.

If no Addresses are specified, the GatewayClass may schedule the Gateway in an implementation-defined manner, assigning an appropriate set of Addresses.

The GatewayClass MUST bind all Listeners to every GatewayAddress that it assigns to the Gateway.

Support: Core

GatewayStatus

(Appears on: Gateway)

GatewayStatus defines the observed state of Gateway.

Field Description
addresses
[]GatewayAddress 		(Optional)

Addresses lists the IP addresses that have actually been bound to the Gateway. These addresses may differ from the addresses in the Spec, e.g. if the Gateway automatically assigns an address from a reserved pool.

These addresses should all be of type “IPAddress”.
conditions
[]Kubernetes meta/v1.Condition

Conditions describe the current conditions of the Gateway.

Implementations should prefer to express Gateway conditions using the GatewayConditionType and GatewayConditionReason constants so that operators and tools can converge on a common vocabulary to describe Gateway state.

Known condition types are:

  • “Scheduled”
  • “Ready”
listeners
[]ListenerStatus 		(Optional)

Listeners provide status for each unique listener port defined in the Spec.

GatewayTLSConfig

(Appears on: Listener)

GatewayTLSConfig describes a TLS configuration.

References - nginx: https://nginx.org/en/docs/http/configuring_https_servers.html - envoy: https://www.envoyproxy.io/docs/envoy/latest/api-v2/api/v2/auth/cert.proto - haproxy: https://www.haproxy.com/documentation/aloha/9-5/traffic-management/lb-layer7/tls/ - gcp: https://cloud.google.com/load-balancing/docs/use-ssl-policies#creating_an_ssl_policy_with_a_custom_profile - aws: https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html#describe-ssl-policies - azure: https://docs.microsoft.com/en-us/azure/app-service/configure-ssl-bindings#enforce-tls-1112

Field Description
mode
TLSModeType

Mode defines the TLS behavior for the TLS session initiated by the client. There are two possible modes: - Terminate: The TLS session between the downstream client and the Gateway is terminated at the Gateway. - Passthrough: The TLS session is NOT terminated by the Gateway. This implies that the Gateway can’t decipher the TLS stream except for the ClientHello message of the TLS protocol. CertificateRef field is ignored in this mode.
certificateRef
LocalObjectReference 		(Optional)

CertificateRef is the reference to Kubernetes object that contain a TLS certificate and private key. This certificate MUST be used for TLS handshakes for the domain this GatewayTLSConfig is associated with. If an entry in this list omits or specifies the empty string for both the group and the resource, the resource defaults to “secrets”. An implementation may support other resources (for example, resource “mycertificates” in group “networking.acme.io”). Support: Core (Kubernetes Secrets) Support: Implementation-specific (Other resource types)
routeOverride
TLSOverridePolicy

RouteOverride dictates if TLS settings can be configured via Routes or not.

CertificateRef must be defined even if routeOverride.certificate is set to ‘Allow’ as it will be used as the default certificate for the listener.
options
map[string]string 		(Optional)

Options are a list of key/value pairs to give extended options to the provider.

There variation among providers as to how ciphersuites are expressed. If there is a common subset for expressing ciphers then it will make sense to loft that as a core API construct.

Support: Implementation-specific.

HTTPHeaderMatch

(Appears on: HTTPRouteMatch)

HTTPHeaderMatch describes how to select a HTTP route by matching HTTP request headers.

Field Description
type
HeaderMatchType

Type specifies how to match against the value of the header.

Support: core (Exact) Support: custom (RegularExpression, ImplementationSpecific)

Since RegularExpression PathType has custom conformance, implementations can support POSIX, PCRE or any other dialects of regular expressions. Please read the implementation’s documentation to determine the supported dialect.

HTTP Header name matching MUST be case-insensitive (RFC 2616 - section 4.2).
values
map[string]string

Values is a map of HTTP Headers to be matched. It MUST contain at least one entry.

The HTTP header field name to match is the map key, and the value of the HTTP header is the map value. HTTP header field name matching MUST be case-insensitive.

Multiple match values are ANDed together, meaning, a request must match all the specified headers to select the route.

HTTPPathMatch

(Appears on: HTTPRouteMatch)

HTTPPathMatch describes how to select a HTTP route by matching the HTTP request path.

Field Description
type
PathMatchType

Type specifies how to match against the path Value.

Support: core (Exact, Prefix) Support: custom (RegularExpression, ImplementationSpecific)

Since RegularExpression PathType has custom conformance, implementations can support POSIX, PCRE or any other dialects of regular expressions. Please read the implementation’s documentation to determine the supported dialect.
value
string

Value of the HTTP path to match against.

HTTPRequestHeaderFilter

(Appears on: HTTPRouteFilter)

HTTPRequestHeaderFilter defines configuration for the RequestHeaderModifier filter.

Field Description
set
map[string]string 		(Optional)

Set overwrites the request with the given header (name, value) before the action.

Input: GET /foo HTTP/1.1 my-header: foo

Config: set: {“my-header”: “bar”}

Output: GET /foo HTTP/1.1 my-header: bar

Support: Extended
add
map[string]string 		(Optional)

Add adds the given header (name, value) to the request before the action. It appends to any existing values associated with the header name.

Input: GET /foo HTTP/1.1 my-header: foo

Config: add: {“my-header”: “bar”}

Output: GET /foo HTTP/1.1 my-header: foo bar

Support: Extended
remove
[]string 		(Optional)

Remove the given header(s) from the HTTP request before the action. The value of RemoveHeader is a list of HTTP header names. Note that the header names are case-insensitive [RFC-2616 4.2].

Input: GET /foo HTTP/1.1 my-header1: foo my-header2: bar my-header3: baz

Config: remove: [“my-header1”, “my-header3”]

Output: GET /foo HTTP/1.1 my-header2: bar

Support: Extended

HTTPRequestMirrorFilter

(Appears on: HTTPRouteFilter)

HTTPRequestMirrorFilter defines configuration for the RequestMirror filter.

Field Description
serviceName
string 		(Optional)

ServiceName refers to the name of the Service to mirror matched requests to. When specified, this takes the place of BackendRef. If both BackendRef and ServiceName are specified, ServiceName will be given precedence.

If the referent cannot be found, the rule is not included in the route. The controller should raise the “ResolvedRefs” condition on the Gateway with the “DegradedRoutes” reason. The gateway status for this route should be updated with a condition that describes the error more specifically.

Support: Core
backendRef
LocalObjectReference 		(Optional)

BackendRef is a local object reference to mirror matched requests to. If both BackendRef and ServiceName are specified, ServiceName will be given precedence.

If the referent cannot be found, the rule is not included in the route. The controller should raise the “ResolvedRefs” condition on the Gateway with the “DegradedRoutes” reason. The gateway status for this route should be updated with a condition that describes the error more specifically.

Support: Custom
port
PortNumber

Port specifies the destination port number to use for the backend referenced by the ServiceName or BackendRef field.

HTTPRouteFilter

(Appears on: HTTPRouteForwardTo, HTTPRouteRule)

HTTPRouteFilter defines additional processing steps that must be completed during the request or response lifecycle. HTTPRouteFilters are meant as an extension point to express additional processing that may be done in Gateway implementations. Some examples include request or response modification, implementing authentication strategies, rate-limiting, and traffic shaping. API guarantee/conformance is defined based on the type of the filter. TODO(hbagdi): re-render CRDs once controller-tools supports union tags: - kubernetes-sigs/controller-tools#298 - kubernetes-sigs/controller-tools#461

Field Description
type
HTTPRouteFilterType

Type identifies the type of filter to apply. As with other API fields, types are classified into three conformance levels:

  • Core: Filter types and their corresponding configuration defined by “Support: Core” in this package, e.g. “RequestHeaderModifier”. All implementations must support core filters.

  • Extended: Filter types and their corresponding configuration defined by “Support: Extended” in this package, e.g. “RequestMirror”. Implementers are encouraged to support extended filters.

  • Custom: Filters that are defined and supported by specific vendors. In the future, filters showing convergence in behavior across multiple implementations will be considered for inclusion in extended or core conformance levels. Filter-specific configuration for such filters is specified using the ExtensionRef field. Type should be set to “ExtensionRef” for custom filters.

Implementers are encouraged to define custom implementation types to extend the core API with implementation-specific behavior.
requestHeaderModifier
HTTPRequestHeaderFilter 		(Optional)

RequestHeaderModifier defines a schema for a filter that modifies request headers.

Support: Core
requestMirror
HTTPRequestMirrorFilter 		(Optional)

RequestMirror defines a schema for a filter that mirrors requests.

Support: Extended
extensionRef
LocalObjectReference 		(Optional)

ExtensionRef is an optional, implementation-specific extension to the “filter” behavior. For example, resource “myroutefilter” in group “networking.acme.io”). ExtensionRef MUST NOT be used for core and extended filters.

Support: Implementation-specific

HTTPRouteFilterType (string alias)

(Appears on: HTTPRouteFilter)

HTTPRouteFilterType identifies a type of HTTPRoute filter.

HTTPRouteForwardTo

(Appears on: HTTPRouteRule)

HTTPRouteForwardTo defines how a HTTPRoute should forward a request.

Field Description
serviceName
string 		(Optional)

ServiceName refers to the name of the Service to forward matched requests to. When specified, this takes the place of BackendRef. If both BackendRef and ServiceName are specified, ServiceName will be given precedence.

If the referent cannot be found, the route must be dropped from the Gateway. The controller should raise the “ResolvedRefs” condition on the Gateway with the “DegradedRoutes” reason. The gateway status for this route should be updated with a condition that describes the error more specifically.

The protocol to use should be specified with the AppProtocol field on Service resources. This field was introduced in Kubernetes 1.18. If using an earlier version of Kubernetes, a networking.x-k8s.io/app-protocol annotation on the BackendPolicy resource may be used to define the protocol. If the AppProtocol field is available, this annotation should not be used. The AppProtocol field, when populated, takes precedence over the annotation in the BackendPolicy resource. For custom backends, it is encouraged to add a semantically-equivalent field in the Custom Resource Definition.

Support: Core
backendRef
LocalObjectReference 		(Optional)

BackendRef is a reference to a backend to forward matched requests to. If both BackendRef and ServiceName are specified, ServiceName will be given precedence.

If the referent cannot be found, the route must be dropped from the Gateway. The controller should raise the “ResolvedRefs” condition on the Gateway with the “DegradedRoutes” reason. The gateway status for this route should be updated with a condition that describes the error more specifically.

Support: Custom
port
PortNumber

Port specifies the destination port number to use for the backend referenced by the ServiceName or BackendRef field.

Support: Core
weight
int32

Weight specifies the proportion of HTTP requests forwarded to the backend referenced by the ServiceName or BackendRef field. This is computed as weight/(sum of all weights in this ForwardTo list). For non-zero values, there may be some epsilon from the exact proportion defined here depending on the precision an implementation supports. Weight is not a percentage and the sum of weights does not need to equal 100.

If only one backend is specified and it has a weight greater than 0, 100% of the traffic is forwarded to that backend. If weight is set to 0, no traffic should be forwarded for this entry. If unspecified, weight defaults to 1.

Support: Core
filters
[]HTTPRouteFilter 		(Optional)

Filters defined at this-level should be executed if and only if the request is being forwarded to the backend defined here.

Support: Custom (For broader support of filters, use the Filters field in HTTPRouteRule.)

HTTPRouteMatch

(Appears on: HTTPRouteRule)

HTTPRouteMatch defines the predicate used to match requests to a given action. Multiple match types are ANDed together, i.e. the match will evaluate to true only if all conditions are satisfied.

For example, the match below will match a HTTP request only if its path starts with /foo AND it contains the version: "1" header:

match:
path:
value: "/foo"
headers:
values:
version: "1"

Field Description
path
HTTPPathMatch

Path specifies a HTTP request path matcher. If this field is not specified, a default prefix match on the “/” path is provided.
headers
HTTPHeaderMatch 		(Optional)

Headers specifies a HTTP request header matcher.
extensionRef
LocalObjectReference 		(Optional)

ExtensionRef is an optional, implementation-specific extension to the “match” behavior. For example, resource “myroutematcher” in group “networking.acme.io”. If the referent cannot be found, the rule is not included in the route. The controller should raise the “ResolvedRefs” condition on the Gateway with the “DegradedRoutes” reason. The gateway status for this route should be updated with a condition that describes the error more specifically.

Support: custom

HTTPRouteRule

(Appears on: HTTPRouteSpec)

HTTPRouteRule defines semantics for matching an HTTP request based on conditions, optionally executing additional processing steps, and forwarding the request to an API object.

Field Description
matches
[]HTTPRouteMatch

Matches define conditions used for matching the rule against incoming HTTP requests. Each match is independent, i.e. this rule will be matched if any one of the matches is satisfied.

For example, take the following matches configuration:

matches:
- path:
value: "/foo"
headers:
values:
version: "2"
- path:
value: "/v2/foo"

For a request to match against this rule, a request should satisfy EITHER of the two conditions:

  • path prefixed with /foo AND contains the header version: "2"
  • path prefix of /v2/foo

See the documentation for HTTPRouteMatch on how to specify multiple match conditions that should be ANDed together.

If no matches are specified, the default is a prefix path match on “/”, which has the effect of matching every HTTP request.

A client request may match multiple HTTP route rules. Matching precedence MUST be determined in order of the following criteria, continuing on ties: * The longest matching hostname. * The longest matching path. * The largest number of header matches * The oldest Route based on creation timestamp. For example, a Route with a creation timestamp of “2020-09-08 01:02:03” is given precedence over a Route with a creation timestamp of “2020-09-08 01:02:04”. * The Route appearing first in alphabetical order (namespace/name) for example, foo/bar is given precedence over foo/baz.
filters
[]HTTPRouteFilter 		(Optional)

Filters define the filters that are applied to requests that match this rule.

The effects of ordering of multiple behaviors are currently unspecified. This can change in the future based on feedback during the alpha stage.

Conformance-levels at this level are defined based on the type of filter: - ALL core filters MUST be supported by all implementations. - Implementers are encouraged to support extended filters. - Implementation-specific custom filters have no API guarantees across implementations.

Specifying a core filter multiple times has unspecified or custom conformance.

Support: core
forwardTo
[]HTTPRouteForwardTo 		(Optional)

ForwardTo defines the backend(s) where matching requests should be sent. If unspecified, the rule performs no forwarding. If unspecified and no filters are specified that would result in a response being sent, a 503 error code is returned.

HTTPRouteSpec

(Appears on: HTTPRoute)

HTTPRouteSpec defines the desired state of HTTPRoute

Field Description
gateways
RouteGateways

Gateways defines which Gateways can use this Route.
hostnames
[]Hostname 		(Optional)

Hostnames defines a set of hostname that should match against the HTTP Host header to select a HTTPRoute to process the request. Hostname is the fully qualified domain name of a network host, as defined by RFC 3986. Note the following deviations from the “host” part of the URI as defined in the RFC:

  1. IPs are not allowed.
  2. The : delimiter is not respected because ports are not allowed.

Incoming requests are matched against the hostnames before the HTTPRoute rules. If no hostname is specified, traffic is routed based on the HTTPRouteRules.

Hostname can be “precise” which is a domain name without the terminating dot of a network host (e.g. “foo.example.com”) or “wildcard”, which is a domain name prefixed with a single wildcard label (e.g. “.example.com”). The wildcard character ‘’ must appear by itself as the first DNS label and matches only a single label. You cannot have a wildcard label by itself (e.g. Host == “*”). Requests will be matched against the Host field in the following order: 1. If Host is precise, the request matches this rule if the http host header is equal to Host. 2. If Host is a wildcard, then the request matches this rule if the http host header is to equal to the suffix (removing the first label) of the wildcard rule.

Support: Core
tls
RouteTLSConfig 		(Optional)

TLS defines the TLS certificate to use for Hostnames defined in this Route. This configuration only takes effect if the AllowRouteOverride field is set to true in the associated Gateway resource.

Collisions can happen if multiple HTTPRoutes define a TLS certificate for the same hostname. In such a case, conflict resolution guiding principles apply, specificallly, if hostnames are same and two different certificates are specified then the certificate in the oldest resource wins.

Please note that HTTP Route-selection takes place after the TLS Handshake (ClientHello). Due to this, TLS certificate defined here will take precedence even if the request has the potential to match multiple routes (in case multiple HTTPRoutes share the same hostname).

Support: Core
rules
[]HTTPRouteRule

Rules are a list of HTTP matchers, filters and actions.

HTTPRouteStatus

(Appears on: HTTPRoute)

HTTPRouteStatus defines the observed state of HTTPRoute.

Field Description
RouteStatus
RouteStatus

(Members of RouteStatus are embedded into this type.)

HeaderMatchType (string alias)

(Appears on: HTTPHeaderMatch)

HeaderMatchType specifies the semantics of how HTTP header values should be compared. Valid HeaderMatchType values are:

  • “Exact”
  • “RegularExpression”
  • “ImplementationSpecific”

Hostname (string alias)

(Appears on: HTTPRouteSpec, Listener, ListenerStatus, TLSRouteMatch)

Hostname is used to specify a hostname that should be matched.

Listener

(Appears on: GatewaySpec)

Listener embodies the concept of a logical endpoint where a Gateway can accept network connections. Each listener in a Gateway must have a unique combination of Hostname, Port, and Protocol. This will be enforced by a validating webhook.

Field Description
hostname
Hostname 		(Optional)

Hostname specifies the virtual hostname to match for protocol types that define this concept. When unspecified or “*”, all hostnames are matched. This field can be omitted for protocols that don’t require hostname based matching.

Hostname is the fully qualified domain name of a network host, as defined by RFC 3986. Note the following deviations from the “host” part of the URI as defined in the RFC:

  1. IP literals are not allowed.
  2. The : delimiter is not respected because ports are not allowed.

Hostname can be “precise” which is a domain name without the terminating dot of a network host (e.g. “foo.example.com”) or “wildcard”, which is a domain name prefixed with a single wildcard label (e.g. “.example.com”). The wildcard character ‘’ must appear by itself as the first DNS label and matches only a single label.

Support: Core
port
PortNumber

Port is the network port. Multiple listeners may use the same port, subject to the Listener compatibility rules.

Support: Core
protocol
ProtocolType

Protocol specifies the network protocol this listener expects to receive. The GatewayClass MUST apply the Hostname match appropriately for each protocol:

  • For the “TLS” protocol, the Hostname match MUST be applied to the SNI server name offered by the client.
  • For the “HTTP” protocol, the Hostname match MUST be applied to the host portion of the effective request URI or the :authority pseudo-header
  • For the “HTTPS” protocol, the Hostname match MUST be applied at both the TLS and HTTP protocol layers.

Support: Core
tls
GatewayTLSConfig 		(Optional)

TLS is the TLS configuration for the Listener. This field is required if the Protocol field is “HTTPS” or “TLS” and ignored otherwise.

The association of SNIs to Certificate defined in GatewayTLSConfig is defined based on the Hostname field for this listener.

The GatewayClass MUST use the longest matching SNI out of all available certificates for any TLS handshake.

Support: Core
routes
RouteBindingSelector

Routes specifies a schema for associating routes with the Listener using selectors. A Route is a resource capable of servicing a request and allows a cluster operator to expose a cluster resource (i.e. Service) by externally-reachable URL, load-balance traffic and terminate SSL/TLS. Typically, a route is a “HTTPRoute” or “TCPRoute” in group “networking.x-k8s.io”, however, an implementation may support other types of resources.

The Routes selector MUST select a set of objects that are compatible with the application protocol specified in the Protocol field.

Although a client request may technically match multiple route rules, only one rule may ultimately receive the request. Matching precedence MUST be determined in order of the following criteria:

  • The most specific match. For example, the most specific HTTPRoute match is determined by the longest matching combination of hostname and path.
  • The oldest Route based on creation timestamp. For example, a Route with a creation timestamp of “2020-09-08 01:02:03” is given precedence over a Route with a creation timestamp of “2020-09-08 01:02:04”.
  • If everything else is equivalent, the Route appearing first in alphabetical order (namespace/name) should be given precedence. For example, foo/bar is given precedence over foo/baz.

All valid portions of a Route selected by this field should be supported. Invalid portions of a Route can be ignored (sometimes that will mean the full Route). If a portion of a Route transitions from valid to invalid, support for that portion of the Route should be dropped to ensure consistency. For example, even if a filter specified by a Route is invalid, the rest of the Route should still be supported.

Support: Core

ListenerConditionReason (string alias)

ListenerConditionReason defines the set of reasons that explain why a particular Listener condition type has been raised.

ListenerConditionType (string alias)

ListenerConditionType is a type of condition associated with the listener. This type should be used with the ListenerStatus.Conditions field.

ListenerStatus

(Appears on: GatewayStatus)

ListenerStatus is the status associated with a Listener.

Field Description
port
PortNumber

Port is the unique Listener port value for which this message is reporting the status.
protocol
ProtocolType

Protocol is the Listener protocol value for which this message is reporting the status.
hostname
Hostname 		(Optional)

Hostname is the Listener hostname value for which this message is reporting the status.
conditions
[]Kubernetes meta/v1.Condition

Conditions describe the current condition of this listener.

LocalObjectReference

(Appears on: BackendTLSConfig, GatewayClassSpec, GatewayTLSConfig, HTTPRequestMirrorFilter, HTTPRouteFilter, HTTPRouteForwardTo, HTTPRouteMatch, RouteForwardTo, RouteTLSConfig, TCPRouteMatch, TLSRouteMatch, UDPRouteMatch)

LocalObjectReference identifies an API object within a known namespace.

Field Description
group
string

Group is the group of the referent.
kind
string

Kind is kind of the referent.
name
string

Name is the name of the referent.

PathMatchType (string alias)

(Appears on: HTTPPathMatch)

PathMatchType specifies the semantics of how HTTP paths should be compared. Valid PathMatchType values are:

  • “Exact”
  • “Prefix”
  • “RegularExpression”
  • “ImplementationSpecific”

Prefix and Exact paths must be syntactically valid: - Must begin with the ‘/’ character - Must not contain consecutive ‘/’ characters (e.g. /foo///, //). - For prefix paths, a trailing ‘/’ character in the Path is ignored, e.g. /abc and /abc/ specify the same match.

PortNumber (int32 alias)

(Appears on: BackendRef, HTTPRequestMirrorFilter, HTTPRouteForwardTo, Listener, ListenerStatus, RouteForwardTo)

PortNumber defines a network port.

ProtocolType (string alias)

(Appears on: Listener, ListenerStatus)

ProtocolType defines the application protocol accepted by a Listener. Implementations are not required to accept all the defined protocols. If an implementation does not support a specified protocol, it should raise a “Detached” condition for the affected Listener with a reason of “UnsupportedProtocol”.

Core ProtocolType values are:

  • “HTTP”
  • “HTTPS”
  • “TLS”
  • “TCP”
  • “UDP”

Implementations can define their own protocols if a core ProtocolType does not exist. Such definitions must use prefixed name, such as mycompany.com/my-custom-protocol. Un-prefixed names are reserved for core protocols. Any protocol defined by implementations will fall under custom conformance.

RouteBindingSelector

(Appears on: Listener)

RouteBindingSelector defines a schema for associating routes with the Gateway. If Namespaces and Selector are defined, only routes matching both selectors are associated with the Gateway.

Field Description
namespaces
RouteNamespaces

Namespaces indicates in which namespaces Routes should be selected for this Gateway. This is restricted to the namespace of this Gateway by default.

Support: Core
selector
Kubernetes meta/v1.LabelSelector 		(Optional)

Selector specifies a set of route labels used for selecting routes to associate with the Gateway. If this Selector is defined, only routes matching the Selector are associated with the Gateway. An empty Selector matches all routes.

Support: Core
group
string

Group is the group of the route resource to select. Omitting the value or specifying the empty string indicates the networking.x-k8s.io API group. For example, use the following to select an HTTPRoute:

routes: kind: HTTPRoute

Otherwise, if an alternative API group is desired, specify the desired group:

routes: group: acme.io kind: FooRoute

Support: Core
kind
string

Kind is the kind of the route resource to select.

Kind MUST correspond to kinds of routes that are compatible with the application protocol specified in the Listener’s Protocol field.

If an implementation does not support or recognize this resource type, it SHOULD set the “ResolvedRefs” condition to false for this listener with the “InvalidRoutesRef” reason.

Support: Core

RouteConditionType (string alias)

RouteConditionType is a type of condition for a route.

RouteForwardTo

(Appears on: TCPRouteRule, TLSRouteRule, UDPRouteRule)

RouteForwardTo defines how a Route should forward a request.

Field Description
serviceName
string 		(Optional)

ServiceName refers to the name of the Service to forward matched requests to. When specified, this takes the place of BackendRef. If both BackendRef and ServiceName are specified, ServiceName will be given precedence.

If the referent cannot be found, the rule is not included in the route. The controller should raise the “ResolvedRefs” condition on the Gateway with the “DegradedRoutes” reason. The gateway status for this route should be updated with a condition that describes the error more specifically.

The protocol to use is defined using AppProtocol field (introduced in Kubernetes 1.18) in the Service resource. In the absence of the AppProtocol field a networking.x-k8s.io/app-protocol annotation on the BackendPolicy resource may be used to define the protocol. If the AppProtocol field is available, this annotation should not be used. The AppProtocol field, when populated, takes precedence over the annotation in the BackendPolicy resource. For custom backends, it is encouraged to add a semantically-equivalent field in the Custom Resource Definition.

Support: Core
backendRef
LocalObjectReference 		(Optional)

BackendRef is a reference to a backend to forward matched requests to. If both BackendRef and ServiceName are specified, ServiceName will be given precedence.

If the referent cannot be found, the rule is not included in the route. The controller should raise the “ResolvedRefs” condition on the Gateway with the “DegradedRoutes” reason. The gateway status for this route should be updated with a condition that describes the error more specifically.

Support: Custom
port
PortNumber

Port specifies the destination port number to use for the backend referenced by the ServiceName or BackendRef field.

Support: Core
weight
int32

Weight specifies the proportion of HTTP requests forwarded to the backend referenced by the ServiceName or BackendRef field. This is computed as weight/(sum of all weights in this ForwardTo list). For non-zero values, there may be some epsilon from the exact proportion defined here depending on the precision an implementation supports. Weight is not a percentage and the sum of weights does not need to equal 100.

If only one backend is specified and it has a weight greater than 0, 100% of the traffic is forwarded to that backend. If weight is set to 0, no traffic should be forwarded for this entry. If unspecified, weight defaults to 1.

Support: Extended

RouteGatewayStatus

(Appears on: RouteStatus)

RouteGatewayStatus describes the status of a route with respect to an associated Gateway.

Field Description
gatewayRef
GatewayReference

GatewayRef is a reference to a Gateway object that is associated with the route.
conditions
[]Kubernetes meta/v1.Condition

Conditions describes the status of the route with respect to the Gateway. For example, the “Admitted” condition indicates whether the route has been admitted or rejected by the Gateway, and why. Note that the route’s availability is also subject to the Gateway’s own status conditions and listener status.

RouteGateways

(Appears on: HTTPRouteSpec, TCPRouteSpec, TLSRouteSpec, UDPRouteSpec)

RouteGateways defines which Gateways will be able to use a route. If this field results in preventing the selection of a Route by a Gateway, an “Admitted” condition with a status of false must be set for the Gateway on that Route.

Field Description
allow
GatewayAllowType

Allow indicates which Gateways will be allowed to use this route. Possible values are: * All: Gateways in any namespace can use this route. * FromList: Only Gateways specified in GatewayRefs may use this route. * SameNamespace: Only Gateways in the same namespace may use this route.
gatewayRefs
[]GatewayReference 		(Optional)

GatewayRefs must be specified when Allow is set to “FromList”. In that case, only Gateways referenced in this list will be allowed to use this route. This field is ignored for other values of “Allow”.

RouteNamespaces

(Appears on: RouteBindingSelector)

RouteNamespaces indicate which namespaces Routes should be selected from.

Field Description
from
RouteSelectType

From indicates where Routes will be selected for this Gateway. Possible values are: * All: Routes in all namespaces may be used by this Gateway. * Selector: Routes in namespaces selected by the selector may be used by this Gateway. * Same: Only Routes in the same namespace may be used by this Gateway.

Support: Core
selector
Kubernetes meta/v1.LabelSelector 		(Optional)

Selector must be specified when From is set to “Selector”. In that case, only Routes in Namespaces matching this Selector will be selected by this Gateway. This field is ignored for other values of “From”.

Support: Core

RouteSelectType (string alias)

(Appears on: RouteNamespaces)

RouteSelectType specifies where Routes should be selected by a Gateway.

RouteStatus

(Appears on: HTTPRouteStatus, TCPRouteStatus, TLSRouteStatus, UDPRouteStatus)

RouteStatus defines the observed state that is required across all route types.

Field Description
gateways
[]RouteGatewayStatus

Gateways is a list of the Gateways that are associated with the route, and the status of the route with respect to each of these Gateways. When a Gateway selects this route, the controller that manages the Gateway should add an entry to this list when the controller first sees the route and should update the entry as appropriate when the route is modified.

A maximum of 100 Gateways will be represented in this list. If this list is full, there may be additional Gateways using this Route that are not included in the list.

RouteTLSConfig

(Appears on: HTTPRouteSpec)

RouteTLSConfig describes a TLS configuration defined at the Route level.

Field Description
certificateRef
LocalObjectReference

CertificateRef refers to a Kubernetes object that contains a TLS certificate and private key. This certificate MUST be used for TLS handshakes for the domain this RouteTLSConfig is associated with. If an entry in this list omits or specifies the empty string for both the group and kind, the resource defaults to “secrets”. An implementation may support other resources (for example, resource “mycertificates” in group “networking.acme.io”). Support: Core (Kubernetes Secrets) Support: Implementation-specific (Other resource types)

TCPRouteMatch

(Appears on: TCPRouteRule)

TCPRouteMatch defines the predicate used to match connections to a given action.

Field Description
extensionRef
LocalObjectReference 		(Optional)

ExtensionRef is an optional, implementation-specific extension to the “match” behavior. For example, resource “mytcproutematcher” in group “networking.acme.io”. If the referent cannot be found, the rule is not included in the route. The controller should raise the “ResolvedRefs” condition on the Gateway with the “DegradedRoutes” reason. The gateway status for this route should be updated with a condition that describes the error more specifically.

Support: custom

TCPRouteRule

(Appears on: TCPRouteSpec)

TCPRouteRule is the configuration for a given rule.

Field Description
matches
[]TCPRouteMatch 		(Optional)

Matches define conditions used for matching the rule against incoming TCP connections. Each match is independent, i.e. this rule will be matched if any one of the matches is satisfied. If unspecified, all requests from the associated gateway TCP listener will match.
forwardTo
[]RouteForwardTo

ForwardTo defines the backend(s) where matching requests should be sent.

TCPRouteSpec

(Appears on: TCPRoute)

TCPRouteSpec defines the desired state of TCPRoute

Field Description
rules
[]TCPRouteRule

Rules are a list of TCP matchers and actions.
gateways
RouteGateways

Gateways defines which Gateways can use this Route.

TCPRouteStatus

(Appears on: TCPRoute)

TCPRouteStatus defines the observed state of TCPRoute

Field Description
RouteStatus
RouteStatus

(Members of RouteStatus are embedded into this type.)

TLSModeType (string alias)

(Appears on: GatewayTLSConfig)

TLSModeType type defines behavior of gateway with TLS protocol.

TLSOverridePolicy

(Appears on: GatewayTLSConfig)

TLSOverridePolicy defines a schema for overriding TLS settings at the Route level.

Field Description
certificate
TLSRouteOverrideType

Certificate dictates if TLS certificates can be configured via Routes. If set to ‘Allow’, a TLS certificate for a hostname defined in a Route takes precedence over the certificate defined in Gateway.

Support: Core

TLSRouteMatch

(Appears on: TLSRouteRule)

TLSRouteMatch defines the predicate used to match connections to a given action.

Field Description
snis
[]Hostname 		(Optional)

SNIs defines a set of SNI names that should match against the SNI attribute of TLS ClientHello message in TLS handshake.

SNI can be “precise” which is a domain name without the terminating dot of a network host (e.g. “foo.example.com”) or “wildcard”, which is a domain name prefixed with a single wildcard label (e.g. “.example.com”). The wildcard character ‘’ must appear by itself as the first DNS label and matches only a single label. You cannot have a wildcard label by itself (e.g. Host == “*”).

Requests will be matched against the Host field in the following order:

  1. If SNI is precise, the request matches this rule if the SNI in ClientHello is equal to one of the defined SNIs.
  2. If SNI is a wildcard, then the request matches this rule if the SNI is to equal to the suffix (removing the first label) of the wildcard rule.
  3. If SNIs is unspecified, all requests associated with the gateway TLS listener will match. This can be used to define a default backend for a TLS listener.

Support: core
extensionRef
LocalObjectReference 		(Optional)

ExtensionRef is an optional, implementation-specific extension to the “match” behavior. For example, resource “mytlsroutematcher” in group “networking.acme.io”. If the referent cannot be found, the rule is not included in the route. The controller should raise the “ResolvedRefs” condition on the Gateway with the “DegradedRoutes” reason. The gateway status for this route should be updated with a condition that describes the error more specifically.

Support: custom

TLSRouteOverrideType (string alias)

(Appears on: TLSOverridePolicy)

TLSRouteOverrideType type defines the level of allowance for Routes to override a specific TLS setting.

TLSRouteRule

(Appears on: TLSRouteSpec)

TLSRouteRule is the configuration for a given rule.

Field Description
matches
[]TLSRouteMatch 		(Optional)

Matches define conditions used for matching the rule against an incoming TLS handshake. Each match is independent, i.e. this rule will be matched if any one of the matches is satisfied. If unspecified, all requests from the associated gateway TLS listener will match.
forwardTo
[]RouteForwardTo

ForwardTo defines the backend(s) where matching requests should be sent.

TLSRouteSpec

(Appears on: TLSRoute)

TLSRouteSpec defines the desired state of TLSRoute

Field Description
rules
[]TLSRouteRule

Rules are a list of TLS matchers and actions.
gateways
RouteGateways

Gateways defines which Gateways can use this Route.

TLSRouteStatus

(Appears on: TLSRoute)

TLSRouteStatus defines the observed state of TLSRoute

Field Description
RouteStatus
RouteStatus

(Members of RouteStatus are embedded into this type.)

UDPRouteMatch

(Appears on: UDPRouteRule)

UDPRouteMatch defines the predicate used to match packets to a given action.

Field Description
extensionRef
LocalObjectReference 		(Optional)

ExtensionRef is an optional, implementation-specific extension to the “match” behavior. For example, resource “myudproutematcher” in group “networking.acme.io”. If the referent cannot be found, the rule is not included in the route. The controller should raise the “ResolvedRefs” condition on the Gateway with the “DegradedRoutes” reason. The gateway status for this route should be updated with a condition that describes the error more specifically.

Support: custom

UDPRouteRule

(Appears on: UDPRouteSpec)

UDPRouteRule is the configuration for a given rule.

Field Description
matches
[]UDPRouteMatch 		(Optional)

Matches define conditions used for matching the rule against incoming UDP connections. Each match is independent, i.e. this rule will be matched if any one of the matches is satisfied. If unspecified, all requests from the associated gateway UDP listener will match.
forwardTo
[]RouteForwardTo

ForwardTo defines the backend(s) where matching requests should be sent.

UDPRouteSpec

(Appears on: UDPRoute)

UDPRouteSpec defines the desired state of UDPRoute.

Field Description
rules
[]UDPRouteRule

Rules are a list of UDP matchers and actions.
gateways
RouteGateways

Gateways defines which Gateways can use this Route.

UDPRouteStatus

(Appears on: UDPRoute)

UDPRouteStatus defines the observed state of UDPRoute.

Field Description
RouteStatus
RouteStatus

(Members of RouteStatus are embedded into this type.)

Generated with gen-crd-api-reference-docs.