K8S 中的 无状态服务 和 有状态服务
背景
K8S 中，由于ReplicaSet、ReplicationController、Deployment等这些控制器都是无状态的，但是想要使用k8s来编排有状态的服务如数据库等，k8s 推出了面向有状态服务的工作负载 StatefulSet。网络持久化、存储持久化，部署持久化有状态服务
定义
无状态服务（stateless service）对单次请求的处理，不依赖其他请求，也就是说，处理一次请求所需的全部信息，要么都包含在这个请求里，要么可以从外部获取到（比如说数据库），服务器本身不存储任何信息。
有状态服务（stateful service）则相反，它会在自身保存一些数据，先后的请求是有关联的。
电商购物为例，在商城里购买一件商品。需要经过放入购物车、确认订单、付款等多个步骤。由于HTTP协议本身是无状态的，所以为了实现有状态服务，就需要通过一些额外的方案。比如最常见的session，将用户挑选的商品（购物车），保存到session中，当付款的时候，再从购物车里取出商品信息。
二、无状态服务 和 有状态服务
无状态服务特点
1、数据方面：无状态服务不会在本地存储持久化数据.多个实例可以共享相同的持久化数据
2、结果方面：多个服务实例对于同一个用户请求的响应结果是完全一致的
3、关系方面：这种多服务实例之间是没有依赖关系
4、影响方面：在k8s控制器 中动态启停无状态服务的pod并不会对其它的pod产生影响
5、示例方面：nginx实例，tomcat实例，web应用
6、资源方面：相关的k8s资源有：ReplicaSet、ReplicationController、Deployment
7、创建方式：Deployment被设计用来管理无状态服务的pod
每个 pod完全一致，原因如下：
无状态服务内的多个 Pod创建的顺序是没有顺序的
无状态服务内的多个Pod的名称是随机的.pod被重新启动调度后,它的名称与IP都会发生变化
无状态服务内的多个Pod背后是共享存储的
8、扩缩容方式：随机缩容
由于是无状态服务，所以这些控制器创建的pod序号都是随机值。并且在缩容也是随机，并不会明确缩容某一个pod。因为所有实例得到的返回值都是一样，所以缩容任何一个pod都可以。
有状态服务介绍
1、数据方面：有状态服务需要在本地存储持久化数据,典型的是分布式数据库的应
2、结果方面：实例之间，请求结果可能存在不一致
3、关系方面：分布式节点实例之间有依赖的拓扑关系.比如,主从关系.
4、影响方面：如果K8S停止分布式集群中任 一实例pod,就可能会导致数据丢失或者集群的crash
5、示例方面：mysql数据库、kafka、zookeeper、Redis主从架构
6、资源方面：statefulSet
7、创建方式：statefulSet管理
Stateful管理有状态的应用，Pod有如下特征:
唯一性：每个Pod会被分配一个唯一序号.
顺序性：Pod启动,更新,销毁是按顺序进行.
稳定的网络标识：Pod主机名,DNS地址不会随着Pod被重新调度而发生变化.
稳定的持久化存储：Pod被重新调度后,仍然能挂载原有的PV,从而保证了数据的完整性和一致性
有状态的 pod是用来运行有状态应用的，所以其在数据卷上存储的数据非常重要，在 Statefulset 缩容时删除这个声明将是灾难性的，特别是对于 Statefulset 来说，缩容就像减少其 replicas 数值一样简单。基于这个原因，当需要释放特定的持久卷时，需要手动删除对应的持久卷声明。