This is a cache of https://docs.openshift.com/container-platform/4.6/rest_api/workloads_apis/workloads-apis-index.html. It is a snapshot of the page at 2024-11-25T23:59:03.774+0000.
About Workloads <strong>api</strong>s - Workloads <strong>api</strong>s | <strong>api</strong> reference | OpenShift Container Platform 4.6
×

BuildConfig [build.openshift.io/v1]

Description

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.

Type

object

Build [build.openshift.io/v1]

Description

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.

Type

object

CronJob [batch/v1beta1]

Description

CronJob represents the configuration of a single cron job.

Type

object

DaemonSet [apps/v1]

Description

DaemonSet represents the configuration of a daemon set.

Type

object

Deployment [apps/v1]

Description

Deployment enables declarative updates for Pods and ReplicaSets.

Type

object

DeploymentConfig [apps.openshift.io/v1]

Description

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.

Type

object

Job [batch/v1]

Description

Job represents the configuration of a single job.

Type

object

Pod [core/v1]

Description

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

Type

object

ReplicationController [core/v1]

Description

ReplicationController represents the configuration of a replication controller.

Type

object

PersistentVolume [core/v1]

Description

PersistentVolume (PV) is a storage resource provisioned by an administrator. It is analogous to a node. More info: https://kubernetes.io/docs/concepts/storage/persistent-volumes

Type

object

ReplicaSet [apps/v1]

Description

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

Type

object

StatefulSet [apps/v1]

Description

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.

Type

object