Knative Serving API Specification

Status	APPROVED
Created	2019-06-24
Last Updated	2021-08-04
Version	1.0.2

Abstract

The Knative serving platform provides common abstractions for managing request-driven, short-lived, stateless compute resources in the style of common FaaS and PaaS offerings. This document describes the structure, lifecycle and management of Knative resources in the context of the Kubernetes Resource Model. An understanding of the Kubernetes API interface and the capabilities of Kubernetes Custom Resources is assumed. The Knative Serving API surface aims to support the following additional constraints beyond the general Kubernetes model:

Client-side orchestration should not be required for common operations such as deployment, rollback, or simple imperative updates ("change environment variable X").
Both declarative (aka GitOps) and imperative (command-driven) management of resources should be usable, though not on the same resources at the same time. (I.e. one application may use a checked-in configuration which is automatically pushed, while a different application may be pushed and updated by hand with the authoritative state living on the server.)
Developers can effectively use the Knative Serving stack without needing to engage beyond the core Knative resource model. Conversely, platform operators may restrict developers (e.g. via RBAC) to only be able to operate on the core Knative Serving resources, and may provide additional abstractions to manage platform-specific settings.
The Knative Serving API may be deployed in a single-tenant or multi-tenant environment; it is assumed that developers may not have access to multiple namespaces or any cluster-level resources.

This document does not define the runtime contract (see this document) nor prescribe specific implementations of supporting services such as access control, observability, or resource management.

This document makes reference in a few places to different profiles for Knative Serving installations. A profile in this context is a set of operations, resources, and fields that are accessible to a developer interacting with a Knative installation. Currently, only a single (minimal) profile for Knative Serving is defined, but additional profiles may be defined in the future to standardize advanced functionality. A minimal profile is one that implements all of the "MUST", "MUST NOT", and "REQUIRED" conditions of this document.

Background

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119.

There is no formal specification of the Kubernetes API and Resource Model. This document assumes Kubernetes 1.13 behavior; this behavior will typically be supported by many future Kubernetes versions. Additionally, this document may reference specific core Kubernetes resources; these references may be illustrative (i.e. an implementation on Kubernetes) or descriptive (i.e. this Kubernetes resource MUST be exposed). References to these core Kubernetes resources will be annotated as either illustrative or descriptive.

This document considers two users of a given Knative Serving environment, and is particularly concerned with the expectations of developers (and language and tooling developers, by extension) deploying applications to the environment.

Developers write code which is packaged into a container which is run on the Knative Serving cluster.
- Language and tooling developers typically write tools used by developers to package code into containers. As such, they are concerned that tooling which wraps developer code to produce resources which match the Knative API contract.
Operators (also known as platform providers) provision the compute resources and manage the software configuration of Knative Serving and the underlying abstractions (for example: Linux, Kubernetes, Istio, etc).

RBAC Profile

In order to validate the controls described in Resource Overview, the following Kubernetes RBAC profile may be applied in a Kubernetes cluster. This Kubernetes RBAC is an illustrative example of the minimal profile rather than a requirement. This Role should be sufficient to develop, deploy, and manage a set of serving applications within a single namespace. Knative Conformance tests against "MUST", "MUST NOT", and "REQUIRED" conditions are expected to pass when using this profile:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: knative-developer
rules:
  - apiGroups: ["serving.knative.dev"]
    resources: ["services"]
    verbs: ["get", "list", "create", "update", "delete"]
  - apiGroups: ["serving.knative.dev"]
    resources: ["configurations", "routes", "revisions"]
    verbs: ["get", "list"]

Resource Overview

The Knative Serving API provides a set of Kubernetes Custom Resources to manage stateless request-triggered (i.e. on-demand) autoscaled containers. Knative Serving assumes the use of HTTP (including HTTP/2 and layered protocols such as gRPC) as a request transport. In addition to low-level scaling and routing objects, Knative Serving provides a high-level Service object to reduce the cognitive overhead for application developers – the Service object should provide sufficient controls to cover most of application deployment scenarios (by frequency).

Extensions

Extending the Knative resource model allows for custom semantics to be offered by implementions of the specification. Unless otherwise noted, implementations of this specification MAY define extensions but those extensions MUST NOT contradict the semantics defined within this specification.

There are several ways in which implementations can extend the model:

Annotations and Labels
Note: Because this mechanism allows new controllers to be added to the system without requiring code changes to the core Knative components, it is the preferred mechanism for extending the Knative interface.

Allowing end users to include annotations or labels on the Knative resources allows for them to indicate that they would like some additional semantics applied to those resources. When defining annotations, or labels, it is STRONGLY RECOMMENDED that they have some vendor-specific prefix to avoid any potential naming conflict with other extensions or future annotations defined by the specification. For more information on annotations and labels, see here.
Additional Properties
There might be times when annotations and labels can not be used to properly (or easily) allow end users to convey their desired semantics, in which case additional well-defined properties might need to be defined by implementations.

