前提知识
存储状态
PVC、PV 的设计，使得 StatefulSet 对存储状态的管理成为了可能。用上节的stateful的yaml文件为例：
额外添加了一个 volumeClaimTemplates 字段。从名字可以看出，它跟 Pod 模板的作用类似。凡是被这个 StatefulSet 管理的 Pod，都会声明一个对应的 PVC；而这个 PVC 的定义，就来自于 volumeClaimTemplates 这个模板字段。更重要的是，这个 PVC 的名字，会被分配一个与这个 Pod 完全一致的编号。
这个自动创建的 PVC，与 PV 绑定成功后，就会进入 Bound 状态，意味着这个 Pod 可以挂载并使用这个 PV 了。
我们在创建 StatefulSet 后，就会看到集群里出现了两个 PVC：
$ kubectl create -f statefulset.yaml
$ kubectl get pvc -l app=nginx
NAME STATUS VOLUME CAPACITY ACCESSMODES AGE
www-web-0 Bound pvc-15c268c7-b507-11e6-932f-42010a800002 1Gi RWO 48s
www-web-1 Bound pvc-15c79307-b507-11e6-932f-42010a800002 1Gi RWO 48s
这些 PVC，都以<PVC 名字 >-<StatefulSet 名字 >-< 编号 >的方式命名，并且处于 Bound 状态。
这个 StatefulSet 创建出来的所有 Pod，都会声明使用编号的 PVC。比如，在名叫 web-0 的 Pod 的 volumes 字段，它会声明使用名叫 www-web-0 的 PVC，从而挂载到这个 PVC 所绑定的 PV。
我们可以使用如下指令，在 Pod 的 Volume 目录里写入一个文件，来验证一下上述 Volume 的分配情况：
$ for i in 0 1; do kubectl exec web-$i -- sh -c 'echo hello $(hostname) > /usr/share/nginx/html/index.html'; done
通过 kubectl exec 指令，在每个 Pod 的 Volume 目录里，写入了一个 index.html 文件。这个文件的内容，正是 Pod 的 hostname。比如，我们在 web-0 的 index.html 里写入的内容就是 "hello web-0"。
此时，如果你在这个 Pod 容器里访问“http://localhost”，你实际访问到的就是 Pod 里 Nginx 服务器进程，而它会为你返回 /usr/share/nginx/html/index.html 里的内容。这个操作的执行方法如下所示：
$ for i in 0 1; do kubectl exec -it web-$i -- curl localhost; done
hello web-0
hello web-1
现在，关键来了。如果你使用 kubectl delete 命令删除这两个 Pod，这些 Volume 里的文件会不会丢失呢？
$ kubectl delete pod -l app=nginx
pod "web-0" deleted
pod "web-1" deleted
正如我们前面介绍过的，在被删除之后，这两个 Pod 会被按照编号的顺序被重新创建出来。这时在新创建的容器里通过访问“http://localhost”的方式去访问 web-0 里的 Nginx 服务：
# 在被重新创建出来的 Pod 容器里访问 http://localhost
$ kubectl exec -it web-0 -- curl localhost
hello web-0
就会发现，这个请求依然会返回：hello web-0。也就是说，原先与名叫 web-0 的 Pod 绑定的 PV，在这个 Pod 被重新创建之后，依然同新的名叫 web-0 的 Pod 绑定在了一起。对于 Pod web-1 来说，也是完全一样的情况。
这是怎么做到的呢？
首先，当你把一个 Pod，比如 web-0，删除后，其对应的 PVC 和 PV 并不会被删除，而这个 Volume 里已经写入的数据，也依然会保存。
此时 StatefulSet 控制器发现一个名叫 web-0 的 Pod 消失了。控制器就会重新创建一个新的、名字还是叫作 web-0 的 Pod 。
在这个新的 Pod 对象的定义里，它声明使用的 PVC 的名字，还是叫作：www-web-0。这个 PVC 的定义还是来自于 PVC 模板，这是 StatefulSet 创建 Pod 的标准流程。
新的 web-0 Pod 被创建后，K8s 为它查找名叫 www-web-0 的 PVC 时，就会直接找到旧 Pod 遗留下来的同名的 PVC，进而找到跟这个 PVC 绑定在一起的 PV。
这样，新的 Pod 就可以挂载到旧 Pod 对应的那个 Volume，并且获取到保存在 Volume 里的数据。
通过这种方式，K8s 的 StatefulSet 就实现了对应用存储状态的管理。
再次梳理工作原理
首先，StatefulSet 的控制器直接管理的是 Pod。因为 StatefulSet 里的 Pod 不再像 ReplicaSet 中那样都是一样的，而是有了细微区别的。比如，每个 Pod 的 hostname、名字等都是不同的、携带了编号的。而 StatefulSet 区分这些实例的方式，就是通过在 Pod 的名字里加上事先约定好的编号。
其次，K8s 通过 Headless Service，为这些有编号的 Pod，在 DNS 服务器中生成带有同样编号的 DNS 记录。只要 StatefulSet 能够保证这些 Pod 名字里的编号不变，那么 Service 里类似于 web-0.nginx.default.svc.cluster.local 这样的 DNS 记录也就不会变，而这条记录解析出来的 Pod 的 IP 地址，则会随着后端 Pod 的删除和再创建而自动更新。这当然是 Service 机制本身的能力，不需要 StatefulSet 操心。
最后，StatefulSet 还为每个 Pod 分配并创建一个同样编号的 PVC。K8s 为这个 PVC 绑定上对应的 PV，从而保证了每一个 Pod 都拥有一个独立的 Volume。
即使 Pod 被删除，它所对应的 PVC 和 PV 依然会保留下来。当这个 Pod 被重新创建出来之后，K8s 会为它找到同样编号的 PVC，挂载这个 PVC 对应的 Volume，从而获取到以前保存在 Volume 里的数据。
总结
StatefulSet 其实就是一种特殊的 Deployment，而其独特之处在于，它的每个 Pod 都被编号了。而且，这个编号会体现在 Pod 的名字和 hostname 等标识信息上，这不仅代表了 Pod 的创建顺序，也是 Pod 的重要网络标识（即：在整个集群里唯一的、可被的访问身份）。
有了这个编号后，StatefulSet 就使用 K8s 里的两个标准功能：Headless Service 和 PV/PVC，实现了对 Pod 的拓扑状态和存储状态的维护。
