openova/openova
1
0
Fork 0
Code Issues Pull Requests Actions 4 Packages Projects Releases Wiki Activity

fix(cloud-init): install Gateway API v1.1.0 CRDs before cilium so operator registers gateway controller (#581)

Browse Source 
Root cause (otech22 2026-05-02): Cilium operator checks for Gateway API
CRDs at startup and disables its gateway controller if they are absent —
a static, one-shot decision. Cloud-init installs k3s+Cilium first, then
Flux reconciles bp-gateway-api minutes later, so the operator always
starts without CRDs and never recovers. All 8 HTTPRoutes orphaned.

Three-part permanent fix:

1. cloud-init: apply Gateway API v1.1.0 experimental CRDs (incl.
   TLSRoute) BEFORE the Cilium helm install. Cilium 1.16.x requires
   TLSRoute CRD to be present; without it the operator's capability
   check fails entirely and disables the gateway controller.

2. bp-cilium (1.1.2 → 1.1.3): add gatewayAPI.gatewayClass.create: "true"
   to force GatewayClass creation regardless of CRD presence at Helm
   render time. Upstream default "auto" skips GatewayClass when the
   gateway API CRDs are absent at install time (Capabilities check).

3. bp-gateway-api (1.0.0 → 1.1.0): downgrade CRDs from v1.2.0 to v1.1.0
   and ship experimental channel (TLSRoute, TCPRoute, UDPRoute,
   BackendLBPolicy, BackendTLSPolicy). Gateway API v1.2.0 changed
   status.supportedFeatures from string[] to object[]; Cilium 1.16.5
   writes the old string format and the v1.2.0 CRD rejects the status
   patch with "must be of type object: string", leaving GatewayClass
   permanently Unknown/Pending. v1.1.0 retains string schema.

Upgrade path: bump bp-gateway-api + bp-cilium together when Cilium ≥ 1.17
adopts the v1.2.0 object schema for supportedFeatures.

Closes #503

Co-authored-by: hatiyildiz <hatiyildiz@openova.io>
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
e3mrah 2026-05-02 13:23:32 +04:00 committed by GitHub
parent 83ec889f06
commit 73ae746637
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
18 changed files with 8375 additions and 272 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
clusters/_template/bootstrap-kit/01-cilium.yaml
View File

@ -36,7 +36,7 @@ spec:
chart:
spec:
chart: bp-cilium
version: 1.1.1
version: 1.1.3
sourceRef:
kind: HelmRepository
name: bp-cilium

2
clusters/_template/bootstrap-kit/01a-gateway-api.yaml
View File

@ -60,7 +60,7 @@ spec:
chart:
spec:
chart: bp-gateway-api
version: 1.0.0
version: 1.1.0
sourceRef:
kind: HelmRepository
name: bp-gateway-api

43
infra/hetzner/cloudinit-control-plane.tftpl
View File

@ -421,6 +421,16 @@ write_files:
type: wireguard
gatewayAPI:
enabled: true
gatewayClass:
# Force GatewayClass creation regardless of CRD presence at Helm
# render time. Default is "auto" which skips creation when the
# gateway.networking.k8s.io CRDs are not yet present — exactly
# what happens during bootstrap: the upstream Helm chart's
# Capabilities check fires BEFORE bp-gateway-api has run, so
# GatewayClass/cilium is never rendered into the release.
# Forcing "true" ensures the GatewayClass is always created.
# Fix for cilium-gateway-race (issue #503).
create: "true"
envoy:
enabled: true
# envoyConfig.enabled is the load-bearing flag from issue #491.
@ -847,6 +857,39 @@ runcmd:
# inline as a --version flag because OpenTofu's `var.k3s_version`
# parameterisation wires through to it (per INVIOLABLE-PRINCIPLES
# #4 — never hardcode).
# ── Gateway API CRDs BEFORE Cilium ──────────────────────────────────────
#
# Cilium 1.16.x operator checks for gateway.networking.k8s.io CRDs at
# startup. If the CRDs are absent the operator disables its gateway
# controller entirely and never re-checks — a static decision made once
# at boot. This creates a race when Gateway API CRDs are installed AFTER
# k3s/Cilium, which is the normal Flux GitOps order (bp-gateway-api
# reconciles minutes after bp-cilium). Result: every fresh Sovereign has
# no GatewayClass/cilium, all HTTPRoutes are orphaned, no routing.
#
# Fix: pre-install the Gateway API experimental CRDs here, before the
# Cilium helm install below. The experimental channel is required because
# Cilium 1.16.x references tlsroutes.gateway.networking.k8s.io (v1alpha2)
# at startup; the standard channel does not ship TLSRoute.
#
# Version choice — v1.1.0 NOT v1.2.0:
# Gateway API v1.2.0 changed status.supportedFeatures from an array of
# strings to an array of objects ({name: string}). Cilium 1.16.5 still
# writes the old string format; the v1.2.0 CRD rejects its status patch
# with "must be of type object: string", leaving GatewayClass/cilium
# permanently in status=Unknown/Pending. v1.1.0 retains the string
# format and is fully compatible with Cilium 1.16.x.
#
# bp-gateway-api Flux blueprint becomes a no-op on first reconcile
# (CRDs already present, kubectl apply is idempotent); it is kept as the
# GitOps record and handles CRD upgrades when Cilium is bumped.
#
# Incident reference: otech22 2026-05-02 — all 8 HTTPRoutes orphaned,
# cilium-operator log: "Required GatewayAPI resources are not found …
# tlsroutes.gateway.networking.k8s.io not found". Fix: issue #503.
- 'kubectl --kubeconfig=/etc/rancher/k3s/k3s.yaml apply -f https://github.com/kubernetes-sigs/gateway-api/releases/download/v1.1.0/experimental-install.yaml'
- 'kubectl --kubeconfig=/etc/rancher/k3s/k3s.yaml wait --for=condition=Established crd/tlsroutes.gateway.networking.k8s.io --timeout=60s'
- 'curl -sSL https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash'
- 'helm repo add cilium https://helm.cilium.io/'
- 'helm repo update'

2
platform/cilium/blueprint.yaml
View File

@ -6,7 +6,7 @@ metadata:
catalyst.openova.io/category: per-host-cluster-infrastructure
catalyst.openova.io/section: pts-3-1-networking-and-service-mesh
spec:
version: 1.1.1
version: 1.1.3
card:
title: Cilium
summary: Unified CNI + Service Mesh (eBPF). mTLS via WireGuard, Hubble observability, Gateway API.

2
platform/cilium/chart/Chart.yaml
View File

@ -1,6 +1,6 @@
apiVersion: v2
name: bp-cilium
version: 1.1.2
version: 1.1.3
description: |
Catalyst-curated Blueprint umbrella chart for Cilium. Depends on the
upstream `cilium` chart as a Helm subchart so `helm dependency build`

10
platform/cilium/chart/values.yaml
View File

@ -86,6 +86,16 @@ cilium:
# Gateway API — replaces traditional ingress controllers
gatewayAPI:
enabled: true
gatewayClass:
# Force GatewayClass creation regardless of CRD presence at Helm
# render time. Upstream default is "auto" which skips creation when
# the gateway.networking.k8s.io CRDs are absent (Capabilities check
# at helm install time). During bootstrap, bp-gateway-api runs AFTER
# bp-cilium, so "auto" silently skips the GatewayClass — leaving
# every HTTPRoute orphaned until the operator is manually restarted.
# Forcing "true" ensures GatewayClass/cilium is always created.
# Permanent fix for the cilium-gateway race (issue #503).
create: "true"
# L7 proxy via Envoy — for HTTPRoute, gRPCRoute, L7 NetworkPolicy
envoy:

4
platform/gateway-api/blueprint.yaml
View File

@ -6,11 +6,11 @@ metadata:
catalyst.openova.io/category: per-host-cluster-infrastructure
catalyst.openova.io/section: pts-3-1-networking-and-service-mesh
spec:
version: 1.0.0
version: 1.1.0
card:
title: Gateway API
summary: |
Upstream Kubernetes Gateway API CRDs (Standard channel) — the
Upstream Kubernetes Gateway API CRDs (Experimental channel, v1.1.0) — the
gateway.networking.k8s.io/v1 family that every HTTPRoute/Gateway/
GatewayClass-using Blueprint depends on. Cilium 1.16's `gatewayAPI.
enabled=true` flag wires up the cilium controller but does NOT

21
platform/gateway-api/chart/Chart.yaml
View File

@ -1,6 +1,6 @@
apiVersion: v2
name: bp-gateway-api
version: 1.0.0
version: 1.1.0
description: |
Catalyst Blueprint installing the upstream Kubernetes Gateway API
CustomResourceDefinitions (Standard channel — gatewayclasses, gateways,
@ -41,8 +41,21 @@ maintainers:
# Upstream Gateway API release pinned here (operator-bumpable per
# docs/INVIOLABLE-PRINCIPLES.md #4 — never hardcode in app/values, only in
# the Blueprint version metadata + a single annotation that the templates
# read via .Chart.Annotations). Cilium 1.16 supports Gateway API v1.2.x;
# bumping requires a paired Cilium support-matrix check.
# read via .Chart.Annotations).
#
# Version v1.1.0 (NOT v1.2.0): Gateway API v1.2.0 changed
# status.supportedFeatures from string[] to object[]; Cilium 1.16.5
# still writes the old string format. The v1.2.0 CRD rejects the
# status patch with "must be of type object: string", leaving
# GatewayClass/cilium permanently Unknown/Pending. v1.1.0 retains the
# string schema. Bump in lock-step with Cilium when 1.17+ (which
# writes the v1.2.0 object format) is adopted. See issue #503.
#
# experimental-install.yaml (NOT standard-install.yaml): Cilium 1.16.x
# checks for tlsroutes.gateway.networking.k8s.io at operator startup.
# The standard channel does not ship TLSRoute — the operator disables
# its gateway controller if TLSRoute is absent. Experimental channel
# includes TLSRoute, TCPRoute, UDPRoute, BackendLBPolicy, BackendTLSPolicy.
annotations:
catalyst.openova.io/no-upstream: "true"
catalyst.openova.io/upstream-gateway-api-version: "v1.2.0"
catalyst.openova.io/upstream-gateway-api-version: "v1.1.0"

569
platform/gateway-api/chart/templates/backendlbpolicies.yaml Normal file
View File

@ -0,0 +1,569 @@
{{/*
Vendored from kubernetes-sigs/gateway-api {{ index .Chart.Annotations "catalyst.openova.io/upstream-gateway-api-version" }}
experimental-install.yaml. Do NOT hand-edit annotations / spec — re-vendor
via the script in tests/regenerate.sh when bumping the upstream version
(also bump catalyst.openova.io/upstream-gateway-api-version in Chart.yaml).
helm.sh/resource-policy: keep is added under metadata.annotations so a
Helm uninstall does NOT delete the CRD. Gateway API CRDs are foundational
cluster-scoped infrastructure; deleting them on uninstall would break
every HTTPRoute on the cluster simultaneously.
*/}}
#
# config/crd/experimental/gateway.networking.k8s.io_backendlbpolicies.yaml
#
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
annotations:
helm.sh/resource-policy: keep
api-approved.kubernetes.io: https://github.com/kubernetes-sigs/gateway-api/pull/2997
gateway.networking.k8s.io/bundle-version: v1.1.0
gateway.networking.k8s.io/channel: experimental
creationTimestamp: null
name: backendlbpolicies.gateway.networking.k8s.io
spec:
group: gateway.networking.k8s.io
names:
categories:
- gateway-api
kind: BackendLBPolicy
listKind: BackendLBPolicyList
plural: backendlbpolicies
shortNames:
- blbpolicy
singular: backendlbpolicy
scope: Namespaced
versions:
- additionalPrinterColumns:
- jsonPath: .metadata.creationTimestamp
name: Age
type: date
name: v1alpha2
schema:
openAPIV3Schema:
description: |-
BackendLBPolicy provides a way to define load balancing rules
for a backend.
properties:
apiVersion:
description: |-
APIVersion defines the versioned schema of this representation of an object.
Servers should convert recognized schemas to the latest internal value, and
may reject unrecognized values.
More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources
type: string
kind:
description: |-
Kind is a string value representing the REST resource this object represents.
Servers may infer this from the endpoint the client submits requests to.
Cannot be updated.
In CamelCase.
More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
type: string
metadata:
type: object
spec:
description: Spec defines the desired state of BackendLBPolicy.
properties:
sessionPersistence:
description: |-
SessionPersistence defines and configures session persistence
for the backend.
Support: Extended
properties:
absoluteTimeout:
description: |-
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}$
type: string
cookieConfig:
description: |-
CookieConfig provides configuration settings that are specific
to cookie-based session persistence.
Support: Core
properties:
lifetimeType:
default: Session
description: |-
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
enum:
- Permanent
- Session
type: string
type: object
idleTimeout:
description: |-
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: string
sessionName:
description: |-
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
type: string
type:
default: Cookie
description: |-
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
enum:
- Cookie
- Header
type: string
type: object
x-kubernetes-validations:
- message: AbsoluteTimeout must be specified when cookie lifetimeType
is Permanent
rule: '!has(self.cookieConfig.lifetimeType) || self.cookieConfig.lifetimeType
!= ''Permanent'' || has(self.absoluteTimeout)'
targetRefs:
description: |-
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.
items:
description: |-
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.
properties:
group:
description: 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])?)*$
type: string
kind:
description: Kind is kind of the target resource.
maxLength: 63
minLength: 1
pattern: ^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$
type: string
name:
description: Name is the name of the target resource.
maxLength: 253
minLength: 1
type: string
required:
- group
- kind
- name
type: object
maxItems: 16
minItems: 1
type: array
x-kubernetes-list-map-keys:
- group
- kind
- name
x-kubernetes-list-type: map
required:
- targetRefs
type: object
status:
description: Status defines the current state of BackendLBPolicy.
properties:
ancestors:
description: |-
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.
items:
description: |-
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.
properties:
ancestorRef:
description: |-
AncestorRef corresponds with a ParentRef in the spec that this
PolicyAncestorStatus struct describes the status of.
properties:
group:
default: gateway.networking.k8s.io
description: |-
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
maxLength: 253
pattern: ^$|^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$
type: string
kind:
default: Gateway
description: |-
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.
maxLength: 63
minLength: 1
pattern: ^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$
type: string
name:
description: |-
Name is the name of the referent.
Support: Core
maxLength: 253
minLength: 1
type: string
namespace:
description: |-
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])?$
type: string
port:
description: |-
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
format: int32
maximum: 65535
minimum: 1
type: integer
sectionName:
description: |-
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])?)*$
type: string
required:
- name
type: object
conditions:
description: Conditions describes the status of the Policy with
respect to the given Ancestor.
items:
description: "Condition contains details for one aspect of
the current state of this API Resource.\n---\nThis struct
is intended for direct use as an array at the field path
.status.conditions. For example,\n\n\n\ttype FooStatus
struct{\n\t // Represents the observations of a foo's
current state.\n\t // Known .status.conditions.type are:
\"Available\", \"Progressing\", and \"Degraded\"\n\t //
+patchMergeKey=type\n\t // +patchStrategy=merge\n\t //
+listType=map\n\t // +listMapKey=type\n\t Conditions
[]metav1.Condition `json:\"conditions,omitempty\" patchStrategy:\"merge\"
patchMergeKey:\"type\" protobuf:\"bytes,1,rep,name=conditions\"`\n\n\n\t
\ // other fields\n\t}"
properties:
lastTransitionTime:
description: |-
lastTransitionTime is the last time the condition transitioned from one status to another.
This should be when the underlying condition changed. If that is not known, then using the time when the API field changed is acceptable.
format: date-time
type: string
message:
description: |-
message is a human readable message indicating details about the transition.
This may be an empty string.
maxLength: 32768
type: string
observedGeneration:
description: |-
observedGeneration represents the .metadata.generation that the condition was set based upon.
For instance, if .metadata.generation is currently 12, but the .status.conditions[x].observedGeneration is 9, the condition is out of date
with respect to the current state of the instance.
format: int64
minimum: 0
type: integer
reason:
description: |-
reason contains a programmatic identifier indicating the reason for the condition's last transition.
Producers of specific condition types may define expected values and meanings for this field,
and whether the values are considered a guaranteed API.
The value should be a CamelCase string.
This field may not be empty.
maxLength: 1024
minLength: 1
pattern: ^[A-Za-z]([A-Za-z0-9_,:]*[A-Za-z0-9_])?$
type: string
status:
description: status of the condition, one of True, False,
Unknown.
enum:
- "True"
- "False"
- Unknown
type: string
type:
description: |-
type of condition in CamelCase or in foo.example.com/CamelCase.
---
Many .condition.type values are consistent across resources like Available, but because arbitrary conditions can be
useful (see .node.status.conditions), the ability to deconflict is important.
The regex it matches is (dns1123SubdomainFmt/)?(qualifiedNameFmt)
maxLength: 316
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_.]*)?[A-Za-z0-9])$
type: string
required:
- lastTransitionTime
- message
- reason
- status
- type
type: object
maxItems: 8
minItems: 1
type: array
x-kubernetes-list-map-keys:
- type
x-kubernetes-list-type: map
controllerName:
description: |-
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\/\-._~%!$&'()*+,;=:]+$
type: string
required:
- ancestorRef
- controllerName
type: object
maxItems: 16
type: array
required:
- ancestors
type: object
required:
- spec
type: object
served: true
storage: true
subresources:
status: {}
status:
acceptedNames:
kind: ""
plural: ""
conditions: null
storedVersions: null

