API Specification

Packages:

• gateway.networking.k8s.io/v1alpha2

gateway.networking.k8s.io/v1alpha2

Package v1alpha2 contains API Schema definitions for the gateway.networking.k8s.io API group.

Resource Types:

• Gateway
• GatewayClass
• HTTPRoute
• ReferencePolicy
• TCPRoute
• TLSRoute
• UDPRoute

Gateway

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

Field	Description
apiVersion string	gateway.networking.k8s.io/v1alpha2
kind string	Gateway
metadata Kubernetes meta/v1.ObjectMeta	Refer to the Kubernetes API documentation for the fields of the metadata field.
spec GatewaySpec	Spec defines the desired state of Gateway. gatewayClassName ObjectName 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. 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”. 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: 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 Hostname that is unique within the group. 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 implementation. If a value is set in the spec and the requested address is invalid or unavailable, the implementation MUST indicate this in the associated entry in GatewayStatus.Addresses. The Addresses field represents a request for the address(es) on the “outside of the Gateway”, that traffic bound for this Gateway will use. This could be the IP address or hostname of an external load balancer or other networking infrastructure, or some other address that traffic will be sent to. The .listener.hostname field is used to route traffic that has already arrived at the Gateway to the correct in-cluster destination. If no Addresses are specified, the implementation MAY schedule the Gateway in an implementation-specific manner, assigning an appropriate set of Addresses. The implementation MUST bind all Listeners to every GatewayAddress that it assigns to the Gateway and add a corresponding entry in GatewayStatus.Addresses. Support: Core
status GatewayStatus	Status defines the current state of Gateway.

GatewayClass

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

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. This recommendation is intended to limit the blast radius of changes to GatewayClass or associated parameters. If implementations choose to propagate GatewayClass changes to existing Gateways, that MUST be clearly documented by the implementation.

Whenever one or more Gateways are using a GatewayClass, implementations MUST add the gateway-exists-finalizer.gateway.networking.k8s.io finalizer on the associated GatewayClass. This ensures that a GatewayClass associated with a Gateway is not deleted while in use.

GatewayClass is a Cluster level resource.

Field	Description
apiVersion string	gateway.networking.k8s.io/v1alpha2
kind string	GatewayClass
metadata Kubernetes meta/v1.ObjectMeta	Refer to the Kubernetes API documentation for the fields of the metadata field.
spec GatewayClassSpec	Spec defines the desired state of GatewayClass. controllerName GatewayController ControllerName is the name of the controller that is managing Gateways of this class. The value of this field MUST be a domain prefixed path. Example: “example.net/gateway-controller”. This field is not mutable and cannot be empty. Support: Core parametersRef ParametersReference (Optional) ParametersRef is a reference to a resource that contains the configuration parameters corresponding to the GatewayClass. This is optional if the controller does not require any additional configuration. ParametersRef can reference a standard Kubernetes resource, i.e. ConfigMap, or an implementation-specific custom resource. The resource can be cluster-scoped or namespace-scoped. If the referent cannot be found, the GatewayClass’s “InvalidParameters” status condition will be true. Support: Custom description string (Optional) Description helps describe a GatewayClass with more details.
status GatewayClassStatus	Status defines the current state of GatewayClass.

HTTPRoute

HTTPRoute provides a way to route HTTP requests. This includes the capability to match requests by hostname, path, header, or query param. Filters can be used to specify additional processing steps. Backends specify where matching requests should be routed.

Field	Description
apiVersion string	gateway.networking.k8s.io/v1alpha2
kind string	HTTPRoute
metadata Kubernetes meta/v1.ObjectMeta	Refer to the Kubernetes API documentation for the fields of the metadata field.
spec HTTPRouteSpec	Spec defines the desired state of HTTPRoute. CommonRouteSpec CommonRouteSpec (Members of CommonRouteSpec are embedded into this type.) 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. This matches the RFC 1123 definition of a hostname with 2 notable exceptions: IPs are not allowed. A hostname may be prefixed with a wildcard label (*.). The wildcard label must appear by itself as the first label. If a hostname is specified by both the Listener and HTTPRoute, there must be at least one intersecting hostname for the HTTPRoute to be attached to the Listener. For example: A Listener with test.example.com as the hostname matches HTTPRoutes that have either not specified any hostnames, or have specified at least one of test.example.com or *.example.com. A Listener with *.example.com as the hostname matches HTTPRoutes that have either not specified any hostnames or have specified at least one hostname that matches the Listener hostname. For example, test.example.com and *.example.com would both match. On the other hand, example.com and test.example.net would not match. If both the Listener and HTTPRoute have specified hostnames, any HTTPRoute hostnames that do not match the Listener hostname MUST be ignored. For example, if a Listener specified *.example.com, and the HTTPRoute specified test.example.com and test.example.net, test.example.net must not be considered for a match. If both the Listener and HTTPRoute have specified hostnames, and none match with the criteria above, then the HTTPRoute is not accepted. The implementation must raise an ‘Accepted’ Condition with a status of False in the corresponding RouteParentStatus. Support: Core rules []HTTPRouteRule (Optional) Rules are a list of HTTP matchers, filters and actions.
status HTTPRouteStatus	Status defines the current state of HTTPRoute.

ReferencePolicy

ReferencePolicy identifies kinds of resources in other namespaces that are trusted to reference the specified kinds of resources in the same namespace as the policy.

Each ReferencePolicy can be used to represent a unique trust relationship. Additional Reference Policies can be used to add to the set of trusted sources of inbound references for the namespace they are defined within.

All cross-namespace references in Gateway API (with the exception of cross-namespace Gateway-route attachment) require a ReferencePolicy.

Support: Core

Field	Description
apiVersion string	gateway.networking.k8s.io/v1alpha2
kind string	ReferencePolicy
metadata Kubernetes meta/v1.ObjectMeta	Refer to the Kubernetes API documentation for the fields of the metadata field.
spec ReferencePolicySpec	Spec defines the desired state of ReferencePolicy. from []ReferencePolicyFrom From describes the trusted namespaces and kinds that can reference the resources described in “To”. Each entry in this list must be considered to be an additional place that references can be valid from, or to put this another way, entries must be combined using OR. Support: Core to []ReferencePolicyTo To describes the resources that may be referenced by the resources described in “From”. Each entry in this list must be considered to be an additional place that references can be valid to, or to put this another way, entries must be combined using OR. Support: Core

TCPRoute

TCPRoute provides a way to route TCP requests. When combined with a Gateway listener, it can be used to forward connections on the port specified by the listener to a set of backends specified by the TCPRoute.

Field	Description
apiVersion string	gateway.networking.k8s.io/v1alpha2
kind string	TCPRoute
metadata Kubernetes meta/v1.ObjectMeta	Refer to the Kubernetes API documentation for the fields of the metadata field.
spec TCPRouteSpec	Spec defines the desired state of TCPRoute. CommonRouteSpec CommonRouteSpec (Members of CommonRouteSpec are embedded into this type.) rules []TCPRouteRule Rules are a list of TCP matchers and actions.
status TCPRouteStatus	Status defines the current state of TCPRoute.

TLSRoute

The TLSRoute resource 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 choose to use a TCPRoute with a TLS listener.

