Day19-Kubernetes 那些事 - Stateless 与 Stateful

前言

今天来稍微讲点轻松的内容，但同时也是 K8s 中非常重要的一个观念，从这篇文章开始都会是 Pod 的扩充内容，但在正式进入扩充内容之前先带大家了解一下一个非常重要的观念：Stateless 与 Stateful 。

什麽是 Stateless？

Stateless 顾名思义就是无状态，简单来说就是我们每次跟服务器要资料的过程中都不会被服务器记录状态，每次 Request 都是独立，彼此是没有关联性的，也就是说我们每次获得的资料仅限於当下有用因为无法保存，所以静态网页通常都是一种 Stateless 应用。

举例来说：今天想到气象局查看天气，我可以藉由 Google 搜寻气象局并点击连结，或者是直接在浏览器输入 https://www.cwb.gov.tw/V8/C/ ，这两种最终结果都会一致，并不会因为我任何的操作而产生不同的结果，这就是一种 Stateless 的表现。

什麽是 Stateful？

tateful 就是 Stateless 的相反，也就是每次的 Request 都会被记录下来，日後都还是可以进行存取，而 Stateful 最常见的就是资料库，所以我们可以想像 Stateful 应用背後一定会有一个负责更新内容的储存空间。

举例来说：今天想到 Google 云端硬碟查看内容，我必须要先登入自己的 Google 帐号才可以查看内容，这种会有操作先後顺序才会有结果的就是一种 Stateful 的表现。

为什麽要提到 Stateless 以及 Stateful 呢？

其实跟我们 Pod 有很大的关系，在 K8s 中 Pod 是属於 Stateless 的，前面提到 Stateless 的特性就是每次 Request 都是独立的，这样有一个最大的好处就是可以快速扩充。

在 Pod 的文章中提到：Pod 是 K8s 中可以运行的最小单位，由於 Pod 是属於 Stateless 的，即便今天同一种内容的 Pod 有多个也没关系，因为每次的 Request 都是独立的，多个 Pod 就多个连线的端点而已，所以这也是为什麽 Pod 会是 Stateless ，至於要如何扩充 Pod 笔者会在後续的文章说明。

K8s 的 Stateful

上面提到由於 Pod 本身是 Stateless 了再加上 Pod 也是 K8s 的最小运行单位，难道 K8s 就没办法做 Stateful 应用吗？其实是可以的，K8s 为了 Stateful 有特别开启一种类别叫： StatefulSet。

由於 K8s 的 StatefulSet 牵涉到非常多进阶的观念，这些都是前面文章没有提过的，所以这里笔者就先提一下 K8s 的 StatefulSet 架构，范例的部分读者可以参考官网的范例。

StatefulSet 架构

StatefulSet 一共有两个重要的部分：

• Persistent Volume Claim

  前面提到 Stateful 背後会有一个更新内容的储存空间，在 K8s 中负责管理储存空间的就是 Volume ，作用跟 Docker 的 Volume 几乎一模一样，但毕竟 K8s 的 Volume 只是在 Pod 中做暂时存放的储存空间而已，当 Pod 移除之後这个储存空间也会一并消失，为了要在 K8s 中建立一个像资料库可以永久储存的空间，也就是这个 Volume 不能被包含在 Pod 内，而这个就是 Persistent Volume。

  Persistent Volume Claim 就是负责连接 Persistent Volume 的物件了，所以可以想像一下今天有多少的 Persistent Volume 就会有多少个 Persistent Volume Claim ，这两个是相辅相成的。

• Headless Service

  还记得在 Service 的文章中提到 ClusterIP 吗？其实每个 Service 都会有一组自己的 ClusterIP (ExternalName 形式的除外)，所以 Headless 的意思其实就是不要有 ClusterIP，方法也很简单直接在设定档里面加个 ClusterIP: None 即可。

  这麽做有什麽好处呢？由於 Headless Service 并没有直接跟 Pod 有对应关系，因此 Service 本身没有 ClusterIP ，所以 K8s 内部在沟通时就没办法把我们设定好的 Service 名称进行 IP 转换，不过 Headless Service 会将内部的 Pod 都建立一个专属於自己的 domain ，所以我们可以自由的选择要连接到某个 Pod，至於 K8s 内部是如何沟通的笔者之後也会写一篇文章介绍给大家，这里读者稍微有个印象就好。

  这时候你可能会想说我也可以自己手动连接啊？但因为 Service 一般是跟着 Pod 的 Label 走，所以一个 Service 会连接到许多个 Pod ，这样我们就没办法针对其中一个 Pod 做事情了，所以 Headless Service 在 StatefulSet 中也会被建立就是这个原因，不过这个也是要看架构师要如何设计这块就是了。

还记得笔者一直有强调 K8s 中最小的执行单位是 Pod ，即便是 StatefulSet 也会有 Pod ，只是这个 Pod 会归 StatefulSet 管，综合上面所提到的可以知道一个 StatefulSet 里面除了执行的 Pod 外还会有负责跟 Persistent Volume 连接的 Persistent Volume Claim，所以整体 StatefulSet 的架构会长得像下面这样。

小结

今天介绍了 Stateless 以及 Stateful 两个满重要的观念，但这里笔者稍微埋了个伏笔，到底 StatefulSet 是如何控制底下的 Pod 呢？

所以从下一篇文章开始要介绍给各位读者 K8s 是如何控管底下 Pod 数量，如果对於文章有任何问题都欢迎留言给我，那我们就下一篇文章见喽～