Skip to main content
ReplicaSets ensure a specified number of pod replicas are running at any time. They are typically managed by Deployments rather than created directly, but you can view, scale, and manage them when needed.

​
Key Concepts

ReplicaSet

A controller that maintains a stable set of replica pods running at any time.

Selector

Label selector that identifies which pods belong to the ReplicaSet.

Replicas

The desired number of pod instances to maintain.

Owner Reference

Link to the parent controller (usually a Deployment) that manages the ReplicaSet.

​
Required Permissions

ActionPermission
View replicasetsiam:project:infrastructure:kubernetes:read
Scale replicasetiam:project:infrastructure:kubernetes:write
Create replicasetiam:project:infrastructure:kubernetes:write
Edit replicasetiam:project:infrastructure:kubernetes:write
Delete replicasetiam:project:infrastructure:kubernetes:delete

​
ReplicaSet Status Values

StatusDescription
RunningAll desired replicas are ready
NotReadySome replicas are not ready yet
Scaled to 0ReplicaSet has zero replicas
UnknownStatus cannot be determined

​
ReplicaSet Metrics

MetricDescription
ReplicasDesired number of pods
ReadyPods that are ready (ready/desired)
AvailablePods available for service
Fully LabeledPods with all expected labels

​
How to View ReplicaSets

1

Select Cluster

Choose a cluster from the cluster dropdown.
2

Select Namespace

Choose a namespace or select “all” to view ReplicaSets across all namespaces.
3

Filter and Search

Use the search box to find ReplicaSets by name or controlling resource.
The “Controlled By” column shows the parent resource (usually a Deployment) that manages each ReplicaSet.

​
How to View ReplicaSet Details

1

Find the ReplicaSet

Locate the ReplicaSet in the list.
2

Click ReplicaSet Name

Click on the ReplicaSet name to open the detail drawer.
3

Review Details

View ReplicaSet information including:
  • Replica counts and status
  • Pod template specification
  • Label selectors
  • Owner references
  • Events

​
How to Scale a ReplicaSet

1

Find the ReplicaSet

Locate the ReplicaSet in the list.
2

Open Actions Menu

Click the actions menu (three dots) on the ReplicaSet row.
3

Click Scale

Select Scale to open the scale dialog.
4

Set Replica Count

Enter the desired number of replicas.
5

Apply

Click Scale to apply the change.
If the ReplicaSet is managed by a Deployment, scaling the ReplicaSet directly may be overridden by the Deployment controller. Scale the parent Deployment instead for persistent changes.

​
How to Create a ReplicaSet

1

Click Create ReplicaSet

Click the Create ReplicaSet button in the page header.
2

Write YAML

Enter the ReplicaSet manifest in YAML format.
3

Select Namespace

Choose the target namespace for the ReplicaSet.
4

Create

Click Create to apply the manifest.
For most use cases, create a Deployment instead of a ReplicaSet directly. Deployments provide rolling updates, rollback capabilities, and better lifecycle management.

​
How to Edit a ReplicaSet

1

Open Actions Menu

Click the actions menu on the ReplicaSet row.
2

Click Edit YAML

Select Edit YAML to open the editor.
3

Modify Spec

Edit the ReplicaSet specification. Common changes:
  • Replica count
  • Pod template (triggers pod replacement)
  • Labels and annotations
4

Save

Click Update to apply changes.
The selector field is immutable after creation. To change the selector, delete and recreate the ReplicaSet.

​
How to Delete a ReplicaSet

1

Open Actions Menu

Click the actions menu on the ReplicaSet row.
2

Click Delete

Select Delete from the menu.
3

Confirm

Confirm the deletion.
If the ReplicaSet is managed by a Deployment, it will be automatically recreated. Delete the parent Deployment instead to permanently remove the ReplicaSet.

​
ReplicaSets vs Deployments

FeatureReplicaSetDeployment
Pod replicationYesYes (via ReplicaSet)
Rolling updatesNoYes
RollbackNoYes
Update historyNoYes
Declarative updatesManualAutomatic
Deployments are the recommended way to manage stateless applications. They create and manage ReplicaSets automatically, providing additional features like rolling updates and rollbacks.

​
Understanding Owner References

Most ReplicaSets are created and managed by Deployments:
  • Controlled By Deployment: The ReplicaSet is managed by a Deployment. Changes to replica count should be made on the Deployment.
  • No Owner: The ReplicaSet is standalone and can be managed directly.
When a Deployment updates, it creates a new ReplicaSet with the updated pod template and scales down the old ReplicaSet.

​
Troubleshooting

  • Check if replica count is greater than zero
  • Verify selector matches pod template labels
  • Check for resource quota limits in namespace
  • Review ReplicaSet events for errors
  • Check pod logs for application errors
  • Verify readiness probe configuration
  • Check if required ConfigMaps/Secrets exist
  • Verify image pull is successful
  • Check if ReplicaSet is managed by a Deployment
  • Scale the parent Deployment instead
  • Check for HorizontalPodAutoscaler targeting the Deployment
  • Deployments keep old ReplicaSets for rollback
  • Set spec.revisionHistoryLimit on Deployment to limit retained ReplicaSets
  • Default is 10 revisions
  • If managed by Deployment, it will be recreated
  • Delete the parent Deployment instead
  • Check for finalizers blocking deletion
  • Selectors are immutable after creation
  • Ensure pod template labels match the selector
  • Delete and recreate to change the selector

​
FAQ

Generally no. Use Deployments instead, which manage ReplicaSets and provide additional features like rolling updates and rollbacks. Direct ReplicaSet creation is only needed for specific use cases.
Each time you update a Deployment’s pod template, a new ReplicaSet is created. Old ReplicaSets are kept (scaled to 0) for rollback capability. The number retained is controlled by revisionHistoryLimit.
ReplicaSets don’t have a built-in restart mechanism. Delete pods to have them recreated, or if managed by a Deployment, use the Deployment’s restart feature.
The Deployment controller will detect the change and revert it to match the Deployment’s replica count. Always scale the Deployment instead.
Check the “Controlled By” column or the owner references in the ReplicaSet details. The ReplicaSet name usually includes the Deployment name as a prefix.
This is normal for old ReplicaSets after a Deployment update. The Deployment scales down old ReplicaSets to 0 but keeps them for rollback history.
Yes, but existing pods won’t be updated. Only new pods (created due to scaling or pod deletion) will use the new template. Use Deployments for proper rolling updates.