StatefulSet

Deployment 不足以覆盖所有的应用编排问题,因为在它 看来 ,一个应用的 所有Pod,是完全一样的 ,所以它们之间就没有顺序,也无所谓运行在哪台宿主机上需要时,Deployment就通过Pod模板创建新的Pod,不需要时,就"杀掉"任意一个Pod

但是在实际场景中,并不是所有应用都满足这样的要求比如:主从关系,主备关系,还有就是数据存储类应用,多个实例通常会在本地磁盘上保存一份数据,而这些实例一旦被杀掉,即使重建出来,实例与数据之间的对应关系也已经丢失,从而导致应用失败

这种实例之间有不对等关系,或者 有依赖关系 的应用,被称为"有状态应用"(Stateful Application)，为了能对"有状态应用"做出支持,Kubernetes在Deployment基础上,扩展出了:StatefulSet。

StatefulSet将真实世界里的应用状态,抽象为了两种情况:

1, 拓扑状态(顺序编号+固定的网络表示dns) 这种情况是说,应用的多个实例之间不是完全对等的关系这些应用实例,必须按照某些顺序启动,比如某个应用的主节点A要先于B启动,那么当我把A和B两个节点删除之后,重新创建出来时,也要是这个顺序才行并且,新创建出来的A和B,必须和原来的A和B网络标识一样,这样原先的访问者才能使用同样的方法,访问到这个新Pod

2, 存储状态 这种情况是说,应用的多个实例分别绑定了不同的存储数据对于这些应用实例来说,Pod A第一次读取到的数据,和隔了十分钟之后再次读取到的数据,应该是同一份,哪怕在此期间Pod A被重新创建过

所以,StatefulSet的核心功能,就是通过某种方式, 记录这些状态 ,然后在Pod被重新创建时,能够为新Pod恢复这些状态

在深入了解StatefulSet之前,咱们先来讲讲 Headless Service

我们知道,Service是Kubernetes项目中用来将一组Pod暴露给外界访问的一种机制,比如,一个Deployment有3个Pod,那么我就可以定义一个Service,然后用户只要能访问到这个Service,就能访问到某个具体的Pod

但是,这个Service是怎么被访问到的呢

第一种方式,以Service的VIP(Virtual IP,即: 虚拟IP )方式比如:当我访问19216801这个Service的IP地址时,它就是一个VIP在实际中,它会把请求转发到Service代理的具体Pod上

第二种方式,就是以Service的 DNS 方式在这里又分为两种处理方法:第一种是Normal Service这种情况下,当访问DNS记录时,解析到的是Service的VIP第二种是Headless Service这种情况下,访问DNS记录时,解析到的就是某一个Pod的IP地址

可以看到, Headless Service不需要分配一个VIP,而是可以直接以DNS记录的方式解析出被代理Pod的IP地址 这样设计有什么好处呢

service定义时，它的 clusterIP 字段的值是：None，即：这个 Service，没有一个 VIP 作为“头”。这也就是 Headless 的含义。所以，这个 Service 被创建后并不会被分配一个 VIP，而是会以 DNS 记录的方式暴露出它所代理的 Pod。当你按照这样的方式创建了一个 Headless Service 之后，它所代理的所有 Pod 的 IP 地址，都会被绑定一个这样格式的 DNS 记录，如下所示：

<pod-name><svc-name><namespace>svcclusterlocal

这个 DNS 记录，正是 Kubernetes 项目为 Pod 分配的唯一的“可解析身份”（Resolvable Identity）。而有了这个身份之后,只要知道了一个Pod的名字以及它对应的Service的名字,就可以非常确定地通过这条DNS记录访问到Pod的IP地址

介绍完Headless Service之后,咱们再回来讲讲,StatefulSet的核心功能,是如何在Pod被重新创建时,能够为新Pod恢复这些状态

为了详细讲解,现在编写一个StatefulSet的YAML文件,如下:
可以看到,在这个YAML文件中,多了一个 serviceName=nginx 字段这个字段的作用,就是告诉StatefulSet控制器,在执行控制循环时,要使用nginx这个Headless Service来保证Pod的"可解析身份"这样,在创建Pod过程中,StatefulSet给它所管理的所有Pod名字,进行编号,使得每个Pod实例不重复而更重要的是,这些Pod的创建,也是严格按照编号顺序来进行的

StatefulSet 就保证了 Pod 网络标识的稳定性 。

这样的意思就是说,当有主从关系时,有明确先后关系时,StatefulSet通过这种机制,使得先后创建顺序成为可能

通过这种方法， Kubernetes 就成功地将 Pod 的拓扑状态（比如：哪个节点先启动，哪个节点后启动），按照 Pod 的“名字 + 编号”的方式固定了下来 。此外，Kubernetes 还为每一个 Pod 提供了一个固定并且唯一的访问入口，即：这个 Pod 对应的 DNS 记录。

这些状态，在 StatefulSet 的整个生命周期里都会保持不变，绝不会因为对应 Pod 的删除或者重新创建而失效。

不过，相信你也已经注意到了，尽管 web-0nginx 这条记录本身不会变，但它解析到的 Pod 的 IP 地址，并不是固定的。这就意味着，对于“有状态应用”实例的访问，你必须使用 DNS 记录或者 hostname 的方式，而绝不应该直接访问这些 Pod 的 IP 地址。

