Struct gateway_api::experimental::gateways::GatewaySpec
source · pub struct GatewaySpec {
pub addresses: Option<Vec<GatewayAddresses>>,
pub gateway_class_name: String,
pub listeners: Vec<GatewayListeners>,
}
Expand description
Spec defines the desired state of Gateway.
Fields
addresses: Option<Vec<GatewayAddresses>>
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: Extended
gateway_class_name: String
GatewayClassName used for this Gateway. This is the name of a GatewayClass resource.
listeners: Vec<GatewayListeners>
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
Trait Implementations
sourceimpl Clone for GatewaySpec
impl Clone for GatewaySpec
sourcefn clone(&self) -> GatewaySpec
fn clone(&self) -> GatewaySpec
1.0.0 · sourcefn clone_from(&mut self, source: &Self)
fn clone_from(&mut self, source: &Self)
source
. Read moresourceimpl Debug for GatewaySpec
impl Debug for GatewaySpec
sourceimpl<'de> Deserialize<'de> for GatewaySpec
impl<'de> Deserialize<'de> for GatewaySpec
sourcefn deserialize<__D>(__deserializer: __D) -> Result<Self, __D::Error>where
__D: Deserializer<'de>,
fn deserialize<__D>(__deserializer: __D) -> Result<Self, __D::Error>where
__D: Deserializer<'de>,
sourceimpl JsonSchema for GatewaySpec
impl JsonSchema for GatewaySpec
sourcefn schema_name() -> String
fn schema_name() -> String
sourcefn json_schema(gen: &mut SchemaGenerator) -> Schema
fn json_schema(gen: &mut SchemaGenerator) -> Schema
sourcefn is_referenceable() -> bool
fn is_referenceable() -> bool
$ref
keyword. Read more