Kubernetes ReplicaSets explained

A ReplicaSet maintains a selected number of matching Pods. If one disappears, its controller creates another. If too many match, it removes extras. This reconciliation is useful, but a ReplicaSet does not provide a complete rollout strategy.

Most teams should create Deployments rather than managing ReplicaSets directly. A Deployment owns ReplicaSets and adds declarative updates, rollout history, and rollback behavior.

Understand the reconciliation contract

The Kubernetes ReplicaSet documentation defines three important parts:

• replicas declares the desired number of Pods;
• selector identifies the Pods counted and managed;
• template defines the Pods the controller creates.

The selector must match the labels on the Pod template. The controller continuously compares the number of matching Pods with the desired count and acts on the difference.

This means membership is label-based, not based only on which Pods the ReplicaSet created. A badly chosen selector can overlap with another controller or adopt existing unmanaged Pods. Treat selectors as stable identity and avoid changing labels casually during an incident.

Let Deployments own ReplicaSets

A Deployment creates a new ReplicaSet when its Pod template changes and gradually moves replicas from the previous set to the new one according to rollout policy. That history supports status, pause, resume, and rollback workflows.

Managing the child ReplicaSet directly fights the Deployment controller. A manually changed replica count may be overwritten, and deleting a child can cause the Deployment to recreate it.

When investigating a serving workload, follow ownership upward:

kubectl --context ml-production --namespace inference describe pod model-api-7d6c8d7b98-x2abc
kubectl --context ml-production --namespace inference describe replicaset model-api-7d6c8d7b98
kubectl --context ml-production --namespace inference describe deployment model-api

Change the Deployment or the platform configuration that produced it, not the generated Pod or ReplicaSet.

Do not use ReplicaSets for finite work

A ReplicaSet tries to keep Pods running indefinitely. That is correct for interchangeable service replicas but wrong for a training task that should complete and stay complete.

Use a Job for finite work. The Job controller understands successful completion, retries, parallelism, backoff, and cleanup. A completed Pod managed by a ReplicaSet is simply below the desired running count, so another Pod may be created.

For distributed training, use the workload abstraction and scheduler integration appropriate to the framework. Replica count alone does not provide gang scheduling, rank assignment, coordinated failure, or elastic membership.

Plan serving rollouts around capacity

Model-serving Deployments often run large images, load substantial model artifacts, and request GPUs. A rolling update can temporarily require capacity for old and new ReplicaSets at the same time.

Set rollout policy with that cost in mind. maxSurge may be constrained by scarce accelerators; maxUnavailable may be constrained by the latency or availability objective. Readiness must indicate that a Pod can actually serve the model, not merely that its process has started.

A rollout can stall because new Pods are unschedulable, images or model weights load slowly, storage cannot attach, or readiness never succeeds. Inspect Deployment and ReplicaSet conditions alongside Pod events and queue state before increasing a timeout.

Keep selectors and labels safe

Use labels that distinguish the application identity from the rollout revision. A Service should normally select stable workload labels shared by old and new ReplicaSets, while the Deployment controller uses additional labels to identify each revision.

Avoid selectors that are broad enough to match test Pods or workloads from another controller. In a shared cluster, use namespaces and a consistent label taxonomy to reduce accidental overlap.

Deletion propagation also matters. Deleting a Deployment normally removes its dependent ReplicaSets and Pods. Before using orphaning behavior, confirm who will own and clean up the remaining resources.

Monitor desired, current, and available replicas

Do not rely on one Pod phase. Compare the desired, current, ready, and available counts and watch how long mismatches persist. Useful questions include:

• Does the Deployment expect a rollout that has not completed?
• Is a ReplicaSet unable to create Pods because of admission or quota?
• Are Pods created but unschedulable?
• Are containers running but not ready?
• Did a Service selector stop matching the intended Pods?

Our guide to kube-state-metrics for ML platforms explains how to expose object-state mismatches without confusing them with resource usage or model performance.

Connect the controller to Polyaxon

Polyaxon uses workload-appropriate execution models for tracked operations and services. The platform preserves the project, code, parameters, environment, resources, logs, and artifacts that Kubernetes objects alone do not explain.

Use platform observability to connect platform behavior with Kubernetes state, and centralize reusable placement through scheduling presets.

ReplicaSets solve one narrow problem well: maintaining a number of equivalent Pods. Use a Deployment when those replicas need safe rollout management, a Job when work should finish, and Polyaxon to keep the ML intent and evidence connected above the Kubernetes controllers.