Deployments

Replication controllers

A
replication
controller ensures that a specified number of replicas of a pod are running at
all times. If pods exit or are deleted, the replication controller acts to
instantiate more up to the defined number. Likewise, if there are more running
than desired, it deletes as many as necessary to match the defined amount.

A replication controller configuration consists of:

The number of replicas desired (which can be adjusted at runtime).

A pod definition to use when creating a replicated pod.

A selector for identifying managed pods.

A selector is a set of labels assigned to
the pods that are managed by the replication controller. These labels are
included in the pod definition that the replication controller instantiates.
The replication controller uses the selector to determine how many
instances of the pod are already running in order to adjust as needed.

The replication controller does not perform auto-scaling based on load or
traffic, as it does not track either. Rather, this would require its replica
count to be adjusted by an external auto-scaler.

A replication controller is a core Kubernetes object called ReplicationController.

The maximum name length after expanding any parameters is 63 characters.

Replica set

Similar to a replication controller, a replica set
ensures that a specified number of pod replicas are running at any given time.
The difference between a replica set and a replication controller is that a
replica set supports set-based selector requirements whereas a replication
controller only supports equality-based selector requirements.

Only use replica sets if you require custom update orchestration or do not
require updates at all, otherwise, use
Deployments.
Replica sets can be used independently, but are used by deployments to
orchestrate pod creation, deletion, and updates. Deployments manage their
replica sets automatically, provide declarative updates to pods, and do not have
to manually manage the replica sets that they create.

A label query over a set of resources. The result of matchLabels and
matchExpressions are logically conjoined.

2

Equality-based selector to specify resources with labels that match the
selector.

3

Set-based selector to filter keys. This selects all resources with key equal
to tier and value equal to frontend.

Jobs

A job is similar to a replication controller, in that its purpose is to create
pods for specified reasons. The difference is that replication controllers are
designed for pods that will be continuously running, whereas jobs are for
one-time pods. A job tracks any successful completions and when the specified
amount of completions have been reached, the job itself is completed.

The following example computes π to 2000 places, prints it out, then completes:

Deployments and Deployment Configurations

Building on replication controllers, OpenShift Container Platform adds expanded support
for the software development and deployment lifecycle with the concept
of deployments. In the simplest case, a deployment just creates a new
replication controller and lets it start up pods. However, OpenShift Container Platform
deployments also provide the ability to transition from an existing
deployment of an image to a new one and also define hooks to be run
before or after creating the replication controller.

The OpenShift Container Platform DeploymentConfig object defines the following
details of a deployment:

The elements of a ReplicationController definition.

Triggers for creating a new deployment automatically.

The strategy for transitioning between deployments.

Life cycle hooks.

Each time a deployment is triggered, whether manually or automatically,
a deployer pod manages the deployment (including scaling down the old
replication controller, scaling up the new one, and running hooks).
The deployment pod remains for an indefinite amount of time after it
completes the deployment in order to retain its logs of the deployment.
When a deployment is superseded by another, the previous replication
controller is retained to enable easy rollback if needed.

For detailed instructions on how to create and interact with deployments,
refer to Deployments.

Here is an example DeploymentConfig definition with some
omissions and callouts: