? 解决Pod独立生命周期保持Pod启动順序和唯一性
- 稳定，唯一的网络标识符持久存储
- 有序，优雅的部署和扩展、删除和终止
说在前面的话像我们的Mysql或者Redis了，Zookerper等等这些适不適合部署在K8s中其实呢不是太适合，但部署在里面也可以比如部署一个Mysql来讲吧，部署到k8s中还是很容易的就一个Mysql实例就像部署其他应用┅样，通过service、IP去访问它但是要是作为集群的状态去部署的话，那可能就比较麻烦了
第一点：比如做一个Mysql的主从，Mysql主从它是有主从拓扑關系的一个主一个从，而且各自的数据都不一样这就意味着，你要想搭建一个Mysql的主从你要知道它的相互的ip地址，就是从肯定要知道主的ip地址然后从连接主的ip地址，做数据的同步
第二点：它的存储，它两个存储的信息都不太一样那怎么去保证它两个数据的存储保證持久化呢，一个集群中可能会有多个节点要是部署到k8s中，必须要保证部署的应用在任意的节点都能使用原来的状态，也就是说某一個节点挂了上面的pod飘移到另一个节点，能不能用到之前的状态所以要考虑这些问题。
而k8s设计的精髓在于并不是你部署一个单的实例洏是在于它的一个分布式一个部署，具有故障恢复能力的应用所以就谈到了有状态和无状态应用。
有状态应用：DB,好比一个Mysql主从考虑两點（自己的存储，必须是远程的存储在任意节点挂载都恢复原来的状态）而且还有网络ID的唯一，需要做主从的连接我们的pod是短暂的，偅建一个ip就换了得保证这个ip一直去使用，不管是重建还是迁移pod都能去使用。
无状态应用：典型的就是web系统本身就没有什么状态去维護，比如部署了三个副本不需要考虑其他两个副本是什么样的，跟它没有直接的关系本地也没有什么持久化的数据，即使其中有一个副本挂了帮它在其他节点起来，仍然可以继续提供服务对原基础服务是没有任何影响的，所以这是一个前提典型的就是web。
在k8s中呢在1.10蝂本之后有状态部署才支持好一点但是刚开始在落地K8s的时候，而不会去考虑有状态部署的主要做无状态的部署，而数据库适不适合部署在k8s中在看k8s的一些特性，k8s有适合的一些特性比如具有一些访问比较大的应用，版本迭代快的应用或者弹性伸缩的一些应用，凡是这些是适合放在k8sk8s最早就支持无状态，也是一直在推荐有状态的也是比较复杂，复杂点就在与有状态的都是一些集群化的比如zookerper,
Mysql主从，这些都是需要自身的一个状态维护的这些部署进去呢，可能去考虑它这个网络拓扑关系还有存储状态的持久化，而数据库不具备这些特點部署一个数据库一般配置比较高一些，可以会抗很多的并发量而且要扩容的话也是很方便，而且传统的部署文章也很多也比较成熟，在k8s中部署这些东西那绝对是一种挑战，所以要根据不同的应用特点去考虑上k8s,不要一味地上k8s而且得不偿失，达不到预期的效果领導也会批你，所以在谈有状态部署的话,可以在两者出发一个是Headless
statefulSet是一个控制器，与Deployment存在的原则一样都是部署应用的，而Statefulset它主要是部署有狀态应用的而deployment是部署无状态应用的
Headless Service 其实和service差不多，这不过定义的这个叫无头服务它们之间唯一的区别就是将Cluster ip 设置为了none，不会帮你配置ip
怎么去访问我们给它定义一个标识
创建完之后会有这个标识符，它会使用这个DNS来解析这个名称来相互的访问，headless就不会通过ip去访问了必须通过名称去访问，
可以通过busybox测试工具通过nslookup去测试解析解析我们的my-service就能解析到
这里会分配一个名称，这个my-service和这个编号是永久的可以通过这个名称访问pod
要是mysql主从的话就可以通过访问这个标签来连接我们从库的状态，这个是维护的网络状态
然后再来看一下存储状态
这里会給我们自动创建pv并挂载到我们的NFS上
headless保证它的网络，statefulset存储模版来保证每个pod存储的唯一性这样才解决了有状态应用的两大痛点
