ReplicaSet 的目的是维护一组在任何时候都处于运行状态的 Pod 副本的稳定集合。 因此，它通常用来保证给定数量的、完全相同的 Pod 的可用性。
何时使用 ReplicaSet
ReplicaSet 确保任何时间都有指定数量的 Pod 副本在运行。 然而，Deployment 是一个更高级的概念，它管理 ReplicaSet，并向 Pod 提供声明式的更新以及许多其他有用的功能。 因此，我们建议使用 Deployment 而不是直接使用 ReplicaSet， 除非你需要自定义更新业务流程或根本不需要更新。
这实际上意味着，你可能永远不需要操作 ReplicaSet 对象：而是使用 Deployment，并在 spec 部分定义你的应用。
ReplicaSet 的工作原理
ReplicaSet 是通过一组字段来定义的，包括一个用来识别可获得的 Pod 的集合的选择算符、一个用来标明应该维护的副本个数的数值、一个用来指定应该创建新 Pod 以满足副本个数条件时要使用的 Pod 模板等等。 每个 ReplicaSet 都通过根据需要创建和删除 Pod 以使得副本个数达到期望值， 进而实现其存在价值。当 ReplicaSet 需要创建新的 Pod 时，会使用所提供的 Pod 模板。
ReplicaSet 通过 Pod 上的 metadata.ownerReferences 字段连接到附属 Pod，该字段给出当前对象的属主资源。 ReplicaSet 所获得的 Pod 都在其 ownerReferences（直译的话就是主人指针，主人是谁） 字段中包含了属主 （主人，属主是一个很让人疑惑的翻译）ReplicaSet 的标识信息。正是通过这一连接，ReplicaSet 知道它所维护的 Pod 集合的状态， 并据此计划其操作行为。
ReplicaSet 使用其选择算符来辨识要获得的 Pod 集合。如果某个 Pod 没有 OwnerReference 或者其 OwnerReference 不是一个控制器（在 Kubernetes 中，控制器通过监控集群 的公共状态，并致力于将当前状态转变为期望的状态。）， 且其匹配到某 ReplicaSet 的选择算符，则该 Pod 立即被此 ReplicaSet 获得。
ReplicaSet和Deployment的区别
Deployment让你更轻松地将pod更新到一个新的版本。
假设你用ReplicaSet-A来控制你的pod，之后你希望来更新你自己的pod变成一个更新的版本。现在你就应该创建Replicaset-B,不停地降低ReplicaSet-A的规模，增加ReplicaSet-B的规模。这个过程被称为rolling update。尽管这能够满足需求却并不是一个好的实践。最好让k8s来做相关工作。
一个Deployment会自动处理这个过程，没有任何的人工干扰并且提高抽象级别。
注意Deployment并不和pod直接互动，它只是使用replicaset来直接做rolling update(滚动更新)。
DeploymentStatus中几个字段的区别
-
Replicas - 描述这个deployment应该有多少pod。它是从spec拷贝的。这是异步发生的。所以在一段时间内，你有可能读到spec.replicas不等于status.replicas。
-
availableReplicas - 意味着有多少pod已经至少变成ready状态 minReadySeconds了。
这保证了状态是稳定的，而不是一会儿ready一会儿不ready。
-
unavailableReplicas - 应该有的pod总数 - 已经创建的pod总数或者是一直不可用（failing或成为ready状态没有超过minReadySeconds）的pod
-
updatedReplicas - 部署可到达的、与规范模板匹配的 Pod 数量。
-
readyReplicas - 在所有replica当中，能够联系到的pod数目。
参考链接