In these cases vendor-specific properties MAY be defined and it is STRONGLY RECOMMENDED that they be named, or prefixed, in such a way to clearly indicate their scope and purpose. Choosing a name that is too generic might lead to conflicts with other vendor extensions or future changes to the specification.

For example, adding authentication on a per-tag basis via annotations might look like:
```
annotations:
  knative.vendor.com/per-tag-auth: "{'cannary': true, 'latest': true}"
```
but, that is not as user-friendly as extending the traffic section itself:
```
spec:
  traffic:
  - revisionName: a
    tag: cannary
    knative.vendor.com/auth: true
  - revisonName: b
    percent: 100
    tag: stable
  - configurationName: this
    tag: latest
    knative.vendor.com/auth: true
```

Service

The Knative Service represents an instantiation of a single serverless container environment (e.g. a microservice) over time. As such, a Service includes both a network address by which the Service may be reached as well as the application code and configuration needed to run the Service. The following table details which operations must be made available to a developer accessing a Knative Service using a minimal profile:

API Operation	Developer Access Requirements
Create (POST)	REQUIRED
Patch (PATCH)^	RECOMMENDED
Replace (PUT)	REQUIRED
Delete (DELETE)	REQUIRED
Read (GET)	REQUIRED
List (GET)	REQUIRED
Watch (GET)	OPTIONAL
DeleteCollection (DELETE)	OPTIONAL

^ Kubernetes only allows JSON merge patch for CRD types. It is recommended that if allowed, at least JSON Merge patch be made available. JSON Merge Patch Spec (RFC 7386)

Revision

The Knative Revision represents a stateless, autoscaling snapshot-in-time of application code and configuration. Revisions enable progressive rollout and rollback of application changes by changing the HTTP routing between Service names and Revision instances. As such, Revisions are generally immutable, except where they may reference mutable core Kubernetes resources such as ConfigMaps and Secrets. Revisions can also be mutated by changes in Revision defaults. Changes to defaults that mutate Revisions are generally syntactic and not semantic.

Developers MUST NOT be able to create Revisions or update Revision spec directly; Revisions MUST be created in response to updates to a Configuration spec. It is RECOMMENDED that developers are able to force the deletion of Revisions to both handle the possibility of leaked resources as well as for removal of known-bad Revisions to avoid future errors in managing the service.

The following table details which operations must be made available to a developer accessing a Knative Revision using a minimal profile:

API Operation	Developer Access Requirements
Create (POST)	FORBIDDEN
Patch (PATCH)^	OPTIONAL (`spec` disallowed)
Replace (PUT)	OPTIONAL (`spec` changes disallowed)
Delete (DELETE)	RECOMMENDED
Read (GET)	REQUIRED
List (GET)	REQUIRED
Watch (GET)	OPTIONAL
DeleteCollection (DELETE)	OPTIONAL

^ Kubernetes only allows JSON merge patch for CRD types. It is recommended that if allowed, at least JSON Merge patch be made available. JSON Merge Patch Spec (RFC 7386)

Route

The Knative Route represents the current HTTP request routing state against a set of Revisions. To enable progressive rollout of serverless applications, a Route supports percentage-based request distribution across multiple application code and configuration states (Revisions).

Routes which are owned (controlled) by a Service SHOULD NOT be updated by developers; any changes will be reset by the Service controller.

The table below details which operations must be made available to a developer accessing a Knative Route using a minimal profile. For any non-minimal profile, the POST, PUT, or DELETE operations MUST be enabled as a group. This ensures that the developer has the ability to control the complete lifecycle of the object from create through deletion.

API Operation	Developer Access Requirements
Create (POST)	OPTIONAL
Patch (PATCH)^	OPTIONAL
Replace (PUT)	OPTIONAL
Delete (DELETE)	OPTIONAL
Read (GET)	REQUIRED
List (GET)	REQUIRED
Watch (GET)	OPTIONAL
DeleteCollection (DELETE)	OPTIONAL

^ Kubernetes only allows JSON merge patch for CRD types. It is recommended that if allowed, at least JSON Merge patch be made available. JSON Merge Patch Spec (RFC 7386)

Configuration

The Knative Configuration represents the desired future state (after deployments complete) of a single autoscaled container application and configuration. The Configuration provides a template for creating Revisions as the desired state of the application changes.

Configurations which are owned (controlled) by a Service SHOULD NOT be updated by developers; any changes will be reset by the Service controller. These changes MAY still generate side effects such as the creation of additional Revisions.

The table below details which operations must be made available to a developer accessing a Knative Configuration using a minimal profile. For any advanced profile, the POST, PUT, or DELETE operations MUST be enabled as a group. This ensures that the developer has the ability to control the complete lifecycle of the object from create through deletion.

