概述
有状态服务与无状态服务
无状态服务器处理的客户信息必须全部来自于请求所携带的信息以及其他服务器自身所保存的、并且可以被所有请求所使用的公共信息 。
如果是无状态化请求，那么服务端一般需要保存请求的相关信息，每个请求可以默认地使用以前的请求信息。
下面是一个横向 对比表格
| 支持 | 有状态服务 | 无状态服务 |
|---|---|---|
| 网络身份 | 固定 | 不定 |
| 实例名 | 固定 | 随机生成 |
| 存储 | 存储固定 | 无固定存储 |
下面是具体的说明:
访问方式
无状态服务，K8S 使用 RC（或更新的 Replica Set）来保证一个服务的实例数量，如果说某个 Pod 实例由于某种原因 Crash 了，RC 会立刻用这个 Pod 的模版新启一个 Pod 来替代它，由于是无状态的服务，新启的 Pod 与原来健康状态下的 Pod 一模一样。在 Pod 被重建后它的IP地址可能发生变化，为了对外提供一个稳定的访问接口，K8S 引入了 Service 的概念。一个 Service 后面可以挂多个 Pod，实现服务的高可用。 普通有状态服务，和无状态服务相比，它多了状态保存的需求。Kubernetes 提供了以 Volume 和 Persistent Volume 为基础的存储系统，可以实现服务的状态保存。 有状态集群服务，与普通有状态服务相比，它多了集群管理的需求。K8S 为此开发了一套以 Pet Set 为核心的全新特性，方便了有状态集群服务在 K8S 上的部署和管理。具体来说是通过 Init Container 来做集群的初始化工作，用 Headless Service 来维持集群成员的稳定关系，用动态存储供给来方便集群扩容，最后用Pet Set来综合管理整个集群。 要运行有状态集群服务要解决的问题有两个，一个是状态保存，另一个是集群管理。 我们先来看如何解决第一个问题：状态保存。Kubernetes 有一套以Volume插件为基础的存储系统，通过这套存储系统可以实现应用和服务的状态保存。
无状态服务的访问是通过一种叫 Headless Service 的特殊Service来实现的。要理解Headless Service是如何工作的，需要先了解Service是如何工作。我们提到过Service可以为多个Pod实例提供一个稳定的对外访问接口。这个稳定的接口是如何实现的的呢，是通过Cluster IP来实现的，Cluster IP是一个虚拟IP，不是真正的IP，所以稳定。K8S会在每个节点上创建一系列的IPTables规则，实现从Cluster IP到实际Pod IP的转发。同时还会监控这些Pod的IP地址变化，如果变了，会更新IP Tables规则，使转发路径保持正确。所以即使Pod IP有变化，外部照样能通过Service的ClusterIP访问到后面的Pod。
普通Service的Cluster IP 是对外的，用于外部访问多个Pod实例。而Headless Service的作用是对内的，用于为一个集群内部的每个成员提供一个唯一的DNS名字，这样集群成员之间就能相互通信了。所以Headless Service没有Cluster IP，这是它和普通Service的区别。
Headless Service为每个集群成员创建的DNS名字是什么样的呢？右下角是一个例子，第一个部分是每个Pet自己的名字，后面foo是Headless Service的名字，default是PetSet所在命名空间的名字，cluser.local是K8S集群的域名。对于同一个Pet Set里的每个Pet，除了Pet自己的名字，后面几部分都是一样的。所以要有一个稳定且唯一的DNS名字，就要求每个Pet的名字是稳定且唯一的。
实例名
无状态服务管理的不是Pod集合，而是Pet集合。 Pet是一种特殊的Pod，那么Pet能不能用Pod的命名规则呢？答案是不能，因为Pod的名字是不稳定的。Pod的命名规则是，如果一个Pod是由一个RC创建的，那么Pod的名字是RC的名字加上一个随机字符串。为什么要加一个随机字符串，是因为RC里指定的是Pod的模版，为了实现高可用，通常会从这个模版里创建多个一模一样的Pod实例，如果没有这个随机字符串，同一个RC创建的Pod之间就会由名字冲突。
如果说某个Pod由于某种原因死掉了，RC会新建一个来代替它，但是这个新建里的Pod名字里的随机字符串与原来死掉的Pod是不一样的。所以Pod的名字跟它的IP一样是不稳定的。
为了解决名字不稳定的问题，K8S对Pet的名字不再使用随机字符串，而是为每个Pet分配一个唯一不变的序号，比如 Pet Set 的名字叫 mysql，那么第一个启起来的Pet就叫 mysql-0，第二个叫 mysql-1，如此下去。
当一个Pet down 掉后，新创建的Pet 会被赋予跟原来Pet一样的名字。由于Pet名字不变所以DNS名字也跟以前一样，同时通过名字还能匹配到原来Pet用到的存储，实现状态保存
存储
无状态服务一般不绑定存储，或绑定存储作临时使用，实例停止后存储空间会被回收。而新起的实例会绑定新的Pvc卷。
而有状态服务一般实例名固定，重启的该实例会保持和原实例一致且会绑定原实例的Pvc。
服务汇总
Deployment
概念
Deployment（中文意思为部署、调度）提供了一种更加简单的更新RC和Pod的机制，K8S版本1.2实现的。通过在Deployment中描述所期望的集群状态，Deployment Controller会将现在的集群状态在一个可控的速度下逐步更新成所期望的集群状态。Deployment主要职责同样是为了保证pod的数量和健康，90%的功能与RC完全一样，可以看做新一代的RC。
功能
Deployment集成了上线部署、滚动升级、创建副本、暂停上线任务，恢复上线任务，回滚到以前某一版本（成功/稳定）的Deployment等功能，在某种程度上，Deployment可以实现无人值守的上线，大大降低上线过程的复杂沟通、操作风险。
- RC全部功能：Deployment继承了RC全部功能。
- 事件和状态查看：可以查看Deployment的升级详细进度和状态。
- 回滚：当升级pod镜像或者相关参数时发现问题，可以使用回滚操作回滚到上一个稳定的版本或者指定的版本。
- 版本记录：每次对Deployment的操作，都能保存下来，给予后续可能的回滚使用。
- 暂停和启动：对于每一次升级，都能够随时暂停和启动。
- 多种升级方案：Recreate--删除所有已存在的pod,重新创建新的; RollingUpdate--滚动升级，逐步替换的策略，同时滚动升级时，支持更多的附加参数，例如设置最大不可用pod数量，最小升级间隔时间等等。
使用场景
使用Deployment来启动（上线/部署）一个Pod或者RS
检查一个Deployment是否成功执行
更新Deployment来重新创建相应的Pods（例如，需要使用一个新的Image）
如果现有的Deployment不稳定，那么回滚到一个早期的稳定的Deployment版本
暂停或者恢复一个Deployment
与RC比较，deployment的优势
- Deployment使用了RS，它是更高一层的概念。
- RC只支持基于等式的selector（env=dev或environment!=qa），但RS还支持新的，基于集合的selector（version in (v1.0, v2.0)或env notin (dev, qa)），这对复杂的运维管理很方便。
- 使用Deployment升级Pod，只需要定义Pod的最终状态，K8S会为你执行必要的操作，虽然能够使用命令kubectl rolling-update完成升级，但它是在客户端与服务端多次交互控制RC完成的，所以REST API中并没有rolling-update的接口，这为定制自己的管理系统带来了一些麻烦。
- Deployment拥有更加灵活强大的升级、回滚功能。
Daemonset
概念
DaemonSet能够让所有（或者一些特定）的Node节点运行同一个pod。当节点加入到kubernetes集群中，pod会被（DaemonSet）调度到该节点上运行，当节点从kubernetes集群中被移除，被（DaemonSet）调度的pod会被移除，如果删除DaemonSet，所有跟这个DaemonSet相关的pods都会被删除。
功能
支持在每个加入集群的节点上自动启动一个该Pod的实例
使用场景
每个节点都需要的通用服务可以使用该功能，譬如保证每个节点都自动开启日志收集。
StatefulSet
概念
StatefulSet被用来管理有状态应用的API对象。StatefulSets在Kubernetes 1.9版本才稳定。StatefulSet管理Pod部署和扩容，并为这些Pod提供顺序和唯一性的保证。与Deployment相似的地方是，StatefulSet基于spec规格管理Pod；与Deployment不同的地方是，StatefulSet需要维护每一个Pod的唯一身份标识。这些Pod基于同样的spec创建，但互相之间不能替换，每一个Pod都保留自己的持久化标识。
功能
- 稳定、唯一的网络标识
- 稳定、持久的存储
- 按照顺序、优雅的部署和扩容
- 按照顺序、优雅的删除和终止
- 按照顺序、自动滚动更新
使用场景
需要本地状态存储
mysql redis mq的实例都是他的使用场景
ReplicaSet
概述
已经逐渐被Deployment替代
