Kubernetes 理解笔记之 StatefulSet

---

本文是对“有状态应用”的多副本控制器 StatefulSet 的理解笔记。StatefulSet 是 Kubernetes 中用来处理“有状态应用”的，所以理解过程从“什么是有状态应用”到“Kubernetes的解决方案”顺序展开，着重在记录 Kubernetes 在处理拥有拓扑状态和存储状态的“有状态应用”的控制管理上的的解决方案。大部分都是按照自己的理解记录，所以若有错误欢迎指正。

---

---

“使用”一句话：StatefulSet 是 Kubernetes 中用来处理“多实例的有状态应用”的。
“原理”一句话：StatefulSet 直接管理 Pod，并为每一个 Pod 编号命名。

---

一. 有状态应用

1.1 这个“有没有状态”到底代表什么？

这里首先要讲一个自己的理解：”应用“ 和 ”实例“
之前从容器到Pod理解的时候，往往说 Kubernetes 通过 Pod 来对“应用”进行描述，但准确地说应该是 Pod YAML 来描述，而通过这个 Pod YAML 建立运行起来的 Pod ，在这里就称为一个“实例”。
所以在 Kubernetes 中 Pod 描述的其实应该是”单实例应用“，但是应用的部署为了高可用和方便扩展伸缩，往往都是多实例部署，也就是”多实例应用“，之前理解的 Deployment 便是一种描述，多副本可伸缩控制器。
这里就会有一个困惑：每一个 Pod 都会有自己的网络地址、数据依赖的，要不然也不会有 Volume 这种设置了。为什么还会出现”无状态应用“呢 ？
其实，这里的”应用状态“是对于”多实例应用“而言的，并不是对于 Pod 这种”单实例应用“而言。如果一个”多实例应用“的各个实例承担不同的责任相互配合，并各自有着不同的外部数据依赖就是”有状态应用“，如果多个实例仅是单纯的副本扩展则是”无状态应用“了。

1.2 “有状态应用”的状态抽象

Kubernetes 将“多实例应用”的有状态抽象为了两种情况：

1. 有拓扑状态：一个应用的多个实例之间有拓扑状态
   场景：应用多个实例必须按照某些顺序启动，比如应用的主节点 A 要先于从节点 B 启动。而如果你把 A 和 B 两个 Pod