Field	Description
apiVersion string	gateway.networking.k8s.io/v1alpha2
kind string	TLSRoute
metadata Kubernetes meta/v1.ObjectMeta	Refer to the Kubernetes API documentation for the fields of the metadata field.
spec TLSRouteSpec	Spec defines the desired state of TLSRoute. CommonRouteSpec CommonRouteSpec (Members of CommonRouteSpec are embedded into this type.) hostnames []Hostname (Optional) Hostnames defines a set of SNI names that should match against the SNI attribute of TLS ClientHello message in TLS handshake. This matches the RFC 1123 definition of a hostname with 2 notable exceptions: IPs are not allowed in SNI names per RFC 6066. A hostname may be prefixed with a wildcard label (*.). The wildcard label must appear by itself as the first label. If a hostname is specified by both the Listener and TLSRoute, there must be at least one intersecting hostname for the TLSRoute to be attached to the Listener. For example: A Listener with test.example.com as the hostname matches TLSRoutes that have either not specified any hostnames, or have specified at least one of test.example.com or *.example.com. A Listener with *.example.com as the hostname matches TLSRoutes that have either not specified any hostnames or have specified at least one hostname that matches the Listener hostname. For example, test.example.com and *.example.com would both match. On the other hand, example.com and test.example.net would not match. If both the Listener and TLSRoute have specified hostnames, any TLSRoute hostnames that do not match the Listener hostname MUST be ignored. For example, if a Listener specified *.example.com, and the TLSRoute specified test.example.com and test.example.net, test.example.net must not be considered for a match. If both the Listener and TLSRoute have specified hostnames, and none match with the criteria above, then the TLSRoute is not accepted. The implementation must raise an ‘Accepted’ Condition with a status of False in the corresponding RouteParentStatus. Support: Core rules []TLSRouteRule Rules are a list of TLS matchers and actions.
status TLSRouteStatus	Status defines the current state of TLSRoute.

UDPRoute

UDPRoute provides a way to route UDP traffic. When combined with a Gateway listener, it can be used to forward traffic on the port specified by the listener to a set of backends specified by the UDPRoute.

Field	Description
apiVersion string	gateway.networking.k8s.io/v1alpha2
kind string	UDPRoute
metadata Kubernetes meta/v1.ObjectMeta	Refer to the Kubernetes API documentation for the fields of the metadata field.
spec UDPRouteSpec	Spec defines the desired state of UDPRoute. CommonRouteSpec CommonRouteSpec (Members of CommonRouteSpec are embedded into this type.) rules []UDPRouteRule Rules are a list of UDP matchers and actions.
status UDPRouteStatus	Status defines the current state of UDPRoute.

AddressType (string alias)

(Appears on: GatewayAddress)

AddressType defines how a network address is represented as a text string.

If the requested address is unsupported, the controller should raise the “Detached” listener status condition on the Gateway with the “UnsupportedAddress” reason.

Value	Description
"Hostname"	A Hostname represents a DNS based ingress point. This is similar to the corresponding hostname field in Kubernetes load balancer status. For example, this concept may be used for cloud load balancers where a DNS name is used to expose a load balancer. Support: Extended
"IPAddress"	A textual representation of a numeric IP address. IPv4 addresses must be in dotted-decimal form. IPv6 addresses must be in a standard IPv6 text representation (see RFC 5952). Support: Extended
"NamedAddress"	A NamedAddress provides a way to reference a specific IP address by name. For example, this may be a name or other unique identifier that refers to a resource on a cloud provider such as a static IP. Support: Implementation-Specific

AllowedRoutes

(Appears on: Listener)

AllowedRoutes defines which Routes may be attached to this Listener.

Field	Description
namespaces RouteNamespaces	(Optional) Namespaces indicates namespaces from which Routes may be attached to this Listener. This is restricted to the namespace of this Gateway by default. Support: Core
kinds []RouteGroupKind	(Optional) Kinds specifies the groups and kinds of Routes that are allowed to bind to this Gateway Listener. When unspecified or empty, the kinds of Routes selected are determined using the Listener protocol. A RouteGroupKind 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 MUST set the “ResolvedRefs” condition to False for this Listener with the “InvalidRoutesRef” reason. Support: Core

AnnotationKey (string alias)

AnnotationKey is the key of an annotation in Gateway API. This is used for validation of maps such as TLS options. This matches the Kubernetes “qualified name” validation that is used for annotations and other common values.

Valid values include:

• example
• example.com
• example.com/path
• example.com/path.html

Invalid values include:

• example~ - “~” is an invalid character
• example.com. - can not start or end with “.”

AnnotationValue (string alias)

(Appears on: GatewayTLSConfig)

AnnotationValue is the value of an annotation in Gateway API. This is used for validation of maps such as TLS options. This roughly matches Kubernetes annotation validation, although the length validation in that case is based on the entire size of the annotations struct.

BackendObjectReference

(Appears on: BackendRef, HTTPRequestMirrorFilter)

BackendObjectReference defines how an ObjectReference that is specific to BackendRef. It includes a few additional fields and features than a regular ObjectReference.

Note that when a namespace is specified, a ReferencePolicy object is required in the referent namespace to allow that namespace’s owner to accept the reference. See the ReferencePolicy documentation for details.

The API object must be valid in the cluster; the Group and Kind must be registered in the cluster for this reference to be valid.

References to objects with invalid Group and Kind are not valid, and must be rejected by the implementation, with appropriate Conditions set on the containing object.

Field	Description
group Group	(Optional) Group is the group of the referent. For example, “networking.k8s.io”. When unspecified (empty string), core API group is inferred.
kind Kind	(Optional) Kind is kind of the referent. For example “HTTPRoute” or “Service”.
name ObjectName	Name is the name of the referent.
namespace Namespace	(Optional) Namespace is the namespace of the backend. When unspecified, the local namespace is inferred. Note that when a namespace is specified, a ReferencePolicy object is required in the referent namespace to allow that namespace’s owner to accept the reference. See the ReferencePolicy documentation for details. Support: Core
port PortNumber	(Optional) Port specifies the destination port number to use for this resource. Port is required when the referent is a Kubernetes Service. For other resources, destination port might be derived from the referent resource or this field.

BackendRef

(Appears on: HTTPBackendRef, TCPRouteRule, TLSRouteRule, UDPRouteRule)

BackendRef defines how a Route should forward a request to a Kubernetes resource.

Note that when a namespace is specified, a ReferencePolicy object is required in the referent namespace to allow that namespace’s owner to accept the reference. See the ReferencePolicy documentation for details.