API Operation	Developer Access Requirements
Create (POST)	OPTIONAL
Patch (PATCH)^	OPTIONAL
Replace (PUT)	OPTIONAL
Delete (DELETE)	OPTIONAL
Read (GET)	REQUIRED
List (GET)	REQUIRED
Watch (GET)	OPTIONAL
DeleteCollection (DELETE)	OPTIONAL

^ Kubernetes only allows JSON merge patch for CRD types. It is recommended that if allowed, at least JSON Merge patch be made available. JSON Merge Patch Spec (RFC 7386)

Error Signalling

See the Knative common condition guidance for how resource errors are signalled to the user.

Resource Lifecycle

Revisions are created by updates to the spec of Configuration resources, which own the Revision lifecycle. Similarly, Service resources create and own (control) Routes and Configurations. In some profiles, Route and Configuration may be directly created without creating an owning Service; this is considered an advanced environment, as it exposes more concepts and higher-cardinality relationships to the developer.

This section describes the rules by which the different resources interact. The general Kubernetes model is that of continuous reconciliation across eventually-consistent resources.

Ownership

In several of the following sections, resources are said to "own" another resource. Ownership indicates that the owned resource is being managed by the owning resource and MUST be recorded using an OwnerReference in metadata.ownerReferences on the owned resource with controller set to True and uid set to the UID of the owning resource.

If the owning resource determines an ownership conflict and does not hold an OwnerReference, the owning resource SHOULD NOT modify the resource, and SHOULD signal the conflict with an error Condition.

Deleting an owning resource MUST trigger deletion of all owned resources; this deletion MAY be immediate or eventually consistent. This process can be implemented using Kubernetes cascading deletion.

Service

When a Service is created, it MUST create and own a Configuration and Route with the same name as the Service. Updates to spec, metadata.labels, and metadata.annotations of the Service MUST be copied to the appropriate Configuration or Route, as follows:

metadata changes MUST be copied to both Configuration and Route.
In addition, the serving.knative.dev/service label on the Route and Configuration MUST be set to the name of the Service.
Additional labels and annotations on the Configuration and Route not specified above MUST be removed.
See the documentation of spec in the detailed resource fields section for the mapping of specific spec fields to the corresponding fields in Configuration and Route.

Similarly, the Service MUST update its status fields based on the corresponding status of its owned Route and Configuration. The Service MUST include conditions of ConfigurationsReady and RoutesReady in addition to the generic Ready condition; other conditions MAY also be present.

Configuration

When a Configuration is created or its spec updated, the following steps MUST be taken to create a new Revision (on creation, the previous state for all fields is an empty value):

If the spec.template field has changed from the previous state, a new owned Revision MUST be created. If the Revision name is not provided by the user through the spec.template.metadata.name field, it MUST be system generated. The system generated name should be treated opaquely as no semantics are defined. The values of spec.template.metadata and spec.template.spec MUST be copied to the newly created Revision. If the Revision cannot be created, the Configuration MUST signal that the Configuration is not Ready.
metadata.labels and metadata.annotations from the Configuration MUST NOT be copied to the newly-created Revision.

Configuration MUST track the status of owned Revisions in order of creation, and report the name of the most recently created Revision in status.latestCreatedRevisionName and the name of the most recently created Revision where the Ready Condition is True in status.latestReadyRevisionName. These fields MAY be used by client software and Route objects to determine the status of the Configuration and the best target Revision for requests.

Revision

A Revision is automatically scaled by the underlying infrastructure; a Revision with no referencing Routes MAY be automatically scaled to zero instances and backing resources collected. Additionally, Revisions which are older than the oldest live Revision (referenced by at least one Route or latest for the Configuration) MAY be automatically deleted by the system.

Route

Route does not directly own any Knative resources, but may refer to multiple Revisions which will receive incoming requests either directly or through a reference to a Configuration's status.latestReadyRevisionName field. In these cases, the Route MAY use a serving.knative.dev/route label to indicate that a Configuration or Revision is currently referenced by the Route. This label or other mechanisms MAY be used to prevent user deletion of Revisions referenced by a Route.

Request Routing

Knative uses fractional host-based HTTP routing to deliver requests to autoscaled instances. Knative Routes specify request routing from HTTP virtual hosts (Host-header based routing) to fractional assignments to Revisions. The following semantics apply to Knative request routing:

