ReplicaSet [page]deterministic

A ReplicaSet's purpose is to maintain a stable set of replica Pods running at any given time. As such, it is often used to guarantee the availability of a specified number of identical Pods.

## How a ReplicaSet works

A ReplicaSet is defined with fields, including a selector that specifies how to identify Pods it can acquire, a number of replicas indicating how many Pods it should be maintaining, and a pod template specifying the data of new Pods it should create to meet the number of replicas criteria. A ReplicaSet then fulfills its purpose by creating and deleting Pods as needed to reach the desired number. When a ReplicaSet needs to create new Pods, it uses its Pod template.

A ReplicaSet is linked to its Pods via the Pods' [metadata.ownerReferences](/docs/concepts/architecture/garbage-collection/#owners-dependents) field, which specifies what resource the current object is owned by. All Pods acquired by a ReplicaSet have their owning ReplicaSet's identifying information within their ownerReferences field. It's through this link that the ReplicaSet knows of the state of the Pods it is maintaining and plans accordingly.

A ReplicaSet identifies new Pods to acquire by using its selector. If there is a Pod that has no OwnerReference or the OwnerReference is not a [controller](#gloss:controller) and it matches a ReplicaSet's selector, it will be immediately acquired by said ReplicaSet.

## When to use a ReplicaSet

A ReplicaSet ensures that a specified number of pod replicas are running at any given time. However, a Deployment is a higher-level concept that manages ReplicaSets and provides declarative updates to Pods along with a lot of other useful features. Therefore, we recommend using Deployments instead of directly using ReplicaSets, unless you require custom update orchestration or don't require updates at all.

This actually means that you may never need to manipulate ReplicaSet objects: use a Deployment instead, and define your application in the spec section.

## Example

Saving this manifest into `frontend.yaml` and submitting it to a Kubernetes cluster will create the defined ReplicaSet and the Pods that it manages.

```shell kubectl apply -f https://kubernetes.io/examples/controllers/frontend.yaml ```

You can then get the current ReplicaSets deployed:

```shell kubectl get rs ```

And see the frontend one you created:

``` NAME DESIRED CURRENT READY AGE frontend 3 3 3 6s ```

You can also check on the state of the ReplicaSet:

```shell kubectl describe rs/frontend ```

And you will see output similar to:

``` Name: frontend Namespace: default Selector: tier=frontend Labels: app=guestbook tier=frontend Annotations: <none> Replicas: 3 current / 3 desired Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed Pod Template: Labels: tier=frontend Containers: php-redis: Image: us-docker.pkg.dev/google-samples/containers/gke/gb-frontend:v5 Port: <none> Host Port: <none> Environment: <none> Mounts: <none> Volumes: <none> Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal SuccessfulCreate 13s replicaset-controller Created pod: frontend-gbgfx Normal SuccessfulCreate 13s replicaset-controller Created pod: frontend-rwz57 Normal SuccessfulCreate 13s replicaset-controller Created pod: frontend-wkl7w ```

And lastly you can check for the Pods brought up:

```shell kubectl get pods ```

You should see Pod information similar to:

``` NAME READY STATUS RESTARTS AGE frontend-gbgfx 1/1 Running 0 10m frontend-rwz57 1/1 Running 0 10m frontend-wkl7w 1/1 Running 0 10m ```

You can also verify that the owner reference of these pods is set to the frontend ReplicaSet. To do this, get the yaml of one of the Pods …(trimmed)