Field	Description
BackendObjectReference BackendObjectReference	(Members of BackendObjectReference are embedded into this type.) BackendObjectReference references a Kubernetes object.
weight int32	(Optional) Weight specifies the proportion of requests forwarded to the referenced backend. This is computed as weight/(sum of all weights in this BackendRefs 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 for this field varies based on the context where used.

CommonRouteSpec

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

CommonRouteSpec defines the common attributes that all Routes MUST include within their spec.

Field

Description

parentRefs []ParentRef

(Optional) ParentRefs references the resources (usually Gateways) that a Route wants to be attached to. Note that the referenced parent resource needs to allow this for the attachment to be complete. For Gateways, that means the Gateway needs to allow attachment from Routes of this kind and namespace. The only kind of parent resource with “Core” support is Gateway. This API may be extended in the future to support additional kinds of parent resources such as one of the route kinds. It is invalid to reference an identical parent more than once. It is valid to reference multiple distinct sections within the same parent resource, such as 2 Listeners within a Gateway. It is possible to separately reference multiple distinct objects that may be collapsed by an implementation. For example, some implementations may choose to merge compatible Gateway Listeners together. If that is the case, the list of routes attached to those resources should also be merged.

FromNamespaces (string alias)

(Appears on: RouteNamespaces)

FromNamespaces specifies namespace from which Routes may be attached to a Gateway.

Value	Description
"All"	Routes in all namespaces may be attached to this Gateway.
"Same"	Only Routes in the same namespace as the Gateway may be attached to this Gateway.
"Selector"	Only Routes in namespaces selected by the selector may be attached to this Gateway.

GatewayAddress

(Appears on: GatewaySpec, GatewayStatus)

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

Field	Description
type AddressType	(Optional) Type of the address.
value string	Value of the address. The validity of the values will depend on the type and support by the controller. Examples: 1.2.3.4, 128::1, my-ip-address.

GatewayClassConditionReason (string alias)

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

Value	Description
"Accepted"	This reason is used with the “Accepted” condition when the condition is true.
"InvalidParameters"	This reason is used with the “Accepted” condition when the GatewayClass was not accepted because the parametersRef field was invalid, with more detail in the message.
"Waiting"	This reason is used with the “Accepted” condition when the requested controller has not yet made a decision about whether to admit the GatewayClass. It is the default Reason on a new GatewayClass.

GatewayClassConditionType (string alias)

GatewayClassConditionType is the type for status conditions on Gateway resources. This type should be used with the GatewayClassStatus.Conditions field.

Value

Description

"Accepted"

This condition indicates whether the GatewayClass has been accepted by the controller requested in the spec.controller field. This condition defaults to Unknown, and MUST be set by a controller when it sees a GatewayClass using its controller string. The status of this condition MUST be set to True if the controller will support provisioning Gateways using this class. Otherwise, this status MUST be set to False. If the status is set to False, the controller SHOULD set a Message and Reason as an explanation. Possible reasons for this condition to be true are: “Accepted” Possible reasons for this condition to be False are: “InvalidParameters” “Waiting” Controllers should prefer to use the values of GatewayClassConditionReason for the corresponding Reason, where appropriate.

GatewayClassSpec

(Appears on: GatewayClass)

GatewayClassSpec reflects the configuration of a class of Gateways.

Field	Description
controllerName GatewayController	ControllerName is the name of the controller that is managing Gateways of this class. The value of this field MUST be a domain prefixed path. Example: “example.net/gateway-controller”. This field is not mutable and cannot be empty. Support: Core
parametersRef ParametersReference	(Optional) ParametersRef is a reference to a resource that contains the configuration parameters corresponding to the GatewayClass. This is optional if the controller does not require any additional configuration. ParametersRef can reference a standard Kubernetes resource, i.e. ConfigMap, or an implementation-specific custom resource. The resource can be cluster-scoped or namespace-scoped. If the referent cannot be found, the GatewayClass’s “InvalidParameters” status condition will be true. Support: Custom
description string	(Optional) Description helps describe a GatewayClass with more details.

GatewayClassStatus

(Appears on: GatewayClass)

GatewayClassStatus is the current status for the GatewayClass.

Field	Description
conditions []Kubernetes meta/v1.Condition	(Optional) Conditions is the current status from the controller for this GatewayClass. Controllers should prefer to publish conditions using values of GatewayClassConditionType for the type of each Condition.

GatewayConditionReason (string alias)

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

Value	Description
"AddressNotAssigned"	This reason is used with the “Ready” condition when none of the requested addresses have been assigned to the Gateway. This reason can be used to express a range of circumstances, including (but not limited to) IPAM address exhaustion, invalid or unsupported address requests, or a named address not being found.
"ListenersNotReady"	This reason is used with the “Ready” condition when one or more Listeners are not ready to serve traffic.
"ListenersNotValid"	This reason is used with the “Ready” condition when one or more Listeners have an invalid or unsupported configuration and cannot be configured on the Gateway.
"NoResources"	This reason is used with the “Scheduled” condition when the Gateway is not scheduled because insufficient infrastructure resources are available.
"NotReconciled"	This reason is used with the “Scheduled” condition when no controller has reconciled the Gateway.
"Ready"	This reason is used with the “Ready” condition when the condition is true.
"Scheduled"	This reason is used with the “Scheduled” condition when the condition is true.

GatewayConditionType (string alias)

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

Value	Description
"Ready"	This condition is true when the Gateway is expected to be able to serve traffic. Note that this does not indicate that the Gateway configuration is current or even complete (e.g. the controller may still not have reconciled the latest version, or some parts of the configuration could be missing). If both the “ListenersNotValid” and “ListenersNotReady” reasons are true, the Gateway controller should prefer the “ListenersNotValid” reason. Possible reasons for this condition to be true are: “Ready” Possible reasons for this condition to be False are: “ListenersNotValid” “ListenersNotReady” “AddressNotAssigned” Controllers may raise this condition with other reasons, but should prefer to use the reasons listed above to improve interoperability.
"Scheduled"	This condition is true when the controller managing the Gateway has scheduled the Gateway to the underlying network infrastructure. Possible reasons for this condition to be true are: “Scheduled” Possible reasons for this condition to be False are: “NotReconciled” “NoResources” Controllers may raise this condition with other reasons, but should prefer to use the reasons listed above to improve interoperability.

GatewayController (string alias)

(Appears on: GatewayClassSpec, RouteParentStatus)

GatewayController is the name of a Gateway API controller. It must be a domain prefixed path.

Valid values include:

• “example.com/bar”

Invalid values include:

• “example.com” - must include path
• “foo.example.com” - must include path

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 ObjectName	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. 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”. 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: 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 Hostname that is unique within the group. 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 implementation. If a value is set in the spec and the requested address is invalid or unavailable, the implementation MUST indicate this in the associated entry in GatewayStatus.Addresses. The Addresses field represents a request for the address(es) on the “outside of the Gateway”, that traffic bound for this Gateway will use. This could be the IP address or hostname of an external load balancer or other networking infrastructure, or some other address that traffic will be sent to. The .listener.hostname field is used to route traffic that has already arrived at the Gateway to the correct in-cluster destination. If no Addresses are specified, the implementation MAY schedule the Gateway in an implementation-specific manner, assigning an appropriate set of Addresses. The implementation MUST bind all Listeners to every GatewayAddress that it assigns to the Gateway and add a corresponding entry in GatewayStatus.Addresses. 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.
conditions []Kubernetes meta/v1.Condition	(Optional) 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.

Field	Description
mode TLSModeType	(Optional) 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. This mode requires certificateRefs to be set and contain at least one element. 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. CertificateRefs field is ignored in this mode. Support: Core
certificateRefs []*sigs.k8s.io/gateway-api/apis/v1alpha2.SecretObjectReference	(Optional) CertificateRefs contains a series of references to Kubernetes objects that contains TLS certificates and private keys. These certificates are used to establish a TLS handshake for requests that match the hostname of the associated listener. A single CertificateRef to a Kubernetes Secret has “Core” support. Implementations MAY choose to support attaching multiple certificates to a Listener, but this behavior is implementation-specific. References to a resource in different namespace are invalid UNLESS there is a ReferencePolicy in the target namespace that allows the certificate to be attached. If a ReferencePolicy does not allow this reference, the “ResolvedRefs” condition MUST be set to False for this listener with the “InvalidCertificateRef” reason. This field is required to have at least one element when the mode is set to “Terminate” (default) and is optional otherwise. CertificateRefs can reference to standard Kubernetes resources, i.e. Secret, or implementation-specific custom resources. Support: Core - A single reference to a Kubernetes Secret Support: Implementation-specific (More than one reference or other resource types)
options map[sigs.k8s.io/gateway-api/apis/v1alpha2.AnnotationKey]sigs.k8s.io/gateway-api/apis/v1alpha2.AnnotationValue	(Optional) Options are a list of key/value pairs to enable extended TLS configuration for each implementation. For example, configuring the minimum TLS version or supported cipher suites. A set of common keys MAY be defined by the API in the future. To avoid any ambiguity, implementation-specific definitions MUST use domain-prefixed names, such as example.com/my-custom-option. Un-prefixed names are reserved for key names defined by Gateway API. Support: Implementation-specific

Group (string alias)

(Appears on: BackendObjectReference, LocalObjectReference, ParametersReference, ParentRef, PolicyTargetReference, ReferencePolicyFrom, ReferencePolicyTo, RouteGroupKind, SecretObjectReference)

Group refers to a Kubernetes Group. It must either be an empty string or a RFC 1123 subdomain.

This validation is based off of the corresponding Kubernetes validation: https://github.com/kubernetes/apimachinery/blob/02cfb53916346d085a6c6c7c66f882e3c6b0eca6/pkg/util/validation/validation.go#L208

Valid values include:

• ”” - empty string implies core Kubernetes API group
• “networking.k8s.io”
• “foo.example.com”

Invalid values include:

• “example.com/bar” - “/” is an invalid character

HTTPBackendRef

(Appears on: HTTPRouteRule)

HTTPBackendRef defines how a HTTPRoute should forward an HTTP request.

Field	Description
BackendRef BackendRef	(Members of BackendRef are embedded into this type.) (Optional) BackendRef is a reference to a backend to forward matched requests to. If the referent cannot be found, this HTTPBackendRef is invalid and must be dropped from the Gateway. The controller must ensure the “ResolvedRefs” condition on the Route is set to status: False and not configure this backend in the underlying implementation. If there is a cross-namespace reference to an existing object that is not covered by a ReferencePolicy, the controller must ensure the “ResolvedRefs” condition on the Route is set to status: true, with the “RefNotPermitted” reason and not configure this backend in the underlying implementation. In either error case, the Message of the ResolvedRefs Condition should be used to provide more detail about the problem. Support: Custom
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.)