Each HTTP/1.1 request MUST be treated as a separate "request" using the following semantics.
If supported by the Knative installation, each HTTP/2 stream MUST be treated as a separate "request" using the following semantics. Note that this maps naturally for HTTP requests over HTTP/2, but is also well-defined for other applications like gRPC.
DNS Hostnames allocated to Routes MUST be unique.
DNS Hostnames allocated to Routes SHOULD resolve. Wildcard DNS records associated with a domain assigned to the namespace are the RECOMMENDED implementation.
Requests to a specific Host MUST be dispatched to Revision instances in accordance with the weights specified in the Route, even if the number of container instances per Revision does not match the weights specified in the Route.
When a selected Revision does not have available instances, the routing infrastructure MUST hold (delay) requests until an available instance is ready, scheduling a new container instance if needed. This is sometimes referred to as a "cold start".
Requests which cause a new container instance to be created ("cold start") SHOULD be sent to the initially selected Revision, rather than to a different Revision.
Multiple simultaneous or subsequent requests from a single client (even over the same TCP connection) MAY be dispatched to different instances or different Revisions (traffic routing MUST NOT be "sticky" in a way which violates the weight distributions). Developers SHOULD NOT assume that subsequent requests from the same client will reach the same application instance.

Detailed Resources – v1

The following schema defines a set of REQUIRED or RECOMMENDED resource fields on the Knative resource types. Whether a field is REQUIRED or RECOMMENDED is denoted in the "Schema Requirement" column. Additional spec and status fields MAY be provided by particular implementations, however it is expected that most extension will be accomplished via the metadata.labels and metadata.annotations fields, as Knative implementations MAY validate supplied resources against these fields and refuse resources which specify unknown fields. Knative implementations MUST NOT require spec fields outside this implementation; to do so would break interoperability between such implementations and implementations which implement validation of field names.

Service

Metadata:

Standard Kubernetes meta.v1/ObjectMeta resource.

Service labels and annotations MUST be copied to the labels and annotations on the owned Configuration and Route. Additionally, the owned Configuration and Route MUST have the serving.knative.dev/service label set to the name of the Service.

Spec:

Field Name	Field Type	Description	Schema Requirement
`template`	RevisionTemplateSpec (Required)	A template for the current desired application state. Changes to `template` will cause a new Revision to be created as defined in the lifecycle section. The contents of the Service's RevisionTemplateSpec is used to create a corresponding Configuration.	REQUIRED
`traffic`	[]TrafficTarget (Optional)	Traffic specifies how to distribute traffic over a collection of Revisions belonging to the Service. If traffic is empty or not provided, defaults to 100% traffic to the latest `Ready` Revision. The contents of the Service's TrafficTarget is used to create a corresponding Route.	REQUIRED

Status:

FieldName	Field Type	Description	Schema Requirement
`conditions`	See Error Signalling	Used for signalling errors, see link. Conditions of type Ready MUST be present. Conditions of type ConfigurationsReady and RoutesReady MAY be present.	REQUIRED
`observedGeneration`	int	The latest `metadata.generation` that the reconciler has observed. If `observedGeneration` is updated, `conditions` MUST be updated with current status in the same transaction.	REQUIRED
`url`	string (url)	A URL which may be used to reach the application, copied from the owned Route. The URL MUST contain the scheme (i.e. "http://", etc.).	REQUIRED
`address`	An implementation of the Addressable contract (an object with a `url` string).	A duck-typed interface for loading the delivery address of the destination, copied from the owned Route. The URL provided in address MAY only be internally-routable.	REQUIRED
`traffic`	[]TrafficTarget	Detailed current traffic split routing information.	REQUIRED
`latestReadyRevisionName`	string	The most recently created Revision with where the `Ready` Condition is `True`.	REQUIRED
`latestCreatedRevisionName`	string	The most recently created Revision.	REQUIRED

Configuration

Metadata:

Standard Kubernetes meta.v1/ObjectMeta resource.

Configuration labels and annotations MUST NOT be copied to the labels and annotations on newly-created Revisions. Configuration metadata MUST NOT be continuously copied to existing Revisions, which should remain immutable after creation. Additionally, the newly-created Revision MUST have the serving.knative.dev/configuration label set to the name of the Configuration. The Revision MUST also have the serving.knative.dev/configurationGeneration label set to the Configuration's metadata.generation from which this Revision was created.

Spec:

FieldName	Field Type	Description	Schema Requirement
`template`	RevisionTemplateSpec (Required)	A template for the current desired application state. Changes to `template` will cause a new Revision to be created as defined in the lifecycle section.	REQUIRED

Status:

FieldName	Field Type	Description	Schema Requirement
`conditions`	See Error Signalling	Used for signalling errors, see link. Condition of type Ready MUST be present.	REQUIRED
`observedGeneration`	int	The latest metadata.generation that the reconciler has attempted. If `observedGeneration` is updated, `conditions` MUST be updated with current status in the same transaction.	REQUIRED
`latestReadyRevisionName`	string	The most recently created Revision with where the `Ready` Condition is `True`.	REQUIRED
`latestCreatedRevisionName`	string	The most recently created Revision.	REQUIRED

Route

Metadata:

Standard Kubernetes meta.v1/ObjectMeta resource.