616
platform/gateway-api/chart/templates/backendtlspolicies.yaml Normal file
View File

@ -0,0 +1,616 @@
{{/*
Vendored from kubernetes-sigs/gateway-api {{ index .Chart.Annotations "catalyst.openova.io/upstream-gateway-api-version" }}
experimental-install.yaml. Do NOT hand-edit annotations / spec — re-vendor
via the script in tests/regenerate.sh when bumping the upstream version
(also bump catalyst.openova.io/upstream-gateway-api-version in Chart.yaml).
helm.sh/resource-policy: keep is added under metadata.annotations so a
Helm uninstall does NOT delete the CRD. Gateway API CRDs are foundational
cluster-scoped infrastructure; deleting them on uninstall would break
every HTTPRoute on the cluster simultaneously.
*/}}
#
# config/crd/experimental/gateway.networking.k8s.io_backendtlspolicies.yaml
#
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
annotations:
helm.sh/resource-policy: keep
api-approved.kubernetes.io: https://github.com/kubernetes-sigs/gateway-api/pull/2997
gateway.networking.k8s.io/bundle-version: v1.1.0
gateway.networking.k8s.io/channel: experimental
creationTimestamp: null
labels:
gateway.networking.k8s.io/policy: Direct
name: backendtlspolicies.gateway.networking.k8s.io
spec:
group: gateway.networking.k8s.io
names:
categories:
- gateway-api
kind: BackendTLSPolicy
listKind: BackendTLSPolicyList
plural: backendtlspolicies
shortNames:
- btlspolicy
singular: backendtlspolicy
scope: Namespaced
versions:
- additionalPrinterColumns:
- jsonPath: .metadata.creationTimestamp
name: Age
type: date
name: v1alpha3
schema:
openAPIV3Schema:
description: |-
BackendTLSPolicy provides a way to configure how a Gateway
connects to a Backend via TLS.
properties:
apiVersion:
description: |-
APIVersion defines the versioned schema of this representation of an object.
Servers should convert recognized schemas to the latest internal value, and
may reject unrecognized values.
More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources
type: string
kind:
description: |-
Kind is a string value representing the REST resource this object represents.
Servers may infer this from the endpoint the client submits requests to.
Cannot be updated.
In CamelCase.
More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
type: string
metadata:
type: object
spec:
description: Spec defines the desired state of BackendTLSPolicy.
properties:
targetRefs:
description: |-
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.
Support: Extended for Kubernetes Service
Support: Implementation-specific for any other resource
items:
description: |-
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.
properties:
group:
description: 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])?)*$
type: string
kind:
description: Kind is kind of the target resource.
maxLength: 63
minLength: 1
pattern: ^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$
type: string
name:
description: Name is the name of the target resource.
maxLength: 253
minLength: 1
type: string
sectionName:
description: |-
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])?)*$
type: string
required:
- group
- kind
- name
type: object
maxItems: 16
minItems: 1
type: array
validation:
description: Validation contains backend TLS validation configuration.
properties:
caCertificateRefs:
description: |-
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 CACertifcateRefs 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).
items:
description: |-
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.
properties:
group:
description: |-
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])?)*$
type: string
kind:
description: 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])?$
type: string
name:
description: Name is the name of the referent.
maxLength: 253
minLength: 1
type: string
required:
- group
- kind
- name
type: object
maxItems: 8
type: array
hostname:
description: |-
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.
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])?)*$
type: string
wellKnownCACertificates:
description: |-
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
type: string
required:
- hostname
type: object
x-kubernetes-validations:
- message: must not contain both CACertificateRefs and WellKnownCACertificates
rule: '!(has(self.caCertificateRefs) && size(self.caCertificateRefs)
> 0 && has(self.wellKnownCACertificates) && self.wellKnownCACertificates
!= "")'
- message: must specify either CACertificateRefs or WellKnownCACertificates
rule: (has(self.caCertificateRefs) && size(self.caCertificateRefs)
> 0 || has(self.wellKnownCACertificates) && self.wellKnownCACertificates
!= "")
required:
- targetRefs
- validation
type: object
status:
description: Status defines the current state of BackendTLSPolicy.
properties:
ancestors:
description: |-
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.
items:
description: |-
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.
properties:
ancestorRef:
description: |-
AncestorRef corresponds with a ParentRef in the spec that this
PolicyAncestorStatus struct describes the status of.
properties:
group:
default: gateway.networking.k8s.io
description: |-
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
maxLength: 253
pattern: ^$|^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$
type: string
kind:
default: Gateway
description: |-
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.
maxLength: 63
minLength: 1
pattern: ^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$
type: string
name:
description: |-
Name is the name of the referent.
Support: Core
maxLength: 253
minLength: 1
type: string
namespace:
description: |-
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])?$
type: string
port:
description: |-
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
format: int32
maximum: 65535
minimum: 1
type: integer
sectionName:
description: |-
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])?)*$
type: string
required:
- name
type: object
conditions:
description: Conditions describes the status of the Policy with
respect to the given Ancestor.
items:
description: "Condition contains details for one aspect of
the current state of this API Resource.\n---\nThis struct
is intended for direct use as an array at the field path
.status.conditions. For example,\n\n\n\ttype FooStatus
struct{\n\t // Represents the observations of a foo's
current state.\n\t // Known .status.conditions.type are:
\"Available\", \"Progressing\", and \"Degraded\"\n\t //
+patchMergeKey=type\n\t // +patchStrategy=merge\n\t //
+listType=map\n\t // +listMapKey=type\n\t Conditions
[]metav1.Condition `json:\"conditions,omitempty\" patchStrategy:\"merge\"
patchMergeKey:\"type\" protobuf:\"bytes,1,rep,name=conditions\"`\n\n\n\t
\ // other fields\n\t}"
properties:
lastTransitionTime:
description: |-
lastTransitionTime is the last time the condition transitioned from one status to another.
This should be when the underlying condition changed. If that is not known, then using the time when the API field changed is acceptable.
format: date-time
type: string
message:
description: |-
message is a human readable message indicating details about the transition.
This may be an empty string.
maxLength: 32768
type: string
observedGeneration:
description: |-
observedGeneration represents the .metadata.generation that the condition was set based upon.
For instance, if .metadata.generation is currently 12, but the .status.conditions[x].observedGeneration is 9, the condition is out of date
with respect to the current state of the instance.
format: int64
minimum: 0
type: integer
reason:
description: |-
reason contains a programmatic identifier indicating the reason for the condition's last transition.
Producers of specific condition types may define expected values and meanings for this field,
and whether the values are considered a guaranteed API.
The value should be a CamelCase string.
This field may not be empty.
maxLength: 1024
minLength: 1
pattern: ^[A-Za-z]([A-Za-z0-9_,:]*[A-Za-z0-9_])?$
type: string
status:
description: status of the condition, one of True, False,
Unknown.
enum:
- "True"
- "False"
- Unknown
type: string
type:
description: |-
type of condition in CamelCase or in foo.example.com/CamelCase.
---
Many .condition.type values are consistent across resources like Available, but because arbitrary conditions can be
useful (see .node.status.conditions), the ability to deconflict is important.
The regex it matches is (dns1123SubdomainFmt/)?(qualifiedNameFmt)
maxLength: 316
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_.]*)?[A-Za-z0-9])$
type: string
required:
- lastTransitionTime
- message
- reason
- status
- type
type: object
maxItems: 8
minItems: 1
type: array
x-kubernetes-list-map-keys:
- type
x-kubernetes-list-type: map
controllerName:
description: |-
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\/\-._~%!$&'()*+,;=:]+$
type: string
required:
- ancestorRef
- controllerName
type: object
maxItems: 16
type: array
required:
- ancestors
type: object
required:
- spec
type: object
served: true
storage: true
subresources:
status: {}
status:
acceptedNames:
kind: ""
plural: ""
conditions: null
storedVersions: null

