10.1 复制有状态pod
ReplicaSet通过一个pod模板创建多个pod副本。这些副本除了它们的名字和IP地址不同外，没有别的差异。如果pod模板里描述了一个关联到特定持久卷声明的数据卷，那么ReplicaSet的所有副本都将共享这个持久卷声明，也就是绑定到同持久卷声明，也就是绑到同一个声明的持久卷。
因为是在pod模板里关联声明的，又会依据pod模板创建多个pod副本，则不能对每个副本都指定独立的持久卷声明。所以也不能通过一个ReplicaSet来运行一个每个实例都需要独立存储的分布式数据存储服务，至少通过单个ReplicaSet是做不到的。老实说，之前你学习到的所有API对象都不能提供这样的数据存储服务，还需要其他的对象。
10.1.1 运行每个实例都有单独存储的多副本
那如何运行一个pod的多个副本，让每个pod都有独立的存储卷呢？ReplicaSet会依据一个pod创建一致的副本，所以不能通过它们来达到目的，那你可以使用什么呢？
手动创建pod
可以手动创建多个pod，每个pod使用一个独立的持久卷声明，但是因为没有一个ReplicaSet在后面对应它们，所以需要手动管理它们。当有的pod消失后（比如节点故障），需要手动创建它们。因此这不是一个好的选择。
一个pod实例对应一个ReplicaSet
与直接创建不同，可以创建多个ReplicaSet，每个ReplicaSet的副本数设为1，做到pod和ReplicaSet的一一对应，为每个ReplicaSet的pod模板关联一个专属的持久卷声明。
尽管这种方法能保证在节点故障或者pod误删时能自动重新调度创建，但是与单个ReplicaSet相比，它还是显得比较笨重的。例如，在这种情况下要如何伸缩pod？扩容的话，必须重新创建新的ReplicaSet。
所以说使用多个ReplicaSet也不是最好的方案。那是否可以创建一个ReplicaSet，即使在共享一个存储卷的情况下，让每个pod实例都独立保持自己的持久化状态呢？
使用同一数据卷中的不同目录
一个比较取巧的做法是：所有pod共享同一数据卷，但是每个pod在数据卷中使用不同的数据目录（如图10.3所示）。
[图片上传失败...(image-5cce5d-1627435211102)]
图10.3 每个pod中的应用使用同一数据卷中的不同目录
因为不能在一个pod模板中差异化配置pod副本，所以不能指定一个实例使用哪个特定目录！但是可以让每个实例自动选择（或创建）一个别的实例还没有使用的数据目录。这种方案要求实例之间相互协作，其正确性很难保证，同时共享存储也会成为整个应用的性能瓶颈。
10.1.2 每个pod都提供稳定的标识
除了上面说的存储需求，集群应用也会要求每一个实例拥有生命周期内唯一标识。pod可以随时被删掉，然后被新的pod替代。当一个ReplicaSet中的pod被替换时，尽管新的pod也可能使用被删掉pod数据卷中的数据，但它却是拥有全新主机名和IP的崭新pod。在一些应用中，当启动的实例拥有完全新的网络标识，但还使用旧实例的数据时，很可能引起问题。
为什么一些应用需要维护一个稳定的网络标识呢？这个需求在有状态的分布式应用中很普遍。这类应用要求管理者在每个集群成员的配置文件中列出所有其他集群成员和它们的IP地址（或主机名）。但是在Kubernetes中，每次重新调度一个pod，这个新的pod就有一个新的主机名和IP地址，这样就要求当集群中任何一个成员被重新调度后，整个应用集群都需要重新配置。
每个pod实例配置单独的Service
一个比较取巧的做法是：针对集群中的每个成员实例，都创建一个独立的Kubernetes Service来提供稳定的网络地址。因为服务IP是固定的，可以在配置文件中指定集群成员对应的服务IP（而不是pod IP）。
这种做法跟之前提到的一种方法类似：为每个成员创建一个ReplicaSet，并配置独立存储。把这两种方法结合起来就构成如图10.4所示的结构（额外添加一个访问集群所有成员的服务，因为需要它来服务集群中的客户端）。
图10.4 每个pod对应一个Service和ReplicaSet提供稳定的网络地址，每个pod配置一个独立的数据卷
这种解决方案不仅令人厌恶，而且它也不是一个完美的解决办法。每个单独的pod没法知道它对应的Service（所以也无法知道对应的稳定IP），所以它们不能在别的pod里通过服务IP自行注册。
幸运的是，Kubernetes为我们提供了这类需求的完美解决方案。在Kubernetes中运行这类特定需求应用的最简单的办法就是通过Statefulset。
