Workloads APIs

Build configurations define a build process for new container images. There are three types of builds possible - a container image build using a Dockerfile, a Source-to-Image build that uses a specially prepared base image that accepts source code that it can make runnable, and a custom build that can run // arbitrary container images as a base and accept the build parameters. Builds run on the cluster and on completion are pushed to the container image registry specified in the "output" section. A build can be triggered via a webhook, when the base image changes, or when a user manually requests a new build be // created.

Each build created by a build configuration is numbered and refers back to its parent configuration. Multiple builds can be triggered at once. Builds that do not have "output" set can be used to test code or run a verification build.

Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer).

Build encapsulates the inputs needed to produce a new deployable image, as well as the status of the execution and a reference to the Pod which executed the build.

Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer).

BuildLog is the (unused) resource associated with the build log redirector

Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer).

BuildRequest is the resource used to pass parameters to build generator

Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer).

CronJob represents the configuration of a single cron job.

DaemonSet represents the configuration of a daemon set.

deployment enables declarative updates for Pods and ReplicaSets.

deployment Configs define the template for a pod and manages deploying new images or configuration changes. A single deployment configuration is usually analogous to a single micro-service. Can support many different deployment patterns, including full restart, customizable rolling updates, and fully custom behaviors, as well as pre- and post- deployment hooks. Each individual deployment is represented as a replication controller.

A deployment is "triggered" when its configuration is changed or a tag in an Image Stream is changed. Triggers can be disabled to allow manual control over a deployment. The "strategy" determines how the deployment is carried out and may be changed at any time. The latestVersion field is updated when a new deployment is triggered by any means.

Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer). Deprecated: Use deployments or other means for declarative updates for pods instead.

deploymentConfigRollback provides the input to rollback generation.

Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer).

deploymentLog represents the logs for a deployment

Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer).

deploymentRequest is a request to a deployment config for a new deployment.

Compatibility level 1: Stable within a major release for a minimum of 12 months or 3 minor releases (whichever is longer).

Job represents the configuration of a single job.

Pod is a collection of containers that can run on a host. This resource is created by clients and scheduled onto hosts.

ReplicationController represents the configuration of a replication controller.

ReplicaSet ensures that a specified number of pod replicas are running at any given time.

StatefulSet represents a set of pods with consistent identities. Identities are defined as: - Network: A single stable DNS and hostname. - Storage: As many VolumeClaims as requested.

The StatefulSet guarantees that a given network identity will always map to the same storage identity.