k8s集群StatefulSets的Pod调度查询丢失问题?
考点之你了解k8s集群StatefulSets的Pod调度查询丢失问题吗?k8s集群中StatefulSet管理的Pod已经完成调度并启动,为什么还是无法查询Pod 的 DNS 命名?
k8s集群StatefulSets的Pod调度查询丢失问题?
考点之简单介绍下StatefulSets 和 Deployment 之间有什么本质区别?特定场景该如何做出选择呢?
考点之你能辩证的说说看StatefulSets 和 Deployment具体有哪些区别嘛?
考点之你了解k8s集群StatefulSets的Pod调度查询丢失问题吗?k8s集群中StatefulSet管理的Pod已经完成调度并启动,为什么还是无法查询Pod 的 DNS 命名?
囧么肥事-胡说八道
简单介绍下StatefulSets 和 Deployment 之间有什么本质区别?
首先、StatefulSet
和Deployment
都是用来管理应用的工作负载 API 对象,都管理基于各自相同容器规约的一组 Pod,同时负责各自管理的Pod 集合的部署和扩缩、更新回滚等。
但和 Deployment
本质上不同的是,StatefulSets
用来管理有状态应用,而Deployment
负责管理无状态应用。
如果应用程序不需要任何稳定的标识符或有序的部署、删除或伸缩,则应该使用 由一组无状态的副本控制器提供的工作负载来部署应用程序,比如 Deployment
或者ReplicaSet
。
如果希望使用存储卷为工作负载提供持久存储,可以使用 StatefulSet
作为解决方案的一部分。
尽管 StatefulSet 中的单个 Pod 仍可能出现故障, 但持久的 Pod 标识符 可以更容易将现有卷与于重新调度的Pod进行绑定。
说道这里,下面简单介绍一下,应用分类:
应用通常可以分为两大类:有状态与无状态
无状态应用
简单理解就是没有特殊状态的服务
服务和数据分离,本身不存储数据
各个请求对于服务器来说统一无差别处理
请求可以随机发送到任意一台server上
请求自身携带了所有服务端所需要的所有参数
服务自身不存储跟请求相关的任何数据
有状态应用
容器数据需要持久化保持
对于有数据存储功能的服务
每个实例都需要有自己独立的持久化存储
或者指多线程类型的服务、队列
mysql数据库、kafka、zookeeper等
如果server是有状态的,客户端需要始终把请求发到同一台server才行,
同时,这里理解StatefulSets 两个关键点:1、稳定的 2、有序的
“稳定的”意味着 Pod 调度或重调度的整个过程是有持久性的
“有序的”意味着 Pod 调度或重调度的整个过程是需要保持顺序的
关于Deployment 的具体情况,可参考:【跟k8s工作负载Deployments的缘起缘灭】
你能辩证的说说看StatefulSets 和 Deployment具体有哪些区别嘛?
Deployment管理的Pod特点
Deployment被设计用来管理无状态服务的pod,每个pod完全一致
- 无序性:无状态服务的多个Pod副本创建和销毁是无序的,可以并行创建或销毁,相互之间不必等待,除了需要遵守规约中定义的副本个数之外,没有其他制约。
- 随机性:无状态服务的多个Pod副本的名称是随机的,pod被重新启动调度后,它的名称与IP都会发生变化,替换为一个新的副本。
- 共享性:无状态服务的多个Pod副本共享存储卷。Deployment中Pod基于template定义存储卷,所有副本集共用一个存储卷。
StatefulSets管理的Pod特点
StatefulSets 被设计用来管理有状态的应用,StatefulSet 管理的 Pod 具有唯一的标识,该标识包括顺序标识、稳定的网络标识和稳定的存储。 并且该标识和 Pod 是绑定,不管它被调度在哪个节点上,最终都会被绑定这个唯一标识。
- 唯一性:对于具有 N 个副本的 StatefulSet,它管理的每个 Pod 将被分配一个整数序号,该序号在 StatefulSet 上是唯一的。
- 顺序性:顺序标识、Pod 调度过程,无论是启动、销毁、更新都需要严格遵守顺序。有序优雅的部署和缩放,有序自动的滚动更新。
- 稳定的网络标识:Pod主机名、DNS地址不会随着Pod被重新调度而发生变化。
- 稳定的持久化存储:Pod被重新调度后,不会删除原有的PV,重新调度成功后,继续挂载绑定原有的PV,从而保证了数据的完整性和一致性。
你了解过k8s集群StatefulSets的Pod调度查询丢失问题吗?
k8s集群中StatefulSet
管理的Pod已经完成调度并启动,为什么还是无法查询Pod 的 DNS 命名?如果需要在 Pod 调度完成之后及时发现,该怎么做?
先看看StatefulSet是如何为每个Pod分配DNS的呢?
StatefulSet
中管理的每个 Pod 会根据 StatefulSet 的名称和 以及为 Pod 的分配的有序索引(序号),派生出它的主机名。
组合主机名的格式为:
$(StatefulSet 名称)-$(序号)
StatefulSet
使用 Headless Services
控制内部 Pod 的网络域。
通过Headless Service为Pod
编号,在DNS服务器中生成带有编号的DNS记录,从而可以达到通过Pod名字定位到相应的服务
管理域的服务的格式为:
$(服务名称).$(命名空间).svc.cluster.local
其中 cluster.local
是集群域。 一旦每个 Pod 创建成功,就会得到一个匹配的 DNS 子域,格式为: $(pod 名称).$(所属服务的 DNS 域名)
,其中所属服务由 StatefulSet
的 serviceName
域来设定。
了解完分配和组成,接下来说一下为什么会出现查询失败的情况呢?
第一种情况,Pod尚在创建过程中,这时候查询,DNS命名还未分配成功
第二种情况,Pod已经创建成功,取决于集群域内部 DNS 的配置,可能无法查询一个刚刚启动的 Pod 的 DNS 命名。原因是k8s有个负缓存的概念。
负缓存 (在 DNS 中较为常见)
之前失败的查询结果会被记录和重用至少若干秒钟
默认缓存时长为 30s
查询过程
第一次查询结果是失败
结果记录到负缓存中,标注失败
在缓存周期内查询,直接从负缓存中取,结果是失败
如何及时发现创建的Pod的DNS命名?
如果需要在 Pod 被创建之后及时发现它们,有以下选项:
- 直接查询
Kubernetes API
(比如,利用watch
机制)而不是依赖于 DNS 查询 - 缩短
Kubernetes DNS
驱动的缓存时长(修改CoreDNS
的ConfigMap
,目前DNS缓存时长为 30 秒)
更多推荐
所有评论(0)