Getting Started with ReplicaSets

Understanding ReplicaSets

Note: Most applications should be scalable fault tolerant. While Pods do not provide those features, ReplicaSets do.

Previously, we learned that Pods are the smallest unit in Kubernetes. We also learned that Pods are not fault tolerant. If a Pod is created without a controller and subsequently destroyed, Kubernetes does nothing to remedy the problem.

The first Controller we’ll explore is called ReplicaSet. Its primary function is to ensure that a specified number of replicas of a Pod match the Pod’s actual state (almost) all the time. This means that ReplicaSets make Pods scalable.

We can think of ReplicaSets as a self-healing mechanism. As long as elementary conditions are met (e.g., enough memory and CPU), Pods associated with a ReplicaSet are guaranteed to run. They provide fault tolerance and high availability.

If you’re familiar with Replication-Controllers, it is worth mentioning that the ReplicaSet is the next-generation ReplicationController. The only significant difference is that ReplicaSet has extended support for selectors. Everything else is the same. ReplicationController is considered deprecated, so we’ll focus only on ReplicaSet.

Note: ReplicaSet’s primary function is to ensure that the specified number of replicas of service are (almost) always running.

Let’s explore ReplicaSet in this chapter through examples to see how it works.