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

The following is an example definition of a replication controller: 

apiVersion: v1 kind: ReplicationController metadata: name: frontend-1 spec: replicas: 1 1 selector: 2 name: frontend template: 3 metadata: labels: 4 name: frontend 5 spec: containers: - image: openshift/hello-openshift name: helloworld ports: - containerPort: 8080 protocol: TCP restartPolicy: Always 

1 The number of copies of the pod to run. 

2 The label selector of the pod to run. 

3 A template for the pod the controller creates. 

4 Labels on the pod should include those from the label selector. 

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

## 3.1.1.2. Replica sets 

Similar to a replication controller, a ReplicaSet  is a native Kubernetes API object that ensures 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. 

<img src='content_image/857434.jpg'>

The following is an example ReplicaSet  definition: 

## NOTE 

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. 