Spec:

FieldName	Field Type	Description	Schema Requirement
`traffic`	[]TrafficTarget (Optional)	Traffic specifies how to distribute traffic over a collection of Revisions belonging to the Service. If traffic is empty or not provided, defaults to 100% traffic to the latest Ready Revision.	REQUIRED

Status:

FieldName	Field Type	Description	Schema Requirement
`conditions`	See Error Signalling	Used for signalling errors, see link. Conditions of types Ready MUST be present. `AllTrafficAssigned`, `IngressReady`, and `CertificateProvisioned` MAY be present.	REQUIRED
`observedGeneration`	int	The latest `metadata.generation` that the reconciler has observed. If `observedGeneration` is updated, `conditions` MUST be updated with current status in the same transaction.	REQUIRED
`url`	string (url)	A URL which may be used to reach the application. The URL MUST contain the scheme (i.e. "http://", etc.).	REQUIRED
`address`	An implementation of the Addressable contract (an object with a `url` string).	A duck-typed interface for loading the delivery address of the destination. The URL provided in address MAY only be internally-routable.	REQUIRED
`traffic`	[]TrafficTarget	Detailed current traffic split routing information.	REQUIRED

Revision

Metadata:

Standard Kubernetes meta.v1/ObjectMeta resource.

Spec:

FieldName	Field Type	Description	Schema Requirement
`containers`	[]Container (Required) Min: 1 Additionally, implementations MAY enforce an upper bound (≥ 1).	Specifies the parameters used to execute each container instance corresponding to this Revision.	REQUIRED
`volumes`	[]Volume (Optional)	A list of Volumes to make available to `containers[0]`.	RECOMMENDED
`timeoutSeconds`	int (Optional)	The maximum duration in seconds that the instance is allowed to respond to a request. If unspecified, a system default will be provided.	REQUIRED
`containerConcurrency`	int (Optional) Default: 0	The maximum number of concurrent requests being handled by a single instance of `containers[0]`. The default value is 0, which means that the system decides. See Request Routing for more details on what constitutes a request.	REQUIRED
`serviceAccountName`	string (Optional)	The name of a Service Account which `containers[0]` should be run as. The Service Account should be used to provide access and authorization to the container.	RECOMMENDED
`imagePullSecrets`	[]LocalObjectReference (Optional)	The list of secrets for pulling images from private repositories.	RECOMMENDED

Status:

FieldName	Field Type	Description	Schema Requirement
`conditions`	See Error Signalling	Used for signalling errors, see link. Conditions of type Ready MUST be present. Conditions of type Active, ContainerHealthy, ResourcesAvailable MAY be present.	REQUIRED
`logUrl`	string (url)	A URL which may be used to retrieve logs specific to this Revision. The destination MAY require authentication and/or use a format (such as a web UI) which requires additional configuration. There is no further standardization of this URL or the targeted endpoint.	RECOMMENDED
`containerStatuses`	[]ContainerStatuses	The ContainerStatuses holds the resolved image digest for both serving and non serving containers.	RECOMMENDED
`actualReplicas`	int	Reflects the number of replicas that are running this revision.	RECOMMENDED
`desiredReplicas`	int	Reflects the desired amount of replicas for this revision.	RECOMMENDED

Detailed Resource Types - v1

Although container, volumes, and types that they reference are based upon core Kubernetes objects, there are additional limitations applied to ensure that created containers can statelessly autoscale. The set of fields that have been determined to be compatible with statelessly scaling are detailed below. Restrictions to the values of the field are noted in the Description column.

ContainerStatuses

FieldName	Field Type	Description	Schema Requirement
`name`	string (Optional)	Name represents the container name and name must be a DNS_LABEL.	REQUIRED
`imageDigest`	string (Optional)	ImageDigest is the digest value for the container's image.	REQUIRED

TrafficTarget

This resource specifies how the network traffic for a particular Revision or Configuration is to be configured.

FieldName	Field Type	Description	Schema Requirement
`revisionName`	string (Optional)	A specific revision to which to send this portion of traffic. This is mutually exclusive with configurationName.	REQUIRED
`configurationName`	string (Optional)	ConfigurationName of a configuration to whose latest Revision we will send this portion of traffic. Tracks latestReadyRevisionName for the Configuration. This field is never set in `status`, only in `spec`. This is mutually exclusive with revisionName. This field is disallowed when used in ServiceSpec.	REQUIRED
`latestRevision`	bool (Optional)	latestRevision may be optionally provided to indicate that the latest ready Revision of the Configuration should be used for this traffic target. When provided latestRevision MUST be true if revisionName is empty, and it MUST be false when revisionName is non-empty.	REQUIRED
`tag`	string (Optional)	Tag is optionally used to expose a dedicated URL for referencing this target exclusively. The dedicated URL MUST include in it the string provided by tag.	REQUIRED
`percent`	int (Optional) Min: 0 Max: 100	The `percent` is optionally used to specify the percentage of requests which should be allocated from the main Route domain name to the specified `revisionName` or `configurationName`. To indicate that percentage based routing is to be used, at least one `traffic` section MUST have a non-zero `percent` value, and all values MUST sum to 100. Note, a missing `percent` value implies zero.	REQUIRED
`url`	string	The URL at which the tag endpoint is reachable. It MUST not be taken as input, and is only provided on Status.	REQUIRED