HTTPHeader

(Appears on: HTTPRequestHeaderFilter)

HTTPHeader represents an HTTP Header name and value as defined by RFC 7230.

Field	Description
name HTTPHeaderName	Name is the name of the HTTP Header to be matched. Name matching MUST be case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, the first entry with an equivalent name MUST be considered for a match. Subsequent entries with an equivalent header name MUST be ignored. Due to the case-insensitivity of header names, “foo” and “Foo” are considered equivalent.
value string	Value is the value of HTTP Header to be matched.

HTTPHeaderMatch

(Appears on: HTTPRouteMatch)

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

Field	Description
type HeaderMatchType	(Optional) Type specifies how to match against the value of the header. Support: Core (Exact) Support: Custom (RegularExpression) Since RegularExpression HeaderMatchType 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.
name HTTPHeaderName	Name is the name of the HTTP Header to be matched. Name matching MUST be case insensitive. (See https://tools.ietf.org/html/rfc7230#section-3.2). If multiple entries specify equivalent header names, only the first entry with an equivalent name MUST be considered for a match. Subsequent entries with an equivalent header name MUST be ignored. Due to the case-insensitivity of header names, “foo” and “Foo” are considered equivalent. When a header is repeated in an HTTP request, it is implementation-specific behavior as to how this is represented. Generally, proxies should follow the guidance from the RFC: https://www.rfc-editor.org/rfc/rfc7230.html#section-3.2.2 regarding processing a repeated header, with special handling for “Set-Cookie”.
value string	Value is the value of HTTP Header to be matched.

HTTPHeaderName (string alias)

(Appears on: HTTPHeader, HTTPHeaderMatch)

HTTPHeaderName is the name of an HTTP header.

Valid values include:

• “Authorization”
• “Set-Cookie”

Invalid values include:

• ”:method” - “:” is an invalid character. This means that HTTP/2 pseudo headers are not currently supported by this type.
• ”/invalid” - “/” is an invalid character

HTTPMethod (string alias)

(Appears on: HTTPRouteMatch)

HTTPMethod describes how to select a HTTP route by matching the HTTP method as defined by RFC 7231 and RFC 5789. The value is expected in upper case.

Value	Description
"CONNECT"
"DELETE"
"GET"
"HEAD"
"OPTIONS"
"PATCH"
"POST"
"PUT"
"TRACE"

HTTPPathMatch

(Appears on: HTTPRouteMatch)

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

Field	Description
type PathMatchType	(Optional) Type specifies how to match against the path Value. Support: Core (Exact, PathPrefix) Support: Custom (RegularExpression)
value string	(Optional) Value of the HTTP path to match against.

HTTPPathModifier

(Appears on: HTTPRequestRedirectFilter, HTTPURLRewriteFilter)

HTTPPathModifier defines configuration for path modifiers. gateway:experimental

Field	Description
type HTTPPathModifierType	Type defines the type of path modifier. gateway:experimental
substitution string	Substitution defines the HTTP path value to substitute. An empty value (“”) indicates that the portion of the path to be changed should be removed from the resulting path. For example, a request to “/foo/bar” with a prefix match of “/foo” would be modified to “/bar”. gateway:experimental

HTTPPathModifierType (string alias)

(Appears on: HTTPPathModifier)

HTTPPathModifierType defines the type of path redirect.

Value	Description
"Absolute"	This type of modifier indicates that the complete path will be replaced by the path redirect value.
"ReplacePrefixMatch"	This type of modifier indicates that any prefix path matches will be replaced by the substitution value. For example, a path with a prefix match of “/foo” and a ReplacePrefixMatch substitution of “/bar” will have the “/foo” prefix replaced with “/bar” in matching requests.

HTTPQueryParamMatch

(Appears on: HTTPRouteMatch)

HTTPQueryParamMatch describes how to select a HTTP route by matching HTTP query parameters.

Field	Description
type QueryParamMatchType	(Optional) Type specifies how to match against the value of the query parameter. Support: Extended (Exact) Support: Custom (RegularExpression) Since RegularExpression QueryParamMatchType 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.
name string	Name is the name of the HTTP query param to be matched. This must be an exact string match. (See https://tools.ietf.org/html/rfc7230#section-2.7.3).
value string	Value is the value of HTTP query param to be matched.

HTTPRequestHeaderFilter

(Appears on: HTTPRouteFilter)

HTTPRequestHeaderFilter defines configuration for the RequestHeaderModifier filter.

Field	Description
set []HTTPHeader	(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: - name: “my-header” value: “bar” Output: GET /foo HTTP/1.1 my-header: bar
add []HTTPHeader	(Optional) Add adds the given header(s) (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: - name: “my-header” value: “bar” Output: GET /foo HTTP/1.1 my-header: foo my-header: bar
remove []string	(Optional) Remove the given header(s) from the HTTP request before the action. The value of Remove is a list of HTTP header names. Note that the header names are case-insensitive (see https://datatracker.ietf.org/doc/html/rfc2616#section-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

HTTPRequestMirrorFilter

(Appears on: HTTPRouteFilter)

HTTPRequestMirrorFilter defines configuration for the RequestMirror filter.

Field

Description

backendRef BackendObjectReference

BackendRef references a resource where mirrored requests are sent. If the referent cannot be found, this BackendRef is invalid and must be dropped from the Gateway. The controller must ensure the “ResolvedRefs” condition on the Route status is set to status: False and not configure this backend in the underlying implementation. If there is a cross-namespace reference to an existing object that is not allowed by a ReferencePolicy, the controller must ensure the “ResolvedRefs” condition on the Route is set to status: False, with the “RefNotPermitted” reason and not configure this backend in the underlying implementation. In either error case, the Message of the ResolvedRefs Condition should be used to provide more detail about the problem. Support: Extended for Kubernetes Service Support: Custom for any other resource

HTTPRequestRedirectFilter

(Appears on: HTTPRouteFilter)

HTTPRequestRedirect defines a filter that redirects a request. This filter MUST not be used on the same Route rule as a HTTPURLRewrite filter.

Field	Description
scheme string	(Optional) Scheme is the scheme to be used in the value of the Location header in the response. When empty, the scheme of the request is used. Support: Extended
hostname Hostname	(Optional) Hostname is the hostname to be used in the value of the Location header in the response. When empty, the hostname of the request is used. Support: Core
path HTTPPathModifier	(Optional) Path defines parameters used to modify the path of the incoming request. The modified path is then used to construct the Location header. When empty, the request path is used as-is. Support: Extended gateway:experimental
port PortNumber	(Optional) Port is the port to be used in the value of the Location header in the response. When empty, port (if specified) of the request is used. Support: Extended
statusCode int	(Optional) StatusCode is the HTTP status code to be used in response. Support: Core

HTTPRouteFilter

(Appears on: HTTPBackendRef, HTTPRouteRule)

HTTPRouteFilter defines processing steps that must be completed during the request or response lifecycle. HTTPRouteFilters are meant as an extension point to express 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.

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. If a reference to a custom filter type cannot be resolved, the filter MUST NOT be skipped. Instead, requests that would have been processed by that filter MUST receive a HTTP error response. gateway:experimental:validation:Enum=RequestHeaderModifier;RequestMirror;RequestRedirect;URLRewrite;ExtensionRef
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. Requests are sent to the specified destination, but responses from that destination are ignored. Support: Extended
requestRedirect HTTPRequestRedirectFilter	(Optional) RequestRedirect defines a schema for a filter that responds to the request with an HTTP redirection. Support: Core
urlRewrite HTTPURLRewriteFilter	(Optional) URLRewrite defines a schema for a filter that responds to the request with an HTTP redirection. Support: Extended gateway:experimental
extensionRef LocalObjectReference	(Optional) ExtensionRef is an optional, implementation-specific extension to the “filter” behavior. For example, resource “myroutefilter” in group “networking.example.net”). 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.

Value	Description
"ExtensionRef"	HTTPRouteFilterExtensionRef should be used for configuring custom HTTP filters. Support in HTTPRouteRule: Custom Support in HTTPBackendRef: Custom
"RequestHeaderModifier"	HTTPRouteFilterRequestHeaderModifier can be used to add or remove an HTTP header from an HTTP request before it is sent to the upstream target. Support in HTTPRouteRule: Core Support in HTTPBackendRef: Extended
"RequestMirror"	HTTPRouteFilterRequestMirror can be used to mirror HTTP requests to a different backend. The responses from this backend MUST be ignored by the Gateway. Support in HTTPRouteRule: Extended Support in HTTPBackendRef: Extended
"RequestRedirect"	HTTPRouteFilterRequestRedirect can be used to redirect a request to another location. This filter can also be used for HTTP to HTTPS redirects. This may not be used on the same Route rule or BackendRef as a URLRewrite filter. Support in HTTPRouteRule: Core Support in HTTPBackendRef: Extended
"URLRewrite"	HTTPRouteFilterURLRewrite can be used to modify a request during forwarding. At most one of these filters may be used on a Route rule. This may not be used on the same Route rule or BackendRef as a RequestRedirect filter. Support in HTTPRouteRule: Extended Support in HTTPBackendRef: Extended gateway:experimental

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: v1 header:

match:
path:
value: "/foo"
headers:
- name: "version"
value "v1"

Field	Description
path HTTPPathMatch	(Optional) 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 HTTP request header matchers. Multiple match values are ANDed together, meaning, a request must match all the specified headers to select the route.
queryParams []HTTPQueryParamMatch	(Optional) QueryParams specifies HTTP query parameter matchers. Multiple match values are ANDed together, meaning, a request must match all the specified query parameters to select the route.
method HTTPMethod	(Optional) Method specifies HTTP method matcher. When specified, this route will be matched only if the request has the specified method. Support: Extended

HTTPRouteRule

(Appears on: HTTPRouteSpec)

HTTPRouteRule defines semantics for matching an HTTP request based on conditions (matches), processing it (filters), and forwarding the request to an API object (backendRefs).

Field	Description
matches []HTTPRouteMatch	(Optional) 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: - name: "version" value: "v2" - path: value: "/v2/foo" For a request to match against this rule, a request must satisfy EITHER of the two conditions: path prefixed with /foo AND contains the header version: v2 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. Proxy or Load Balancer routing configuration generated from HTTPRoutes MUST prioritize rules based on the following criteria, continuing on ties. Precedence must be given to the the Rule with the largest number of: Characters in a matching non-wildcard hostname. Characters in a matching hostname. Characters in a matching path. Header matches. Query param matches. If ties still exist across multiple Routes, matching precedence MUST be determined in order of the following criteria, continuing on ties: The oldest Route based on creation timestamp. The Route appearing first in alphabetical order by “/”. If ties still exist within the Route that has been given precedence, matching precedence MUST be granted to the first matching rule meeting the above criteria.
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
backendRefs []HTTPBackendRef	(Optional) If unspecified or invalid (refers to a non-existent resource or a Service with no endpoints), the rule performs no forwarding. If there are also no filters specified that would result in a response being sent, a HTTP 503 status code is returned. 503 responses must be sent so that the overall weight is respected; if an invalid backend is requested to have 80% of requests, then 80% of requests must get a 503 instead. Support: Core for Kubernetes Service Support: Custom for any other resource Support for weight: Core

HTTPRouteSpec

(Appears on: HTTPRoute)

HTTPRouteSpec defines the desired state of HTTPRoute

Field	Description
CommonRouteSpec CommonRouteSpec	(Members of CommonRouteSpec are embedded into this type.)
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. This matches the RFC 1123 definition of a hostname with 2 notable exceptions: IPs are not allowed. A hostname may be prefixed with a wildcard label (*.). The wildcard label must appear by itself as the first label. If a hostname is specified by both the Listener and HTTPRoute, there must be at least one intersecting hostname for the HTTPRoute to be attached to the Listener. For example: A Listener with test.example.com as the hostname matches HTTPRoutes that have either not specified any hostnames, or have specified at least one of test.example.com or *.example.com. A Listener with *.example.com as the hostname matches HTTPRoutes that have either not specified any hostnames or have specified at least one hostname that matches the Listener hostname. For example, test.example.com and *.example.com would both match. On the other hand, example.com and test.example.net would not match. If both the Listener and HTTPRoute have specified hostnames, any HTTPRoute hostnames that do not match the Listener hostname MUST be ignored. For example, if a Listener specified *.example.com, and the HTTPRoute specified test.example.com and test.example.net, test.example.net must not be considered for a match. If both the Listener and HTTPRoute have specified hostnames, and none match with the criteria above, then the HTTPRoute is not accepted. The implementation must raise an ‘Accepted’ Condition with a status of False in the corresponding RouteParentStatus. Support: Core
rules []HTTPRouteRule	(Optional) 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.)

HTTPURLRewriteFilter

(Appears on: HTTPRouteFilter)

HTTPURLRewriteFilter defines a filter that modifies a request during forwarding. At most one of these filters may be used on a Route rule. This may not be used on the same Route rule as a HTTPRequestRedirect filter.

gateway:experimental Support: Extended

Field	Description
hostname Hostname	(Optional) Hostname is the value to be used to replace the Host header value during forwarding. Support: Extended gateway:experimental
path HTTPPathModifier	(Optional) Path defines a path rewrite. Support: Extended gateway:experimental

HeaderMatchType (string alias)

(Appears on: HTTPHeaderMatch)

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

• “Exact”
• “RegularExpression”

Value	Description
"Exact"
"RegularExpression"

Hostname (string alias)

(Appears on: HTTPRequestRedirectFilter, HTTPRouteSpec, HTTPURLRewriteFilter, Listener, TLSRouteSpec)

Hostname is the fully qualified domain name of a network host. This matches the RFC 1123 definition of a hostname with 2 notable exceptions:

1. IPs are not allowed.
2. A hostname may be prefixed with a wildcard label (*.). The wildcard label must appear by itself as the first label.

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).

Note that as per RFC1035 and RFC1123, a label must consist of lower case alphanumeric characters or ‘-’, and must start and end with an alphanumeric character. No other punctuation is allowed.

Kind (string alias)

(Appears on: BackendObjectReference, LocalObjectReference, ParametersReference, ParentRef, PolicyTargetReference, ReferencePolicyFrom, ReferencePolicyTo, RouteGroupKind, SecretObjectReference)

Kind refers to a Kubernetes Kind.

Valid values include:

• “Service”
• “HTTPRoute”

Invalid values include:

• “invalid/kind” - “/” is an invalid character

Listener

(Appears on: GatewaySpec)

Listener embodies the concept of a logical endpoint where a Gateway accepts network connections.

Field	Description
name SectionName	Name is the name of the Listener. Support: Core
hostname Hostname	(Optional) Hostname specifies the virtual hostname to match for protocol types that define this concept. When unspecified, all hostnames are matched. This field is ignored for protocols that don’t require hostname based matching. Implementations MUST apply Hostname matching appropriately for each of the following protocols: TLS: The Listener Hostname MUST match the SNI. HTTP: The Listener Hostname MUST match the Host header of the request. HTTPS: The Listener Hostname SHOULD match at both the TLS and HTTP protocol layers as described above. If an implementation does not ensure that both the SNI and Host header match the Listener hostname, it MUST clearly document that. For HTTPRoute and TLSRoute resources, there is an interaction with the spec.hostnames array. When both listener and route specify hostnames, there MUST be an intersection between the values for a Route to be accepted. For more information, refer to the Route specific Hostnames documentation. 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. 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”. It is invalid to set this field if the Protocol field is “HTTP”, “TCP”, or “UDP”. 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
allowedRoutes AllowedRoutes	(Optional) AllowedRoutes defines the types of routes that MAY be attached to a Listener and the trusted namespaces where those Route resources MAY be present. Although a client request may 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 as defined by the Route type. 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 rules within a Route attached to this Listener should be implemented. Invalid Route rules can be ignored (sometimes that will mean the full Route). If a Route rule transitions from valid to invalid, support for that Route rule should be dropped to ensure consistency. For example, even if a filter specified by a Route rule is invalid, the rest of the rules within that 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.

Value	Description
"Attached"	This reason is used with the “Detached” condition when the condition is False.
"HostnameConflict"	This reason is used with the “Conflicted” condition when the Listener conflicts with hostnames in other Listeners. For example, this reason would be used when multiple Listeners on the same port use example.com in the hostname field.
"Invalid"	This reason is used with the “Ready” condition when the Listener is syntactically or semantically invalid.
"InvalidCertificateRef"	This reason is used with the “ResolvedRefs” condition when the Listener has a TLS configuration with at least one TLS CertificateRef that is invalid or cannot be resolved.
"InvalidRouteKinds"	This reason is used with the “ResolvedRefs” condition when an invalid or unsupported Route kind is specified by the Listener.
"NoConflicts"	This reason is used with the “Conflicted” condition when the condition is False.
"Pending"	This reason is used with the “Ready” condition when the Listener is not yet not online and ready to accept client traffic.
"PortUnavailable"	This reason is used with the “Detached” condition when the Listener requests a port that cannot be used on the Gateway. This reason could be used in a number of instances, including: The port is already in use. The port is not supported by the implementation.
"ProtocolConflict"	This reason is used with the “Conflicted” condition when multiple Listeners are specified with the same Listener port number, but have conflicting protocol specifications.
"Ready"	This reason is used with the “Ready” condition when the condition is true.
"RefNotPermitted"	This reason is used with the “ResolvedRefs” condition when one of the Listener’s Routes has a BackendRef to an object in another namespace, where the object in the other namespace does not have a ReferencePolicy explicitly allowing the reference.
"ResolvedRefs"	This reason is used with the “ResolvedRefs” condition when the condition is true.
"RouteConflict"	This reason is used with the “Conflicted” condition when the route resources selected for this Listener conflict with other specified properties of the Listener (e.g. Protocol). For example, a Listener that specifies “UDP” as the protocol but a route selector that resolves “TCPRoute” objects.
"UnsupportedAddress"	This reason is used with the “Detached” condition when the Listener could not be attached to the Gateway because the requested address is not supported. This reason could be used in a number of instances, including: The address is already in use. The type of address is not supported by the implementation.
"UnsupportedExtension"	This reason is used with the “Detached” condition when the controller detects that an implementation-specific Listener extension is being requested, but is not able to support the extension.
"UnsupportedProtocol"	This reason is used with the “Detached” condition when the Listener could not be attached to be Gateway because its protocol type is not supported.

ListenerConditionType (string alias)

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

Value	Description
"Conflicted"	This condition indicates that the controller was unable to resolve conflicting specification requirements for this Listener. If a Listener is conflicted, its network port should not be configured on any network elements. Possible reasons for this condition to be true are: “HostnameConflict” “ProtocolConflict” “RouteConflict” Possible reasons for this condition to be False are: “NoConflicts” Controllers may raise this condition with other reasons, but should prefer to use the reasons listed above to improve interoperability.
"Detached"	This condition indicates that, even though the listener is syntactically and semantically valid, the controller is not able to configure it on the underlying Gateway infrastructure. A Listener is specified as a logical requirement, but needs to be configured on a network endpoint (i.e. address and port) by a controller. The controller may be unable to attach the Listener if it specifies an unsupported requirement, or prerequisite resources are not available. Possible reasons for this condition to be true are: “PortUnavailable” “UnsupportedExtension” “UnsupportedProtocol” “UnsupportedAddress” Possible reasons for this condition to be False are: “Attached” Controllers may raise this condition with other reasons, but should prefer to use the reasons listed above to improve interoperability.
"Ready"	This condition indicates whether the Listener has been configured on the Gateway. Possible reasons for this condition to be true are: “Ready” Possible reasons for this condition to be False are: “Invalid” “Pending” Controllers may raise this condition with other reasons, but should prefer to use the reasons listed above to improve interoperability.
"ResolvedRefs"	This condition indicates whether the controller was able to resolve all the object references for the Listener. Possible reasons for this condition to be true are: “ResolvedRefs” Possible reasons for this condition to be False are: “InvalidCertificateRef” “InvalidRouteKinds” “RefNotPermitted” Controllers may raise this condition with other reasons, but should prefer to use the reasons listed above to improve interoperability.

ListenerStatus

(Appears on: GatewayStatus)

ListenerStatus is the status associated with a Listener.

Field	Description
name SectionName	Name is the name of the Listener that this status corresponds to.
supportedKinds []RouteGroupKind	SupportedKinds is the list indicating the Kinds supported by this listener. This MUST represent the kinds an implementation supports for that Listener configuration. If kinds are specified in Spec that are not supported, they MUST NOT appear in this list and an implementation MUST set the “ResolvedRefs” condition to “False” with the “InvalidRouteKinds” reason. If both valid and invalid Route kinds are specified, the implementation MUST reference the valid Route kinds that have been specified.
attachedRoutes int32	AttachedRoutes represents the total number of Routes that have been successfully attached to this Listener.
conditions []Kubernetes meta/v1.Condition	Conditions describe the current condition of this listener.

LocalObjectReference

(Appears on: HTTPRouteFilter)

LocalObjectReference identifies an API object within the namespace of the referrer. The API object must be valid in the cluster; the Group and Kind must be registered in the cluster for this reference to be valid.

References to objects with invalid Group and Kind are not valid, and must be rejected by the implementation, with appropriate Conditions set on the containing object.

Field	Description
group Group	Group is the group of the referent. For example, “networking.k8s.io”. When unspecified (empty string), core API group is inferred.
kind Kind	Kind is kind of the referent. For example “HTTPRoute” or “Service”.
name ObjectName	Name is the name of the referent.

Namespace (string alias)

(Appears on: BackendObjectReference, ParametersReference, ParentRef, PolicyTargetReference, ReferencePolicyFrom, SecretObjectReference)

Namespace refers to a Kubernetes namespace. It must be a RFC 1123 label.

This validation is based off of the corresponding Kubernetes validation: https://github.com/kubernetes/apimachinery/blob/02cfb53916346d085a6c6c7c66f882e3c6b0eca6/pkg/util/validation/validation.go#L187

This is used for Namespace name validation here: https://github.com/kubernetes/apimachinery/blob/02cfb53916346d085a6c6c7c66f882e3c6b0eca6/pkg/api/validation/generic.go#L63

Valid values include:

• “example”

Invalid values include:

• “example.com” - “.” is an invalid character

ObjectName (string alias)

(Appears on: BackendObjectReference, GatewaySpec, LocalObjectReference, ParentRef, PolicyTargetReference, ReferencePolicyTo, SecretObjectReference)

ObjectName refers to the name of a Kubernetes object. Object names can have a variety of forms, including RFC1123 subdomains, RFC 1123 labels, or RFC 1035 labels.

ParametersReference

(Appears on: GatewayClassSpec)

ParametersReference identifies an API object containing controller-specific configuration resource within the cluster.

Field	Description
group Group	Group is the group of the referent.
kind Kind	Kind is kind of the referent.
name string	Name is the name of the referent.
namespace Namespace	(Optional) Namespace is the namespace of the referent. This field is required when referring to a Namespace-scoped resource and MUST be unset when referring to a Cluster-scoped resource.

ParentRef

(Appears on: CommonRouteSpec, RouteParentStatus)

ParentRef identifies an API object (usually a Gateway) that can be considered a parent of this resource (usually a route). The only kind of parent resource with “Core” support is Gateway. This API may be extended in the future to support additional kinds of parent resources, such as HTTPRoute.

The API object must be valid in the cluster; the Group and Kind must be registered in the cluster for this reference to be valid.

References to objects with invalid Group and Kind are not valid, and must be rejected by the implementation, with appropriate Conditions set on the containing object.

Field	Description
group Group	(Optional) Group is the group of the referent. Support: Core
kind Kind	(Optional) Kind is kind of the referent. Support: Core (Gateway) Support: Custom (Other Resources)
namespace Namespace	(Optional) Namespace is the namespace of the referent. When unspecified (or empty string), this refers to the local namespace of the Route. Support: Core
name ObjectName	Name is the name of the referent. Support: Core
sectionName SectionName	(Optional) SectionName is the name of a section within the target resource. In the following resources, SectionName is interpreted as the following: Gateway: Listener Name Implementations MAY choose to support attaching Routes to other resources. If that is the case, they MUST clearly document how SectionName is interpreted. When unspecified (empty string), this will reference the entire resource. For the purpose of status, an attachment is considered successful if at least one section in the parent resource accepts it. For example, Gateway listeners can restrict which Routes can attach to them by Route kind, namespace, or hostname. If 1 of 2 Gateway listeners accept attachment from the referencing Route, the Route MUST be considered successfully attached. If no Gateway listeners accept attachment from this Route, the Route MUST be considered detached from the Gateway. Support: Core

PathMatchType (string alias)

(Appears on: HTTPPathMatch)

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

• “Exact”
• “PathPrefix”
• “RegularExpression”

PathPrefix and Exact paths must be syntactically valid:

• Must begin with the / character
• Must not contain consecutive / characters (e.g. /foo///, //).

Value	Description
"Exact"	Matches the URL path exactly and with case sensitivity.
"PathPrefix"	Matches based on a URL path prefix split by /. Matching is case sensitive and done on a path element by element basis. A path element refers to the list of labels in the path split by the / separator. When specified, a trailing / is ignored. For example. the paths /abc, /abc/, and /abc/def would all match the prefix /abc, but the path /abcd would not. “PathPrefix” is semantically equivalent to the “Prefix” path type in the Kubernetes Ingress API.
"RegularExpression"	Matches if the URL path matches the given regular expression with case sensitivity. Since "RegularExpression" has custom conformance, implementations can support POSIX, PCRE, RE2 or any other regular expression dialect. Please read the implementation’s documentation to determine the supported dialect.

PolicyTargetReference

PolicyTargetReference identifies an API object to apply policy to. This should be used as part of Policy resources that can target Gateway API resources. For more information on how this policy attachment model works, and a sample Policy resource, refer to the policy attachment documentation for Gateway API.

Field	Description
group Group	Group is the group of the target resource.
kind Kind	Kind is kind of the target resource.
name ObjectName	Name is the name of the target resource.
namespace Namespace	(Optional) Namespace is the namespace of the referent. When unspecified, the local namespace is inferred. Even when policy targets a resource in a different namespace, it MUST only apply to traffic originating from the same namespace as the policy.

PortNumber (int32 alias)

(Appears on: BackendObjectReference, HTTPRequestRedirectFilter, Listener)

PortNumber defines a network port.

ProtocolType (string alias)

(Appears on: Listener)

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 listed in the table below.

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.

Valid values include:

• “HTTP” - Core support
• “example.com/bar” - Implementation-specific support

Invalid values include:

• “example.com” - must include path if domain is used
• “foo.example.com” - must include path if domain is used

Value	Description
"HTTP"	Accepts cleartext HTTP/1.1 sessions over TCP. Implementations MAY also support HTTP/2 over cleartext. If implementations support HTTP/2 over cleartext on “HTTP” listeners, that MUST be clearly documented by the implementation.
"HTTPS"	Accepts HTTP/1.1 or HTTP/2 sessions over TLS.
"TCP"	Accepts TCP sessions.
"TLS"	Accepts TLS sessions over TCP.
"UDP"	Accepts UDP packets.

QueryParamMatchType (string alias)

(Appears on: HTTPQueryParamMatch)

QueryParamMatchType specifies the semantics of how HTTP query parameter values should be compared. Valid QueryParamMatchType values are:

• “Exact”
• “RegularExpression”

Value	Description
"Exact"
"RegularExpression"

ReferencePolicyFrom

(Appears on: ReferencePolicySpec)

ReferencePolicyFrom describes trusted namespaces and kinds.

Field	Description
group Group	Group is the group of the referent. When empty, the Kubernetes core API group is inferred. Support: Core
kind Kind	Kind is the kind of the referent. Although implementations may support additional resources, the following Route types are part of the “Core” support level for this field: HTTPRoute TCPRoute TLSRoute UDPRoute
namespace Namespace	Namespace is the namespace of the referent. Support: Core

ReferencePolicySpec

(Appears on: ReferencePolicy)

ReferencePolicySpec identifies a cross namespace relationship that is trusted for Gateway API.

Field	Description
from []ReferencePolicyFrom	From describes the trusted namespaces and kinds that can reference the resources described in “To”. Each entry in this list must be considered to be an additional place that references can be valid from, or to put this another way, entries must be combined using OR. Support: Core
to []ReferencePolicyTo	To describes the resources that may be referenced by the resources described in “From”. Each entry in this list must be considered to be an additional place that references can be valid to, or to put this another way, entries must be combined using OR. Support: Core

ReferencePolicyTo

(Appears on: ReferencePolicySpec)

ReferencePolicyTo describes what Kinds are allowed as targets of the references.

Field	Description
group Group	Group is the group of the referent. When empty, the Kubernetes core API group is inferred. Support: Core
kind Kind	Kind is the kind of the referent. Although implementations may support additional resources, the following types are part of the “Core” support level for this field: Service
name ObjectName	(Optional) Name is the name of the referent. When unspecified or empty, this policy refers to all resources of the specified Group and Kind in the local namespace.

RouteConditionType (string alias)

RouteConditionType is a type of condition for a route.

Value	Description
"Accepted"	This condition indicates whether the route has been accepted or rejected by a Gateway, and why.
"ResolvedRefs"	This condition indicates whether the controller was able to resolve all the object references for the Route.

RouteGroupKind

(Appears on: AllowedRoutes, ListenerStatus)

RouteGroupKind indicates the group and kind of a Route resource.

Field	Description
group Group	(Optional) Group is the group of the Route.
kind Kind	Kind is the kind of the Route.

RouteNamespaces

(Appears on: AllowedRoutes)

RouteNamespaces indicate which namespaces Routes should be selected from.

Field	Description
from FromNamespaces	(Optional) 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

RouteParentStatus

(Appears on: RouteStatus)

RouteParentStatus describes the status of a route with respect to an associated Parent.

Field	Description
parentRef ParentRef	ParentRef corresponds with a ParentRef in the spec that this RouteParentStatus struct describes the status of.
controllerName GatewayController	ControllerName is a domain/path string that indicates the name of the controller that wrote this status. This corresponds with the controllerName field on GatewayClass. Example: “example.net/gateway-controller”. 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).
conditions []Kubernetes meta/v1.Condition	Conditions describes the status of the route with respect to the Gateway. Note that the route’s availability is also subject to the Gateway’s own status conditions and listener status. If the Route’s ParentRef specifies an existing Gateway that supports Routes of this kind AND that Gateway’s controller has sufficient access, then that Gateway’s controller MUST set the “Accepted” condition on the Route, to indicate whether the route has been accepted or rejected by the Gateway, and why. A Route MUST be considered “Accepted” if at least one of the Route’s rules is implemented by the Gateway. There are a number of cases where the “Accepted” condition may not be set due to lack of controller visibility, that includes when: The Route refers to a non-existent parent. The Route is of a type that the controller does not support. The Route is in a namespace the the controller does not have access to.

RouteStatus

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

RouteStatus defines the common attributes that all Routes MUST include within their status.

Field

Description

parents []RouteParentStatus

Parents is a list of parent resources (usually Gateways) that are associated with the route, and the status of the route with respect to each parent. When this route attaches to a parent, the controller that manages the parent must add an entry to this list when the controller first sees the route and should update the entry as appropriate when the route or gateway is modified. Note that parent references that cannot be resolved by an implementation of this API will not be added to this list. Implementations of this API can only populate Route status for the Gateways/parent resources they are responsible for. A maximum of 32 Gateways will be represented in this list. An empty list means the route has not been attached to any Gateway.

SecretObjectReference

SecretObjectReference identifies an API object including its namespace, defaulting to Secret.

The API object must be valid in the cluster; the Group and Kind must be registered in the cluster for this reference to be valid.

References to objects with invalid Group and Kind are not valid, and must be rejected by the implementation, with appropriate Conditions set on the containing object.

Field	Description
group Group	(Optional) Group is the group of the referent. For example, “networking.k8s.io”. When unspecified (empty string), core API group is inferred.
kind Kind	(Optional) Kind is kind of the referent. For example “HTTPRoute” or “Service”.
name ObjectName	Name is the name of the referent.
namespace Namespace	(Optional) Namespace is the namespace of the backend. When unspecified, the local namespace is inferred. Note that when a namespace is specified, a ReferencePolicy object is required in the referent namespace to allow that namespace’s owner to accept the reference. See the ReferencePolicy documentation for details. Support: Core

SectionName (string alias)

(Appears on: Listener, ListenerStatus, ParentRef)

SectionName is the name of a section in a Kubernetes resource.

This validation is based off of the corresponding Kubernetes validation: https://github.com/kubernetes/apimachinery/blob/02cfb53916346d085a6c6c7c66f882e3c6b0eca6/pkg/util/validation/validation.go#L208

Valid values include:

• “example.com”
• “foo.example.com”

Invalid values include:

• “example.com/bar” - “/” is an invalid character

TCPRouteRule

(Appears on: TCPRouteSpec)

TCPRouteRule is the configuration for a given rule.

Field

Description

backendRefs []BackendRef

BackendRefs defines the backend(s) where matching requests should be sent. If unspecified or invalid (refers to a non-existent resource or a Service with no endpoints), the underlying implementation MUST actively reject connection attempts to this backend. Connection rejections must respect weight; if an invalid backend is requested to have 80% of connections, then 80% of connections must be rejected instead. Support: Core for Kubernetes Service Support: Custom for any other resource Support for weight: Extended

TCPRouteSpec

(Appears on: TCPRoute)

TCPRouteSpec defines the desired state of TCPRoute

Field	Description
CommonRouteSpec CommonRouteSpec	(Members of CommonRouteSpec are embedded into this type.)
rules []TCPRouteRule	Rules are a list of TCP matchers and actions.

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 how a Gateway handles TLS sessions.

Value	Description
"Passthrough"	In this mode, 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. Note that SSL passthrough is only supported by TLSRoute.
"Terminate"	In this mode, TLS session between the downstream client and the Gateway is terminated at the Gateway.

TLSRouteRule

(Appears on: TLSRouteSpec)

TLSRouteRule is the configuration for a given rule.

Field

Description

backendRefs []BackendRef

BackendRefs defines the backend(s) where matching requests should be sent. If unspecified or invalid (refers to a non-existent resource or a Service with no endpoints), the rule performs no forwarding; if no filters are specified that would result in a response being sent, the underlying implementation must actively reject request attempts to this backend, by rejecting the connection or returning a 503 status code. Request rejections must respect weight; if an invalid backend is requested to have 80% of requests, then 80% of requests must be rejected instead. Support: Core for Kubernetes Service Support: Custom for any other resource Support for weight: Extended

TLSRouteSpec

(Appears on: TLSRoute)

TLSRouteSpec defines the desired state of a TLSRoute resource.

Field	Description
CommonRouteSpec CommonRouteSpec	(Members of CommonRouteSpec are embedded into this type.)
hostnames []Hostname	(Optional) Hostnames defines a set of SNI names that should match against the SNI attribute of TLS ClientHello message in TLS handshake. This matches the RFC 1123 definition of a hostname with 2 notable exceptions: IPs are not allowed in SNI names per RFC 6066. A hostname may be prefixed with a wildcard label (*.). The wildcard label must appear by itself as the first label. If a hostname is specified by both the Listener and TLSRoute, there must be at least one intersecting hostname for the TLSRoute to be attached to the Listener. For example: A Listener with test.example.com as the hostname matches TLSRoutes that have either not specified any hostnames, or have specified at least one of test.example.com or *.example.com. A Listener with *.example.com as the hostname matches TLSRoutes that have either not specified any hostnames or have specified at least one hostname that matches the Listener hostname. For example, test.example.com and *.example.com would both match. On the other hand, example.com and test.example.net would not match. If both the Listener and TLSRoute have specified hostnames, any TLSRoute hostnames that do not match the Listener hostname MUST be ignored. For example, if a Listener specified *.example.com, and the TLSRoute specified test.example.com and test.example.net, test.example.net must not be considered for a match. If both the Listener and TLSRoute have specified hostnames, and none match with the criteria above, then the TLSRoute is not accepted. The implementation must raise an ‘Accepted’ Condition with a status of False in the corresponding RouteParentStatus. Support: Core
rules []TLSRouteRule	Rules are a list of TLS matchers and actions.

TLSRouteStatus

(Appears on: TLSRoute)

TLSRouteStatus defines the observed state of TLSRoute

Field	Description
RouteStatus RouteStatus	(Members of RouteStatus are embedded into this type.)

UDPRouteRule

(Appears on: UDPRouteSpec)

UDPRouteRule is the configuration for a given rule.

Field

Description

backendRefs []BackendRef

BackendRefs defines the backend(s) where matching requests should be sent. If unspecified or invalid (refers to a non-existent resource or a Service with no endpoints), the underlying implementation MUST actively reject connection attempts to this backend. Packet drops must respect weight; if an invalid backend is requested to have 80% of the packets, then 80% of packets must be dropped instead. Support: Core for Kubernetes Service Support: Custom for any other resource Support for weight: Extended

UDPRouteSpec

(Appears on: UDPRoute)

UDPRouteSpec defines the desired state of UDPRoute.

Field	Description
CommonRouteSpec CommonRouteSpec	(Members of CommonRouteSpec are embedded into this type.)
rules []UDPRouteRule	Rules are a list of UDP matchers and actions.

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.