PolicyStatus: status"]] + spec[["spec
PolicyTargetReferenceWithSectionName: targetRefs
BackendTLSPolicyValidation: tls"]] + status[["status
[ ]PolicyAncestorStatus: ancestors"]] + validation[["tls
LocalObjectReference: caCertificateRefs
wellKnownCACertificatesType: wellKnownCACertificates/
PreciseHostname: hostname"]] + ancestorStatus[["ancestors
AncestorRef: parentReference
GatewayController: controllerName
[]Condition: conditions"]] + targetRefs[[targetRefs
]] + service["service"] + backendTLSPolicy -->spec + backendTLSPolicy -->status + spec -->targetRefs & validation + status -->ancestorStatus + targetRefs -->service + note[choose only one
caCertificateRefs OR wellKnownCACertificates] + style note fill:#fff + validation -.- note +``` + +The following illustrates a BackendTLSPolicy that configures TLS for a Service serving a backend: +```mermaid +flowchart LR + client(["client"]) + gateway["Gateway"] + style gateway fill:#02f,color:#fff + httproute["HTTP
Route"] + style httproute fill:#02f,color:#fff + service["Service"] + style service fill:#02f,color:#fff + pod1["Pod"] + style pod1 fill:#02f,color:#fff + pod2["Pod"] + style pod2 fill:#02f,color:#fff + client -.->|HTTP
request| gateway + gateway --> httproute + httproute -.->|BackendTLSPolicy|service + service --> pod1 & pod2 +``` + +### Targeting backends + +A BackendTLSPolicy targets a backend Pod (or set of Pods) via one or more TargetRefs to a Service. This TargetRef is a +required object reference that specifies a Service by its Name, Kind (Service), and optionally its Namespace and Group. +TargetRefs identify the Service/s for which your HTTPRoute requires TLS. + +!!! info "Restrictions" + + - Cross-namespace certificate references are not allowed. + +### BackendTLSPolicyValidation + +A BackendTLSPolicyValidation is the specification for the BackendTLSPolicy and defines the configuration for TLS, +including hostname (for server name indication) and certificates. + +#### Hostname + +Hostname defines the server name indication (SNI) the Gateway should use in order to connect to the backend, and must +match the certificate served by the backend pod. A hostname is the fully qualified domain name of a network host, as +defined by [RFC 3986][rfc-3986]. Note the following deviations from the “host” part of the URI as defined in the RFC: + +- IP addresses are not allowed. + +Also note: + +!!! info "Restrictions" + + - Wildcard hostnames are not allowed. + +#### Certificates + +The BackendTLSPolicyValidation must contain a certificate reference of some kind, and contains two ways to configure the +certificate to use for backend TLS, CACertificateRefs and WellKnownCACertificates. Only one of these may be used per +BackendTLSPolicyValidation. + +##### CACertificateRefs + +CACertificateRefs refer to one or more PEM-encoded TLS certificates. + +!!! info "Restrictions" + + - Cross-namespace certificate references are not allowed. + +##### WellKnownCACertificates + +If you are working in an environment where specific TLS certificates are not required, and your Gateway API +implementation allows system or default certificates to be used, e.g. in a development environment, you may +set WellKnownCACertificates to "System" to tell the Gateway to use a set of trusted CA Certificates. There may be +some variation in which system certificates are used by each implementation. Refer to documentation from your +implementation of choice for more information. + +### PolicyStatus + +Status defines the observed state of the BackendTLSPolicy and is not user-configurable. Check status in the same +way you do for other Gateway API objects to verify correct operation. Note that the status in BackendTLSPolicy +uses `PolicyAncestorStatus` to allow you to know which parentReference set that particular status. + +[backendtlspolicy]: ../reference/spec.md#gateway.networking.k8s.io/v1alpha3.BackendTLSPolicy +[validation]: ../reference/spec.md#gateway.networking.k8s.io/v1alpha3.BackendTLSPolicy.Validation +[caCertificateRefs]: ../reference/spec.md#gateway.networking.k8s.io/v1alpha3.BackendTLSPolicyValidation.CACertificateRefs +[wellKnownCACertificates]: ../reference/spec.md#gateway.networking.k8s.io/v1alpha3.BackendTLSPolicyValidation.WellKnownCACertificates +[hostname]: ../reference/spec.md#gateway.networking.k8s.io/v1.PreciseHostname +[rfc-3986]: https://tools.ietf.org/html/rfc3986 +[targetRefs]: ../reference/spec.md#gateway.networking.k8s.io/v1alpha2.PolicyTargetReference diff --git a/site-src/ko/api-types/backendtrafficpolicy.md b/site-src/ko/api-types/backendtrafficpolicy.md new file mode 100644 index 0000000000..61dd645229 --- /dev/null +++ b/site-src/ko/api-types/backendtrafficpolicy.md @@ -0,0 +1,93 @@ +# BackendTrafficPolicy + +??? example "Experimental Channel since v1.3.0" + + The `BackendTrafficPolicy` resource is a part of the Experimental Channel + since `v1.3.0`. For more information on release channels, refer to our + [versioning guide](../concepts/versioning.md). + +[BackendTrafficPolicy][backendtrafficpolicy] is a Gateway API type to configure +the behavior of clients when targeting a valid backend resource. + +## Background + +`BackendTrafficPolicy` is used to configure the behavior of clients when making +requests targeting a backend, a grouping of like endpoints. Currently, this +policy includes the ability to configure a `RetryConstraint`, which can +dynamically limit the number of active retries targeting the specified backend, +by defining a "retry budget". Additional features may be added in the future. + +### Retry Constraint + +While client-side retries are important for allowing requests to be +successfully retried in +periods of intermittent failure, excessive retries can quickly overwhelm a +system, leading to cascading failures such as retry storms. Specifying a +`RetryConstraint` within `BackendTrafficPolicy` allows application +developers to dynamically calculate a limit on active client-side retries as a percentage of +the overall active request volume. While the retry stanza within the +[HTTPRouteRule][httproute] resource allows specifying whether a request +*should* be retried, as well as the maximum number of +retries that may be performed for a failed request, budgeted +retries instead act as a +fail-safe in order to ensure that the targeted backend will not be overwhelmed +by the *overall* volume of retries from the client. + +The retry budget is calculated based on the percentage of incoming traffic +composed of retries over a given time interval. Retrying the same original +request multiple times within the retry budget interval will lead to each retry +being counted towards calculating the budget. Once the budget is exceeded, +additional retries to the backend will be rejected and MUST return a 503 +response to the client. The parameters of the retry budget calculation can be +configured within `RetryConstraint`. + +BackendTrafficPolicy is a Direct +[PolicyAttachment](../reference/policy-attachment.md). All Gateway API Routes +that target the referenced Backend should respect a configured +BackendTrafficPolicy. Additional configurations for defining a constraint on +retries MAY be defined in the future. + + +## Spec + +The specification of a [BackendTrafficPolicy][backendtrafficpolicy] consists of: + +- [TargetRefs][localpolicytargetreference] - Defines the targeted API object(s) of the policy. + Backends (A grouping of like endpoints such as Service, + ServiceImport, or any implementation-specific backendRef) are the only valid + API target references. +- [RetryConstraint][retryConstraint] - Defines the configuration for how a retry budget should be calculated, by specifying BudgetDetails and MinRetryRate. +- [SessionPersistence][sessionPersistence] - Defines the session persistence for the backend. + +The following chart outlines the object definitions and relationship: +```mermaid +flowchart LR + backendTrafficPolicy[["backendTrafficPolicy
PolicyStatus: status"]] + spec[["spec
LocalPolicyTargetReference: targetRefs
RetryConstraint: retryConstraint"
SessionPersistence: sessionPersistence]] + status[["status
[ ]PolicyAncestorStatus: ancestors"]] + budget[["budget
int: budgetPercent
Duration: budgetInterval"]] + retryConstraint[["retryConstraint
BudgetDetails: budget
MinRetryRate: RequestRate"]] + ancestorStatus[["ancestors
AncestorRef: parentReference
GatewayController: controllerName
[]Condition: conditions"]] + targetRefs[[targetRefs
]] + backendRef["one of:
" Service OR ServiceImport OR an implementation-specific backendRef] + backendTrafficPolicy -->spec + backendTrafficPolicy -->status + spec -->targetRefs & retryConstraint + retryConstraint -->budget + status -->ancestorStatus + targetRefs -->backendRef +``` + +### Targeting backends + +`BackendTrafficPolicy` targets a group of backend Pods via one or more +TargetRefs such as Service, ServiceImport, or implementation-specific +backendRef. TargetRefs is a required object reference, specifying a Backend via +its Name, Kind, and Group. Currently, TargetRefs can not be scoped to +specific ports on a service. + +[backendtrafficpolicy]: /references/specx.md#xbackendtrafficpolicy +[localpolicytargetreference]: /references/spec/#gateway.networking.k8s.io/v1alpha2.LocalPolicyTargetReference +[retryConstraint]: /references/specx.md#retryconstraint +[sessionPersistence]: /references/spec/#gateway.networking.k8s.io/v1.SessionPersistence +[httproute]: /references/spec/#https://gateway-api.sigs.k8s.io/reference/spec/#gateway.networking.k8s.io/v1beta1.HTTPRoute diff --git a/site-src/ko/api-types/gateway.md b/site-src/ko/api-types/gateway.md new file mode 100644 index 0000000000..372eab5a89 --- /dev/null +++ b/site-src/ko/api-types/gateway.md @@ -0,0 +1,53 @@ +# Gateway + +??? success "Standard Channel since v0.5.0" + + The `Gateway` resource is GA and has been part of the Standard Channel since + `v0.5.0`. For more information on release channels, refer to our [versioning + guide](../concepts/versioning.md). + +A `Gateway` is 1:1 with the lifecycle of the configuration of infrastructure. +When a user creates a `Gateway`, some load balancing infrastructure is +provisioned or configured (see below for details) by the `GatewayClass` +controller. `Gateway` is the resource that triggers actions in this API. Other +resources in this API are configuration snippets until a Gateway has been +created to link the resources together. + +The `Gateway` spec defines the following: + +* `GatewayClassName`- Defines the name of a `GatewayClass` object used by + this Gateway. +* `Listeners`- Define the hostnames, ports, protocol, termination, TLS + settings and which routes can be attached to a listener. +* `Addresses`- Define the network addresses requested for this gateway. + +If the desired configuration specified in Gateway spec cannot be achieved, the +Gateway will be in an error state with details provided by status conditions. + +### Deployment models + +Depending on the `GatewayClass`, the creation of a `Gateway` could do any of +the following actions: + +* Use cloud APIs to create an LB instance. +* Spawn a new instance of a software LB (in this or another cluster). +* Add a configuration stanza to an already instantiated LB to handle the new + routes. +* Program the SDN to implement the configuration. +* Something else we haven’t thought of yet... + +The API does not specify which one of these actions will be taken. + +### Gateway Status + +`GatewayStatus` is used to surface the status of a `Gateway` relative to the +desired state represented in `spec`. `GatewayStatus` consists of the following: + +- `Addresses`- Lists the IP addresses that have actually been bound to the + Gateway. +- `Listeners`- Provide status for each unique listener defined in `spec`. +- `Conditions`- Describe the current status conditions of the Gateway. + +Both `Conditions` and `Listeners.conditions` follow the conditions pattern used +elsewhere in Kubernetes. This is a list that includes a type of condition, the +status of the condition and the last time this condition changed. diff --git a/site-src/ko/api-types/gatewayclass.md b/site-src/ko/api-types/gatewayclass.md new file mode 100644 index 0000000000..9eb2fd674e --- /dev/null +++ b/site-src/ko/api-types/gatewayclass.md @@ -0,0 +1,145 @@ +# GatewayClass + +??? success "Standard Channel since v0.5.0" + + The `GatewayClass` resource is GA and has been part of the Standard Channel since + `v0.5.0`. For more information on release channels, refer to our [versioning + guide](../concepts/versioning.md). + +[GatewayClass][gatewayclass] is cluster-scoped resource defined by the +infrastructure provider. This resource represents a class of Gateways that can +be instantiated. + +> Note: GatewayClass serves the same function as the +> [`networking.IngressClass` resource][ingress-class-api]. + +```yaml +kind: GatewayClass +metadata: + name: cluster-gateway +spec: + controllerName: "example.net/gateway-controller" +``` + +We expect that one or more `GatewayClasses` will be created by the +infrastructure provider for the user. It allows decoupling of which mechanism +(e.g. controller) implements the `Gateways` from the user. For instance, an +infrastructure provider may create two `GatewayClasses` named `internet` and +`private` to reflect `Gateways` that define Internet-facing vs private, internal +applications. + +```yaml +kind: GatewayClass +metadata: + name: internet + ... +--- +kind: GatewayClass +metadata: + name: private + ... +``` + +The user of the classes will not need to know *how* `internet` and `private` are +implemented. Instead, the user will only need to understand the resulting +properties of the class that the `Gateway` was created with. + +### GatewayClass parameters + +Providers of the `Gateway` API may need to pass parameters to their controller +as part of the class definition. This is done using the +`GatewayClass.spec.parametersRef` field: + +```yaml +# GatewayClass for Gateways that define Internet-facing applications. +kind: GatewayClass +metadata: + name: internet +spec: + controllerName: "example.net/gateway-controller" + parametersRef: + group: example.net + kind: Config + name: internet-gateway-config +--- +apiVersion: example.net/v1alpha1 +kind: Config +metadata: + name: internet-gateway-config +spec: + ip-address-pool: internet-vips + ... +``` + +Using a Custom Resource for `GatewayClass.spec.parametersRef` is encouraged +but implementations may resort to using a ConfigMap if needed. + +### GatewayClass status + +`GatewayClasses` MUST be validated by the provider to ensure that the configured +parameters are valid. The validity of the class will be signaled to the user via +`GatewayClass.status`: + +```yaml +kind: GatewayClass +... +status: + conditions: + - type: Accepted + status: False + ... +``` + +A new `GatewayClass` will start with the `Accepted` condition set to +`False`. At this point the controller has not seen the configuration. Once the +controller has processed the configuration, the condition will be set to +`True`: + +```yaml +kind: GatewayClass +... +status: + conditions: + - type: Accepted + status: True + ... +``` + +If there is an error in the `GatewayClass.spec`, the conditions will be +non-empty and contain information about the error. + +```yaml +kind: GatewayClass +... +status: + conditions: + - type: Accepted + status: False + Reason: BadFooBar + Message: "foobar" is an FooBar. +``` + +### GatewayClass controller selection + +The `GatewayClass.spec.controller` field determines the controller implementation +responsible for managing the `GatewayClass`. The format of the field is opaque +and specific to a particular controller. The GatewayClass selected by a given +controller field depends on how various controller(s) in the cluster interpret +this field. + +It is RECOMMENDED that controller authors/deployments make their selection +unique by using a domain / path combination under their administrative control +(e.g. controller managing of all `controller`s starting with `example.net` is the +owner of the `example.net` domain) to avoid conflicts. + +Controller versioning can be done by encoding the version of a controller into +the path portion. An example scheme could be (similar to container URIs): + +```text +example.net/gateway/v1 // Use version 1 +example.net/gateway/v2.1 // Use version 2.1 +example.net/gateway // Use the default version +``` + +[gatewayclass]: ../reference/spec.md#gateway.networking.k8s.io/v1.GatewayClass +[ingress-class-api]: https://kubernetes.io/docs/concepts/services-networking/ingress/#ingress-class diff --git a/site-src/ko/api-types/grpcroute.md b/site-src/ko/api-types/grpcroute.md new file mode 100644 index 0000000000..2b6188ad47 --- /dev/null +++ b/site-src/ko/api-types/grpcroute.md @@ -0,0 +1,283 @@ +# GRPCRoute + +??? success "Standard Channel since v1.1.0" + + The `GRPCRoute` resource is GA and has been part of the Standard Channel since + `v1.1.0`. For more information on release channels, refer to our [versioning + guide](../concepts/versioning.md). + +[GRPCRoute][grpcroute] is a Gateway API type for specifying routing behavior +of gRPC requests from a Gateway listener to an API object, i.e. Service. + +## Background + +While it is possible to route gRPC with `HTTPRoutes` or via custom, out-of-tree +CRDs, in the long run, this leads to a fragmented ecosystem. + +gRPC is a [popular RPC framework adopted widely across the industry](https://grpc.io/about/#whos-using-grpc-and-why). +The protocol is used pervasively within the Kubernetes project itself as the basis for +many interfaces, including: + +- [the CSI](https://github.com/container-storage-interface/spec/blob/5b0d4540158a260cb3347ef1c87ede8600afb9bf/spec.md), +- [the CRI](https://github.com/kubernetes/cri-api/blob/49fe8b135f4556ea603b1b49470f8365b62f808e/README.md), +- [the device plugin framework](https://kubernetes.io/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) + +Given gRPC's importance in the application-layer networking space and to +the Kubernetes project in particular, the determination was made not to allow +the ecosystem to fragment unnecessarily. + +### Encapsulated Network Protocols + +In general, when it is possible to route an encapsulated protocol at a lower +level, it is acceptable to introduce a route resource at the higher layer when +the following criteria are met: + +- Users of the encapsulated protocol would miss out on significant conventional features from their ecosystem if forced to route at a lower layer. +- Users of the encapsulated protocol would experience a degraded user experience if forced to route at a lower layer. +- The encapsulated protocol has a significant user base, particularly in the Kubernetes community. + +gRPC meets all of these criteria, so the decision was made to include `GRPCRoute`in Gateway API. + +### Cross Serving + +Implementations that support GRPCRoute must enforce uniqueness of +hostnames between `GRPCRoute`s and `HTTPRoute`s. If a route (A) of type `HTTPRoute` or +`GRPCRoute` is attached to a Listener and that listener already has another Route (B) of +the other type attached and the intersection of the hostnames of A and B is +non-empty, then the implementation must reject Route A. That is, the +implementation must raise an 'Accepted' condition with a status of 'False' in +the corresponding RouteParentStatus. + +In general, it is recommended that separate hostnames be used for gRPC and +non-gRPC HTTP traffic. This aligns with standard practice in the gRPC community. +If however, it is a necessity to serve HTTP and gRPC on the same hostname with +the only differentiator being URI, the user should use `HTTPRoute` resources for +both gRPC and HTTP. This will come at the cost of the improved UX of the +`GRPCRoute` resource. + +## Spec + +The specification of a GRPCRoute consists of: + +- [ParentRefs][parentRef]- Define which Gateways this Route wants to be attached + to. +- [Hostnames][hostname] (optional)- Define a list of hostnames to use for + matching the Host header of gRPC requests. +- [Rules][grpcrouterule]- Define a list of rules to perform actions against + matching gRPC requests. Each rule consists of [matches][matches], + [filters][filters] (optional), [backendRefs][backendRef] (optional), and + [name][name] (optional) fields. + + +The following illustrates a GRPCRoute that sends all traffic to one Service: + + +### Attaching to Gateways + +Each Route includes a way to reference the parent resources it wants to attach +to. In most cases, that's going to be Gateways, but there is some flexibility +here for implementations to support other types of parent resources. + +The following example shows how a Route would attach to the `acme-lb` Gateway: + +```yaml +apiVersion: gateway.networking.k8s.io/v1 +kind: GRPCRoute +metadata: + name: grpcroute-example +spec: + parentRefs: + - name: acme-lb +``` + +Note that the target Gateway needs to allow GRPCRoutes from the route's +namespace to be attached for the attachment to be successful. + +### Hostnames + +Hostnames define a list of hostnames to match against the Host header of the +gRPC request. When a match occurs, the GRPCRoute is selected to perform request +routing based on rules and filters (optional). A hostname is the fully qualified +domain name of a network host, as defined by [RFC 3986][rfc-3986]. Note the +following deviations from the “host” part of the URI as defined in the RFC: + +- IPs are not allowed. +- The : delimiter is not respected because ports are not allowed. + +Incoming requests are matched against hostnames before the GRPCRoute rules are +evaluated. If no hostname is specified, traffic is routed based on GRPCRoute +rules and filters (optional). + +The following example defines hostname "my.example.com": + +```yaml +apiVersion: gateway.networking.k8s.io/v1 +kind: GRPCRoute +metadata: + name: grpcroute-example +spec: + hostnames: + - my.example.com +``` + +### Rules + +Rules define semantics for matching an gRPC requests based on conditions, +optionally executing additional processing steps, and optionally forwarding +the request to an API object. + +#### Matches + +Matches define conditions used for matching an gRPC requests. Each match is +independent, i.e. this rule will be matched if any single match is satisfied. + +Take the following matches configuration as an example: + +```yaml +apiVersion: gateway.networking.k8s.io/v1 +kind: GRPCRoute +... +matches: + - method: + service: com.example.User + method: Login + headers: + - name: version + value: "2" + - method: + service: com.example.v2.User + method: Login +``` + +For a request to match against this rule, it must satisfy EITHER of the +following conditions: + + - The `com.example.User.Login` method **AND** contains the header "version: 2" + - The `com.example.v2.User.Login` method. + +If no matches are specified, the default is to match every gRPC request. + +#### Filters (optional) + +Filters define processing steps that must be completed during the request or +response lifecycle. Filters act as an extension point to express additional +processing that may be performed in Gateway implementations. Some examples +include request or response modification, implementing authentication +strategies, rate-limiting, and traffic shaping. + +The following example adds header "my-header: foo" to gRPC requests with Host +header "my.filter.com". Note that GRPCRoute uses HTTPRoute filters for features +with functionality identical to HTTPRoute, such as this. + +```yaml +{% include 'standard/grpc-filter.yaml' %} +``` + +API conformance is defined based on the filter type. The effects of ordering +multiple behaviors are currently unspecified. This may change in the future +based on feedback during the alpha stage. + +Conformance levels are defined by the filter type: + + - All "core" filters MUST be supported by implementations supporting GRPCRoute. + - Implementers are encouraged to support "extended" filters. + - "Implementation-specific" filters have no API guarantees across implementations. + +Specifying a core filter multiple times has unspecified or custom conformance. + +If an implementation cannot support a combinations of filters, they must clearly +document that limitation. In cases where incompatible or unsupported +filters are specified and cause the `Accepted` condition to be set to status +`False`, implementations may use the `IncompatibleFilters` reason to specify +this configuration error. + +#### BackendRefs (optional) + +BackendRefs defines the API objects to which 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, an `UNIMPLEMENTED` error code +is returned. + +The following example forwards gRPC requests for the method `User.Login` to service +"my-service1" on port `50051` and gRPC requests for the method `Things.DoThing` with +header `magic: foo` to service "my-service2" on port `50051`: + +```yaml +{% include 'standard/basic-grpc.yaml' %} +``` + +The following example uses the `weight` field to forward 90% of gRPC requests to +`foo.example.com` to the "foo-v1" Service and the other 10% to the "foo-v2" +Service: + +```yaml +{% include 'standard/traffic-splitting/grpc-traffic-split-2.yaml' %} +``` + +Reference the [backendRef][backendRef] API documentation for additional details +on `weight` and other fields. + +#### Name (optional) + +??? example "Experimental Channel since v1.2.0" + + This concept has been part of the Experimental Channel since `v1.2.0`. + For more information on release channels, refer to our + [versioning guide](../concepts/versioning.md). + +GRPCRoute Rules include an optional `name` field. The applications for the name of a route rule are implementation-specific. It can be used to reference individual route rules by name from other resources, such as in the `sectionName` field of metaresources ([GEP-2648](../geps/gep-2648/index.md#section-names)), in the status stanzas of resources related to the route object, to identify internal configuration objects generated by the implementation from GRPCRoute Rule, etc. + +If specified, the value of the name field must comply with the [`SectionName`](https://github.com/kubernetes-sigs/gateway-api/blob/v1.0.0/apis/v1/shared_types.go#L607-L624) type. + +## Status + +Status defines the observed state of the GRPCRoute. + +### RouteStatus + +RouteStatus defines the observed state that is required across all route types. + +#### Parents + +Parents define a list of the Gateways (or other parent resources) that are +associated with the GRPCRoute, and the status of the GRPCRoute with respect to +each of these Gateways. When a GRPCRoute adds a reference to a Gateway in +parentRefs, 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. + +## Examples + +The following example indicates GRPCRoute "grpc-example" has been accepted by +Gateway "gw-example" in namespace "gw-example-ns": + +```yaml +apiVersion: gateway.networking.k8s.io/v1 +kind: GRPCRoute +metadata: + name: grpc-example +... +status: + parents: + - parentRefs: + name: gw-example + namespace: gw-example-ns + conditions: + - type: Accepted + status: "True" +``` + +## Merging +Multiple GRPCRoutes can be attached to a single Gateway resource. Importantly, +only one Route rule may match each request. For more information on how conflict +resolution applies to merging, refer to the [API specification][grpcrouterule]. + +[grpcroute]: ../reference/spec.md#gateway.networking.k8s.io/v1.GRPCRoute +[grpcrouterule]: ../reference/spec.md#gateway.networking.k8s.io/v1.GRPCRouteRule +[hostname]: ../reference/spec.md#gateway.networking.k8s.io/v1.Hostname +[rfc-3986]: https://tools.ietf.org/html/rfc3986 +[matches]: ../reference/spec.md#gateway.networking.k8s.io/v1.GRPCRouteMatch +[filters]: ../reference/spec.md#gateway.networking.k8s.io/v1.GRPCRouteFilter +[backendRef]: ../reference/spec.md#gateway.networking.k8s.io/v1.GRPCBackendRef +[parentRef]: ../reference/spec.md#gateway.networking.k8s.io/v1.ParentRef +[name]: ../reference/spec.md#gateway.networking.k8s.io/v1.SectionName diff --git a/site-src/ko/api-types/httproute.md b/site-src/ko/api-types/httproute.md new file mode 100644 index 0000000000..0551a37c3d --- /dev/null +++ b/site-src/ko/api-types/httproute.md @@ -0,0 +1,349 @@ +# HTTPRoute + +??? success "Standard Channel since v0.5.0" + + The `HTTPRoute` resource is GA and has been part of the Standard Channel since + `v0.5.0`. For more information on release channels, refer to our [versioning + guide](../concepts/versioning.md). + +[HTTPRoute][httproute] is a Gateway API type for specifying routing behavior +of HTTP requests from a Gateway listener to an API object, i.e. Service. + +## Spec + +The specification of an HTTPRoute consists of: + +- [ParentRefs][parentRef]- Define which Gateways this Route wants to be attached + to. +- [Hostnames][hostname] (optional)- Define a list of hostnames to use for + matching the Host header of HTTP requests. +- [Rules][httprouterule]- Define a list of rules to perform actions against + matching HTTP requests. Each rule consists of [matches][matches], + [filters][filters] (optional), [backendRefs][backendRef] (optional), + [timeouts][timeouts] (optional), and [name][sectionName] (optional) fields. + +The following illustrates an HTTPRoute that sends all traffic to one Service: + + +### Attaching to Gateways + +Each Route includes a way to reference the parent resources it wants to attach +to. In most cases, that's going to be Gateways, but there is some flexibility +here for implementations to support other types of parent resources. + +The following example shows how a Route would attach to the `acme-lb` Gateway: + +```yaml +apiVersion: gateway.networking.k8s.io/v1 +kind: HTTPRoute +metadata: + name: httproute-example +spec: + parentRefs: + - name: acme-lb +``` + +Note that the target Gateway needs to allow HTTPRoutes from the route's +namespace to be attached for the attachment to be successful. + +You can also attach routes to specific sections of the parent resource. +For example, let's say that the `acme-lb` Gateway includes the following +listeners: + +```yaml + listeners: + - name: foo + protocol: HTTP + port: 8080 + ... + - name: bar + protocol: HTTP + port: 8090 + ... + - name: baz + protocol: HTTP + port: 8090 + ... +``` + +You can bind a route to listener `foo` only, using the `sectionName` field +in `parentRefs`: + +```yaml +spec: + parentRefs: + - name: acme-lb + sectionName: foo +``` + +Alternatively, you can achieve the same effect by using the `port` field, +instead of `sectionName`, in the `parentRefs`: + +```yaml +spec: + parentRefs: + - name: acme-lb + port: 8080 +``` + +Binding to a port also allows you to attach to multiple listeners at once. +For example, binding to port `8090` of the `acme-lb` Gateway would be more +convenient than binding to the corresponding listeners by name: + +```yaml +spec: + parentRefs: + - name: acme-lb + sectionName: bar + - name: acme-lb + sectionName: baz +``` + +However, when binding Routes by port number, Gateway admins will no longer have +the flexibility to switch ports on the Gateway without also updating the Routes. +The approach should only be used when a Route should apply to a specific port +number as opposed to listeners whose ports may be changed. + +### Hostnames + +Hostnames define a list of hostnames to match against the Host header of the +HTTP request. When a match occurs, the HTTPRoute is selected to perform request +routing based on rules and filters (optional). A hostname is the fully qualified +domain name of a network host, as defined by [RFC 3986][rfc-3986]. Note the +following deviations from the “host” part of the URI as defined in the RFC: + +- IPs are not allowed. +- The : delimiter is not respected because ports are not allowed. + +Incoming requests are matched against hostnames before the HTTPRoute rules are +evaluated. If no hostname is specified, traffic is routed based on HTTPRoute +rules and filters (optional). + +The following example defines hostname "my.example.com": + +```yaml +apiVersion: gateway.networking.k8s.io/v1 +kind: HTTPRoute +metadata: + name: httproute-example +spec: + hostnames: + - my.example.com +``` + +### Rules + +Rules define semantics for matching an HTTP request based on conditions, +optionally executing additional processing steps, and optionally forwarding +the request to an API object. + +#### Matches + +Matches define conditions used for matching an HTTP request. Each match is +independent, i.e. this rule will be matched if any single match is satisfied. + +Take the following matches configuration as an example: + +```yaml +apiVersion: gateway.networking.k8s.io/v1 +kind: HTTPRoute +... +spec: + rules: + - matches: + - path: + value: "/foo" + headers: + - name: "version" + value: "2" + - path: + value: "/v2/foo" +``` + +For a request to match against this rule, it must satisfy EITHER of the +following conditions: + + - A path prefixed with /foo **AND** contains the header "version: 2" + - A path prefix of /v2/foo + +If no matches are specified, the default is a prefix path match on “/”, +which has the effect of matching every HTTP request. + +#### Filters (optional) + +Filters define processing steps that must be completed during the request or +response lifecycle. Filters act as an extension point to express additional +processing that may be performed in Gateway implementations. Some examples +include request or response modification, implementing authentication +strategies, rate-limiting, and traffic shaping. + +The following example adds header "my-header: foo" to HTTP requests with Host +header "my.filter.com". +```yaml +{% include 'standard/http-filter.yaml' %} +``` + +API conformance is defined based on the filter type. The effects of ordering +multiple behaviors is currently unspecified. This may change in the future +based on feedback during the alpha stage. + +Conformance levels are defined by the filter type: + + - All "core" filters MUST be supported by implementations. + - Implementers are encouraged to support "extended" filters. + - "Implementation-specific" filters have no API guarantees across implementations. + +Specifying a core filter multiple times has unspecified or +implementation-specific conformance. + +All filters are expected to be compatible with each other except for the +URLRewrite and RequestRedirect filters, which may not be combined. If an +implementation cannot support other combinations of filters, they must clearly +document that limitation. In cases where incompatible or unsupported +filters are specified and cause the `Accepted` condition to be set to status +`False`, implementations may use the `IncompatibleFilters` reason to specify +this configuration error. + +#### BackendRefs (optional) + +BackendRefs defines API objects 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 404 error code +is returned. + +The following example forwards HTTP requests for path prefix `/bar` to service +"my-service1" on port `8080`, and HTTP requests fulfilling _all_ four of the +following criteria + +- header `magic: foo` +- query param `great: example` +- path prefix `/some/thing` +- method `GET` + +to service "my-service2" on port `8080`: +```yaml +{% include 'standard/basic-http.yaml' %} +``` + +The following example uses the `weight` field to forward 90% of HTTP requests to +`foo.example.com` to the "foo-v1" Service and the other 10% to the "foo-v2" +Service: +```yaml +{% include 'standard/traffic-splitting/traffic-split-2.yaml' %} +``` + +Reference the [backendRef][backendRef] API documentation for additional details +on `weight` and other fields. + +#### Timeouts (optional) + +??? example "Experimental Channel since v1.0.0" + + HTTPRoute timeouts have been part of the Experimental Channel since `v1.0.0`. + For more information on release channels, refer to our + [versioning guide](../concepts/versioning.md). + +HTTPRoute Rules include a `Timeouts` field. If unspecified, timeout behavior is implementation-specific. + +There are 2 kinds of timeouts that can be configured in an HTTPRoute Rule: + +1. `request` is the timeout for the Gateway API implementation to send a response to a client HTTP request. This timeout is intended to cover as close to the whole request-response transaction as possible, although an implementation MAY choose to start the timeout after the entire request stream has been received instead of immediately after the transaction is initiated by the client. + +2. `backendRequest` is a timeout for a single request from the Gateway to a backend. This timeout covers the time from when the request first starts being sent from the gateway to when the full response has been received from the backend. This can be particularly helpful if the Gateway retries connections to a backend. + +Because the `request` timeout encompasses the `backendRequest` timeout, the value of `backendRequest` must not be greater than the value of `request` timeout. + +Timeouts are optional, and their fields are of type [Duration](../geps/gep-2257/index.md). A zero-valued timeout ("0s") MUST be interpreted as disabling the timeout. A valid non-zero-valued timeout MUST be >= 1ms. + +The following example uses the `request` field which will cause a timeout if a client request is taking longer than 10 seconds to complete. The example also defines a 2s `backendRequest` which specifies a timeout for an individual request from the gateway to a backend service `timeout-svc`: + +```yaml +{% include 'experimental/http-route-timeouts/timeout-example.yaml' %} +``` + +Reference the [timeouts][timeouts] API documentation for additional details. + +#### Name (optional) + +??? example "Experimental Channel since v1.2.0" + + This concept has been part of the Experimental Channel since `v1.2.0`. + For more information on release channels, refer to our + [versioning guide](../concepts/versioning.md). + +HTTPRoute Rules include an optional `name` field. The applications for the name of a route rule are implementation-specific. It can be used to reference individual route rules by name from other resources, such as in the `sectionName` field of metaresources ([GEP-2648](../geps/gep-2648/index.md#section-names)), in the status stanzas of resources related to the route object, to identify internal configuration objects generated by the implementation from HTTPRoute Rule, etc. + +If specified, the value of the name field must comply with the [`SectionName`](https://github.com/kubernetes-sigs/gateway-api/blob/v1.0.0/apis/v1/shared_types.go#L607-L624) type. + +The following example specifies the `name` field to identify HTTPRoute Rules used to split traffic between a _read-only_ backend service and a _write-only_ one: + +```yaml +{% include 'experimental/http-route-rule-name.yaml' %} +``` + +##### Backend Protocol + +??? example "Experimental Channel since v1.0.0" + + This concept has been part of the Experimental Channel since `v1.0.0`. + For more information on release channels, refer to our + [versioning guide](../concepts/versioning.md). + +Some implementations may require the [backendRef][backendRef] to be labeled +explicitly in order to route traffic using a certain protocol. For Kubernetes +Service backends this can be done by specifying the [`appProtocol`][appProtocol] +field. + + +## Status + +Status defines the observed state of HTTPRoute. + +### RouteStatus + +RouteStatus defines the observed state that is required across all route types. + +#### Parents + +Parents define a list of the Gateways (or other parent resources) that are +associated with the HTTPRoute, and the status of the HTTPRoute with respect to +each of these Gateways. When a HTTPRoute adds a reference to a Gateway in +parentRefs, 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. + +The following example indicates HTTPRoute "http-example" has been accepted by +Gateway "gw-example" in namespace "gw-example-ns": +```yaml +apiVersion: gateway.networking.k8s.io/v1 +kind: HTTPRoute +metadata: + name: http-example +... +status: + parents: + - parentRef: + name: gw-example + namespace: gw-example-ns + conditions: + - type: Accepted + status: "True" +``` + +## Merging +Multiple HTTPRoutes can be attached to a single Gateway resource. Importantly, +only one Route rule may match each request. For more information on how conflict +resolution applies to merging, refer to the [API specification][httprouterule]. + + +[httproute]: ../reference/spec.md#gateway.networking.k8s.io/v1.HTTPRoute +[httprouterule]: ../reference/spec.md#gateway.networking.k8s.io/v1.HTTPRouteRule +[hostname]: ../reference/spec.md#gateway.networking.k8s.io/v1.Hostname +[rfc-3986]: https://tools.ietf.org/html/rfc3986 +[matches]: ../reference/spec.md#gateway.networking.k8s.io/v1.HTTPRouteMatch +[filters]: ../reference/spec.md#gateway.networking.k8s.io/v1.HTTPRouteFilter +[backendRef]: ../reference/spec.md#gateway.networking.k8s.io/v1.HTTPBackendRef +[parentRef]: ../reference/spec.md#gateway.networking.k8s.io/v1.ParentRef +[timeouts]: ../reference/spec.md#gateway.networking.k8s.io/v1.HTTPRouteTimeouts +[appProtocol]: https://kubernetes.io/docs/concepts/services-networking/service/#application-protocol +[sectionName]: ../reference/spec.md#gateway.networking.k8s.io/v1.SectionName diff --git a/site-src/ko/api-types/referencegrant.md b/site-src/ko/api-types/referencegrant.md new file mode 100644 index 0000000000..9ac9964a0f --- /dev/null +++ b/site-src/ko/api-types/referencegrant.md @@ -0,0 +1,160 @@ +# ReferenceGrant + +??? success "Standard Channel since v0.6.0" + + The `ReferenceGrant` resource is Beta and part of the + Standard Channel since `v0.6.0`. For more information on release + channels, refer to our [versioning guide](../concepts/versioning.md). + +!!! note + This resource was originally named "ReferencePolicy". It was renamed + to "ReferenceGrant" to avoid any confusion with policy attachment. + +A ReferenceGrant can be used to enable cross namespace references within +Gateway API. In particular, Routes may forward traffic to backends in other +namespaces, or Gateways may refer to Secrets in another namespace. + + + + +In the past, we've seen that forwarding traffic across namespace boundaries is a +desired feature, but without a safeguard like ReferenceGrant, +[vulnerabilities](https://github.com/kubernetes/kubernetes/issues/103675) can +emerge. + +If an object is referred to from outside its namespace, the object's owner must +create a ReferenceGrant resource to explicitly allow that reference. Without a +ReferenceGrant, a cross namespace reference is invalid. + +## Structure +Fundamentally a ReferenceGrant is made up of two lists, a list of resources +references may come from, and a list of resources that may be referenced. + +The `from` list allows you to specify the group, kind, and namespace of +resources that may reference items described in the `to` list. + +The `to` list allows you to specify the group and kind of resources that may be +referenced by items described in the `from` list. The namespace is not necessary +in the `to` list because a ReferenceGrant can only be used to allow references +to resources in the same namespace as the ReferenceGrant. + +## Example +The following example shows how a HTTPRoute in namespace `foo` can reference a +Service in namespace `bar`. In this example a ReferenceGrant in the `bar` +namespace explicitly allows references to Services from HTTPRoutes in the `foo` +namespace. + +```yaml +apiVersion: gateway.networking.k8s.io/v1 +kind: HTTPRoute +metadata: + name: foo + namespace: foo +spec: + rules: + - matches: + - path: /bar + backendRefs: + - name: bar + namespace: bar +--- +apiVersion: gateway.networking.k8s.io/v1beta1 +kind: ReferenceGrant +metadata: + name: bar + namespace: bar +spec: + from: + - group: gateway.networking.k8s.io + kind: HTTPRoute + namespace: foo + to: + - group: "" + kind: Service +``` + +## API design decisions +While the API is simplistic in nature, it comes with a few notable decisions: + +1. Each ReferenceGrant only supports a single From and To section. Additional + trust relationships must be modeled with additional ReferenceGrant + resources. +1. Resource names are intentionally excluded from the "From" section of + ReferenceGrant because they rarely provide any meaningful protection. A user + that is able to write to resources of a certain kind within a namespace can + always rename resources or change the structure of the resources to match a + given grant. +1. A single Namespace is allowed per "From" struct. Although a selector would be + more powerful, it encourages unnecessarily insecure configuration. +1. The effect of these resources is purely additive, they stack on top of each + other. This makes it impossible for them to conflict with each other. + +Please see the [API +Specification](../reference/spec.md#gateway.networking.k8s.io/v1alpha2.ReferenceGrant) +for more details on how specific ReferenceGrant fields are interpreted. + +## Implementation Guidelines +This API relies on runtime verification. Implementations MUST watch for changes +to these resources and recalculate the validity of cross-namespace references +after each change or deletion. + +When communicating the status of a cross-namespace reference, implementations +MUST NOT expose information about the existence of a resource in another +namespace unless a ReferenceGrant exists allowing the reference to occur. This +means that if a cross-namespace reference is made without a ReferenceGrant to a +resource that doesn't exist, any status conditions or warning messages need to +focus on the fact that a ReferenceGrant does not exist to allow this reference. +No hints should be provided about whether or not the referenced resource exists. + +## Exceptions +Cross namespace Route -> Gateway binding follows a slightly different pattern +where the handshake mechanism is built into the Gateway resource. For more +information on that approach, refer to the relevant [Security Model +documentation](../concepts/security-model.md). Although conceptually similar to +ReferenceGrant, this configuration is built directly into Gateway Listeners, +and allows for fine-grained per Listener configuration that would not be +possible with ReferenceGrant. + +There are some situations where it MAY be acceptable to ignore ReferenceGrant +in favor of some other security mechanism. This MAY only be done if other +mechanisms like NetworkPolicy can effectively limit cross-namespace references +by the implementation. + +An implementation choosing to make this exception MUST clearly document that +ReferenceGrant is not honored by their implementations and detail which +alternative safeguards are available. Note that this is unlikely to apply to +ingress implementations of the API and will not apply to all mesh +implementations. + +For an example of the risks involved in cross-namespace references, refer to +[CVE-2021-25740](https://github.com/kubernetes/kubernetes/issues/103675). +Implementations of this API need to be very careful to avoid confused deputy +attacks. ReferenceGrant provides a safeguard for that. Exceptions MUST only be +made by implementations that are absolutely certain that other equally effective +safeguards are in place. + +## Conformance Level +ReferenceGrant support is a "CORE" conformance level requirement for +cross-namespace references that originate from the following objects: + +- Gateway +- GRPCRoute +- HTTPRoute +- TLSRoute +- TCPRoute +- UDPRoute + +That is, all implementations MUST use this flow for any cross namespace +references in the Gateway and any of the core xRoute types, except as noted +in the Exceptions section above. + +Other "ImplementationSpecific" objects and references MUST also use this flow +for cross-namespace references, except as noted in the Exceptions section above. + +## Potential Future API Group Change + +ReferenceGrant is starting to gain interest outside of Gateway API and SIG +Network use cases. It is possible that this resource may move to a more neutral +home. Users of the ReferenceGrant API may be required to transition to a +different API Group (instead of `gateway.networking.k8s.io`) at some point in +the future. diff --git a/site-src/ko/blog/2021/introducing-v1alpha2.md b/site-src/ko/blog/2021/introducing-v1alpha2.md new file mode 100644 index 0000000000..55f5231efa --- /dev/null +++ b/site-src/ko/blog/2021/introducing-v1alpha2.md @@ -0,0 +1,149 @@ +--- +description: > + We’re pleased to announce the release of v1alpha2, our second alpha API + version. This release includes some major changes and improvements. This post + will cover the highlights. +--- + +# Introducing Gateway API v1alpha2 + + + :octicons-calendar-24: October 14, 2021 · + :octicons-clock-24: 5 min read + + +We’re pleased to announce the release of v1alpha2, our second alpha API version. +This release includes some major changes and improvements. This post will cover +the highlights. + +## Highlights + +### New API Group +To recognize our status as an official Kubernetes API, we've transitioned from +an experimental API group (`networking.x-k8s.io`) to the new +`gateway.networking.k8s.io` API group. This means that, as far as the apiserver +is concerned, this version is wholly distinct from v1alpha1, and automatic +conversion is not possible. + + + +### Simpler Route-Gateway Binding +In v1alpha1 we provided many ways to connect Gateways and Routes. This was a bit +more complicated to understand than we'd like. With v1alpha2, we've focused on +simpler attachment mechanism: + +* Routes directly reference the Gateway(s) they want to attach to. This is a + list, so a Route can attach to more than one Gateway. +* Each Gateway listener can choose to specify the kinds of Routes they support + and where they can be. This defaults to Routes that support the specified + protocol in the same Namespace as the Gateway. + +For example, the following HTTPRoute uses the `parentRefs` field to attach +itself to the `prod-web-gw` Gateway. + +```yaml +apiVersion: gateway.networking.k8s.io/v1alpha2 +kind: HTTPRoute +metadata: + name: foo +spec: + parentRefs: + - name: prod-web + rules: + - backendRefs: + - name: foo-svc + port: 8080 +``` + +This is covered in more detail in [GEP 724](../../geps/gep-709/index.md). + +### Safe Cross Namespace References + +!!! info "Experimental Channel" + + The `ReferenceGrant` resource described below is currently only included in the + "Experimental" channel of Gateway API. For more information on release + channels, refer to our [versioning guide](../../concepts/versioning.md). + +It is quite challenging to cross namespace boundaries in a safe manner. With +Gateway API, we had several key feature requests that required this capability. +Most notably, forwarding traffic to backends in other namespaces and referring +to TLS certificates in other namespaces. + +To accomplish this, we've introduced a new ReferenceGrant resource that +provides a handshake mechanism. By default, references across namespaces are not +permitted; creating a reference across a namespace (like a Route referencing a +Service in another namespace) must be rejected by implementations. These +references can be accepted by creating a ReferenceGrant in the referent +(target) namespace, that specifies what Kind is allowed to accept incoming +references, and from what namespace and Kind the references may be. + +For example, the following ReferenceGrant would allow HTTPRoutes in the prod +namespace to forward traffic to Services wherever this ReferenceGrant was +installed: + +```yaml +apiVersion: gateway.networking.k8s.io/v1alpha2 +kind: ReferenceGrant +metadata: + name: allow-prod-traffic +spec: + from: + - group: gateway.networking.k8s.io + kind: HTTPRoute + namespace: prod + to: + - group: "" + kind: Service +``` + +This is covered in more detail in [GEP 709](../../geps/gep-709/index.md). + +### Policy Attachment +One of the key goals of this API is to provide meaningful and consistent +extension points. In v1alpha2, we've introduced a new standard for attaching +policies to Gateway API resources. + +What is a policy? Well, it's kind of up to the implementations, but the best +example to begin with is timeout policy. + +Timeout policy for HTTP connections is highly dependent on how the underlying +implementation handles policy - it's very difficult to extract commonalities. + +This is intended to allow things like: + +* Attaching a policy that specifies the default connection timeout for backends + to a GatewayClass. All Gateways that are part of that Class will have Routes + get that default connection timeout unless they specify differently. +* If a Gateway that's a member of the GatewayClass has a different default + attached, then that will beat the GatewayClass (for defaults, more specific + object beats less specific object). +* Alternatively, a Policy that mandates that you can't set the client timeout to + "no timeout" can be attached to a GatewayClass as an override. An override + will always take effect, with less specific beating more specific. + +As a simple example, a TimeoutPolicy may be attached to a Gateway. The effects +of that policy would cascade down to Routes attached to that policy: + + + +This is covered in more detail in [GEP 713](../../geps/gep-713/index.md). + +## Next Steps +There are a lot of changes in v1alpha2 that we haven't covered here. For the +full changelog, refer to our [v0.4.0 release +notes](https://github.com/kubernetes-sigs/gateway-api/releases/tag/v0.4.0). + +Many of our [implementations](../../implementations.md) are planning to release support +for the v1alpha2 API in the coming weeks. We'll update our documentation as +v1alpha2 implementations become available. + +We still have lots more to work on. Some of our next items to discuss include: + +* Conformance testing +* Route delegation +* Rewrite support +* L4 Route matching + +If these kinds of topics interest you, we'd love to have your input. Refer to +our [community page](../../contributing/index.md) to see how you can get involved. diff --git a/site-src/ko/blog/2022/graduating-to-beta.md b/site-src/ko/blog/2022/graduating-to-beta.md new file mode 100644 index 0000000000..7b0e011560 --- /dev/null +++ b/site-src/ko/blog/2022/graduating-to-beta.md @@ -0,0 +1,184 @@ +--- +description: > + We are excited to announce the v0.5.0 release of Gateway API. For the first + time, several of our most important Gateway API resources are graduating to + beta. Additional, we are starting a new initiative to explore how Gateway API + can be used for mesh and introducing new experimental concepts such as URL + rewrites. +--- + +# Gateway API Graduates to Beta + + + :octicons-calendar-24: July 13, 2022 · + :octicons-clock-24: 5 min read + + +We are excited to announce the v0.5.0 release of Gateway API. For the first +time, several of our most important Gateway API resources are graduating to +beta. Additionally, we are starting a new initiative to explore how Gateway API +can be used for mesh and introducing new experimental concepts such as URL +rewrites. We'll cover all of this and more below. + +## What is Gateway API? + +Gateway API is a collection of resources centered around [Gateway][gw] resources +(which represent the underlying network gateways / proxy servers) to enable +robust Kubernetes service networking through expressive, extensible and +role-oriented interfaces that are implemented by many vendors and have broad +industry support. + +Originally conceived as a successor to the well known [Ingress][ing] API, the +benefits of Gateway API include (but are not limited to) explicit support for +many commonly used networking protocols (e.g. `HTTP`, `TLS`, `TCP`, `UDP`) as +well as tightly integrated support for Transport Layer Security (TLS). The +`Gateway` resource in particular enables implementations to manage the lifecycle +of network gateways as a Kubernetes API. + +If you're an end-user interested in some of the benefits of Gateway API we +invite you to jump in and find an implementation that suits you. At the time of +this release there are over a dozen [implementations][impl] for popular API +gateways and service meshes and guides are available to start exploring quickly. + +[gw]:../../api-types/gateway.md +[ing]:https://kubernetes.io/docs/reference/kubernetes-api/service-resources/ingress-v1/ +[impl]:../../implementations.md + +### Getting started + +Gateway API is an official Kubernetes API like +[Ingress](https://kubernetes.io/docs/concepts/services-networking/ingress/). +Gateway API represents a superset of Ingress functionality, enabling more +advanced concepts. Similar to Ingress, there is no default implementation of +Gateway API built into Kubernetes. Instead, there are many different +[implementations][impl] available, providing significant choice in terms of underlying +technologies while providing a consistent and portable experience. + +Take a look at the [API concepts documentation][concepts] and check out some of +the [Guides][guides] to start familiarizing yourself with the APIs and how they +work. When you're ready for a practical application open the [implementations +page][impl] and select an implementation that belongs to an existing technology +you may already be familiar with or the one your cluster provider uses as a +default (if applicable). Gateway API is a [Custom Resource Definition +(CRD)][crd] based API so you'll need to [install the CRDs][install-crds] onto a +cluster to use the API. + +If you're specifically interested in helping to contribute to Gateway API, we +would love to have you! Please feel free to [open a new issue][issue] on the +repository, or join in the [discussions][disc]. Also check out the [community +page][community] which includes links to the Slack channel and community meetings. + +[crd]:https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/ +[concepts]:../../concepts/api-overview.md +[guides]:../../guides/index.md +[impl]:../../implementations.md +[install-crds]:../../guides/index.md#installing-gateway-api +[issue]:https://github.com/kubernetes-sigs/gateway-api/issues/new/choose +[disc]:https://github.com/kubernetes-sigs/gateway-api/discussions +[community]:../../contributing/index.md + +## Release highlights + +### Graduation to beta + +The `v0.5.0` release is particularly historic because it marks the growth in +maturity to a beta API version (`v1beta1`) release for some of the key APIs: + +- [GatewayClass](../../api-types/gatewayclass.md) +- [Gateway](../../api-types/gateway.md) +- [HTTPRoute](../../api-types/httproute.md) + +This achievement was marked by the completion of several graduation criteria: + +- API has been [widely implemented][impl]. +- Conformance tests provide basic coverage for all resources and have multiple implementations passing tests. +- Most of the API surface is actively being used. +- Kubernetes SIG Network API reviewers have approved graduation to beta. + +For more information on Gateway API versioning, refer to the [official +documentation](../../concepts/versioning.md). To see +what's in store for future releases check out the [next steps](#next-steps) +section. + +[impl]:../../implementations.md + +### Release channels + +This release introduces the `experimental` and `standard` [release channels][ch] +which enable a better balance of maintaining stability while still enabling +experimentation and iterative development. + +The `standard` release channel includes: + +- resources that have graduated to beta +- fields that have graduated to standard (no longer considered experimental) + +The `experimental` release channel includes everything in the `standard` release +channel, plus: + +- `alpha` API resources +- fields that are considered experimental and have not graduated to `standard` channel + +Release channels are used internally to enable iterative development with +quick turnaround, and externally to indicate feature stability to implementors +and end-users. + +For this release we've added the following experimental features: + +- [Routes can attach to Gateways by specifying port numbers](../../geps/gep-957/index.md) +- [URL rewrites and path redirects](../../geps/gep-726/index.md) + +[ch]:../../concepts/versioning.md#release-channels + +### Other improvements + +For an exhaustive list of changes included in the `v0.5.0` release, please see +the [v0.5.0 release notes](https://github.com/kubernetes-sigs/gateway-api/releases/tag/v0.5.0). + +## Gateway API for service mesh: the GAMMA Initiative +Some service mesh projects have [already implemented support for the Gateway +API](../../implementations.md). Significant overlap +between the Service Mesh Interface (SMI) APIs and the Gateway API has [inspired +discussion in the SMI +community](https://github.com/servicemeshinterface/smi-spec/issues/249) about +possible integration. + +We are pleased to announce that the service mesh community, including +representatives from Cilium Service Mesh, Consul, Istio, Kuma, Linkerd, NGINX +Service Mesh and Open Service Mesh, is coming together to form the [GAMMA +Initiative](../../mesh/index.md), a dedicated +workstream within the Gateway API subproject focused on Gateway API for Mesh +Management and Administration. + +This group will deliver [enhancement +proposals](../../contributing/enhancement-requests.md) consisting +of resources, additions, and modifications to the Gateway API specification for +mesh and mesh-adjacent use-cases. + +This work has begun with [an exploration of using Gateway API for +service-to-service +traffic](https://docs.google.com/document/d/1T_DtMQoq2tccLAtJTpo3c0ohjm25vRS35MsestSL9QU/edit#heading=h.jt37re3yi6k5) +and will continue with enhancement in areas such as authentication and +authorization policy. + +## Next steps + +As we continue to mature the API for production use cases, here are some of the highlights of what we'll be working on for the next Gateway API releases: + +- [GRPCRoute][gep1016] for [gRPC][grpc] traffic routing +- [Route delegation][pr1085] +- Layer 4 API maturity: Graduating [TCPRoute][tcpr], [UDPRoute][udpr] and + [TLSRoute][tlsr] to beta +- [GAMMA Initiative](../../mesh/index.md) - Gateway API for Service Mesh + +If there's something on this list you want to get involved in, or there's +something not on this list that you want to advocate for to get on the roadmap +please join us in the #sig-network-gateway-api channel on Kubernetes Slack or our weekly [community calls](../../contributing/index.md#meetings). + +[gep1016]:https://github.com/kubernetes-sigs/gateway-api/blob/master/geps/gep-1016.md +[grpc]:https://grpc.io/ +[pr1085]:https://github.com/kubernetes-sigs/gateway-api/pull/1085 +[tcpr]:https://github.com/kubernetes-sigs/gateway-api/blob/main/apis/v1alpha2/tcproute_types.go +[udpr]:https://github.com/kubernetes-sigs/gateway-api/blob/main/apis/v1alpha2/udproute_types.go +[tlsr]:https://github.com/kubernetes-sigs/gateway-api/blob/main/apis/v1alpha2/tlsroute_types.go +[community]:../../contributing/index.md diff --git a/site-src/ko/blog/2023/0829-mesh-support.md b/site-src/ko/blog/2023/0829-mesh-support.md new file mode 100644 index 0000000000..7bc15c4429 --- /dev/null +++ b/site-src/ko/blog/2023/0829-mesh-support.md @@ -0,0 +1,209 @@ +--- +description: > + We are excited to announce the v0.8.0 release of Gateway API, where service + mesh support has now reached Experimental status, we've introduced CEL + validation and a Mesh conformance profile, and more! +--- + +# Gateway API v0.8.0: Introducing Service Mesh Support! + + + :octicons-calendar-24: August 29, 2023 · + :octicons-clock-24: 5 min read + + +We are thrilled to announce the v0.8.0 release of Gateway API! With this +release, Gateway API support for service mesh has reached [Experimental +status][status], and we've also made some smaller additions such as CEL +validation. We look forward to your feedback! + +We're especially delighted to announce that Kuma 2.3+, Linkerd 2.14+, and +Istio 1.16+ are all fully-conformant implementations of the Gateway API +service mesh support. + +## Service mesh support in Gateway API + +While the initial focus of Gateway API was always ingress (north-south) +traffic, it was clear almost from the beginning that the same basic routing +concepts should also be applicable to service mesh (east-west) traffic. In +2022, the Gateway API subproject started the [GAMMA initiative][gamma], a +dedicated vendor-neutral workstream, specifically to examine how best to fit +service mesh support into the framework of the Gateway API resources, without +requiring users of Gateway API to relearn everything they understand about the +API. + +Over the last year, GAMMA has dug deeply into the challenges and possible +solutions around using the Gateway API for service mesh. The end result is a +small number of [enhancement proposals][geps] that subsume many hours of +thought and debate, and provide a minimum viable path to allow the Gateway API +to be used for service mesh. + +### How will mesh routing work when using the Gateway API? + +You can find all the details in the [Gateway API Mesh routing +documentation][mesh-routing] and [GEP-1426], but the short version for Gateway +API v0.8.0 is that an HTTPRoute can now have a `parentRef` that is a Service, +rather than just a Gateway. We anticipate future GEPs in this area as we gain +more experience with service mesh use cases -- binding to a Service makes it +possible to use the Gateway API with a service mesh, but there are several +interesting use cases that remain difficult to cover. + +As an example, you might use an HTTPRoute to do an A-B test in the mesh as +follows: + +```yaml + apiVersion: gateway.networking.k8s.io/v1beta1 + kind: HTTPRoute + metadata: + name: bar-route + spec: + parentRefs: + - group: "" + kind: Service + name: demo-app + port: 5000 + rules: + - matches: + - headers: + - type: Exact + name: env + value: v1 + backendRefs: + - name: demo-app-v1 + port: 5000 + - backendRefs: + - name: demo-app-v2 + port: 5000 +``` + +Any request to port 5000 of the `demo-app` Service that has the header `env: +v1` will be routed to `demo-app-v1`, while any request without that header +will be routed to `demo-app-v2` -- and since this is being handled by the +service mesh, not the ingress controller, the A/B test can happen anywhere in +the application's call graph. + +### How do I know this will be truly portable? + +Gateway API has been investing heavily in conformance tests across all +features it supports, and mesh is no exception. One of the challenges that the +GAMMA initiative ran into is that many of these tests were strongly tied to +the idea that a given implementation provides an ingress controller. Many +service meshes don't, and requiring a GAMMA-conformant mesh to also implement +an ingress controller seemed impractical at best. This resulted in work +restarting on Gateway API _conformance profiles_, as discussed in [GEP-1709]. + +The basic idea of conformance profiles is that we can define subsets of the +Gateway API, and allow implementations to choose (and document) which subsets +they conform to. GAMMA is adding a new profile, named `Mesh` and described in +[GEP-1686], which checks only the mesh functionality as defined by GAMMA. At +this point, Kuma 2.3+, Linkerd 2.14+, and Istio 1.16+ are all conformant with +the `Mesh` profile. + +## What else is in Gateway API v0.8.0? + +This release is all about preparing Gateway API for the upcoming v1.0 release +where HTTPRoute, Gateway, and GatewayClass will graduate to GA. There are two +main changes related to this: CEL validation and GEP process changes. + +### CEL Validation + +The first major change is that Gateway API v0.8.0 is the start of a transition +from webhook validation to [CEL validation][cel] using information built into +the CRDs. That will mean different things depending on the version of +Kubernetes you're using: + +#### Kubernetes 1.25+ + +CEL validation is fully supported, and almost all validation is implemented in +CEL. (The sole exception is that header names in header modifier filters can +only do case-insensitive validation. There is more information in [issue +2277].) + +We recommend _not_ using the validating webhook on these Kubernetes versions. + +#### Kubernetes 1.23 and 1.24 + +CEL validation is not supported, but Gateway API v0.8.0 CRDs can still be +installed. When you upgrade to Kubernetes 1.25+, the validation included in +these CRDs will automatically take effect. + +We recommend continuing to use the validating webhook on these Kubernetes +versions. + +#### Kubernetes 1.22 and older + +Gateway API only commits to support for [5 most recent versions of +Kubernetes][supported-versions]. As such, these versions are no longer +supported by Gateway API, and unfortunately Gateway API v0.8.0 cannot be +installed on them, since CRDs containing CEL validation will be rejected. + +### GEP Process Changes + +The second significant change in Gateway API v0.8.0 is that we have (by +necessity) taken a hard look at the process around [Experimental][status] +GEPs. Some of these GEPs have been lingering long enough that projects have +come to rely on them in production use, which is a bit of a breakdown of the +GEP process. In order to prevent it happening in the future, we have changed +the GEP process such that reaching [Experimental][status] _requires_ that a +GEP include both the graduation criteria by which the GEP will become +[Standard][status], and a probationary period after which the GEP will be +dropped if does not meet its graduation criteria. + +For an exhaustive list of changes included in the `v0.8.0` release, please see +the [v0.8.0 release notes]. For more information on Gateway API versioning, +refer to the [official documentation][versioning docs]. + +## How can I get started with the Gateway API? + +Gateway API represents the future of load balancing, routing, and service mesh +APIs in Kubernetes. There are already more than 20 [implementations][impl] +available (including both ingress controllers and service meshes) and the list +keeps growing. + +If you're interested in getting started with Gateway API, take a look at the +[API concepts documentation][concepts] and check out some of the +[Guides][guides] to try it out. Because this is a CRD-based API, you can +install the latest version on any Kubernetes 1.23+ cluster. + +If you're specifically interested in helping to contribute to Gateway API, we +would love to have you! Please feel free to [open a new issue][issue] on the +repository, or join in the [discussions][disc]. Also check out the [community +page][community] which includes links to the Slack channel and community +meetings. We look forward to seeing you!! + +## Further Reading: + +- [GEP-1324] provides an overview of the GAMMA goals and some important + definitions. This GEP is well worth a read for its discussion of the problem + space. +- [GEP-1426] defines how to use Gateway API route resources, such as + HTTPRoute, to manage traffic within a service mesh. +- [GEP-1686] builds on the work of [GEP-1709] to define a _conformance + profile_ for service meshes to be declared conformant with the Gateway API. + +Although these are [Experimental][status] patterns, note that they are +available in the [`standard` release channel][ch], since the GAMMA initiative +has not needed to introduce new resources or fields to date. + +[gamma]:../../mesh/index.md +[status]:../../geps/overview.md#gep-states +[ch]:../../concepts/versioning.md#release-channels +[cel]:https://kubernetes.io/docs/reference/using-api/cel/ +[crd]:https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/ +[concepts]:../../concepts/api-overview.md +[geps]:../../contributing/enhancement-requests.md +[guides]:../../guides/index.md +[impl]:../../implementations.md +[install-crds]:../../guides/index.md#installing-gateway-api +[issue]:https://github.com/kubernetes-sigs/gateway-api/issues/new/choose +[disc]:https://github.com/kubernetes-sigs/gateway-api/discussions +[community]:../../contributing/index.md +[mesh-routing]:../../mesh/index.md +[GEP-1426]:../../geps/gep-1294/index.md +[GEP-1324]:../../geps/gep-1324/index.md +[GEP-1686]:../../geps/gep-1686/index.md +[GEP-1709]:../../geps/gep-1709/index.md +[issue 2277]:https://github.com/kubernetes-sigs/gateway-api/issues/2277 +[supported-versions]:../../concepts/versioning.md#supported-versions +[v0.8.0 release notes]:https://github.com/kubernetes-sigs/gateway-api/releases/tag/v0.8.0 +[versioning docs]:../../concepts/versioning.md diff --git a/site-src/ko/blog/index.md b/site-src/ko/blog/index.md new file mode 100644 index 0000000000..85027e3d40 --- /dev/null +++ b/site-src/ko/blog/index.md @@ -0,0 +1,53 @@ +# Blog + + + +## [Gateway API: Introducing Service Mesh Support!] + + + :octicons-calendar-24: August 29, 2023 · + :octicons-clock-24: 5 min read + + +We are thrilled to announce the v0.8.0 release of Gateway API! With this +release, Gateway API support for service mesh has reached [Experimental +status][status], we've introduced CEL validation and a `Mesh` conformance +profile, and we've made some changes to the GEP process. We look forward to +your feedback! + +[:octicons-arrow-right-24: Continue reading][Gateway API: Introducing Service Mesh Support!] + +[status]:../geps/overview.md#gep-states +[Gateway API: Introducing Service Mesh Support!]:2023/0829-mesh-support.md + +## [Gateway API Graduates to Beta] + + + :octicons-calendar-24: July 13, 2022 · + :octicons-clock-24: 5 min read + + +We are excited to announce the v0.5.0 release of Gateway API. For the first +time, several of our most important Gateway API resources are graduating to +beta. Additionally, we are starting a new initiative to explore how Gateway API +can be used for mesh and introducing new experimental concepts such as URL +rewrites. + +[:octicons-arrow-right-24: Continue reading][Gateway API Graduates to Beta] + +[Gateway API Graduates to Beta]:2022/graduating-to-beta.md + +## [Introducing Gateway API v1alpha2] + + + :octicons-calendar-24: October 14, 2021 · + :octicons-clock-24: 5 min read + + +We’re pleased to announce the release of v1alpha2, our second alpha API version. +This release includes some major changes and improvements. This post will cover +the highlights. + +[:octicons-arrow-right-24: Continue reading][Introducing Gateway API v1alpha2] + +[Introducing Gateway API v1alpha2]: 2021/introducing-v1alpha2.md diff --git a/site-src/ko/concepts/api-overview.md b/site-src/ko/concepts/api-overview.md new file mode 100644 index 0000000000..b61eafe25f --- /dev/null +++ b/site-src/ko/concepts/api-overview.md @@ -0,0 +1,355 @@ +# API 개요 + +이 문서는 게이트웨이 API에 대한 개요를 제공한다. + +## 역할과 페르소나 + +[역할과 페르소나]에 설명된 대로 게이트웨이 API에는 3가지 주요 역할이 있다. + +- **Ian** (그/그의): 인프라 제공자 +- **Chihiro** (그들/그들의): 클러스터 운영자 +- **Ana** (그녀/그녀의): 애플리케이션 개발자 + +[역할과 페르소나]:roles-and-personas.md + +## 리소스 모델 + +!!! 참고 + 게이트웨이 API 리소스는 커스텀 리소스 정의(CRDs)로서 + `gateway.networking.k8s.io` API 그룹에 속해 있다. + 아래의 리소스 이름은 특별한 언급이 없는 한 이 API 그룹에 속한 것으로 간주된다. + +리소스 모델에는 세 가지 주요 객체 타입이 있다. + +*Gateway Class*는 공통 구성과 동작을 가진 게이트웨이 집합을 +정의한다. + +*Gateway*는 트래픽이 클러스터 내의 서비스로 변환될 수 있는 지점을 +요청한다. + +*Route*는 게이트웨이를 통해 들어오는 트래픽이 서비스에 어떻게 매핑되는지 설명한다. + +### 게이트웨이 클래스 (GatewayClass) + +??? success "v0.5.0 부터 표준 채널" + + `GatewayClass` 리소스는 GA(정식 출시)되었으며 `v0.5.0` 부터 표준 채널의 일부이다. + 릴리스 채널에 대한 자세한 정보는 + [버전 관리 가이드](versioning.md)를 참조하자. + +게이트웨이 클래스는 공통 구성과 동작을 공유하는 게이트웨이 집합을 정의한다. +각 게이트웨이 클래스는 단일 컨트롤러에 의해 처리되지만, +컨트롤러는 여러 게이트웨이 클래스를 처리할 수 있다. + +게이트웨이 클래스는 클러스터 범위의 리소스이다. +기능적인 게이트웨이를 사용하기 위해서는 최소한 하나의 게이트웨이 클래스가 정의되어 있어야 한다. +게이트웨이 API를 구현하는 컨트롤러는 사용자가 게이트웨이에서 참조할 수 있는 연관된 +게이트웨이 클래스 리소스를 제공함으로써 이를 수행한다. + +이는 인그레스의 +[인그레스 클래스](https://kubernetes.io/ko/docs/concepts/services-networking/ingress/#%EC%9D%B8%EA%B7%B8%EB%A0%88%EC%8A%A4-%ED%81%B4%EB%9E%98%EC%8A%A4)와 +퍼시스턴트 볼륨의 +[스토리지 클래스](https://kubernetes.io/ko/docs/concepts/storage/storage-classes/)와 유사하다. +인그레스 v1beta1에서 게이트웨이 클래스와 +가장 유사한 것은 `ingress-class` 어노테이션이며, +IngressV1에서는 인그레스 클래스 객체가 가장 유사하다. + +### 게이트웨이 (Gateway) + +??? success "v0.5.0 부터 표준 채널" + + `게이트웨이` 리소스는 GA(정식 출시)되었으며 `v0.5.0` 부터 표준 채널의 일부이다. + 릴리스 채널에 대한 자세한 정보는 [버전 관리 가이드](versioning.md)를 + 참조하자. + +게이트웨이는 트래픽이 클러스터 내의 서비스로 어떻게 변환될 수 있는지 설명한다. +즉, 쿠버네티스를 알지 못하는 곳에서 +쿠버네티스를 아는 곳으로 트래픽을 변환하는 방법에 대한 요청을 정의한다. +예를 들어, 클라우드 로드 밸런서, 클러스터 내 프록시 또는 외부 하드웨어 로드 밸런서에 의해 +쿠버네티스 서비스로 전송되는 트래픽이 이에 해당한다. +많은 사용 사례에서 클라이언트 트래픽이 클러스터 "외부"에서 시작되지만, +이는 필수 요구사항은 아니다. + +게이트웨이는 게이트웨이 클래스의 구성 및 동작 계약을 구현하는 +특정 로드 밸런서 구성에 대한 요청을 정의한다. +이 리소스는 운영자가 직접 생성하거나, +게이트웨이 클래스를 처리하는 컨트롤러에 의해 생성될 수 있다. + +게이트웨이 스펙은 사용자의 의도를 담고 있으므로, 스펙의 모든 속성에 대한 +완전한 명세를 포함하지 않을 수 있다. +예를 들어, 사용자는 주소, TLS 설정과 같은 필드를 생략할 수 있다. +이를 통해 게이트웨이 클래스를 관리하는 컨트롤러가 +사용자를 위해 이러한 설정을 제공할 수 있으며, 이는 더 이식성 있는 스펙을 제공한다. +이러한 동작은 게이트웨이 클래스 상태 객체를 사용하여 명확하게 표시된다. + +게이트웨이는 하나 이상의 *라우트 참조*에 연결될 수 있으며, +이는 트래픽의 일부를 *특정 서비스*로 전달하는 역할을 한다. + +### 라우트 리소스 (Route Resource) + +라우트 리소스는 게이트웨이에서 쿠버네티스 서비스로의 요청 매핑을 위한 +프로토콜별 규칙을 정의한다. + +v1alpha2를 기준으로, API에는 네 가지 라우트 리소스 타입이 포함되어 있다. +구현별로 특정한 사용자 정의 라우트 타입은 다른 프로토콜에 대해 권장된다. +향후 API에 새로운 라우트 타입이 추가될 수 있다. + +#### HTTPRoute + +??? success "v0.5.0 부터 표준 채널" + + `HTTPRoute` 리소스는 GA(정식 출시)되었으며 `v0.5.0` 부터 표준 채널의 일부이다. + 릴리스 채널에 대한 자세한 정보는 [버전 관리 가이드](versioning.md)를 + 참조하자. + +HTTPRoute는 HTTP 또는 종료된 HTTPS 연결을 다중화하기 위한 것이다. +HTTP 스트림을 검사하고 HTTP 요청 데이터를 라우팅하거나 수정에 사용하려는 경우에 사용된다. +예를 들어, HTTP 헤더를 사용하여 라우팅하거나 +이를 전송 중에 수정하는 경우에 사용된다. + +#### TLSRoute + +??? example "v0.3.0 부터 실험적 채널" + + `TLSRoute` 리소스는 알파 상태이며 `v0.3.0` 부터 실험적 채널의 일부이다. + 릴리스 채널에 대한 자세한 정보는 [버전 관리 가이드](versioning.md)를 + 참조하자. + +TLSRoute는 SNI를 통해 구분되는 TLS 연결을 멀티플렉싱하기 위한 것이다. +SNI를 주요 라우팅 방법으로 사용하고 싶고, HTTP와 같은 상위 레벨 프로토콜의 +속성에는 관심이 없는 경우에 사용된다. 연결의 바이트 스트림은 +백엔드로 검사 없이 프록시된다. + +#### TCPRoute와 UDPRoute + +??? example "v0.3.0 부터 실험적 채널" + + `TCPRoute` 및 `UDPRoute` 리소스는 알파 상태이며 `v0.3.0` 부터 실험적 채널의 일부이다. + 릴리스 채널에 대한 자세한 정보는 [버전 관리 가이드](versioning.md)를 + 참조하자. + +TCPRoute(및 UDPRoute)는 하나 이상의 포트를 단일 백엔드에 매핑하는 데 사용된다. +이 경우, 동일한 포트에서 서로 다른 백엔드를 선택할 수 있는 구분자가 없으므로, +일반적으로 각 TCPRoute는 리스너에서 서로 다른 포트를 필요로 한다. +TLS를 종료할 수 있는데, +이 경우 암호화되지 않은 바이트 스트림이 백엔드에 전달된다. +TLS를 종료하지 않도록 선택할 수도 있으며, +이 경우에는 암호화된 바이트 스트림이 백엔드에 전달된다. + +#### GRPCRoute + +??? success "v1.1.0 부터 표준 채널" + + `GRPCRoute` 리소스는 GA(정식 출시)되었으며 `v1.1.0` 부터 표준 채널의 일부이다. + 릴리스 채널에 대한 자세한 정보는 [버전 관리 가이드](versioning.md)를 + 참조하자. + +GRPCRoute는 gRPC 트래픽을 관용적으로 라우팅하기 위한 것이다. +GRPCRoute를 지원하는 게이트웨이는 HTTP/1에서 초기 업그레이드 없이 +HTTP/2를 지원해야 하므로, gRPC 트래픽이 올바르게 흐를 수 있도록 보장된다. + +#### 라우트 요약 표 + +아래의 "라우팅 식별자" 열은 여러 라우트가 리스너의 포트를 공유할 수 있도록 +하는 데 사용할 수 있는 정보를 나타낸다. + +|객체|OSI 계층|라우팅 식별자|TLS 지원|목적| +|------|---------|---------------------|-----------|-------| +|HTTPRoute| 레이어 7 | HTTP 프로토콜의 모든 것 | 종료만 가능 | HTTP 및 HTTPS 라우팅| +|TLSRoute| 레이어 4와 7 사이 | SNI 또는 다른 TLS 속성 | 패스스루 또는 종료 | HTTP 스트림 검사가 필요하지 않은 HTTPS를 포함한 TLS 프로토콜 라우팅| +|TCPRoute| 레이어 4 | 목적지 포트 | 패스스루 또는 종료 | 리스너에서 백엔드로 TCP 스트림 전달 허용 | +|UDPRoute| 레이어 4 | 목적지 포트 | 없음 | 리스너에서 백엔드로 UDP 스트림 전달 허용 | +|GRPCRoute| 레이어 7 | gRPC 프로토콜의 모든 것 | 종료만 가능 | HTTP/2 및 HTTP/2 클리어텍스트를 통한 gRPC 라우팅| + +참고로 HTTPRoute 및 TCPRoute를 통해 라우팅되는 트래픽은 게이트웨이와 +백엔드 사이에서 암호화될 수 있다(일반적으로 재암호화라고 함). +기존 게이트웨이 API 리소스로는 이를 구성할 수 없지만, +게이트웨이 API에서 표준화된 방식이 정의될 때까지 +구현체에서 이에 대한 사용자 정의 구성을 제공할 수 있다. + +## 라우트를 게이트웨이에 연결하기 + +라우트가 게이트웨이에 연결되면, 이는 기본 로드 밸런서나 프록시를 구성하는 +게이트웨이에 적용되는 구성을 나타낸다. 라우트가 게이트웨이에 연결되는 방법과 +어떤 라우트가 연결되는지는 리소스 자체에 의해 제어된다. 라우트와 +게이트웨이 리소스에는 연결 방법을 허용하거나 제한하는 내장 제어 기능이 있다. +쿠버네티스 RBAC와 함께 이러한 기능은 조직이 라우트가 노출되는 방식과 +어떤 게이트웨이에 노출되는지에 대한 정책을 시행할 수 있게 한다. + +라우트가 게이트웨이에 연결되는 방법에는 다양한 조직 정책과 책임 범위를 +달성하기 위한 많은 유연성이 있다. 게이트웨이와 라우트가 가질 수 있는 +다양한 관계는 다음과 같다. + +- **일대일(One-to-one)** - 게이트웨이와 라우트는 단일 소유자에 의해 + 배포되고 사용되며 일대일 관계를 가질 수 있다. +- **일대다(One-to-many)** - 게이트웨이는 서로 다른 네임스페이스의 + 다양한 팀이 소유한 여러 라우트가 바인딩될 수 있다. +- **다대일(Many-to-one)** - 라우트도 여러 게이트웨이에 바인딩될 수 있어, + 단일 라우트가 서로 다른 IP, 로드 밸런서 또는 네트워크에서 동시에 + 애플리케이션 노출을 제어할 수 있다. + +### 예시 + +[Chihiro]는 `infra` 네임스페이스에 `shared-gw` 게이트웨이를 배포하여 +여러 애플리케이션 팀이 클러스터 외부에 애플리케이션을 노출할 수 있도록 했다. +A팀과 B팀(각각 네임스페이스 `A`와 `B`에 있음)은 자신의 라우트를 +이 게이트웨이에 연결한다. +이들은 서로에 대해 알지 못하며, +라우트 규칙이 서로 충돌하지 않는 한 계속 독립적으로 운영할 수 있다. +C팀은 특별한 네트워킹 요구 사항(성능, 보안 또는 중요도 등)이 있어 +애플리케이션을 외부 세계로 프록시하기 위한 전용 게이트웨이가 필요하다. +C팀은 `C` 네임스페이스에 자체 게이트웨이인 `dedicated-gw`를 배포하며, +이는 `C` 네임스페이스의 앱에서만 사용할 수 있다. + + + + +[Chihiro]:roles-and-personas.md#Chihiro + +### 작동 방식 + +라우트가 게이트웨이에 연결되기 위해서는 다음 사항이 필요하다. + +1. 라우트는 게이트웨이를 참조하는 `parentRefs` 필드에 항목이 있어야 한다. +2. 게이트웨이의 최소 하나의 리스너가 이 연결을 허용해야 한다. + +#### 게이트웨이 참조 + +??? example "실험적 채널" + + 아래에서 설명하는 `Port` 필드는 현재 게이트웨이 API의 "실험적" + 채널에만 포함되어 있다. 릴리스 채널에 대한 자세한 정보는 + [관련 문서](versioning.md#release-channels)를 참조하자. + +라우트는 네임스페이스(라우트와 게이트웨이가 동일한 네임스페이스에 있는 경우 선택 사항)와 +`parentRef`에서 게이트웨이의 이름을 지정하여 게이트웨이를 참조할 수 있다. +기본적으로 라우트는 +게이트웨이의 모든 리스너에 연결되지만, +`parentRef`에서 아래의 필드를 사용하여 선택을 리스너의 하위 집합으로 제한할 수 있다. + +1. **SectionName** `sectionName`이 설정되면, 라우트는 지정된 이름을 가진 + 리스너를 선택한다. +2. **Port** `port`가 설정되면, 라우트는 지정된 포트에서 리스닝하고 + 이 종류의 라우트와 호환되는 프로토콜을 가진 모든 리스너를 선택한다. + +`parentRef`에서 여러 필드가 설정되면, 라우트는 이러한 필드에 지정된 +모든 조건을 충족하는 리스너를 선택한다. 예를 들어, `sectionName`과 `port`가 +모두 설정된 경우, 라우트는 지정된 이름을 가지고 지정된 포트에서 +리스닝하는 리스너를 선택한다. + +#### 라우트 연결 제한 + +각 게이트웨이 리스너는 다음 메커니즘을 사용하여 어떤 라우트를 +연결할 수 있는지 제한할 수 있다. + +1. **Hostname:** 리스너에 `hostname` 필드가 설정되면, `hostnames` 필드를 + 지정하는 연결된 라우트는 최소한 하나의 겹치는 값을 가져야 한다. +2. **Namespaces:** 리스너의 `allowedRoutes.namespaces` 필드는 라우트가 + 연결될 수 있는 위치를 제한하는 데 사용할 수 있다. `namespaces.from` + 필드는 다음 값을 지원한다. + * `Same`은 기본 옵션이다. 이 게이트웨이와 동일한 네임스페이스에 있는 + 라우트만 연결될 수 있다. + * `All`은 모든 네임스페이스의 라우트가 연결될 수 있도록 허용한다. + * `Selector`는 네임스페이스 레이블 셀렉터에 의해 선택된 네임스페이스의 + 하위 집합에서 라우트가 이 게이트웨이에 연결될 수 있음을 의미한다. + `Selector`가 사용될 때, `namespaces.selector` 필드는 레이블 + 셀렉터를 지정하는 데 사용되어야 한다. 이 필드는 `All` 또는 `Same`과 함께 지원되지 않는다. +3. **Kinds:** 리스너의 `allowedRoutes.kinds` 필드를 사용하여 연결될 수 + 있는 라우트의 종류를 제한할 수 있다. + +위의 내용이 지정되지 않은 경우, 게이트웨이 리스너는 리스너 프로토콜을 +지원하는 동일한 네임스페이스에서 연결된 라우트를 신뢰한다. + +#### 추가 게이트웨이 - 라우트 연결 예시 + +아래 `my-route` 라우트는 `gateway-api-example-ns1`의 `foo-gateway`에 +연결하려고 하며 다른 게이트웨이에는 연결되지 않는다. `foo-gateway`가 +다른 네임스페이스에 있다는 점에 유의하자. `foo-gateway`는 +`gateway-api-example-ns2` 네임스페이스의 HTTPRoute에서 연결을 허용해야 한다. + +```yaml +{% include 'standard/http-route-attachment/httproute.yaml' %} +``` + +이 `foo-gateway`는 `my-route` HTTPRoute의 연결을 허용한다. + +```yaml +{% include 'standard/http-route-attachment/gateway-strict.yaml' %} +``` + +더 관대한 예시로, 아래 게이트웨이는 "expose-apps: true" 레이블이 있는 +네임스페이스에서 모든 HTTPRoute 리소스가 연결될 수 있도록 허용한다. + +```yaml +{% include 'standard/http-route-attachment/gateway-namespaces.yaml' %} +``` + +### 결합된 타입 + +`게이트웨이 클래스`, `게이트웨이`, `xRoute` 및 `서비스`의 조합은 +구현 가능한 로드 밸런서를 정의한다. 아래 다이어그램은 +서로 다른 리소스 간의 관계를 보여준다: + + + + +### 요청 흐름 + +리버스 프록시를 사용하여 구현된 게이트웨이의 일반적인 [북/남] +API 요청 흐름은 다음과 같다. + +1. 클라이언트가
[set-cookie] + Note right of G: [set-cookie] indicates a response
with a set-cookie header.
May include other set-cookie
headers from backend. + C->>C: Create Cookie(s)
from set-cookie header(s) + Note right of C: [cookie] indicates a request
with one or more cookies + C->>+G: Request Web Page
[cookie] + G->>G: Consistent lookup of
server using cookie value + G->>+B: Request
[cookie] + B-->>-G: Response + G-->>-C: Response +``` + +#### Backend Initiated Session Example + +**Important**: While we took it into consideration, this GEP does not support configuring backend-initiated sessions. +This could potentially affect frameworks that initiate sessions in the backend. Implementing this feature is complicated +and requires careful design, making it suitable for exploration in a separate GEP. + +Continuing with the cookie example, when dealing with backend-initiated sessions, the process becomes somewhat more +complex. For cookie-based session persistence, the gateway needs to store a value within a cookie containing a backend +identifier. This identifier can be then used as a reference to maintain a persistent session to a specific backend. +There are several approaches a gateway could use in this situation to achieve session persistence: + +1. Insert an additional cookie +2. Modify the existing cookie's value +3. Prefix the existing cookie + +Additionally, there are variations to each of these approaches, such as making new or updated cookies transparent to the +backend, either by remove an inserted cookie or reversing modifications of the cookie's value. + +Alternatively, if the backend is not configured for session persistence, the gateway should refrain from modifying or +inserting a cookie. In this situation, the gateway should remain passive and simply forward the `set-cookie` header as +it is. + +Refer to the [Session Initiation Guidelines](#session-initiation-guidelines) section of the API for implementation +guidance. + +Here's an example implementation of a backend initiating a session and the gateway modifies the cookie's value: +```mermaid +sequenceDiagram + actor C as Client + participant G as Gateway + participant B as Backend + C->>+G: Request Web Page + activate G + G->>+B: Request + B->>B: Add set-cookie
header + B-->>-G: Response
[set-cookie] + G->>G: Modify set-cookie
header per configuration + G-->>-C: Response
[set-cookie*] + Note right of G: [set-cookie] indicates a response
with a set-cookie header
[set-cookie*] indicates a response
with a MODIFIED set-cookie header + C->>C: Create Cookie
from set-cookie header + Note right of C: [cookie] indicates a request
or response with a cookie + C->>+G: Request Web Page
[cookie] + G->>G: Consistent lookup
of server using cookie value + G->>+B: Request
[cookie] + B-->>-G: Response + G-->>-C: Response +``` + +#### Global Load Balancer Initiated Session Example + +In a more complex architecture example, a global load balancer may need to use cookies in order to maintain persistent +connections to a regional load balancer. The regional cluster load balancer initiates the session by issuing the +`set-cookie` header and subsequently uses the cookie to maintain persistent connections to a specific backend. The +global load balancer then adds or modifies a cookie in order to establish persistent connection to a regional cluster +load balancer. + +Here an example implementation of a global load balancer and a regional load balancer creating sessions through cookies: +```mermaid +sequenceDiagram + actor C as Client + participant G as Global
Load Balancer + participant R as Regional Cluster
Load Balancer + participant B as Backend + C->>+G: Request Web Page + G->>+R: Request + R->>+B: Request + B-->>-R: Response + R->>R: Initiates session by
adding set-cookie header + R-->>-G: Response
[set-cookie] + G->>G: Add or modify
set-cookie header + G-->>-C: Response
[set-cookie*] + Note right of G: [set-cookie] indicates a response
with a set-cookie header
[set-cookie*] indicates a response with a
modified or additional set-cookie header + C->>C: Create Cookie
from set-cookie header + Note right of C: [cookie] indicates a request
with one or more cookies + C->>+G: Request Web Page
[cookie] + G->>G: Consistent lookup of
regional cluster load balancer
using cookie value + G->>+R: Request
[cookie] + R->>R: Consistent lookup of backend
using cookie value + R->>+B: Request
[cookie] + B-->>-R: Response + R-->>-G: Response + G-->>-C: Response +``` + +### When does an application require session persistence? + +Enabling session persistence is a required configuration for applications intentionally designed by the application +developer to use it, as they will encounter failures or malfunctions when it's not enabled. However, it's worth noting +that certain applications may be designed to function both with and without session persistence. Regardless, the +importance of Gateway API supporting session persistence remains emphasized because it is frequently seen as a necessary +feature. + +Conversely, apps that have not been designed or tested with session persistence in mind may misbehave when it is +enabled, primarily because of the impacts of load distribution on the app. Apps using session persistence must account +for aspects like load shedding, draining, and session migration as a part of their application design. + +### The Relationship of Session Persistence and Session Affinity + +As discussed in [Naming](#naming), we defined session persistence as "strong" and session affinity as "weak". Though +this GEP's intention is not to define an API for session affinity, let's understand its distinction with session +persistence. + +While session persistence uses attributes in the application layer, session affinity can also use attributes below the +application layer. Session affinity doesn't require a specific backend identifier to be encoded in a cookie or header; +instead, it can use any existing connection attributes to establish a consistent hashing load balancing algorithm. This +implies session affinity can use cookies or headers, as seen in Istio's [ConsistentHashLB](https://istio.io/latest/docs/reference/config/networking/destination-rule/#LoadBalancerSettings-ConsistentHashLB). With session +affinity, the cookie or header will be hashed on its arbitrary value. + +It is important to note the session affinity is less reliable and doesn't guarantee persistent connections to the same +backend server. If a proxy or load balancer restarts, or if backends are added to the backend pool, the session affinity +mechanism will likely redirect the user's connection to a new backend. In contrast, session persistence encodes a +backend identifier in a cookie or header, so as long as the backend still exists, it will be unaffected by proxy +restarts or changes in the backend pool. + +Session affinity can be achieved by deterministic load balancing algorithms or a proxy feature that tracks IP-to-backend +associations such as [HAProxy's stick tables](https://www.haproxy.com/blog/introduction-to-haproxy-stick-tables/) or +[Cilium's session affinity](https://docs.cilium.io/en/v1.12/gettingstarted/kubeproxy-free/#id2). + +We can also examine how session persistence and session affinity functionally work together, by framing the relationship +into a two tiered logical decision made by the data plane: + +1. If the request contains a session persistence identity (e.g. in a cookie or header), then route it directly to the + backend it has previously established a session with. +2. If no session persistence identity is present, load balance as per load balancing configuration, taking into account + the session affinity configuration (e.g. by utilizing a hashing algorithm that is deterministic). + +This tiered decision-based logic is consistent with the idea that session persistence is an exception to load balancing. +Though there are different ways to frame this relationship, this design will influence the separation between +persistence and affinity API design. + +### Implementations + +In this section, we will describe how implementations achieve session persistence, along with a breakdown of related configuration options. Input from implementations is appreciated to complete this information. + +In the following tables, we will example two types of APIs: + +1. Dataplane APIs +2. Implementation APIs + +Generally, the implementation API programs the dataplane API; however these two are not always clearly separated. The two types of APIs can use different API structures for configuring the same feature. Examining the dataplane APIs helps to remove the layer of API abstraction that implementations provide. Removing this layer avoids situations where implementations don’t fully implement all capabilities of a dataplane API or obfuscate certain configuration around session persistence. On the other hand, examining implementation APIs provides valuable data points in what implementations are interested in configuring. + +**Table Last Updated:** Feb 21, 2024 + +| **Technology** | **Technology Type** | **Session Persistence Type** | **Configuration Options** | **Configuration Association (Global, Gateway, Route, or Backends)** | **Notes** | +|--- |--- |--- |--- |--- |--- | +| Acnodal EPIC | Implementation (Envoy) | N/A | Supports Gateway API Only* | N/A | *Acnodal Epic solely uses Gateway API; therefore, it doesn’t yet have a way to configure session persistence. [Acnodal EPIC Docs](https://www.epick8sgw.io/docs/) | +| Amazon Elastic Kubernetes Service | Implementation / Dataplane | N/A | Supports Gateway API Only* | N/A | *Amazon Elastic Kubernetes Service solely uses Gateway API; therefore, it doesn’t yet have a way to configure session persistence. [Amazon Elastic Kubernetes Service Docs](https://www.gateway-api-controller.eks.aws.dev/) | +| Apache APISIX | Implementation (Nginx) | [Cookie-Based](https://apisix.apache.org/docs/apisix/admin-api/#upstream) | hash_on=[vars \| header \| cookie \| consumer]
key=cookie_name | [Upstream](https://apisix.apache.org/docs/apisix/admin-api/#upstream) (Route or Backends) | N/A | +| | Implementation (Nginx) | [Header-Based](https://apisix.apache.org/docs/apisix/terminology/upstream/#header) | hash_on=[vars \| header \| cookie \| consumer]
key=header_name | [Upstream](https://apisix.apache.org/docs/apisix/admin-api/#upstream) (Route or Backends) | N/A | +| Apache httpd | Web Server | [Cookie-Based / URL-Encoded](https://httpd.apache.org/docs/2.4/mod/mod_proxy_balancer.html) | Cookie Attributes | N/A | N/A | +| Avi Kubernetes Operator | Implementation / Dataplane | [Cookie-Based](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/3.2/administration/GUID-8B5C8D64-2B69-4C95-86A5-C5396CB9E51F.html) | Shared Persistence Cookie Mode=[Insert \| Prefix \| Rewrite] Cookie Name=name Cookie Domain=domain Cookie Fallback=domain Cookie Path=path Cookie Garbling Cookie Type=[ Session Cookie \| Persistence Cookie] Http Only Flag Secure Flag Max Idle Time=time Max Cookie Age=time | [Route](https://docs.vmware.com/en/VMware-NSX-Advanced-Load-Balancer/1.11/Avi-Kubernetes-Operator-Guide/GUID-E8F3C338-46FB-412E-8B46-16EE2C12A8AF.html) | N/A | +| Azure Application Gateway for Containers | Implementation / Dataplane | [Cookie-Based](https://learn.microsoft.com/en-us/azure/application-gateway/for-containers/session-affinity?tabs=session-affinity-gateway-api) | affinityType=[application-cookie \| managed-cookie]
cookieName=name
cookieDuration=seconds | [Route](https://github.com/MicrosoftDocs/azure-docs/blob/main/articles/application-gateway/for-containers/api-specification-kubernetes.md#alb.networking.azure.io/v1.RoutePolicy) | RoutePolicy which attaches to HTTPRoutes | +| BIG-IP Kubernetes Gateway | Implementation (F5 BIG-IP) | N/A | Supports Gateway API Only* | N/A | *BIG-IP Kubernetes Gateway solely uses Gateway API; therefore, it doesn’t yet have a way to configure session persistence. [BIG-IP Kubernetes Gateway Docs](https://gateway-api.f5se.io/) | +| Cilium | Implementation / Dataplane | None | None | None | Cilium has no documented way of doing session persistence. [Cilium Docs](https://cilium.io/) | +| Contour | Implementation (Envoy) | [Cookie-Based](https://projectcontour.io/docs/1.24/config/api/#projectcontour.io/v1.CookieRewritePolicy) | Name=name
pathRewrite=path
domainRewrite=domain
secure
sameSite | [Route](https://projectcontour.io/docs/1.24/config/api/#projectcontour.io/v1.Route) and [Service](https://projectcontour.io/docs/1.24/config/api/#projectcontour.io/v1.Service) (Backends) | Envoy does not natively support cookie attribute rewriting nor adding attributes other than path and TTL, but rewriting and adding additional attributes is possible via Lua ([Contour design reference](https://github.com/projectcontour/contour/blob/main/design/cookie-rewrite-design.md), [Envoy Issue](https://github.com/envoyproxy/envoy/issues/15612)). | +| Easegress | Implementation / Dataplane | None | None | None | [Easegress Docs](https://megaease.com/docs/easegress/) | +| Emissary-Ingress | Implementation (Envoy) | [Cookie-Based](https://www.getambassador.io/docs/emissary/latest/topics/running/load-balancer#cookie) | Name=name
Path=path
TTL=duration | [Module or Mapping](https://www.getambassador.io/docs/emissary/latest/topics/running/load-balancer#cookie) (Global or Route) | N/A | +| | | [Header-Based](https://www.getambassador.io/docs/emissary/latest/topics/running/load-balancer#header) | Name=name | [Module or Mapping](https://www.getambassador.io/docs/emissary/latest/topics/running/load-balancer#cookie) (Global or Route) | N/A | +| Envoy | Dataplane | [Cookie-Based](https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/http/stateful_session/cookie/v3/cookie.proto) | Name=name
Path=path
TTL=duration | [HttpConnectionManager](https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/network/http_connection_manager/v3/http_connection_manager.proto) (Route) | Envoy does not natively support cookie attribute rewriting nor adding attributes other than path and TTL, but rewriting and adding additional attributes is possible via Lua ([Contour design reference](https://github.com/projectcontour/contour/blob/main/design/cookie-rewrite-design.md), [Envoy Issue](https://github.com/envoyproxy/envoy/issues/15612)). | +| | | [Header-Based](https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/http/stateful_session/header/v3/header.proto) | Name=name | [HttpConnectionManager](https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/network/http_connection_manager/v3/http_connection_manager.proto) (Route) | N/A | +| Envoy Gateway | Implementation (Envoy) | N/A | Supports Gateway API Only* | N/A | *Envoy Gateway solely uses Gateway API; therefore, it doesn’t yet have a way to configure session persistence. [Envoy Gateway Docs](https://gateway.envoyproxy.io/v0.3.0/index.html) | +| Flomesh Service Mesh | Implementation / Dataplane (Pipy) | ? | ? | ? | ? | +| Gloo Gateway | Implementation (Envoy) | [Cookie-Based](https://docs.solo.io/gloo-edge/latest/reference/api/envoy/api/v2/route/route.proto.sk/#cookie) | Name=name Path=path TTL=duration | [Route](https://docs.solo.io/gloo-edge/latest/reference/api/envoy/api/v2/route/route.proto.sk/#route) (Route) | N/A | +| | | [Header-Based](https://docs.solo.io/gloo-edge/latest/reference/api/envoy/api/v2/route/route.proto.sk/#hashpolicy) | Name=name | [Route](https://docs.solo.io/gloo-edge/latest/reference/api/envoy/api/v2/route/route.proto.sk/#route) (Route) | N/A | +| Google CloudRun | Dataplane | [Cookie-Based](https://cloud.google.com/run/docs/configuring/session-affinity) | Enabled / Disabled | [Service](https://cloud.google.com/run/docs/configuring/session-affinity) (Backends) | Only allowed to turn off or on, no other configuration items | +| Google Kubernetes Engine | Implementation / Dataplane | [Cookie-Based](https://cloud.google.com/load-balancing/docs/backend-service#session_affinity) | GENERATED_COOKIE or HTTP_COOKIE=name
cookieTtlSec | [Backend Policy](https://cloud.google.com/kubernetes-engine/docs/how-to/configure-gateway-resources#session_affinity) (Backends) | Google Kubernetes Engine [lists](https://cloud.google.com/load-balancing/docs/backend-service#bs-session-affinity) the products that can do persistence/affinity mode. All persistence/affinity options are exclusive and can’t be used at the same time.
Note: Google Kubernetes Engine defines everything (persistence and affinity) as session affinity. | +| | | [Header-Based](https://cloud.google.com/load-balancing/docs/backend-service#header_field_affinity) | httpHeaderName=name | [Backend Policy](https://cloud.google.com/kubernetes-engine/docs/how-to/configure-gateway-resources#session_affinity) (Backends) | N/A | +| HAProxy | Dataplane | [Cookie-Based](https://docs.haproxy.org/2.6/configuration.html#4.2-cookie) | name=name
[rewrite \| insert \| prefix ]
indirect
nocache
postonly
preserve
httponly
secure
domain=domain
maxidle=idle
maxlife=life
dynamic
attr=value | [Default or Backends](https://docs.haproxy.org/2.6/configuration.html#4.2-cookie) (Global or Backends) | HAProxy allows for operational cookie strategy configuration (i.e. when/how HAProxy should inject cookies) | +| HAProxy Ingress | Implementation (HAProxy) | [Cookie-Based](https://haproxy-ingress.github.io/docs/configuration/keys/#affinity) | affinity (enable/disable)
cookie-key=key
session-cookie-domain=domain
session-cookie-dynamic=[true \| false]
session-cookie-keywords=keywords
session-cookie-name=name
session-cookie-preserve=[true \| false]
session-cookie-same-site=[true \| false]
session-cookie-shared=[true \| false]
session-cookie-strategy=strategy
session-cookie-value-strategy=value_strategy | [Backend](https://haproxy-ingress.github.io/docs/configuration/keys/#affinity) (Backends) | N/A | +| Hashicorp Consul | Implementation (Envoy) | N/A | Supports Gateway API Only* | N/A | *Hashicorp Consul solely uses Gateway API; therefore, it doesn’t yet have a way to configure session persistence. [Hashicorp Consul API Gateway Docs](https://developer.hashicorp.com/consul/docs/api-gateway) | +| Istio | Implementation (Envoy) | [Cookie-Based](https://istio.io/latest/docs/reference/config/networking/destination-rule/#LoadBalancerSettings-ConsistentHashLB-HTTPCookie) | Name=name
Path=path
TTL=duration | [ConsistentHashLB](https://istio.io/latest/docs/reference/config/networking/destination-rule/#LoadBalancerSettings-ConsistentHashLB) (Backends) | Istio also supports turning on cookie-based session persistence via the Pilot ENV variable [PILOT_PERSISTENT_SESSION_LABEL](https://istio.io/latest/docs/reference/commands/pilot-discovery/#envvars). | +| | Implementation (Envoy) | [Header-Based](https://istio.io/latest/docs/reference/config/networking/destination-rule/#LoadBalancerSettings-ConsistentHashLB) | Name=name | [ConsistentHashLB](https://istio.io/latest/docs/reference/config/networking/destination-rule/#LoadBalancerSettings-ConsistentHashLB) (Backends) | N/A | +| Java Servlet | Web Server | [Cookie-Based / URL-Encoded](https://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpSession.html) | invalidate()
setAttribute(String name, Object value)
setMaxInactiveInterval(int interval) | N/A | Java Servlets do not natively support proxy functions. | +| Kong | Implementation / Dataplane | [Cookie-Based](https://docs.konghq.com/hub/kong-inc/session/) | cookie_name=name
rolling_timeout=timeout
absolute_timeout=timeout
idling_timeout=timeout
cookie_path=path
cookie_domain=domain
cookie_same_site=[Strict \| Lax \| None \| off]
cookie_http_only
cookie_secure=[true \| false]
stale_ttl=duration
cookie_persistent=[true \| false]
storage=storage_type | [Route, Service, Global](https://docs.konghq.com/hub/kong-inc/session/) (Route or Backends or Global) | N/A | +| | | [Header-Based](https://docs.konghq.com/gateway/latest/how-kong-works/load-balancing/#balancing-algorithms) | name | [Upstreams](https://docs.konghq.com/gateway/3.2.x/admin-api/#add-upstream) (Backends) | N/A | +| Kuma | Implementation (Envoy) | None | None | None | Kuma has no documentation on how it supports session persistence or cookies. [Kuma Docs](https://kuma.io/docs/2.1.x/) | +| Linkerd | Gamma Implementation | None | None | None | [Linkerd Docs](https://linkerd.io/) | +| LiteSpeed Ingress Controller | ? | ? | ? | ? | ? | +| Nginx | Dataplane | [Cookie-Based (Nginx Plus Only)](https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/#enabling-session-persistence) | Name=name
Expires=time
Domain=domain
HttpOnly
SameSite = [strict \| lax \| none \| $variable]
Secure
path=path | [Upstream](https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/#enabling-session-persistence) (Backends) | See also [Sticky Cookie](https://nginx.org/en/docs/http/ngx_http_upstream_module.html?&_ga=2.184452070.1306763907.1680031702-1761609832.1671225057#sticky_cookie) | +| NGINX Gateway Fabric | Implementation (Nginx) | N/A | Supports Gateway API Only* | N/A | *NGINX Gateway Fabric solely uses Gateway API; therefore, it doesn’t yet have a way to configure session persistence. [NGINX Gateway Fabric Docs](https://github.com/nginxinc/nginx-gateway-fabric) | +| STUNner | Implementation / Dataplane | None | None | None | [STUNner Docs](https://github.com/l7mp/stunner) | +| Traefik | Implementation / Dataplane | [Cookie-Based](https://doc.traefik.io/traefik/routing/services/#sticky-sessions) | name=name
secure
httpOnly
sameSite=[none \| lax \| strict ] | [Services](https://doc.traefik.io/traefik/routing/services/#sticky-sessions) (Backends) | N/A | +| Tyk | Implementation / Dataplane | None | None | None | [Tyk Docs](https://tyk.io/docs/) | +| WSO2 APK | Implementation / Dataplane | None | None | None | [WSO2 APK Docs](https://apk.docs.wso2.com/en/latest/) | + +### Sessions in Java + +Java application servers such as Tomcat and Jetty, were the first to standardize the API around cookies and sessions. +These Java applications introduced the “jsessionid” cookie and session IDs encoded in URL parameters as well as more +advanced features such as session migration, replication, and on demand session activation. It’s important for Gateway +API to examine cookie use cases and history from Java APIs to ensure the API is designed appropriately. + +### Session Affinity in K8S Services + +Kubernetes provides an API that allows you to enable [session affinity](https://kubernetes.io/docs/reference/networking/virtual-ips/#session-affinity) +on service objects. It ensures consistent sessions by utilizing the client's IP address and also offers the option to +set a timeout for the maximum session duration. Implementations of Gateway API, such as service mesh use cases, may use +the service IP directly. In these cases where both Kubernetes service session affinity and Gateway API session +persistence are both enabled, the route MUST be rejected, and a status should be set describing the incompatibility of +these two configurations. + +## API + +In this section, we will explore the questions and design elements associated with a session persistence API. + +We will present two distinct patterns for configuring session persistence: + +1. `BackendLBPolicy`: a Direct Policy Attachment for backends (Services, ServiceImports, or any + implementation-specific backendRef) +2. An inline API update to HTTPRoute and GRPCRoute rules + +### BackendLBPolicy API + +In order to apply session persistence configuration to a backend, we will implement it as a [Policy Attachment](../../reference/policy-attachment.md). +The new metaresource is named `BackendLBPolicy` and is responsible for configuring load balancing-related configuration +for traffic intended for a backend after routing has occurred. It is defined as a [Direct Policy Attachment](../gep-713/index.md#direct-policy-attachment) +without defaults or overrides, applied to the targeted backend. + +Instead of utilizing a specific, session persistence-only policy object, we introduce a more generic API object named +`BackendLBPolicy`. This design provides tighter coupling with other load balancing configuration which helps reduce +CRD proliferation. For instance, `BackendLBPolicy` could be augmented to add configuration for selecting a load +balancing algorithm for traffic to the backends, as desired in issue [#1778](https://github.com/kubernetes-sigs/gateway-api/issues/1778). +`BackendLBPolicy` could also be later expanded to contain [session affinity](#the-relationship-of-session-persistence-and-session-affinity) +configuration. This would provide a convenient grouping of the two related APIs within the same policy object. +Additionally, other future enhancements to the API may include the addition of timeouts, connection draining, and +logging within `BackendLBPolicy`. + +As for achieving session persistence, this API currently exposes the `Type` field which allows selection between +cookie-based and header-based session persistence. Cookie-based session persistence is considered a core feature, +while header-based session persistence is extended and therefore optional. + +```go +// BackendLBPolicy provides a way to define load balancing rules +// for a backend. +type BackendLBPolicy struct { + metav1.TypeMeta `json:",inline"` + metav1.ObjectMeta `json:"metadata,omitempty"` + + // Spec defines the desired state of BackendLBPolicy. + Spec BackendLBPolicySpec `json:"spec"` + + // Status defines the current state of BackendLBPolicy. + Status PolicyStatus `json:"status,omitempty"` +} + +// BackendLBPolicySpec defines the desired state of +// BackendLBPolicy. +// Note: there is no Override or Default policy configuration. +type BackendLBPolicySpec struct { + // TargetRef identifies an API object to apply policy to. + // Currently, Backends (i.e. Service, ServiceImport, or any + // implementation-specific backendRef) are the only valid API + // target references. + // +listType=map + // +listMapKey=group + // +listMapKey=kind + // +listMapKey=name + // +kubebuilder:validation:MinItems=1 + // +kubebuilder:validation:MaxItems=16 + TargetRefs []LocalPolicyTargetReference `json:"targetRefs"` + + // SessionPersistence defines and configures session persistence + // for the backend. + // + // Support: Extended + // + // +optional + SessionPersistence *SessionPersistence `json:"sessionPersistence"` +} + +// SessionPersistence defines the desired state of +// SessionPersistence. +// +kubebuilder:validation:XValidation:message="AbsoluteTimeout must be specified when cookie lifetimeType is Permanent",rule="!has(self.cookieConfig) || !has(self.cookieConfig.lifetimeType) || self.cookieConfig.lifetimeType != 'Permanent' || has(self.absoluteTimeout)" +type SessionPersistence struct { + // SessionName defines the name of the persistent session token + // which may be reflected in the cookie or the header. Users + // should avoid reusing session names to prevent unintended + // consequences, such as rejection or unpredictable behavior. + // + // Support: Implementation-specific + // + // +optional + // +kubebuilder:validation:MaxLength=128 + SessionName *string `json:"sessionName,omitempty"` + + // AbsoluteTimeout defines the absolute timeout of the persistent + // session. Once the AbsoluteTimeout duration has elapsed, the + // session becomes invalid. + // + // Support: Extended + // + // +optional + AbsoluteTimeout *Duration `json:"absoluteTimeout,omitempty"` + + // IdleTimeout defines the idle timeout of the persistent session. + // Once the session has been idle for more than the specified + // IdleTimeout duration, the session becomes invalid. + // + // Support: Extended + // + // +optional + IdleTimeout *Duration `json:"idleTimeout,omitempty"` + + // Type defines the type of session persistence such as through + // the use a header or cookie. Defaults to cookie based session + // persistence. + // + // Support: Core for "Cookie" type + // + // Support: Extended for "Header" type + // + // +optional + // +kubebuilder:default=Cookie + Type *SessionPersistenceType `json:"type,omitempty"` + + // CookieConfig provides configuration settings that are specific + // to cookie-based session persistence. + // + // Support: Core + // + // +optional + CookieConfig *CookieConfig `json:"cookieConfig,omitempty"` +} + +// Duration is a string value representing a duration in time. The format is as specified +// in GEP-2257, a strict subset of the syntax parsed by Golang time.ParseDuration. +// +// +kubebuilder:validation:Pattern=`^([0-9]{1,5}(h|m|s|ms)){1,4}$` +type Duration string + +// +kubebuilder:validation:Enum=Cookie;Header +type SessionPersistenceType string + +const ( + // CookieBasedSessionPersistence specifies cookie-based session + // persistence. + // + // Support: Core + CookieBasedSessionPersistence SessionPersistenceType = "Cookie" + + // HeaderBasedSessionPersistence specifies header-based session + // persistence. + // + // Support: Extended + HeaderBasedSessionPersistence SessionPersistenceType = "Header" +) + +// CookieConfig defines the configuration for cookie-based session persistence. +type CookieConfig struct { + // LifetimeType specifies whether the cookie has a permanent or + // session-based lifetime. A permanent cookie persists until its + // specified expiry time, defined by the Expires or Max-Age cookie + // attributes, while a session cookie is deleted when the current + // session ends. + // + // When set to "Permanent", AbsoluteTimeout indicates the + // cookie's lifetime via the Expires or Max-Age cookie attributes + // and is required. + // + // When set to "Session", AbsoluteTimeout indicates the + // absolute lifetime of the cookie tracked by the gateway and + // is optional. + // + // Support: Core for "Session" type + // + // Support: Extended for "Permanent" type + // + // +optional + // +kubebuilder:default=Session + LifetimeType *CookieLifetimeType `json:"lifetimeType,omitempty"` +} + +// +kubebuilder:validation:Enum=Permanent;Session +type CookieLifetimeType string + +const ( + // SessionCookieLifetimeType specifies the type for a session + // cookie. + // + // Support: Core + SessionCookieLifetimeType CookieLifetimeType = "Session" + + // PermanentCookieLifetimeType specifies the type for a permanent + // cookie. + // + // Support: Extended + PermanentCookieLifetimeType CookieLifetimeType = "Permanent" +) +``` + +### Route Rule API + +To support route rule level configuration, this GEP also introduces an API as inline fields within HTTPRouteRule and GRPCRouteRule. +Any configuration that is specified at Route Rule level MUST override configuration that is attached at the backend level because route rule have a more global view and responsibility for the overall traffic routing. +This route rule level API for enabling session persistence currently uses the same `SessionPersistence` struct from the +`BackendLBPolicy` API. + +```go +type HTTPRouteRule struct { + [...] + + // SessionPersistence defines and configures session persistence + // for the route rule. + // + // Support: Extended + // + // +optional + SessionPersistence *SessionPersistence `json:"sessionPersistence"` +} +``` + +```go +type GRPCRouteRule struct { + [...] + + // SessionPersistence defines and configures session persistence + // for the route rule. + // + // Support: Extended + // + // +optional + SessionPersistence *SessionPersistence `json:"sessionPersistence"` +} +``` + +### API Granularity + +The purpose of this session persistence API spec is to enable developers to specify that a specific backend expects a +persistent session. However, it intentionally avoids specifying low-level details or configurations related to the +session persistence implementation, such as cookie attributes. This decision is because the Gateway API supports various +infrastructure types, and some implementations that already provide session persistence may not be able to adhere to a +low-level API. + +For instance, platforms using global load balancers to maintain persistent sessions between regional load balancers, or +Tomcat servlets generating distinct cookies per server. In such scenarios, it is important that this GEP does not +obstruct the existing use of cookies while enabling session persistence. Enabling particular low-level API +configurations, like allowing customization of the cookie name, could prevent certain implementations from conforming to +the spec. In other words, opting for a higher-level API provides better interoperability among our implementations. + +However, this API spec does allow specifying specific forms or types of session persistence through the `Type` field in +the `SessionPersistence` struct, including options for cookie-based or header-based session persistence. This API field +accommodates implementations that offer multiple methods of session persistence, while also allowing users to specify +their preferred form of session persistence if desired. + +### Target Persona + +Referring to the [Gateway API Security Model](../../concepts/security-model.md#roles-and-personas), +the target kubernetes role/persona for session persistence are application developers, as mentioned in the [When does an application require session persistence?](#when-does-an-application-require-session-persistence) +section. It is the responsibility of the application developers to adjust the persistence configuration to ensure the +functionality of their applications. + +### Prior Art + +Referring to our [Implementations](#Implementations) table on session persistence, the majority of Gateway API +implementations designed session persistence in their APIs to be attached to a service or backends. This should be +considered cautiously, as making associations to Gateway API's notion of Gateway, Route, and Service to other +implementation's objects is hard to directly translate. The idea of a route in Gateway API is often not the same as a +route in any given implementation. + +### API Attachment Points + +The new `BackendLBPolicy` metaresource only supports attaching to a backend. A backend can be a Service, +ServiceImport (see [GEP-1748](../gep-1748/index.md)), or any implementation-specific backends that are a valid +[`BackendObjectReference`](../../reference/spec.md#gateway.networking.k8s.io%2fv1.BackendObjectReference). Enabling session +persistence for a backend enables subsequently enables it for any route directing traffic to this backend. To learn more +about the process of attaching a policy to a backend, please refer to [GEP-713](../gep-713/index.md). + +On the other hand, configuring the `sessionPersistence` field in the route rule enables session persistence exclusively +for the traffic directed to the `backendRefs` in this route rule. This means applying session persistence configuration +to a route rule MUST NOT affect traffic for other routes or route rules. Designing the configuration for a specific +route rule section rather than the route entirely, allows users to configure session persistence in a more granular +fashion. This approach avoids the need to decompose routes if the configuration is specific to a route path. + +Session persistence configuration specified in a route rule SHALL override equivalent configuration in `BackendLBPolicy`. +In this situation, implementations MAY want to indicate a warning via a log or status. Refer to [GEP-713](../gep-713/index.md) +and/or [GEP-2648](../gep-2648/index.md) for more specific details on how to handle override scenarios. + +Edge cases will arise when implementing session persistence support for both backends and route rules through +`BackendLBPolicy` and the route rule's `sessionPersistence` field. For guidance on addressing conflicting +attachments, please consult the [Edge Case Behavior](#edge-case-behavior) section, which outlines API +use cases. Only a subset of implementations have already designed their data plane to incorporate route rule level session +persistence, making it likely that route rule level session persistence will be less widely implemented. + +### Traffic Splitting + +In scenarios involving traffic splitting, session persistence impacts load balancing done after routing. +When a persistent session is established and traffic splitting is configured across services, the persistence to a single backend MUST be maintained across services, even if the weight is set to 0. +Consequently, a persistent session takes precedence over traffic split +weights when selecting a backend after route matching. It's important to note that session persistence does not impact +the process of route matching. + +When using multiple backends in traffic splitting, all backend services should have session persistence enabled. +Nonetheless, implementations MUST carefully consider how to manage traffic splitting scenarios in which one service has +persistence enabled while the other does not. This includes scenarios where users are transitioning to or from an +implementation version designed with or without persistence. For traffic splitting scenario within a single route rule, +this GEP leaves the decision to the implementation. Implementations MUST choose to apply session persistence to all +backends equally, reject the session persistence configuration entirely, or apply session persistence only for the +backends with it configured. + +See [Edge Case Behavior](#edge-case-behavior) for more use cases on traffic splitting. + +### Cookie Attributes + +While the API is intended to be generic, as described in [API Granularity](#api-granularity), a majority of +implementations will employ session persistence through cookies. Therefore, let's explore the possibilities of cookie +configuration for these APIs. + +A cookie is composed of various attributes, each represented as key=value pairs. While some attributes may have optional +values, the cookie name attribute is the only mandatory one, and the rest are considered optional. + +The cookie attributes defined by [RFC6265](https://www.rfc-editor.org/rfc/rfc6265#section-5.2) are: + +- Name=_value_ +- Expires=_date_ +- Max-Age=_number_ +- Domain=_domain_ +- Path=_path-value_ +- Secure +- HttpOnly + +Other cookie attributes not defined by RFC6265, but are captured in draft RFCs and could be considered de facto +standards due to wide acceptance are: + +- SameSite=[Strict|Lax|None] +- Partitioned + +Unless a `sessionPersistence` API field can be satisfied through a manipulating a cookie attribute, the attributes +of the cookies are considered as opaque values in this spec and are to be determined by the individual implementations. +Let's discuss some of these cookie attributes in more detail. + +#### Name + +The `Name` cookie attribute MAY be configured via the `SessionName` field in `sessionPersistence`. However, this field +is implementation-specific because it's impossible to create a conformance test for it, given that sessions could be +created in a variety of ways. Additionally, `SessionName` is not universally supported as some implementations, such as +ones supporting global load balancers, don't have the capability to configure the cookie name. Some implementations +have a fixed cookie name, and therefore `SessionName` may be reflected in the value of the cookie. + +The use case for modifying the cookie name using `SessionName` is that certain users might need to align it with an +existing cookie name, such as Java's `JSESSIONID`. Refer to [Session Initiation Guidelines](#session-initiation-guidelines) +for details on how this GEP supports existing sessions. If `SessionName` is not specified, then a unique cookie name +should be generated. + +#### Expires / Max-Age + +The `Expires` and `Max-Age` cookie attributes are important in distinguishing between [session cookies and permanent +cookies](https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies#define_the_lifetime_of_a_cookie). Session cookies do +not include either of these attributes, while permanent cookies will contain one of them. Session cookies can still +have an expiration or timeout, but it will be accomplished through alternative mechanisms, such as the proxy tracking +the cookie's lifetime via its value. + +The `LifetimeType` API field specifies whether a cookie should be a session or permanent cookie. Additionally, the lifetime +or timeout for both session and permanent cookies is represented by `AbsoluteTimeout`. In the case of +`LifetimeType` being `Permanent`, `AbsoluteTimeout` MUST configure the `Expires` or `Max-Age` cookie attributes. +Conversely, if `LifetimeType` is `Session`, `AbsoluteTimeout` MUST regulate the cookie's lifespan through a +different mechanism, as mentioned above. If `LifetimeType` is set to `Permanent`, then `AbsoluteTimeout` MUST +also be set as well. This requirement is necessary because an expiration value is required to set `Expires` or `Max-Age`. +`LifetimeType` of `Session` is core support level and the default, while `LifetimeType` of `Permanent` is extended. + +See [issue #2747](https://github.com/kubernetes-sigs/gateway-api/issues/2747) for more context regarding distinguishing +between permanent and session cookies. + +#### Path + +The cookie's `Path` attribute defines the URL path that must exist in order for the client to send the `cookie` header. +Whether attaching session persistence to an xRoute or a service, it's important to consider the relationship the cookie +`Path` attribute has with the route path. + +When session persistence is enabled on a xRoute rule, the implementor should interpret the path as +configured on the xRoute. To interpret the `Path` attribute from an xRoute, implementors should take note of the +following: + +1. For an xRoute that matches all paths, the `Path` should be set to `/`. +2. For an xRoute that has multiple paths, the `Path` should be interpreted based on the route path that was matched. +3. For an xRoute using a path that is a regex, the `Path` should be set to the longest non-regex prefix (.e.g. if the + path is /p1/p2/*/p3 and the request path was /p1/p2/foo/p3, then the cookie path would be /p1/p2). + +It is also important to note that this design makes persistent session unique per route path. For instance, if two +distinct routes, one with path prefix `/foo` and the other with `/bar`, both target the same service, the persistent +session won't be shared between these two paths. + +Conversely, if the `BackendLBPolicy` policy is attached to a service, the `Path` attribute MUST be left +unset. This is because multiple routes can target a single service. If the `Path` cookie attribute is configured in this +scenario, it could result in problems due to the possibility of different paths being taken for the same cookie. +Implementations MUST also handle the case where the client is a browser making requests to multiple persistent services +from the same page. + +#### Secure, HttpOnly, SameSite + +The `Secure`, `HttpOnly`, and `SameSite` cookie attributes are security-related. The API implementers SHOULD follow the +security-by-default principle and configure these attributes accordingly. This means enabling `Secure` and `HttpOnly`, +and setting `SameSite` to `Strict`. However, in certain implementation use cases such as service mesh, secure values +might not function as expected. In such cases, it's acceptable to make appropriate adjustments. + +### Session Persistence API with GAMMA + +The object of the [GAMMA (Gateway API for Mesh Management and Administration)](../../mesh/gamma.md) +initiative is to provide support for service mesh and mesh-adjacent use-cases with Gateway API. GAMMA is focused on +defining how Gateway API could also be used for inter-service or [east/west](../../concepts/glossary.md#eastwest-traffic) +traffic within the same cluster. + +Given that service meshes commonly have session persistence requirements, this API design should take into consideration +session persistence needs in GAMMA and service mesh scenarios. + +### Session Initiation Guidelines + +As illustrated in the examples provided in [Session Persistence Initiation](#session-persistence-initiation), +implementations must consider how to manage sessions initiated by other components. As mentioned in [Backend Initiated Session Example](#backend-initiated-session-example), +this GEP does not support configuring backend-initiated persistent sessions. We leave the decision of handling existing +sessions with each specific implementation. In the case of cookie-based session persistence, an implementation MAY +either rewrite the cookie or insert an additional cookie, or to do nothing (resulting in the lack of a +persistent session). In general, inserting an additional cookie is a generally safe option, but it's important for +implementations to exercise their own discretion. However, regardless of the implementation's design choice, the +implementation MUST be able to handle multiple cookies. + +### Session Persistence Failure Behavior + +In a situation where session persistence is configured and the backend becomes unhealthy, this GEP doesn't specify a +prescribed fallback behavior mechanism or HTTP status code. Implementations MAY exhibit different behaviors depending +on whether active health checking is enabled. Data planes MAY fall back to available backends, disregarding the broken +session, and reestablish session persistence when the backend becomes available again. + +### Edge Case Behavior + +Implementing session persistence is complex and involves many edge cases. In this section, we will outline API +configuration scenarios (use cases) and how implementations should handle them. + +#### Attaching Session Persistence to both Service and a Route Rule + +In a situation which: + +- `ServiceA` with `BackendLBPolicy` attached +- `RouteX` with `sessionPersistence` configured on the route rule and backend `ServiceA` + +The `sessionPersistence` configuration inline to `RouteX` route rule MUST take precedence over `BackendLBPolicy`. Since +routes direct traffic to services, the policy attached to route operates at a higher-level and MUST override policies +applied to individual services. + +```mermaid +graph TB + RouteX ----> ServiceA((ServiceA)) + BackendLBPolicyServiceA[BackendLBPolicy] -.-> ServiceA + BackendLBPolicyRouteA[SessionPersistence] -.Precedence.-> RouteX + linkStyle 2 stroke:red; +``` + +#### Two Routes Rules have Session Persistence to the Same Service + +Consider the situation in which two different route paths have session persistence configured and are going to the same +service: + +```yaml +kind: HTTPRoute +metadata: + name: routeX +spec: + rules: + - matches: + - path: + value: /a + backendRefs: + - name: servicev1 + sessionPersistence: + name: session-a + - matches: + - path: + value: /b + backendRefs: + - name: servicev1 + weight: 0 + - name: servicev2 + weight: 100 + sessionPersistence: + name: session-b +``` + +Route rules referencing the same service MUST NOT share persistent sessions (i.e. the same cookie). Let's illustrate +this by the following commands: + +1. Curl to `/a` which establishes a persistent session with `servicev1` +2. Curl to `/b` routes MUST direct traffic to `servicev2` since the persistent session established earlier is not + shared with this route path. + +#### Route Rules Referencing to a Session Persistent Enabled Service Must Not Share Sessions + +Consider the situation in which two different route paths are going to the same service, and session persistence is enabled with the service via `BackendLBPolicy`: + +```yaml +kind: HTTPRoute +metadata: + name: routeX +spec: + rules: + - matches: + - path: + value: /a + backendRefs: + - name: servicev1 + - matches: + - path: + value: /b + backendRefs: + - name: servicev1 +--- +kind: BackendLBPolicy +metadata: + name: lbp +spec: + targetRef: + kind: Service + Name: servicev1 + sessionPersistence: + sessionName: service-cookie + type: Cookie +``` + +Route rules referencing the same service MUST NOT share persistent sessions (i.e. the same cookie), even if the session persistence is attached to the service via `BackendLBPolicy`, and each route rule should have different persistent sessions. + +1. Curl to `/a` which establishes a persistent session with `servicev1` +2. Curl to `/b` which establishes another persistent session with `servicev1` since the previous session established earlier is not shared with this route path. + +#### Session Naming Collision + +Consider the situation in which two different services have cookie-based session persistence configured with the +same `sessionName`: + +```yaml +kind: HTTPRoute +metadata: + name: split-route +spec: + rules: + - backendRefs: + - name: servicev1 + weight: 50 + - name: servicev2 + weight: 50 +--- +kind: BackendLBPolicy +metadata: + name: lbp-split-route +spec: + targetRef: + kind: Service + Name: servicev1 + sessionPersistence: + sessionName: split-route-cookie + type: Cookie +--- +kind: BackendLBPolicy +metadata: + name: lbp-split-route2 +spec: + targetRef: + kind: Service + Name: servicev2 + sessionPersistence: + sessionName: split-route-cookie + type: Cookie +``` + +This is an invalid configuration as two separate sessions cannot have the same cookie name. Implementations SHOULD +address this scenario in manner they deem appropriate. Implementations MAY choose to reject the configuration, or they +MAY non-deterministically allow one cookie to work (e.g. whichever cookie is configured first). + +#### Traffic Splitting with route rule inline sessionPersistence field + +Consider the scenario where a route is traffic splitting between two backends, and additionally, an inline route rule `sessionPersistence` config is applied: + +```yaml +kind: HTTPRoute +metadata: + name: split-route +spec: + rules: + - backendRefs: + - name: servicev1 + weight: 50 + - name: servicev2 + weight: 50 + sessionPersistence: + sessionName: split-route-cookie + type: Cookie +``` + +In this scenario, session persistence is enabled at route rule level and all services in the traffic split have persistent session. + +That is to say, traffic routing to `servicev1` previously MUST continue to be routed to `servicev1` when cookie is present, and traffic routing to `servicev2` previously MUST continue to be routed to `servicev2` when cookie is present. + +When cookie is not present, such as, a new session, it will be routed based on the `weight` configuration and choose one of the services. + +#### Traffic Splitting with BackendLBPolicy attached to some Backends (not all) + +Consider the scenario where a route is traffic splitting between two backends, and additionally, a +`BackendLBPolicy` with `sessionPersistence` config is attached to one of the services: + +```yaml +kind: HTTPRoute +metadata: + name: split-route +spec: + rules: + - backendRefs: + - name: servicev1 + weight: 50 + - name: servicev2 + weight: 50 +--- +kind: BackendLBPolicy +metadata: + name: lbp-split-route +spec: + targetRef: + kind: Service + Name: servicev1 + sessionPersistence: + sessionName: split-route-cookie + type: Cookie +``` + +In this traffic splitting scenario within a single route rule, this GEP leaves the decision to the implementation. An +implementation MUST choose one of the following: + +1. Apply session persistence configured in `BackendLBPolicy` to `servicev1` and `servicev2` equally +2. Reject the session persistence configured in `BackendLBPolicy` so that `servicev1` does not have session persistence +3. Apply session persistence for only `servicev1`, potentially causing all traffic to eventually migrate to `servicev1` + +This is also described in [Traffic Splitting](#traffic-splitting). + +#### A Service's Selector is Dynamically Updated + +In Kubernetes, it's possible to modify the [selector](https://kubernetes.io/docs/concepts/services-networking/service/#services-in-kubernetes) +of a service after the gateway has established persistent sessions with it. + +```yaml +kind: Service +metadata: + name: my-service +spec: + selector: + app.kubernetes.io/name: MyApp # Service selector can change +``` + +The expected behavior is that the gateway SHOULD retain existing persistent sessions, even if the pod is no longer +selected, and establish new persistent sessions after a selector update. This use case is uncommon and may not be +supported by some implementations due to their current designs. + +### Conformance Details + +TODO + +### Open Questions + +- What happens when session persistence causes traffic splitting scenarios to overload a backend? +- Should we add status somewhere when a user gets into a "risky" configuration with session persistence? +- Should there be an API configuration field that specifies how already established sessions are handled? +- How do implementations drain established sessions during backend upgrades without disruption? + - Do we need a "session draining timeout" as documented by [A55: xDS-Based Stateful Session Affinity for Proxyless gRPC](https://github.com/grpc/proposal/blob/master/A55-xds-stateful-session-affinity.md#background) + defined in this API? +- How do we provide a standard way to communicate that an implementation does not support Route Rule API? + - Do we want something conceptually similar to the `IncompatibleFilters` reason? + +## TODO + +The following are items that we intend to resolve in future revisions: + +- We need to identify and document requirements regarding session draining and migration. +- We need to document sessions with Java in greater detail. Java standardized the API and behavior of session persistence long ago and would be worth examining. +- We need to add a small section on compliance regarding the browser and client relationship. +- We need to finish enumerating all the edge cases in [Edge Case Behavior](#edge-case-behavior) and identify +potential scenarios where session persistence could break so an implementation can implement session persistence in a +predicable way. +- We need to clean up the [Implementations](#implementations) table to make it more organized and readable. +- We need to revisit how to indicate to a user that a `BackendLBPolicy` configuration is being overridden by a route +configuration via a warning status or log. + - This might require addressing as part of an update to [GEP-2648](../gep-2648/index.md). + +## Alternatives + +### SessionPersistence API Alternative + +Taking a different approach, this GEP could design a more specific policy for configuring session persistence. Rather +than containing all load balancing configuration within a single metaresource, we could opt for a more specific design +with a metaresource called `SessionPersistencePolicy`, specifically to handle session persistence configuration. + +The advantage of `SessionPersistencePolicy` is that it is more specific, which may enable a smoother transition to +attaching to routes in the future (see [Route Attachment Future Work](#route-attachment-future-work)). + +```go +// SessionPersistencePolicy provides a way to define session persistence rules +// for a service or route. +type SessionPersistencePolicy struct { + metav1.TypeMeta `json:",inline"` + metav1.ObjectMeta `json:"metadata,omitempty"` + + // Spec defines the desired state of SessionPersistencePolicy. + Spec SessionPersistencePolicySpec `json:"spec"` + + // Status defines the current state of SessionPersistencePolicy. + Status PolicyStatus `json:"status,omitempty"` +} + +// SessionPersistencePolicySpec defines the desired state of +// SessionPersistencePolicy. +// Note: there is no Override or Default policy configuration. +type SessionPersistencePolicySpec struct { + // TargetRef identifies an API object to apply policy to. + TargetRef gatewayv1a2.PolicyTargetReference `json:"targetRef"` + + // SessionName defines the name of the persistent session token + // (e.g. a cookie name). + // + // +optional + // +kubebuilder:validation:MaxLength=4096 + SessionName String `json:"sessionName,omitempty"` +} +``` + +### HTTPCookie API Alternative + +Alternatively, the API for session persistence could be tightly coupled to cookies rather than being generic as +described in [API Granularity](#api-granularity). The advantage here is the API's ability to offer greater control +through specific cookie attributes and configuration, catering to the needs of advanced users. However, there could be +challenges with implementations adhering to an API that is closely tied to cookies. This alternative could apply to the +current [`BackendLBPolicy`](#api) design or the [`SessionPersistencePolicy`](#sessionpersistence-api-alternative) +alternative. + +The cookie attributes can be defined either as a loosely-typed list of attributes or as strongly-typed attribute fields. +A loosely-typed list approach offers a more flexible specification, particularly when new attributes need to be +introduced. However, loosely-typed lists may not be as user-friendly due to the lack of validation. + +```go +// HttpCookie defines a cookie to achieve session persistence. +type HttpCookie struct { + // Name defines the cookie's name. + // + // +kubebuilder:validation:MaxLength=4096 + Name String `json:"name,omitempty"` + + // CookieAttributes defines the cookie's attributes. + // + // +optional + CookieAttributes []CookieAttribute `json:cookieAttributes` +} + +// CookieAttribute defines the cookie's attributes. +type CookieAttribute map[string][]string +) +``` + +Strongly-typed attribute fields provide a more user-friendly experience by offering stronger validation for each of the +fields. A strongly-type cookie API could be a mix of individual fields and listed attributes. More specifically, we +could separate the key attributes with no value into a list. This approach is taken by [Haproxy Ingress](https://haproxy-ingress.github.io/docs/configuration/keys/#affinity) +with their `session-cookie-keywords` field. This provides flexibility for simple boolean-typed attributes, while +validating attributes that have values. However, this approach may be confusing to users as uses two different API +patterns for cookie attributes. + +```go +// HttpCookie defines a cookie to achieve session persistence. +type HttpCookie struct { + // Name defines the cookie's name. + // + // +kubebuilder:validation:MaxLength=4096 + Name String `json:"name,omitempty"` + + // SameSite defines the cookie's SameSite attribute. + // + // +optional + // +kubebuilder:validation:Enum=Strict;Lax;None + SameSite SameSiteType `json:"sameSite,omitempty"` + // Domain defines the cookie's Domain attribute. + // + // +optional + // +kubebuilder:validation:MaxLength=4096 + Domain String `json:"domain,omitempty"` + + // CookieKeywords defines the cookie's attributes that have no value. + // + // +optional + CookieKeywords []CookieKeyword `json:cookieKeywords` +} + +// CookieKeyword defines the cookie's attributes that have no value. +type CookieKeyword string + +const ( + // CookieKeywordsHttpOnly specifies the HttpOnly cookie attribute. + CookieKeywordsHttpOnly HttpOnlyMode = "HttpOnly" + // CookieKeywordsSecure specifies the Secure cookie attribute. + CookieKeywordsSecure HttpOnlyMode = "Secure" +) +``` + +### Alternate Naming + +This GEP describes session persistence and session affinity as the idea of strong and weak connection persistence respectively. Other technologies use different names or define persistence and affinity differently: + +- Envoy defines [stateful sessions](https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/http/stateful_session/cookie/v3/cookie.proto) as what we've defined as session persistence +- Google Cloud Run defines [session affinity](https://cloud.google.com/run/docs/configuring/session-affinity) as what we've defined as session persistence +- Nginx defines [session persistence](https://docs.nginx.com/nginx/admin-guide/load-balancer/http-load-balancer/#enabling-session-persistence) as what we've defined as both session persistence and affinity +- Traefik defines [sticky sessions](https://doc.traefik.io/traefik/routing/services/#sticky-sessions) as what we've defined as session persistence +- Apache httpd defines [sticky sessions or stickiness](https://httpd.apache.org/docs/2.4/mod/mod_proxy_balancer.html) as what we've defined as session persistence +- Kubernetes defines [session affinity](https://kubernetes.io/docs/reference/networking/virtual-ips/#session-affinity) based on client IP hashing (same as our session affinity) +- Microsoft Application Gateway defines [session affinity, session persistence, and sticky sessions](https://learn.microsoft.com/en-us/azure/application-gateway/for-containers/session-affinity?tabs=session-affinity-gateway-api) as what we've defined as session persistence + +Though session persistence is a ubiquitous name, session affinity is more inconsistently used. An alternate decision could be made to use a different name for session affinity based on the prevalence of other naming conventions. + +## References + +- [LBPolicy](https://static.sched.com/hosted_files/kccnceu2023/c4/Autoscaling%20Elastic%20Kubernetes%20Infrastructure%20for%20Stateful%20Applications%20using%20Proxyless%20gRPC%20and%20Istio.pdf#page=25) (proposed extension for session persistence API) +- [gRPC Stateful Session Affinity Proposal](https://github.com/grpc/proposal/blob/master/A55-xds-stateful-session-affinity.md) (info on session draining and session persistence in gRPC) +- [Kube-Proxy Session Affinity](https://kubernetes.io/docs/reference/networking/virtual-ips/#session-affinity) +- [GEP-713: Metaresources and PolicyAttachment](../gep-713/index.md) +- [RFC6265](https://www.rfc-editor.org/rfc/rfc6265) +- [Policy Attachment](../../reference/policy-attachment.md) +- [Envoy Session Persistence Design Doc](https://docs.google.com/document/d/1IU4b76AgOXijNa4sew1gfBfSiOMbZNiEt5Dhis8QpYg/edit#heading=h.sobqsca7i45e) +- [Envoy Session Persistence Issue](https://github.com/envoyproxy/envoy/issues/16698) diff --git a/site-src/ko/geps/gep-1619/metadata.yaml b/site-src/ko/geps/gep-1619/metadata.yaml new file mode 100644 index 0000000000..d7d009cf35 --- /dev/null +++ b/site-src/ko/geps/gep-1619/metadata.yaml @@ -0,0 +1,23 @@ +apiVersion: internal.gateway.networking.k8s.io/v1alpha1 +kind: GEPDetails +number: 1619 +name: Session Persistence +status: Provisional +authors: + - gcs278 + - sjberman + - robscott +relationships: + seeAlso: + - number: 713 + name: Metaresources and Policy Attachment + description: Defines metaresource and policy attachment API + - number: 2257 + name: Gateway API Duration Format + description: Defines the Duration API field +changelog: + - "https://github.com/kubernetes-sigs/gateway-api/pull/1643" + - "https://github.com/kubernetes-sigs/gateway-api/pull/1889" + - "https://github.com/kubernetes-sigs/gateway-api/pull/1935" + - "https://github.com/kubernetes-sigs/gateway-api/pull/2159" + - "https://github.com/kubernetes-sigs/gateway-api/pull/2634" diff --git a/site-src/ko/geps/gep-1651/index.md b/site-src/ko/geps/gep-1651/index.md new file mode 100644 index 0000000000..967c65d59e --- /dev/null +++ b/site-src/ko/geps/gep-1651/index.md @@ -0,0 +1,420 @@ +# GEP-1651: Gateway Routability + +* Issue: [#1651](https://github.com/kubernetes-sigs/gateway-api/issues/1651) +* Status: Provisional + +(See [status definitions](../overview.md#gep-states).) + +## TLDR + +Allow users to configure a Gateway so that it is only routable within +a specific scope (ie. public/private/cluster) + +## Goals + +- Define a mechanic to set the routability on a Gateway +- Provide a default set of routability options +- Provide a way for vendors to support custom options + +## Non-Goals + +- Per-request/route scope +- Not a lightweight service mesh + +## Introduction + +One of the early feature requests for Knative was the ability to deploy an +application using Knative's HTTP routing support, but make it only available +within the cluster. I want to be able to specify both the "cluster" +(service.namespace.svc) and "external" (service.namespace.example.com). +Gateways using the same GatewayClass on the cluster, but ensure that the +"cluster" service is only routable within the cluster. This would greatly +simplify deployment for users over the instructions we have today. + +Likewise another use case is to provide load balancing capabilities within a virtual +private network. Different IaaS providers offer private load balancers to support +these use cases. + +## API + +We propose adding a new `routability` field under the `spec.infrastructure` stanza of a Gateway. + +### Predefined Routability Values + +Implementations MAY implement the following values for 'routability' and MUST abide by +their defined semantics. + +Value | Scope +-|- +`Public`|The address is routable on the public internet +`Private`|The address is routable inside a private network larger than a single cluster (ie. VPC) and MAY include RFC1918 address space +`Cluster`|The address is routable inside the [cluster's network](https://kubernetes.io/docs/concepts/cluster-administration/networking/#how-to-implement-the-kubernetes-network-model) + +Values can be compared semantically - `Public` has a larger scope than `Private`, while `Private` has a larger scope than `Cluster`. + +### Vendor prefixed values + +Implementations can define custom 'routability' values by specifying a vendor prefix followed +by a slash `/` and a custom name ie. `com.example.com/my-routability`. + +Comparing vendor prefixed scopes with the pre-defined ones in implementation specific. + +### Default Routability + +The default value of `routability` is implementation specific. It is RECOMMENDED that +the default `routability` remains consistent for Gateways with the same +`gatewayClassName`. + +Implementations MUST signal the default routability using the Gateway's `status.addresses`. See 'Status Addresses` +for more details. + +### Mutability + +Implementations MAY prevent end-users from updating the `routability` value of a Gateway. If +updates are allowed the semantics and behaviour will depend on the underlying implementation. + +If a Gateway is mutated but does not support the desired routability it MUST set the conditions +`Accepted`, `Programmed` to `False` with `Reason` set to `UnsupportedRoutability`. Implementations +MAY choose to leave the old Gateway running with the previous generation's configuration. + +### Go + +```go + +// GatewayRoutability represents the routability of a Gateway +// +// The pre-defined values listed in this package can be compared semantically. +// `Public` has a larger scope than `Private`, while `Private` has a larger scope than +// `Cluster`. +// +// Implementations can define custom routability values by specifying a vendor +// prefix followed by a slash '/' and a custom name ie. `dev.example.com/my-routability`. +// +// +kubebuilder:validation:MinLength=1 +// +kubebuilder:validation:MaxLength=253 +// +kubebuilder:validation:Pattern=`^Public|Private|Cluster|[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*\/[A-Za-z0-9\/\-_]+$` +type GatewayRoutability string + +const ( + // GatewayRoutabilityPublic means the Gateway's address MUST + // be routable on the public internet + // + // Implementations MAY support this routability + GatewayRoutabilityPublic GatewayRoutability = "Public" + + // GatewayRoutabilityPrivate means the Gateway's address MUST + // only be routable inside a private network larger than a single + // cluster (ie. VPC) and MAY include the RFC1918 address space + // + // Implementations MAY support this routability + GatewayRoutabilityPrivate GatewayRoutability = "Private" + + // GatewayRoutabilityCluster means the Gateway's address MUST + // only be routable inside the [cluster's network] + // + // Implementations MAY support this routability + // + // [cluster's network](https://kubernetes.io/docs/concepts/cluster-administration/networking/#how-to-implement-the-kubernetes-network-model) + GatewayRoutabilityCluster GatewayRoutability = "Cluster" +) + +type GatewaySpec struct { + // Infrastructure defines infrastructure level attributes about this Gateway instance. + Infrastructure GatewayInfrastructure `json:"infrastructure"` + // ... +} +type GatewayInfrastructure struct { + // Routability allows the Gateway to specify the accessibility of its addresses. Setting + // this property will override the default value defined by the GatewayClass. + // + // If the desired Gateway routability is incompatible with the GatewayClass implementations + // MUST set the condition `Accepted` to `False` with `Reason` set to `UnsupportedRoutability`. + + // The default value of routability is implementation specific and MUST remains consistent for + // Gateways with the same gatewayClassName + // + // Implementations MAY prevent end-users from updating the routability value of a Gateway. + // If updates are allowed the semantics and behaviour will depend on the underlying implementation. + // If a Gateway is mutated but does not support the desired routability it MUST set `Accepted` + // and `Programmed` conditions to `False` with `Reason` set to `UnsupportedRoutability`. + // + // It is RECOMMENDED that in-cluster gateways SHOULD NOT support 'Private' routability. + // Kubernetes doesn't have a concept of 'Private' routability for Services. In the future this may + // change upstream. + // + // +optional + Routability *GatewayRoutability `json:"routability,omitempty"` +} + +type GatewayStatus struct { + // 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. + // + // Implementations that support Gateway routability MUST include an address + // that has the same routable semantics as defined in the Gateway spec. + // + // Implementations MAY add additional addresses in status, but they MUST be + // semantically less than the scope of the requested scope. For example if a + // user requests a `Private` routable Gateway then an additional address MAY + // have a routability of `Cluster` but MUST NOT include `Public`. + // + // +optional + // +kubebuilder:validation:MaxItems=16 + Addresses []GatewayStatusAddress `json:"addresses,omitempty"` + // ... +} + +type GatewayStatusAddress struct { + // Routability specifies the routable bounds of this address + // Predefined values are: 'Private', 'Public', Cluster + // Other values MUST have a vendor prefix. + // + // Implementations that support Routability MUST populate this + // field + // + // +optional + Routability *GatewayRoutability `json:"routability,omitempty"` + + // ... +} + +type GatewayClassStatus struct { + // Routabilities specifies a list of supported routabilities offered by + // the GatewayClass. The first entry in this list will be the default + // routability used when Gateways of this class are created. + // + // Implementations MAY provide a pre-defined set of GatewayClasses that + // limit the routability choices of a Gateway. + // + // Implementations that support routability MUST populate this list with + // a subset of the pre-defined GatewayRoutability values or vendored + // prefix values. + // + // +optional + // +kubebuilder:validation:MaxItems=8 + //
CM max_connection_duration + P->>U: Starts sending Request + P->>U: Finishes Headers + note left of P: CM request_timeout + P->>U: Finishes request + deactivate P + activate U + U->>P: Starts Response + U->>P: Finishes Headers + note right of U: R timeout
R per_try_timeout
R per_try_idle_timeout + U->>P: Finishes Response + deactivate U + P->>C: Starts Response + P->>C: Finishes Headers + P->>C: Finishes Response + Note left of C: CM stream_idle_timeout
R idle_timeout
CM,R max_stream_duration
TCP proxy idle_timeout
TCP protocol idle_timeout + deactivate C + Note right of P: Repeat if connection sharing + U->>C: Connection ended + deactivate U +``` + +#### Nginx timeouts + +Nginx allows setting of GRPC and general HTTP timeouts separately, although the +purposes seem to be roughly equivalent. + +```mermaid +sequenceDiagram + participant C as Client + participant P as Nginx + participant U as Upstream + C->>P: Connection Started + activate P + C->>P: Starts sending Request + C->>P: Finishes Headers + Note right of P: client_headers_timeout + deactivate P + activate P + C->>P: Finishes request + deactivate P + Note right of P: client_body_timeout + activate U + note left of U: proxy_connect_timeout
grpc_connect_timeout + deactivate U + P->>U: Connection Started + Activate U + Activate U + P->>U: Starts sending Request + P->>U: Finishes Headers + P->>U: Finishes request + Note right of U: (between write operations)
proxy_send_timeout
grpc_send_timeout + deactivate U + activate U + U->>P: Starts Response + U->>P: Finishes Headers + Note right of U: (between read operations)
proxy_read_timeout
grpc_read_timeout + U->>P: Finishes Response + deactivate U + activate P + P->>C: Starts Response + P->>C: Finishes Headers + P->>C: Finishes Response + deactivate P + Note left of P: send_timeout (only between two successive write operations) + Note left of C: Repeat if connection is shared until server's keepalive_timeout is hit + Note Right of U: upstream's keepalive_timeout (if keepalive enabled) + U->>C: Connection ended + deactivate U +``` + +#### HAProxy timeouts + +```mermaid +sequenceDiagram + participant C as Client + participant P as Proxy + participant U as Upstream + + C->>P: Connection Started + activate U + activate C + activate P + note left of P: timeout client (idle) + C->>P: Starts sending Request + C->>P: Finishes Headers + C->>P: Finishes request + note left of C: timeout http-request + deactivate C + activate C + note left of C: timeout client-fin + deactivate C + deactivate P + activate U + note left of U: timeout queue
(wait for available server) + deactivate U + + P->>U: Connection Started + activate U + P->>U: Starts sending Request + activate U + P->>U: Finishes Headers + P->>U: Finishes request + + note right of U: timeout connect + deactivate U + note left of U: timeout server
(idle timeout) + deactivate U + activate U + note left of U: timeout server-fin + deactivate U + U->>P: Starts Response + U->>P: Finishes Headers + U->>P: Finishes Response + P->>C: Starts Response + P->>C: Finishes Headers + P->>C: Finishes Response + activate C + note left of C: timeout http-keep-alive + deactivate C + Note right of P: Repeat if connection sharing + Note right of U: timeout tunnel
(for upgraded connections) + deactivate U + U->>C: Connection ended + +``` + +#### Traefik timeouts + +```mermaid +sequenceDiagram + participant C as Client + participant P as Proxy + participant U as Upstream + C->>P: Connection Started + activate U + C->>P: Starts sending Request + activate P + C->>P: Finishes Headers + Note right of P: respondingTimeouts
readTimeout + C->>P: Finishes request + deactivate P + P->>U: Connection Started + activate U + Note right of U: forwardingTimeouts
dialTimeout + deactivate U + P->>U: Starts sending Request + P->>U: Finishes request + P->>U: Finishes Headers + U->>P: Starts Response + activate U + note right of U: forwardingTimeouts
responseHeaderTimeout + U->>P: Finishes Headers + deactivate U + U->>P: Finishes Response + P->>C: Starts Response + activate P + P->>C: Finishes Headers + Note right of P: respondingTimeouts
writeTimeout + P->>C: Finishes Response + deactivate P + Note right of P: Repeat if connection sharing + Note right of U: respondingTimeouts
idleTimeout
Keepalive connections only + deactivate U + U->>C: Connection ended + +``` +#### F5 BIG-IP Timeouts + +Could not find any HTTP specific timeouts. PRs welcomed. 😊 + +#### Pipy Timeouts + +Could not find any HTTP specific timeouts. PRs welcomed. 😊 + +#### Litespeed WebADC Timeouts + +Could not find any HTTP specific timeouts. PRs welcomed. 😊 + +## API + +The above diagrams show that there are many different kinds of configurable timeouts +supported by Gateway implementations: connect, idle, request, upstream, downstream. +Although there may be opportunity for the specification of a common API for more of +them in the future, this GEP will focus on the L7 timeouts in HTTPRoutes that are +most valuable to clients. + +From the above analysis, it appears that most implementations are capable of +supporting the configuration of simple client downstream request timeouts on HTTPRoute +rules. This is a relatively small addition that would benefit many users. + +Some implementations support configuring a timeout for individual backend requests, +separate from the overall client request timeout. This is particularly useful if a +client HTTP request to a gateway can result in more than one call from the gateway +to the destination backend service, for example, if automatic retries are supported. +Adding support for this would also benefit many users. + +### Timeout values + +There are 2 kinds of timeouts that can be configured in an `HTTPRouteRule`: + +1. `timeouts.request` is the timeout for the Gateway API implementation to send a + response to a client HTTP request. Whether the gateway starts the timeout before + or after the entire client request stream has been received, is implementation dependent. + This field is optional `Extended` support. + +1. `timeouts.backendRequest` is a timeout for a single request from the gateway to a backend. + This field is optional `Extended` support. Typically used in conjunction with retry configuration, + if supported by an implementation. + Note that retry configuration will be the subject of a separate GEP (GEP-1731). + +```mermaid +sequenceDiagram + participant C as Client + participant P as Proxy + participant U as Upstream + C->>P: Connection Started + note left of P: timeouts.request start time (min) + C->>P: Starts sending Request + C->>P: Finishes Headers + C->>P: Finishes request + note left of P: timeouts.request start time (max) + P->>U: Connection Started + note right of P: timeouts.backendRequest start time + P->>U: Starts sending Request + P->>U: Finishes request + P->>U: Finishes Headers + U->>P: Starts Response + U->>P: Finishes Headers + note right of P: timeouts.backendRequest end time + note left of P: timeouts.request end time + U->>P: Finishes Response + note right of P: Repeat if retry + P->>C: Starts Response + P->>C: Finishes Headers + P->>C: Finishes Response + Note right of P: Repeat if connection sharing + U->>C: Connection ended +``` + +Both timeout fields are [GEP-2257 Duration] values. A zero-valued timeout +("0s") MUST be interpreted as disabling the timeout; a non-zero-valued timeout +MUST be >= 1ms. + +[GEP-2257 Duration]:../gep-2257/index.md + +### GO + +```go +type HTTPRouteRule struct { + // Timeouts defines the timeouts that can be configured for an HTTP request. + // + // Support: Extended + // + // +optional + //
first created wins
otherwise first alphabetically | Namespace override B | Namespace override B| +|Gateway override B| Gateway override B | Namespace override A| Gateway override
first created wins
otherwise first alphabetically | Gateway override B| +|HTTPRoute override B| HTTPRoute override B | Namespace override A| Gateway override A| HTTPRoute override
first created wins
otherwise first alphabetically| + +#### Defaults interacting with other defaults for RetryOnPolicy, empty list in HTTPRoute +||No default|Namespace default A|Gateway default A|HTTPRoute default A| +|----|-----|-----|----|----| +|No default|Empty list|Namespace default| Gateway default| HTTPRoute default A| +|Namespace default B| Namespace default B| Namespace default
first created wins
otherwise first alphabetically | Gateway default A | HTTPRoute default A| +|Gateway default B| Gateway default B| Gateway default B| Gateway default
first created wins
otherwise first alphabetically | HTTPRoute default A| +|HTTPRoute default B| HTTPRoute default B| HTTPRoute default B| HTTPRoute default B| HTTPRoute default
first created wins
otherwise first alphabetically| + + +Now, if the HTTPRoute _does_ specify a RetryPolicy, +it's a bit easier, because we can basically disregard all defaults: + +#### Overrides interacting with defaults for RetryOnPolicy, value in HTTPRoute + +||None|Namespace override|Gateway override|HTTPRoute override| +|----|-----|-----|----|----| +|No default| Value in HTTPRoute|Namespace override| Gateway override | HTTPRoute override| +|Namespace default| Value in HTTPRoute| Namespace override | Gateway override | HTTPRoute override | +|Gateway default| Value in HTTPRoute | Namespace override | Gateway override | HTTPRoute override | +|HTTPRoute default| Value in HTTPRoute | Namespace override | Gateway override | HTTPRoute override| + +#### Overrides interacting with other overrides for RetryOnPolicy, value in HTTPRoute +||No override|Namespace override A|Gateway override A|HTTPRoute override A| +|----|-----|-----|----|----| +|No override|Value in HTTPRoute|Namespace override A| Gateway override A| HTTPRoute override A| +|Namespace override B| Namespace override B| Namespace override
first created wins
otherwise first alphabetically | Namespace override B| Namespace override B| +|Gateway override B| Gateway override B| Namespace override A| Gateway override
first created wins
otherwise first alphabetically | Gateway override B| +|HTTPRoute override B| HTTPRoute override B | Namespace override A| Gateway override A| HTTPRoute override
first created wins
otherwise first alphabetically| + +#### Defaults interacting with other defaults for RetryOnPolicy, value in HTTPRoute +||No default|Namespace default A|Gateway default A|HTTPRoute default A| +|----|-----|-----|----|----| +|No default|Value in HTTPRoute|Value in HTTPRoute|Value in HTTPRoute|Value in HTTPRoute| +|Namespace default B|Value in HTTPRoute|Value in HTTPRoute|Value in HTTPRoute|Value in HTTPRoute| +|Gateway default B|Value in HTTPRoute|Value in HTTPRoute|Value in HTTPRoute|Value in HTTPRoute| +|HTTPRoute default B|Value in HTTPRoute|Value in HTTPRoute|Value in HTTPRoute|Value in HTTPRoute| + + +## User discoverability and status + +### Standard label on CRD objects + +Each CRD that defines an Inherited Policy object MUST include a label that specifies +that it is a Policy object, and that label MUST specify that the object is an +`inherited` one. + +The label is `gateway.networking.k8s.io/policy: inherited`. + +This solution is intended to allow both users and tooling to identify which CRDs +in the cluster should be treated as Policy objects, and so is intended to help +with discoverability generally. It will also be used by the forthcoming `kubectl` +plugin. + +### Conditions + +Implementations using Policy objects MUST include a `spec` and `status` stanza, +and the `status` stanza MUST contain a `conditions` stanza, using the standard +Condition format. + +Policy authors should consider namespacing the `conditions` stanza with a +`controllerName`, as in Route status, if more than one implementation will be +reconciling the Policy type. + +#### On `Policy` objects + +Each Inherited Policy MUST populate the `Accepted` condition and reasons +as defined in the Go spec, a snapshot of which is included below. The canonical +representation is in the actual Go files. (At the time of writing, this is in +`apis/v1alpha2/policy_types.go`) + +This allows the responsible controller to indicate that the Policy has been +accepted for processing. + +```go +// PolicyConditionType is a type of condition for a policy. +type PolicyConditionType string + +// PolicyConditionReason is a reason for a policy condition. +type PolicyConditionReason string + +const ( + // PolicyConditionAccepted indicates whether the policy has been accepted or rejected + // by a targeted resource, and why. + // + // Possible reasons for this condition to be True are: + // + // * "Accepted" + // + // Possible reasons for this condition to be False are: + // + // * "Conflicted" + // * "Invalid" + // * "TargetNotFound" + // + PolicyConditionAccepted PolicyConditionType = "Accepted" + + // PolicyReasonAccepted is used with the "Accepted" condition when the policy has been + // accepted by the targeted resource. + PolicyReasonAccepted PolicyConditionReason = "Accepted" + + // PolicyReasonConflicted is used with the "Accepted" condition when the policy has not + // been accepted by a targeted resource because there is another policy that targets the same + // resource and a merge is not possible. + PolicyReasonConflicted PolicyConditionReason = "Conflicted" + + // PolicyReasonInvalid is used with the "Accepted" condition when the policy is syntactically + // or semantically invalid. + PolicyReasonInvalid PolicyConditionReason = "Invalid" + + // PolicyReasonTargetNotFound is used with the "Accepted" condition when the policy is attached to + // an invalid target resource + PolicyReasonTargetNotFound PolicyConditionReason = "TargetNotFound" +) +``` +#### On targeted resources + +Implementations that use Inherited Policy objects SHOULD put a Condition into +`status.Conditions` of any objects affected by a Inherited Policy, if that field +is present. + +If they do, that Condition MUST have a `type` ending in `PolicyAffected` (like +`gateway.networking.k8s.io/PolicyAffected`), +and have the optional `observedGeneration` field kept up to date when the `spec` +of the Policy-attached object changes. + +Implementations SHOULD use their own unique domain prefix for this Condition +`type` - it is recommended that implementations use the same domain as in the +`controllerName` field on GatewayClass (or some other implementation-unique +domain for implementations that do not use GatewayClass). + +For objects that do _not_ have a `status.Conditions` field available (`Secret` +is a good example), that object SHOULD instead have a label of +`gateway.networking.k8s.io/PolicyAffected: true` (or with an +implementation-specific domain prefix) added instead. + +Because these Conditions or labels are namespaced per-implementation, +implementations SHOULD: + +- Add the Condition or label if an object is policy affected when it is not + already present +- Remove the Condition or label when the last policy object stops referencing + the targeted object. + +The intent here is to give _some_ feedback that the object is affected by a Policy, +even if the details are difficult to communicate. + +#### Further status design + +Further status design for Inherited Policy is required, but needs to solve the +complexity and fanout problems listed above. Further design is therefore currently +up for discussion. + +Community members are encouraged to submit updates to this GEP with further patterns. diff --git a/site-src/ko/geps/gep-2649/metadata.yaml b/site-src/ko/geps/gep-2649/metadata.yaml new file mode 100644 index 0000000000..403a0c72ec --- /dev/null +++ b/site-src/ko/geps/gep-2649/metadata.yaml @@ -0,0 +1,21 @@ +apiVersion: internal.gateway.networking.k8s.io/v1alpha1 +kind: GEPDetails +number: 2649 +name: Inherited Policy Attachment +status: Provisional +authors: + - youngnick + - robscott +relationships: + extends: + - name: Metaresources and Policy Attachment + number: 713 + description: Split out Inherited Policy Attachment +# references is a list of hyperlinks to relevant external references. +# It's intended to be used for storing GitHub discussions, Google docs, etc. +references: + - "https://github.com/kubernetes-sigs/gateway-api/discussions/2927" +# changelog is a list of hyperlinks to PRs that make changes to the GEP, in +# ascending date order. +changelog: + - "https://github.com/kubernetes-sigs/gateway-api/pull/2813" diff --git a/site-src/ko/geps/gep-2659/index.md b/site-src/ko/geps/gep-2659/index.md new file mode 100644 index 0000000000..00cabd8e2a --- /dev/null +++ b/site-src/ko/geps/gep-2659/index.md @@ -0,0 +1,165 @@ +# GEP-2659: Document and improve the GEP process + +* Issue: [#2659](https://github.com/kubernetes-sigs/gateway-api/issues/2659) +* Type: Memorandum +* Status: Accepted + +(See [status definitions](../overview.md#gep-states).) + +## TLDR + +This GEP clarifies some details about GEPs, and adds relationships and a new +status. + + +## Goals + +- Enumerate how we should use RFC2119 language +- Add relationships between GEPs +- Add a metadata YAML schema for GEPs, including the new relationships +- Add a new status to cover some only recently noticed cases +- Update existing documentation outside this GEP to support the new material + +## Introduction + +As part of preparing for work to split up GEP-713, we (the Gateway API and GAMMA +maintainers) have noticed a few shortcomings in our GEP process. + +In particular, we have some GEPs that are very different to other GEPs. +[GEP-1324](../gep-1324/index.md) is a good example, +as it lays out the general agreement and use cases for the GAMMA initiative, but +has no firm deliverables of its own. In fact, its main purpose was to ensure +that the community was in agreement on the language around and scope of the +problem of representing Mesh config using Gateway API primitives. Essentially, +it lays out a shared understanding of the problem space, as a basis for further +work (in the form of subsequent GEPs). However, our current GEP system of checklists +for graduating levels fits this type of GEP poorly. + +Additionally, we've had two GEPs moved to Declined ([GEP-735: TCP and UDP address +matching](../gep-735/index.md) and +[GEP-1282: Describing Backend Properties](../gep-1282/index.md)). +In the case of GEP-1282, we now have a replacement GEP, +[GEP-1897: BackendTLSPolicy](../gep-1897/index.md) +which obsoletes the older GEP. But we have no way of representing this +relationship (or any other, in fact) between GEPs at the moment. + +With these previous two changes, the addition of a metadata YAML file, similar +to what the KEP process uses, seems like it is increasingly necessary. This GEP +introduces a schema, which will be detailed in `.go` files rather than completely +in this document. + +Lastly, we should clarify our use of [RFC2119](https://www.rfc-editor.org/rfc/rfc2119.txt) +language - we use MUST, SHOULD, MAY and so on as per that RFC in general, +but there is an extension in [RFC8174](https://www.rfc-editor.org/rfc/rfc8174.txt) +that adds that these words are only to be interpreted per the RFC when they are +in ALL CAPS, and "must" "should", "may" are to be interpreted in their usual +English meaning (which is not as strong as the RFC2119 one). This seems like +a _very_ good idea to adopt to me. + +## Proposals + +### Adopt the RFC8174 modification to RFC2119 language + +RFC8174 clarifies that the reserved words MUST be in all-caps to have their +assigned meaning. This should make the spec clearer over time as we migrate. + +### Addition of a new GEP status + +We will introduce a new GEP status, `Memorandum`, that marks a GEP as recording +an agreement on either the definition of a problem, its scope +and a common language, or further process changes to the GEP process itself. + +The defining characteristic here is that the GEP MUST NOT result in any changes +to the Gateway API spec, and MAY result in further GEPs to further clarify. +For GEPs that _do_ make changes to the API, but also require further GEPs to +clarify, they SHOULD use the new "Extended By" relationship instead. + +Memorandum GEPs should be used sparingly, and should form the umbrella for a +significant amount of work, particularly work that may have parts that can +move through the GEP phases at different speeds. + +The status is reached when a Memorandum GEP is merged, although as we will document +in the "Addition of GEP relationships" section, it can still be Extended +or Obsoleted. + +Existing GEPs that meet this criteria will be gradually moved to be proper +Memorandum GEPs after this GEP is merged. + +### Addition of YAML metadata file + +The core Gateway API maintainers were hoping not to need metadata YAMLs for a +while, but the addition of relationships has turbocharged the need for machine +parseable GEP metadata. + +This should also help with building display for GEPs; theoretically we can build +tooling that will let people slice the list of GEPs by whatever dimensions +we (or they) wish. + +Similarly to the `ConformanceReport` object, I'm proposing to make CRD definitions +for this `GEPDetails` object, which will not be included in the usual CRD +definitions for Gateway API, nor will it be part of the regular API spec. + +The use of a CRD is just to make the schema more similar to the other schemas +in this repository. + +With that said, here's a rough sample of what a GEPMetadata object will look like: + +```yaml +apiVersion: internal.gateway.networking.k8s.io/v1alpha1 +kind: GEPDetails +number: 2659 +name: Document and improve the GEP process +status: Memorandum +authors: + - youngnick +relationships: + # obsoletes indicates that a GEP makes the linked GEP obsolete, and completely + # replaces that GEP. The obsoleted GEP MUST have its obsoletedBy field + # set back to this GEP, and MUST be moved to Declined. + obsoletes: {} + obsoletedBy: {} + # extends indicates that a GEP extends the linked GEP, adding more detail + # or additional implementation. The extended GEP MUST have its extendedBy + # field set back to this GEP. + extends: {} + extendedBy: {} + # seeAlso indicates other GEPs that are relevant in some way without being + # covered by an existing relationship. + seeAlso: {} +# references is a list of hyperlinks to relevant external references. +# It's intended to be used for storing GitHub discussions, Google docs, etc. +references: {} +# featureNames is a list of the feature names introduced by the GEP, if there +# are any. This will allow us to track which feature was introduced by which GEP. +featureNames: {} +# changelog is a list of hyperlinks to PRs that make changes to the GEP, in +# ascending date order. +changelog: + - "https://github.com/kubernetes-sigs/gateway-api/pull/2689" +``` + +### Addition of GEP relationships + +As you can see in the previous section, this GEP adds three relationships between +GEPs: +- `Obsoletes` and its backreference `ObsoletedBy` - when a GEP is made obsolete + by another GEP, and has its functionality completely replaced. +- `Extends` and its backreference `ExtendedBy` - when a GEP has additional details + or implementation added in another GEP. +- `SeeAlso` - when a GEP is relevant to another GEP, but is not affected in any + other defined way. + +Each stanza in `relationships` includes a `number`, `name`, and a optional free-form +`description` field, which can be used to better describe the relationship. + +At this time it's the updater's responsibility to ensure that both directions +are created for bidirectional relationships. + +Further relationships may be added at a later date (at which time that GEP will +have an `Extends` relationship to this one). + +Because of the addition of structured definitions for these relationships, the +relationships will _not_ be recorded in the main GEP file (it's anticipated +that the metadata will eventually be rendered in table form in the canonical +display on the website for general consumption, and PRs will need to create or +update a YAML file for each GEP change). diff --git a/site-src/ko/geps/gep-2659/metadata.yaml b/site-src/ko/geps/gep-2659/metadata.yaml new file mode 100644 index 0000000000..e98ec3f7a2 --- /dev/null +++ b/site-src/ko/geps/gep-2659/metadata.yaml @@ -0,0 +1,21 @@ +apiVersion: internal.gateway.networking.k8s.io/v1alpha1 +kind: GEPDetails +number: 2659 +name: Document and improve the GEP process +type: Memorandum +status: Accepted +relationships: + seeAlso: + - number: 917 + name: Gateway API Conformance Testing + description: GEP is Memorandum type + - number: 922 + name: Gateway API Versioning + description: GEP is Memorandum type + - number: 1324 + name: Service Mesh in Gateway API + description: GEP is Memorandum type +authors: + - youngnick +changelog: + - "https://github.com/kubernetes-sigs/gateway-api/pull/2689" diff --git a/site-src/ko/geps/gep-2722/index.md b/site-src/ko/geps/gep-2722/index.md new file mode 100644 index 0000000000..135e2c7670 --- /dev/null +++ b/site-src/ko/geps/gep-2722/index.md @@ -0,0 +1,642 @@ +# GEP-2722: Goals and UX for gwctl + +* Issue: [#2722](https://github.com/kubernetes-sigs/gateway-api/issues/2722) +* Status: Memorandum + +## TLDR + +TLDR: This GEP proposes `gwctl`, a new command line tool designed to streamline + the experience of working with Gateway API resources. It offers a familiar + kubectl-like interface for viewing resources while providing more detailed and + informative output that is specifically focused on the Gateway API. For + advanced filtering and other in-depth features, `gwctl` can be effectively + used alongside `kubectl`. + +## Motivations + +* Limited kubectl customizability for CRDs: + * kubectl's customization capabilities for CRDs (through + `additionalPrinterColumns`) is constrained, limiting the ability to create + optimal views for Gateway API resources. +* Complex policy attachment management: + * As described in [GEP-713](../gep-713/index.md), + policies present a valuable mechanism for expanding the capabilities of + Gateway API resources. However, discoverability poses a challenge due to + the absence of a clear connection between resources and their associated + policies. There have been growing questions around suitability of policies + as a means to provide extensions. +* Challenging multi-resource model navigation: + * Comprehending the relationships between multiple Gateway API resources can + be challenging within kubectl. + +## Goals + +* Greater control over output formatting and presentation: + * Offer greater control over output formatting and presentation, enhancing + visibility and understanding of Gateway API resources. +* Improved policy discoverability, increasing adoption and usability: + * Make policies easily discoverable, aiding in the adoption and fostering + broader acceptance of policies as an extension mechanism. +* Simplified multi-resource model navigation: + * Facilitate navigation of the multi-resource model by making connections + between Gateway API resources explicit, aiding in configuration, + troubleshooting, and issue identification. +* Proactive error detection and reporting: + * Leverage native understanding of resource relationships to proactively + detect and report on potential configuration errors, further simplifying + issue identification and resolution. This would complement the ability of + users to readily pinpoint configuration problems themselves. +* Provide incentive for policy implementations that are consistent across cloud + providers: + * Encourage the adoption of consistent policy implementations across + different Gateway API providers, promoting interoperability and + predictability. + +## Commands Specification + +### Milestone 1 + +#### Supported Commands: + +* **get**: Retrieves information about specified resources without including + additional information from related resources. +* **describe**: Provides detailed information about specified resources, + including augmented information from related resources. + +#### Supported Resources: + +* gatewayclass +* gateways +* httproutes +* namespaces +* backends (not a native k8s resource) +* policycrds (not a native k8s resource) +* policies (not a native k8s resource) + +#### Filtering Options: + +* `-n` **Namespace**: Filters resources by namespace. Applicable to all + resources except cluster-scoped resources. +* `-l` **Labels**: Filters resources by labels. Applicable to all resources. +* `-A` **All Namespaces**: Fetches resources across all namespaces (redundant + for cluster-scoped resources). +* `-t` **Target Resource**: Filters policies based on the target resource type + they apply to. Applicable only to the policies resource. + * Syntax: `-t
+
+
+
+
+
+#### Additional Notes:
+
+* The behavior of `get` and `describe` commands is similar to kubectl, with
+ `get` focusing on concise resource information and `describe` providing
+ comprehensive details.
+* `backends` represent resources that can be attached as backends to HTTPRoutes
+ (currently limited to k8s services).
+* `policycrds` and `policies` are not native k8s resources but represent subsets
+ of CRDs and custom resource objects related to policies. (`policycrds` are
+ identified by
+ [PolicyLabelKey](https://github.com/kubernetes-sigs/gateway-api/blob/5658635bce70f3a52b6936ad5a99249a4f5116ad/apis/v1alpha2/policy_types.go#L31C2-L31C16))
+
+#### Examples of commands that should be supported:
+
+* `gwctl get gateways -n foo` (Lists basic information about Gateways in the
+ "foo" namespace)
+* `gwctl get httproutes -l version=v1,app=myapp` (Lists basic information about
+ HTTPRoutes with the labels "version=v1" and "app=myapp")
+* `gwctl get gateways -n foo -o yaml` (Shows detailed Gateway information in
+ YAML format within the "foo" namespace)
+* `gwctl get httproutes -l version=v1,app=myapp -o json` (Shows detailed
+ HTTPRoute information in JSON format with specified labels)
+* `gwctl describe gateways my-gateway` (Provides comprehensive details about the
+ "my-gateway" Gateway, including information from related resources)
+* `gwctl describe policies my-policy` (Shows detailed information about the
+ "my-policy" policy, encompassing data from relevant any related resources when
+ applicable)
+* `gwctl get policies -t kind=httproute` (Lists basic information about policies that apply to HTTPRoutes)
+
+#### Distribution
+To ensure gwctl is widely accessible and easy to adopt, the following
+distribution mechanisms will be provided:
+
+* **Prebuilt Binaries:** Prebuilt binaries for various platforms (Linux, macOS,
+ Windows) will be made available for download. Tooling like
+ [GoReleaser](https://goreleaser.com/) can be used to streamline some of the
+ build processes. Binaries will be offered in two variants:
+ * `gwctl` for standalone use.
+ * `kubectl-gw` for use as a kubectl plugin (`kubectl gw`).
+* **Kubectl Plugin Integration:** gwctl will be integrated with
+ [Krew](https://github.com/kubernetes-sigs/krew), the kubectl plugin manager.
+ This should immensely help with improving discoverability of the plugin,
+ allowing easier installation, and handling automatic updates for the user.
+* **Versioning:** gwctl versions will be aligned with Gateway API releases (for
+ the time when gwctl is developed within the same repository as Gateway API)
+ * As gwctl matures, the need for maintaining it within the primary Gateway API
+ repository will be reassessed. Factors such as a potential divergence in
+ release cadence, independent contributor growth or the desire to reduce the
+ triage workload for Gateway API maintainers could motivate a move to a
+ separate repository.
+
+### Future Milestones
+* Each output of `describe` will include an extra `Analysis` field. This field
+ will display any errors or other analysis information associated with the
+ resource.
+* Investigate the feasibility and any advantages of using Graphviz or webview
+ for visualizing data and presenting information in a visually appealing
+ manner.
+* Evaluate how gwctl can be extended to support [Mesh use
+ cases](/concepts/gamma/#how-the-gateway-api-works-for-service-mesh)
+
+## References
+
+* [GEP-713: Metaresources and Policy
+ Attachment](../gep-713/index.md)
+
+## Sample outputs
+
+The example outputs provided below serve as a guideline for the implementation,
+outlining the range of values that may be presented:
+
+* `gwctl get gatewayclass -o wide`
+ ```
+ NAME CONTROLLER ACCEPTED AGE DESCRIPTION Gateways
+ bar-com-internal-gateway-class bar.baz/internal-gateway-class True 100d Internal Load Balancer 10
+ foo-com-external-gateway-class foo.com/external-gateway-class True 365d External Load Balancer 25
+ ```
+
+* `gwctl get gateway -o wide`
+ ```
+ NAME CLASS ADDRESSES PORTS PROGRAMMED AGE POLICIES HTTPROUTES
+ demo-gateway-2 external-class 10.0.0.1 80 True 20d 10 5
+ abc-gateway-12345 internal-class 192.168.100.5 443,8080 False 5d 2 1
+ random-gateway regional-internal-class 10.11.12.13 8443 Unknown 3s 3 5
+ ```
+
+* `gwctl get httproute -o wide`
+ ```
+ NAMESPACE NAME HOSTNAMES PARENT REFS AGE POLICIES
+ default foo-httproute-1 example.com,example2.com + 1 more ns2/demo-gateway-2 5m 2
+ default qmn-httproute-100 example.com demo-gateway-1 5m 1
+ ns1 bar-route-21 foo.com,bar.com + 5 more default/demo-gateway-200 5m 3
+ ns2 bax-httproute-18777 None ns1/demo-gateway-345 5m 4
+ ```
+
+* `gwctl get namespace -o wide`
+ ```
+ NAME STATUS AGE POLICIES
+ default Active 46d 3
+ kube-system Active 46d 5
+ ```
+
+* `gwctl get backend -o wide`
+ ```
+ NAME TYPE REFERRED BY ROUTES AGE POLICIES
+ foo-svc Service foo-httproute-1,abc-httproute-33 + 4 more 45m 5
+ bar-baz-svc Service bar-httproute 11d 1
+ ```
+
+* `gwctl get policycrds -o wide`
+ ```
+ NAME POLICY TYPE SCOPE POLICIES COUNT AGE
+ healthcheckpolicies.foo.com Direct Namespaced 1 5d
+ retryonpolicies.foo.com Direct Namespaced 2 4d
+ timeoutpolicies.bar.com Inherited Cluster 1 10m
+ tlsminimumversionpolicies.baz.com Direct Namespaced 3 45s
+ ```
+
+* `gwctl get policies -o wide`
+ ```
+ NAME KIND TARGET NAME TARGET KIND POLICY TYPE AGE
+ demo-timeout-policy-on-gatewayclass TimeoutPolicy.foo.com foo-com-external-gateway-class GatewayClass Inherited 10d
+ demo-timeout-policy-on-namespace TimeoutPolicy.foo.com default Namespace Inherited 10d
+ demo-health-check-1 HealthCheckPolicy.bar.com demo-gateway-1 Gateway Direct 10d
+ demo-retry-policy-1 RetryOnPolicy.baz.com demo-gateway-1 Gateway Direct 10d
+ demo-retry-policy-2 RetryOnPolicy.baz.com demo-httproute-2 HTTPRoute Direct 10d
+ demo-tls-min-version-policy-1 TLSMinimumVersionPolicy.foobar.com demo-gateway-3 Gateway Direct 10d
+ demo-tls-min-version-policy-2 TLSMinimumVersionPolicy.foobar.com demo-gateway-4 Gateway Direct 10d
+ ```
+
+* `gwctl describe gateway demo-gateway`
+ ```
+ Name: demo-gateway
+ Namespace: default
+ Labels: Output columns while using get
+| Resource | +Output Columns | +Description | +Visibility (Defaults to always unless specified otherwise) | +
|---|---|---|---|
| gatewayclass | +NAME | +Name of the GatewayClass | ++ |
| CONTROLLER | +Controller managing the GatewayClass | ++ | |
| ACCEPTED | +Whether the GatewayClass is accepted by the controller | ++ | |
| AGE | +Age of the GatewayClass | ++ | |
| GATEWAYS | +Count of Gateways using this GatewayClass | +-o wide | +|
| DESCRIPTION | +Description from the GatewayClass | +-o wide | +|
| gateway | +NAME | +Name of the Gateway | ++ |
| CLASS | +Class of the Gateway | ++ | |
| ADDRESSES | +Addresses of the Gateway (displayed using |
+ + | |
| PORTS | +Ports exposed by the Gateway | ++ | |
| PROGRAMMED | +Whether the Gateway is programmed | ++ | |
| AGE | +Age of the Gateway | ++ | |
| POLICIES | +Count of policies affecting this Gateway | +-o wide | +|
| HTTPROUTES | +Count of HTTPRoutes that are attached to this Gateway | +-o wide | +|
| httproute | +NAMESPACE | +Namespace of the HTTPRoute | ++ |
| NAME | +Name of the HTTPRoute | ++ | |
| HOSTNAMES | +Hostnames associated with the HTTPRoute | ++ | |
| PARENT REFS | +Count of parent references of the HTTPRoute (e.g., Gateways) | ++ | |
| AGE | +Age of the HTTPRoute | ++ | |
| POLICIES | +Count of policies affecting this HTTPRoute | +-o wide | +|
| namespace | +NAME | +Name of the namespace | ++ |
| STATUS | +Status of the namespace | ++ | |
| AGE | +Age of the namespace | ++ | |
| POLICIES | +Count of policies affecting this Namespace | +-o wide | +|
| backend | +NAME | +Name of the backend | ++ |
| TYPE | +Type of the backend (currently only supports Services) | ++ | |
| REFERRED BY ROUTES | +HTTPRoutes that refer to the backend (displayed using |
+ + | |
| AGE | +Age of the backend | ++ | |
| POLICIES | +Count of policies affecting this Backend | +-o wide | +|
| policycrd | +NAME | +Name of the Policy CRD in the form <kind.group> | ++ |
| POLICY TYPE | +Type of policy defined by the CRD (Inherited or Direct) | ++ | |
| SCOPE | +Scope of the policy (Namespaced or Cluster) | ++ | |
| POLICIES COUNT | +Count of policy resources of this particular type. | +-o wide | +|
| AGE | +Age of the Policy CRD | ++ | |
| policy | +NAME | +Name of the policy | ++ |
| KIND | +The kind of policy in the form <kind.group> + | ++ | |
| TARGET NAME | +Name of the resource the policy applies to | ++ | |
| TARGET KIND | +The kind of target resource in the form | ++ | |
| POLICY TYPE | +Type of policy (Inherited or Direct) | ++ | |
| AGE | +Age of the Policy CRD | ++ |
+
+```mermaid
+flowchart TD
+ D([Discuss with
the community]) --> C + C([Issue Created]) -------> Memorandum + C([Issue Created]) --> Provisional + Provisional -->|If practical
work needed| Prototyping + Provisional -->|GEP Doc PR
done| Implementable + Prototyping -->|GEP Doc PR
done| Implementable + Implementable -->|Gateway API
work completed| Experimental + Experimental -->|Supported in
multiple implementations
+ Conformance tests| Standard + Standard -->|Entire change is GA or implemented| Completed + +``` + +
+
+## GEP Definitions
+
+### GEP States
+
+Each GEP has a state, which tracks where it is in the GEP process.
+
+GEPs can move to some states from any other state:
+
+ * **Deferred:** We do not currently have bandwidth to handle this GEP, it
+ may be revisited in the future.
+ * **Declined:** This proposal was considered by the community but ultimately
+ rejected and further work will not occur.
+ * **Withdrawn:** This proposal was considered by the community but ultimately
+ withdrawn by the author.
+
+There is a special state to cover Memorandum GEPs:
+
+ * **Memorandum**: These GEPs either:
+ * Document an agreement for further work, creating no spec changes themselves, or
+ * Update the GEP process.
+
+API GEPs flow through a number of states, which generally correspond to the level
+of stability of the change described in the GEP:
+
+ * **Provisional:** The goals described by this GEP have consensus but
+ implementation details have not been agreed to yet.
+ * **Prototyping:** An optional extension of `Provisional` in
+ order to indicate to the community that there are some active practical tests
+ and experiments going on which are intended to be a part of the development
+ of this GEP. This may include APIs or code, but that content _must_ not be
+ distributed with releases.
+ * **Implementable:** The goals and implementation details described by this GEP
+ have consensus but have not been fully implemented yet.
+ * **Experimental:** This GEP has been implemented and is part of the
+ "Experimental" release channel. Breaking changes are still possible, up to
+ and including complete removal and moving to `Rejected`.
+ * **Standard:** This GEP has been implemented and is part of the
+ "Standard" release channel. It should be quite stable.
+ * **Completed**: All implementation work on this API GEP has been completed.
+
+### Relationships between GEPs
+
+GEPs can have relationships between them. At this time, there are three possible
+relationships:
+
+* **Obsoletes** and its backreference **ObsoletedBy**: when a GEP is made obsolete
+ by another GEP, and has its functionality completely replaced. The Obsoleted
+ GEP is moved to the **Declined** state.
+* **Extends** and its backreference **ExtendedBy**: when a GEP has additional details
+ or implementation added in another GEP.
+* **SeeAlso**: when a GEP is relevant to another GEP, but is not affected in any
+ other defined way.
+
+Relationships are tracked in the YAML metadata files accompanying each GEP.
+
+### GEP metadata file
+
+Each GEP has a YAML file containing metadata alongside it, please keep it up to
+date as changes to the GEP occur.
+
+In particular, note the `authors`, and `changelog` fields, please keep those up
+to date.
+
+## Process
+
+### 1. Discuss with the community
+
+Before creating a GEP, share your high level idea with the community. There are
+several places this may be done:
+
+- A [new GitHub Discussion](https://github.com/kubernetes-sigs/gateway-api/discussions/new)
+- On our [Slack Channel](https://kubernetes.slack.com/archives/CR0H13KGA)
+- On one of our [community meetings](../contributing/index.md?h=meetings#meetings)
+
+Please default to GitHub discussions: they work a lot like GitHub issues which
+makes them easy to search.
+
+### 2. Create an Issue
+[Create a GEP issue](https://github.com/kubernetes-sigs/gateway-api/issues/new?assignees=&labels=kind%2Ffeature&template=enhancement.md) in the repo describing your change.
+At this point, you should copy the outcome of any other conversations or documents
+into this document.
+
+### 3. Agree on the Goals
+Although it can be tempting to start writing out all the details of your
+proposal, it's important to first ensure we all agree on the goals.
+
+For API GEPs, the first version of your GEP should aim for a "Provisional"
+status and leave out any implementation details, focusing primarily on
+"Goals" and "Non-Goals".
+
+For Memorandum GEPs, the first version of your GEP will be the only one, as
+Memorandums have only a single stage - `Accepted`.
+
+### 3. Document Implementation Details
+Now that everyone agrees on the goals, it is time to start writing out your
+proposed implementation details. These implementation details should be very
+thorough, including the proposed API spec, and covering any relevant edge cases.
+Note that it may be helpful to use a shared doc for part of this phase to enable
+faster iteration on potential designs.
+
+It is likely that throughout this process, you will discuss a variety of
+alternatives. Be sure to document all of these in the GEP, and why we decided
+against them. At this stage, the GEP should be targeting the "Implementable"
+stage.
+
+### 4. Implement the GEP as "Experimental"
+
+With the GEP marked as "Implementable", it is time to actually make those
+proposed changes in our API. In some cases, these changes will be documentation
+only, but in most cases, some API changes will also be required. It is important
+that every new feature of the API is marked as "Experimental" when it is
+introduced. Within the API, we use `the community]) --> C + C([Issue Created]) -------> Memorandum + C([Issue Created]) --> Provisional + Provisional -->|If practical
work needed| Prototyping + Provisional -->|GEP Doc PR
done| Implementable + Prototyping -->|GEP Doc PR
done| Implementable + Implementable -->|Gateway API
work completed| Experimental + Experimental -->|Supported in
multiple implementations
+ Conformance tests| Standard + Standard -->|Entire change is GA or implemented| Completed + +``` + +
+
+이 API의 대부분의 설정은 라우팅 레이어에 포함되어 있다.
+이러한 프로토콜별 리소스
+([HTTPRoute](api-types/httproute.md), [GRPCRoute](api-types/grpcroute.md) 등)는
+인그레스와 메시 모두에 대해 고급 라우팅 기능을 제공한다.
+
+게이트웨이 API 로고는 API의 이중 목적을 시각적으로 설명하며,
+북/남 (인그레스) 및 동/서 (메시) 트래픽이
+동일한 구성 설정을 공유하며 라우팅을 가능하게 한다.
+
+
+
+## 인그레스를 위한 게이트웨이 API
+
+??? success "v0.5.0 부터 표준 채널"
+
+ 게이트웨이, 게이트웨이클래스, HTTPRoute는 v0.5.0부터 게이트웨이
+ API의 표준 채널에 포함되었으며 안정적인 API로 간주된다.
+ 자세한 내용은 [버전 관리 가이드](concepts/versioning.md)를 참조하자.
+
+게이트웨이 API를 사용하여 인그레스 트래픽을 관리할 때,
+[게이트웨이](api-types/gateway.md) 리소스는 트래픽이
+여러 컨텍스트를 거쳐 라우팅될 수 있는 접근 지점을 정의한다.
+예를 들어, 클러스터 외부에서 내부로의 ([북/남 트래픽])이 있다.
+
+각 게이트웨이는 [게이트웨이클래스](api-types/gatewayclass.md)와 연결되며,
+이는 게이트웨이의 트래픽을 처리할 [게이트웨이 컨트롤러]의 실제 타입을 설명한다.
+개별 라우팅 리소스(예: [HTTPRoute](api-types/httproute.md))는
+[게이트웨이 리소스와 연결된다][게이트웨이 리소스 연결].
+이러한 서로 다른 관심사를 별도의 리소스로 분리하는 것은
+게이트웨이 API의 역할 지향적 특성의 핵심 부분이며,
+동일한 클러스터 내에서
+여러 타입의 게이트웨이 컨트롤러(게이트웨이클래스 리소스로 표현)와
+각각의 여러 인스턴스(게이트웨이 리소스로 표현)를 허용한다.
+
+[인그레스 API]:https://kubernetes.io/ko/docs/concepts/services-networking/ingress/
+[북/남 트래픽]:concepts/glossary.md#northsouth-traffic
+[동/서 트래픽]:concepts/glossary.md#eastwest-traffic
+[게이트웨이 컨트롤러]:concepts/glossary.md#gateway-controller
+[게이트웨이 리소스 연결]:concepts/api-overview.md#attaching-routes-to-gateways
+
+## 서비스 메시를 위한 게이트웨이 API ([GAMMA initiative](mesh/gamma.md))
+
+??? success "v1.1.0 부터 표준 채널"
+
+ 서비스 메시 사용 사례를 지원하기 위한 [GAMMA 이니셔티브](mesh/gamma.md)
+ 작업은 v1.1.0부터 표준 채널에 포함되었으며 GA로 간주된다.
+ 자세한 내용은 [버전 관리 가이드](concepts/versioning.md)를 참조하자.
+
+게이트웨이 API를 사용하여 [서비스 메시][서비스-메시]를 관리할 때는 상황이 약간 다르다.
+클러스터 내에서 일반적으로 하나의 메시만 활성화되므로
+[게이트웨이](api-types/gateway.md)와 [게이트웨이클래스](api-types/gatewayclass.md) 리소스는
+사용되지 않는다.
+대신, 개별 라우팅 리소스(예: [HTTPRoute](api-types/httproute.md))는
+[서비스 리소스와 직접 연결][메시-연결]되며, 이를 통해 메시가 해당 서비스로 향하는
+모든 트래픽을 관리하면서
+게이트웨이 API의 역할 지향적 특성을 유지한다.
+
+현재까지 [GAMMA](mesh/index.md)는 게이트웨이 API에
+최소한의 변경만으로 메시 기능을 지원해왔다.
+하지만 GAMMA에서 특히 빠르게 중요해진 영역은
+[서비스 리소스의 다양한 측면][서비스-측면] 정의이다.
+
+[gamma]:mesh/index.md
+[서비스-메시]:concepts/glossary.md#service-mesh
+[서비스-측면]:mesh/service-facets.md
+[메시-연결]:mesh/index.md
+
+## 시작하기
+
+게이트웨이 API 사용에 관심 있는 사용자든,
+API 준수를 원하는 구현자든,
+아래의 리소스는 필요한 배경 정보를 제공한다.
+
+- [API 개요](concepts/api-overview.md)
+- [사용자 가이드](guides/index.md)
+- [구현](implementations.md)
+- [API 참조 사양](reference/spec.md)
+- [커뮤니티 링크](contributing/index.md)와 [개발자 가이드](contributing/devguide.md)
+
+## 게이트웨이 API 개념
+이어지는 설계 목표는 게이트웨이 API의 개념을 이끌어낸다.
+이는 게이트웨이가 인그레스와 같은 현재 표준을 어떻게 개선하려는지 보여준다.
+
+- **역할-지향적** - 게이트웨이는 쿠버네티스 서비스 네트워킹을 사용하고 설정하는 조직적 역할을
+모델링하는 API 리소스로 구성되어 있다.
+- **이식성** - 이는 개선이라기보다는 유지해야 할 특성이다.
+인그레스가
+[수많은 구현](https://kubernetes.io/ko/docs/concepts/services-networking/ingress-controllers/)을 가진 보편적 사양인 것처럼,
+게이트웨이 API는 다양한 구현을 지원하는
+이식 가능한 사양으로 설계되었다.
+- **표현력** - 게이트웨이 API 리소스는
+헤더 기반 매칭, 트래픽 가중치 설정 등
+인그레스에서는 사용자 정의 주석을 통해서만 가능했던 핵심 기능을 지원한다.
+- **확장 가능** - 게이트웨이 API는 API의 다양한 계층에서
+사용자 정의 리소스를 연결할 수 있도록 한다.
+이를 통해 API 구조 내 적절한 위치에서 세분화된 사용자 정의가 가능하다.
+
+기타 주목할 만한 기능은 다음과 같다.
+
+- **게이트웨이클래스** - 게이트웨이클래스는 부하 분산 구현의 타입을 공식화한다.
+이러한 클래스는 사용자가 쿠버네티스 리소스 모델을 통해
+어떤 기능이 사용 가능한지
+명확하고 쉽게 이해할 수 있도록 한다.
+- **공유 게이트웨이와 네임스페이스 간 지원** - 독립적인 라우트 리소스가
+동일한 게이트웨이에 연결될 수 있도록 하여 로드 밸런서와 VIPs를 공유한다.
+이를 통해 팀(심지어 네임스페이스를 넘어) 간
+직접적인 조정 없이 안전하게 인프라를 공유할 수 있다.
+- **타입화된 라우트 및 백엔드** - 게이트웨이 API는
+타입화된 라우트 리소스와 다양한 백엔드 타입을 지원한다.
+이를 통해 API는 (HTTP, gRPC와 같이) 다양한 프로토콜과
+(쿠버네티스 서비스, 스토리지 버킷, 함수와 같은) 다양한 백엔드 타겟을
+지원하는 데 유연성을 갖는다.
+- 실험적 **서비스 메시 지원** ([GAMMA 이니셔티브][gamma]) -
+게이트웨이 API는 라우팅 리소스를 서비스 리소스와 연결하여
+인그레스 컨트롤러뿐만 아니라 서비스 메시를 구성할 수 있도록 지원한다.
+
+## 왜 역할 지향적 API가 중요한가?
+
+도로, 전력, 데이터 센터, 쿠버네티스 클러스터 등 인프라는 공유를 목적으로 구축된다.
+하지만 공유 인프라는 공통적인 도전 과제를 제시한다.
+즉, 인프라 사용자에게 유연성을 제공하면서
+인프라 소유자의 통제력을 어떻게 유지할 것인가?
+
+게이트웨이 API는 쿠버네티스 서비스 네트워킹을 위한 역할 지향적 설계를 통해
+분산된 유연성과 중앙 집중식 통제 간의 균형을 이룬다.
+이를 통해 공유 네트워크 인프라(하드웨어 부하 분산기, 클라우드 네트워킹, 클러스터 호스팅 프록시 등)를
+클러스터 운영자가 설정한 정책과 제약에 따라
+서로 협력하지 않는 다양한 팀이 사용할 수
+있다.
+
+게이트웨이 API의 설계에 사용되는 역할은 세 가지 페르소나로 정의된다.
+
+### 페르소나
+
+- **Ian** (그/그의)은 인프라 제공자이다.
+ 그의 역할은 여러 개별 클러스터가 다수의 테넌트를 제공할 수 있도록 인프라를 관리하고 유지하는 것이다.
+ 그는 단일 테넌트에 얽매이지 않고,
+ 모든 테넌트를 집합적으로 고려한다.
+
+- **Chihiro** (그들/그들의)은 >클러스터 운영자이다.
+ 그들의 역할은 단일 클러스터를 관리하여 여러 사용자의 요구를 충족하도록 하는 것이다.
+ Chihiro는 클러스터의 단일 사용자에게 얽매이지 않으며,
+ 클러스터가 모든 사용자를 필요에 따라 지원하도록 해야 한다.
+
+- **Ana** (그녀/그녀의)은 애플리케이션 개발자이다.
+ Ana는 게이트웨이 API 역할 중 유일한 위치에 있다.
+ 그녀의 초점은 애플리케이션이 제공해야 하는 비즈니스 요구에 있으며,
+ 쿠버네티스나 게이트웨이 API 자체가 아니다.
+ 실제로, Ana는 게이트웨이 API와 쿠버네티스를 일을 완수하는 데 방해가 되는 순수한 마찰로 볼 가능성이 높다.
+
+(이 세 가지에 대한 자세한 내용은 [역할과 페르소나](concepts/roles-and-personas.md)에서
+자세히 설명한다).
+
+Ana, Chihiro, Ian이 모든 점에서 의견이 일치하지는 않지만,
+원활한 운영을 위해 협력해야 한다는 점은 분명하다.
+한마디로 이것이 게이트웨이 API의 핵심 과제이다.
+
+### 사용 사례
+
+[예제 사용 사례][사용-사례]는 역할-지향적 모델이 작동하는 모습을 보여준다.
+이 모델의 유연성은 API가 매우 다른 조직 모델과 구현에 적응하면서도
+이식 가능하고 표준적인 API로 남을 수 있게 한다.
+
+제시된 사용 사례는 위에서 소개한 역할들을 기준으로 의도적으로 구성되었다.
+궁극적으로 게이트웨이 API는 인간이 사용하도록 설계되었으며,
+이는 Ana, Chihiro, Ian 각각이 API를 사용하는 목적에 맞아야 함을 의미한다.
+
+[사용-사례]:concepts/use-cases.md
+
+## 게이트웨이 API와 API 게이트웨이의 차이점은 무엇인가?
+
+[API 게이트웨이](https://glossary.cncf.io/api-gateway/)는
+고유한 애플리케이션 API를 집계하여 한 곳에서 모두 사용 가능하게 만드는 도구이다.
+이를 통해 조직은 인증, 권한 부여, 애플리케이션 간 요청 수 제한과 같은 핵심 기능을
+중앙에서 관리할 수 있다.
+API 게이트웨이는 (종종 외부) API 소비자를 위한 공통 인터페이스로 기능한다.
+
+게이트웨이 API는 쿠버네티스에서 서비스 네트워킹을 모델링하는 일련의 쿠버네티스 리소스로 정의된
+인터페이스이다.
+주요 리소스 중 하나는 `게이트웨이`로, 인스턴스화할 게이트웨이 타입(또는 클래스)과 그 설정을 선언한다.
+게이트웨이 제공자로서 게이트웨이 API를 구현하여
+쿠버네티스 서비스 네트워킹을 표현력 있고 확장 가능하며 역할 지향적인 방식으로 모델링할 수 있다.
+
+일부 API 게이트웨이는 게이트웨이 API를 사용하여 프로그래밍할 수 있다.
+
+## 누가 게이트웨이 API를 개발하고 있는가?
+
+게이트웨이 API는
+쿠버네티스에서 서비스 네트워킹을 개선하고 표준화하기 위해
+[SIG-네트워크](https://github.com/kubernetes/community/tree/master/sig-network)
+프로젝트로 개발되고 있다.
+최신 게이트웨이를 지원하는 프로젝트 및 제품은 [구현 참조](implementations.md)에서 확인할 수 있다.
+게이트웨이 API를 사용해 기여하거나 구현을 구축하는 데 관심이 있다면 주저하지 말고
+[참여하라!](/contributing/index.md)
+
+[sig-네트워크]: https://github.com/kubernetes/community/tree/master/sig-network
+
diff --git a/site-src/ko/js/implementations.js b/site-src/ko/js/implementations.js
new file mode 100644
index 0000000000..26be6d972d
--- /dev/null
+++ b/site-src/ko/js/implementations.js
@@ -0,0 +1,8 @@
+document$.subscribe(function() {
+ var tables = document.querySelectorAll("article table:not([class])")
+ tables.forEach(function(table) {
+ new Tablesort(table)
+ })
+})
+
+
diff --git a/site-src/ko/mesh/gamma.md b/site-src/ko/mesh/gamma.md
new file mode 100644
index 0000000000..b482dde790
--- /dev/null
+++ b/site-src/ko/mesh/gamma.md
@@ -0,0 +1,48 @@
+# GAMMA 이니셔티브 (서비스 메시를 위한 게이트웨이 API)
+
+게이트웨이 API는 원래 클러스터 외부의 클라이언트에서 클러스터 내부의 서비스로의 트래픽을 관리하도록 설계되었다.
+-- 즉, _인그레스_ 또는 [_북/남_][north/south traffic] 케이스 --.
+하지만 시간이 지나면서 [서비스 메시] 사용자들의 관심에 따라
+2022년에 GAMMA(**G**ateway **A**PI for **M**esh **M**anagement and **A**dministration) 이니셔티브가 만들어졌다.
+이는 게이트웨이 API가 동일한 클러스터 내에서 서비스 간 또는
+[_동/서_ 트래픽][east/west traffic]에도 사용될 수 있는 방법을
+정의하기 위함이었다.
+
+GAMMA 이니셔티브는 별도의 서브프로젝트가 아닌 게이트웨이 API 서브프로젝트 내의 전용 워크스트림으로,
+[GAMMA 리드]가 관리한다.
+GAMMA의 목표는 게이트웨이 API에 최소한의 변경만을 가하면서
+서비스 메시를 구성하는 데 게이트웨이 API를 사용할 수 있는 방법을 정의하는 것이며,
+항상 게이트웨이 API의 [역할 지향적] 특성을 보존한다.
+또한 기술 스택이나 프록시에 관계없이 서비스 메시 프로젝트들의 게이트웨이 API 구현 간 일관성을 옹호하기 위해
+노력한다.
+
+## 결과물
+
+GAMMA 이니셔티브의 작업은 메시 및 메시 관련 사용 사례를 다루기 위해 게이트웨이 API 명세를 확장하거나 개선하는
+[게이트웨이 개선 제안서][geps]에 포함된다.
+현재까지 이러한 변경사항들은 비교적 작았지만(때로는 상대적으로 큰 영향을 미치지만!),
+앞으로도 그럴 것으로 예상한다.
+게이트웨이 API 명세의 거버넌스는 게이트웨이 API 서브프로젝트의 메인테이너들에게만 남아
+있다.
+
+GAMMA 이니셔티브의 이상적인 최종 결과는
+서비스 메시 사용 사례가 게이트웨이 API의 일급 관심사가 되는 것이며,
+이 시점에는 더 이상 별도의 이니셔티브가 필요하지 않을 것이다.
+
+## 기여
+
+모든 수준의 기여자를 환영한다!
+게이트웨이 API와 GAMMA에 [기여할 수 있는 다양한 방법][contributor-ladder]이 있으며
+이는 기술적인 것과 비기술적인 것 모두를 포함한다.
+
+시작하는 가장 간단한 방법은 정기적으로 열리는 게이트웨이 API [회의] 중 하나에
+참석하는 것이다.
+
+[north/south traffic]:../concepts/glossary.md#northsouth-traffic
+[서비스 메시]:../concepts/glossary.md#service-mesh
+[east/west traffic]:../concepts/glossary.md#eastwest-traffic
+[역할 지향적]:../concepts/roles-and-personas.md
+[geps]:../geps/overview.md
+[contributor-ladder]:../contributing/contributor-ladder.md
+[회의]:../contributing/index.md/#meetings
+[GAMMA 리드]:https://github.com/kubernetes-sigs/gateway-api/blob/main/OWNERS_ALIASES#L23
diff --git a/site-src/ko/mesh/index.md b/site-src/ko/mesh/index.md
new file mode 100644
index 0000000000..3d95227042
--- /dev/null
+++ b/site-src/ko/mesh/index.md
@@ -0,0 +1,162 @@
+
+# 서비스 메시를 위한 게이트웨이 API
+
+??? success "v1.1.0부터 표준 채널"
+
+ 서비스 메시 사용 사례를 지원하기 위한 [GAMMA 이니셔티브](gamma.md) 작업은
+ v1.1.0부터 표준 채널에 포함되었으며 GA로 간주된다.
+ 자세한 정보는 [버전 관리 가이드](../concepts/versioning.md)를 참조하라.
+
+"[GAMMA 이니셔티브](gamma.md)"는 게이트웨이 API가 서비스 메시에서
+어떻게 사용될 수 있는지를 정의하는 그룹을 의미한다.
+현재까지 이 그룹은 비교적 작은 변경사항으로 게이트웨이 API에서 서비스 메시 지원을 정의할 수 있었다.
+GAMMA가 현재까지 도입한 가장 중요한 변경사항은 서비스 메시를 구성할 때
+개별 라우트 리소스([HTTPRoute] 등)가 [서비스 리소스와 직접 연결](#gateway-api-for-mesh)된다는
+것이다.
+
+이는 주로 클러스터에서 일반적으로 하나의 메시만 활성화되므로
+메시 작업 시 [게이트웨이]와 [게이트웨이 클래스] 리소스가 사용되지 않기 때문이다.
+결과적으로 서비스 리소스가 라우팅 정보를 위한 가장 범용적인 바인딩 지점으로 남게
+된다.
+
+서비스 리소스는 불행히도 복잡하며 여러 오버로드되거나 명세가 부족한 측면이 있기 때문에,
+GAMMA는 [서비스 _프론트엔드_ 와 _백엔드_ 측면][service-facets]을 공식적으로 정의하는 것이 중요하다고 판단했다.
+간단히 말하면,
+
+- 서비스 프론트엔드는 그 이름과 클러스터 IP이고,
+- 서비스 백엔드는 엔드포인트 IP들의 집합이다.
+
+이러한 구분은 게이트웨이 API가 서비스를 크게 복제하는 새로운 리소스를 요구하지 않으면서도
+메시 내에서 라우팅이 어떻게 작동하는지 정확하게 설명하는 데
+도움이 된다.
+
+[게이트웨이 클래스]: ../api-types/gatewayclass.md
+[게이트웨이]: ../api-types/gateway.md
+[HTTPRoute]: ../api-types/httproute.md
+[TCPRoute]: ../concepts/api-overview.md#tcproute-and-udproute
+[Service]: https://kubernetes.io/docs/concepts/services-networking/service/
+[service-mesh]:../concepts/glossary.md#service-mesh
+[service-facets]:service-facets.md
+
+## 라우트와 서비스 연결
+
+GAMMA는 개별 라우트 리소스가 서비스에 직접 연결되어
+_해당 서비스로 향하는 모든 트래픽에 적용될 구성_ 을
+나타낸다고 명시한다.
+
+하나 이상의 라우트가 서비스에 연결되면
+**최소 하나 이상의 라우트와 일치하지 않는 요청은 거부된다**.
+라우트가 서비스에 연결되지 않은 경우,
+해당 서비스에 대한 요청은 단순히 메시의 기본 동작에 따라 진행된다
+(일반적으로 메시가 없는 것처럼 요청이 전달됨).
+
+주어진 서비스에 어떤 라우트가 연결되는지는
+라우트 자체에서 제어한다(쿠버네티스 RBAC와 함께 작동).
+라우트는 게이트웨이가 아닌 서비스를 지정하는 `parentRef`를 단순히 명시한다.
+
+```yaml
+kind: HTTPRoute
+metadata:
+ name: smiley-route
+ namespace: faces
+spec:
+ parentRefs:
+ - name: smiley
+ kind: Service
+ group: core
+ port: 80
+ rules:
+ ...
+```
+
+!!! note "진행 중인 작업"
+
+ 프로듀서 라우트와 컨슈머 라우트 간의 관계에 대한 작업이
+ 진행 중이다.
+
+라우트의 네임스페이스와 서비스의 네임스페이스 간의 관계가
+중요하다.
+
+- 동일한 네임스페이스
+
+ 서비스와 동일한 네임스페이스에 있는 라우트를 [프로듀서 라우트]라고 하는데,
+ 이는 일반적으로 워크로드의 생성자가 워크로드의 허용 가능한 사용을 정의하기 위해생성하기 때문이다
+ (예를 들어, [Ana]가 워크로드와 라우트를 모두 배포하는 경우).
+ 모든 네임스페이스의 워크로드 클라이언트로부터의 모든 요청이
+ 이 라우트의 영향을 받는다.
+
+ 위에 표시된 라우트는 프로듀서 라우트이다.
+
+- 다른 네임스페이스
+
+ 서비스와 다른 네임스페이스에 있는 라우트를 [컨슈머 라우트]라고 한다.
+ 일반적으로 이는 주어진 워크로드의 소비자가 해당 워크로드에 대한 요청 방식을 개선하기 위한 라우트이다
+ (예를 들어, 해당 소비자의 워크로드 사용에 대한 사용자 정의 타임아웃 구성).
+ 이 라우트는 라우트와 동일한 네임스페이스의 워크로드로부터의 요청에만
+ 영향을 준다.
+
+ 예를 들어, 아래의 HTTPRoute는 `fast-clients` 네임스페이스에 있는 `smiley` 워크로드의 모든 클라이언트가
+ 100ms 타임아웃을 갖도록 한다.
+
+ ```yaml
+ kind: HTTPRoute
+ metadata:
+ name: smiley-route
+ namespace: fast-clients
+ spec:
+ parentRefs:
+ - name: smiley
+ namespace: faces
+ kind: Service
+ group: core
+ port: 80
+ rules:
+ ...
+ timeouts:
+ request: 100ms
+ ```
+
+서비스에 바인딩된 라우트에 대해 중요한 참고 사항은
+단일 네임스페이스 내에서 동일한 서비스에 대한 여러 라우트(프로듀서 라우트든 컨슈머 라우트든)가
+게이트웨이 API [라우트 병합 규칙]에 따라 결합된다는 것이다.
+따라서 현재 동일한 네임스페이스 내의 여러 소비자에 대해 구별되는 컨슈머 라우트를 정의하는 것은
+불가능하다.
+
+예를 들어, `blender` 워크로드와 `mixer` 워크로드가 모두 `foodprep` 네임스페이스에 있고,
+둘 다 동일한 서비스를 사용하여 `oven` 워크로드를 호출하는 경우,
+현재 `blender`와 `mixer`가 HTTPRoute를 사용하여 `oven` 워크로드 호출에 대해
+서로 다른 타임아웃을 설정하는 것은 불가능하다.
+이를 허용하려면 `blender`와 `mixer`를 별도의 네임스페이스로 이동해야 한다.
+
+[Ana]:../concepts/roles-and-personas.md#ana
+[프로듀서 라우트]:../concepts/glossary.md#producer-route
+[컨슈머 라우트]:../concepts/glossary.md#consumer-route
+[서비스 메시]:../concepts/glossary.md#service-mesh
+[라우트 병합 규칙]:../api-types/httproute.md#merging
+
+## 요청 흐름
+
+GAMMA 호환 메시가 사용될 때 일반적인 [동/서] API 요청 흐름은 다음과
+같다.
+
+1. 클라이언트 워크로드가
+ {% if config.extra.trademark %}
+
diff --git a/site-src/ko/overrides/partials/header.html b/site-src/ko/overrides/partials/header.html
new file mode 100644
index 0000000000..07b787a4dc
--- /dev/null
+++ b/site-src/ko/overrides/partials/header.html
@@ -0,0 +1,117 @@
+
+
+
+{% set class = "md-header" %}
+{% if "navigation.tabs.sticky" in features %}
+ {% set class = class ~ " md-header--shadow md-header--lifted" %}
+{% elif "navigation.tabs" not in features %}
+ {% set class = class ~ " md-header--shadow" %}
+{% endif %}
+
+
++ The Linux Foundation has registered trademarks and uses trademarks. For a list of trademarks of The Linux Foundation, + please see our Trademark Usage page. +
+ {% endif %} + {% if not config.extra.generator == false %} + Made with + + Material for MkDocs + + {% endif %} +addresses must be in dotted-decimal form. IPv6 addresses
must be in a standard IPv6 text representation
(see [RFC 5952](https://tools.ietf.org/html/rfc5952)).
This type is intended for specific addresses. Address ranges are not
supported (e.g. you cannot use a CIDR range like 127.0.0.0/24 as an
IPAddress).
Support: Extended
| +| `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
| +| `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.
The `NamedAddress` type has been deprecated in favor of implementation
specific domain-prefixed strings.
Support: Implementation-specific
| + + +#### AllowedListeners + + + +AllowedListeners defines which ListenerSets can be attached to this Gateway. + + + +_Appears in:_ +- [GatewaySpec](#gatewayspec) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `namespaces` _[ListenerNamespaces](#listenernamespaces)_ | Namespaces defines which namespaces ListenerSets can be attached to this Gateway.
While this feature is experimental, the default value is to allow no ListenerSets. | \{ from:None \} | | + + +#### AllowedRoutes + + + +AllowedRoutes defines which Routes may be attached to this Listener. + + + +_Appears in:_ +- [Listener](#listener) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `namespaces` _[RouteNamespaces](#routenamespaces)_ | 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 | \{ from:Same \} | | +| `kinds` _[RouteGroupKind](#routegroupkind) array_ | 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
"InvalidRouteKinds" reason.
Support: Core | | MaxItems: 8
| + + +#### AnnotationKey + +_Underlying type:_ _string_ + +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. - cannot start or end with "." + +_Validation:_ +- MaxLength: 253 +- MinLength: 1 +- Pattern: `^([a-z0-9]([-a-z0-9]*[a-z0-9])?(\\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*/)?([A-Za-z0-9][-A-Za-z0-9_.]{0,61})?[A-Za-z0-9]$` + +_Appears in:_ +- [BackendTLSPolicySpec](#backendtlspolicyspec) +- [GatewayInfrastructure](#gatewayinfrastructure) +- [GatewayTLSConfig](#gatewaytlsconfig) + + + +#### AnnotationValue + +_Underlying type:_ _string_ + +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. + +_Validation:_ +- MaxLength: 4096 +- MinLength: 0 + +_Appears in:_ +- [BackendTLSPolicySpec](#backendtlspolicyspec) +- [GatewayInfrastructure](#gatewayinfrastructure) +- [GatewayTLSConfig](#gatewaytlsconfig) + + + +#### BackendObjectReference + + + +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 different than the local namespace is specified, a +ReferenceGrant object is required in the referent namespace to allow that +namespace's owner to accept the reference. See the ReferenceGrant +documentation for details. + +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. + + + +_Appears in:_ +- [BackendRef](#backendref) +- [GRPCBackendRef](#grpcbackendref) +- [HTTPBackendRef](#httpbackendref) +- [HTTPRequestMirrorFilter](#httprequestmirrorfilter) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `group` _[Group](#group)_ | Group is the group of the referent. For example, "gateway.networking.k8s.io".
When unspecified or empty string, core API group is inferred. | | MaxLength: 253
Pattern: `^$\|^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$`
| +| `kind` _[Kind](#kind)_ | Kind is the Kubernetes resource kind of the referent. For example
"Service".
Defaults to "Service" when not specified.
ExternalName services can refer to CNAME DNS records that may live
outside of the cluster and as such are difficult to reason about in
terms of conformance. They also may not be safe to forward to (see
CVE-2021-25740 for more information). Implementations SHOULD NOT
support ExternalName Services.
Support: Core (Services with a type other than ExternalName)
Support: Implementation-specific (Services with type ExternalName) | Service | MaxLength: 63
MinLength: 1
Pattern: `^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$`
| +| `name` _[ObjectName](#objectname)_ | Name is the name of the referent. | | MaxLength: 253
MinLength: 1
| +| `namespace` _[Namespace](#namespace)_ | Namespace is the namespace of the backend. When unspecified, the local
namespace is inferred.
Note that when a namespace different than the local namespace is specified,
a ReferenceGrant object is required in the referent namespace to allow that
namespace's owner to accept the reference. See the ReferenceGrant
documentation for details.
Support: Core | | MaxLength: 63
MinLength: 1
Pattern: `^[a-z0-9]([-a-z0-9]*[a-z0-9])?$`
| +| `port` _[PortNumber](#portnumber)_ | Port specifies the destination port number to use for this resource.
Port is required when the referent is a Kubernetes Service. In this
case, the port number is the service port number, not the target port.
For other resources, destination port might be derived from the referent
resource or this field. | | Maximum: 65535
Minimum: 1
| + + +#### BackendRef + + + +BackendRef defines how a Route should forward a request to a Kubernetes +resource. + +Note that when a namespace different than the local namespace is specified, a +ReferenceGrant object is required in the referent namespace to allow that +namespace's owner to accept the reference. See the ReferenceGrant +documentation for details. + +
When unspecified or empty string, core API group is inferred. | | MaxLength: 253
Pattern: `^$\|^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$`
| +| `kind` _[Kind](#kind)_ | Kind is the Kubernetes resource kind of the referent. For example
"Service".
Defaults to "Service" when not specified.
ExternalName services can refer to CNAME DNS records that may live
outside of the cluster and as such are difficult to reason about in
terms of conformance. They also may not be safe to forward to (see
CVE-2021-25740 for more information). Implementations SHOULD NOT
support ExternalName Services.
Support: Core (Services with a type other than ExternalName)
Support: Implementation-specific (Services with type ExternalName) | Service | MaxLength: 63
MinLength: 1
Pattern: `^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$`
| +| `name` _[ObjectName](#objectname)_ | Name is the name of the referent. | | MaxLength: 253
MinLength: 1
| +| `namespace` _[Namespace](#namespace)_ | Namespace is the namespace of the backend. When unspecified, the local
namespace is inferred.
Note that when a namespace different than the local namespace is specified,
a ReferenceGrant object is required in the referent namespace to allow that
namespace's owner to accept the reference. See the ReferenceGrant
documentation for details.
Support: Core | | MaxLength: 63
MinLength: 1
Pattern: `^[a-z0-9]([-a-z0-9]*[a-z0-9])?$`
| +| `port` _[PortNumber](#portnumber)_ | Port specifies the destination port number to use for this resource.
Port is required when the referent is a Kubernetes Service. In this
case, the port number is the service port number, not the target port.
For other resources, destination port might be derived from the referent
resource or this field. | | Maximum: 65535
Minimum: 1
| +| `weight` _integer_ | 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. | 1 | Maximum: 1e+06
Minimum: 0
| + + +#### CommonRouteSpec + + + +CommonRouteSpec defines the common attributes that all Routes MUST include +within their spec. + + + +_Appears in:_ +- [GRPCRouteSpec](#grpcroutespec) +- [HTTPRouteSpec](#httproutespec) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `parentRefs` _[ParentReference](#parentreference) array_ | 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. For Services, that means the Service must either be in the same
namespace for a "producer" route, or the mesh implementation must support
and allow "consumer" routes for the referenced Service. ReferenceGrant is
not applicable for governing ParentRefs to Services - it is not possible to
create a "producer" route for a Service in a different namespace from the
Route.
There are two kinds of parent resources with "Core" support:
* Gateway (Gateway conformance profile)
* Service (Mesh conformance profile, ClusterIP Services only)
This API may be extended in the future to support additional kinds of parent
resources.
ParentRefs must be _distinct_. This means either that:
* They select different objects. If this is the case, then parentRef
entries are distinct. In terms of fields, this means that the
multi-part key defined by `group`, `kind`, `namespace`, and `name` must
be unique across all parentRef entries in the Route.
* They do not select different objects, but for each optional field used,
each ParentRef that selects the same object must set the same set of
optional fields to different values. If one ParentRef sets a
combination of optional fields, all must set the same combination.
Some examples:
* If one ParentRef sets `sectionName`, all ParentRefs referencing the
same object must also set `sectionName`.
* If one ParentRef sets `port`, all ParentRefs referencing the same
object must also set `port`.
* If one ParentRef sets `sectionName` and `port`, all ParentRefs
referencing the same object must also set `sectionName` and `port`.
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.
Note that for ParentRefs that cross namespace boundaries, there are specific
rules. Cross-namespace references are only valid if they are explicitly
allowed by something in the namespace they are referring to. For example,
Gateway has the AllowedRoutes field, and ReferenceGrant provides a
generic way to enable other kinds of cross-namespace reference.
ParentRefs from a Route to a Service in the same namespace are "producer"
routes, which apply default routing rules to inbound connections from
any namespace to the Service.
ParentRefs from a Route to a Service in a different namespace are
"consumer" routes, and these routing rules are only applied to outbound
connections originating from the same namespace as the Route, for which
the intended destination of the connections are a Service targeted as a
ParentRef of the Route.
| + + +#### CookieConfig + + + +CookieConfig defines the configuration for cookie-based session persistence. + + + +_Appears in:_ +- [SessionPersistence](#sessionpersistence) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `lifetimeType` _[CookieLifetimeType](#cookielifetimetype)_ | LifetimeType specifies whether the cookie has a permanent or
session-based lifetime. A permanent cookie persists until its
specified expiry time, defined by the Expires or Max-Age cookie
attributes, while a session cookie is deleted when the current
session ends.
When set to "Permanent", AbsoluteTimeout indicates the
cookie's lifetime via the Expires or Max-Age cookie attributes
and is required.
When set to "Session", AbsoluteTimeout indicates the
absolute lifetime of the cookie tracked by the gateway and
is optional.
Defaults to "Session".
Support: Core for "Session" type
Support: Extended for "Permanent" type | Session | Enum: [Permanent Session]
| + + +#### CookieLifetimeType + +_Underlying type:_ _string_ + + + +_Validation:_ +- Enum: [Permanent Session] + +_Appears in:_ +- [CookieConfig](#cookieconfig) + +| Field | Description | +| --- | --- | +| `Session` | SessionCookieLifetimeType specifies the type for a session
cookie.
Support: Core
| +| `Permanent` | PermanentCookieLifetimeType specifies the type for a permanent
cookie.
Support: Extended
| + + +#### Duration + +_Underlying type:_ _string_ + +Duration is a string value representing a duration in time. The format is as specified +in GEP-2257, a strict subset of the syntax parsed by Golang time.ParseDuration. + +_Validation:_ +- Pattern: `^([0-9]{1,5}(h|m|s|ms)){1,4}$` + +_Appears in:_ +- [HTTPRouteRetry](#httprouteretry) +- [HTTPRouteTimeouts](#httproutetimeouts) +- [SessionPersistence](#sessionpersistence) + + + +#### FeatureName + +_Underlying type:_ _string_ + +FeatureName is used to describe distinct features that are covered by +conformance tests. + + + +_Appears in:_ +- [SupportedFeature](#supportedfeature) + + + +#### Fraction + + + + + + + +_Appears in:_ +- [HTTPRequestMirrorFilter](#httprequestmirrorfilter) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `numerator` _integer_ | | | Minimum: 0
| +| `denominator` _integer_ | | 100 | Minimum: 1
| + + +#### FromNamespaces + +_Underlying type:_ _string_ + +FromNamespaces specifies namespace from which Routes/ListenerSets may be attached to a +Gateway. + + + +_Appears in:_ +- [ListenerNamespaces](#listenernamespaces) +- [RouteNamespaces](#routenamespaces) + +| Field | Description | +| --- | --- | +| `All` | Routes/ListenerSets in all namespaces may be attached to this Gateway.
| +| `Selector` | Only Routes/ListenerSets in namespaces selected by the selector may be attached to
this Gateway.
| +| `Same` | Only Routes/ListenerSets in the same namespace as the Gateway may be attached to this
Gateway.
| +| `None` | No Routes/ListenerSets may be attached to this Gateway.
| + + +#### FrontendTLSValidation + + + +FrontendTLSValidation holds configuration information that can be used to validate +the frontend initiating the TLS connection + + + +_Appears in:_ +- [GatewayTLSConfig](#gatewaytlsconfig) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `caCertificateRefs` _[ObjectReference](#objectreference) array_ | CACertificateRefs contains one or more references to
Kubernetes objects that contain TLS certificates of
the Certificate Authorities that can be used
as a trust anchor to validate the certificates presented by the client.
A single CA certificate reference to a Kubernetes ConfigMap
has "Core" support.
Implementations MAY choose to support attaching multiple CA certificates to
a Listener, but this behavior is implementation-specific.
Support: Core - A single reference to a Kubernetes ConfigMap
with the CA certificate in a key named `ca.crt`.
Support: Implementation-specific (More than one reference, or other kinds
of resources).
References to a resource in a different namespace are invalid UNLESS there
is a ReferenceGrant in the target namespace that allows the certificate
to be attached. If a ReferenceGrant does not allow this reference, the
"ResolvedRefs" condition MUST be set to False for this listener with the
"RefNotPermitted" reason. | | MaxItems: 8
MinItems: 1
| + + +#### GRPCBackendRef + + + +GRPCBackendRef defines how a GRPCRoute forwards a gRPC request. + +Note that when a namespace different than the local namespace is specified, a +ReferenceGrant object is required in the referent namespace to allow that +namespace's owner to accept the reference. See the ReferenceGrant +documentation for details. + +
When unspecified or empty string, core API group is inferred. | | MaxLength: 253
Pattern: `^$\|^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$`
| +| `kind` _[Kind](#kind)_ | Kind is the Kubernetes resource kind of the referent. For example
"Service".
Defaults to "Service" when not specified.
ExternalName services can refer to CNAME DNS records that may live
outside of the cluster and as such are difficult to reason about in
terms of conformance. They also may not be safe to forward to (see
CVE-2021-25740 for more information). Implementations SHOULD NOT
support ExternalName Services.
Support: Core (Services with a type other than ExternalName)
Support: Implementation-specific (Services with type ExternalName) | Service | MaxLength: 63
MinLength: 1
Pattern: `^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$`
| +| `name` _[ObjectName](#objectname)_ | Name is the name of the referent. | | MaxLength: 253
MinLength: 1
| +| `namespace` _[Namespace](#namespace)_ | Namespace is the namespace of the backend. When unspecified, the local
namespace is inferred.
Note that when a namespace different than the local namespace is specified,
a ReferenceGrant object is required in the referent namespace to allow that
namespace's owner to accept the reference. See the ReferenceGrant
documentation for details.
Support: Core | | MaxLength: 63
MinLength: 1
Pattern: `^[a-z0-9]([-a-z0-9]*[a-z0-9])?$`
| +| `port` _[PortNumber](#portnumber)_ | Port specifies the destination port number to use for this resource.
Port is required when the referent is a Kubernetes Service. In this
case, the port number is the service port number, not the target port.
For other resources, destination port might be derived from the referent
resource or this field. | | Maximum: 65535
Minimum: 1
| +| `weight` _integer_ | 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. | 1 | Maximum: 1e+06
Minimum: 0
| +| `filters` _[GRPCRouteFilter](#grpcroutefilter) array_ | Filters defined at this level MUST be executed if and only if the
request is being forwarded to the backend defined here.
Support: Implementation-specific (For broader support of filters, use the
Filters field in GRPCRouteRule.) | | MaxItems: 16
| + + +#### GRPCHeaderMatch + + + +GRPCHeaderMatch describes how to select a gRPC route by matching gRPC request +headers. + + + +_Appears in:_ +- [GRPCRouteMatch](#grpcroutematch) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `type` _[GRPCHeaderMatchType](#grpcheadermatchtype)_ | Type specifies how to match against the value of the header. | Exact | Enum: [Exact RegularExpression]
| +| `name` _[GRPCHeaderName](#grpcheadername)_ | Name is the name of the gRPC Header to be matched.
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. | | MaxLength: 256
MinLength: 1
Pattern: `^[A-Za-z0-9!#$%&'*+\-.^_\x60\|~]+$`
| +| `value` _string_ | Value is the value of the gRPC Header to be matched. | | MaxLength: 4096
MinLength: 1
| + + +#### GRPCHeaderMatchType + +_Underlying type:_ _string_ + +GRPCHeaderMatchType specifies the semantics of how GRPC header values should +be compared. Valid GRPCHeaderMatchType values, along with their conformance +levels, are: + +* "Exact" - Core +* "RegularExpression" - Implementation Specific + +Note that new values may be added to this enum in future releases of the API, +implementations MUST ensure that unknown values will not cause a crash. + +Unknown values here MUST result in the implementation setting the Accepted +Condition for the Route to `status: False`, with a Reason of +`UnsupportedValue`. + +_Validation:_ +- Enum: [Exact RegularExpression] + +_Appears in:_ +- [GRPCHeaderMatch](#grpcheadermatch) + +| Field | Description | +| --- | --- | +| `Exact` | | +| `RegularExpression` | | + + +#### GRPCHeaderName + +_Underlying type:_ _[HeaderName](#headername)_ + + + +_Validation:_ +- MaxLength: 256 +- MinLength: 1 +- Pattern: `^[A-Za-z0-9!#$%&'*+\-.^_\x60|~]+$` + +_Appears in:_ +- [GRPCHeaderMatch](#grpcheadermatch) + + + +#### GRPCMethodMatch + + + +GRPCMethodMatch describes how to select a gRPC route by matching the gRPC +request service and/or method. + +At least one of Service and Method MUST be a non-empty string. + + + +_Appears in:_ +- [GRPCRouteMatch](#grpcroutematch) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `type` _[GRPCMethodMatchType](#grpcmethodmatchtype)_ | Type specifies how to match against the service and/or method.
Support: Core (Exact with service and method specified)
Support: Implementation-specific (Exact with method specified but no service specified)
Support: Implementation-specific (RegularExpression) | Exact | Enum: [Exact RegularExpression]
| +| `service` _string_ | Value of the service to match against. If left empty or omitted, will
match any service.
At least one of Service and Method MUST be a non-empty string. | | MaxLength: 1024
| +| `method` _string_ | Value of the method to match against. If left empty or omitted, will
match all services.
At least one of Service and Method MUST be a non-empty string. | | MaxLength: 1024
| + + +#### GRPCMethodMatchType + +_Underlying type:_ _string_ + +MethodMatchType specifies the semantics of how gRPC methods and services are compared. +Valid MethodMatchType values, along with their conformance levels, are: + +* "Exact" - Core +* "RegularExpression" - Implementation Specific + +Exact methods MUST be syntactically valid: + +- Must not contain `/` character + +_Validation:_ +- Enum: [Exact RegularExpression] + +_Appears in:_ +- [GRPCMethodMatch](#grpcmethodmatch) + +| Field | Description | +| --- | --- | +| `Exact` | Matches the method or service exactly and with case sensitivity.
| +| `RegularExpression` | Matches if the method or service matches the given regular expression with
case sensitivity.
Since `"RegularExpression"` has implementation-specific conformance,
implementations can support POSIX, PCRE, RE2 or any other regular expression
dialect.
Please read the implementation's documentation to determine the supported
dialect.
| + + +#### GRPCRoute + + + +GRPCRoute provides a way to route gRPC requests. This includes the capability +to match requests by hostname, gRPC service, gRPC method, or HTTP/2 header. +Filters can be used to specify additional processing steps. Backends specify +where matching requests will be routed. + +GRPCRoute falls under extended support within the Gateway API. Within the +following specification, the word "MUST" indicates that an implementation +supporting GRPCRoute must conform to the indicated requirement, but an +implementation not supporting this route type need not follow the requirement +unless explicitly indicated. + +Implementations supporting `GRPCRoute` with the `HTTPS` `ProtocolType` MUST +accept HTTP/2 connections without an initial upgrade from HTTP/1.1, i.e. via +ALPN. If the implementation does not support this, then it MUST set the +"Accepted" condition to "False" for the affected listener with a reason of +"UnsupportedProtocol". Implementations MAY also accept HTTP/2 connections +with an upgrade from HTTP/1. + +Implementations supporting `GRPCRoute` with the `HTTP` `ProtocolType` MUST +support HTTP/2 over cleartext TCP (h2c, +https://www.rfc-editor.org/rfc/rfc7540#section-3.1) without an initial +upgrade from HTTP/1.1, i.e. with prior knowledge +(https://www.rfc-editor.org/rfc/rfc7540#section-3.4). If the implementation +does not support this, then it MUST set the "Accepted" condition to "False" +for the affected listener with a reason of "UnsupportedProtocol". +Implementations MAY also accept HTTP/2 connections with an upgrade from +HTTP/1, i.e. without prior knowledge. + + + +_Appears in:_ +- [GRPCRoute](#grpcroute) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `apiVersion` _string_ | `gateway.networking.k8s.io/v1` | | | +| `kind` _string_ | `GRPCRoute` | | | +| `metadata` _[ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#objectmeta-v1-meta)_ | Refer to Kubernetes API documentation for fields of `metadata`. | | | +| `spec` _[GRPCRouteSpec](#grpcroutespec)_ | Spec defines the desired state of GRPCRoute. | | | +| `status` _[GRPCRouteStatus](#grpcroutestatus)_ | Status defines the current state of GRPCRoute. | | | + + +#### GRPCRouteFilter + + + +GRPCRouteFilter defines processing steps that must be completed during the +request or response lifecycle. GRPCRouteFilters 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. + + + +_Appears in:_ +- [GRPCBackendRef](#grpcbackendref) +- [GRPCRouteRule](#grpcrouterule) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `type` _[GRPCRouteFilterType](#grpcroutefiltertype)_ | 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 supporting GRPCRoute 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.
- Implementation-specific: 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` MUST 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.
| +| `requestHeaderModifier` _[HTTPHeaderFilter](#httpheaderfilter)_ | RequestHeaderModifier defines a schema for a filter that modifies request
headers.
Support: Core | | | +| `responseHeaderModifier` _[HTTPHeaderFilter](#httpheaderfilter)_ | ResponseHeaderModifier defines a schema for a filter that modifies response
headers.
Support: Extended | | | +| `requestMirror` _[HTTPRequestMirrorFilter](#httprequestmirrorfilter)_ | RequestMirror defines a schema for a filter that mirrors requests.
Requests are sent to the specified destination, but responses from
that destination are ignored.
This filter can be used multiple times within the same rule. Note that
not all implementations will be able to support mirroring to multiple
backends.
Support: Extended | | | +| `extensionRef` _[LocalObjectReference](#localobjectreference)_ | 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
This filter can be used multiple times within the same rule. | | | + + +#### GRPCRouteFilterType + +_Underlying type:_ _string_ + +GRPCRouteFilterType identifies a type of GRPCRoute filter. + + + +_Appears in:_ +- [GRPCRouteFilter](#grpcroutefilter) + +| Field | Description | +| --- | --- | +| `RequestHeaderModifier` | GRPCRouteFilterRequestHeaderModifier can be used to add or remove a gRPC
header from a gRPC request before it is sent to the upstream target.
Support in GRPCRouteRule: Core
Support in GRPCBackendRef: Extended
| +| `ResponseHeaderModifier` | GRPCRouteFilterRequestHeaderModifier can be used to add or remove a gRPC
header from a gRPC response before it is sent to the client.
Support in GRPCRouteRule: Core
Support in GRPCBackendRef: Extended
| +| `RequestMirror` | GRPCRouteFilterRequestMirror can be used to mirror gRPC requests to a
different backend. The responses from this backend MUST be ignored by
the Gateway.
Support in GRPCRouteRule: Extended
Support in GRPCBackendRef: Extended
| +| `ExtensionRef` | GRPCRouteFilterExtensionRef should be used for configuring custom
gRPC filters.
Support in GRPCRouteRule: Implementation-specific
Support in GRPCBackendRef: Implementation-specific
| + + +#### GRPCRouteMatch + + + +GRPCRouteMatch 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 gRPC request only if its service +is `foo` AND it contains the `version: v1` header: + +``` +matches: + - method: + type: Exact + service: "foo" + headers: + - name: "version" + value "v1" + +``` + + + +_Appears in:_ +- [GRPCRouteRule](#grpcrouterule) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `method` _[GRPCMethodMatch](#grpcmethodmatch)_ | Method specifies a gRPC request service/method matcher. If this field is
not specified, all services and methods will match. | | | +| `headers` _[GRPCHeaderMatch](#grpcheadermatch) array_ | Headers specifies gRPC request header matchers. Multiple match values are
ANDed together, meaning, a request MUST match all the specified headers
to select the route. | | MaxItems: 16
| + + +#### GRPCRouteRule + + + +GRPCRouteRule defines the semantics for matching a gRPC request based on +conditions (matches), processing it (filters), and forwarding the request to +an API object (backendRefs). + + + +_Appears in:_ +- [GRPCRouteSpec](#grpcroutespec) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `name` _[SectionName](#sectionname)_ | Name is the name of the route rule. This name MUST be unique within a Route if it is set.
Support: Extended
MinLength: 1
Pattern: `^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$`
| +| `matches` _[GRPCRouteMatch](#grpcroutematch) array_ | Matches define conditions used for matching the rule against incoming
gRPC 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:
- method:
service: foo.bar
headers:
values:
version: 2
- method:
service: foo.bar.v2
```
For a request to match against this rule, it MUST satisfy
EITHER of the two conditions:
- service of foo.bar AND contains the header `version: 2`
- service of foo.bar.v2
See the documentation for GRPCRouteMatch on how to specify multiple
match conditions to be ANDed together.
If no matches are specified, the implementation MUST match every gRPC request.
Proxy or Load Balancer routing configuration generated from GRPCRoutes
MUST prioritize rules based on the following criteria, continuing on
ties. Merging MUST not be done between GRPCRoutes and HTTPRoutes.
Precedence MUST be given to the rule with the largest number of:
* Characters in a matching non-wildcard hostname.
* Characters in a matching hostname.
* Characters in a matching service.
* Characters in a matching method.
* Header 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
"\{namespace\}/\{name\}".
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. | | MaxItems: 64
| +| `filters` _[GRPCRouteFilter](#grpcroutefilter) array_ | 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 that support
GRPCRoute.
- Implementers are encouraged to support extended filters.
- Implementation-specific custom filters have no API guarantees across
implementations.
Specifying the same filter multiple times is not supported unless explicitly
indicated in the filter.
If an implementation cannot support a combination of filters, it must clearly
document that limitation. In cases where incompatible or unsupported
filters are specified and cause the `Accepted` condition to be set to status
`False`, implementations may use the `IncompatibleFilters` reason to specify
this configuration error.
Support: Core | | MaxItems: 16
| +| `backendRefs` _[GRPCBackendRef](#grpcbackendref) array_ | BackendRefs defines the backend(s) where matching requests should be
sent.
Failure behavior here depends on how many BackendRefs are specified and
how many are invalid.
If *all* entries in BackendRefs are invalid, and there are also no filters
specified in this route rule, *all* traffic which matches this rule MUST
receive an `UNAVAILABLE` status.
See the GRPCBackendRef definition for the rules about what makes a single
GRPCBackendRef invalid.
When a GRPCBackendRef is invalid, `UNAVAILABLE` statuses MUST be returned for
requests that would have otherwise been routed to an invalid backend. If
multiple backends are specified, and some are invalid, the proportion of
requests that would otherwise have been routed to an invalid backend
MUST receive an `UNAVAILABLE` status.
For example, if two backends are specified with equal weights, and one is
invalid, 50 percent of traffic MUST receive an `UNAVAILABLE` status.
Implementations may choose how that 50 percent is determined.
Support: Core for Kubernetes Service
Support: Implementation-specific for any other resource
Support for weight: Core | | MaxItems: 16
| +| `sessionPersistence` _[SessionPersistence](#sessionpersistence)_ | SessionPersistence defines and configures session persistence
for the route rule.
Support: Extended
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. For Services, that means the Service must either be in the same
namespace for a "producer" route, or the mesh implementation must support
and allow "consumer" routes for the referenced Service. ReferenceGrant is
not applicable for governing ParentRefs to Services - it is not possible to
create a "producer" route for a Service in a different namespace from the
Route.
There are two kinds of parent resources with "Core" support:
* Gateway (Gateway conformance profile)
* Service (Mesh conformance profile, ClusterIP Services only)
This API may be extended in the future to support additional kinds of parent
resources.
ParentRefs must be _distinct_. This means either that:
* They select different objects. If this is the case, then parentRef
entries are distinct. In terms of fields, this means that the
multi-part key defined by `group`, `kind`, `namespace`, and `name` must
be unique across all parentRef entries in the Route.
* They do not select different objects, but for each optional field used,
each ParentRef that selects the same object must set the same set of
optional fields to different values. If one ParentRef sets a
combination of optional fields, all must set the same combination.
Some examples:
* If one ParentRef sets `sectionName`, all ParentRefs referencing the
same object must also set `sectionName`.
* If one ParentRef sets `port`, all ParentRefs referencing the same
object must also set `port`.
* If one ParentRef sets `sectionName` and `port`, all ParentRefs
referencing the same object must also set `sectionName` and `port`.
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.
Note that for ParentRefs that cross namespace boundaries, there are specific
rules. Cross-namespace references are only valid if they are explicitly
allowed by something in the namespace they are referring to. For example,
Gateway has the AllowedRoutes field, and ReferenceGrant provides a
generic way to enable other kinds of cross-namespace reference.
ParentRefs from a Route to a Service in the same namespace are "producer"
routes, which apply default routing rules to inbound connections from
any namespace to the Service.
ParentRefs from a Route to a Service in a different namespace are
"consumer" routes, and these routing rules are only applied to outbound
connections originating from the same namespace as the Route, for which
the intended destination of the connections are a Service targeted as a
ParentRef of the Route.
| +| `hostnames` _[Hostname](#hostname) array_ | Hostnames defines a set of hostnames to match against the GRPC
Host header to select a GRPCRoute to process the request. 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.
If a hostname is specified by both the Listener and GRPCRoute, there
MUST be at least one intersecting hostname for the GRPCRoute to be
attached to the Listener. For example:
* A Listener with `test.example.com` as the hostname matches GRPCRoutes
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 GRPCRoutes
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.
Hostnames that are prefixed with a wildcard label (`*.`) are interpreted
as a suffix match. That means that a match for `*.example.com` would match
both `test.example.com`, and `foo.test.example.com`, but not `example.com`.
If both the Listener and GRPCRoute have specified hostnames, any
GRPCRoute hostnames that do not match the Listener hostname MUST be
ignored. For example, if a Listener specified `*.example.com`, and the
GRPCRoute specified `test.example.com` and `test.example.net`,
`test.example.net` MUST NOT be considered for a match.
If both the Listener and GRPCRoute have specified hostnames, and none
match with the criteria above, then the GRPCRoute MUST NOT be accepted by
the implementation. The implementation MUST raise an 'Accepted' Condition
with a status of `False` in the corresponding RouteParentStatus.
If a Route (A) of type HTTPRoute or GRPCRoute is attached to a
Listener and that listener already has another Route (B) of the other
type attached and the intersection of the hostnames of A and B is
non-empty, then the implementation MUST accept exactly one of these two
routes, determined by the following criteria, in order:
* The oldest Route based on creation timestamp.
* The Route appearing first in alphabetical order by
"\{namespace\}/\{name\}".
The rejected Route MUST raise an 'Accepted' condition with a status of
'False' in the corresponding RouteParentStatus.
Support: Core | | MaxItems: 16
MaxLength: 253
MinLength: 1
Pattern: `^(\*\.)?[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$`
| +| `rules` _[GRPCRouteRule](#grpcrouterule) array_ | Rules are a list of GRPC matchers, filters and actions.
| + + +#### GRPCRouteStatus + + + +GRPCRouteStatus defines the observed state of GRPCRoute. + + + +_Appears in:_ +- [GRPCRoute](#grpcroute) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `parents` _[RouteParentStatus](#routeparentstatus) array_ | 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. | | MaxItems: 32
| + + +#### Gateway + + + +Gateway represents an instance of a service-traffic handling infrastructure +by binding Listeners to a set of IP addresses. + + + +_Appears in:_ +- [Gateway](#gateway) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `apiVersion` _string_ | `gateway.networking.k8s.io/v1` | | | +| `kind` _string_ | `Gateway` | | | +| `metadata` _[ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#objectmeta-v1-meta)_ | Refer to Kubernetes API documentation for fields of `metadata`. | | | +| `spec` _[GatewaySpec](#gatewayspec)_ | Spec defines the desired state of Gateway. | | | +| `status` _[GatewayStatus](#gatewaystatus)_ | Status defines the current state of Gateway. | \{ conditions:[map[lastTransitionTime:1970-01-01T00:00:00Z message:Waiting for controller reason:Pending status:Unknown type:Accepted] map[lastTransitionTime:1970-01-01T00:00:00Z message:Waiting for controller reason:Pending status:Unknown type:Programmed]] \} | | + + +#### GatewayBackendTLS + + + +GatewayBackendTLS describes backend TLS configuration for gateway. + + + +_Appears in:_ +- [GatewaySpec](#gatewayspec) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `clientCertificateRef` _[SecretObjectReference](#secretobjectreference)_ | ClientCertificateRef is a reference to an object that contains a Client
Certificate and the associated private key.
References to a resource in different namespace are invalid UNLESS there
is a ReferenceGrant in the target namespace that allows the certificate
to be attached. If a ReferenceGrant does not allow this reference, the
"ResolvedRefs" condition MUST be set to False for this listener with the
"RefNotPermitted" reason.
ClientCertificateRef can reference to standard Kubernetes resources, i.e.
Secret, or implementation-specific custom resources.
This setting can be overridden on the service level by use of BackendTLSPolicy.
Support: Core
Implementations MUST populate status on all GatewayClass resources which
specify their controller name. | \{ conditions:[map[lastTransitionTime:1970-01-01T00:00:00Z message:Waiting for controller reason:Pending status:Unknown type:Accepted]] \} | | + + + + + + +#### GatewayClassSpec + + + +GatewayClassSpec reflects the configuration of a class of Gateways. + + + +_Appears in:_ +- [GatewayClass](#gatewayclass) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `controllerName` _[GatewayController](#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 | | MaxLength: 253
MinLength: 1
Pattern: `^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*\/[A-Za-z0-9\/\-._~%!$&'()*+,;=:]+$`
| +| `parametersRef` _[ParametersReference](#parametersreference)_ | 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, refers to an unsupported kind, or when
the data within that resource is malformed, the GatewayClass SHOULD be
rejected with the "Accepted" status condition set to "False" and an
"InvalidParameters" reason.
A Gateway for this GatewayClass may provide its own `parametersRef`. When both are specified,
the merging behavior is implementation specific.
It is generally recommended that GatewayClass provides defaults that can be overridden by a Gateway.
Support: Implementation-specific | | | +| `description` _string_ | Description helps describe a GatewayClass with more details. | | MaxLength: 64
| + + +#### GatewayClassStatus + + + +GatewayClassStatus is the current status for the GatewayClass. + + + +_Appears in:_ +- [GatewayClass](#gatewayclass) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `conditions` _[Condition](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#condition-v1-meta) array_ | 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. | [map[lastTransitionTime:1970-01-01T00:00:00Z message:Waiting for controller reason:Pending status:Unknown type:Accepted]] | MaxItems: 8
| +| `supportedFeatures` _[SupportedFeature](#supportedfeature) array_ | SupportedFeatures is the set of features the GatewayClass support.
It MUST be sorted in ascending alphabetical order by the Name key.
| + + + + + + +#### GatewayController + +_Underlying type:_ _string_ + +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 + +_Validation:_ +- MaxLength: 253 +- MinLength: 1 +- Pattern: `^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*\/[A-Za-z0-9\/\-._~%!$&'()*+,;=:]+$` + +_Appears in:_ +- [GatewayClassSpec](#gatewayclassspec) +- [RouteParentStatus](#routeparentstatus) + + + +#### GatewayInfrastructure + + + +GatewayInfrastructure defines infrastructure level attributes about a Gateway instance. + + + +_Appears in:_ +- [GatewaySpec](#gatewayspec) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `labels` _object (keys:[LabelKey](#labelkey), values:[LabelValue](#labelvalue))_ | Labels that SHOULD be applied to any resources created in response to this Gateway.
For implementations creating other Kubernetes objects, this should be the `metadata.labels` field on resources.
For other implementations, this refers to any relevant (implementation specific) "labels" concepts.
An implementation may chose to add additional implementation-specific labels as they see fit.
If an implementation maps these labels to Pods, or any other resource that would need to be recreated when labels
change, it SHOULD clearly warn about this behavior in documentation.
Support: Extended | | MaxProperties: 8
| +| `annotations` _object (keys:[AnnotationKey](#annotationkey), values:[AnnotationValue](#annotationvalue))_ | Annotations that SHOULD be applied to any resources created in response to this Gateway.
For implementations creating other Kubernetes objects, this should be the `metadata.annotations` field on resources.
For other implementations, this refers to any relevant (implementation specific) "annotations" concepts.
An implementation may chose to add additional implementation-specific annotations as they see fit.
Support: Extended | | MaxProperties: 8
| +| `parametersRef` _[LocalParametersReference](#localparametersreference)_ | ParametersRef is a reference to a resource that contains the configuration
parameters corresponding to the Gateway. This is optional if the
controller does not require any additional configuration.
This follows the same semantics as GatewayClass's `parametersRef`, but on a per-Gateway basis
The Gateway's GatewayClass may provide its own `parametersRef`. When both are specified,
the merging behavior is implementation specific.
It is generally recommended that GatewayClass provides defaults that can be overridden by a Gateway.
If the referent cannot be found, refers to an unsupported kind, or when
the data within that resource is malformed, the Gateway SHOULD be
rejected with the "Accepted" status condition set to "False" and an
"InvalidParameters" reason.
Support: Implementation-specific | | | + + +#### GatewaySpec + + + +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 CRD +validation, but there are many cases that will require asynchronous +signaling via the GatewayStatus block. + + + +_Appears in:_ +- [Gateway](#gateway) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `gatewayClassName` _[ObjectName](#objectname)_ | GatewayClassName used for this Gateway. This is the name of a
GatewayClass resource. | | MaxLength: 253
MinLength: 1
| +| `listeners` _[Listener](#listener) array_ | Listeners associated with this Gateway. Listeners define
logical endpoints that are bound on this Gateway's addresses.
At least one Listener MUST be specified.
## Distinct Listeners
Each Listener in a set of Listeners (for example, in a single Gateway)
MUST be _distinct_, in that a traffic flow MUST be able to be assigned to
exactly one listener. (This section uses "set of Listeners" rather than
"Listeners in a single Gateway" because implementations MAY merge configuration
from multiple Gateways onto a single data plane, and these rules _also_
apply in that case).
Practically, this means that each listener in a set MUST have a unique
combination of Port, Protocol, and, if supported by the protocol, Hostname.
Some combinations of port, protocol, and TLS settings are considered
Core support and MUST be supported by implementations based on the objects
they support:
HTTPRoute
1. HTTPRoute, Port: 80, Protocol: HTTP
2. HTTPRoute, Port: 443, Protocol: HTTPS, TLS Mode: Terminate, TLS keypair provided
TLSRoute
1. TLSRoute, Port: 443, Protocol: TLS, TLS Mode: Passthrough
"Distinct" Listeners have the following property:
**The implementation can match inbound requests to a single distinct
Listener**.
When multiple Listeners share values for fields (for
example, two Listeners with the same Port value), the implementation
can match requests to only one of the Listeners using other
Listener fields.
When multiple listeners have the same value for the Protocol field, then
each of the Listeners with matching Protocol values MUST have different
values for other fields.
The set of fields that MUST be different for a Listener differs per protocol.
The following rules define the rules for what fields MUST be considered for
Listeners to be distinct with each protocol currently defined in the
Gateway API spec.
The set of listeners that all share a protocol value MUST have _different_
values for _at least one_ of these fields to be distinct:
* **HTTP, HTTPS, TLS**: Port, Hostname
* **TCP, UDP**: Port
One **very** important rule to call out involves what happens when an
implementation:
* Supports TCP protocol Listeners, as well as HTTP, HTTPS, or TLS protocol
Listeners, and
* sees HTTP, HTTPS, or TLS protocols with the same `port` as one with TCP
Protocol.
In this case all the Listeners that share a port with the
TCP Listener are not distinct and so MUST NOT be accepted.
If an implementation does not support TCP Protocol Listeners, then the
previous rule does not apply, and the TCP Listeners SHOULD NOT be
accepted.
Note that the `tls` field is not used for determining if a listener is distinct, because
Listeners that _only_ differ on TLS config will still conflict in all cases.
### Listeners that are distinct only by Hostname
When the Listeners are distinct based only on Hostname, inbound request
hostnames MUST match from the most specific to least specific Hostname
values to choose the correct Listener and its associated set of Routes.
Exact matches MUST be processed before wildcard matches, and wildcard
matches MUST be processed before fallback (empty Hostname value)
matches. For example, `"foo.example.com"` takes precedence over
`"*.example.com"`, and `"*.example.com"` takes precedence over `""`.
Additionally, if there are multiple wildcard entries, more specific
wildcard entries must be processed before less specific wildcard entries.
For example, `"*.foo.example.com"` takes precedence over `"*.example.com"`.
The precise definition here is that the higher the number of dots in the
hostname to the right of the wildcard character, the higher the precedence.
The wildcard character will match any number of characters _and dots_ to
the left, however, so `"*.example.com"` will match both
`"foo.bar.example.com"` _and_ `"bar.example.com"`.
## Handling indistinct Listeners
If a set of Listeners contains Listeners that are not distinct, then those
Listeners are _Conflicted_, and the implementation MUST set the "Conflicted"
condition in the Listener Status to "True".
The words "indistinct" and "conflicted" are considered equivalent for the
purpose of this documentation.
Implementations MAY choose to accept a Gateway with some Conflicted
Listeners only if they only accept the partial Listener set that contains
no Conflicted Listeners.
Specifically, an implementation MAY accept a partial Listener set subject to
the following rules:
* The implementation MUST NOT pick one conflicting Listener as the winner.
ALL indistinct Listeners must not be accepted for processing.
* At least one distinct Listener MUST be present, or else the Gateway effectively
contains _no_ Listeners, and must be rejected from processing as a whole.
The implementation MUST set a "ListenersNotValid" condition on the
Gateway Status when the Gateway contains Conflicted Listeners whether or
not they accept the Gateway. That Condition SHOULD clearly
indicate in the Message which Listeners are conflicted, and which are
Accepted. Additionally, the Listener status for those listeners SHOULD
indicate which Listeners are conflicted and not Accepted.
## General Listener behavior
Note that, for all distinct Listeners, requests SHOULD match at most one Listener.
For example, if Listeners are defined for "foo.example.com" and "*.example.com", a
request to "foo.example.com" SHOULD only be routed using routes attached
to the "foo.example.com" Listener (and not the "*.example.com" Listener).
This concept is known as "Listener Isolation", and it is an Extended feature
of Gateway API. Implementations that do not support Listener Isolation MUST
clearly document this, and MUST NOT claim support for the
`GatewayHTTPListenerIsolation` feature.
Implementations that _do_ support Listener Isolation SHOULD claim support
for the Extended `GatewayHTTPListenerIsolation` feature and pass the associated
conformance tests.
## Compatible Listeners
A Gateway's Listeners are considered _compatible_ if:
1. They are distinct.
2. The implementation can serve them in compliance with the Addresses
requirement that all Listeners are available on all assigned
addresses.
Compatible combinations in Extended support are expected to vary across
implementations. A combination that is compatible for one implementation
may not be compatible for another.
For example, an implementation that cannot serve both TCP and UDP listeners
on the same address, or cannot mix HTTPS and generic TLS listens on the same port
would not consider those cases compatible, even though they are distinct.
Implementations MAY merge separate Gateways onto a single set of
Addresses if all Listeners across all Gateways are compatible.
In a future release the MinItems=1 requirement MAY be dropped.
Support: Core | | MaxItems: 64
MinItems: 1
| +| `addresses` _[GatewaySpecAddress](#gatewayspecaddress) array_ | 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.
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
| +| `infrastructure` _[GatewayInfrastructure](#gatewayinfrastructure)_ | Infrastructure defines infrastructure level attributes about this Gateway instance.
Support: Extended | | | +| `backendTLS` _[GatewayBackendTLS](#gatewaybackendtls)_ | BackendTLS configures TLS settings for when this Gateway is connecting to
backends with TLS.
Support: Core
While this feature is experimental, the default value is to allow no ListenerSets.
MinLength: 1
Pattern: `^Hostname\|IPAddress\|NamedAddress\|[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*\/[A-Za-z0-9\/\-._~%!$&'()*+,;=:]+$`
| +| `value` _string_ | When a value is unspecified, an implementation SHOULD automatically
assign an address matching the requested type if possible.
If an implementation does not support an empty value, they MUST set the
"Programmed" condition in status to False with a reason of "AddressNotAssigned".
Examples: `1.2.3.4`, `128::1`, `my-ip-address`. | | MaxLength: 253
| + + +#### GatewayStatus + + + +GatewayStatus defines the observed state of Gateway. + + + +_Appears in:_ +- [Gateway](#gateway) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `addresses` _[GatewayStatusAddress](#gatewaystatusaddress) array_ | Addresses lists the network addresses that have been bound to the
Gateway.
This list may differ from the addresses provided in the spec under some
conditions:
* no addresses are specified, all addresses are dynamically assigned
* a combination of specified and dynamic addresses are assigned
* a specified address was unusable (e.g. already in use)
| +| `conditions` _[Condition](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#condition-v1-meta) array_ | 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:
* "Accepted"
* "Programmed"
* "Ready" | [map[lastTransitionTime:1970-01-01T00:00:00Z message:Waiting for controller reason:Pending status:Unknown type:Accepted] map[lastTransitionTime:1970-01-01T00:00:00Z message:Waiting for controller reason:Pending status:Unknown type:Programmed]] | MaxItems: 8
| +| `listeners` _[ListenerStatus](#listenerstatus) array_ | Listeners provide status for each unique listener port defined in the Spec. | | MaxItems: 64
| + + +#### GatewayStatusAddress + + + +GatewayStatusAddress describes a network address that is bound to a Gateway. + + + +_Appears in:_ +- [GatewayStatus](#gatewaystatus) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `type` _[AddressType](#addresstype)_ | Type of the address. | IPAddress | MaxLength: 253
MinLength: 1
Pattern: `^Hostname\|IPAddress\|NamedAddress\|[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*\/[A-Za-z0-9\/\-._~%!$&'()*+,;=:]+$`
| +| `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`. | | MaxLength: 253
MinLength: 1
| + + +#### GatewayTLSConfig + + + +GatewayTLSConfig describes a TLS configuration. + + + +_Appears in:_ +- [Listener](#listener) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `mode` _[TLSModeType](#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. This mode requires certificates
to be specified in some way, such as populating the certificateRefs
field.
- 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. The certificateRefs field
is ignored in this mode.
Support: Core | Terminate | Enum: [Terminate Passthrough]
| +| `certificateRefs` _[SecretObjectReference](#secretobjectreference) array_ | 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 ReferenceGrant in the target namespace that allows the certificate
to be attached. If a ReferenceGrant does not allow this reference, the
"ResolvedRefs" condition MUST be set to False for this listener with the
"RefNotPermitted" 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 of type kubernetes.io/tls
Support: Implementation-specific (More than one reference or other resource types) | | MaxItems: 64
| +| `frontendValidation` _[FrontendTLSValidation](#frontendtlsvalidation)_ | FrontendValidation holds configuration information for validating the frontend (client).
Setting this field will require clients to send a client certificate
required for validation during the TLS handshake. In browsers this may result in a dialog appearing
that requests a user to specify the client certificate.
The maximum depth of a certificate chain accepted in verification is Implementation specific.
Support: Extended
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 | | MaxProperties: 16
| + + +#### Group + +_Underlying type:_ _string_ + +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 +* "gateway.networking.k8s.io" +* "foo.example.com" + +Invalid values include: + +* "example.com/bar" - "/" is an invalid character + +_Validation:_ +- MaxLength: 253 +- Pattern: `^$|^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$` + +_Appears in:_ +- [BackendObjectReference](#backendobjectreference) +- [BackendRef](#backendref) +- [GRPCBackendRef](#grpcbackendref) +- [HTTPBackendRef](#httpbackendref) +- [LocalObjectReference](#localobjectreference) +- [LocalParametersReference](#localparametersreference) +- [ObjectReference](#objectreference) +- [ParametersReference](#parametersreference) +- [ParentReference](#parentreference) +- [RouteGroupKind](#routegroupkind) +- [SecretObjectReference](#secretobjectreference) + + + +#### HTTPBackendRef + + + +HTTPBackendRef defines how a HTTPRoute forwards a HTTP request. + +Note that when a namespace different than the local namespace is specified, a +ReferenceGrant object is required in the referent namespace to allow that +namespace's owner to accept the reference. See the ReferenceGrant +documentation for details. + +
When unspecified or empty string, core API group is inferred. | | MaxLength: 253
Pattern: `^$\|^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$`
| +| `kind` _[Kind](#kind)_ | Kind is the Kubernetes resource kind of the referent. For example
"Service".
Defaults to "Service" when not specified.
ExternalName services can refer to CNAME DNS records that may live
outside of the cluster and as such are difficult to reason about in
terms of conformance. They also may not be safe to forward to (see
CVE-2021-25740 for more information). Implementations SHOULD NOT
support ExternalName Services.
Support: Core (Services with a type other than ExternalName)
Support: Implementation-specific (Services with type ExternalName) | Service | MaxLength: 63
MinLength: 1
Pattern: `^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$`
| +| `name` _[ObjectName](#objectname)_ | Name is the name of the referent. | | MaxLength: 253
MinLength: 1
| +| `namespace` _[Namespace](#namespace)_ | Namespace is the namespace of the backend. When unspecified, the local
namespace is inferred.
Note that when a namespace different than the local namespace is specified,
a ReferenceGrant object is required in the referent namespace to allow that
namespace's owner to accept the reference. See the ReferenceGrant
documentation for details.
Support: Core | | MaxLength: 63
MinLength: 1
Pattern: `^[a-z0-9]([-a-z0-9]*[a-z0-9])?$`
| +| `port` _[PortNumber](#portnumber)_ | Port specifies the destination port number to use for this resource.
Port is required when the referent is a Kubernetes Service. In this
case, the port number is the service port number, not the target port.
For other resources, destination port might be derived from the referent
resource or this field. | | Maximum: 65535
Minimum: 1
| +| `weight` _integer_ | 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. | 1 | Maximum: 1e+06
Minimum: 0
| +| `filters` _[HTTPRouteFilter](#httproutefilter) array_ | Filters defined at this level should be executed if and only if the
request is being forwarded to the backend defined here.
Support: Implementation-specific (For broader support of filters, use the
Filters field in HTTPRouteRule.) | | MaxItems: 16
| + + +#### HTTPCORSFilter + + + +HTTPCORSFilter defines a filter that that configures Cross-Origin Request +Sharing (CORS). + + + +_Appears in:_ +- [HTTPRouteFilter](#httproutefilter) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `allowOrigins` _[AbsoluteURI](#absoluteuri) array_ | AllowOrigins indicates whether the response can be shared with requested
resource from the given `Origin`.
The `Origin` consists of a scheme and a host, with an optional port, and
takes the form `
Valid values for scheme are: `http` and `https`.
Valid values for port are any integer between 1 and 65535 (the list of
available TCP/UDP ports). Note that, if not included, port `80` is
assumed for `http` scheme origins, and port `443` is assumed for `https`
origins. This may affect origin matching.
The host part of the origin may contain the wildcard character `*`. These
wildcard characters behave as follows:
* `*` is a greedy match to the _left_, including any number of
DNS labels to the left of its position. This also means that
`*` will include any number of period `.` characters to the
left of its position.
* A wildcard by itself matches all hosts.
An origin value that includes _only_ the `*` character indicates requests
from all `Origin`s are allowed.
When the `AllowOrigins` field is configured with multiple origins, it
means the server supports clients from multiple origins. If the request
`Origin` matches the configured allowed origins, the gateway must return
the given `Origin` and sets value of the header
`Access-Control-Allow-Origin` same as the `Origin` header provided by the
client.
The status code of a successful response to a "preflight" request is
always an OK status (i.e., 204 or 200).
If the request `Origin` does not match the configured allowed origins,
the gateway returns 204/200 response but doesn't set the relevant
cross-origin response headers. Alternatively, the gateway responds with
403 status to the "preflight" request is denied, coupled with omitting
the CORS headers. The cross-origin request fails on the client side.
Therefore, the client doesn't attempt the actual cross-origin request.
The `Access-Control-Allow-Origin` response header can only use `*`
wildcard as value when the `AllowCredentials` field is unspecified.
When the `AllowCredentials` field is specified and `AllowOrigins` field
specified with the `*` wildcard, the gateway must return a single origin
in the value of the `Access-Control-Allow-Origin` response header,
instead of specifying the `*` wildcard. The value of the header
`Access-Control-Allow-Origin` is same as the `Origin` header provided by
the client.
Support: Extended | | MaxItems: 64
MaxLength: 253
MinLength: 1
Pattern: `^(([^:/?#]+):)(//([^/?#]*))([^?#]*)(\?([^#]*))?(#(.*))?`
| +| `allowCredentials` _[TrueField](#truefield)_ | AllowCredentials indicates whether the actual cross-origin request allows
to include credentials.
The only valid value for the `Access-Control-Allow-Credentials` response
header is true (case-sensitive).
If the credentials are not allowed in cross-origin requests, the gateway
will omit the header `Access-Control-Allow-Credentials` entirely rather
than setting its value to false.
Support: Extended | | Enum: [true]
| +| `allowMethods` _[HTTPMethodWithWildcard](#httpmethodwithwildcard) array_ | AllowMethods indicates which HTTP methods are supported for accessing the
requested resource.
Valid values are any method defined by RFC9110, along with the special
value `*`, which represents all HTTP methods are allowed.
Method names are case sensitive, so these values are also case-sensitive.
(See https://www.rfc-editor.org/rfc/rfc2616#section-5.1.1)
Multiple method names in the value of the `Access-Control-Allow-Methods`
response header are separated by a comma (",").
A CORS-safelisted method is a method that is `GET`, `HEAD`, or `POST`.
(See https://fetch.spec.whatwg.org/#cors-safelisted-method) The
CORS-safelisted methods are always allowed, regardless of whether they
are specified in the `AllowMethods` field.
When the `AllowMethods` field is configured with one or more methods, the
gateway must return the `Access-Control-Allow-Methods` response header
which value is present in the `AllowMethods` field.
If the HTTP method of the `Access-Control-Request-Method` request header
is not included in the list of methods specified by the response header
`Access-Control-Allow-Methods`, it will present an error on the client
side.
The `Access-Control-Allow-Methods` response header can only use `*`
wildcard as value when the `AllowCredentials` field is unspecified.
When the `AllowCredentials` field is specified and `AllowMethods` field
specified with the `*` wildcard, the gateway must specify one HTTP method
in the value of the Access-Control-Allow-Methods response header. The
value of the header `Access-Control-Allow-Methods` is same as the
`Access-Control-Request-Method` header provided by the client. If the
header `Access-Control-Request-Method` is not included in the request,
the gateway will omit the `Access-Control-Allow-Methods` response header,
instead of specifying the `*` wildcard. A Gateway implementation may
choose to add implementation-specific default methods.
Support: Extended | | Enum: [GET HEAD POST PUT DELETE CONNECT OPTIONS TRACE PATCH *]
MaxItems: 9
| +| `allowHeaders` _[HTTPHeaderName](#httpheadername) array_ | AllowHeaders indicates which HTTP request headers are supported for
accessing the requested resource.
Header names are not case sensitive.
Multiple header names in the value of the `Access-Control-Allow-Headers`
response header are separated by a comma (",").
When the `AllowHeaders` field is configured with one or more headers, the
gateway must return the `Access-Control-Allow-Headers` response header
which value is present in the `AllowHeaders` field.
If any header name in the `Access-Control-Request-Headers` request header
is not included in the list of header names specified by the response
header `Access-Control-Allow-Headers`, it will present an error on the
client side.
If any header name in the `Access-Control-Allow-Headers` response header
does not recognize by the client, it will also occur an error on the
client side.
A wildcard indicates that the requests with all HTTP headers are allowed.
The `Access-Control-Allow-Headers` response header can only use `*`
wildcard as value when the `AllowCredentials` field is unspecified.
When the `AllowCredentials` field is specified and `AllowHeaders` field
specified with the `*` wildcard, the gateway must specify one or more
HTTP headers in the value of the `Access-Control-Allow-Headers` response
header. The value of the header `Access-Control-Allow-Headers` is same as
the `Access-Control-Request-Headers` header provided by the client. If
the header `Access-Control-Request-Headers` is not included in the
request, the gateway will omit the `Access-Control-Allow-Headers`
response header, instead of specifying the `*` wildcard. A Gateway
implementation may choose to add implementation-specific default headers.
Support: Extended | | MaxItems: 64
MaxLength: 256
MinLength: 1
Pattern: `^[A-Za-z0-9!#$%&'*+\-.^_\x60\|~]+$`
| +| `exposeHeaders` _[HTTPHeaderName](#httpheadername) array_ | ExposeHeaders indicates which HTTP response headers can be exposed
to client-side scripts in response to a cross-origin request.
A CORS-safelisted response header is an HTTP header in a CORS response
that it is considered safe to expose to the client scripts.
The CORS-safelisted response headers include the following headers:
`Cache-Control`
`Content-Language`
`Content-Length`
`Content-Type`
`Expires`
`Last-Modified`
`Pragma`
(See https://fetch.spec.whatwg.org/#cors-safelisted-response-header-name)
The CORS-safelisted response headers are exposed to client by default.
When an HTTP header name is specified using the `ExposeHeaders` field,
this additional header will be exposed as part of the response to the
client.
Header names are not case sensitive.
Multiple header names in the value of the `Access-Control-Expose-Headers`
response header are separated by a comma (",").
A wildcard indicates that the responses with all HTTP headers are exposed
to clients. The `Access-Control-Expose-Headers` response header can only
use `*` wildcard as value when the `AllowCredentials` field is
unspecified.
Support: Extended | | MaxItems: 64
MaxLength: 256
MinLength: 1
Pattern: `^[A-Za-z0-9!#$%&'*+\-.^_\x60\|~]+$`
| +| `maxAge` _integer_ | MaxAge indicates the duration (in seconds) for the client to cache the
results of a "preflight" request.
The information provided by the `Access-Control-Allow-Methods` and
`Access-Control-Allow-Headers` response headers can be cached by the
client until the time specified by `Access-Control-Max-Age` elapses.
The default value of `Access-Control-Max-Age` response header is 5
(seconds). | 5 | Minimum: 1
| + + +#### HTTPHeader + + + +HTTPHeader represents an HTTP Header name and value as defined by RFC 7230. + + + +_Appears in:_ +- [HTTPHeaderFilter](#httpheaderfilter) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `name` _[HTTPHeaderName](#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. | | MaxLength: 256
MinLength: 1
Pattern: `^[A-Za-z0-9!#$%&'*+\-.^_\x60\|~]+$`
| +| `value` _string_ | Value is the value of HTTP Header to be matched. | | MaxLength: 4096
MinLength: 1
| + + +#### HTTPHeaderFilter + + + +HTTPHeaderFilter defines a filter that modifies the headers of an HTTP +request or response. Only one action for a given header name is permitted. +Filters specifying multiple actions of the same or different type for any one +header name are invalid and will be rejected by CRD validation. +Configuration to set or add multiple values for a header must use RFC 7230 +header value formatting, separating each value with a comma. + + + +_Appears in:_ +- [GRPCRouteFilter](#grpcroutefilter) +- [HTTPRouteFilter](#httproutefilter) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `set` _[HTTPHeader](#httpheader) array_ | 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 | | MaxItems: 16
| +| `add` _[HTTPHeader](#httpheader) array_ | 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,baz"
Output:
GET /foo HTTP/1.1
my-header: foo,bar,baz | | MaxItems: 16
| +| `remove` _string array_ | 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 | | MaxItems: 16
| + + +#### HTTPHeaderMatch + + + +HTTPHeaderMatch describes how to select a HTTP route by matching HTTP request +headers. + + + +_Appears in:_ +- [HTTPRouteMatch](#httproutematch) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `type` _[HeaderMatchType](#headermatchtype)_ | Type specifies how to match against the value of the header.
Support: Core (Exact)
Support: Implementation-specific (RegularExpression)
Since RegularExpression HeaderMatchType has implementation-specific
conformance, implementations can support POSIX, PCRE or any other dialects
of regular expressions. Please read the implementation's documentation to
determine the supported dialect. | Exact | Enum: [Exact RegularExpression]
| +| `name` _[HTTPHeaderName](#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". | | MaxLength: 256
MinLength: 1
Pattern: `^[A-Za-z0-9!#$%&'*+\-.^_\x60\|~]+$`
| +| `value` _string_ | Value is the value of HTTP Header to be matched. | | MaxLength: 4096
MinLength: 1
| + + +#### HTTPHeaderName + +_Underlying type:_ _[HeaderName](#headername)_ + +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 + +_Validation:_ +- MaxLength: 256 +- MinLength: 1 +- Pattern: `^[A-Za-z0-9!#$%&'*+\-.^_\x60|~]+$` + +_Appears in:_ +- [HTTPCORSFilter](#httpcorsfilter) +- [HTTPHeader](#httpheader) +- [HTTPHeaderMatch](#httpheadermatch) +- [HTTPQueryParamMatch](#httpqueryparammatch) + + + +#### HTTPMethod + +_Underlying type:_ _string_ + +HTTPMethod describes how to select a HTTP route by matching the HTTP +method as defined by +[RFC 7231](https://datatracker.ietf.org/doc/html/rfc7231#section-4) and +[RFC 5789](https://datatracker.ietf.org/doc/html/rfc5789#section-2). +The value is expected in upper case. + +Note that values may be added to this enum, implementations +must ensure that unknown values will not cause a crash. + +Unknown values here must result in the implementation setting the +Accepted Condition for the Route to `status: False`, with a +Reason of `UnsupportedValue`. + +_Validation:_ +- Enum: [GET HEAD POST PUT DELETE CONNECT OPTIONS TRACE PATCH] + +_Appears in:_ +- [HTTPRouteMatch](#httproutematch) + +| Field | Description | +| --- | --- | +| `GET` | | +| `HEAD` | | +| `POST` | | +| `PUT` | | +| `DELETE` | | +| `CONNECT` | | +| `OPTIONS` | | +| `TRACE` | | +| `PATCH` | | + + +#### HTTPMethodWithWildcard + +_Underlying type:_ _string_ + + + +_Validation:_ +- Enum: [GET HEAD POST PUT DELETE CONNECT OPTIONS TRACE PATCH *] + +_Appears in:_ +- [HTTPCORSFilter](#httpcorsfilter) + + + +#### HTTPPathMatch + + + +HTTPPathMatch describes how to select a HTTP route by matching the HTTP request path. + + + +_Appears in:_ +- [HTTPRouteMatch](#httproutematch) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `type` _[PathMatchType](#pathmatchtype)_ | Type specifies how to match against the path Value.
Support: Core (Exact, PathPrefix)
Support: Implementation-specific (RegularExpression) | PathPrefix | Enum: [Exact PathPrefix RegularExpression]
| +| `value` _string_ | Value of the HTTP path to match against. | / | MaxLength: 1024
| + + +#### HTTPPathModifier + + + +HTTPPathModifier defines configuration for path modifiers. + + + +_Appears in:_ +- [HTTPRequestRedirectFilter](#httprequestredirectfilter) +- [HTTPURLRewriteFilter](#httpurlrewritefilter) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `type` _[HTTPPathModifierType](#httppathmodifiertype)_ | Type defines the type of path modifier. Additional types may be
added in a future release of the API.
Note that values may be added to this enum, implementations
must ensure that unknown values will not cause a crash.
Unknown values here must result in the implementation setting the
Accepted Condition for the Route to `status: False`, with a
Reason of `UnsupportedValue`. | | Enum: [ReplaceFullPath ReplacePrefixMatch]
| +| `replaceFullPath` _string_ | ReplaceFullPath specifies the value with which to replace the full path
of a request during a rewrite or redirect. | | MaxLength: 1024
| +| `replacePrefixMatch` _string_ | ReplacePrefixMatch specifies the value with which to replace the prefix
match of a request during a rewrite or redirect. For example, a request
to "/foo/bar" with a prefix match of "/foo" and a ReplacePrefixMatch
of "/xyz" would be modified to "/xyz/bar".
Note that this matches the behavior of the PathPrefix match type. This
matches full path elements. 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.
ReplacePrefixMatch is only compatible with a `PathPrefix` HTTPRouteMatch.
Using any other HTTPRouteMatch type on the same HTTPRouteRule will result in
the implementation setting the Accepted Condition for the Route to `status: False`.
Request Path \| Prefix Match \| Replace Prefix \| Modified Path | | MaxLength: 1024
| + + +#### HTTPPathModifierType + +_Underlying type:_ _string_ + +HTTPPathModifierType defines the type of path redirect or rewrite. + + + +_Appears in:_ +- [HTTPPathModifier](#httppathmodifier) + +| Field | Description | +| --- | --- | +| `ReplaceFullPath` | This type of modifier indicates that the full path will be replaced
by the specified 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.
Note that this matches the behavior of the PathPrefix match type. This
matches full path elements. 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.
| + + +#### HTTPQueryParamMatch + + + +HTTPQueryParamMatch describes how to select a HTTP route by matching HTTP +query parameters. + + + +_Appears in:_ +- [HTTPRouteMatch](#httproutematch) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `type` _[QueryParamMatchType](#queryparammatchtype)_ | Type specifies how to match against the value of the query parameter.
Support: Extended (Exact)
Support: Implementation-specific (RegularExpression)
Since RegularExpression QueryParamMatchType has Implementation-specific
conformance, implementations can support POSIX, PCRE or any other
dialects of regular expressions. Please read the implementation's
documentation to determine the supported dialect. | Exact | Enum: [Exact RegularExpression]
| +| `name` _[HTTPHeaderName](#httpheadername)_ | 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).
If multiple entries specify equivalent query param names, only the first
entry with an equivalent name MUST be considered for a match. Subsequent
entries with an equivalent query param name MUST be ignored.
If a query param is repeated in an HTTP request, the behavior is
purposely left undefined, since different data planes have different
capabilities. However, it is *recommended* that implementations should
match against the first value of the param if the data plane supports it,
as this behavior is expected in other load balancing contexts outside of
the Gateway API.
Users SHOULD NOT route traffic based on repeated query params to guard
themselves against potential differences in the implementations. | | MaxLength: 256
MinLength: 1
Pattern: `^[A-Za-z0-9!#$%&'*+\-.^_\x60\|~]+$`
| +| `value` _string_ | Value is the value of HTTP query param to be matched. | | MaxLength: 1024
MinLength: 1
| + + +#### HTTPRequestMirrorFilter + + + +HTTPRequestMirrorFilter defines configuration for the RequestMirror filter. + + + +_Appears in:_ +- [GRPCRouteFilter](#grpcroutefilter) +- [HTTPRouteFilter](#httproutefilter) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `backendRef` _[BackendObjectReference](#backendobjectreference)_ | BackendRef references a resource where mirrored requests are sent.
Mirrored requests must be sent only to a single destination endpoint
within this BackendRef, irrespective of how many endpoints are present
within this BackendRef.
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 ReferenceGrant, 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: Implementation-specific for any other resource | | | +| `percent` _integer_ | Percent represents the percentage of requests that should be
mirrored to BackendRef. Its minimum value is 0 (indicating 0% of
requests) and its maximum value is 100 (indicating 100% of requests).
Only one of Fraction or Percent may be specified. If neither field
is specified, 100% of requests will be mirrored. | | Maximum: 100
Minimum: 0
| +| `fraction` _[Fraction](#fraction)_ | Fraction represents the fraction of requests that should be
mirrored to BackendRef.
Only one of Fraction or Percent may be specified. If neither field
is specified, 100% of requests will be mirrored. | | | + + +#### HTTPRequestRedirectFilter + + + +HTTPRequestRedirect defines a filter that redirects a request. This filter +MUST NOT be used on the same Route rule as a HTTPURLRewrite filter. + + + +_Appears in:_ +- [HTTPRouteFilter](#httproutefilter) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `scheme` _string_ | 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.
Scheme redirects can affect the port of the redirect, for more information,
refer to the documentation for the port field of this filter.
Note that values may be added to this enum, implementations
must ensure that unknown values will not cause a crash.
Unknown values here must result in the implementation setting the
Accepted Condition for the Route to `status: False`, with a
Reason of `UnsupportedValue`.
Support: Extended | | Enum: [http https]
| +| `hostname` _[PreciseHostname](#precisehostname)_ | Hostname is the hostname to be used in the value of the `Location`
header in the response.
When empty, the hostname in the `Host` header of the request is used.
Support: Core | | MaxLength: 253
MinLength: 1
Pattern: `^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$`
| +| `path` _[HTTPPathModifier](#httppathmodifier)_ | 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 | | | +| `port` _[PortNumber](#portnumber)_ | Port is the port to be used in the value of the `Location`
header in the response.
If no port is specified, the redirect port MUST be derived using the
following rules:
* If redirect scheme is not-empty, the redirect port MUST be the well-known
port associated with the redirect scheme. Specifically "http" to port 80
and "https" to port 443. If the redirect scheme does not have a
well-known port, the listener port of the Gateway SHOULD be used.
* If redirect scheme is empty, the redirect port MUST be the Gateway
Listener port.
Implementations SHOULD NOT add the port number in the 'Location'
header in the following cases:
* A Location header that will use HTTP (whether that is determined via
the Listener protocol or the Scheme field) _and_ use port 80.
* A Location header that will use HTTPS (whether that is determined via
the Listener protocol or the Scheme field) _and_ use port 443.
Support: Extended | | Maximum: 65535
Minimum: 1
| +| `statusCode` _integer_ | StatusCode is the HTTP status code to be used in response.
Note that values may be added to this enum, implementations
must ensure that unknown values will not cause a crash.
Unknown values here must result in the implementation setting the
Accepted Condition for the Route to `status: False`, with a
Reason of `UnsupportedValue`.
Support: Core | 302 | Enum: [301 302]
| + + +#### 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. + + + +_Appears in:_ +- [HTTPRoute](#httproute) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `apiVersion` _string_ | `gateway.networking.k8s.io/v1` | | | +| `kind` _string_ | `HTTPRoute` | | | +| `metadata` _[ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#objectmeta-v1-meta)_ | Refer to Kubernetes API documentation for fields of `metadata`. | | | +| `spec` _[HTTPRouteSpec](#httproutespec)_ | Spec defines the desired state of HTTPRoute. | | | +| `status` _[HTTPRouteStatus](#httproutestatus)_ | Status defines the current state of HTTPRoute. | | | + + +#### HTTPRouteFilter + + + +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. + +
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.
- Implementation-specific: 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.
Note that values may be added to this enum, implementations
must ensure that unknown values will not cause a crash.
Unknown values here must result in the implementation setting the
Accepted Condition for the Route to `status: False`, with a
Reason of `UnsupportedValue`.
| +| `requestHeaderModifier` _[HTTPHeaderFilter](#httpheaderfilter)_ | RequestHeaderModifier defines a schema for a filter that modifies request
headers.
Support: Core | | | +| `responseHeaderModifier` _[HTTPHeaderFilter](#httpheaderfilter)_ | ResponseHeaderModifier defines a schema for a filter that modifies response
headers.
Support: Extended | | | +| `requestMirror` _[HTTPRequestMirrorFilter](#httprequestmirrorfilter)_ | RequestMirror defines a schema for a filter that mirrors requests.
Requests are sent to the specified destination, but responses from
that destination are ignored.
This filter can be used multiple times within the same rule. Note that
not all implementations will be able to support mirroring to multiple
backends.
Support: Extended | | | +| `requestRedirect` _[HTTPRequestRedirectFilter](#httprequestredirectfilter)_ | RequestRedirect defines a schema for a filter that responds to the
request with an HTTP redirection.
Support: Core | | | +| `urlRewrite` _[HTTPURLRewriteFilter](#httpurlrewritefilter)_ | URLRewrite defines a schema for a filter that modifies a request during forwarding.
Support: Extended | | | +| `cors` _[HTTPCORSFilter](#httpcorsfilter)_ | CORS defines a schema for a filter that responds to the
cross-origin request based on HTTP response header.
Support: Extended
"filter" behavior. For example, resource "myroutefilter" in group
"networking.example.net"). ExtensionRef MUST NOT be used for core and
extended filters.
This filter can be used multiple times within the same rule.
Support: Implementation-specific | | | + + +#### HTTPRouteFilterType + +_Underlying type:_ _string_ + +HTTPRouteFilterType identifies a type of HTTPRoute filter. + + + +_Appears in:_ +- [HTTPRouteFilter](#httproutefilter) + +| Field | Description | +| --- | --- | +| `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
| +| `ResponseHeaderModifier` | HTTPRouteFilterResponseHeaderModifier can be used to add or remove an HTTP
header from an HTTP response before it is sent to the client.
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
| +| `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
| +| `CORS` | HTTPRouteFilterCORS can be used to add CORS headers to an
HTTP response before it is sent to the client.
Support in HTTPRouteRule: Extended
Support in HTTPBackendRef: Extended
| +| `ExtensionRef` | HTTPRouteFilterExtensionRef should be used for configuring custom
HTTP filters.
Support in HTTPRouteRule: Implementation-specific
Support in HTTPBackendRef: Implementation-specific
| + + +#### HTTPRouteMatch + + + +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" + +``` + + + +_Appears in:_ +- [HTTPRouteRule](#httprouterule) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `path` _[HTTPPathMatch](#httppathmatch)_ | Path specifies a HTTP request path matcher. If this field is not
specified, a default prefix match on the "/" path is provided. | \{ type:PathPrefix value:/ \} | | +| `headers` _[HTTPHeaderMatch](#httpheadermatch) array_ | 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. | | MaxItems: 16
| +| `queryParams` _[HTTPQueryParamMatch](#httpqueryparammatch) array_ | 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.
Support: Extended | | MaxItems: 16
| +| `method` _[HTTPMethod](#httpmethod)_ | Method specifies HTTP method matcher.
When specified, this route will be matched only if the request has the
specified method.
Support: Extended | | Enum: [GET HEAD POST PUT DELETE CONNECT OPTIONS TRACE PATCH]
| + + +#### HTTPRouteRetry + + + +HTTPRouteRetry defines retry configuration for an HTTPRoute. + +Implementations SHOULD retry on connection errors (disconnect, reset, timeout, +TCP failure) if a retry stanza is configured. + + + +_Appears in:_ +- [HTTPRouteRule](#httprouterule) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `codes` _[HTTPRouteRetryStatusCode](#httprouteretrystatuscode) array_ | Codes defines the HTTP response status codes for which a backend request
should be retried.
Support: Extended | | Maximum: 599
Minimum: 400
| +| `attempts` _integer_ | Attempts specifies the maximum number of times an individual request
from the gateway to a backend should be retried.
If the maximum number of retries has been attempted without a successful
response from the backend, the Gateway MUST return an error.
When this field is unspecified, the number of times to attempt to retry
a backend request is implementation-specific.
Support: Extended | | | +| `backoff` _[Duration](#duration)_ | Backoff specifies the minimum duration a Gateway should wait between
retry attempts and is represented in Gateway API Duration formatting.
For example, setting the `rules[].retry.backoff` field to the value
`100ms` will cause a backend request to first be retried approximately
100 milliseconds after timing out or receiving a response code configured
to be retryable.
An implementation MAY use an exponential or alternative backoff strategy
for subsequent retry attempts, MAY cap the maximum backoff duration to
some amount greater than the specified minimum, and MAY add arbitrary
jitter to stagger requests, as long as unsuccessful backend requests are
not retried before the configured minimum duration.
If a Request timeout (`rules[].timeouts.request`) is configured on the
route, the entire duration of the initial request and any retry attempts
MUST not exceed the Request timeout duration. If any retry attempts are
still in progress when the Request timeout duration has been reached,
these SHOULD be canceled if possible and the Gateway MUST immediately
return a timeout error.
If a BackendRequest timeout (`rules[].timeouts.backendRequest`) is
configured on the route, any retry attempts which reach the configured
BackendRequest timeout duration without a response SHOULD be canceled if
possible and the Gateway should wait for at least the specified backoff
duration before attempting to retry the backend request again.
If a BackendRequest timeout is _not_ configured on the route, retry
attempts MAY time out after an implementation default duration, or MAY
remain pending until a configured Request timeout or implementation
default duration for total request time is reached.
When this field is unspecified, the time to wait between retry attempts
is implementation-specific.
Support: Extended | | Pattern: `^([0-9]\{1,5\}(h\|m\|s\|ms))\{1,4\}$`
| + + +#### HTTPRouteRetryStatusCode + +_Underlying type:_ _integer_ + +HTTPRouteRetryStatusCode defines an HTTP response status code for +which a backend request should be retried. + +Implementations MUST support the following status codes as retryable: + +* 500 +* 502 +* 503 +* 504 + +Implementations MAY support specifying additional discrete values in the +500-599 range. + +Implementations MAY support specifying discrete values in the 400-499 range, +which are often inadvisable to retry. + +
Support: Extended
MinLength: 1
Pattern: `^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$`
| +| `matches` _[HTTPRouteMatch](#httproutematch) array_ | 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 matches based on the following criteria, continuing on
ties. Across all rules specified on applicable Routes, precedence must be
given to the match having:
* "Exact" path match.
* "Prefix" path match with largest number of characters.
* Method match.
* Largest number of header matches.
* Largest number of query param matches.
Note: The precedence of RegularExpression path matches are implementation-specific.
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
"\{namespace\}/\{name\}".
If ties still exist within an HTTPRoute, matching precedence MUST be granted
to the FIRST matching rule (in list order) with a match meeting the above
criteria.
When no rules matching a request have been successfully attached to the
parent a request is coming from, a HTTP 404 status code MUST be returned. | [map[path:map[type:PathPrefix value:/]]] | MaxItems: 64
| +| `filters` _[HTTPRouteFilter](#httproutefilter) array_ | Filters define the filters that are applied to requests that match
this rule.
Wherever possible, implementations SHOULD implement filters in the order
they are specified.
Implementations MAY choose to implement this ordering strictly, rejecting
any combination or order of filters that cannot be supported. If implementations
choose a strict interpretation of filter ordering, they MUST clearly document
that behavior.
To reject an invalid combination or order of filters, implementations SHOULD
consider the Route Rules with this configuration invalid. If all Route Rules
in a Route are invalid, the entire Route would be considered invalid. If only
a portion of Route Rules are invalid, implementations MUST set the
"PartiallyInvalid" condition for the Route.
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 the same filter multiple times is not supported unless explicitly
indicated in the filter.
All filters are expected to be compatible with each other except for the
URLRewrite and RequestRedirect filters, which may not be combined. If an
implementation cannot support other combinations of filters, they must clearly
document that limitation. In cases where incompatible or unsupported
filters are specified and cause the `Accepted` condition to be set to status
`False`, implementations may use the `IncompatibleFilters` reason to specify
this configuration error.
Support: Core | | MaxItems: 16
| +| `backendRefs` _[HTTPBackendRef](#httpbackendref) array_ | BackendRefs defines the backend(s) where matching requests should be
sent.
Failure behavior here depends on how many BackendRefs are specified and
how many are invalid.
If *all* entries in BackendRefs are invalid, and there are also no filters
specified in this route rule, *all* traffic which matches this rule MUST
receive a 500 status code.
See the HTTPBackendRef definition for the rules about what makes a single
HTTPBackendRef invalid.
When a HTTPBackendRef is invalid, 500 status codes MUST be returned for
requests that would have otherwise been routed to an invalid backend. If
multiple backends are specified, and some are invalid, the proportion of
requests that would otherwise have been routed to an invalid backend
MUST receive a 500 status code.
For example, if two backends are specified with equal weights, and one is
invalid, 50 percent of traffic must receive a 500. Implementations may
choose how that 50 percent is determined.
When a HTTPBackendRef refers to a Service that has no ready endpoints,
implementations SHOULD return a 503 for requests to that backend instead.
If an implementation chooses to do this, all of the above rules for 500 responses
MUST also apply for responses that return a 503.
Support: Core for Kubernetes Service
Support: Extended for Kubernetes ServiceImport
Support: Implementation-specific for any other resource
Support for weight: Core | | MaxItems: 16
| +| `timeouts` _[HTTPRouteTimeouts](#httproutetimeouts)_ | Timeouts defines the timeouts that can be configured for an HTTP request.
Support: Extended | | | +| `retry` _[HTTPRouteRetry](#httprouteretry)_ | Retry defines the configuration for when to retry an HTTP request.
Support: Extended
for the route rule.
Support: Extended
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. For Services, that means the Service must either be in the same
namespace for a "producer" route, or the mesh implementation must support
and allow "consumer" routes for the referenced Service. ReferenceGrant is
not applicable for governing ParentRefs to Services - it is not possible to
create a "producer" route for a Service in a different namespace from the
Route.
There are two kinds of parent resources with "Core" support:
* Gateway (Gateway conformance profile)
* Service (Mesh conformance profile, ClusterIP Services only)
This API may be extended in the future to support additional kinds of parent
resources.
ParentRefs must be _distinct_. This means either that:
* They select different objects. If this is the case, then parentRef
entries are distinct. In terms of fields, this means that the
multi-part key defined by `group`, `kind`, `namespace`, and `name` must
be unique across all parentRef entries in the Route.
* They do not select different objects, but for each optional field used,
each ParentRef that selects the same object must set the same set of
optional fields to different values. If one ParentRef sets a
combination of optional fields, all must set the same combination.
Some examples:
* If one ParentRef sets `sectionName`, all ParentRefs referencing the
same object must also set `sectionName`.
* If one ParentRef sets `port`, all ParentRefs referencing the same
object must also set `port`.
* If one ParentRef sets `sectionName` and `port`, all ParentRefs
referencing the same object must also set `sectionName` and `port`.
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.
Note that for ParentRefs that cross namespace boundaries, there are specific
rules. Cross-namespace references are only valid if they are explicitly
allowed by something in the namespace they are referring to. For example,
Gateway has the AllowedRoutes field, and ReferenceGrant provides a
generic way to enable other kinds of cross-namespace reference.
ParentRefs from a Route to a Service in the same namespace are "producer"
routes, which apply default routing rules to inbound connections from
any namespace to the Service.
ParentRefs from a Route to a Service in a different namespace are
"consumer" routes, and these routing rules are only applied to outbound
connections originating from the same namespace as the Route, for which
the intended destination of the connections are a Service targeted as a
ParentRef of the Route.
| +| `hostnames` _[Hostname](#hostname) array_ | Hostnames defines a set of hostnames that should match against the HTTP Host
header to select a HTTPRoute used to process the request. Implementations
MUST ignore any port value specified in the HTTP Host header while
performing a match and (absent of any applicable header modification
configuration) MUST forward this header unmodified to the backend.
Valid values for Hostnames are determined by 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.
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,
`*.example.com`, `test.example.com`, and `foo.test.example.com` would
all match. On the other hand, `example.com` and `test.example.net` would
not match.
Hostnames that are prefixed with a wildcard label (`*.`) are interpreted
as a suffix match. That means that a match for `*.example.com` would match
both `test.example.com`, and `foo.test.example.com`, but not `example.com`.
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.
In the event that multiple HTTPRoutes specify intersecting hostnames (e.g.
overlapping wildcard matching and exact matching hostnames), precedence must
be given to rules from the HTTPRoute with the largest number of:
* Characters in a matching non-wildcard hostname.
* Characters in a matching hostname.
If ties exist across multiple Routes, the matching precedence rules for
HTTPRouteMatches takes over.
Support: Core | | MaxItems: 16
MaxLength: 253
MinLength: 1
Pattern: `^(\*\.)?[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$`
| +| `rules` _[HTTPRouteRule](#httprouterule) array_ | Rules are a list of HTTP matchers, filters and actions.
| + + +#### HTTPRouteStatus + + + +HTTPRouteStatus defines the observed state of HTTPRoute. + + + +_Appears in:_ +- [HTTPRoute](#httproute) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `parents` _[RouteParentStatus](#routeparentstatus) array_ | 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. | | MaxItems: 32
| + + +#### HTTPRouteTimeouts + + + +HTTPRouteTimeouts defines timeouts that can be configured for an HTTPRoute. +Timeout values are represented with Gateway API Duration formatting. + + + +_Appears in:_ +- [HTTPRouteRule](#httprouterule) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `request` _[Duration](#duration)_ | Request specifies the maximum duration for a gateway to respond to an HTTP request.
If the gateway has not been able to respond before this deadline is met, the gateway
MUST return a timeout error.
For example, setting the `rules.timeouts.request` field to the value `10s` in an
`HTTPRoute` will cause a timeout if a client request is taking longer than 10 seconds
to complete.
Setting a timeout to the zero duration (e.g. "0s") SHOULD disable the timeout
completely. Implementations that cannot completely disable the timeout MUST
instead interpret the zero duration as the longest possible value to which
the timeout can be set.
This timeout is intended to cover as close to the whole request-response transaction
as possible although an implementation MAY choose to start the timeout after the entire
request stream has been received instead of immediately after the transaction is
initiated by the client.
The value of Request is a Gateway API Duration string as defined by GEP-2257. When this
field is unspecified, request timeout behavior is implementation-specific.
Support: Extended | | Pattern: `^([0-9]\{1,5\}(h\|m\|s\|ms))\{1,4\}$`
| +| `backendRequest` _[Duration](#duration)_ | BackendRequest specifies a timeout for an individual request from the gateway
to a backend. This covers the time from when the request first starts being
sent from the gateway to when the full response has been received from the backend.
Setting a timeout to the zero duration (e.g. "0s") SHOULD disable the timeout
completely. Implementations that cannot completely disable the timeout MUST
instead interpret the zero duration as the longest possible value to which
the timeout can be set.
An entire client HTTP transaction with a gateway, covered by the Request timeout,
may result in more than one call from the gateway to the destination backend,
for example, if automatic retries are supported.
The value of BackendRequest must be a Gateway API Duration string as defined by
GEP-2257. When this field is unspecified, its behavior is implementation-specific;
when specified, the value of BackendRequest must be no more than the value of the
Request timeout (since the Request timeout encompasses the BackendRequest timeout).
Support: Extended | | Pattern: `^([0-9]\{1,5\}(h\|m\|s\|ms))\{1,4\}$`
| + + +#### HTTPURLRewriteFilter + + + +HTTPURLRewriteFilter defines a filter that modifies a request during +forwarding. At most one of these filters may be used on a Route rule. This +MUST NOT be used on the same Route rule as a HTTPRequestRedirect filter. + +Support: Extended + + + +_Appears in:_ +- [HTTPRouteFilter](#httproutefilter) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `hostname` _[PreciseHostname](#precisehostname)_ | Hostname is the value to be used to replace the Host header value during
forwarding.
Support: Extended | | MaxLength: 253
MinLength: 1
Pattern: `^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$`
| +| `path` _[HTTPPathModifier](#httppathmodifier)_ | Path defines a path rewrite.
Support: Extended | | | + + +#### HeaderMatchType + +_Underlying type:_ _string_ + +HeaderMatchType specifies the semantics of how HTTP header values should be +compared. Valid HeaderMatchType values, along with their conformance levels, are: + +* "Exact" - Core +* "RegularExpression" - Implementation Specific + +Note that values may be added to this enum, implementations +must ensure that unknown values will not cause a crash. + +Unknown values here must result in the implementation setting the +Accepted Condition for the Route to `status: False`, with a +Reason of `UnsupportedValue`. + +_Validation:_ +- Enum: [Exact RegularExpression] + +_Appears in:_ +- [HTTPHeaderMatch](#httpheadermatch) + +| Field | Description | +| --- | --- | +| `Exact` | | +| `RegularExpression` | | + + +#### HeaderName + +_Underlying type:_ _string_ + +HeaderName is the name of a header or query parameter. + +_Validation:_ +- MaxLength: 256 +- MinLength: 1 +- Pattern: `^[A-Za-z0-9!#$%&'*+\-.^_\x60|~]+$` + +_Appears in:_ +- [GRPCHeaderName](#grpcheadername) +- [HTTPHeaderName](#httpheadername) + + + +#### Hostname + +_Underlying type:_ _string_ + +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. + +_Validation:_ +- MaxLength: 253 +- MinLength: 1 +- Pattern: `^(\*\.)?[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$` + +_Appears in:_ +- [GRPCRouteSpec](#grpcroutespec) +- [HTTPRouteSpec](#httproutespec) +- [Listener](#listener) +- [SubjectAltName](#subjectaltname) + + + +#### Kind + +_Underlying type:_ _string_ + +Kind refers to a Kubernetes Kind. + +Valid values include: + +* "Service" +* "HTTPRoute" + +Invalid values include: + +* "invalid/kind" - "/" is an invalid character + +_Validation:_ +- MaxLength: 63 +- MinLength: 1 +- Pattern: `^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$` + +_Appears in:_ +- [BackendObjectReference](#backendobjectreference) +- [BackendRef](#backendref) +- [GRPCBackendRef](#grpcbackendref) +- [HTTPBackendRef](#httpbackendref) +- [LocalObjectReference](#localobjectreference) +- [LocalParametersReference](#localparametersreference) +- [ObjectReference](#objectreference) +- [ParametersReference](#parametersreference) +- [ParentReference](#parentreference) +- [RouteGroupKind](#routegroupkind) +- [SecretObjectReference](#secretobjectreference) + + + +#### LabelKey + +_Underlying type:_ _string_ + +LabelKey is the key of a label in the Gateway API. This is used for validation +of maps such as Gateway infrastructure labels. This matches the Kubernetes +"qualified name" validation that is used for labels. + +Valid values include: + +* example +* example.com +* example.com/path +* example.com/path.html + +Invalid values include: + +* example~ - "~" is an invalid character +* example.com. - cannot start or end with "." + +_Validation:_ +- MaxLength: 253 +- MinLength: 1 +- Pattern: `^([a-z0-9]([-a-z0-9]*[a-z0-9])?(\\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*/)?([A-Za-z0-9][-A-Za-z0-9_.]{0,61})?[A-Za-z0-9]$` + +_Appears in:_ +- [GatewayInfrastructure](#gatewayinfrastructure) + + + +#### LabelValue + +_Underlying type:_ _string_ + +LabelValue is the value of a label in the Gateway API. This is used for validation +of maps such as Gateway infrastructure labels. This matches the Kubernetes +label validation rules: +* must be 63 characters or less (can be empty), +* unless empty, must begin and end with an alphanumeric character ([a-z0-9A-Z]), +* could contain dashes (-), underscores (_), dots (.), and alphanumerics between. + +Valid values include: + +* MyValue +* my.name +* 123-my-value + +_Validation:_ +- MaxLength: 63 +- MinLength: 0 +- Pattern: `^(([A-Za-z0-9][-A-Za-z0-9_.]*)?[A-Za-z0-9])?$` + +_Appears in:_ +- [GatewayInfrastructure](#gatewayinfrastructure) + + + +#### Listener + + + +Listener embodies the concept of a logical endpoint where a Gateway accepts +network connections. + + + +_Appears in:_ +- [GatewaySpec](#gatewayspec) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `name` _[SectionName](#sectionname)_ | Name is the name of the Listener. This name MUST be unique within a
Gateway.
Support: Core | | MaxLength: 253
MinLength: 1
Pattern: `^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$`
| +| `hostname` _[Hostname](#hostname)_ | 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 both the SNI and Host header.
Note that this does not require the SNI and Host header to be the same.
The semantics of this are described in more detail below.
To ensure security, Section 11.1 of RFC-6066 emphasizes that server
implementations that rely on SNI hostname matching MUST also verify
hostnames within the application protocol.
Section 9.1.2 of RFC-7540 provides a mechanism for servers to reject the
reuse of a connection by responding with the HTTP 421 Misdirected Request
status code. This indicates that the origin server has rejected the
request because it appears to have been misdirected.
To detect misdirected requests, Gateways SHOULD match the authority of
the requests with all the SNI hostname(s) configured across all the
Gateway Listeners on the same port and protocol:
* If another Listener has an exact match or more specific wildcard entry,
the Gateway SHOULD return a 421.
* If the current Listener (selected by SNI matching during ClientHello)
does not match the Host:
* If another Listener does match the Host the Gateway SHOULD return a
421.
* If no other Listener matches the Host, the Gateway MUST return a
404.
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.
Hostnames that are prefixed with a wildcard label (`*.`) are interpreted
as a suffix match. That means that a match for `*.example.com` would match
both `test.example.com`, and `foo.test.example.com`, but not `example.com`.
Support: Core | | MaxLength: 253
MinLength: 1
Pattern: `^(\*\.)?[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$`
| +| `port` _[PortNumber](#portnumber)_ | Port is the network port. Multiple listeners may use the
same port, subject to the Listener compatibility rules.
Support: Core | | Maximum: 65535
Minimum: 1
| +| `protocol` _[ProtocolType](#protocoltype)_ | Protocol specifies the network protocol this listener expects to receive.
Support: Core | | MaxLength: 255
MinLength: 1
Pattern: `^[a-zA-Z0-9]([-a-zA-Z0-9]*[a-zA-Z0-9])?$\|[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*\/[A-Za-z0-9]+$`
| +| `tls` _[GatewayTLSConfig](#gatewaytlsconfig)_ | 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](#allowedroutes)_ | 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 | \{ namespaces:map[from:Same] \} | | + + + + + + +#### ListenerNamespaces + + + +ListenerNamespaces indicate which namespaces ListenerSets should be selected from. + + + +_Appears in:_ +- [AllowedListeners](#allowedlisteners) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `from` _[FromNamespaces](#fromnamespaces)_ | From indicates where ListenerSets can attach to this Gateway. Possible
values are:
* Same: Only ListenerSets in the same namespace may be attached to this Gateway.
* Selector: ListenerSets in namespaces selected by the selector may be attached to this Gateway.
* All: ListenerSets in all namespaces may be attached to this Gateway.
* None: Only listeners defined in the Gateway's spec are allowed
While this feature is experimental, the default value None | None | Enum: [All Selector Same None]
| +| `selector` _[LabelSelector](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#labelselector-v1-meta)_ | Selector must be specified when From is set to "Selector". In that case,
only ListenerSets in Namespaces matching this Selector will be selected by this
Gateway. This field is ignored for other values of "From". | | | + + +#### ListenerStatus + + + +ListenerStatus is the status associated with a Listener. + + + +_Appears in:_ +- [GatewayStatus](#gatewaystatus) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `name` _[SectionName](#sectionname)_ | Name is the name of the Listener that this status corresponds to. | | MaxLength: 253
MinLength: 1
Pattern: `^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$`
| +| `supportedKinds` _[RouteGroupKind](#routegroupkind) array_ | 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. | | MaxItems: 8
| +| `attachedRoutes` _integer_ | AttachedRoutes represents the total number of Routes that have been
successfully attached to this Listener.
Successful attachment of a Route to a Listener is based solely on the
combination of the AllowedRoutes field on the corresponding Listener
and the Route's ParentRefs field. A Route is successfully attached to
a Listener when it is selected by the Listener's AllowedRoutes field
AND the Route has a valid ParentRef selecting the whole Gateway
resource or a specific Listener as a parent resource (more detail on
attachment semantics can be found in the documentation on the various
Route kinds ParentRefs fields). Listener or Route status does not impact
successful attachment, i.e. the AttachedRoutes field count MUST be set
for Listeners with condition Accepted: false and MUST count successfully
attached Routes that may themselves have Accepted: false conditions.
Uses for this field include troubleshooting Route attachment and
measuring blast radius/impact of changes to a Listener. | | | +| `conditions` _[Condition](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#condition-v1-meta) array_ | Conditions describe the current condition of this listener. | | MaxItems: 8
| + + +#### LocalObjectReference + + + +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. + + + +_Appears in:_ +- [BackendTLSPolicyValidation](#backendtlspolicyvalidation) +- [GRPCRouteFilter](#grpcroutefilter) +- [HTTPRouteFilter](#httproutefilter) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `group` _[Group](#group)_ | Group is the group of the referent. For example, "gateway.networking.k8s.io".
When unspecified or empty string, core API group is inferred. | | MaxLength: 253
Pattern: `^$\|^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$`
| +| `kind` _[Kind](#kind)_ | Kind is kind of the referent. For example "HTTPRoute" or "Service". | | MaxLength: 63
MinLength: 1
Pattern: `^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$`
| +| `name` _[ObjectName](#objectname)_ | Name is the name of the referent. | | MaxLength: 253
MinLength: 1
| + + +#### LocalParametersReference + + + +LocalParametersReference identifies an API object containing controller-specific +configuration resource within the namespace. + + + +_Appears in:_ +- [GatewayInfrastructure](#gatewayinfrastructure) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `group` _[Group](#group)_ | Group is the group of the referent. | | MaxLength: 253
Pattern: `^$\|^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$`
| +| `kind` _[Kind](#kind)_ | Kind is kind of the referent. | | MaxLength: 63
MinLength: 1
Pattern: `^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$`
| +| `name` _string_ | Name is the name of the referent. | | MaxLength: 253
MinLength: 1
| + + +#### Namespace + +_Underlying type:_ _string_ + +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 + +_Validation:_ +- MaxLength: 63 +- MinLength: 1 +- Pattern: `^[a-z0-9]([-a-z0-9]*[a-z0-9])?$` + +_Appears in:_ +- [BackendObjectReference](#backendobjectreference) +- [BackendRef](#backendref) +- [GRPCBackendRef](#grpcbackendref) +- [HTTPBackendRef](#httpbackendref) +- [ObjectReference](#objectreference) +- [ParametersReference](#parametersreference) +- [ParentReference](#parentreference) +- [SecretObjectReference](#secretobjectreference) + + + +#### ObjectName + +_Underlying type:_ _string_ + +ObjectName refers to the name of a Kubernetes object. +Object names can have a variety of forms, including RFC 1123 subdomains, +RFC 1123 labels, or RFC 1035 labels. + +_Validation:_ +- MaxLength: 253 +- MinLength: 1 + +_Appears in:_ +- [BackendObjectReference](#backendobjectreference) +- [BackendRef](#backendref) +- [GRPCBackendRef](#grpcbackendref) +- [GatewaySpec](#gatewayspec) +- [HTTPBackendRef](#httpbackendref) +- [LocalObjectReference](#localobjectreference) +- [ObjectReference](#objectreference) +- [ParentReference](#parentreference) +- [SecretObjectReference](#secretobjectreference) + + + +#### ObjectReference + + + +ObjectReference identifies an API object including its namespace. + +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. + + + +_Appears in:_ +- [FrontendTLSValidation](#frontendtlsvalidation) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `group` _[Group](#group)_ | Group is the group of the referent. For example, "gateway.networking.k8s.io".
When set to the empty string, core API group is inferred. | | MaxLength: 253
Pattern: `^$\|^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$`
| +| `kind` _[Kind](#kind)_ | Kind is kind of the referent. For example "ConfigMap" or "Service". | | MaxLength: 63
MinLength: 1
Pattern: `^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$`
| +| `name` _[ObjectName](#objectname)_ | Name is the name of the referent. | | MaxLength: 253
MinLength: 1
| +| `namespace` _[Namespace](#namespace)_ | Namespace is the namespace of the referenced object. When unspecified, the local
namespace is inferred.
Note that when a namespace different than the local namespace is specified,
a ReferenceGrant object is required in the referent namespace to allow that
namespace's owner to accept the reference. See the ReferenceGrant
documentation for details.
Support: Core | | MaxLength: 63
MinLength: 1
Pattern: `^[a-z0-9]([-a-z0-9]*[a-z0-9])?$`
| + + +#### ParametersReference + + + +ParametersReference identifies an API object containing controller-specific +configuration resource within the cluster. + + + +_Appears in:_ +- [GatewayClassSpec](#gatewayclassspec) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `group` _[Group](#group)_ | Group is the group of the referent. | | MaxLength: 253
Pattern: `^$\|^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$`
| +| `kind` _[Kind](#kind)_ | Kind is kind of the referent. | | MaxLength: 63
MinLength: 1
Pattern: `^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$`
| +| `name` _string_ | Name is the name of the referent. | | MaxLength: 253
MinLength: 1
| +| `namespace` _[Namespace](#namespace)_ | 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. | | MaxLength: 63
MinLength: 1
Pattern: `^[a-z0-9]([-a-z0-9]*[a-z0-9])?$`
| + + +#### ParentReference + + + +ParentReference identifies an API object (usually a Gateway) that can be considered +a parent of this resource (usually a route). There are two kinds of parent resources +with "Core" support: + +* Gateway (Gateway conformance profile) +* Service (Mesh conformance profile, ClusterIP Services only) + +This API may be extended in the future to support additional kinds of parent +resources. + +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. + + + +_Appears in:_ +- [CommonRouteSpec](#commonroutespec) +- [GRPCRouteSpec](#grpcroutespec) +- [HTTPRouteSpec](#httproutespec) +- [RouteParentStatus](#routeparentstatus) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `group` _[Group](#group)_ | Group is the group of the referent.
When unspecified, "gateway.networking.k8s.io" is inferred.
To set the core API group (such as for a "Service" kind referent),
Group must be explicitly set to "" (empty string).
Support: Core | gateway.networking.k8s.io | MaxLength: 253
Pattern: `^$\|^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$`
| +| `kind` _[Kind](#kind)_ | Kind is kind of the referent.
There are two kinds of parent resources with "Core" support:
* Gateway (Gateway conformance profile)
* Service (Mesh conformance profile, ClusterIP Services only)
Support for other resources is Implementation-Specific. | Gateway | MaxLength: 63
MinLength: 1
Pattern: `^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$`
| +| `namespace` _[Namespace](#namespace)_ | Namespace is the namespace of the referent. When unspecified, this refers
to the local namespace of the Route.
Note that there are specific rules for ParentRefs which cross namespace
boundaries. Cross-namespace references are only valid if they are explicitly
allowed by something in the namespace they are referring to. For example:
Gateway has the AllowedRoutes field, and ReferenceGrant provides a
generic way to enable any other kind of cross-namespace reference.
ParentRefs from a Route to a Service in the same namespace are "producer"
routes, which apply default routing rules to inbound connections from
any namespace to the Service.
ParentRefs from a Route to a Service in a different namespace are
"consumer" routes, and these routing rules are only applied to outbound
connections originating from the same namespace as the Route, for which
the intended destination of the connections are a Service targeted as a
ParentRef of the Route.
Support: Core | | MaxLength: 63
MinLength: 1
Pattern: `^[a-z0-9]([-a-z0-9]*[a-z0-9])?$`
| +| `name` _[ObjectName](#objectname)_ | Name is the name of the referent.
Support: Core | | MaxLength: 253
MinLength: 1
| +| `sectionName` _[SectionName](#sectionname)_ | SectionName is the name of a section within the target resource. In the
following resources, SectionName is interpreted as the following:
* Gateway: Listener name. When both Port (experimental) and SectionName
are specified, the name and port of the selected listener must match
both specified values.
* Service: Port name. When both Port (experimental) and SectionName
are specified, the name and port of the selected listener must match
both specified values.
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 | | MaxLength: 253
MinLength: 1
Pattern: `^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$`
| +| `port` _[PortNumber](#portnumber)_ | Port is the network port this Route targets. It can be interpreted
differently based on the type of parent resource.
When the parent resource is a Gateway, this targets all listeners
listening on the specified port that also support this kind of Route(and
select this Route). It's not recommended to set `Port` unless the
networking behaviors specified in a Route must apply to a specific port
as opposed to a listener(s) whose port(s) may be changed. When both Port
and SectionName are specified, the name and port of the selected listener
must match both specified values.
When the parent resource is a Service, this targets a specific port in the
Service spec. When both Port (experimental) and SectionName are specified,
the name and port of the selected port must match both specified values.
Implementations MAY choose to support other parent resources.
Implementations supporting other types of parent resources MUST clearly
document how/if Port is interpreted.
For the purpose of status, an attachment is considered successful as
long as the parent resource accepts it partially. 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: Extended | | Maximum: 65535
Minimum: 1
| + + +#### PathMatchType + +_Underlying type:_ _string_ + +PathMatchType specifies the semantics of how HTTP paths should be compared. +Valid PathMatchType values, along with their support levels, are: + +* "Exact" - Core +* "PathPrefix" - Core +* "RegularExpression" - Implementation Specific + +PathPrefix and Exact paths must be syntactically valid: + +- Must begin with the `/` character +- Must not contain consecutive `/` characters (e.g. `/foo///`, `//`). + +Note that values may be added to this enum, implementations +must ensure that unknown values will not cause a crash. + +Unknown values here must result in the implementation setting the +Accepted Condition for the Route to `status: False`, with a +Reason of `UnsupportedValue`. + +_Validation:_ +- Enum: [Exact PathPrefix RegularExpression] + +_Appears in:_ +- [HTTPPathMatch](#httppathmatch) + +| Field | Description | +| --- | --- | +| `Exact` | Matches the URL path exactly and with case sensitivity. This means that
an exact path match on `/abc` will only match requests to `/abc`, NOT
`/abc/`, `/Abc`, or `/abcd`.
| +| `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 implementation-specific conformance,
implementations can support POSIX, PCRE, RE2 or any other regular expression
dialect.
Please read the implementation's documentation to determine the supported
dialect.
| + + +#### PortNumber + +_Underlying type:_ _integer_ + +PortNumber defines a network port. + +_Validation:_ +- Maximum: 65535 +- Minimum: 1 + +_Appears in:_ +- [BackendObjectReference](#backendobjectreference) +- [BackendRef](#backendref) +- [GRPCBackendRef](#grpcbackendref) +- [HTTPBackendRef](#httpbackendref) +- [HTTPRequestRedirectFilter](#httprequestredirectfilter) +- [Listener](#listener) +- [ParentReference](#parentreference) + + + +#### PreciseHostname + +_Underlying type:_ _string_ + +PreciseHostname is the fully qualified domain name of a network host. This +matches the RFC 1123 definition of a hostname with 1 notable exception that +numeric IP addresses are not allowed. + +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. + +_Validation:_ +- MaxLength: 253 +- MinLength: 1 +- Pattern: `^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$` + +_Appears in:_ +- [BackendTLSPolicyValidation](#backendtlspolicyvalidation) +- [HTTPRequestRedirectFilter](#httprequestredirectfilter) +- [HTTPURLRewriteFilter](#httpurlrewritefilter) + + + +#### ProtocolType + +_Underlying type:_ _string_ + +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 MUST set the +"Accepted" condition to False 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 +Implementation-specific 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 + +_Validation:_ +- MaxLength: 255 +- MinLength: 1 +- Pattern: `^[a-zA-Z0-9]([-a-zA-Z0-9]*[a-zA-Z0-9])?$|[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*\/[A-Za-z0-9]+$` + +_Appears in:_ +- [Listener](#listener) + +| Field | 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.
| +| `TLS` | Accepts TLS sessions over TCP.
| +| `TCP` | Accepts TCP sessions.
| +| `UDP` | Accepts UDP packets.
| + + +#### QueryParamMatchType + +_Underlying type:_ _string_ + +QueryParamMatchType specifies the semantics of how HTTP query parameter +values should be compared. Valid QueryParamMatchType values, along with their +conformance levels, are: + +* "Exact" - Core +* "RegularExpression" - Implementation Specific + +Note that values may be added to this enum, implementations +must ensure that unknown values will not cause a crash. + +Unknown values here must result in the implementation setting the +Accepted Condition for the Route to `status: False`, with a +Reason of `UnsupportedValue`. + +_Validation:_ +- Enum: [Exact RegularExpression] + +_Appears in:_ +- [HTTPQueryParamMatch](#httpqueryparammatch) + +| Field | Description | +| --- | --- | +| `Exact` | | +| `RegularExpression` | | + + + + + + +#### RouteGroupKind + + + +RouteGroupKind indicates the group and kind of a Route resource. + + + +_Appears in:_ +- [AllowedRoutes](#allowedroutes) +- [ListenerStatus](#listenerstatus) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `group` _[Group](#group)_ | Group is the group of the Route. | gateway.networking.k8s.io | MaxLength: 253
Pattern: `^$\|^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$`
| +| `kind` _[Kind](#kind)_ | Kind is the kind of the Route. | | MaxLength: 63
MinLength: 1
Pattern: `^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$`
| + + +#### RouteNamespaces + + + +RouteNamespaces indicate which namespaces Routes should be selected from. + + + +_Appears in:_ +- [AllowedRoutes](#allowedroutes) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `from` _[FromNamespaces](#fromnamespaces)_ | 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 | Same | Enum: [All Selector Same]
| +| `selector` _[LabelSelector](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#labelselector-v1-meta)_ | 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 + + + +RouteParentStatus describes the status of a route with respect to an +associated Parent. + + + +_Appears in:_ +- [GRPCRouteStatus](#grpcroutestatus) +- [HTTPRouteStatus](#httproutestatus) +- [RouteStatus](#routestatus) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `parentRef` _[ParentReference](#parentreference)_ | ParentRef corresponds with a ParentRef in the spec that this
RouteParentStatus struct describes the status of. | | | +| `controllerName` _[GatewayController](#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).
Controllers MUST populate this field when writing status. Controllers should ensure that
entries to status populated with their ControllerName are cleaned up when they are no
longer necessary. | | MaxLength: 253
MinLength: 1
Pattern: `^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*\/[A-Za-z0-9\/\-._~%!$&'()*+,;=:]+$`
| +| `conditions` _[Condition](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#condition-v1-meta) array_ | 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 nonexistent parent.
* The Route is of a type that the controller does not support.
* The Route is in a namespace the controller does not have access to. | | MaxItems: 8
MinItems: 1
| + + +#### RouteStatus + + + +RouteStatus defines the common attributes that all Routes MUST include within +their status. + + + +_Appears in:_ +- [GRPCRouteStatus](#grpcroutestatus) +- [HTTPRouteStatus](#httproutestatus) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `parents` _[RouteParentStatus](#routeparentstatus) array_ | 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. | | MaxItems: 32
| + + +#### 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. + + + +_Appears in:_ +- [GatewayBackendTLS](#gatewaybackendtls) +- [GatewayTLSConfig](#gatewaytlsconfig) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `group` _[Group](#group)_ | Group is the group of the referent. For example, "gateway.networking.k8s.io".
When unspecified or empty string, core API group is inferred. | | MaxLength: 253
Pattern: `^$\|^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$`
| +| `kind` _[Kind](#kind)_ | Kind is kind of the referent. For example "Secret". | Secret | MaxLength: 63
MinLength: 1
Pattern: `^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$`
| +| `name` _[ObjectName](#objectname)_ | Name is the name of the referent. | | MaxLength: 253
MinLength: 1
| +| `namespace` _[Namespace](#namespace)_ | Namespace is the namespace of the referenced object. When unspecified, the local
namespace is inferred.
Note that when a namespace different than the local namespace is specified,
a ReferenceGrant object is required in the referent namespace to allow that
namespace's owner to accept the reference. See the ReferenceGrant
documentation for details.
Support: Core | | MaxLength: 63
MinLength: 1
Pattern: `^[a-z0-9]([-a-z0-9]*[a-z0-9])?$`
| + + +#### SectionName + +_Underlying type:_ _string_ + +SectionName is the name of a section in a Kubernetes resource. + +In the following resources, SectionName is interpreted as the following: + +* Gateway: Listener name +* HTTPRoute: HTTPRouteRule name +* Service: Port name + +Section names can have a variety of forms, including RFC 1123 subdomains, +RFC 1123 labels, or RFC 1035 labels. + +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" +* "foo-example" +* "example.com" +* "foo.example.com" + +Invalid values include: + +* "example.com/bar" - "/" is an invalid character + +_Validation:_ +- MaxLength: 253 +- MinLength: 1 +- Pattern: `^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$` + +_Appears in:_ +- [GRPCRouteRule](#grpcrouterule) +- [HTTPRouteRule](#httprouterule) +- [Listener](#listener) +- [ListenerStatus](#listenerstatus) +- [ParentReference](#parentreference) + + + +#### SessionPersistence + + + +SessionPersistence defines the desired state of SessionPersistence. + + + +_Appears in:_ +- [GRPCRouteRule](#grpcrouterule) +- [HTTPRouteRule](#httprouterule) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `sessionName` _string_ | SessionName defines the name of the persistent session token
which may be reflected in the cookie or the header. Users
should avoid reusing session names to prevent unintended
consequences, such as rejection or unpredictable behavior.
Support: Implementation-specific | | MaxLength: 128
| +| `absoluteTimeout` _[Duration](#duration)_ | AbsoluteTimeout defines the absolute timeout of the persistent
session. Once the AbsoluteTimeout duration has elapsed, the
session becomes invalid.
Support: Extended | | Pattern: `^([0-9]\{1,5\}(h\|m\|s\|ms))\{1,4\}$`
| +| `idleTimeout` _[Duration](#duration)_ | IdleTimeout defines the idle timeout of the persistent session.
Once the session has been idle for more than the specified
IdleTimeout duration, the session becomes invalid.
Support: Extended | | Pattern: `^([0-9]\{1,5\}(h\|m\|s\|ms))\{1,4\}$`
| +| `type` _[SessionPersistenceType](#sessionpersistencetype)_ | Type defines the type of session persistence such as through
the use a header or cookie. Defaults to cookie based session
persistence.
Support: Core for "Cookie" type
Support: Extended for "Header" type | Cookie | Enum: [Cookie Header]
| +| `cookieConfig` _[CookieConfig](#cookieconfig)_ | CookieConfig provides configuration settings that are specific
to cookie-based session persistence.
Support: Core | | | + + +#### SessionPersistenceType + +_Underlying type:_ _string_ + + + +_Validation:_ +- Enum: [Cookie Header] + +_Appears in:_ +- [SessionPersistence](#sessionpersistence) + +| Field | Description | +| --- | --- | +| `Cookie` | CookieBasedSessionPersistence specifies cookie-based session
persistence.
Support: Core
| +| `Header` | HeaderBasedSessionPersistence specifies header-based session
persistence.
Support: Extended
| + + +#### SupportedFeature + + + + + + + +_Appears in:_ +- [GatewayClassStatus](#gatewayclassstatus) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `name` _[FeatureName](#featurename)_ | | | | + + +#### TLSModeType + +_Underlying type:_ _string_ + +TLSModeType type defines how a Gateway handles TLS sessions. + +_Validation:_ +- Enum: [Terminate Passthrough] + +_Appears in:_ +- [GatewayTLSConfig](#gatewaytlsconfig) + +| Field | Description | +| --- | --- | +| `Terminate` | In this mode, TLS session between the downstream client
and the Gateway is terminated at the Gateway.
| +| `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.
| + + +#### TrueField + +_Underlying type:_ _boolean_ + +TrueField is a boolean value that can only be set to true + +_Validation:_ +- Enum: [true] + +_Appears in:_ +- [HTTPCORSFilter](#httpcorsfilter) + + + + +## gateway.networking.k8s.io/v1alpha2 + +Package v1alpha2 contains API Schema definitions for the +gateway.networking.k8s.io API group. + + +### Resource Types +- [GRPCRoute](#grpcroute) +- [ReferenceGrant](#referencegrant) +- [TCPRoute](#tcproute) +- [TLSRoute](#tlsroute) +- [UDPRoute](#udproute) + + + + + + + + + + + + + + + + + +#### GRPCRoute + +_Underlying type:_ _[GRPCRoute](#grpcroute)_ + + + + + + + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `apiVersion` _string_ | `gateway.networking.k8s.io/v1alpha2` | | | +| `kind` _string_ | `GRPCRoute` | | | +| `metadata` _[ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#objectmeta-v1-meta)_ | Refer to Kubernetes API documentation for fields of `metadata`. | | | +| `spec` _[GRPCRouteSpec](#grpcroutespec)_ | Spec defines the desired state of GRPCRoute. | | | +| `status` _[GRPCRouteStatus](#grpcroutestatus)_ | Status defines the current state of GRPCRoute. | | | + + + + + + + + + + + + +#### LocalPolicyTargetReference + + + +LocalPolicyTargetReference identifies an API object to apply a direct or +inherited 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. + + + +_Appears in:_ +- [LocalPolicyTargetReferenceWithSectionName](#localpolicytargetreferencewithsectionname) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `group` _[Group](#group)_ | Group is the group of the target resource. | | MaxLength: 253
Pattern: `^$\|^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$`
| +| `kind` _[Kind](#kind)_ | Kind is kind of the target resource. | | MaxLength: 63
MinLength: 1
Pattern: `^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$`
| +| `name` _[ObjectName](#objectname)_ | Name is the name of the target resource. | | MaxLength: 253
MinLength: 1
| + + +#### LocalPolicyTargetReferenceWithSectionName + + + +LocalPolicyTargetReferenceWithSectionName identifies an API object to apply a +direct policy to. This should be used as part of Policy resources that can +target single resources. For more information on how this policy attachment +mode works, and a sample Policy resource, refer to the policy attachment +documentation for Gateway API. + +Note: This should only be used for direct policy attachment when references +to SectionName are actually needed. In all other cases, +LocalPolicyTargetReference should be used. + + + +_Appears in:_ +- [BackendTLSPolicySpec](#backendtlspolicyspec) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `group` _[Group](#group)_ | Group is the group of the target resource. | | MaxLength: 253
Pattern: `^$\|^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$`
| +| `kind` _[Kind](#kind)_ | Kind is kind of the target resource. | | MaxLength: 63
MinLength: 1
Pattern: `^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$`
| +| `name` _[ObjectName](#objectname)_ | Name is the name of the target resource. | | MaxLength: 253
MinLength: 1
| +| `sectionName` _[SectionName](#sectionname)_ | SectionName is the name of a section within the target resource. When
unspecified, this targetRef targets the entire resource. In the following
resources, SectionName is interpreted as the following:
* Gateway: Listener name
* HTTPRoute: HTTPRouteRule name
* Service: Port name
If a SectionName is specified, but does not exist on the targeted object,
the Policy must fail to attach, and the policy implementation should record
a `ResolvedRefs` or similar Condition in the Policy's status. | | MaxLength: 253
MinLength: 1
Pattern: `^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$`
| + + + + + + + + + + +#### PolicyAncestorStatus + + + +PolicyAncestorStatus describes the status of a route with respect to an +associated Ancestor. + +Ancestors refer to objects that are either the Target of a policy or above it +in terms of object hierarchy. For example, if a policy targets a Service, the +Policy's Ancestors are, in order, the Service, the HTTPRoute, the Gateway, and +the GatewayClass. Almost always, in this hierarchy, the Gateway will be the most +useful object to place Policy status on, so we recommend that implementations +SHOULD use Gateway as the PolicyAncestorStatus object unless the designers +have a _very_ good reason otherwise. + +In the context of policy attachment, the Ancestor is used to distinguish which +resource results in a distinct application of this policy. For example, if a policy +targets a Service, it may have a distinct result per attached Gateway. + +Policies targeting the same resource may have different effects depending on the +ancestors of those resources. For example, different Gateways targeting the same +Service may have different capabilities, especially if they have different underlying +implementations. + +For example, in BackendTLSPolicy, the Policy attaches to a Service that is +used as a backend in a HTTPRoute that is itself attached to a Gateway. +In this case, the relevant object for status is the Gateway, and that is the +ancestor object referred to in this status. + +Note that a parent is also an ancestor, so for objects where the parent is the +relevant object for status, this struct SHOULD still be used. + +This struct is intended to be used in a slice that's effectively a map, +with a composite key made up of the AncestorRef and the ControllerName. + + + +_Appears in:_ +- [PolicyStatus](#policystatus) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `ancestorRef` _[ParentReference](#parentreference)_ | AncestorRef corresponds with a ParentRef in the spec that this
PolicyAncestorStatus struct describes the status of. | | | +| `controllerName` _[GatewayController](#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).
Controllers MUST populate this field when writing status. Controllers should ensure that
entries to status populated with their ControllerName are cleaned up when they are no
longer necessary. | | MaxLength: 253
MinLength: 1
Pattern: `^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*\/[A-Za-z0-9\/\-._~%!$&'()*+,;=:]+$`
| +| `conditions` _[Condition](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#condition-v1-meta) array_ | Conditions describes the status of the Policy with respect to the given Ancestor. | | MaxItems: 8
MinItems: 1
| + + + + + + +#### PolicyStatus + + + +PolicyStatus defines the common attributes that all Policies should include within +their status. + + + +_Appears in:_ +- [BackendTLSPolicy](#backendtlspolicy) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `ancestors` _[PolicyAncestorStatus](#policyancestorstatus) array_ | Ancestors is a list of ancestor resources (usually Gateways) that are
associated with the policy, and the status of the policy with respect to
each ancestor. When this policy attaches to a parent, the controller that
manages the parent and the ancestors MUST add an entry to this list when
the controller first sees the policy and SHOULD update the entry as
appropriate when the relevant ancestor is modified.
Note that choosing the relevant ancestor is left to the Policy designers;
an important part of Policy design is designing the right object level at
which to namespace this status.
Note also that implementations MUST ONLY populate ancestor status for
the Ancestor resources they are responsible for. Implementations MUST
use the ControllerName field to uniquely identify the entries in this list
that they are responsible for.
Note that to achieve this, the list of PolicyAncestorStatus structs
MUST be treated as a map with a composite key, made up of the AncestorRef
and ControllerName fields combined.
A maximum of 16 ancestors will be represented in this list. An empty list
means the Policy is not relevant for any ancestors.
If this slice is full, implementations MUST NOT add further entries.
Instead they MUST consider the policy unimplementable and signal that
on any related resources such as the ancestor that would be referenced
here. For example, if this list was full on BackendTLSPolicy, no
additional Gateways would be able to reference the Service targeted by
the BackendTLSPolicy. | | MaxItems: 16
| + + + + + + +#### ReferenceGrant + +_Underlying type:_ _[ReferenceGrant](#referencegrant)_ + +ReferenceGrant 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 ReferenceGrant can be used to represent a unique trust relationship. +Additional Reference Grants can be used to add to the set of trusted +sources of inbound references for the namespace they are defined within. + +A ReferenceGrant is required for all cross-namespace references in Gateway API +(with the exception of cross-namespace Route-Gateway attachment, which is +governed by the AllowedRoutes configuration on the Gateway, and cross-namespace +Service ParentRefs on a "consumer" mesh Route, which defines routing rules +applicable only to workloads in the Route namespace). ReferenceGrants allowing +a reference from a Route to a Service are only applicable to BackendRefs. + +ReferenceGrant is a form of runtime verification allowing users to assert +which cross-namespace object references are permitted. Implementations that +support ReferenceGrant MUST NOT permit cross-namespace references which have +no grant, and MUST respond to the removal of a grant by revoking the access +that the grant allowed. + + + + + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `apiVersion` _string_ | `gateway.networking.k8s.io/v1alpha2` | | | +| `kind` _string_ | `ReferenceGrant` | | | +| `metadata` _[ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#objectmeta-v1-meta)_ | Refer to Kubernetes API documentation for fields of `metadata`. | | | +| `spec` _[ReferenceGrantSpec](#referencegrantspec)_ | Spec defines the desired state of ReferenceGrant. | | | + + + + + + + + + + + + + + + + + + + + + + +#### 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 | Default | Validation | +| --- | --- | --- | --- | +| `apiVersion` _string_ | `gateway.networking.k8s.io/v1alpha2` | | | +| `kind` _string_ | `TCPRoute` | | | +| `metadata` _[ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#objectmeta-v1-meta)_ | Refer to Kubernetes API documentation for fields of `metadata`. | | | +| `spec` _[TCPRouteSpec](#tcproutespec)_ | Spec defines the desired state of TCPRoute. | | | +| `status` _[TCPRouteStatus](#tcproutestatus)_ | Status defines the current state of TCPRoute. | | | + + +#### TCPRouteRule + + + +TCPRouteRule is the configuration for a given rule. + + + +_Appears in:_ +- [TCPRouteSpec](#tcproutespec) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `name` _[SectionName](#sectionname)_ | Name is the name of the route rule. This name MUST be unique within a Route if it is set.
Support: Extended | | MaxLength: 253
MinLength: 1
Pattern: `^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$`
| +| `backendRefs` _[BackendRef](#backendref) array_ | BackendRefs defines the backend(s) where matching requests should be
sent. If unspecified or invalid (refers to a nonexistent 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: Extended for Kubernetes ServiceImport
Support: Implementation-specific for any other resource
Support for weight: Extended | | MaxItems: 16
MinItems: 1
| + + +#### TCPRouteSpec + + + +TCPRouteSpec defines the desired state of TCPRoute + + + +_Appears in:_ +- [TCPRoute](#tcproute) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `rules` _[TCPRouteRule](#tcprouterule) array_ | Rules are a list of TCP matchers and actions.
MinItems: 1
| + + +#### TCPRouteStatus + + + +TCPRouteStatus defines the observed state of TCPRoute + + + +_Appears in:_ +- [TCPRoute](#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 | Default | Validation | +| --- | --- | --- | --- | +| `apiVersion` _string_ | `gateway.networking.k8s.io/v1alpha2` | | | +| `kind` _string_ | `TLSRoute` | | | +| `metadata` _[ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#objectmeta-v1-meta)_ | Refer to Kubernetes API documentation for fields of `metadata`. | | | +| `spec` _[TLSRouteSpec](#tlsroutespec)_ | Spec defines the desired state of TLSRoute. | | | +| `status` _[TLSRouteStatus](#tlsroutestatus)_ | Status defines the current state of TLSRoute. | | | + + +#### TLSRouteRule + + + +TLSRouteRule is the configuration for a given rule. + + + +_Appears in:_ +- [TLSRouteSpec](#tlsroutespec) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `name` _[SectionName](#sectionname)_ | Name is the name of the route rule. This name MUST be unique within a Route if it is set.
Support: Extended | | MaxLength: 253
MinLength: 1
Pattern: `^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$`
| +| `backendRefs` _[BackendRef](#backendref) array_ | BackendRefs defines the backend(s) where matching requests should be
sent. If unspecified or invalid (refers to a nonexistent 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 500 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: Extended for Kubernetes ServiceImport
Support: Implementation-specific for any other resource
Support for weight: Extended | | MaxItems: 16
MinItems: 1
| + + +#### TLSRouteSpec + + + +TLSRouteSpec defines the desired state of a TLSRoute resource. + + + +_Appears in:_ +- [TLSRoute](#tlsroute) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `hostnames` _[Hostname](#hostname) array_ | 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:
1. IPs are not allowed in SNI names per RFC 6066.
2. 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 | | MaxItems: 16
MaxLength: 253
MinLength: 1
Pattern: `^(\*\.)?[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$`
| +| `rules` _[TLSRouteRule](#tlsrouterule) array_ | Rules are a list of TLS matchers and actions.
MinItems: 1
| + + +#### TLSRouteStatus + + + +TLSRouteStatus defines the observed state of TLSRoute + + + +_Appears in:_ +- [TLSRoute](#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 | Default | Validation | +| --- | --- | --- | --- | +| `apiVersion` _string_ | `gateway.networking.k8s.io/v1alpha2` | | | +| `kind` _string_ | `UDPRoute` | | | +| `metadata` _[ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#objectmeta-v1-meta)_ | Refer to Kubernetes API documentation for fields of `metadata`. | | | +| `spec` _[UDPRouteSpec](#udproutespec)_ | Spec defines the desired state of UDPRoute. | | | +| `status` _[UDPRouteStatus](#udproutestatus)_ | Status defines the current state of UDPRoute. | | | + + +#### UDPRouteRule + + + +UDPRouteRule is the configuration for a given rule. + + + +_Appears in:_ +- [UDPRouteSpec](#udproutespec) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `name` _[SectionName](#sectionname)_ | Name is the name of the route rule. This name MUST be unique within a Route if it is set.
Support: Extended | | MaxLength: 253
MinLength: 1
Pattern: `^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$`
| +| `backendRefs` _[BackendRef](#backendref) array_ | BackendRefs defines the backend(s) where matching requests should be
sent. If unspecified or invalid (refers to a nonexistent 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: Extended for Kubernetes ServiceImport
Support: Implementation-specific for any other resource
Support for weight: Extended | | MaxItems: 16
MinItems: 1
| + + +#### UDPRouteSpec + + + +UDPRouteSpec defines the desired state of UDPRoute. + + + +_Appears in:_ +- [UDPRoute](#udproute) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `rules` _[UDPRouteRule](#udprouterule) array_ | Rules are a list of UDP matchers and actions.
MinItems: 1
| + + +#### UDPRouteStatus + + + +UDPRouteStatus defines the observed state of UDPRoute. + + + +_Appears in:_ +- [UDPRoute](#udproute) + + + + +## gateway.networking.k8s.io/v1alpha3 + +Package v1alpha3 contains API Schema definitions for the +gateway.networking.k8s.io API group. + + +### Resource Types +- [BackendTLSPolicy](#backendtlspolicy) + + + +#### BackendTLSPolicy + + + +BackendTLSPolicy provides a way to configure how a Gateway +connects to a Backend via TLS. + + + + + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `apiVersion` _string_ | `gateway.networking.k8s.io/v1alpha3` | | | +| `kind` _string_ | `BackendTLSPolicy` | | | +| `metadata` _[ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#objectmeta-v1-meta)_ | Refer to Kubernetes API documentation for fields of `metadata`. | | | +| `spec` _[BackendTLSPolicySpec](#backendtlspolicyspec)_ | Spec defines the desired state of BackendTLSPolicy. | | | +| `status` _[PolicyStatus](#policystatus)_ | Status defines the current state of BackendTLSPolicy. | | | + + +#### BackendTLSPolicySpec + + + +BackendTLSPolicySpec defines the desired state of BackendTLSPolicy. + +Support: Extended + + + +_Appears in:_ +- [BackendTLSPolicy](#backendtlspolicy) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `targetRefs` _[LocalPolicyTargetReferenceWithSectionName](#localpolicytargetreferencewithsectionname) array_ | TargetRefs identifies an API object to apply the policy to.
Only Services have Extended support. Implementations MAY support
additional objects, with Implementation Specific support.
Note that this config applies to the entire referenced resource
by default, but this default may change in the future to provide
a more granular application of the policy.
TargetRefs must be _distinct_. This means either that:
* They select different targets. If this is the case, then targetRef
entries are distinct. In terms of fields, this means that the
multi-part key defined by `group`, `kind`, and `name` must
be unique across all targetRef entries in the BackendTLSPolicy.
* They select different sectionNames in the same target.
Support: Extended for Kubernetes Service
Support: Implementation-specific for any other resource | | MaxItems: 16
MinItems: 1
| +| `validation` _[BackendTLSPolicyValidation](#backendtlspolicyvalidation)_ | Validation contains backend TLS validation configuration. | | | +| `options` _object (keys:[AnnotationKey](#annotationkey), values:[AnnotationValue](#annotationvalue))_ | 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 | | MaxProperties: 16
| + + +#### BackendTLSPolicyValidation + + + +BackendTLSPolicyValidation contains backend TLS validation configuration. + + + +_Appears in:_ +- [BackendTLSPolicySpec](#backendtlspolicyspec) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `caCertificateRefs` _[LocalObjectReference](#localobjectreference) array_ | CACertificateRefs contains one or more references to Kubernetes objects that
contain a PEM-encoded TLS CA certificate bundle, which is used to
validate a TLS handshake between the Gateway and backend Pod.
If CACertificateRefs is empty or unspecified, then WellKnownCACertificates must be
specified. Only one of CACertificateRefs or WellKnownCACertificates may be specified,
not both. If CACertificateRefs is empty or unspecified, the configuration for
WellKnownCACertificates MUST be honored instead if supported by the implementation.
References to a resource in a different namespace are invalid for the
moment, although we will revisit this in the future.
A single CACertificateRef to a Kubernetes ConfigMap kind has "Core" support.
Implementations MAY choose to support attaching multiple certificates to
a backend, but this behavior is implementation-specific.
Support: Core - An optional single reference to a Kubernetes ConfigMap,
with the CA certificate in a key named `ca.crt`.
Support: Implementation-specific (More than one reference, or other kinds
of resources). | | MaxItems: 8
| +| `wellKnownCACertificates` _[WellKnownCACertificatesType](#wellknowncacertificatestype)_ | WellKnownCACertificates specifies whether system CA certificates may be used in
the TLS handshake between the gateway and backend pod.
If WellKnownCACertificates is unspecified or empty (""), then CACertificateRefs
must be specified with at least one entry for a valid configuration. Only one of
CACertificateRefs or WellKnownCACertificates may be specified, not both. If an
implementation does not support the WellKnownCACertificates field or the value
supplied is not supported, the Status Conditions on the Policy MUST be
updated to include an Accepted: False Condition with Reason: Invalid.
Support: Implementation-specific | | Enum: [System]
| +| `hostname` _[PreciseHostname](#precisehostname)_ | Hostname is used for two purposes in the connection between Gateways and
backends:
1. Hostname MUST be used as the SNI to connect to the backend (RFC 6066).
2. Hostname MUST be used for authentication and MUST match the certificate served by the matching backend, unless SubjectAltNames is specified.
authentication and MUST match the certificate served by the matching
backend.
Support: Core | | MaxLength: 253
MinLength: 1
Pattern: `^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$`
| +| `subjectAltNames` _[SubjectAltName](#subjectaltname) array_ | SubjectAltNames contains one or more Subject Alternative Names.
When specified the certificate served from the backend MUST
have at least one Subject Alternate Name matching one of the specified SubjectAltNames.
Support: Extended | | MaxItems: 5
| + + +#### SubjectAltName + + + +SubjectAltName represents Subject Alternative Name. + + + +_Appears in:_ +- [BackendTLSPolicyValidation](#backendtlspolicyvalidation) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `type` _[SubjectAltNameType](#subjectaltnametype)_ | Type determines the format of the Subject Alternative Name. Always required.
Support: Core | | Enum: [Hostname URI]
| +| `hostname` _[Hostname](#hostname)_ | Hostname contains Subject Alternative Name specified in DNS name format.
Required when Type is set to Hostname, ignored otherwise.
Support: Core | | MaxLength: 253
MinLength: 1
Pattern: `^(\*\.)?[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$`
| +| `uri` _[AbsoluteURI](#absoluteuri)_ | URI contains Subject Alternative Name specified in a full URI format.
It MUST include both a scheme (e.g., "http" or "ftp") and a scheme-specific-part.
Common values include SPIFFE IDs like "spiffe://mycluster.example.com/ns/myns/sa/svc1sa".
Required when Type is set to URI, ignored otherwise.
Support: Core | | MaxLength: 253
MinLength: 1
Pattern: `^(([^:/?#]+):)(//([^/?#]*))([^?#]*)(\?([^#]*))?(#(.*))?`
| + + +#### SubjectAltNameType + +_Underlying type:_ _string_ + +SubjectAltNameType is the type of the Subject Alternative Name. + +_Validation:_ +- Enum: [Hostname URI] + +_Appears in:_ +- [SubjectAltName](#subjectaltname) + +| Field | Description | +| --- | --- | +| `Hostname` | HostnameSubjectAltNameType specifies hostname-based SAN.
Support: Core
| +| `URI` | URISubjectAltNameType specifies URI-based SAN, e.g. SPIFFE id.
Support: Core
| + + +#### WellKnownCACertificatesType + +_Underlying type:_ _string_ + +WellKnownCACertificatesType is the type of CA certificate that will be used +when the caCertificateRefs field is unspecified. + +_Validation:_ +- Enum: [System] + +_Appears in:_ +- [BackendTLSPolicyValidation](#backendtlspolicyvalidation) + +| Field | Description | +| --- | --- | +| `System` | WellKnownCACertificatesSystem indicates that well known system CA certificates should be used.
| + + + +## gateway.networking.k8s.io/v1beta1 + +Package v1beta1 contains API Schema definitions for the +gateway.networking.k8s.io API group. + + +### Resource Types +- [Gateway](#gateway) +- [GatewayClass](#gatewayclass) +- [HTTPRoute](#httproute) +- [ReferenceGrant](#referencegrant) + + + + + + + + + + + + + + + + + + + + + +#### Gateway + +_Underlying type:_ _[Gateway](#gateway)_ + +Gateway represents an instance of a service-traffic handling infrastructure +by binding Listeners to a set of IP addresses. + + + + + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `apiVersion` _string_ | `gateway.networking.k8s.io/v1beta1` | | | +| `kind` _string_ | `Gateway` | | | +| `metadata` _[ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#objectmeta-v1-meta)_ | Refer to Kubernetes API documentation for fields of `metadata`. | | | +| `spec` _[GatewaySpec](#gatewayspec)_ | Spec defines the desired state of Gateway. | | | +| `status` _[GatewayStatus](#gatewaystatus)_ | Status defines the current state of Gateway. | \{ conditions:[map[lastTransitionTime:1970-01-01T00:00:00Z message:Waiting for controller reason:Pending status:Unknown type:Accepted] map[lastTransitionTime:1970-01-01T00:00:00Z message:Waiting for controller reason:Pending status:Unknown type:Programmed]] \} | | + + +#### GatewayClass + +_Underlying type:_ _[GatewayClass](#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 SHOULD +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 | Default | Validation | +| --- | --- | --- | --- | +| `apiVersion` _string_ | `gateway.networking.k8s.io/v1beta1` | | | +| `kind` _string_ | `GatewayClass` | | | +| `metadata` _[ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#objectmeta-v1-meta)_ | Refer to Kubernetes API documentation for fields of `metadata`. | | | +| `spec` _[GatewayClassSpec](#gatewayclassspec)_ | Spec defines the desired state of GatewayClass. | | | +| `status` _[GatewayClassStatus](#gatewayclassstatus)_ | Status defines the current state of GatewayClass.
Implementations MUST populate status on all GatewayClass resources which
specify their controller name. | \{ conditions:[map[lastTransitionTime:1970-01-01T00:00:00Z message:Waiting for controller reason:Pending status:Unknown type:Accepted]] \} | | + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +#### HTTPRoute + +_Underlying type:_ _[HTTPRoute](#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 | Default | Validation | +| --- | --- | --- | --- | +| `apiVersion` _string_ | `gateway.networking.k8s.io/v1beta1` | | | +| `kind` _string_ | `HTTPRoute` | | | +| `metadata` _[ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#objectmeta-v1-meta)_ | Refer to Kubernetes API documentation for fields of `metadata`. | | | +| `spec` _[HTTPRouteSpec](#httproutespec)_ | Spec defines the desired state of HTTPRoute. | | | +| `status` _[HTTPRouteStatus](#httproutestatus)_ | Status defines the current state of HTTPRoute. | | | + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +#### ReferenceGrant + + + +ReferenceGrant 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 ReferenceGrant can be used to represent a unique trust relationship. +Additional Reference Grants 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 ReferenceGrant. + +ReferenceGrant is a form of runtime verification allowing users to assert +which cross-namespace object references are permitted. Implementations that +support ReferenceGrant MUST NOT permit cross-namespace references which have +no grant, and MUST respond to the removal of a grant by revoking the access +that the grant allowed. + + + +_Appears in:_ +- [ReferenceGrant](#referencegrant) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `apiVersion` _string_ | `gateway.networking.k8s.io/v1beta1` | | | +| `kind` _string_ | `ReferenceGrant` | | | +| `metadata` _[ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#objectmeta-v1-meta)_ | Refer to Kubernetes API documentation for fields of `metadata`. | | | +| `spec` _[ReferenceGrantSpec](#referencegrantspec)_ | Spec defines the desired state of ReferenceGrant. | | | + + +#### ReferenceGrantFrom + + + +ReferenceGrantFrom describes trusted namespaces and kinds. + + + +_Appears in:_ +- [ReferenceGrantSpec](#referencegrantspec) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `group` _[Group](#group)_ | Group is the group of the referent.
When empty, the Kubernetes core API group is inferred.
Support: Core | | MaxLength: 253
Pattern: `^$\|^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$`
| +| `kind` _[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.
When used to permit a SecretObjectReference:
* Gateway
When used to permit a BackendObjectReference:
* GRPCRoute
* HTTPRoute
* TCPRoute
* TLSRoute
* UDPRoute | | MaxLength: 63
MinLength: 1
Pattern: `^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$`
| +| `namespace` _[Namespace](#namespace)_ | Namespace is the namespace of the referent.
Support: Core | | MaxLength: 63
MinLength: 1
Pattern: `^[a-z0-9]([-a-z0-9]*[a-z0-9])?$`
| + + +#### ReferenceGrantSpec + + + +ReferenceGrantSpec identifies a cross namespace relationship that is trusted +for Gateway API. + + + +_Appears in:_ +- [ReferenceGrant](#referencegrant) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `from` _[ReferenceGrantFrom](#referencegrantfrom) array_ | 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 | | MaxItems: 16
MinItems: 1
| +| `to` _[ReferenceGrantTo](#referencegrantto) array_ | 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 | | MaxItems: 16
MinItems: 1
| + + +#### ReferenceGrantTo + + + +ReferenceGrantTo describes what Kinds are allowed as targets of the +references. + + + +_Appears in:_ +- [ReferenceGrantSpec](#referencegrantspec) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `group` _[Group](#group)_ | Group is the group of the referent.
When empty, the Kubernetes core API group is inferred.
Support: Core | | MaxLength: 253
Pattern: `^$\|^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$`
| +| `kind` _[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:
* Secret when used to permit a SecretObjectReference
* Service when used to permit a BackendObjectReference | | MaxLength: 63
MinLength: 1
Pattern: `^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$`
| +| `name` _[ObjectName](#objectname)_ | Name is the name of the referent. When unspecified, this policy
refers to all resources of the specified Group and Kind in the local
namespace. | | MaxLength: 253
MinLength: 1
| + + + + + + + + + + + + + + + + + + + + diff --git a/site-src/ko/reference/specx.md b/site-src/ko/reference/specx.md new file mode 100644 index 0000000000..d234d9750f --- /dev/null +++ b/site-src/ko/reference/specx.md @@ -0,0 +1,263 @@ +# API Reference + +## Packages +- [gateway.networking.x-k8s.io/v1alpha1](#gatewaynetworkingx-k8siov1alpha1) + + +## gateway.networking.x-k8s.io/v1alpha1 + +Package v1alpha1 contains API Schema definitions for the gateway.networking.k8s-x.io +API group. + + +### Resource Types +- [XBackendTrafficPolicy](#xbackendtrafficpolicy) +- [XListenerSet](#xlistenerset) + + + + + +#### BackendTrafficPolicySpec + + + +BackendTrafficPolicySpec define the desired state of BackendTrafficPolicy +Note: there is no Override or Default policy configuration. + + + +_Appears in:_ +- [XBackendTrafficPolicy](#xbackendtrafficpolicy) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `targetRefs` _[LocalPolicyTargetReference](#localpolicytargetreference) array_ | TargetRefs identifies API object(s) to apply this policy to.
Currently, Backends (A grouping of like endpoints such as Service,
ServiceImport, or any implementation-specific backendRef) are the only
valid API target references.
Currently, a TargetRef can not be scoped to a specific port on a
Service. | | MaxItems: 16
MinItems: 1
| +| `retryConstraint` _[RetryConstraint](#retryconstraint)_ | RetryConstraint defines the configuration for when to allow or prevent
further retries to a target backend, by dynamically calculating a 'retry
budget'. This budget is calculated based on the percentage of incoming
traffic composed of retries over a given time interval. Once the budget
is exceeded, additional retries will be rejected.
For example, if the retry budget interval is 10 seconds, there have been
1000 active requests in the past 10 seconds, and the allowed percentage
of requests that can be retried is 20% (the default), then 200 of those
requests may be composed of retries. Active requests will only be
considered for the duration of the interval when calculating the retry
budget. Retrying the same original request multiple times within the
retry budget interval will lead to each retry being counted towards
calculating the budget.
Configuring a RetryConstraint in BackendTrafficPolicy is compatible with
HTTPRoute Retry settings for each HTTPRouteRule that targets the same
backend. While the HTTPRouteRule Retry stanza can specify whether a
request will be retried, and the number of retry attempts each client
may perform, RetryConstraint helps prevent cascading failures such as
retry storms during periods of consistent failures.
After the retry budget has been exceeded, additional retries to the
backend MUST return a 503 response to the client.
Additional configurations for defining a constraint on retries MAY be
defined in the future.
Support: Extended
for the backend.
Support: Extended | | | + + +#### BudgetDetails + + + +BudgetDetails specifies the details of the budget configuration, like +the percentage of requests in the budget, and the interval between +checks. + + + +_Appears in:_ +- [RetryConstraint](#retryconstraint) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `percent` _integer_ | BudgetPercent defines the maximum percentage of active requests that may
be made up of retries.
Support: Extended | 20 | Maximum: 100
Minimum: 0
| +| `interval` _[Duration](#duration)_ | BudgetInterval defines the duration in which requests will be considered
for calculating the budget for retries.
Support: Extended | 10s | | + + + + + + + + + + + + +#### ListenerEntry + + + + + + + +_Appears in:_ +- [ListenerSetSpec](#listenersetspec) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `name` _[SectionName](#sectionname)_ | Name is the name of the Listener. This name MUST be unique within a
ListenerSet.
Name is not required to be unique across a Gateway and ListenerSets.
Routes can attach to a Listener by having a ListenerSet as a parentRef
and setting the SectionName | | | +| `hostname` _[Hostname](#hostname)_ | 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.
Hostnames that are prefixed with a wildcard label (`*.`) are interpreted
as a suffix match. That means that a match for `*.example.com` would match
both `test.example.com`, and `foo.test.example.com`, but not `example.com`. | | | +| `port` _[PortNumber](#portnumber)_ | Port is the network port. Multiple listeners may use the
same port, subject to the Listener compatibility rules. | | | +| `protocol` _[ProtocolType](#protocoltype)_ | Protocol specifies the network protocol this listener expects to receive. | | | +| `tls` _[GatewayTLSConfig](#gatewaytlsconfig)_ | 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. | | | +| `allowedRoutes` _[AllowedRoutes](#allowedroutes)_ | 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. | \{ namespaces:map[from:Same] \} | | + + + + + + +#### ListenerEntryStatus + + + +ListenerStatus is the status associated with a Listener. + + + +_Appears in:_ +- [ListenerSetStatus](#listenersetstatus) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `name` _[SectionName](#sectionname)_ | Name is the name of the Listener that this status corresponds to. | | | +| `port` _[PortNumber](#portnumber)_ | Port is the network port the listener is configured to listen on. | | | +| `supportedKinds` _[RouteGroupKind](#routegroupkind) array_ | 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. | | MaxItems: 8
| +| `attachedRoutes` _integer_ | AttachedRoutes represents the total number of Routes that have been
successfully attached to this Listener.
Successful attachment of a Route to a Listener is based solely on the
combination of the AllowedRoutes field on the corresponding Listener
and the Route's ParentRefs field. A Route is successfully attached to
a Listener when it is selected by the Listener's AllowedRoutes field
AND the Route has a valid ParentRef selecting the whole Gateway
resource or a specific Listener as a parent resource (more detail on
attachment semantics can be found in the documentation on the various
Route kinds ParentRefs fields). Listener or Route status does not impact
successful attachment, i.e. the AttachedRoutes field count MUST be set
for Listeners with condition Accepted: false and MUST count successfully
attached Routes that may themselves have Accepted: false conditions.
Uses for this field include troubleshooting Route attachment and
measuring blast radius/impact of changes to a Listener. | | | +| `conditions` _[Condition](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#condition-v1-meta) array_ | Conditions describe the current condition of this listener. | | MaxItems: 8
| + + + + + + +#### ListenerSetSpec + + + +ListenerSetSpec defines the desired state of a ListenerSet. + + + +_Appears in:_ +- [XListenerSet](#xlistenerset) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `parentRef` _[ParentGatewayReference](#parentgatewayreference)_ | ParentRef references the Gateway that the listeners are attached to. | | | +| `listeners` _[ListenerEntry](#listenerentry) array_ | Listeners associated with this ListenerSet. Listeners define
logical endpoints that are bound on this referenced parent Gateway's addresses.
Listeners in a `Gateway` and their attached `ListenerSets` are concatenated
as a list when programming the underlying infrastructure. Each listener
name does not need to be unique across the Gateway and ListenerSets.
See ListenerEntry.Name for more details.
Implementations MUST treat the parent Gateway as having the merged
list of all listeners from itself and attached ListenerSets using
the following precedence:
1. "parent" Gateway
2. ListenerSet ordered by creation time (oldest first)
3. ListenerSet ordered alphabetically by “\{namespace\}/\{name\}”.
An implementation MAY reject listeners by setting the ListenerEntryStatus
`Accepted`` condition to False with the Reason `TooManyListeners`
If a listener has a conflict, this will be reported in the
Status.ListenerEntryStatus setting the `Conflicted` condition to True.
Implementations SHOULD be cautious about what information from the
parent or siblings are reported to avoid accidentally leaking
sensitive information that the child would not otherwise have access
to. This can include contents of secrets etc. | | MaxItems: 64
MinItems: 1
| + + +#### ListenerSetStatus + + + + + + + +_Appears in:_ +- [XListenerSet](#xlistenerset) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `conditions` _[Condition](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#condition-v1-meta) array_ | Conditions describe the current conditions of the ListenerSet.
Implementations MUST express ListenerSet conditions using the
`ListenerSetConditionType` and `ListenerSetConditionReason`
constants so that operators and tools can converge on a common
vocabulary to describe ListenerSet state.
Known condition types are:
* "Accepted"
* "Programmed" | [map[lastTransitionTime:1970-01-01T00:00:00Z message:Waiting for controller reason:Pending status:Unknown type:Accepted] map[lastTransitionTime:1970-01-01T00:00:00Z message:Waiting for controller reason:Pending status:Unknown type:Programmed]] | MaxItems: 8
| +| `listeners` _[ListenerEntryStatus](#listenerentrystatus) array_ | Listeners provide status for each unique listener port defined in the Spec. | | MaxItems: 64
| + + + + + + + + +#### ParentGatewayReference + + + +ParentGatewayReference identifies an API object including its namespace, +defaulting to Gateway. + + + +_Appears in:_ +- [ListenerSetSpec](#listenersetspec) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `group` _[Group](#group)_ | Group is the group of the referent. | gateway.networking.k8s.io | | +| `kind` _[Kind](#kind)_ | Kind is kind of the referent. For example "Gateway". | Gateway | | +| `name` _[ObjectName](#objectname)_ | Name is the name of the referent. | | | +| `namespace` _[Namespace](#namespace)_ | Namespace is the namespace of the referent. If not present,
the namespace of the referent is assumed to be the same as
the namespace of the referring object. | | | + + + + + + + + +#### RequestRate + + + +RequestRate expresses a rate of requests over a given period of time. + + + +_Appears in:_ +- [RetryConstraint](#retryconstraint) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `count` _integer_ | Count specifies the number of requests per time interval.
Support: Extended | | Maximum: 1e+06
Minimum: 1
| +| `interval` _[Duration](#duration)_ | Interval specifies the divisor of the rate of requests, the amount of
time during which the given count of requests occur.
Support: Extended | | | + + +#### RetryConstraint + + + +RetryConstraint defines the configuration for when to retry a request. + + + +_Appears in:_ +- [BackendTrafficPolicySpec](#backendtrafficpolicyspec) + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `budget` _[BudgetDetails](#budgetdetails)_ | Budget holds the details of the retry budget configuration. | \{ interval:10s percent:20 \} | | +| `minRetryRate` _[RequestRate](#requestrate)_ | MinRetryRate defines the minimum rate of retries that will be allowable
over a specified duration of time.
The effective overall minimum rate of retries targeting the backend
service may be much higher, as there can be any number of clients which
are applying this setting locally.
This ensures that requests can still be retried during periods of low
traffic, where the budget for retries may be calculated as a very low
value.
Support: Extended | \{ count:10 interval:1s \} | | + + + + + + + + +#### XBackendTrafficPolicy + + + +XBackendTrafficPolicy defines the configuration for how traffic to a +target backend should be handled. + + + + + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `apiVersion` _string_ | `gateway.networking.x-k8s.io/v1alpha1` | | | +| `kind` _string_ | `XBackendTrafficPolicy` | | | +| `metadata` _[ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#objectmeta-v1-meta)_ | Refer to Kubernetes API documentation for fields of `metadata`. | | | +| `spec` _[BackendTrafficPolicySpec](#backendtrafficpolicyspec)_ | Spec defines the desired state of BackendTrafficPolicy. | | | +| `status` _[PolicyStatus](#policystatus)_ | Status defines the current state of BackendTrafficPolicy. | | | + + +#### XListenerSet + + + +XListenerSet defines a set of additional listeners +to attach to an existing Gateway. + + + + + +| Field | Description | Default | Validation | +| --- | --- | --- | --- | +| `apiVersion` _string_ | `gateway.networking.x-k8s.io/v1alpha1` | | | +| `kind` _string_ | `XListenerSet` | | | +| `metadata` _[ObjectMeta](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.32/#objectmeta-v1-meta)_ | Refer to Kubernetes API documentation for fields of `metadata`. | | | +| `spec` _[ListenerSetSpec](#listenersetspec)_ | Spec defines the desired state of ListenerSet. | | | +| `status` _[ListenerSetStatus](#listenersetstatus)_ | Status defines the current state of ListenerSet. | \{ conditions:[map[lastTransitionTime:1970-01-01T00:00:00Z message:Waiting for controller reason:Pending status:Unknown type:Accepted] map[lastTransitionTime:1970-01-01T00:00:00Z message:Waiting for controller reason:Pending status:Unknown type:Programmed]] \} | | + + diff --git a/site-src/ko/stylesheets/extra.css b/site-src/ko/stylesheets/extra.css new file mode 100644 index 0000000000..83df9a8d60 --- /dev/null +++ b/site-src/ko/stylesheets/extra.css @@ -0,0 +1,43 @@ +/* Hide title in favor of logo */ +.md-header__topic { + display: none; +} + +/* Use Kubernetes color as primary */ +:root { + --md-primary-fg-color: #326ce5; +} + +/* Increase size of logo */ +.md-header__button.md-logo img, .md-header__button.md-logo svg { + height: 1.8rem; +} + +/* Always show tabs, even on smaller screens */ +@media screen and (max-width: 76.234375em) { + .md-header__button.md-logo { + display: block; + } + .md-tabs { + display: block; + } +} + +/* Rounded search box + results */ +.md-search__form { + border-radius: .5rem; +} + +[data-md-toggle=search]:checked~.md-header .md-search__form { + border-radius: .5rem .5rem 0 0; +} +[dir=ltr] .md-search__output { + border-radius: 0 0 .5rem .5rem; +} + +/* Center images */ +img.center { + display: block; + margin: 20px auto; + width: 550px; +} diff --git a/site-src/overrides/main.html b/site-src/overrides/main.html new file mode 100644 index 0000000000..d2c7ebbeb3 --- /dev/null +++ b/site-src/overrides/main.html @@ -0,0 +1,12 @@ +{% extends "base.html" %} + +{% block site_meta %} + {{ super() }} + {# Add language metadata to HTML for language detection #} + {# This enables language-switch.js to detect the current language #} + {% if page and page.meta and page.meta.lang %} + + {% else %} + + {% endif %} +{% endblock %} \ No newline at end of file diff --git a/site-src/stylesheets/extra.css b/site-src/stylesheets/extra.css index 83df9a8d60..42a87b9bc1 100644 --- a/site-src/stylesheets/extra.css +++ b/site-src/stylesheets/extra.css @@ -41,3 +41,94 @@ img.center { margin: 20px auto; width: 550px; } + +/* Language selector */ +.md-select.md-header__option { + position: relative; + margin-right: 0; +} + +.md-select .md-header__button { + background: transparent; + border: none; + color: rgba(255, 255, 255, 0.85); + padding: 0.5rem 1rem; + border-radius: 0; + cursor: pointer; + font-size: 0.75rem; + font-weight: 700; + text-transform: none; + display: flex; + align-items: center; + transition: color 0.125s; + text-decoration: none; + height: 100%; + min-height: 2.4rem; +} + +.md-select .md-header__button:hover { + color: white; +} + +.md-select .md-header__button:focus { + outline: none; +} + + + +.md-select__inner { + background-color: white; + border-radius: 0.2rem; + min-width: 140px; + box-shadow: 0 2px 8px rgba(0, 0, 0, 0.15); + z-index: 1000; + margin-top: 0.5rem; + border: 1px solid rgba(0, 0, 0, 0.1); +} + +.md-select__list { + padding: 0.25rem 0; +} + +.md-select__item { + margin: 0; +} + +.md-select__link { + color: rgba(0, 0, 0, 0.87); + padding: 0.5rem 1rem; + text-decoration: none; + display: block; + font-size: 0.75rem; + transition: background-color 0.125s; +} + +.md-select__link:hover { + background-color: rgba(0, 0, 0, 0.05); + color: rgba(0, 0, 0, 0.87); +} + +.md-select__link.current { + background-color: rgba(50, 108, 229, 0.1); + color: #326ce5; + font-weight: 500; +} + +/* Center align navigation tabs text */ +.md-tabs__link { + text-align: center; +} + +.md-tabs__item { + display: flex; + justify-content: center; +} + +/* Language specific display */ +body.is-korean .md-tabs__item:nth-child(-n+5) { + display: none !important; +} + +body.is-english .md-tabs__item:nth-child(n+6):nth-child(-n+10) { + display: none !important; +}