K8S，StatefulSet

有状态应用

Deployment实际上并不足以覆盖所有的应用编排问题？

分布式应用，它的多个实例之间，往往有依赖关系，比如：主从关系、主备关系。
还有就是数据存储类应用，它的多个实例，往往都会在本地磁盘上保存一份数据。而这些实例一旦被杀掉，即便重建出来，实例与数据之间的对应关系也已经丢失，从而导致应用失败。

所以，这种实例之间有不对等关系，以及实例对外部数据有依赖关系的应用，就被称为“有状态应用”（Stateful Application）

Headless Service

<pod-name>.<svc-name>.<namespace>.svc.cluster.local
Kubernetes项目为Pod分配的唯一的“可解析身份”（Resolvable Identity）

StatefulSet又是如何使用这个DNS记录来维持Pod的拓扑状态

临时启动一个一次性Pod
kubectl run -i --tty --image busybox:1.28.4 dns-test --restart=Never --rm /bin/sh

Kubernetes就成功地将Pod的拓扑状态（比如：哪个节点先启动，哪个节点后启动），按照Pod的“名字+编号”的方式固定了下来

StatefulSet这个控制器的主要作用之一，就是使用Pod模板创建Pod的时候，对它们进行编号，并且按照编号顺序逐一完成创建工作。而当StatefulSet的“控制循环”发现Pod的“实际状态”与“期望状态”不一致，需要新建或者删除Pod进行“调谐”的时候，它会严格按照这些Pod编号的顺序，逐一完成这些操作。

PV和PVC

Kubernetes项目引入了一组叫作Persistent Volume Claim（PVC）和Persistent Volume（PV）的API对象，大大降低了用户声明和使用持久化Volume的门槛。
Kubernetes中PVC和PV的设计，实际上类似于“接口”和“实现”的思想。开发者只要知道并会使用“接口”，即：PVC；而运维人员则负责给“接
口”绑定具体的实现，即：PV。
PVC其实就是一种特殊的Volume。只不过一个PVC具体是什么类型的Volume，要在跟某个PV绑定之后才知道。
PVC与PV的绑定得以实现的前提是，运维人员已经在系统里创建好了符合条件的PV

实践