113
platform/gateway-api/chart/templates/gatewayclasses.yaml
View File

@ -1,6 +1,6 @@
{{/*
Vendored from kubernetes-sigs/gateway-api {{ index .Chart.Annotations "catalyst.openova.io/upstream-gateway-api-version" }}
standard-install.yaml. Do NOT hand-edit annotations / spec — re-vendor
experimental-install.yaml. Do NOT hand-edit annotations / spec — re-vendor
via the script in tests/regenerate.sh when bumping the upstream version
(also bump catalyst.openova.io/upstream-gateway-api-version in Chart.yaml).
@ -9,17 +9,18 @@
cluster-scoped infrastructure; deleting them on uninstall would break
every HTTPRoute on the cluster simultaneously.
*/}}
#
# config/crd/standard/gateway.networking.k8s.io_gatewayclasses.yaml
# config/crd/experimental/gateway.networking.k8s.io_gatewayclasses.yaml
#
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
annotations:
helm.sh/resource-policy: keep
api-approved.kubernetes.io: https://github.com/kubernetes-sigs/gateway-api/pull/3328
gateway.networking.k8s.io/bundle-version: v1.2.0
gateway.networking.k8s.io/channel: standard
api-approved.kubernetes.io: https://github.com/kubernetes-sigs/gateway-api/pull/2997
gateway.networking.k8s.io/bundle-version: v1.1.0
gateway.networking.k8s.io/channel: experimental
creationTimestamp: null
name: gatewayclasses.gateway.networking.k8s.io
spec:
@ -56,6 +57,7 @@ spec:
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
@ -64,11 +66,13 @@ spec:
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.
properties:
apiVersion:
@ -96,10 +100,13 @@ spec:
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
@ -118,19 +125,21 @@ spec:
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.
If the referent cannot be found, the GatewayClass's "InvalidParameters"
status condition will be true.
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
properties:
group:
@ -171,12 +180,13 @@ spec:
conditions:
- lastTransitionTime: "1970-01-01T00:00:00Z"
message: Waiting for controller
reason: Pending
reason: Waiting
status: Unknown
type: Accepted
description: |-
Status defines the current state of GatewayClass.
Implementations MUST populate status on all GatewayClass resources which
specify their controller name.
properties:
@ -191,11 +201,20 @@ spec:
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.
items:
description: Condition contains details for one aspect of the current
state of this API Resource.
description: "Condition contains details for one aspect of the current
state of this API Resource.\n---\nThis struct is intended for
direct use as an array at the field path .status.conditions. For
example,\n\n\n\ttype FooStatus struct{\n\t // Represents the
observations of a foo's current state.\n\t // Known .status.conditions.type
are: \"Available\", \"Progressing\", and \"Degraded\"\n\t //
+patchMergeKey=type\n\t // +patchStrategy=merge\n\t // +listType=map\n\t
\ // +listMapKey=type\n\t Conditions []metav1.Condition `json:\"conditions,omitempty\"
patchStrategy:\"merge\" patchMergeKey:\"type\" protobuf:\"bytes,1,rep,name=conditions\"`\n\n\n\t
\ // other fields\n\t}"
properties:
lastTransitionTime:
description: |-
@ -236,7 +255,12 @@ spec:
- Unknown
type: string
type:
description: type of condition in CamelCase or in foo.example.com/CamelCase.
description: |-
type of condition in CamelCase or in foo.example.com/CamelCase.
---
Many .condition.type values are consistent across resources like Available, but because arbitrary conditions can be
useful (see .node.status.conditions), the ability to deconflict is important.
The regex it matches is (dns1123SubdomainFmt/)?(qualifiedNameFmt)
maxLength: 316
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_.]*)?[A-Za-z0-9])$
type: string
@ -252,6 +276,18 @@ spec:
x-kubernetes-list-map-keys:
- type
x-kubernetes-list-type: map
supportedFeatures:
description: |
SupportedFeatures is the set of features the GatewayClass support.
It MUST be sorted in ascending alphabetical order.
items:
description: |-
SupportedFeature is used to describe distinct features that are covered by
conformance tests.
type: string
maxItems: 64
type: array
x-kubernetes-list-type: set
type: object
required:
- spec
@ -281,6 +317,7 @@ spec:
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
@ -289,11 +326,13 @@ spec:
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.
properties:
apiVersion:
@ -321,10 +360,13 @@ spec:
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
@ -343,19 +385,21 @@ spec:
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.
If the referent cannot be found, the GatewayClass's "InvalidParameters"
status condition will be true.
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
properties:
group:
@ -396,12 +440,13 @@ spec:
conditions:
- lastTransitionTime: "1970-01-01T00:00:00Z"
message: Waiting for controller
reason: Pending
reason: Waiting
status: Unknown
type: Accepted
description: |-
Status defines the current state of GatewayClass.
Implementations MUST populate status on all GatewayClass resources which
specify their controller name.
properties:
@ -416,11 +461,20 @@ spec:
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.
items:
description: Condition contains details for one aspect of the current
state of this API Resource.
description: "Condition contains details for one aspect of the current
state of this API Resource.\n---\nThis struct is intended for
direct use as an array at the field path .status.conditions. For
example,\n\n\n\ttype FooStatus struct{\n\t // Represents the
observations of a foo's current state.\n\t // Known .status.conditions.type
are: \"Available\", \"Progressing\", and \"Degraded\"\n\t //
+patchMergeKey=type\n\t // +patchStrategy=merge\n\t // +listType=map\n\t
\ // +listMapKey=type\n\t Conditions []metav1.Condition `json:\"conditions,omitempty\"
patchStrategy:\"merge\" patchMergeKey:\"type\" protobuf:\"bytes,1,rep,name=conditions\"`\n\n\n\t
\ // other fields\n\t}"
properties:
lastTransitionTime:
description: |-
@ -461,7 +515,12 @@ spec:
- Unknown
type: string
type:
description: type of condition in CamelCase or in foo.example.com/CamelCase.
description: |-
type of condition in CamelCase or in foo.example.com/CamelCase.
---
Many .condition.type values are consistent across resources like Available, but because arbitrary conditions can be
useful (see .node.status.conditions), the ability to deconflict is important.
The regex it matches is (dns1123SubdomainFmt/)?(qualifiedNameFmt)
maxLength: 316
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_.]*)?[A-Za-z0-9])$
type: string
@ -477,6 +536,18 @@ spec:
x-kubernetes-list-map-keys:
- type
x-kubernetes-list-type: map
supportedFeatures:
description: |
SupportedFeatures is the set of features the GatewayClass support.
It MUST be sorted in ascending alphabetical order.
items:
description: |-
SupportedFeature is used to describe distinct features that are covered by
conformance tests.
type: string
maxItems: 64
type: array
x-kubernetes-list-type: set
type: object
required:
- spec

