Last changed in Kgateway v2.4.0
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
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
BackendConfigPolicySpec defines the desired state of BackendConfigPolicy.
CircuitBreakers contains the options necessary to configure circuit breaking. See [Envoy documentation](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/circuit_breaking) for more details.
MaxConnections is the maximum number of connections that will be made to the upstream cluster. If not specified, defaults to 1024.
MaxPendingRequests is the maximum number of pending requests that are allowed to the upstream cluster. If not specified, defaults to 1024.
MaxRequests is the maximum number of parallel requests that are allowed to the upstream cluster. If not specified, defaults to 1024.
MaxRetries is the maximum number of parallel retries that are allowed to the upstream cluster. If not specified, defaults to 3.
TrackRemaining controls whether Envoy tracks the remaining resource gauges for this circuit breaker threshold group. When enabled, the remaining_cx, remaining_pending, remaining_rq, and remaining_retries statistics are populated. Enabling this has a performance cost. If not specified, defaults to false.
Additional options when handling HTTP requests upstream, applicable to both HTTP1 and HTTP2 requests.
The idle timeout for connections. The idle timeout is defined as the period in which there are no active requests. When the idle timeout is reached the connection will be closed. If the connection is an HTTP/2 downstream connection a drain sequence will occur prior to closing the connection. Note that request based timeouts mean that HTTP/2 PINGs will not keep the connection alive. If not specified, this defaults to 1 hour. To disable idle timeouts explicitly set this to 0. Disabling this timeout has a highly likelihood of yielding connection leaks due to lost TCP FIN packets, etc.
Specifies the maximum number of headers that the connection will accept. If not specified, the default of 100 is used. Requests that exceed this limit will receive a 431 response for HTTP/1.x and cause a stream reset for HTTP/2.
Maximum requests for a single upstream connection. If set to 0 or unspecified, defaults to unlimited.
Total duration to keep alive an HTTP request/response stream. If the time limit is reached the stream will be reset independent of any other timeouts. If not specified, this value is not set.
The timeout for new network connections to hosts in the cluster.
DNS contains DNS configuration. Note that this only applies to backends that resolve to Envoy DNS clusters, i.e., Backends of type Static, AWS, or GCP.
Jitter adds a random delay of up to this duration before each DNS refresh, spreading query load over time and helping prevent thundering-herd spikes. Must be less than or equal to refreshRate when both are set.
RefreshRate controls how frequently Envoy polls DNS for this backend's hostnames. Minimum value is 1ms. If unset, Envoy's default of 5s is used. When Envoy respects DNS TTLs, lower TTL values effectively override this setting, so RefreshRate acts as the maximum polling interval. Recommended value for large-scale deployments is 60s or higher.
RespectTTL instructs Envoy to honor TTL values returned by DNS responses. When enabled, TTLs lower than RefreshRate effectively become the refresh interval.
HealthCheck contains the options necessary to configure the health check.
Grpc contains the options to configure the gRPC health check.
Authority is the authority header used to make the gRPC health check request. If unset, the name of the cluster this health check is associated with will be used.
ServiceName is the optional name of the service to check.
HealthyThreshold is the number of healthy health checks required before a host is marked healthy. Note that during startup, only a single successful health check is required to mark a host healthy.
Http contains the options to configure the HTTP health check.
Host is the value of the host header in the HTTP health check request. If unset, the name of the cluster this health check is associated with will be used.
Method is the HTTP method to use. If unset, GET is used.
Path is the HTTP path requested.
Interval is the time between health checks.
Timeout is time to wait for a health check response. If the timeout is reached the health check attempt will be considered a failure.
UnhealthyThreshold is the number of consecutive failed health checks that will be considered unhealthy. Note that for HTTP health checks, if a host responds with a code not in ExpectedStatuses or RetriableStatuses, this threshold is ignored and the host is considered immediately unhealthy.
Additional options when handling HTTP1 requests upstream.
Enables trailers for HTTP/1. By default the HTTP/1 codec drops proxied trailers. Note: Trailers must also be enabled at the gateway level in order for this option to take effect
Allows invalid HTTP messaging. When this option is false, then Envoy will terminate HTTP/1.1 connections upon receiving an invalid HTTP message. However, when this option is true, then Envoy will leave the HTTP/1.1 connection open where possible.
PreserveHttp1HeaderCase determines whether to preserve the case of HTTP1 response headers. See here for more information: https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_conn_man/header_casing
Http2ProtocolOptions contains the options necessary to configure HTTP/2 backends. Note: Http2ProtocolOptions can only be applied to HTTP/2 backends. See [Envoy documentation](https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/transport_sockets/tls/v3/tls.proto#envoy-v3-api-msg-extensions-transport-sockets-tls-v3-sslconfig) for more details.
ConnectionKeepalive enables HTTP/2 keepalive PINGs on upstream connections, actively detecting half-dead connections: if a PING is not acknowledged within the timeout, the connection is closed. See [Envoy documentation](https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/core/v3/protocol.proto#envoy-v3-api-msg-config-core-v3-keepalivesettings) for more details.
If set, a PING is sent before dispatching new streams on a connection that has been idle for at least this duration, verifying the connection is still alive before reusing it.
Interval between keepalive PINGs. If unset, PINGs are only sent when triggered by ConnectionIdleInterval.
Timeout after which the connection is closed if no response to a keepalive PING is received. A PING response is considered received if any frame arrives on the connection while the PING is outstanding.
InitialConnectionWindowSize is similar to InitialStreamWindowSize, but for the connection level. Same range and default value as InitialStreamWindowSize. Values can be specified with units like "64Ki".
InitialStreamWindowSize is the initial window size for the stream. Valid values range from 65535 (2^16 - 1, HTTP/2 default) to 2147483647 (2^31 - 1, HTTP/2 maximum). Defaults to 268435456 (256 * 1024 * 1024). Values can be specified with units like "64Ki".
The maximum number of concurrent streams that the connection can have. Envoy defaults to 1024.
Allows invalid HTTP messaging and headers. When disabled (default), then the whole HTTP/2 connection is terminated upon receiving invalid HEADERS frame. When enabled, only the offending stream is terminated.
LoadBalancer contains the options necessary to configure the load balancer.
If set to true, the load balancer will drain connections when the host set changes. Ring Hash or Maglev can be used to ensure that clients with the same key are routed to the same upstream host. Distruptions can cause new connections with the same key as existing connections to be routed to different hosts. Enabling this feature will cause the load balancer to drain existing connections when the host set changes, ensuring that new connections with the same key are consistently routed to the same host. Connections are not immediately closed, but are allowed to drain before being closed.
HealthyPanicThreshold configures envoy's panic threshold percentage between 0-100. Once the number of non-healthy hosts reaches this percentage, envoy disregards health information. See [Envoy documentation](https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/load_balancing/panic_threshold.html).
LeastRequest configures the least request load balancer type.
How many choices to take into account. Defaults to 2.
SlowStart configures the slow start configuration for the load balancer.
This parameter controls the speed of traffic increase over the slow start window. Defaults to 1.0, so that endpoint would get linearly increasing amount of traffic. When increasing the value for this parameter, the speed of traffic ramp-up increases non-linearly. The value of aggression parameter should be greater than 0.0. By tuning the parameter, is possible to achieve polynomial or exponential shape of ramp-up curve. During slow start window, effective weight of an endpoint would be scaled with time factor and aggression: `new_weight = weight * max(min_weight_percent, time_factor ^ (1 / aggression))`, where `time_factor=(time_since_start_seconds / slow_start_time_seconds)`. As time progresses, more and more traffic would be sent to endpoint, which is in slow start window. Once host exits slow start, time_factor and aggression no longer affect its weight.
Minimum weight percentage of an endpoint during slow start.
Represents the size of slow start window. If set, the newly created host remains in slow start mode starting from its creation time for the duration of slow start window.
LocalityType specifies the locality config type to use. See https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/load_balancing_policies/common/v3/common.proto#envoy-v3-api-msg-extensions-load-balancing-policies-common-v3-localitylbconfig
Maglev configures the maglev load balancer type.
HashPolicies specifies the hash policies for hashing load balancers (RingHash, Maglev).
Cookie specifies a given cookie as a component of the hash key.
HttpOnly specifies whether the cookie is HTTP only, i.e. not accessible to JavaScript.
Name of the cookie.
Path is the name of the path for the cookie.
SameSite controls cross-site sending of cookies. Supported values are Strict, Lax, and None.
Secure specifies whether the cookie is secure. If true, the cookie will only be sent over HTTPS.
TTL specifies the time to live of the cookie. If specified, a cookie with the TTL will be generated if the cookie is not present. If the TTL is present and zero, the generated cookie will be a session cookie.
Header specifies a header's value as a component of the hash key.
Name is the name of the header to use as a component of the hash key.
SourceIP specifies whether to use the request's source IP address as a component of the hash key.
Terminal, if set, and a hash key is available after evaluating this policy, will cause Envoy to skip the subsequent policies and use the key as it is. This is useful for defining "fallback" policies and limiting the time Envoy spends generating hash keys.
UseHostnameForHashing specifies whether to use the hostname instead of the resolved IP address for hashing. Defaults to false.
Random configures the random load balancer type.
RingHash configures the ring hash load balancer type.
HashPolicies specifies the hash policies for hashing load balancers (RingHash, Maglev).
Cookie specifies a given cookie as a component of the hash key.
HttpOnly specifies whether the cookie is HTTP only, i.e. not accessible to JavaScript.
Name of the cookie.
Path is the name of the path for the cookie.
SameSite controls cross-site sending of cookies. Supported values are Strict, Lax, and None.
Secure specifies whether the cookie is secure. If true, the cookie will only be sent over HTTPS.
TTL specifies the time to live of the cookie. If specified, a cookie with the TTL will be generated if the cookie is not present. If the TTL is present and zero, the generated cookie will be a session cookie.
Header specifies a header's value as a component of the hash key.
Name is the name of the header to use as a component of the hash key.
SourceIP specifies whether to use the request's source IP address as a component of the hash key.
Terminal, if set, and a hash key is available after evaluating this policy, will cause Envoy to skip the subsequent policies and use the key as it is. This is useful for defining "fallback" policies and limiting the time Envoy spends generating hash keys.
MaximumRingSize is the maximum size of the ring.
MinimumRingSize is the minimum size of the ring.
UseHostnameForHashing specifies whether to use the hostname instead of the resolved IP address for hashing. Defaults to false.
RoundRobin configures the round robin load balancer type.
SlowStart configures the slow start configuration for the load balancer.
This parameter controls the speed of traffic increase over the slow start window. Defaults to 1.0, so that endpoint would get linearly increasing amount of traffic. When increasing the value for this parameter, the speed of traffic ramp-up increases non-linearly. The value of aggression parameter should be greater than 0.0. By tuning the parameter, is possible to achieve polynomial or exponential shape of ramp-up curve. During slow start window, effective weight of an endpoint would be scaled with time factor and aggression: `new_weight = weight * max(min_weight_percent, time_factor ^ (1 / aggression))`, where `time_factor=(time_since_start_seconds / slow_start_time_seconds)`. As time progresses, more and more traffic would be sent to endpoint, which is in slow start window. Once host exits slow start, time_factor and aggression no longer affect its weight.
Minimum weight percentage of an endpoint during slow start.
Represents the size of slow start window. If set, the newly created host remains in slow start mode starting from its creation time for the duration of slow start window.
This allows batch updates of endpoints health/weight/metadata that happen during a time window. this help lower cpu usage when endpoint change rate is high. defaults to 1 second. Set to 0 to disable and have changes applied immediately.
ZoneAware configures zone-aware routing behavior for the load balancer. When enabled, traffic is preferentially routed to endpoints in the same availability zone as the Envoy proxy. This is mutually exclusive with localityType. Note: This feature is experimental and subject to breaking changes in future releases.
PreferLocal enables Envoy's zone-aware routing which prefers sending traffic to local zone endpoints while maintaining overall traffic balance across zones. On Kubernetes 1.35+, the zone is automatically derived from node label. The KGATEWAY_NODE_* environment variables on the proxy pod can be set as an explicit override. See https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/load_balancing/zone_aware
Force enables Envoy forced zone-local routing. Envoy routes to same-zone endpoints while the local endpoint threshold is met. If there are not enough local endpoints, traffic falls back to standard zone-aware routing behavior.
MinEndpointsInZoneThreshold is the minimum number of endpoints that must exist in the local zone for forced zone-local routing to be active. If the local zone has fewer endpoints than this threshold, the system falls back to standard zone-aware routing behavior. Defaults to 1.
MinEndpointsThreshold is the minimum number of total endpoints in the cluster that must exist for zone-aware routing to be enabled. If the total number of endpoints is below this threshold, zone-aware routing is disabled. This maps to Envoy's min_cluster_size setting. Defaults to 6.
RoutingEnabled is the percentage of requests for which Envoy applies zone-aware routing once the minEndpointsThreshold is met. Defaults to 100.
OutlierDetection contains the options necessary to configure passive health checking.
The base time that a host is ejected for. The real time is equal to the base time multiplied by the number of times the host has been ejected. Defaults to 30s.
The number of consecutive server-side error responses (for HTTP traffic, 5xx responses; for TCP traffic, connection failures; etc.) before an ejection occurs. Defaults to 5. If this is zero, consecutive 5xx passive health checks will be disabled. In the future, other types of passive health checking might be added, but none will be enabled by default.
The time interval between ejection analysis sweeps. This can result in both new ejections as well as hosts being returned to service. Defaults to 10s.
The maximum % of an upstream cluster that can be ejected due to outlier detection. Defaults to 10%.
Soft limit on the size of the cluster's connections read and write buffers. If unspecified, an implementation-defined default is applied (1MiB).
TargetRefs specifies the target references to attach the policy to.
The API group of the target resource. For Kubernetes Gateway API resources, the group is `gateway.networking.k8s.io`.
The API kind of the target resource, such as Gateway or HTTPRoute.
The name of the target resource.
TargetSelectors specifies the target selectors to select resources to attach the policy to.
The API group of the target resource. For Kubernetes Gateway API resources, the group is `gateway.networking.k8s.io`.
The API kind of the target resource, such as Gateway or HTTPRoute.
Label selector to select the target resource.
Configure OS-level TCP keepalive checks.
The number of seconds between keep-alive probes.
Maximum number of keep-alive probes to send before dropping the connection.
The number of seconds a connection needs to be idle before keep-alive probes start being sent.
TLS contains the options necessary to configure a backend to use TLS origination. See [Envoy documentation](https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/transport_sockets/tls/v3/tls.proto#envoy-v3-api-msg-extensions-transport-sockets-tls-v3-sslconfig) for more details.
Allow Tls renegotiation, the default value is false. TLS renegotiation is considered insecure and shouldn't be used unless absolutely necessary.
Set Application Level Protocol Negotiation If empty, defaults to ["h2", "http/1.1"].
File paths to certificates local to the proxy.
InsecureSkipVerify originates TLS but skips verification of the backend's certificate. WARNING: This is an insecure option that should only be used if the risks are understood.
General TLS parameters. See the [envoy docs](https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/transport_sockets/tls/v3/common.proto#extensions-transport-sockets-tls-v3-tlsparameters) for more information on the meaning of these values.
Maximum TLS version.
Minimum TLS version.
Reference to the TLS secret containing the certificate, key, and optionally the root CA.
Name of the referent. This field is effectively required, but due to backwards compatibility is allowed to be empty. Instances of this type with an empty value here are almost certainly wrong. More info: https://kubernetes.io/docs/concepts/overview/working-with-objects/names/#names
If the TLS config has the tls cert and key provided, kgateway uses it to perform mTLS by default. Set simpleTLS to true to disable mTLS in favor of server-only TLS (one-way TLS), even if kgateway has the client cert. If unset, defaults to false.
The SNI domains that should be considered for TLS connection
Verify that the Subject Alternative Name in the peer certificate is one of the specified values. note that a root_ca must be provided if this option is used.
WellKnownCACertificates specifies whether to use a well-known set of CA certificates for validating the backend's certificate chain. Currently, only the system certificate pool is supported via SDS.
UpstreamProxyProtocol configures the PROXY protocol for upstream connections to the backend. When enabled, the proxy protocol header is prepended to upstream connections, allowing backend services to see the original client connection information. See [Envoy documentation](https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/transport_sockets/proxy_protocol/v3/upstream_proxy_protocol.proto) for more details.
Version is the PROXY protocol version to use.
PolicyStatus defines the common attributes that all Policies should include within their status.
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.
AncestorRef corresponds with a ParentRef in the spec that this PolicyAncestorStatus struct describes the status of.
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
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.
Name is the name of the referent. Support: Core
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. <gateway:experimental:description> 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. </gateway:experimental:description> Support: Core
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. <gateway:experimental:description> 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. </gateway:experimental:description> 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
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
Conditions describes the status of the Policy with respect to the given Ancestor. <gateway:util:excludeFromCRD> Notes for implementors: Conditions are a listType `map`, which means that they function like a map with a key of the `type` field _in the k8s apiserver_. This means that implementations must obey some rules when updating this section. * Implementations MUST perform a read-modify-write cycle on this field before modifying it. That is, when modifying this field, implementations must be confident they have fetched the most recent version of this field, and ensure that changes they make are on that recent version. * Implementations MUST NOT remove or reorder Conditions that they are not directly responsible for. For example, if an implementation sees a Condition with type `special.io/SomeField`, it MUST NOT remove, change or update that Condition. * Implementations MUST always _merge_ changes into Conditions of the same Type, rather than creating more than one Condition of the same Type. * Implementations MUST always update the `observedGeneration` field of the Condition to the `metadata.generation` of the Gateway at the time of update creation. * If the `observedGeneration` of a Condition is _greater than_ the value the implementation knows about, then it MUST NOT perform the update on that Condition, but must wait for a future reconciliation and status update. (The assumption is that the implementation's copy of the object is stale and an update will be re-triggered if relevant.) </gateway:util:excludeFromCRD>
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.
message is a human readable message indicating details about the transition. This may be an empty string.
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.
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.
status of the condition, one of True, False, Unknown.
type of condition in CamelCase or in foo.example.com/CamelCase.
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.
Source: gateway.kgateway.dev_backendconfigpolicies.yaml
Changes to BackendConfigPolicy (gateway.kgateway.dev/v1alpha1) in each Kgateway version, compared to the version before it.
3 properties have been added
Released · View BackendConfigPolicy in v2.4.0
3 properties have been added
1 property has changed the description
Released · View BackendConfigPolicy in v2.3.0
1 property has been added
1 property is now required
126 properties have changed the description
Released · View BackendConfigPolicy in v2.2.0
BackendConfigPolicy was first seen on this version of Kgateway
Released · View BackendConfigPolicy in v2.1.0
No examples of BackendConfigPolicy yet. Contribute one on GitHub.
kubespec.dev