乐趣区

关于k8s:k8s集群StatefulSets的Pod调度查询丢失问题

jiezi

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 秒）

获取更多干货，欢送关注微信公众号：囧么肥事

Kubernetes 举荐学习书

Kubernetes 权威指南 PDF
链接: https://pan.baidu.com/s/11huL… 提取码:sa88

退出移动版