549
platform/gateway-api/chart/templates/gateways.yaml
View File

File diff suppressed because it is too large Load Diff

2760
platform/gateway-api/chart/templates/grpcroutes.yaml
View File

File diff suppressed because it is too large Load Diff

1159
platform/gateway-api/chart/templates/httproutes.yaml
View File

File diff suppressed because it is too large Load Diff

211
platform/gateway-api/chart/templates/referencegrants.yaml
View File

@ -1,6 +1,6 @@
{{/*
Vendored from kubernetes-sigs/gateway-api {{ index .Chart.Annotations "catalyst.openova.io/upstream-gateway-api-version" }}
standard-install.yaml. Do NOT hand-edit annotations / spec — re-vendor
experimental-install.yaml. Do NOT hand-edit annotations / spec — re-vendor
via the script in tests/regenerate.sh when bumping the upstream version
(also bump catalyst.openova.io/upstream-gateway-api-version in Chart.yaml).
@ -9,17 +9,18 @@
cluster-scoped infrastructure; deleting them on uninstall would break
every HTTPRoute on the cluster simultaneously.
*/}}
#
# config/crd/standard/gateway.networking.k8s.io_referencegrants.yaml
# config/crd/experimental/gateway.networking.k8s.io_referencegrants.yaml
#
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
annotations:
helm.sh/resource-policy: keep
api-approved.kubernetes.io: https://github.com/kubernetes-sigs/gateway-api/pull/3328
gateway.networking.k8s.io/bundle-version: v1.2.0
gateway.networking.k8s.io/channel: standard
api-approved.kubernetes.io: https://github.com/kubernetes-sigs/gateway-api/pull/2997
gateway.networking.k8s.io/bundle-version: v1.1.0
gateway.networking.k8s.io/channel: experimental
creationTimestamp: null
name: referencegrants.gateway.networking.k8s.io
spec:
@ -39,7 +40,10 @@ spec:
- jsonPath: .metadata.creationTimestamp
name: Age
type: date
name: v1beta1
deprecated: true
deprecationWarning: The v1alpha2 version of ReferenceGrant has been deprecated
and will be removed in a future release of the API. Please upgrade to v1beta1.
name: v1alpha2
schema:
openAPIV3Schema:
description: |-
@ -47,12 +51,19 @@ spec:
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.
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
@ -87,6 +98,7 @@ spec:
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
items:
description: ReferenceGrantFrom describes trusted namespaces and
@ -97,6 +109,7 @@ spec:
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])?)*$
@ -107,12 +120,16 @@ spec:
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
@ -126,6 +143,7 @@ spec:
description: |-
Namespace is the namespace of the referent.
Support: Core
maxLength: 63
minLength: 1
@ -146,6 +164,7 @@ spec:
additional place that references can be valid to, or to put this another
way, entries MUST be combined using OR.
Support: Core
items:
description: |-
@ -157,6 +176,7 @@ spec:
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])?)*$
@ -167,6 +187,181 @@ spec:
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])?$
type: string
name:
description: |-
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
type: string
required:
- group
- kind
type: object
maxItems: 16
minItems: 1
type: array
required:
- from
- to
type: object
type: object
served: true
storage: false
subresources: {}
- additionalPrinterColumns:
- jsonPath: .metadata.creationTimestamp
name: Age
type: date
name: v1beta1
schema:
openAPIV3Schema:
description: |-
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.
properties:
apiVersion:
description: |-
APIVersion defines the versioned schema of this representation of an object.
Servers should convert recognized schemas to the latest internal value, and
may reject unrecognized values.
More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources
type: string
kind:
description: |-
Kind is a string value representing the REST resource this object represents.
Servers may infer this from the endpoint the client submits requests to.
Cannot be updated.
In CamelCase.
More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
type: string
metadata:
type: object
spec:
description: Spec defines the desired state of ReferenceGrant.
properties:
from:
description: |-
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
items:
description: ReferenceGrantFrom describes trusted namespaces and
kinds.
properties:
group:
description: |-
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])?)*$
type: string
kind:
description: |-
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])?$
type: string
namespace:
description: |-
Namespace is the namespace of the referent.
Support: Core
maxLength: 63
minLength: 1
pattern: ^[a-z0-9]([-a-z0-9]*[a-z0-9])?$
type: string
required:
- group
- kind
- namespace
type: object
maxItems: 16
minItems: 1
type: array
to:
description: |-
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
items:
description: |-
ReferenceGrantTo describes what Kinds are allowed as targets of the
references.
properties:
group:
description: |-
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])?)*$
type: string
kind:
description: |-
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