Kubernetes 中 PVC 和 PV 的设计， 实际上类似于“接口”和“实现”的思想 。开发者只要知道并会使用“接口”，即：PVC；而运维人员则负责给“接口”绑定具体的实现，即：PV。而 PVC、PV 的设计，也使得 StatefulSet 对存储状态的管理成为了可能。 PVC 其实就是一种特殊的 Volume 。只不过一个 PVC 具体是什么类型的 Volume，要在跟某个 PV 绑定之后才知道。当然，PVC 与 PV 的绑定得以实现的前提是，运维人员已经在系统里创建好了符合条件的 PV（比如，我们在前面用到的 pv-volume）；或者，你的 Kubernetes 集群运行在公有云上，这样 Kubernetes 就会通过 Dynamic Provisioning 的方式，自动为你创建与 PVC 匹配的 PV。 因为这种方式虽然开发可以直接使用PVC来做存储，但是却需要运维提前定义好PV，包括容量，个数等，这些往往是未知的，所以需要动态存储供应StorageClass 。

通过这种方式，Kubernetes 的 StatefulSet 就实现了对应用存储状态的管理。

看到这里，你是不是已经大致理解了 StatefulSet 的工作原理呢？现在，我再为你详细梳理一下吧。

首先，StatefulSet 的控制器直接管理的是 Pod 。这是因为，StatefulSet 里的不同 Pod 实例，不再像 ReplicaSet 中那样都是完全一样的，而是有了细微区别的。比如，每个 Pod 的 hostname、名字等都是不同的、携带了编号的。而 StatefulSet 区分这些实例的方式，就是通过在 Pod 的名字里加上事先约定好的编号。

其次，Kubernetes 通过 Headless Service，为这些有编号的 Pod，在 DNS 服务器中生成带有同样编号的 DNS 记录 。只要 StatefulSet 能够保证这些 Pod 名字里的编号不变，那么 Service 里类似于 web-0nginxdefaultsvcclusterlocal 这样的 DNS 记录也就不会变，而这条记录解析出来的 Pod 的 IP 地址，则会随着后端 Pod 的删除和再创建而自动更新。这当然是 Service 机制本身的能力，不需要 StatefulSet *** 心。

最后，StatefulSet 还为每一个 Pod 分配并创建一个同样编号的 PVC 。这样，Kubernetes 就可以通过 Persistent Volume 机制为这个 PVC 绑定上对应的 PV，从而保证了每一个 Pod 都拥有一个独立的 Volume。

在这种情况下，即使 Pod 被删除，它所对应的 PVC 和 PV 依然会保留下来。所以当这个 Pod 被重新创建出来之后，Kubernetes 会为它找到同样编号的 PVC，挂载这个 PVC 对应的 Volume，从而获取到以前保存在 Volume 里的数据。

其实StatefulSet就是一种特殊的Deployment,只不过它的每个Pod都被编号了 正是由于这种机制,使得具有主从关系的创建成为可能StatefulSet 其实可以认为是对 Deployment 的改良。与此同时，通过 Headless Service 的方式，StatefulSet 为每个 Pod 创建了一个固定并且稳定的 DNS 记录，来作为它的访问入口。实际上，在部署“有状态应用”的时候，应用的每个实例拥有唯一并且稳定的“网络标识”，是一个非常重要的假设。

pod
[英][pɒd][美][pɑ:d]
n
荚，豆荚; （飞机的）吊舱; （航天器或船只上可与船只主体分离的）分离舱;
vi
结豆荚;
vt
把（豆等）剥出荚; 去荚;
网络
导流罩; 容器; 豆荚;
第三人称单数：pods复数：pods现在分词：podding过去式：podded过去分词：podded形近词：POD

应该是ipod吧
什么是iPod？iPod是APPLE 推出的一种大容量MP3播放器，采用Toshiba出品的18英寸盘片硬盘作为存储介质，高达10～40GB的容量，可存放2500～10000首CD 质量的MP3音乐，它还有完善的管理程序和创新的 *** 作方式，外观也独具创意，是APPLE少数能横跨PC和Mac平台的硬件产品之一，除了MP3播放，iPod还可以作为高速移动硬盘使用，可以显示联系人、日历和任务，以及阅读纯文本电子书和聆听Audible的有声电子书。
iPod历程
第一代iPod
第一代iPod的推出在当时引起了轰动，它不但漂亮，而且拥有独特和人性化的 *** 作方式以及巨大的容量，iPod为MP3播放器带来了全新的思路，此后市场上类似的产品层出不穷，但iPod依然因为它的独特风格而一直受到追捧。
第一代iPod于2001年10月23日发布，容量为5GB，2002年3月21日新增10GB版本iPod，两者都装备了APPLE称为scroll-wheel的选曲盘，只需一个大拇指就能完成进行 *** 作，10G iPod还新增了20种均衡器设置，iPod使用带宽达400Mbps的IEEE1394接口进行传输，配合Mac *** 作系统上的iTunes进行管理，这在当时是相当先进的设计，再加上iPod与众不同的外观设计，让它成为APPLE打造的又一个神话。
第二代iPod
第一代iPod早期的型号是为Mac *** 作系统设计的，在PC上难以使用它，为此喜欢iPod的PC用户不得不借助一些第三方软件来使用，苹果看到其中的商机，在2002年6月17日推出了能够支持Windows *** 作系统的“Windows版iPod”，同时增加了20G版本的iPod，自此Mac和Windows版本iPod都有5GB、10GB、20GB三种容量，这就是大家所说的第二代iPod ，由此iPod成为APPLE阵营中距离PC用户最近的产品之一。

---