pod 底层

pod 内部容器创建之前，必须先创建 pause 容器。pause 有两个作用：共享网络和共享存储。

每个服务容器共享 pause 存储，不需要自己存储数据，都交给 pause维护。

pause 也相当于这三个容器的网卡，因此他们之间的访问可以通过 localhost 方式访问，相当于访问本地服务一样，性能非常高（就像本地几台虚拟机之间可以 ping 通）。

作用：管理控制 pod 副本（服务集群）的数量，以使其永远与预期设定的数量保持一致。例如：replicas = 3 （创建 3 个副本，这是提前设置好的）

当副本设置为 3 时，副本控制器将会永远保证副本数量为 3。因此当有 pod 服务宕机时（如上面第 3 个 pod），那副本控制器会立马重新创建一个新的 pod，就能够保证副本数量一直为预先设定好的 3 个。

ReplicaSet 和 ReplicationController 都是副本控制器，其中：

• 相同点：都有前面 2.1 节所描述的功能
• 不同点：标签选择器的功能不同。ReplicaSet 可以使用标签选择器进行 单选 和 复合选择；而 ReplicationController 只支持 单选操作。

什么意思呢？

假设下面有下面两个不同机器上的 Node 结点，如何知道它们的 pod 其实都是相同的呢？答案是通过标签。

给每个 pod 打上标签 ( key=value 格式，如下图中的 app=web, release=stable，这有两个选项，相同的pod副本的标签是一样的)，于是副本控制器可以通过标签选择器 seletor 去选择一组相关的服务。

一旦 selector 和 pod 的标签匹配上了，就表明这个 pod 是当前这个副本控制器控制的，表明了副本控制器和 pod 的所属关系。如下图中 seletor 指定了 app = web 和 release=stable 是复合选择，要用 ReplicaSet 才能实现若用 ReplicationController 的话只能选择一个，如只选择匹配app=web标签。这样下面的 3 个 pod 就归这个副本控制器管。

可见 ReplicaSet 功能更齐全，所以在新版的 k8s 中，建议使用 ReplicaSet 作为副本控制器，不再使用 ReplicationController。

ReplicaSet 副本控制器可以永久保持 pod 副本的数量。但是项目的需求在不断的迭代、更新，项目在不断发版。那如何做到服务更新？难道把服务停掉再把新版本部署上去吗？当然不是，答案是用滚动更新。就是重新创建一个 pod (v2版本) 来代替 之前的 pod (v1版本)。

那是如何滚动更新的呢？涉及到下面要讲到的部署模型。

单独的 ReplicaSet 是不支持滚动更新的，Deployment 对象支持滚动更新，通常和 ReplicaSet 一起使用。

需要滚动更新时的步骤：

Deployment 建立新的 Replicaset

Replicaset 重新建立新的 pod

所以它们之间是有层次关系的，Deployment 管 Replicaset，Replicaset 维护 pod。在更新时删除的是旧的 pod，老版本的 ReplicaSet 是不会删除的，所以在需要时还可以回退以前的状态。

思考：如果 MySQL(有状态服务) 使用容器化部署，会存在什么问题？

• 1、容器都是有生命周期的，一旦宕机数据就很可能丢失
• 2、pod 也有生命周期的，用 pod 部署时把 pod 集群副本重启以后也可能会出现数据丢失

因此对 k8s 来说，不能使用 Deployment 部署有状态的服务。通常情况下，Deployment 被用来部署无状态服务。

然后 StatefulSet 就是为了解决有状态服务使用容器化部署的一个问题。

有状态服务

• 有实时的数据需要存储在有状态服务集群中，如果把某一个服务抽离出来，一段时间后再加入回集群网络，此后集群网络会无法使用

无状态服务

• 没有实时的数据需要存储在无状态服务集群中，如果把某一个服务抽离出去，一段时间后再加入回集群网络，对集群服务无任何影响，因为它们不需要做交互，不需要数据同步等等。

StatefulSet 的部署模型和 Deployment 的很相似。

比如下图，借助 PVC(与存储有关) 文件系统来存储的实时数据，因此下图就是一个有状态服务的部署。

在 pod 宕机之后重新建立 pod 时，StatefulSet 通过保证 hostname 不发生变化来保证数据不丢失。因此 pod 就可以通过 hostname 来关联(找到) 之前存储的数据。