837
platform/gateway-api/chart/templates/tcproutes.yaml Normal file
View File

@ -0,0 +1,837 @@
{{/*
Vendored from kubernetes-sigs/gateway-api {{ index .Chart.Annotations "catalyst.openova.io/upstream-gateway-api-version" }}
experimental-install.yaml. Do NOT hand-edit annotations / spec — re-vendor
via the script in tests/regenerate.sh when bumping the upstream version
(also bump catalyst.openova.io/upstream-gateway-api-version in Chart.yaml).
helm.sh/resource-policy: keep is added under metadata.annotations so a
Helm uninstall does NOT delete the CRD. Gateway API CRDs are foundational
cluster-scoped infrastructure; deleting them on uninstall would break
every HTTPRoute on the cluster simultaneously.
*/}}
#
# config/crd/experimental/gateway.networking.k8s.io_tcproutes.yaml
#
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
annotations:
helm.sh/resource-policy: keep
api-approved.kubernetes.io: https://github.com/kubernetes-sigs/gateway-api/pull/2997
gateway.networking.k8s.io/bundle-version: v1.1.0
gateway.networking.k8s.io/channel: experimental
creationTimestamp: null
name: tcproutes.gateway.networking.k8s.io
spec:
group: gateway.networking.k8s.io
names:
categories:
- gateway-api
kind: TCPRoute
listKind: TCPRouteList
plural: tcproutes
singular: tcproute
scope: Namespaced
versions:
- additionalPrinterColumns:
- jsonPath: .metadata.creationTimestamp
name: Age
type: date
name: v1alpha2
schema:
openAPIV3Schema:
description: |-
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.
properties:
apiVersion:
description: |-
APIVersion defines the versioned schema of this representation of an object.
Servers should convert recognized schemas to the latest internal value, and
may reject unrecognized values.
More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources
type: string
kind:
description: |-
Kind is a string value representing the REST resource this object represents.
Servers may infer this from the endpoint the client submits requests to.
Cannot be updated.
In CamelCase.
More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
type: string
metadata:
type: object
spec:
description: Spec defines the desired state of TCPRoute.
properties:
parentRefs:
description: |+
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.
items:
description: |-
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.
properties:
group:
default: gateway.networking.k8s.io
description: |-
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
maxLength: 253
pattern: ^$|^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$
type: string
kind:
default: Gateway
description: |-
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.
maxLength: 63
minLength: 1
pattern: ^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$
type: string
name:
description: |-
Name is the name of the referent.
Support: Core
maxLength: 253
minLength: 1
type: string
namespace:
description: |-
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])?$
type: string
port:
description: |-
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
format: int32
maximum: 65535
minimum: 1
type: integer
sectionName:
description: |-
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])?)*$
type: string
required:
- name
type: object
maxItems: 32
type: array
x-kubernetes-validations:
- message: sectionName or port must be specified when parentRefs includes
2 or more references to the same parent
rule: 'self.all(p1, self.all(p2, p1.group == p2.group && p1.kind
== p2.kind && p1.name == p2.name && (((!has(p1.__namespace__)
|| p1.__namespace__ == '''') && (!has(p2.__namespace__) || p2.__namespace__
== '''')) || (has(p1.__namespace__) && has(p2.__namespace__) &&
p1.__namespace__ == p2.__namespace__)) ? ((!has(p1.sectionName)
|| p1.sectionName == '''') == (!has(p2.sectionName) || p2.sectionName
== '''') && (!has(p1.port) || p1.port == 0) == (!has(p2.port)
|| p2.port == 0)): true))'
- message: sectionName or port must be unique when parentRefs includes
2 or more references to the same parent
rule: self.all(p1, self.exists_one(p2, p1.group == p2.group && p1.kind
== p2.kind && p1.name == p2.name && (((!has(p1.__namespace__)
|| p1.__namespace__ == '') && (!has(p2.__namespace__) || p2.__namespace__
== '')) || (has(p1.__namespace__) && has(p2.__namespace__) &&
p1.__namespace__ == p2.__namespace__ )) && (((!has(p1.sectionName)
|| p1.sectionName == '') && (!has(p2.sectionName) || p2.sectionName
== '')) || ( has(p1.sectionName) && has(p2.sectionName) && p1.sectionName
== p2.sectionName)) && (((!has(p1.port) || p1.port == 0) && (!has(p2.port)
|| p2.port == 0)) || (has(p1.port) && has(p2.port) && p1.port
== p2.port))))
rules:
description: Rules are a list of TCP matchers and actions.
items:
description: TCPRouteRule is the configuration for a given rule.
properties:
backendRefs:
description: |-
BackendRefs defines the backend(s) where matching requests should be
sent. If unspecified or invalid (refers to a non-existent resource or a
Service with no endpoints), the underlying implementation MUST actively
reject connection attempts to this backend. Connection rejections must
respect weight; if an invalid backend is requested to have 80% of
connections, then 80% of connections must be rejected instead.
Support: Core for Kubernetes Service
Support: Extended for Kubernetes ServiceImport
Support: Implementation-specific for any other resource
Support for weight: Extended
items:
description: |-
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.
<gateway:experimental:description>
When the BackendRef points to a Kubernetes Service, implementations SHOULD
honor the appProtocol field if it is set for the target Service Port.
Implementations supporting appProtocol SHOULD recognize the Kubernetes
Standard Application Protocols defined in KEP-3726.
If a Service appProtocol isn't specified, an implementation MAY infer the
backend protocol through its own means. Implementations MAY infer the
protocol from the Route type referring to the backend Service.
If a Route is not able to send traffic to the backend using the specified
protocol then the backend is considered invalid. Implementations MUST set the
"ResolvedRefs" condition to "False" with the "UnsupportedProtocol" reason.
</gateway:experimental:description>
Note that when the BackendTLSPolicy object is enabled by the implementation,
there are some extra rules about validity to consider here. See the fields
where this struct is used for more information about the exact behavior.
properties:
group:
default: ""
description: |-
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])?)*$
type: string
kind:
default: Service
description: |-
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)
maxLength: 63
minLength: 1
pattern: ^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$
type: string
name:
description: Name is the name of the referent.
maxLength: 253
minLength: 1
type: string
namespace:
description: |-
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])?$
type: string
port:
description: |-
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.
format: int32
maximum: 65535
minimum: 1
type: integer
weight:
default: 1
description: |-
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.
format: int32
maximum: 1000000
minimum: 0
type: integer
required:
- name
type: object
x-kubernetes-validations:
- message: Must have port for Service reference
rule: '(size(self.group) == 0 && self.kind == ''Service'')
? has(self.port) : true'
maxItems: 16
minItems: 1
type: array
type: object
maxItems: 16
minItems: 1
type: array
required:
- rules
type: object
status:
description: Status defines the current state of TCPRoute.
properties:
parents:
description: |-
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.
items:
description: |-
RouteParentStatus describes the status of a route with respect to an
associated Parent.
properties:
conditions:
description: |-
Conditions describes the status of the route with respect to the Gateway.
Note that the route's availability is also subject to the Gateway's own
status conditions and listener status.
If the Route's ParentRef specifies an existing Gateway that supports
Routes of this kind AND that Gateway's controller has sufficient access,
then that Gateway's controller MUST set the "Accepted" condition on the
Route, to indicate whether the route has been accepted or rejected by the
Gateway, and why.
A Route MUST be considered "Accepted" if at least one of the Route's
rules is implemented by the Gateway.
There are a number of cases where the "Accepted" condition may not be set
due to lack of controller visibility, that includes when:
* The Route refers to a non-existent parent.
* The Route is of a type that the controller does not support.
* The Route is in a namespace the controller does not have access to.
items:
description: "Condition contains details for one aspect of
the current state of this API Resource.\n---\nThis struct
is intended for direct use as an array at the field path
.status.conditions. For example,\n\n\n\ttype FooStatus
struct{\n\t // Represents the observations of a foo's
current state.\n\t // Known .status.conditions.type are:
\"Available\", \"Progressing\", and \"Degraded\"\n\t //
+patchMergeKey=type\n\t // +patchStrategy=merge\n\t //
+listType=map\n\t // +listMapKey=type\n\t Conditions
[]metav1.Condition `json:\"conditions,omitempty\" patchStrategy:\"merge\"
patchMergeKey:\"type\" protobuf:\"bytes,1,rep,name=conditions\"`\n\n\n\t
\ // other fields\n\t}"
properties:
lastTransitionTime:
description: |-
lastTransitionTime is the last time the condition transitioned from one status to another.
This should be when the underlying condition changed. If that is not known, then using the time when the API field changed is acceptable.
format: date-time
type: string
message:
description: |-
message is a human readable message indicating details about the transition.
This may be an empty string.
maxLength: 32768
type: string
observedGeneration:
description: |-
observedGeneration represents the .metadata.generation that the condition was set based upon.
For instance, if .metadata.generation is currently 12, but the .status.conditions[x].observedGeneration is 9, the condition is out of date
with respect to the current state of the instance.
format: int64
minimum: 0
type: integer
reason:
description: |-
reason contains a programmatic identifier indicating the reason for the condition's last transition.
Producers of specific condition types may define expected values and meanings for this field,
and whether the values are considered a guaranteed API.
The value should be a CamelCase string.
This field may not be empty.
maxLength: 1024
minLength: 1
pattern: ^[A-Za-z]([A-Za-z0-9_,:]*[A-Za-z0-9_])?$
type: string
status:
description: status of the condition, one of True, False,
Unknown.
enum:
- "True"
- "False"
- Unknown
type: string
type:
description: |-
type of condition in CamelCase or in foo.example.com/CamelCase.
---
Many .condition.type values are consistent across resources like Available, but because arbitrary conditions can be
useful (see .node.status.conditions), the ability to deconflict is important.
The regex it matches is (dns1123SubdomainFmt/)?(qualifiedNameFmt)
maxLength: 316
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_.]*)?[A-Za-z0-9])$
type: string
required:
- lastTransitionTime
- message
- reason
- status
- type
type: object
maxItems: 8
minItems: 1
type: array
x-kubernetes-list-map-keys:
- type
x-kubernetes-list-type: map
controllerName:
description: |-
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\/\-._~%!$&'()*+,;=:]+$
type: string
parentRef:
description: |-
ParentRef corresponds with a ParentRef in the spec that this
RouteParentStatus struct describes the status of.
properties:
group:
default: gateway.networking.k8s.io
description: |-
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
maxLength: 253
pattern: ^$|^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$
type: string
kind:
default: Gateway
description: |-
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.
maxLength: 63
minLength: 1
pattern: ^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$
type: string
name:
description: |-
Name is the name of the referent.
Support: Core
maxLength: 253
minLength: 1
type: string
namespace:
description: |-
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])?$
type: string
port:
description: |-
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
format: int32
maximum: 65535
minimum: 1
type: integer
sectionName:
description: |-
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])?)*$
type: string
required:
- name
type: object
required:
- controllerName
- parentRef
type: object
maxItems: 32
type: array
required:
- parents
type: object
required:
- spec
type: object
served: true
storage: true
subresources:
status: {}
status:
acceptedNames:
kind: ""
plural: ""
conditions: null
storedVersions: null