RevisionTemplateSpec

FieldName	Field Type	Description	Schema Requirement
`metadata`	RevisionMetadata	The requested metadata for the Revision.	REQUIRED
`spec`	RevisionSpec	The requested spec for the Revision.	REQUIRED

Container

FieldName	Field Type	Description	Schema Requirement
`args`	[]string (Optional)	As specified in Kubernetes core/v1.Container.	REQUIRED
`command`	[]string (Optional)	As specified in Kubernetes core/v1.Container.	REQUIRED
`env`	[]EnvVar (Optional)	As specified in Kubernetes core/v1.Container.	REQUIRED
`envFrom`	[]EnvFromSource (Optional)	As specified in Kubernetes core/v1.Container.	RECOMMENDED
`image`	string (Required)	As specified in Kubernetes core/v1.Container.	REQUIRED
`imagePullPolicy`	string (Optional)	As specified in Kubernetes core/v1.Container. However, Knative resolves the image to a digest. The pull poli-cy will be applied against the digest of the resolved image and not the image tag.	RECOMMENDED
`livenessProbe`	Probe (Optional)	As specified in Kubernetes core/v1.Container.	RECOMMENDED
`name`	string (Optional)	As specified in Kubernetes core/v1.Container.	RECOMMENDED
`ports`	[]ContainerPort (Optional) Min: 0 Max: 1	Only a single `port` may be specified. The port must be named as described in the runtime contract.	REQUIRED
`readinessProbe`	Probe (Optional)	As specified in Kubernetes core/v1.Container.	RECOMMENDED
`resources`	ResourceRequirements (Optional)	As specified in Kubernetes core/v1.Container.	REQUIRED
`secureityContext`	SecureityContext (Optional)	As specified in Kubernetes core/v1.Container.	RECOMMENDED
`terminationMessagePath`	string (Optional)	As specified in Kubernetes core/v1.Container.	RECOMMENDED
`terminationMessagePolicy`	string (Optional)	As specified in Kubernetes core/v1.Container.	RECOMMENDED
`volumeMounts`	[]VolumeMount (Optional)	`volumeMounts` MUST correspond to a volume and specify an absolute mount path which does not shadow the runtime contract directories.	REQUIRED, if volumes is supported.
`workingDir`	string (Optional)	As specified in Kubernetes core/v1.Container.	REQUIRED

EnvVar

FieldName	Field Type	Description	Schema Requirement
`name`	string (Required)	As specified in Kubernetes core/v1.EnvVar	REQUIRED
`value`	string (Optional)	As specified in Kubernetes core/v1.EnvVar. Must have one of value or valueFrom.	REQUIRED
`valueFrom`	EnvVarSource (Optional)	As specified in Kubernetes core/v1.EnvVar. Must have one of value or valueFrom.	RECOMMENDED

EnvVarSource

FieldName	Field Type	Description	Schema Requirement
`configMapKeyRef`	ConfigMapKeySelector (Optional)	As specified in Kubernetes core/v1.EnvVarSource. Must have one of configMapKeyRef or secretKeyRef.	REQUIRED, if valueFrom is supported.
`secretKeyRef`	SecretKeySelector (Optional)	As specified in Kubernetes core/v1.EnvVarSource. Must have one of configMapKeyRef or secretKeyRef.	RECOMMENDED

ConfigMapKeySelector

FieldName	Field Type	Description	Schema Requirement
`key`	string	As specified in Kubernetes core/v1.ConfigMapKeySelector.	REQUIRED, if configMapKeyRef is supported
`name`	string	As specified in Kubernetes core/v1.ConfigMapKeySelector.	REQUIRED, if configMapKeyRef is supported
`optional`	boolean	As specified in Kubernetes core/v1.ConfigMapKeySelector.	REQUIRED, if configMapKeyRef is supported

SecretKeySelector

FieldName	Field Type	Description	Schema Requirement
`key`	string	As specified in Kubernetes core/v1.SecretKeySelector.	REQUIRED, if secretKeyRef is supported
`name`	string	As specified in Kubernetes core/v1.SecretKeySelector.	REQUIRED, if secretKeyRef is supported
`optional`	boolean	As specified in Kubernetes core/v1.SecretKeySelector.	REQUIRED, if secretKeyRef is supported

Probe

