1.了解完分配和组成，接下来说一下为什么会出现查询失败的情况呢？

1)第一种: Pod尚在创建过程中，这时候查询，DNS命名还未分配成功
2)第二种: Pod已经创建成功，取决于集群域内部 DNS 的配置，可能无法查询一个刚刚启动的 Pod 的 DNS 命名。
原因: 是k8s有个负缓存的概念。

负缓存 (在 DNS 中较为常见)

1)之前失败的查询结果会被记录和重用至少若干秒钟
2)默认缓存时长为 30s
3)查询过程
4)第一次查询结果是失败,结果记录到负缓存中，标注失败
5)在缓存周期内查询，直接从负缓存中取，结果是失败

那么如何及时去发现创建的Pod的DNS命名？

1)如果需要在 Pod 被创建之后及时发现它们。
有以下选项：直接查询 Kubernetes API（比如，利用 watch 机制）而不是依赖于 DNS 查询
缩短 Kubernetes DNS 驱动的缓存时长（修改 CoreDNS 的 ConfigMap，目前DNS缓存时长为 30 秒）

2.你能辩证的说说看StatefulSets 和 Deployment具体有哪些区别嘛？

1)Deployment管理的Pod特点
Deployment被设计用来管理无状态服务的pod，每个pod完全一致

无序性：无状态服务的多个Pod副本创建和销毁是无序的，
可以并行创建或销毁，相互之间不必等待，除了需要遵守规约中定义的副本个数之外，没有其他制约

随机性：无状态服务的多个Pod副本的名称是随机的，
pod被重新启动调度后，它的名称与IP都会发生变化，替换为一个新的副本。

共享性：无状态服务的多个Pod副本共享存储卷。
Deployment中Pod基于template定义存储卷，所有副本集共用一个存储卷。

2)StatefulSets管理的Pod特点

StatefulSets 被设计用来管理有状态的应用，StatefulSet 管理的 Pod 具有唯一的标识，该标识包括顺序标识、稳定的网络标识和稳定的存储。 
并且该标识和 Pod 是绑定，不管它被调度在哪个节点上，最终都会被绑定这个唯一标识。

唯一性：对于具有 N 个副本的 StatefulSet，它管理的每个 Pod 将被分配一个整数序号，该序号在 StatefulSet 上是唯一的。

顺序性：顺序标识、Pod 调度过程，无论是启动、销毁、更新都需要严格遵守顺序。有序优雅的部署和缩放，有序自动的滚动更新。

稳定的网络标识：Pod主机名、DNS地址不会随着Pod被重新调度而发生变化。

稳定的持久化存储：Pod被重新调度后，不会删除原有的PV，重新调度成功后，继续挂载绑定原有的PV，从而保证了数据的完整性和一致性。

3.简单介绍下StatefulSets 和 Deployment 之间有什么本质区别？

首先、StatefulSet 和Deployment 都是用来管理应用的工作负载 API 对象，
都管理基于各自相同容器规约的一组 Pod，同时负责各自管理的Pod 

但和 Deployment 本质上不同的是，StatefulSets 用来管理有状态应用，
而Deployment 负责管理无状态应用。

如果应用程序不需要任何稳定的标识符或有序的部署、删除或伸缩，
则应该使用 由一组无状态的副本控制器提供的工作负载来部署应用程序，
比如:
如果希望使用存储卷为工作负载提供持久存储，可以使用 StatefulSet 作为解决方案的一部分。
尽管 StatefulSet 中的单个 Pod 仍可能出现故障， 但持久的 Pod 标识符可以更容易将现有卷与于重新调度的Pod进行绑定。

应用通常可以分为两大类：有状态与无状态

无状态应用：

1）简单理解就是没有特殊状态的服务
2）服务和数据分离，本身不存储数据
3）各个请求对于服务器来说统一无差别处理
4）请求可以随机发送到任意一台server上
5）请求自身携带了所有服务端所需要的所有参数
6）服务自身不存储跟请求相关的任何数据

有状态应用：

1）容器数据需要持久化保持
2）对于有数据存储功能的服务
3）每个实例都需要有自己独立的持久化存储
4）或者指多线程类型的服务、队列
5）mysql数据库、kafka、zookeeper等

如果server是有状态的，客户端需要始终把请求发到同一台server才行

同时，这里理解StatefulSets 两个关键点：
1）"稳定的"意味着 Pod 调度或重调度的整个过程是有持久性的
2）"有序的"意味着 Pod 调度或重调度的整个过程是需要保持顺序的