910
platform/gateway-api/chart/templates/tlsroutes.yaml Normal file
View File

@ -0,0 +1,910 @@
{{/*
Vendored from kubernetes-sigs/gateway-api {{ index .Chart.Annotations "catalyst.openova.io/upstream-gateway-api-version" }}
experimental-install.yaml. Do NOT hand-edit annotations / spec — re-vendor
via the script in tests/regenerate.sh when bumping the upstream version
(also bump catalyst.openova.io/upstream-gateway-api-version in Chart.yaml).
helm.sh/resource-policy: keep is added under metadata.annotations so a
Helm uninstall does NOT delete the CRD. Gateway API CRDs are foundational
cluster-scoped infrastructure; deleting them on uninstall would break
every HTTPRoute on the cluster simultaneously.
*/}}
#
# config/crd/experimental/gateway.networking.k8s.io_tlsroutes.yaml
#
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
annotations:
helm.sh/resource-policy: keep
api-approved.kubernetes.io: https://github.com/kubernetes-sigs/gateway-api/pull/2997
gateway.networking.k8s.io/bundle-version: v1.1.0
gateway.networking.k8s.io/channel: experimental
creationTimestamp: null
name: tlsroutes.gateway.networking.k8s.io
spec:
group: gateway.networking.k8s.io
names:
categories:
- gateway-api
kind: TLSRoute
listKind: TLSRouteList
plural: tlsroutes
singular: tlsroute
scope: Namespaced
versions:
- additionalPrinterColumns:
- jsonPath: .metadata.creationTimestamp
name: Age
type: date
name: v1alpha2
schema:
openAPIV3Schema:
description: |-
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.
properties:
apiVersion:
description: |-
APIVersion defines the versioned schema of this representation of an object.
Servers should convert recognized schemas to the latest internal value, and
may reject unrecognized values.
More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources
type: string
kind:
description: |-
Kind is a string value representing the REST resource this object represents.
Servers may infer this from the endpoint the client submits requests to.
Cannot be updated.
In CamelCase.
More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
type: string
metadata:
type: object
spec:
description: Spec defines the desired state of TLSRoute.
properties:
hostnames:
description: |-
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
items:
description: |-
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.
maxLength: 253
minLength: 1
pattern: ^(\*\.)?[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$
type: string
maxItems: 16
type: array
parentRefs:
description: |+
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.
items:
description: |-
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.
properties:
group:
default: gateway.networking.k8s.io
description: |-
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
maxLength: 253
pattern: ^$|^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$
type: string
kind:
default: Gateway
description: |-
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.
maxLength: 63
minLength: 1
pattern: ^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$
type: string
name:
description: |-
Name is the name of the referent.
Support: Core
maxLength: 253
minLength: 1
type: string
namespace:
description: |-
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])?$
type: string
port:
description: |-
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
format: int32
maximum: 65535
minimum: 1
type: integer
sectionName:
description: |-
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])?)*$
type: string
required:
- name
type: object
maxItems: 32
type: array
x-kubernetes-validations:
- message: sectionName or port must be specified when parentRefs includes
2 or more references to the same parent
rule: 'self.all(p1, self.all(p2, p1.group == p2.group && p1.kind
== p2.kind && p1.name == p2.name && (((!has(p1.__namespace__)
|| p1.__namespace__ == '''') && (!has(p2.__namespace__) || p2.__namespace__
== '''')) || (has(p1.__namespace__) && has(p2.__namespace__) &&
p1.__namespace__ == p2.__namespace__)) ? ((!has(p1.sectionName)
|| p1.sectionName == '''') == (!has(p2.sectionName) || p2.sectionName
== '''') && (!has(p1.port) || p1.port == 0) == (!has(p2.port)
|| p2.port == 0)): true))'
- message: sectionName or port must be unique when parentRefs includes
2 or more references to the same parent
rule: self.all(p1, self.exists_one(p2, p1.group == p2.group && p1.kind
== p2.kind && p1.name == p2.name && (((!has(p1.__namespace__)
|| p1.__namespace__ == '') && (!has(p2.__namespace__) || p2.__namespace__
== '')) || (has(p1.__namespace__) && has(p2.__namespace__) &&
p1.__namespace__ == p2.__namespace__ )) && (((!has(p1.sectionName)
|| p1.sectionName == '') && (!has(p2.sectionName) || p2.sectionName
== '')) || ( has(p1.sectionName) && has(p2.sectionName) && p1.sectionName
== p2.sectionName)) && (((!has(p1.port) || p1.port == 0) && (!has(p2.port)
|| p2.port == 0)) || (has(p1.port) && has(p2.port) && p1.port
== p2.port))))
rules:
description: Rules are a list of TLS matchers and actions.
items:
description: TLSRouteRule is the configuration for a given rule.
properties:
backendRefs:
description: |-
BackendRefs defines the backend(s) where matching requests should be
sent. If unspecified or invalid (refers to a non-existent resource or
a Service with no endpoints), the rule performs no forwarding; if no
filters are specified that would result in a response being sent, the
underlying implementation must actively reject request attempts to this
backend, by rejecting the connection or returning a 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
items:
description: |-
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.
<gateway:experimental:description>
When the BackendRef points to a Kubernetes Service, implementations SHOULD
honor the appProtocol field if it is set for the target Service Port.
Implementations supporting appProtocol SHOULD recognize the Kubernetes
Standard Application Protocols defined in KEP-3726.
If a Service appProtocol isn't specified, an implementation MAY infer the
backend protocol through its own means. Implementations MAY infer the
protocol from the Route type referring to the backend Service.
If a Route is not able to send traffic to the backend using the specified
protocol then the backend is considered invalid. Implementations MUST set the
"ResolvedRefs" condition to "False" with the "UnsupportedProtocol" reason.
</gateway:experimental:description>
Note that when the BackendTLSPolicy object is enabled by the implementation,
there are some extra rules about validity to consider here. See the fields
where this struct is used for more information about the exact behavior.
properties:
group:
default: ""
description: |-
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])?)*$
type: string
kind:
default: Service
description: |-
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)
maxLength: 63
minLength: 1
pattern: ^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$
type: string
name:
description: Name is the name of the referent.
maxLength: 253
minLength: 1
type: string
namespace:
description: |-
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])?$
type: string
port:
description: |-
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.
format: int32
maximum: 65535
minimum: 1
type: integer
weight:
default: 1
description: |-
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.
format: int32
maximum: 1000000
minimum: 0
type: integer
required:
- name
type: object
x-kubernetes-validations:
- message: Must have port for Service reference
rule: '(size(self.group) == 0 && self.kind == ''Service'')
? has(self.port) : true'
maxItems: 16
minItems: 1
type: array
type: object
maxItems: 16
minItems: 1
type: array
required:
- rules
type: object
status:
description: Status defines the current state of TLSRoute.
properties:
parents:
description: |-
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.
items:
description: |-
RouteParentStatus describes the status of a route with respect to an
associated Parent.
properties:
conditions:
description: |-
Conditions describes the status of the route with respect to the Gateway.
Note that the route's availability is also subject to the Gateway's own
status conditions and listener status.
If the Route's ParentRef specifies an existing Gateway that supports
Routes of this kind AND that Gateway's controller has sufficient access,
then that Gateway's controller MUST set the "Accepted" condition on the
Route, to indicate whether the route has been accepted or rejected by the
Gateway, and why.
A Route MUST be considered "Accepted" if at least one of the Route's
rules is implemented by the Gateway.
There are a number of cases where the "Accepted" condition may not be set
due to lack of controller visibility, that includes when:
* The Route refers to a non-existent parent.
* The Route is of a type that the controller does not support.
* The Route is in a namespace the controller does not have access to.
items:
description: "Condition contains details for one aspect of
the current state of this API Resource.\n---\nThis struct
is intended for direct use as an array at the field path
.status.conditions. For example,\n\n\n\ttype FooStatus
struct{\n\t // Represents the observations of a foo's
current state.\n\t // Known .status.conditions.type are:
\"Available\", \"Progressing\", and \"Degraded\"\n\t //
+patchMergeKey=type\n\t // +patchStrategy=merge\n\t //
+listType=map\n\t // +listMapKey=type\n\t Conditions
[]metav1.Condition `json:\"conditions,omitempty\" patchStrategy:\"merge\"
patchMergeKey:\"type\" protobuf:\"bytes,1,rep,name=conditions\"`\n\n\n\t
\ // other fields\n\t}"
properties:
lastTransitionTime:
description: |-
lastTransitionTime is the last time the condition transitioned from one status to another.
This should be when the underlying condition changed. If that is not known, then using the time when the API field changed is acceptable.
format: date-time
type: string
message:
description: |-
message is a human readable message indicating details about the transition.
This may be an empty string.
maxLength: 32768
type: string
observedGeneration:
description: |-
observedGeneration represents the .metadata.generation that the condition was set based upon.
For instance, if .metadata.generation is currently 12, but the .status.conditions[x].observedGeneration is 9, the condition is out of date
with respect to the current state of the instance.
format: int64
minimum: 0
type: integer
reason:
description: |-
reason contains a programmatic identifier indicating the reason for the condition's last transition.
Producers of specific condition types may define expected values and meanings for this field,
and whether the values are considered a guaranteed API.
The value should be a CamelCase string.
This field may not be empty.
maxLength: 1024
minLength: 1
pattern: ^[A-Za-z]([A-Za-z0-9_,:]*[A-Za-z0-9_])?$
type: string
status:
description: status of the condition, one of True, False,
Unknown.
enum:
- "True"
- "False"
- Unknown
type: string
type:
description: |-
type of condition in CamelCase or in foo.example.com/CamelCase.
---
Many .condition.type values are consistent across resources like Available, but because arbitrary conditions can be
useful (see .node.status.conditions), the ability to deconflict is important.
The regex it matches is (dns1123SubdomainFmt/)?(qualifiedNameFmt)
maxLength: 316
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_.]*)?[A-Za-z0-9])$
type: string
required:
- lastTransitionTime
- message
- reason
- status
- type
type: object
maxItems: 8
minItems: 1
type: array
x-kubernetes-list-map-keys:
- type
x-kubernetes-list-type: map
controllerName:
description: |-
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\/\-._~%!$&'()*+,;=:]+$
type: string
parentRef:
description: |-
ParentRef corresponds with a ParentRef in the spec that this
RouteParentStatus struct describes the status of.
properties:
group:
default: gateway.networking.k8s.io
description: |-
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
maxLength: 253
pattern: ^$|^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$
type: string
kind:
default: Gateway
description: |-
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.
maxLength: 63
minLength: 1
pattern: ^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$
type: string
name:
description: |-
Name is the name of the referent.
Support: Core
maxLength: 253
minLength: 1
type: string
namespace:
description: |-
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])?$
type: string
port:
description: |-
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
format: int32
maximum: 65535
minimum: 1
type: integer
sectionName:
description: |-
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])?)*$
type: string
required:
- name
type: object
required:
- controllerName
- parentRef
type: object
maxItems: 32
type: array
required:
- parents
type: object
required:
- spec
type: object
served: true
storage: true
subresources:
status: {}
status:
acceptedNames:
kind: ""
plural: ""
conditions: null
storedVersions: null