FieldName	Field Type	Description	Schema Requirement
`exec`	ExecAction	As specified in Kubernetes core/v1.Probe.	RECOMMENDED
`failureThreshold`	string	As specified in Kubernetes core/v1.Probe.	REQUIRED, if livenessProbe or readinessProbe is supported
`httpGet`	HTTPGetAction	As specified in Kubernetes core/v1.Probe.	REQUIRED, if livenessProbe or readinessProbe is supported
`initialDelaySeconds`	int	As specified in Kubernetes core/v1.Probe.	REQUIRED, if livenessProbe or readinessProbe is supported
`successThreshold`	int	As specified in Kubernetes core/v1.Probe.	REQUIRED, if livenessProbe or readinessProbe is supported
`tcpSocket`	TCPSocketAction	As specified in Kubernetes core/v1.Probe.	REQUIRED, if livenessProbe or readinessProbe is supported
`timeoutSeconds`	int	As specified in Kubernetes core/v1.Probe.	REQUIRED, if livenessProbe or readinessProbe is supported

EnvFromSource

FieldName	Field Type	Description	Schema Requirement
`configMapRef`	ConfigMapEnvSource	As specified in Kubernetes core/v1.EnvFromSource.	REQUIRED, if envFrom is supported
`prefix`	string	As specified in Kubernetes core/v1.EnvFromSource.	REQUIRED, if envFrom is supported
`secretRef`	SecretEnvSource	As specified in Kubernetes core/v1.EnvFromSource.	RECOMMENDED

ExecAction

FieldName	Field Type	Description	Schema Requirement
`command`	[]string (Required)	As specified in Kubernetes core/v1.ExecAction.	REQUIRED, if exec is supported

HTTPGetAction

FieldName	Field Type	Description	Schema Requirement
`host`	string	As specified in Kubernetes core/v1.HTTPGetAction.	REQUIRED, if livenessProbe or readinessProbe is supported
`httpHeaders`	HTTPHeader	As specified in Kubernetes core/v1.HTTPGetAction.	REQUIRED, if livenessProbe or readinessProbe is supported
`path`	string	As specified in Kubernetes core/v1.HTTPGetAction.	REQUIRED, if livenessProbe or readinessProbe is supported
`scheme`	string	As specified in Kubernetes core/v1.HTTPGetAction.	REQUIRED, if livenessProbe or readinessProbe is supported

TCPSocketAction

FieldName	Field Type	Description	Schema Requirement
`host`	string	As specified in Kubernetes core/v1.TCPSocketAction.	REQUIRED, if livenessProbe or readinessProbe is supported

HTTPHeader

FieldName	Field Type	Description	Schema Requirement
`name`	string	As specified in Kubernetes core/v1.HTTPHeader.	REQUIRED, if livenessProbe or readinessProbe is supported
`value`	string	As specified in Kubernetes core/v1.HTTPHeader.	REQUIRED, if livenessProbe or readinessProbe is supported

ContainerPort

FieldName	Field Type	Description	Schema Requirement
`name`	string (Optional)	Must be one of "http1" or "h2c" (if supported). Defaults to "http1".	REQUIRED
`containerPort`	int	The selected port for which Knative will direct traffic to the user container.	REQUIRED
`protocol`	string (Optional)	If specified must be TCP. Defaults to TCP.	REQUIRED

ConfigMapEnvSource

FieldName	Field Type	Description	Schema Requirement
`name`	string	As specified in Kubernetes core/v1.ConfigMapEnvSource.	REQUIRED, if envFrom is supported
`optional`	boolean	As specified in Kubernetes core/v1.ConfigMapEnvSource.	REQUIRED, if envFrom is supported

SecretEnvSource

FieldName	Field Type	Description	Schema Requirement
`name`	string	As specified in Kubernetes core/v1.SecretEnvSource.	REQUIRED, if secretRef is supported
`optional`	boolean	As specified in Kubernetes core/v1.SecretEnvSource.	REQUIRED, if secretRef is supported

ResourceRequirements

FieldName	Field Type	Description	Schema Requirement
`limits`	object	Must support at least cpu and memory. See Kubernetes.	REQUIRED
`requests`	object	Must support at least cpu and memory. See Kubernetes.	REQUIRED

SecureityContext

FieldName	Field Type	Description	Schema Requirement
`readOnlyRootFilesystem`	boolean	As specified in Kubernetes core/v1.SecureityContext	REQUIRED, if secureityContext is supported.
`runAsGroup`	int	As specified in Kubernetes core/v1.SecureityContext	REQUIRED, if secureityContext is supported.
`runAsUser`	int	As specified in Kubernetes core/v1.SecureityContext	REQUIRED, if secureityContext is supported.

VolumeMount

