StatefulSets对应用程序有以下的好处：
稳定的唯一网络标识
稳定的持久存储
平稳的部署和缩放
平稳的终止和删除
在上面，对于pod的规划，稳定性和持久属于同义。 如果一个应用程序不需要任何稳定标识或顺序部署，删除，或缩放，则可以将你的应用程序部署为无状态的replicas的控制器。 对于无状态的服务，Deployment和ReplicaSet或许更适合。
局限:
StatefulSet是一个Beta版本，在Kubernetes 1.5之前没有这个功能。
对所有的alpha/beta版本， 可以通过在apiserver中加入--runtime-config选项中禁用。
给Pod分配的存储空间，必须由调用Storage class的PersistentVolume Provisione预分配，或由由管理员预分配。
删除或收缩StatefulSet不会删除为这个StatefulSet分配的存储卷容量。这是为了保证数据的安全，因为对待StatefulSet的数据普通的做法比自动回收资源更实用。
StatefulSets当前版本需要Headless Service来响应pods的网络标识。所以，需要创建这个服务。
更新StatefulSet需要手动操作。
组件：
下面的例子是StatefulSet 的组件组成;
一个Headless Service, 名为nginx, 用于控制网络
StatefulSet名为web, 在spec中设置replicas为3，这会创建三个容器，并且 三个容器在不同的Pods中。
volumeClaimTemplates将提供稳定的存储，由PersistentVolumes 预分分配。
Pod名称
StatefulSet pod 的名称不能相同，名称包含了一个序列数，一个固定的网络标识，一个固定的存储。不管这个pod分配到那一个node上面，这些标识和这个pod粘在一起。
有序的索引
如果一个StatefulSet 有 N个replicas, 在StatefulSet中每一个Pod会顺序分配一个整数，他的范围是[0,N)，也就是0到N-1之间，所以在这个组中所有的数都是唯一的。
固定的网络ID
每一个在StatefulSet中的Pod由StatefulSet得出Pod的主机名，这个主机名是StatefulSet的名子和Pod的顺序号的组合。Pod主机名组合的模式是$(statefulset name)-$(ordinal) 。在上面的例子中将会创建的三个Pod将被命名为web-0,web-1,web-2。 StatefulSet能使用headless Service来控制Pods的域。 Headless服务通过$(service name).$(namespace).svc.cluster.local管理域。其中cluster.local是集群的域。每当一个Pod创建，都会在DNS中得到一个子域名，域名为:$(podname).$(governing service domain)。 其中governing service在StatefulSet中定义的serviceName.
看下面的例子：
| cluster.local | default/nginx | default/web | nginx.default.svc.cluster.local | web-{0..N-1}.nginx.default.svc.cluster.local | web-{0..N-1} |
| cluster.local | foo/nginx | foo/web | nginx.foo.svc.cluster.local | web-{0..N-1}.nginx.foo.svc.cluster.local | web-{0..N-1} |
Stable Storage
Kubernetes creates one PersistentVolume for each VolumeClaimTemplate. In the nginx example above, each Pod will receive a single PersistentVolume with a storage class of anything and 1 Gib of provisioned storage. When a Pod is (re)scheduled onto a node, its volumeMounts mount the PersistentVolumes associated with its PersistentVolume Claims. Note that, the PersistentVolumes associated with the Pods’ PersistentVolume Claims are not deleted when the Pods, or StatefulSet are deleted. This must be done manually.
Deployment and Scaling Guarantee
- For a StatefulSet with N replicas, when Pods are being deployed, they are created sequentially, in order from {0..N-1}.
- When Pods are being deleted, they are terminated in reverse order, from {N-1..0}.
- Before a scaling operation is applied to a Pod, all of its predecessors must be Running and Ready.
- Before a Pod is terminated, all of its successors must be completely shutdown.
The StatefulSet should not specify a pod.Spec.TerminationGracePeriodSeconds of 0. This practice is unsafe and strongly discouraged. For further explanation, please refer to force deleting StatefulSet Pods.
When the nginx example above is created, three Pods will be deployed in the order web-0, web-1, web-2. web-1 will not be deployed before web-0 is Running and Ready, and web-2 will not be deployed until web-1 is Running and Ready. If web-0 should fail, after web-1 is Running and Ready, but before web-2 is launched, web-2 will not be launched until web-0 is successfully relaunched and becomes Running and Ready.
If a user were to scale the deployed example by patching the StatefulSet such thatreplicas=1, web-2 would be terminated first. web-1 would not be terminated until web-2 is fully shutdown and deleted. If web-0 were to fail after web-2 has been terminated and is completely shutdown, but prior to web-1’s termination, web-1 would not be terminated until web-0 is Running and Ready.
http://blog.csdn.net/wenwst/article/details/54091984