837
platform/gateway-api/chart/templates/udproutes.yaml Normal file
View File

@ -0,0 +1,837 @@
{{/*
Vendored from kubernetes-sigs/gateway-api {{ index .Chart.Annotations "catalyst.openova.io/upstream-gateway-api-version" }}
experimental-install.yaml. Do NOT hand-edit annotations / spec — re-vendor
via the script in tests/regenerate.sh when bumping the upstream version
(also bump catalyst.openova.io/upstream-gateway-api-version in Chart.yaml).
helm.sh/resource-policy: keep is added under metadata.annotations so a
Helm uninstall does NOT delete the CRD. Gateway API CRDs are foundational
cluster-scoped infrastructure; deleting them on uninstall would break
every HTTPRoute on the cluster simultaneously.
*/}}
#
# config/crd/experimental/gateway.networking.k8s.io_udproutes.yaml
#
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
annotations:
helm.sh/resource-policy: keep
api-approved.kubernetes.io: https://github.com/kubernetes-sigs/gateway-api/pull/2997
gateway.networking.k8s.io/bundle-version: v1.1.0
gateway.networking.k8s.io/channel: experimental
creationTimestamp: null
name: udproutes.gateway.networking.k8s.io
spec:
group: gateway.networking.k8s.io
names:
categories:
- gateway-api
kind: UDPRoute
listKind: UDPRouteList
plural: udproutes
singular: udproute
scope: Namespaced
versions:
- additionalPrinterColumns:
- jsonPath: .metadata.creationTimestamp
name: Age
type: date
name: v1alpha2
schema:
openAPIV3Schema:
description: |-
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.
properties:
apiVersion:
description: |-
APIVersion defines the versioned schema of this representation of an object.
Servers should convert recognized schemas to the latest internal value, and
may reject unrecognized values.
More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources
type: string
kind:
description: |-
Kind is a string value representing the REST resource this object represents.
Servers may infer this from the endpoint the client submits requests to.
Cannot be updated.
In CamelCase.
More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
type: string
metadata:
type: object
spec:
description: Spec defines the desired state of UDPRoute.
properties:
parentRefs:
description: |+
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.
items:
description: |-
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.
properties:
group:
default: gateway.networking.k8s.io
description: |-
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
maxLength: 253
pattern: ^$|^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$
type: string
kind:
default: Gateway
description: |-
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.
maxLength: 63
minLength: 1
pattern: ^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$
type: string
name:
description: |-
Name is the name of the referent.
Support: Core
maxLength: 253
minLength: 1
type: string
namespace:
description: |-
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])?$
type: string
port:
description: |-
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
format: int32
maximum: 65535
minimum: 1
type: integer
sectionName:
description: |-
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])?)*$
type: string
required:
- name
type: object
maxItems: 32
type: array
x-kubernetes-validations:
- message: sectionName or port must be specified when parentRefs includes
2 or more references to the same parent
rule: 'self.all(p1, self.all(p2, p1.group == p2.group && p1.kind
== p2.kind && p1.name == p2.name && (((!has(p1.__namespace__)
|| p1.__namespace__ == '''') && (!has(p2.__namespace__) || p2.__namespace__
== '''')) || (has(p1.__namespace__) && has(p2.__namespace__) &&
p1.__namespace__ == p2.__namespace__)) ? ((!has(p1.sectionName)
|| p1.sectionName == '''') == (!has(p2.sectionName) || p2.sectionName
== '''') && (!has(p1.port) || p1.port == 0) == (!has(p2.port)
|| p2.port == 0)): true))'
- message: sectionName or port must be unique when parentRefs includes
2 or more references to the same parent
rule: self.all(p1, self.exists_one(p2, p1.group == p2.group && p1.kind
== p2.kind && p1.name == p2.name && (((!has(p1.__namespace__)
|| p1.__namespace__ == '') && (!has(p2.__namespace__) || p2.__namespace__
== '')) || (has(p1.__namespace__) && has(p2.__namespace__) &&
p1.__namespace__ == p2.__namespace__ )) && (((!has(p1.sectionName)
|| p1.sectionName == '') && (!has(p2.sectionName) || p2.sectionName
== '')) || ( has(p1.sectionName) && has(p2.sectionName) && p1.sectionName
== p2.sectionName)) && (((!has(p1.port) || p1.port == 0) && (!has(p2.port)
|| p2.port == 0)) || (has(p1.port) && has(p2.port) && p1.port
== p2.port))))
rules:
description: Rules are a list of UDP matchers and actions.
items:
description: UDPRouteRule is the configuration for a given rule.
properties:
backendRefs:
description: |-
BackendRefs defines the backend(s) where matching requests should be
sent. If unspecified or invalid (refers to a non-existent resource or a
Service with no endpoints), the underlying implementation MUST actively
reject connection attempts to this backend. Packet drops must
respect weight; if an invalid backend is requested to have 80% of
the packets, then 80% of packets must be dropped instead.
Support: Core for Kubernetes Service
Support: Extended for Kubernetes ServiceImport
Support: Implementation-specific for any other resource
Support for weight: Extended
items:
description: |-
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.
<gateway:experimental:description>
When the BackendRef points to a Kubernetes Service, implementations SHOULD
honor the appProtocol field if it is set for the target Service Port.
Implementations supporting appProtocol SHOULD recognize the Kubernetes
Standard Application Protocols defined in KEP-3726.
If a Service appProtocol isn't specified, an implementation MAY infer the
backend protocol through its own means. Implementations MAY infer the
protocol from the Route type referring to the backend Service.
If a Route is not able to send traffic to the backend using the specified
protocol then the backend is considered invalid. Implementations MUST set the
"ResolvedRefs" condition to "False" with the "UnsupportedProtocol" reason.
</gateway:experimental:description>
Note that when the BackendTLSPolicy object is enabled by the implementation,
there are some extra rules about validity to consider here. See the fields
where this struct is used for more information about the exact behavior.
properties:
group:
default: ""
description: |-
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])?)*$
type: string
kind:
default: Service
description: |-
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)
maxLength: 63
minLength: 1
pattern: ^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$
type: string
name:
description: Name is the name of the referent.
maxLength: 253
minLength: 1
type: string
namespace:
description: |-
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])?$
type: string
port:
description: |-
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.
format: int32
maximum: 65535
minimum: 1
type: integer
weight:
default: 1
description: |-
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.
format: int32
maximum: 1000000
minimum: 0
type: integer
required:
- name
type: object
x-kubernetes-validations:
- message: Must have port for Service reference
rule: '(size(self.group) == 0 && self.kind == ''Service'')
? has(self.port) : true'
maxItems: 16
minItems: 1
type: array
type: object
maxItems: 16
minItems: 1
type: array
required:
- rules
type: object
status:
description: Status defines the current state of UDPRoute.
properties:
parents:
description: |-
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.
items:
description: |-
RouteParentStatus describes the status of a route with respect to an
associated Parent.
properties:
conditions:
description: |-
Conditions describes the status of the route with respect to the Gateway.
Note that the route's availability is also subject to the Gateway's own
status conditions and listener status.
If the Route's ParentRef specifies an existing Gateway that supports
Routes of this kind AND that Gateway's controller has sufficient access,
then that Gateway's controller MUST set the "Accepted" condition on the
Route, to indicate whether the route has been accepted or rejected by the
Gateway, and why.
A Route MUST be considered "Accepted" if at least one of the Route's
rules is implemented by the Gateway.
There are a number of cases where the "Accepted" condition may not be set
due to lack of controller visibility, that includes when:
* The Route refers to a non-existent parent.
* The Route is of a type that the controller does not support.
* The Route is in a namespace the controller does not have access to.
items:
description: "Condition contains details for one aspect of
the current state of this API Resource.\n---\nThis struct
is intended for direct use as an array at the field path
.status.conditions. For example,\n\n\n\ttype FooStatus
struct{\n\t // Represents the observations of a foo's
current state.\n\t // Known .status.conditions.type are:
\"Available\", \"Progressing\", and \"Degraded\"\n\t //
+patchMergeKey=type\n\t // +patchStrategy=merge\n\t //
+listType=map\n\t // +listMapKey=type\n\t Conditions
[]metav1.Condition `json:\"conditions,omitempty\" patchStrategy:\"merge\"
patchMergeKey:\"type\" protobuf:\"bytes,1,rep,name=conditions\"`\n\n\n\t
\ // other fields\n\t}"
properties:
lastTransitionTime:
description: |-
lastTransitionTime is the last time the condition transitioned from one status to another.
This should be when the underlying condition changed. If that is not known, then using the time when the API field changed is acceptable.
format: date-time
type: string
message:
description: |-
message is a human readable message indicating details about the transition.
This may be an empty string.
maxLength: 32768
type: string
observedGeneration:
description: |-
observedGeneration represents the .metadata.generation that the condition was set based upon.
For instance, if .metadata.generation is currently 12, but the .status.conditions[x].observedGeneration is 9, the condition is out of date
with respect to the current state of the instance.
format: int64
minimum: 0
type: integer
reason:
description: |-
reason contains a programmatic identifier indicating the reason for the condition's last transition.
Producers of specific condition types may define expected values and meanings for this field,
and whether the values are considered a guaranteed API.
The value should be a CamelCase string.
This field may not be empty.
maxLength: 1024
minLength: 1
pattern: ^[A-Za-z]([A-Za-z0-9_,:]*[A-Za-z0-9_])?$
type: string
status:
description: status of the condition, one of True, False,
Unknown.
enum:
- "True"
- "False"
- Unknown
type: string
type:
description: |-
type of condition in CamelCase or in foo.example.com/CamelCase.
---
Many .condition.type values are consistent across resources like Available, but because arbitrary conditions can be
useful (see .node.status.conditions), the ability to deconflict is important.
The regex it matches is (dns1123SubdomainFmt/)?(qualifiedNameFmt)
maxLength: 316
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_.]*)?[A-Za-z0-9])$
type: string
required:
- lastTransitionTime
- message
- reason
- status
- type
type: object
maxItems: 8
minItems: 1
type: array
x-kubernetes-list-map-keys:
- type
x-kubernetes-list-type: map
controllerName:
description: |-
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\/\-._~%!$&'()*+,;=:]+$
type: string
parentRef:
description: |-
ParentRef corresponds with a ParentRef in the spec that this
RouteParentStatus struct describes the status of.
properties:
group:
default: gateway.networking.k8s.io
description: |-
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
maxLength: 253
pattern: ^$|^[a-z0-9]([-a-z0-9]*[a-z0-9])?(\.[a-z0-9]([-a-z0-9]*[a-z0-9])?)*$
type: string
kind:
default: Gateway
description: |-
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.
maxLength: 63
minLength: 1
pattern: ^[a-zA-Z]([-a-zA-Z0-9]*[a-zA-Z0-9])?$
type: string
name:
description: |-
Name is the name of the referent.
Support: Core
maxLength: 253
minLength: 1
type: string
namespace:
description: |-
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])?$
type: string
port:
description: |-
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
format: int32
maximum: 65535
minimum: 1
type: integer
sectionName:
description: |-
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])?)*$
type: string
required:
- name
type: object
required:
- controllerName
- parentRef
type: object
maxItems: 32
type: array
required:
- parents
type: object
required:
- spec
type: object
served: true
storage: true
subresources:
status: {}
status:
acceptedNames:
kind: ""
plural: ""
conditions: null
storedVersions: null