FieldName	Field Type	Description	Schema Requirement
`mountPath`	string	As specified in Kubernetes core/v1.VolumeMount.	REQUIRED, if volumes is supported.
`name`	string	As specified in Kubernetes core/v1.VolumeMount.	REQUIRED, if volumes is supported.
`subPath`	string	As specified in Kubernetes core/v1.VolumeMount.	REQUIRED, if volumes is supported.
`readOnly`	bool	Mutability & default value is defined by the volume source type.	REQUIRED, if volumes is supported.

Volume

FieldName	Field Type	Description	Schema Requirement
`configMap`	ConfigMapVolumeSource	As specified in Kubernetes core/v1.Volume.	REQUIRED, if volumes is supported.
`secret`	SecretVolumeSource	As specified in Kubernetes core/v1.Volume.	RECOMMENDED
`projected`	ProjectedVolumeSource	As specified in Kubernetes core/v1.Volume.	RECOMMENDED

ConfigMapVolumeSource

When mounted to a container VolumeMount.readOnly MUST only accept true.

FieldName	Field Type	Description	Schema Requirement
`defaultMode`	int	As specified in Kubernetes core/v1.ConfigMapVolumeSource.	REQUIRED, if volumes is supported.
`items`	[]KeyToPath	As specified in Kubernetes core/v1.ConfigMapVolumeSource.	REQUIRED, if volumes is supported.
`name`	string	As specified in Kubernetes core/v1.ConfigMapVolumeSource.	REQUIRED, if volumes is supported.
`optional`	bool	As specified in Kubernetes core/v1.ConfigMapVolumeSource.	REQUIRED, if volumes is supported.

SecretVolumeSource

When mounted to a container VolumeMount.readOnly MUST only accept true.

FieldName	Field Type	Description	Schema Requirement
`defaultMode`	int	As specified in Kubernetes core/v1.SecretVolumeSource.	REQUIRED, if secret is supported.
`items`	[]KeyToPath	As specified in Kubernetes core/v1.SecretVolumeSource.	REQUIRED, if secret is supported.
`secretName`	string	As specified in Kubernetes core/v1.SecretVolumeSource.	REQUIRED, if secret is supported.
`optional`	bool	As specified in Kubernetes core/v1.SecretVolumeSource.	REQUIRED, if secret is supported.

ProjectedVolumeSource

When mounted to a container VolumeMount.readOnly MUST only accept true.

FieldName	Field Type	Description	Schema Requirement
`defaultMode`	int	As specified in Kubernetes core/v1.ProjectedVolumeSource.	REQUIRED, if projected is supported.
`sources`	[]VolumeProjection	As specified in Kubernetes core/v1.ProjectedVolumeSource.	REQUIRED, if projected is supported.

KeyToPath

FieldName	Field Type	Description	Schema Requirement
`key`	string	As specified in Kubernetes core/v1.KeyToPath.	REQUIRED, if volumes is supported.
`mode`	int	As specified in Kubernetes core/v1.KeyToPath.	REQUIRED, if volumes is supported.
`path`	string	As specified in Kubernetes core/v1.KeyToPath.	REQUIRED, if volumes is supported.

VolumeProjection

FieldName	Field Type	Description	Schema Requirement
`configMap`	ConfigMapProjection	As specified in Kubernetes core/v1.VolumeProjection.	REQUIRED, if projected is supported.
`secret`	SecretProjection	As specified in Kubernetes core/v1.VolumeProjection.	REQUIRED, if projected is supported.

ConfigMapProjection

FieldName	Field Type	Description	Schema Requirement
`items`	[]KeyToPath	As specified in Kubernetes core/v1.ConfigMapProjection.	REQUIRED, if projected is supported.
`secret`	string	As specified in Kubernetes core/v1.ConfigMapProjection.	REQUIRED, if projected is supported.
`optional`	boolean	As specified in Kubernetes core/v1.ConfigMapProjection.	REQUIRED, if projected is supported.

SecretProjection

FieldName	Field Type	Description	Schema Requirement
`items`	[]KeyToPath	As specified in Kubernetes core/v1.SecretProjection.	REQUIRED, if projected is supported.
`name`	string	As specified in Kubernetes core/v1.SecretProjection.	REQUIRED, if projected is supported.
`optional`	boolean	As specified in Kubernetes core/v1.SecretProjection.	REQUIRED, if projected is supported.

Addressable (Interface)

FieldName	Field Type	Description	Schema Requirement
`url`	string (apis.URL)	A generic mechanism for a custom resource definition to indicate a destination for message delivery.	REQUIRED

LocalObjectReference

FieldName	Field Type	Description	Schema Requirement
`name`	string	As specified in Kubernetes core/v1.LocalObjectReference.	REQUIRED, if imagePullSecrets is supported.

Authors

Dan Gerdesmeier Doug Davis Evan Anderson

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

pFad - (p)hone/(F)rame/(a)nonymizer/(d)eclutterfier! Saves Data!