Kubernetes

在K8s中，每一个容器对应一个进程，但复杂的应用系统往往是一个进程组，所以出现了pod，用于管理一组容器。

Pod 是 Kubernetes 在容器之上的一层封装，它由运行在同一主机上的一个或者多个容器构成。而且，同一个 Pod 中的容器可以共享一个 Network Namespace 和同一组数据卷，从而高效的信息交换。因为具有了这些特性，Pod 通常会被类比为物理机。Pod 存在的意义还在于可以屏蔽容器之间可能存在依赖关系。

总体上，Kubernetes 是一个主从结构（Master-Slave）。其中 Master 是一个控制面板，每个 Salve 就是物理节点上代理 Kubelet，Master 与 Kubelet 通讯完成对物理节点上 Pod 和 Container 的管理。

数据库是一个有状态的服务，是指服务要依赖持久化数据，也就是存储状态。而对于 StatefulSet 来说，状态又分为两部分，除了存储状态，还有系统的拓扑状态。

拓扑状态

拓扑状态是指集群内节点之间的关系，在 Kubernetes 中就是 Pod 之间的关系。

StatefulSet 采用记录域名的方式，再通过 DNS 解析出 Pod 的 IP 地址。这样 Pod 就具有了稳定的网络标识。同时，为了确保体现 Pod 之间的依赖关系，StatefulSet 还引入顺序的概念，将 Pod 的拓扑状态，也就是启动顺序，按照 Pod 的“名字 + 编号”的方式固定了下来。

存储状态

Kubernetes 尝试引入本地持久卷（Local Persistent Volume）来解决。简单来说，就是一个 Local PV 对应一块本地磁盘。开启 Local PV 特性后，调度器会先获取所有节点与 Local PV 对应磁盘的关系，基于这些信息来调度 Pod。

与普通 PV 不同，当挂载 Local PV 的节点宕机并无法恢复时，数据可能就会丢失。这和物理机部署方案面临的问题是一样的，而分布式数据库的多副本机制正好弥补了这一点。

Operator

Operator 的工作原理就是利用了 Kubernetes 的自定义资源，来描述用户期望的部署状态；然后在自定义控制器里，根据自定义 API 对象的变化，来完成具体的部署和运维工作。简单来说，Operator 就是将运维人员对软件操作的知识代码化。

Operator 封装了有状态服务容器化的操作复杂性，对于应用系统上云的有重要的意义。

此文章为6月Day25学习笔记，内容来源于极客时间《分布式数据库30讲》