请注意，我们可能还应该将服务重命名为 lbservice 或类似名称，以将它们与其他类型的服务区分开来。

bgrant0607 于 2014-06-28

作为其中的一部分，我将从核心 apiserver 中删除服务对象，并促进其他负载均衡器的使用，例如 HAProxy 和 nginx。

bgrant0607 于 2014-07-10

如果服务的逻辑定义（查询和/或全局名称）能够以多种方式使用/专门化，那就太好了——作为通过基础设施安装的简单负载均衡器，作为像 nginx 这样功能更多的完整负载均衡器或基础设施也提供的 haproxy，作为集成商可以轮询/等待的可查询端点 (GET /services/foo -> { endpoints: [{host, port}, ...] })，或作为主机可用的信息公开本地负载平衡器。显然，这些可能是多个不同的用例，因此分为自己的资源，但是具有一定的灵活性来指定与机制不同的意图（在 lb 下统一）可以更容易地满足广泛的需求。

smarterclayton 于 2014-07-10

@smarterclayton我同意分离政策和机制。

我们需要的原语：

轮询/观看由标签选择器标识的集合的能力。不确定是否有提交的问题。
查询 pod IP 地址的能力（#385）。

这足以与其他命名/发现机制和/或负载平衡器组合。然后，我们可以在核心之上构建一个更高级别的层，该层将通用模式与简单的 API 捆绑在一起。

bgrant0607 于 2014-07-10

@bgrant0607描述的两个原语是否值得让这个问题保持开放？或者我们可以提交更具体的问题吗？

brendandburns 于 2014-07-14

我不认为zookeeper 已经解决了——因为你需要每个容器中的唯一标识符。我_认为_您可以使用 3 个独立的复制控制器（每个实例一个）或复制控制器上的一种模式来做到这一点。

smarterclayton 于 2014-07-14

正如布赖恩所说，我认为服务设计值得讨论。目前，它将基础架构抽象（本地代理）与公开机制（所有容器中的环境变量）与标签查询相结合。边缘代理有一个同样有效的用例，它采用 L7 主机/路径并将它们平衡到标签查询，以及支持 http(s) 和 Web 套接字等协议。此外，今天的服务有 60k 后端的硬性限制，在整个集群中共享（分配的 IP 数量）。应该可以在 minion 上运行本地代理，该代理仅代理该主机上的容器所需的服务，并且还可以避免容器必须知道外部端口。如有必要，我们可以将此讨论移至#494。

smarterclayton 于 2014-07-22

使用固定复制解决单例服务和非自动扩展服务的问题，例如主从复制数据库、具有固定大小对等组的键值存储（例如，etcd、zookeeper）等。

固定复制情况需要可预测的类似数组的行为。对等点需要能够发现彼此并单独寻址。这些服务通常有自己的客户端库和/或协议，因此我们不需要解决确定客户端应该连接到哪个实例的问题，除了使实例单独可寻址。

建议：我们应该创建一种新的服务，称为 Cardinal 服务，它映射 N 个 IP 地址而不是一个。 Cardinal 服务会将这些 IP 地址稳定分配给它们的标签选择器所针对的 N 个实例（即，指定的 N 个实例，而不仅仅是碰巧存在多个目标）。一旦我们有了 DNS (#1261, #146)，它就会根据提供的前缀分配可预测的 DNS 名称，后缀为 0 到 N-1。分配可以记录在目标 Pod 的注释或标签中。

这将保留角色分配与 pod 和复制控制器的身份的解耦，同时提供稳定的名称和 IP 地址，可用于标准应用程序配置机制。

关于不同类型负载平衡的一些讨论发生在服务 v2 设计中：#1107。

我将为主选举提交一个单独的问题。

/cc @smarterclayton @thockin

bgrant0607 于 2014-10-02

分配必须通过某种环境参数化机制（几乎可以肯定）传递到 pod 中。

对于 etcd 示例，我将创建：

复制控制器基数 1:1 pod，指向稳定存储卷 A
复制控制器基数 2：1 个 pod，指向稳定的存储卷 B
复制控制器基数 3：1 pod，指向稳定存储卷 C
指向 Pod 的主要服务“etcd”

如果 pod 2 挂了，复制控制器 2 会创建它的一个新副本并将其重新附加到卷 B。 Cardinal 服务“etcd”知道该 pod 是新的，但它如何知道它应该是基数 2（来自存储的数据）在 B 卷）？

smarterclayton 于 2014-10-02

而不是 3 个复制控制器，为什么不是一个分片控制器，它
做决定时会查看像“kubernetes.io/ShardIndex”这样的标签。如果
你想要 3 路分片，它制作了 3 个索引为 0、1、2 的豆荚。我觉得
这之前被击落过，但我无法重建它造成的麻烦
我的头。

如果这是一个相对的
常见场景。

您认为给定 pod 的标称 IP 是否因以下原因发生变化是否重要？
集合中不相关的变化？例如：

在时间 0 时，pods (A, B, C) 组成了一个主要服务，具有 IP
10.0.0.{1-3} 分别

在时间 1，托管 Pod B 的节点死亡

在时间 2，复制控制器驱动 B 创建一个新的 pod D

在时间 3，基数服务更改为 (A, C, D)，IP 为 10.0.0。{1-3}
分别

注意：pod C 的“稳定 IP”从 10.0.0.3 更改为 10.0.0.2
成员身份发生了变化。我希望这会对跑步造成不良影响
连接。

为了避免这种情况，我们需要指定序数值
在服务之外，或其他聪明的东西。也许那没问题，但它
如果人们不得不处理它，它似乎很脆弱并且很容易出错。

2014 年 10 月 2 日星期四上午 10:17，Clayton Coleman通知@github.com
写道：

任务必须通过一些方式传递到 Pod 中
环境参数化机制（几乎可以肯定）。
对于 etcd 示例，我将创建：
复制控制器基数 1：1 pod，指向稳定
存储卷A
复制控制器基数 2：1 个 pod，指向稳定
存储卷 B
复制控制器基数 3：1 pod，指向稳定
存储量 C
指向 Pod 的主要服务“etcd”
如果 pod 2 挂了，复制控制器 2 会创建它的一个新副本，然后
将其重新附加到卷 B。 Cardinal 服务 'etcd' 知道该 pod 是
new，但它怎么知道它应该是基数 2（来自
存储在卷 B) 上的数据？
直接回复此邮件或在 GitHub 上查看
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57663926
.

thockin 于 2014-10-02

我认为分片控制器是有意义的，并且在主要服务的上下文中可能更有用。

我确实认为基于成员资格的 IP 变化很可怕，我可以想到一堆退化的边缘情况。但是，如果基数与 Pod 一起存储，那么决定就不那么困难了。

smarterclayton 于 2014-10-02

首先，我不打算将其与分片有关 - 那是 #1064。让我们将分片讨论转移到那里。我们已经看到许多尝试使用类似机制进行分片的案例，我们得出的结论是这不是实现分片的最佳方式。

bgrant0607 于 2014-10-02

其次，我的意图是不需要运行 N 个复制控制器。应该可以只使用一个，但所需的数量取决于部署细节（金丝雀、多个发布轨道、滚动更新等）。

bgrant0607 于 2014-10-02

第三，我同意我们需要考虑这将如何与持久数据提案 (#1515) -- @erictune 进行交互。

bgrant0607 于 2014-10-02

四，我同意我们可能需要将身份反映到 pod 中。根据 #386，理想情况下，将使用标准机制使 IP 和 DNS 名称分配对 pod 可见。 IP 和主机别名通常如何在 Linux 中出现？

bgrant0607 于 2014-10-02

第五，我建议我们通过标签或注释在 pod 中记录分配来确保分配稳定性。

bgrant0607 于 2014-10-02

👍1

第六，用“分片控制器”代替复制控制器的问题是我想将角色分配与图像/环境管理分离。我认为复制控制器提供了后者（参见 https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment-57678564）。

bgrant0607 于 2014-10-02

对于持久数据，根据 #1515：

对于耐用的 pod，这个提议会奏效。对于持久的 pod，分配将是稳定的。
对于单独的数据对象，cardinal 服务还需要管理数据对象的角色分配，并将角色分配推迟到 pod，直到它们与数据匹配。我认为这很简单。

/cc @erictune

bgrant0607 于 2014-10-02

我认为您试图让对话更容易进行，但我不确定它是否有效。

回复：分片 - “一组具有不同身份的副本”基本上不是分片吗？

回复：1 个复制控制器 - 我们今天没有复制控制器分配索引。我不认为我们想要那个，是吗？

回复：告诉 pod 自己的身份 - 服务是 pod 上的一个干净的层。将即将到来的 pod 告知服务以便它可以在 IP 存在之前分配它会很麻烦。我认为 ID 需要是 pod 的一部分，例如 ShardIndex 标签或其他东西。我们可以（以某种方式）将其反映到 pod 中，服务可以使用它来分配 IP。如果我们让 Cardinal 服务自己做这件事，那么 pod 在分配时就已经启动了。我们可以像 GCE 中的虚拟机一样拥有每个 Pod 的元数据，但这是一个更大的提议。

thockin 于 2014-10-02

不，提供稳定、独特的身份对于分片来说既不必要也不充分。有关详细信息，请参阅 #1064，这是我刚刚在那里添加的。

不，我们不希望复制控制器分配索引。我特意建议 Cardinal 服务部门这样做。

bgrant0607 于 2014-10-02

是的，我希望 pod 在分配角色（索引）之前就存在（并且可能已经启动）。那是故意的。还需要可以撤销分配。

bgrant0607 于 2014-10-02

可能的身份方法：在容器中创建一个非持久性 IP 别名，并在 DNS 实现中提供反向 DNS 查找。

但是，我不认为将身份连接到 pod 容器中对于许多用例来说是必不可少的。如果应用程序使用自注册，它甚至可能不需要这种机制。

bgrant0607 于 2014-10-03

如果服务经理愿意保留一些状态而不是它的
目前可以，我们只能记住之前所做的映射
并努力尊重他们。

2014 年 10 月 2 日星期四晚上 8:59，bgrant0607 [email protected]写道：

可能的身份方法：在
容器并在 DNS 实现中提供反向 DNS 查找。
但是，我不认为将身份插入 pod 容器是
许多用例必不可少。如果应用程序正在使用
自注册，它可能甚至不需要这种机制。
直接回复此邮件或在 GitHub 上查看
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57749083
.

thockin 于 2014-10-03

回覆。记住映射，我同意——见https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57679787。

不过，我不知道这与您回复的评论有何相关性。

bgrant0607 于 2014-10-03

GitHub 和电子邮件不能混用。对不起

在星期四，2014年10月2日在下午9时39分，bgrant0607 [email protected]写道：

回覆。记住映射，我同意——见#260（评论）
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57679787
.
不过，我不知道这与您回复的评论有何相关性。
直接回复此邮件或在 GitHub 上查看
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57750769
.

thockin 于 2014-10-03

Tim 建议使用“nominal”，我同意它更合适。

http://www.mathsisfun.com/definitions/nominal-number.html
http://www.mathsisfun.com/definitions/cardinal-number.html
http://www.mathsisfun.com/definitions/ordinal-number.html

bgrant0607 于 2014-10-17

我也喜欢名义上的。讨厌向用户解释它，但它经常用于配置创建的东西（即名义上的 mongodb 副本集将成为复制控制器、名义上的服务、卷，所以它已经有些复杂了）。

- - - 原始信息 - - -

Tim 建议使用“nominal”，我同意它更合适。
http://www.mathsisfun.com/definitions/nominal-number.html
http://www.mathsisfun.com/definitions/cardinal-number.html
http://www.mathsisfun.com/definitions/ordinal-number.html
直接回复此邮件或在 GitHub 上查看：
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -59438307

smarterclayton 于 2014-10-30

我看到两个问题：

角色分配涉及至少为每个 pod 设置环境变量或卷设置（即第一个 pod 需要获取卷 a，如果删除它的替换需要相同的卷）
如果名义服务的 pod 来自单个 repl 控制器，则必须在创建之后但在绑定 pod 之前修改模板。

这似乎意味着角色分配是作为工作流步骤位于 apiserver 和调度程序之间的控制器。它还意味着模板的某种形式的转换或覆盖，这样没有角色分配的模板不一定有意义。

分片控制器似乎是这个问题的一个变种，只是为了更复杂的角色分配。

smarterclayton 于 2014-11-16

每个实例运行一个服务的 zookeeper 示例： http :

bgrant0607 于 2014-12-17

所以我知道这是一个由来已久的话题，但它触及了一个对我来说很亲近的话题；-)

如果系统可以将非 nat 的“名义服务”的前向+反向记录推送到 Skydns 并使用名称作为 ENV 注入到使用该服务的 pod 中，是否还有其他限制？

在 ZK 的情况下，它可能看起来有点奇怪，其中仲裁中的每个元素都将使用其他元素，例如：
zk1 用途：zk2、zk3
zk2 用途：zk1、zk3
zk3 用途：zk1、zk2

但理论上它应该可以正常工作吗？前提是我们可以为名义服务添加反向记录。

@bgrant0607我错过了什么吗？

当其他应用程序希望使用它提供的整体服务时，它变得有点奇怪。（https://github.com/GoogleCloudPlatform/kubernetes/issues/1542）

timothysc 于 2015-03-04

@timothysc如果 zk1、zk2 和 zk3 是服务，那么您提出的建议将起作用，至少支持多端口服务一次。

bgrant0607 于 2015-03-08

是的，不过这里有一个丑陋的地方。

正在运行的 pod 不知道它“前面”的是什么服务。例如给定一个服务
在一个后端实例中，用于访问服务的 VIP 不知道
后端（除非它通过了解服务来寻求该信息
名称）。在名义服务 (N) 中，您将拥有 N 个后端和 N 个 VIP（以及
大概是 N 个 DNS 名称或 N 个地址名称），但后端仍然会
不知道自己的贵宾。他们可能会观察 DNS 名称池，但是
不知道（没有探索）哪个是自我。这会让你的 ZK
很难使用 VIP（现在 VIP 也可观察到代理）。

备择方案：

1）设置1个服务（N）并让每个实例为自己探测所有VIP

2) 设置 N 个 service(1) 实例并使用标签和 cmdline 标志来
手动分配索引，让每个 ZK 后端知道（先验）DNS 名称
彼此的 ZK 后端

3）为标签选择器做DNS，为ZK副本集分配一个DNS名称，
希望客户正确使用DNS

4) 在每个同步 kubernetes 端点的 ZK 旁边运行 kube2zk 桥 ->
ZK配置

5) 设计另一种分配 VIP 或指数的方法
以复制控制器为中心而不是以服务为中心。布兰登和我
前一段时间在这里集思广益，但没有时间遵循
之上。

至于反向DNS——我不确定我看到它的作用？我并不反对
支持它（即要求@bketelsen支持它:) 但我不这么认为
适用于此处。流量永远不会“来自”服务 IP。

蒂姆

2015 年 3 月 7 日星期六晚上 8:56，Brian Grant通知@github.com
写道：

@timothysc https://github.com/timothysc如果
zk1、zk2 和 zk3 是服务，至少有一次多端口服务是
支持的。
—
直接回复此邮件或在 GitHub 上查看
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77733331
.

thockin 于 2015-03-08

(5) 听起来像这个提议。

bgrant0607 于 2015-03-08

我是 5 的忠实粉丝 - 知道自己角色的 Pod 是第一步，具有唯一 DNS 标识或使用端点获取其他 IP 并对其做出反应的 Pod 是两个。能够通过稳定的角色 id 在端点中查找 pod ip 将是第三个。

在2015年3月8日，在上午11:06，蒂姆·霍金[email protected]写道：
是的，不过这里有一个丑陋的地方。
正在运行的 pod 不知道它“前面”的是什么服务。例如给定一个服务
在一个后端实例中，用于访问服务的 VIP 不知道
后端（除非它通过了解服务来寻求该信息
名称）。在名义服务 (N) 中，您将拥有 N 个后端和 N 个 VIP（以及
大概是 N 个 DNS 名称或 N 个地址名称），但后端仍然会
不知道自己的贵宾。他们可能会观察 DNS 名称池，但是
不知道（没有探索）哪个是自我。这会让你的 ZK
很难使用 VIP（现在 VIP 也可观察到代理）。
备择方案：
1）设置1个服务（N）并让每个实例为自己探测所有VIP
2) 设置 N 个 service(1) 实例并使用标签和 cmdline 标志来
手动分配索引，让每个 ZK 后端知道（先验）DNS 名称
彼此的 ZK 后端
3）为标签选择器做DNS，为ZK副本集分配一个DNS名称，
希望客户正确使用DNS
4) 在每个同步 kubernetes 端点的 ZK 旁边运行 kube2zk 桥 ->
ZK配置
5) 设计另一种分配 VIP 或指数的方法
以复制控制器为中心而不是以服务为中心。布兰登和我
前一段时间在这里集思广益，但没有时间遵循
之上。
至于反向DNS——我不确定我看到它的作用？我并不反对
支持它（即要求@bketelsen支持它:) 但我不这么认为
适用于此处。流量永远不会“来自”服务 IP。
蒂姆
2015 年 3 月 7 日星期六晚上 8:56，Brian Grant通知@github.com
写道：
@timothysc https://github.com/timothysc如果
zk1、zk2 和 zk3 是服务，至少有一次多端口服务是
支持的。
—
直接回复此邮件或在 GitHub 上查看
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77733331
.
—
直接回复此邮件或在 GitHub 上查看。

smarterclayton 于 2015-03-08

那我得花点时间多写一点这个想法。

2015 年 3 月 8 日星期日上午 10:25，Clayton Coleman通知@github.com
写道：

我是 5 的超级粉丝 - 知道自己角色的豆荚是第一步，豆荚
拥有唯一的 DNS 标识或使用端点获取其他 IP 和
对它的反应是两个。能够通过以下方式在端点中查找 pod ip
稳定的角色 ID 将排在第三位。
2015 年 3 月 8 日上午 11:06，Tim Hockin通知@ github.com
写道：
是的，不过这里有一个丑陋的地方。
正在运行的 pod 不知道它“前面”的是什么服务。例如，给定一个
服务
在一个后端实例中，用于访问服务的 VIP 未知
经过
后端（除非它通过了解服务来寻求该信息
名称）。在名义服务（N）中，您将拥有 N 个后端和 N 个 VIP
（和
大概是 N 个 DNS 名称或 N 个地址名称），但后端会
仍然
不知道自己的贵宾。他们可能会观察 DNS 名称池，但是
不知道（没有探索）哪个是自我。这会让你的 ZK
很难使用 VIP（现在 VIP 也可观察到代理）。
备择方案：
1）设置1个服务（N）并让每个实例为自己探测所有VIP
2) 设置 N 个 service(1) 实例并使用标签和 cmdline 标志来
手动分配索引，让每个 ZK 后端知道（先验）DNS
名称
彼此的 ZK 后端
3）为标签选择器做DNS，为ZK副本集分配一个DNS名称，
希望客户正确使用DNS
4) 在每个同步 kubernetes 端点的 ZK 旁边运行 kube2zk 桥
->
ZK配置
5) 设计另一种分配 VIP 或指数的方法
以复制控制器为中心而不是以服务为中心。布兰登和我
前阵子在这里集思广益，但没有时间
跟随
之上。
至于反向DNS——我不确定我看到它的作用？我并不反对
支持它（即要求@bketelsen支持它:) 但我不这么认为
适用于此处。流量永远不会“来自”服务 IP。
蒂姆
2015 年 3 月 7 日星期六晚上 8:56，Brian Grant通知@github.com
写道：
@timothysc https://github.com/timothysc您提出的建议可行
如果
zk1、zk2 和 zk3 是服务，至少有一次多端口服务是
支持的。
—
直接回复此邮件或在 GitHub 上查看
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment-77733331>
.
—
直接回复此邮件或在 GitHub 上查看。
—
直接回复此邮件或在 GitHub 上查看
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77762731
.

thockin 于 2015-03-08

@thockin 回复：反向 DNS，让我们

ZK 将在没有它的情况下崩溃，许多其他分布式系统也是如此。

timothysc 于 2015-03-09

RC 将唯一标签 (members=#) 应用于它创建的每个 pod，并尝试创建最多 N 个副本的序列，然后是一个无头服务，为“成员”标签的每个值创建一个 A 和 CNAME 名称（# .service.namespace.local)，其中根服务于所有这些 service.namespace.local -> round robin -> 1.service.namespace.local, 2.service.namespace.local 似乎是本地的。

我们_可以_对这些单独的 DNS 标签使用严格的 pod IP。为每个人创建假 IP 会很昂贵，而且容器将无法将自己的 IP 发送给某人。

- - - 原始信息 - - -

@thockin 回复：反向 DNS，让我们
要求。
ZK 将在没有它的情况下崩溃，许多其他分布式系统也是如此。
直接回复此邮件或在 GitHub 上查看：
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369

smarterclayton 于 2015-03-09

@timothysc 回复：反向 DNS - 什么是反向 DNS？源IP
连接？这些都不适用于 kube。通过服务的连接是
代理，所以 source-ip 首先不起作用（可以修复）。

我不知道 ZK - 你能解释一下他们试图通过反向获得什么吗
域名解析？这似乎是一个非常脆弱的假设。

2015 年 3 月 9 日星期一上午 9:05，Timothy St. Clair通知@github.com
写道：

@thockin https://github.com/thockin回复：反向 DNS，让我们挥手吧
我们的手，并认为这是一项要求。
ZK 将在没有它的情况下崩溃，许多其他分布式系统也是如此。
—
直接回复此邮件或在 GitHub 上查看
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369
.

thockin 于 2015-03-10

我认为我的经验（也许是 Tim 的）是当今大多数集群软件都期望以下内容：

每个节点都有一个稳定的身份
该身份是一个 DNS 名称
底层身份的 IP 不必是稳定的
节点希望通过其稳定身份 (DNS) 或公共 IP 向其他节点表明自己的身份
一些集群软件期望客户端到达它的节点的 IP 匹配一个 IP，它可以向集群中的其他人宣布自己，并且该 IP 是可访问的。

- - - 原始信息 - - -

@timothysc 回复：反向 DNS - 什么是反向 DNS？源IP
连接？这些都不适用于 kube。通过服务的连接是
代理，所以 source-ip 首先不起作用（可以修复）。
我不知道 ZK - 你能解释一下他们试图通过反向获得什么吗
域名解析？这似乎是一个非常脆弱的假设。
2015 年 3 月 9 日星期一上午 9:05，Timothy St. Clair通知@github.com
写道：
@thockin https://github.com/thockin回复：反向 DNS，让我们挥手吧
我们的手，并认为这是一项要求。
ZK 将在没有它的情况下崩溃，许多其他分布式系统也是如此。
—
直接回复此邮件或在 GitHub 上查看
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369
.
直接回复此邮件或在 GitHub 上查看：
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78063150

smarterclayton 于 2015-03-10

2015 年 3 月 9 日星期一下午 12:49，Clayton Coleman
通知@github.com写道：

RC 将唯一标签 (members=#) 应用于它创建的每个 pod，并尝试创建一个序列
N 个副本，然后是一个无头服务，该服务为“成员”的每个值创建了一个 A 和 CNAME 名称
标签（#.service.namespace.local），其中根服务于所有这些 service.namespace.local -> round
robin -> 1.service.namespace.local, 2.service.namespace.local 似乎是本地的。

Brendan 和我在周围蹦蹦跳跳的想法基本上是一个游泳池
令牌，也许是 RC 的一部分，也许不是，RC 的每个元素
会被分配。鉴于该令牌，可以分配其他东西

VIP、PD、通用索引等。
死亡，令牌返回到池中，当该 pod 被替换时
该令牌被重新使用。

问题在于如何将“任意令牌”变成
有意义的东西。

我们_可以_对这些单独的 DNS 标签使用严格的 pod IP。为每个人创建假 IP 会很昂贵，而且容器将无法将自己的 IP 发送给某人。

我没试过，但我敢打赌我们可以让名义服务做完整的 SNAT
和 DNAT，因为它们是 1:1。这将是一种稳定的方式
没有可迁移 IP 的每个 Pod 的 IP。

- - - 原始信息 - - -
@thockin 回复：反向 DNS，让我们
要求。
ZK 将在没有它的情况下崩溃，许多其他分布式系统也是如此。
直接回复此邮件或在 GitHub 上查看：
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369
—
直接回复此邮件或在 GitHub 上查看。

thockin 于 2015-03-10

我绝不会游到上游 - 如果有足够多的应用程序真的希望 DNS
以这种方式工作，我们可以让它以这种方式工作。

草图：

创建复制控制器 R 创建一个 DNS 名称“$R.rc”，它是
该 RC“下”的 pod IP 池。每个 pod P 都有一个 DNS 名称
“$P.$R.rc”。但是什么是P？它可能是简单的索引，但它有
在内心狠狠地咬我们。它可以是像 GenerateName 这样的随机字符串，
但它们必须在 pod 死亡/重启后幸存下来（也许 pod 主机名应该
比赛？）。

2015 年 3 月 10 日，星期二，上午 7:59，Clayton Coleman通知@github.com
写道：

我认为我的经验（也许是 Tim 的）是大多数集群
今天的软件期望如下：
每个节点都有一个稳定的身份
该身份是一个 DNS 名称
底层身份的 IP 不必是稳定的
该节点希望通过其稳定的
身份 (DNS) 或其公共 IP
一些集群软件期望节点的IP为客户端
到达它以匹配它可以向其他人宣布自己的 IP
集群和该 IP 是可访问的。
- - - 原始信息 - - -
@timothysc 回复：反向 DNS - 什么是反向 DNS？源IP
连接？这些都不适用于 kube。通过服务的连接是
代理，所以 source-ip 首先不起作用（可以修复）。
我不知道 ZK - 你能解释一下他们试图通过反向获得什么吗
域名解析？这似乎是一个非常脆弱的假设。
2015 年 3 月 9 日星期一上午 9:05，Timothy St. Clair <
通知@github.com>
写道：
@thockin https://github.com/thockin回复：反向 DNS，让我们挥手吧
我们的手，并认为这是一项要求。
ZK 将在没有它的情况下崩溃，许多其他分布式系统也是如此。
—
直接回复此邮件或在 GitHub 上查看
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369
.
直接回复此邮件或在 GitHub 上查看：
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78063150
—
直接回复此邮件或在 GitHub 上查看
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78071406
.

thockin 于 2015-03-10

我有点喜欢将 DNS 附加到名义服务而不是 RC。

内部简单索引的痛点是什么？ P > 5000？

- - - 原始信息 - - -

我绝不会游到上游 - 如果有足够多的应用程序真的希望 DNS
以这种方式工作，我们可以让它以这种方式工作。
草图：
创建复制控制器 R 创建一个 DNS 名称“$R.rc”，它是
该 RC“下”的 pod IP 池。每个 pod P 都有一个 DNS 名称
“$P.$R.rc”。但是什么是P？它可能是简单的索引，但它有
在内心狠狠地咬我们。它可以是像 GenerateName 这样的随机字符串，
但它们必须在 pod 死亡/重启后幸存下来（也许 pod 主机名应该
比赛？）。
2015 年 3 月 10 日，星期二，上午 7:59，Clayton Coleman通知@github.com
写道：
我认为我的经验（也许是 Tim 的）是大多数集群
今天的软件期望如下：
每个节点都有一个稳定的身份
该身份是一个 DNS 名称
底层身份的 IP 不必是稳定的
该节点希望通过其稳定的
身份 (DNS) 或其公共 IP
一些集群软件期望节点的IP为客户端
到达它以匹配它可以向其他人宣布自己的 IP
集群和该 IP 是可访问的。
- - - 原始信息 - - -
@timothysc 回复：反向 DNS - 什么是反向 DNS？源IP
连接？这些都不适用于 kube。通过服务的连接是
代理，所以 source-ip 首先不起作用（可以修复）。
我不知道 ZK - 你能解释一下他们试图通过反向获得什么吗
域名解析？这似乎是一个非常脆弱的假设。
2015 年 3 月 9 日星期一上午 9:05，Timothy St. Clair <
通知@github.com>
写道：
@thockin https://github.com/thockin回复：反向 DNS，让我们挥手吧
我们的手，并认为这是一项要求。
ZK 将在没有它的情况下崩溃，许多其他分布式系统也是如此。
—
直接回复此邮件或在 GitHub 上查看
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -77883369
.
直接回复此邮件或在 GitHub 上查看：
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78063150
—
直接回复此邮件或在 GitHub 上查看
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78071406
.
直接回复此邮件或在 GitHub 上查看：
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78080138

smarterclayton 于 2015-03-10

+1 到特殊外壳 1:1 VIP。我认为这将是一个普遍的案例。

我仍然担心动态更改 DNS 映射。我更喜欢不需要那个的方法。

在评估替代方案时要记住的一点是，我 100% 肯定我们最终将需要 2 个具有相同角色的 Pod 同时共存，旧的和新的。因此，角色不能与对象名称或其他必须唯一且必须在创建 pod 时一成不变的东西相关联。

如果我们将角色分配机制与复制控制器联系起来，那几乎排除了滚动更新、金丝雀等。如果可能的话，我想避免这种情况。

bgrant0607 于 2015-03-10

@smarterclayton简单的索引不会因规模而产生问题。这是模型的原因。看到我几分钟前的评论。如果可以独立于 pod 和 RC 身份动态分配简单索引，则它们是可行的方法。

bgrant0607 于 2015-03-10

鉴于问题之一是面向系统的假设，Linux 可以为我们做些什么吗？例如，我们可以在容器中为服务 VIP 创建一个 IP 别名或类似的东西吗？

bgrant0607 于 2015-03-10

大家好，

这周我都出去了。这是一次非常有趣的对话，但它需要
比我手头有更多的时间。我很乐意坐下来实际讨论
下周时间。

2015 年 3 月 10 日星期二下午 3:56，Brian Grant通知@github.com
写道：

鉴于问题之一是面向系统的假设，是否有
Linux 能为我们做些什么？例如，我们可以创建一个 IP
服务 VIP 的容器中的别名或其他名称？
—
直接回复此邮件或在 GitHub 上查看
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78166544
.

thockin 于 2015-03-11

我接下来两天没钱了——下周就是了。

在2015年3月10日，11:33 PM，蒂姆·霍金[email protected]写道：
大家好，
这周我都出去了。这是一次非常有趣的对话，但它需要
比我手头有更多的时间。我很乐意坐下来实际讨论
下周时间。
2015 年 3 月 10 日星期二下午 3:56，Brian Grant通知@github.com
写道：
鉴于问题之一是面向系统的假设，是否有
Linux 能为我们做些什么？例如，我们可以创建一个 IP
服务 VIP 的容器中的别名或其他名称？
—
直接回复此邮件或在 GitHub 上查看
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78166544
.
—
直接回复此邮件或在 GitHub 上查看。

smarterclayton 于 2015-03-11

下周 +1，也许是一个聚会。

timothysc 于 2015-03-11

由于相关话题的出现，再次戳此贴（https://github.com/GoogleCloudPlatform/kubernetes/issues/4825#issuecomment-76193417, https://github.com/GoogleCloudPlatform/kubernetes/issues/175#issuecomment-84423902 , https://github.com/GoogleCloudPlatform/kubernetes/issues/1607#issuecomment-88177147, #6393)。

我们如何将网络身份（DNS 名称和/或 IP 地址）分配给单个 Pod，这些 Pod 可能是单例或标称集的一部分？
我们如何将身份传达给 Pod 内的容器？

我们应该安排一次环聊，还是使用每周一次的社区环聊？

bgrant0607 于 2015-04-08

还有https://github.com/openshift/mongodb/pull/14 ，我们开始对成员集初始化的通用模式进行原型设计（我们可以将其放入容器或库中，或者......）

@danmcp @mfojtik

- - - 原始信息 - - -

由于相关主题弹出再次戳这个线程
( https://github.com/GoogleCloudPlatform/kubernetes/issues/4825#issuecomment -76193417,
https://github.com/GoogleCloudPlatform/kubernetes/issues/175#issuecomment -84423902，
https://github.com/GoogleCloudPlatform/kubernetes/issues/1607#issuecomment -88177147，
6393）。
我们如何将网络身份（DNS 名称和/或 IP 地址）分配给
单个 Pod，可能是单例还是标称集的一部分？
我们如何将身份传达给 Pod 内的容器？
我们应该安排一次环聊，还是使用每周一次的社区环聊？
直接回复此邮件或在 GitHub 上查看：
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -91041442

smarterclayton 于 2015-04-08

IIUC，其中一个难题是主选举#1542。

bgrant0607 于 2015-04-09

是的，我们讨论过。对于大多数可以自己选举成员资格的集群来说，这是最重要的（从 Kube 端点检测成员资格，应用于集群），但总是有不同的方法来处理它。例如，Cassandra 基本上使用 Kube 作为成员资格的外部真实来源，因此它是 SEP，这使得领导选举更容易。尽管我相信根据成员滞后的方式，如果成员资格变动，您最终可能会出现分区。

对于 mongo，您希望联系每个成员并让他们加入现有集群或形成新集群。如果存在多个集群，您不想让它们变得更糟。

smarterclayton 于 2015-04-09

请注意，将服务 IP 传送到容器的问题类似于将外部 IP 传送到 VM： https : http://169.254.169.254/computeMetadata/v1/instance/network-interfaces/0/access-configs/0/external-ip 。 AWS 是类似的： http://169.254.169.254/latest/meta-data/public-ipv4 。

bgrant0607 于 2015-04-09

@smarterclayton我更新了 mongo 原型 PR： https :

它现在正在使用初始化副本集的一次性 Pod

mfojtik 于 2015-04-09

回覆。将此机制与复制/分片控制器联系起来：

尝试复制控制器和/或 pod 对象名称的 DNS 名称会强制就地更新模型。需要实现一种完全不同类型的“就地”滚动更新，同时以某种方式通过单个控制器同时支持多个模板。这也意味着为了执行某些类型的更新（包括移动到新主机），需要删除 pod，然后使用相同的名称重新创建，与我们添加新主机的方法相比，这会增加停机时间豆荚拿走一个旧的。

代币池的想法听起来很棒。我只是认为它需要与 RC 分离。

bgrant0607 于 2015-04-10

如果我们要添加一个控制器，这可以耦合到更高级别的控制器。将进一步评论 #1743 和/或 #503。

bgrant0607 于 2015-04-10

这不应该真正与 #1743 中提出的 DeploymentController 耦合。它不适用于多个独立发布轨道的场景，也不适用于有人想要使用不同机制控制其发布的情况，例如提议的名称交换滚动更新。出于类似的原因，我不会将 DNS 名称与 pod/RC/DC 对象名称联系起来。

所以我们又回到了某种服务风格，或者说是一个完全独立的控制器。也许端点控制器可以为服务端点分配索引？ Endpoints 本身是一个足够可靠的地方来记录这些数据吗？如果它丢失了，所有的 pod 都会被重新索引。

为了促进身份向下传递到 pod 中的容器（例如通过 #2316 中讨论的 env. var. 替换），当通过子资源分配/取消分配角色时，在 pod 上设置一个字段会很有用。这也可以解决耐用性问题。

我们应该在 DNS 模式中为名义实例保留空间——#6666。

根据https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -78071406，我可以购买我们可以尝试使用 pod IP 并仅为名义实例重新映射 DNS。

bgrant0607 于 2015-04-11

另外，我在 2 月份从 1.0 里程碑中删除了它（虽然不是 roadmap.md），但 #6393 中的讨论表明它可能会被添加回来。

bgrant0607 于 2015-04-11

@thockin建议：使用 DNS（PTR 记录）反向查找看起来是从 pod IP 到名义 DNS 名称的合理方法：
http://en.wikipedia.org/wiki/Reverse_DNS_lookup

bgrant0607 于 2015-04-11

是的，通过标准名称工具可以让“我是谁”变得非常容易。

2015 年 4 月 10 日晚上 8:11，Brian Grant [email protected]写道：
@thockin建议：使用 DNS（PTR 记录）反向查找看起来是从 pod IP 到名义 DNS 名称的合理方法：
http://en.wikipedia.org/wiki/Reverse_DNS_lookup
—
直接回复此邮件或在 GitHub 上查看。

smarterclayton 于 2015-04-11

/订阅

davidopp 于 2015-04-21

我不确定我是否理解这里的要求。

服务和 Pod 之间存在固有的 N 对 M 关系，由
系统的设计。像反向 DNS 之类的东西通常希望得到一个
单一响应：给定 pod 的 IP，获取规范名称。写的每个文档
关于 DNS 说“不要返回多个反向记录”。由于 Pod 可以
在 N 个服务中，这个单一的响应不能真正与服务相关。我们
可以对规范名称进行反向查找，然后对其进行 TXT 查找
名称为“你在什么服务下”，但这很难维护并且是
无论如何，本质上是一个自定义协议。

我认为将名义上的任何东西附加到 RC 的原因是，这是一个
更具体的关系。但它甚至不是。可以通过以下方式创建 Pod
一个 RC，成为孤儿，被另一个 RC 收养，然后被摧毁。或者
手动销毁

所以我不确定我们想用这个做什么，除了限制数量
一个 Pod 可能“低于”的服务数量，这听起来很糟糕。

行为要求是什么？我们想要达到什么目标。我们
可以为 DNS 和无头服务提供简单的集合语义。就是它
充足的？如果不是，为什么？

我们可以走极端，为 SNAT/DNAT pod 设置 iptables 规则
服务，以便他们都能在 VIP 上看到对方。例如，给定一组豆荚
（P1、P2、P3）他们将获得 VIP（V1、V2、V3）。从 P1 到 V2 的流量将
似乎来自 V1 等。客户端将访问 V{1,2,3}。但是什么
问题解决了，真的吗？它提供了稳定的 IP，但这不是一个
无头服务的普遍问题？

2015 年 4 月 21 日星期二下午 2:17，David Oppenheimer < [email protected]

写道：
/订阅
—
直接回复此邮件或在 GitHub 上查看
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -94945744
.

thockin 于 2015-04-22

目标非常具体。真正的集群系统具有具有“身份”的成员，该“身份”在出现节点故障的情况下预计是连续的。该身份可能会附加到永久磁盘或“名称”，但其他系统的身份名称不能更改。

例如，zookeeper 具有每个节点的标识。该身份必须在集群成员中保持稳定 - _可能_有两个 Pod 认为它们是 host1，但如果 host1 消失，host435 无法替换它。该 Pod 可能有一个重复使用的永久性磁盘，从一个地方移动到另一个地方，但是当它移动到另一个地方时，该 Pod 必须能够定义该身份。但是我们需要一种方法来分配#。

我怀疑我对名义服务的看法始终是启用具有小（3/5/7）成员资格的现有软件，而不是完全灵活的数百个用例。也许我们应该从这个讨论中分离出这个用例。

在2015年4月22日，凌晨1:59，蒂姆·霍金[email protected]写道：
我不确定我是否理解这里的要求。
服务和 Pod 之间存在固有的 N 对 M 关系，由
系统的设计。像反向 DNS 之类的东西通常希望得到一个
单一响应：给定 pod 的 IP，获取规范名称。写的每个文档
关于 DNS 说“不要返回多个反向记录”。由于 Pod 可以
在 N 个服务中，这个单一的响应不能真正与服务相关。我们
可以对规范名称进行反向查找，然后对其进行 TXT 查找
名称为“你在什么服务下”，但这很难维护并且是
无论如何，本质上是一个自定义协议。
我认为将名义上的任何东西附加到 RC 的原因是，这是一个
更具体的关系。但它甚至不是。可以通过以下方式创建 Pod
一个 RC，成为孤儿，被另一个 RC 收养，然后被摧毁。或者
手动销毁
所以我不确定我们想用这个做什么，除了限制数量
一个 Pod 可能“低于”的服务数量，这听起来很糟糕。
行为要求是什么？我们想要达到什么目标。我们
可以为 DNS 和无头服务提供简单的集合语义。就是它
充足的？如果不是，为什么？
我们可以走极端，为 SNAT/DNAT pod 设置 iptables 规则
服务，以便他们都能在 VIP 上看到对方。例如，给定一组豆荚
（P1、P2、P3）他们将获得 VIP（V1、V2、V3）。从 P1 到 V2 的流量将
似乎来自 V1 等。客户端将访问 V{1,2,3}。但是什么
问题解决了，真的吗？它提供了稳定的 IP，但这不是一个
无头服务的普遍问题？
2015 年 4 月 21 日星期二下午 2:17，David Oppenheimer < [email protected]
写道：
/订阅
—
直接回复此邮件或在 GitHub 上查看
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -94945744
.
—
直接回复此邮件或在 GitHub 上查看。

smarterclayton 于 2015-04-22

某种控制器可以动态设置/取消设置 Pod 上的某些字段。它不能与 pod 或 RC 身份混为一谈。将网络身份绑定到 pod 或 RC 身份完全被破坏了。

我不会尝试让反向 DNS 查找适用于普通或无头服务，而且我认为每个 pod 最多施加一个名义服务并不是不合理的——这根本不必限制其他类型的服务.

从长远来看，我们希望推动许多 DNS 限制（缓存失效、支持长轮询等）。多个 PTR 记录可能只是添加到该列表中的另一个项目。

另一种选择是，我们可以为标称服务的每个 pod 提供一个服务 IP，然后解决由此产生的问题。

bgrant0607 于 2015-04-22

- - - 原始信息 - - -

某种控制器可以动态设置/取消设置 Pod 上的某些字段。它
不能与 pod 或 RC 身份混为一谈。绑定网络身份
pod 或 RC 身份完全损坏。
我不会尝试使反向 DNS 查找适用于普通或无头
服务，而且我认为强加最多一个名义上的服务是不合理的
每个 Pod 的服务——不必限制其他类型的服务
全部。
从长远来看，我们希望推动许多 DNS 限制
（缓存失效，支持长轮询等）。多个 PTR 记录
也许只是添加到该列表中的另一个项目。
另一种选择是我们可以为每个 Pod 提供一个服务 IP
名义服务，然后解决产生的问题。

许多这些服务期望他们拥有的 IP（他们的名字）解析为他们连接的 IP——所以如果他们连接到 172.1.1.1 上的 X，那么 X 认为它的 172.1.1.1。这不是所有的软件，而是其中的一些。通常它是一个 DNS 名称，这意味着 IP 可以在下面更改。

直接回复此邮件或在 GitHub 上查看：
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -95266421

smarterclayton 于 2015-04-22

恐怕这一切对我来说还是有点抽象。

真正的集群系统具有具有“身份”的成员，该“身份”是
预计在节点故障的情况下是连续的。那个身份
可能附加到永久磁盘或“名称”，但名称
识别到其他系统不能改变。

这不是必需的。它是如此模糊以至于无法实现。

例如，zookeeper 具有每个节点的标识。这个身份必须保持
集群成员稳定

什么是身份？一个IP地址？传递给软件的字符串标志？
和环境变量？ zk进程如何得知自己的身份是什么？

某种控制器可以动态设置/取消设置 Pod 上的某些字段

这将触发那些 pod 重新启动，并且仍然不回答
什么字段，什么值，以及告诉 pod 什么逻辑的问题？

我可以看到类似将注释扩展到命令行标志的内容
（就像我们正在讨论 env vars）或只是进入 env vars。例如
控制器写注解["zookeeper.com/index"] = 9，我们转换
$.metatdata["zookeeper.com/index"] 进入 ZK_INDEX 环境。但我正在做这个
上，我没有看到具体的要求说明动物园管理员（或
随便）需要。

我不认为强加最多一项名义服务是不合理的
每个豆荚

我认为实施这些限制会很困难。系统是这样
松散耦合和异步，强加这些限制可能比
只是解决问题。

我们可以为标称服务的每个 Pod 提供一个服务 IP

这是我们开始的地方，但是......

许多这些服务期望他们拥有的 IP（他们的名字）
解析到它们连接的 IP - 所以如果它们连接到 172.1.1.1 上的 X，
那么 X 认为它的 172.1.1。

服务 IP 不能满足这一点，除非我们做一些更深入的事情，比如
我提到了 SNAT/DNAT。即便如此，它也有真正的缺点。

我不是想成为一个颈部疼痛，只是我们很少
运行到 1.0 的时间，这里没有什么足够清楚的
即使是概念验证，更不用说正确实施了。

我试图准确地确定我们想要体验的东西，以便我可以看到
我们可以实施的。鉴于对 DNS 的重复引用，我持有
关闭 DNS 返工，直到我知道这里发生了什么。

2015 年 4 月 22 日星期三上午 10:12，Clayton Coleman通知@github.com
写道：

- - - 原始信息 - - -
某种控制器可以动态设置/取消设置某些字段
豆荚。它
不能与 pod 或 RC 身份混为一谈。绑定网络
身份
pod 或 RC 身份完全损坏。
我不会尝试使反向 DNS 查找适用于普通或无头
服务，而且我认为强加一个最多是不合理的
名义上的
每个 Pod 的服务——不必限制其他类型的服务
全部。
有许多 DNS 限制我们希望长期推进
跑
（缓存失效，支持长轮询等）。多个PTR
记录
也许只是添加到该列表中的另一个项目。
另一种选择是我们可以为每个 Pod 提供一个服务 IP
名义服务，然后解决产生的问题。
许多这些服务都希望他们拥有的 IP（他们的名字）能够解析
到他们连接的 IP - 所以如果他们在 172.1.1.1 上连接到 X，那么 X
认为它的 172.1.1.1。这不是所有的软件，而是其中的一些。通常是
一个 DNS 名称，这意味着 IP 可以在下面更改。
直接回复此邮件或在 GitHub 上查看：
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -95266421
—
直接回复此邮件或在 GitHub 上查看
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -95267902
.

thockin 于 2015-04-23

大多数多端口示例都是集群系统。例如：
ZK ：配置文件中可解析的主机名或 IP 地址，以及文件中的“id”（即索引：1、2、3、...）

我们还应该查看一些数据库。

无论我们做什么，都不会对所有事情都有效。我们只需要找到最佳点。

bgrant0607 于 2015-04-23

- - - 原始信息 - - -

恐怕这一切对我来说还是有点抽象。
真正的集群系统具有具有“身份”的成员，该“身份”是
预计在节点故障的情况下是连续的。那个身份
可能附加到永久磁盘或“名称”，但名称
识别到其他系统不能改变。
这不是必需的。它是如此模糊以至于无法实现。
例如，zookeeper 具有每个节点的标识。这个身份必须保持
集群成员稳定
什么是身份？一个IP地址？传递给软件的字符串标志？
和环境变量？ zk进程如何得知自己的身份是什么？
某种控制器可以动态设置/取消设置 Pod 上的某些字段
这将触发那些 pod 重新启动，并且仍然不回答
什么字段，什么值，以及告诉 pod 什么逻辑的问题？
我可以看到类似将注释扩展到命令行标志的内容
（就像我们正在讨论 env vars）或只是进入 env vars。例如
控制器写注解["zookeeper.com/index"] = 9，我们转换
$.metatdata["zookeeper.com/index"] 进入 ZK_INDEX 环境。但我正在做这个
上，我没有看到具体的要求说明动物园管理员（或
随便）需要。
我不认为强加最多一项名义服务是不合理的
每个豆荚
我认为实施这些限制会很困难。系统是这样
松散耦合和异步，强加这些限制可能比
只是解决问题。
我们可以为标称服务的每个 Pod 提供一个服务 IP
这是我们开始的地方，但是......
许多这些服务期望他们拥有的 IP（他们的名字）
解析到它们连接的 IP - 所以如果它们连接到 172.1.1.1 上的 X，
那么 X 认为它的 172.1.1。
服务 IP 不能满足这一点，除非我们做一些更深入的事情，比如
我提到了 SNAT/DNAT。即便如此，它也有真正的缺点。
我不是想成为一个颈部疼痛，只是我们很少
运行到 1.0 的时间，这里没有什么足够清楚的
即使是概念验证，更不用说正确实施了。
我试图准确地确定我们想要体验的东西，以便我可以看到
我们可以实施的。鉴于对 DNS 的重复引用，我持有
关闭 DNS 返工，直到我知道这里发生了什么。

我认为这是明智的，我们应该专门花时间解决一组已知的例子。我们有 3 个可以用于具体示例（MongoDB 副本集、Zookeeper、Mysql 主/从）以及 kube/examples 中的现有示例。也许是一个工作会议来散列项目，为无法解决的问题设定界限，确定剩下的问题。

smarterclayton 于 2015-04-23

建议更改此功能的名称，因为它还可用于批处理作业以分配分片 ID 号。

davidopp 于 2015-04-23

批处理作业有一些不同的要求，所以我想把它们分开。

bgrant0607 于 2015-04-23

zookeeper 示例： https :

smarterclayton 于 2015-04-29

名义服务 ish 需要的示例https://github.com/GoogleCloudPlatform/kubernetes/blob/master/examples/rethinkdb/image/run.sh#L26

smarterclayton 于 2015-05-08

我有点困惑为什么这里的方向仍然不清楚 - 特别是来自 Google 员工。谷歌多年来一直在 Borg 下运行有状态服务，很清楚这种类型的工作负载需要什么：

当前 pod 代表的一组“分片”（非相同副本）中的一个的稳定标识符（在 borg 中，这是“任务编号”——一个简单的整数）。此标识符应在 pod 重新调度/重新启动期间保持不变。
一种枚举和联系所有“对等”分片的方法，可能是通过以某种方式使用它们的稳定标识符（在博格中，这是一个带有任务编号的胖前缀）

..我们完成了。

注意：如果资源排除对每个分片都至关重要，那么应用程序将需要执行自己的分布式锁定，因为在故障/重启期间 pod 的生命周期总是有可能重叠（可能使用基于分片标识符的 etcd 锁）。一个潜在的奇特功能扩展是在每个分片中允许多个相同的副本，以实现冗余/负载。

现在可以通过为每个分片创建唯一的服务/端口并运行带有副本的复制控制器来伪造这一点

在 kubernetes 中实现这一点的一种自然方式可能是：

Pod 获得额外的环境变量，给出它们自己的分片索引（整数）和分片总数（或者可能通过向下的 API 进行通信？）。
ReplicationControllers 获得“分片”计数（默认值：1），“副本”被重新解释为“每个分片内的副本”（默认值：1）。当缩小副本集时，它们应该从最后杀死（以保持分片索引连续）。请注意，更改“分片”将需要滚动重启受控 Pod 以更新其“总分片”环境变量（很好，您不希望它立即发生）。
服务获得类似的“分片”计数，将连续范围的端口映射到常规选择器加上隐式“分片索引”选择器。
Pod 可以通过使用 SERVICE_PORT（或一些新的 env var？）+ 分片索引偏移量来找到其他分片。

请注意，当 shards=1 时，上述行为会优雅地降级为当前行为。

anguslees 于 2015-05-14

我普遍同意这一点（正如你所说，它已经在 Borg 中经受了时间的考验），尽管我建议不要使用每个分片多个副本的“异国特征扩展”（尽管我们可能需要在覆盖迁移）。

正如我之前提到的，这与我们需要做什么来支持静态工作分配的批处理作业密切相关（我在这里称之为“类型 1”：https://github.com/GoogleCloudPlatform/kubernetes/issues/1624#issuecomment -97622142 )

davidopp 于 2015-05-14

如果我们更改了 RC（或添加了一些新的东西），我们需要调整的其他功能是部署的适应方式，特别是：

如何进行滚动更新：

一个普通的RC
PerNodeController
一个分片的 RC
批处理作业？

我们可能希望要么保持部署部署，直到我们为每个部署提供一个稻草人，因为我相信仅适用于简单 RC 的部署存在一些问题。

- - - 原始信息 - - -

我大体上同意这一点（正如你所说，它已经经受住了时间的考验
在博格中），尽管我建议不要使用“异国情调”
每个分片的多个副本的扩展（尽管我们可能需要一些东西
就像在迁移的封面下一样）。
正如我之前提到的，这与我们需要做的事情密切相关
支持具有静态工作分配的批处理作业（我称之为“类型 1”
这里：
https://github.com/GoogleCloudPlatform/kubernetes/issues/1624#issuecomment-97622142
)
直接回复此邮件或在 GitHub 上查看：
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -101918080

smarterclayton 于 2015-05-14

我们选择不为 1.0 优先考虑这一点（并自动生成持久卷声明），因为有多种解决方法，例如创建一个服务、RC 和每个实例的持久卷声明。

虽然 Borg 中密集、静态分配的任务索引被非常广泛地使用，但我们了解到它们有许多缺点，并且在过去几年中花费了一些时间来开发替代方案。许多问题源于这样一个事实，即索引与任务本身的生命周期和身份相关联。这使得许多部署策略、迁移、动态任务管理和许多其他场景的实施变得困难。其他复杂性源于为每个任务预部署静态生成每个索引配置——这相当于为每个索引值生成一个 RC。如果有人真的想这样做，那将是直接的。仍然可以使用标签来拆除整个系列。

每个节点/守护程序控制器：好点。在这种情况下，密集分配的索引是不好的模型。例如，当一个节点永久消失时，你会怎么做？指数变得稀疏。我建议我们不支持。

批处理作业：如 #1624 中所述，我们希望根据完成而不是当前正在运行的 Pod 分配索引。

如上所述，索引分配需要考虑关联存储，例如持久卷声明——身份源于网络身份（DNS 名称和/或 IP 地址）和存储。

分配不能由单个复制控制器驱动。这根本行不通。复制控制器不是持久实体，我们希望每个服务有多个 RC，用于金丝雀、滚动更新、多个发布轨道、多个集群等。即使是提议的部署对象 (#1743) 也没有正确的范围.

分配有 3 种选择：

将分配与特殊类型的服务相关联。服务具有完全正确的范围。（我们最终也将需要区域服务。）这将是常规服务和无头服务之间的混合体。这是我最初提出这种机制时所设想的。分配将记录在端点中。端点和/或无头 DNS 将是枚举所有对等点的明显方法。
创建一种类似于 Service 的新型对象，但仅用于名义服务。我们可能还需要一个新对象来记录分配。这会不必要地扩展我们的 API 表面，IMO。
“拉”而不是“推”。 Pod 被安排到没有显式控制器的主机上，即使有节点约束（选择器）或提议的反关联机制之一（https://github.com/GoogleCloudPlatform/kubernetes/issues/4301#issuecomment-74355529）。这也类似于服务 VIP 分配。我们可以为名义服务做类似的事情。一个 pod（或 pod 模板）将指定它想要从中分配索引的索引池。与一般服务不同，我们不希望 pod 需要从不同的池中分配多个索引。分配将记录在 pod 规范中。
优点：对用户来说更简单。不需要另一个对象。允许用户分配。
缺点：不同于其他类型的服务。

理想情况下，PVC 分配将使用相同的模型。

还值得考虑如何编排 pod 迁移 #3949。为了转移容器状态，必须在删除被替换的 Pod 之前创建替换 Pod。这可能会使拉模型有点问题。无论如何，分配机制需要具有迁移意识。

其他注意事项：

如何将索引/身份传达给对等方。 DNS 是显而易见的答案。
如何将索引/身份传达给 pod 中的容器。环境变量，反向 DNS，...分配的索引不会动态更改，尽管在 pod 仍然存在时 DNS 绑定可能会更改。我想选择一种机制，应用程序已经期望在其他环境中工作，并且与更广泛的向下 API 讨论（#386）一样，我不想将应用程序耦合到特定于 Kubernetes 的环境变量，而是新的 EnvVarSource和 env var 替换 (#7936) 将有助于避免这种情况。

bgrant0607 于 2015-05-14

我不同意你说的一些内容，但让我们等到 1.0 之后再继续讨论。

davidopp 于 2015-05-19

重温这个旧线程来问一个问题。对复制控制器命名策略有兴趣吗？如上所述，特别是名义上的命名，其中由该复制控制器控制的所有 Pod 都将具有编号后缀，例如 0001、0002 ....

一个示例用例是一个 nginx 负载均衡器，它通过域名指向这些 pod 集。所以随着 pod 的来来去去，域名预计总是固定在 xxx-0001 到 xxx-000N 之间。

ravigadde 于 2015-06-27

@ravigadde请阅读我对这个问题的最后评论： https :

bgrant0607 于 2015-06-27

在尝试设置 RabbitMQ 容器时遇到了这个问题。 Rabbit 的持久性取决于主机名，因此具有可变主机名意味着您在容器重新启动时会丢失 Mnesia 数据库。

尝试使用图像配置（直接主机名和 Rabbit）、ENV 变量和 Downward API 进行补救。无法解决问题 - Rabbit 仍会获取生成的 Pod 名称。通过根据@mikedanese的建议从使用复制控制器切换来临时解决。

mmayernick 于 2015-07-11

如果我理解正确的话， celerey-rabbit示例中的 rabbitmq pod（使用复制控制器创建）将在 pod 故障时丢失数据，即使数据存储在永久性磁盘上。来自rabbitmq doc：

RabbitMQ 使用系统的当前主机名命名数据库目录。如果主机名更改，则会创建一个新的空数据库。为避免数据丢失，设置固定且可解析的主机名至关重要。

现在没有一个好的解决方案，但您可以创建一个带有可迁移永久磁盘的 pod（未绑定到 rc），但需要注意的是，在某些故障情况下需要手动重新安排 pod。这是我能想到的保持主机名静态的唯一方法。

mikedanese 于 2015-07-11

或者在启动时将主机名目录符号链接到一个稳定的位置

2015 年 7 月 11 日下午 5:26，迈克·丹尼斯通知@github.com 写道：

如果我理解正确，rabbitmq pod（通过复制创建
控制器）在clerey-rabbit
https://github.com/GoogleCloudPlatform/kubernetes/tree/master/examples/celery-rabbitmq
即使数据存储在一个
永久性磁盘。来自rabbitmq doc：

RabbitMQ 使用当前主机名命名数据库目录
系统。如果主机名更改，则会创建一个新的空数据库。避免
数据丢失设置固定且可解析的主机名至关重要。

现在没有一个好的解决方案，但是您可以创建一个 pod（不是
绑定到具有可迁移永久性磁盘的 rc)，需要注意的是 pod
在某些故障情况下需要手动重新安排。那就是
我能想到的保持主机名静态的唯一方法。

—
直接回复此邮件或在 GitHub 上查看
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -120662490
.

smarterclayton 于 2015-07-12

这是为什么主机名不应该从 pod 名称派生的一个例子——#4825

bgrant0607 于 2015-07-13

给它一个轻微的踢：

有几个基本问题需要解决：

某些组件需要为每个 Pod 提供一个唯一的标识，该标识与它们在磁盘上的存储相关联
1. 作为进一步的皱纹，其中一些（在某些情况下是动物园管理员）需要主机名可解析并匹配
一些横向扩展的组件需要具有每个 Pod 不同的持久存储（Pod 指向每个 Pod 不同的 PVC，与身份相关联）
1. 有时，这些卷应该在扩展时按需创建
2. 有时这些卷应该从池中重用而不是重新创建
某些组件可能会扩展到数万个实例，在这种情况下，跟踪单个分配的身份变得不切实际
1. 名义上的大多数用途可能在 2-7 个 pod 实例之间（大多数当前可扩展的数据库，大多数分片多主设置）
一些组件不想实现自己的主选举，而是让平台通过使其中一个身份任意（身份 1 成为主）来管理它
当我们解决这些问题时，用户仍然需要对 pod 进行更改（通过部署）并确保任何身份都得到保留或重新分配。

这些不一定都需要在同一个解决方案中解决。例如，我认为小型集群标识（2-7）和大型集群标识（>7）之间存在显着差异。例如，在较大的情况下，该软件不太关心差距，或者具有现有的共识/成员协议。在较小的情况下，软件需要更多帮助来建立身份。我会将它们分为云原生 (>7) 和现有集群 (2-7) 软件。

smarterclayton 于 2015-08-18

我同意 1a、1b 和 2a。 2b 听起来像是一个不同的问题，但也许解决方案可以重用相同的模式。

我认为规模 (3) 主要表明我们对每个实例的一项服务和 RC 的解决方法是不够的，尽管我同意云原生与非云原生之间的区别。

主选举（4）可以单独处理。

也同意(5)。

我认为大部分设计要求在这一点上是明确的。

剩下的设计问题：

一、分配VIP还是允许IP变更？与此密切相关的是容器是否需要能够通过 Linux 发现自己的 IP，因为目前无法通过系统发现 VIP。我认为他们确实需要能够发现他们的 IP，但可以使用向下的 API，就像 pod IP (#12595)。由于 DNS TTL 和缓存“错误”，允许 IP 更改（由于使用 pod IP）意味着对 IP 更改率的限制。不过，在某些时候，我们还打算使 pod IP 可迁移（#3949），因此更改 IP 不会永远存在。

二、推（到豆荚）与拉（从豆荚）。服务和 RC 有意与 Pod 松散耦合，因此都使用“推送”模型。名义服务与 pod 身份的内在联系更紧密（尽管不是永久的——pod 必须是可替换的）。因此，我认为推动模型的动机较少。其他分配情况，例如调度，尤其是。独占绑定，例如对持久卷的持久卷声明，使用请求/确认模型，又名“拉”。这是目前我喜欢的名义服务模式。

有人对（我）有意见吗？

bgrant0607 于 2015-08-19

主选举是#1542，并且正在作为HA 实施的一部分进行讨论（例如，#12884）。

bgrant0607 于 2015-08-19

我不知道你说的推和拉是什么意思。

我已经重新阅读了这个问题的大部分内容，并且我确信没有一个
解决方案。我们将需要一系列功能来构建通往
这类应用程序。

我从一个公理开始，一旦一个 Pod 运行，你就不能真的
更改正在运行的 pod。对此有一些例外（例如虚拟
文件系统内容）但似乎很重要的事情（环境变量、IP、
主机名）你会陷入困境。

我也开始断言之间的松散耦合
服务和 Pod 保持不变，这使得我们谈论的这件事并不是真正的
服务。 Pod 并不真正知道它们面前的服务是什么。如果我们改变
那，它不再是一个服务。

我只是要做一个意识流，看看什么不臭。

想法 1：ThingPools 和补丁。

定义一个新的 API 对象或允许你定义一个池的东西
事物。什么是东西？一个事物是一个字符串（或者可能是一个 JSON blob），它
有一个枚举类型。您可以创建一个事物池和那些事物
供您使用。事物类型包括 VUID（主机名）、字符串、VIP。

定义一个新的 API 构造，它可以传递给创建操作 - 一个
修补。 Patch 是关于如何修补正在被处理的对象的说明。
创建。补丁选项之一是“从 ThingPool 分配”。

把这些放在一起：

定义一个 ThingPool { metadata.name: my-quorum-hostnames, type: VUID,
autogenerate: 5, } // 创建一个包含 5 个有效 VUID 的池

定义一个 RC { replicas: 5 ...}

在 RC 的创建 (POST) 中也发送一个 Patch: { what:
“podTemplate.spec.containers[*].metadata.VUID”，池：“my-quorum-hostnames”
}

POST 操作会将补丁应用到 RC - 分配一个 VUID
ThingPool 中的每个容器。每当 Pod 被杀死并重新创建时，
VUID 返回到池中，下一个要启动的 pod 将获取它。

您可以使用它来生成一个字符串池（“0”到“99”）并坚持
那些进入环境变量。您可以使用它来分配 VIP 池和
然后将这些 VIP 分配给 pod（将是一个新功能 - 持久的 pod
IPs - 不确定这将如何扩展 :) 您可以生成一个池
PersistentVolumeClaim 命名并修补每个 pod 使用的声明卷。

这个想法在很多方面都不完美，但我认为它最好地捕捉了
一组 Pod 的想法，而无需完全定义一组 Pod。

想法 2：定义一组 pod。不要假装这是一项服务。更近了
到博格工作。它就像一个 RC，但它为它的 Pod 分配序数
控制 - 分片编号。它控制 VUID 池（但我们不希望
主机名是用户可以设置的东西，嗯...）。

我以为我有更多的想法，但我没有。我在与抽象搏斗
和实现 - 定义我们不能的抽象毫无意义
实施。名义上的 VIP 听起来不错，但我认为这会推动
iptables 的限制。为一组 pod 提供一组稳定的主机名
好像是最重要的，一套储物一套
它尾巴上的豆荚很烫。

2015 年 8 月 18 日星期二晚上 7:28，Brian Grant通知@github.com
写道：

我同意 1a、1b 和 2a。 2b 听起来是一个不同的问题，虽然
也许解决方案可以重用相同的模式。
我认为规模 (3) 主要表明我们对一项服务和
每个实例的 RC 是不够的，尽管我同意两者之间的区别
云原生与非云原生
主选举（4）可以单独处理。
也同意(5)。
我认为大部分设计要求在这一点上是明确的。
剩下的设计问题：
一、分配VIP还是允许IP变更？与此密切相关的是
容器需要能够通过 Linux 或不能够发现自己的 IP，
因为目前无法通过系统发现 VIP。我假设他们这样做
需要能够发现他们的 IP，但可以使用向下的 API，如
带有 pod IP (#12595 https://github.com/kubernetes/kubernetes/pull/12595)。
允许 IP 更改（由于使用 pod IP）意味着对速率的限制
由于 DNS TTL 和缓存“错误”而导致的 IP 更改。在某个时候，我们
不过，也打算使 pod IP 可迁移（#3949
https://github.com/kubernetes/kubernetes/issues/3949），所以改变IP
不会永远。
二、推（到豆荚）与拉（从豆荚）。服务和 RC 是
故意松散耦合到 Pod，因此两者都使用“推”
模型。名义服务与 Pod 身份的内在联系更紧密
（虽然不是永久的——豆荚必须是可更换的）。因此，我看到
推动模型的动机较少。其他分配情况，例如
调度，尤其是。排他性绑定，例如持久性卷声明
持久卷，使用请求/确认模型，又名“拉”。那是目前
我喜欢名义服务的模型。
有人对（我）有意见吗？
—
直接回复此邮件或在 GitHub 上查看
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -132423385
.

thockin 于 2015-08-19

我可能不是你想的那样真正的主选举——更多的是
在构建需要初始化一组实例的功能时
（没有明确协调）只有认为它的实例
与其他 Pod 的“1”对话通常足以引导集群。一个
示例是 mongodb，您需要在其中启动副本集 - 如果是 pods
认为他们是“2”或“3”启动，你可以得到
发起分裂。但是“1”每次都可以安全地启动自己，然后
尝试添加其他成员（它们具有持久状态，可用于
确定它们是否已经是集群的一部分）。取决于
身份服务提供的保证，您实际上可能无法获得
成功的集群，但您不必在外部创建单独的 pod
初始化您的服务（尽管这也不可怕）。

2015 年 8 月 18 日星期二晚上 11:59，Brian Grant通知@github.com
写道：

Master选举是#1542
https://github.com/kubernetes/kubernetes/issues/1542 ，并且正在
作为 HA 实施的一部分进行讨论（例如，#12884
https://github.com/kubernetes/kubernetes/pull/12884）。
—
直接回复此邮件或在 GitHub 上查看
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -132439272
.

克莱顿科尔曼 | OpenShift 首席工程师

smarterclayton 于 2015-08-19

@smarterclayton这是名义服务问题的旁白，但按照您的描述进行引导并不安全。如果在新机器上重新启动“1”并且碰巧无法访问现有节点，那么它将重新引导，现在您有两个 mongodb 声称是权威的。您需要更改作业定义以在引导完成后移除引导功能。

anguslees 于 2015-08-19

正如@thockin可能暗示的那样，我认为我们在这里不必要地将几个相似但不同的功能混为一谈——而且我们在 k8s 级别包含了比严格必要的更多的功能。

我看到了上面描述的两个完全不同的用例——根据事实来源不同：

_Prescriptive:_ “我想要运行 N 个分片，如果有更多或更少，则进行更改以将其带回 N。”
_Descriptive:_ “我只想自动发现所有可用的碎片，让我在它们来来去去时以某种方式找出来。”

我认为这些是不同的，应该以不同的方式描述（尽管它们可能会为实际运行的 pod 提供类似的元数据）。

讨论还包括资源围栏和单一访问保证。 Afaics，这需要在 k8s 内完成的 _only_ 情况是挂载远程持久卷（因为 fs 挂载需要在容器外完成），如果底层远程卷服务没有，这很容易通过 etcd 锁完成t 已经在内部提供围栏。所有其他情况都可以由用户作业自己处理，使用分布式锁定服务（或访问内部提供锁定的服务）。要求作业执行自己的锁定会开启各种模式（固定分配、机会分配、“热备件”等）和不可达/恢复策略（硬故障、继续上次已知等）。

我建议将通用资源防护功能请求从这个 bug 中移出（我们只是通过提供在 k8s 上运行各种分布式锁定服务的方法来实现防护，而 k8s 本身不再参与）。

提醒一下：单个 VIP 后面有很多端口。我同意我们不想迁移 IP，因为这在大规模的底层网络上听起来很难，而且网络在故障/恢复边缘情况下处理临时重复项很尴尬。但是，我认为将唯一的服务端口分配给每个分片成员并将代理数据分配给每个 pod 实例是非常可行的 - 即使对于非常大的作业也是如此。（这个建议假设代理仍然是我们想要使用 k8s 的方向——我没有跟上最近关于这个领域的任何讨论）

anguslees 于 2015-08-19

通过推送，我的意思是另一种资源，如服务或控制器，将通过标签选择器监控 Pod 集并赋予它们“事物”（可解析的 DNS 名称、VIP、PVC）。

通过拉，我的意思是 pod 会明确请求分配一个“事物”，然后它会通过诸如 /binding 之类的东西绑定到它。

关于更改正在运行的 pod：创建后更改 pod 与更改具有运行容器的 pod 不同。调度程序执行异步。初始化，例如。 PodIP 分配也很晚。在#3585 中进行了更广泛的讨论。

关于这是否真的是“服务”：

需要在多组 pod 之间分配事物
事物（例如，DNS 名称）不得与 Pod 的资源名称本质上相关
一件事需要可以从一个 Pod 转移到另一个 Pod
Pod 需要“知道”（或能够通过向下的 API 找出）它被分配了什么东西（特别是 DNS 名称和 VIP）。
我们需要支持的一件事是可解析的 DNS
我们是否需要 VIP 是我的一个悬而未决的问题。我不使用 VIP 没问题。
这并不理想，但用户可以创建第二个无头服务，以通过 DNS 和/或端点进行对等发现。

想法（1），ThingPools + Patches 是一个有趣的想法。我将其描述为“拉”方法。 ThingPool 还不错，但我担心补丁很难使用，而且我不想从系统内部的补丁中对语义信息进行逆向工程，以在存储生命周期等方面提供可接受的行为。我d 更喜欢特定领域的东西。此外，用于 DNS 名称和 PVC 的独立 ThingPool 将不起作用，因为它们需要共同分配。

我将想法（2）描述为“推动”方法。我不想在 RC 和部署上重复工作，所以我们不应该引入另一个 pod 控制器。分配器可以，但比必要的松散耦合，并且与我们处理分配的先例不符。

回覆。将信息填充到环境变量中：这也适用于 Job。我想将信息填充到注释中并扩展向下的 API 以便能够请求特定的注释。我想继续允许用户只请求他们需要的信息并选择 env var 名称。

回覆。为每个实例分配不同的端口：这不适用于许多遗留应用程序，也不与我们的系统设计兼容。

回覆。规定：保持 N 运行是 ReplicationController 所做的。

回覆。描述性：这是已经存在的无头服务。

回覆。锁定：是的，这是正在进行的租用 API。

#6773 (push) 和 #12450 (pull) 中正在讨论存储配置。

现在已经太晚了，但我会以某种方式尝试在睡一觉后抽出时间提出建议。

bgrant0607 于 2015-08-19

快速观察：无头服务不分配VIP

我们可以将分配/分配与 DNS 发布分离。暂时忽略分配/分配是如何发生的，我们可以有一种特殊的无头服务，它从代表主机名的 pod 上的某个字段中获取名称。

bgrant0607 于 2015-08-19

并且，持久的本地存储问题是相关的：#7562、#1515、#598

bgrant0607 于 2015-08-19

更快速的更新，因为我主要做其他公关评论：

使用服务的一个优势是我们不需要保证为 pod 请求的主机名是全局唯一的，因为该服务会将发布到 DNS 的名称范围限定。

回覆。分配/分配：我想避免向 ReplicationController、Deployment、Daemon 等添加更多模板类型，并且我希望存储和名称能够像跨 Pod 一样轻松地跨控制器迁移（如果这是用户想要的）。

bgrant0607 于 2015-08-20

在2015年8月19日，在上午01点04分，安格斯酒糟[email protected]写道：

@smarterclayton https://github.com/smarterclayton这是一个旁白
名义上的服务问题，但像你这样引导并不安全
描述。如果“1”在新机器上重启，碰巧无法
到达现有节点，然后它将重新引导，现在您有两个
mongodb 声称是权威的。你需要换工作
删除引导后引导能力的定义是
完全的。

在这种情况下，您完全有可能会重叠 - 但在大多数情况下
我们正在讨论带锁的持久存储的情况，所以你会阻塞
无论如何，直到 gce/AWS 释放您的围栏并且您能够附加。所以
你牺牲了引导时的可用性，但不一定在运行时
（除非您在不受限制的存储中，在这种情况下我同意这不会是
安全的）

—
直接回复此邮件或在 GitHub 上查看
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -132448150
.

smarterclayton 于 2015-08-20

在2015年8月19日，1:35 AM，安格斯酒糟[email protected]写道：

正如@thockin https://github.com/thockin可能暗示的那样，我认为
我们在这里不必要地将几个相似但不同的功能混为一谈

并且我们在 k8s 级别包含了比严格必要的更多内容。

我看到上面描述的两个完全不同的用例 - 因来源而异
真相：

_Prescriptive:_ "我想要运行 N 个分片，如果有更多或更少
比那，然后进行更改以将其带回 N。”
_Descriptive:_ "我只想自动发现所有可用的分片，并且
当他们来来去去的时候，让我以某种方式找出来。”

我认为这些是不同的，应该以不同的方式描述（尽管

它们可能会为实际运行的 Pod 提供类似的元数据）。

讨论还包括资源围栏和单一访问
保证。 Afaics，_only_ 需要在 k8s 内完成的情况
(afaics) 正在安装远程卷 - 因为需要完成 fs 安装
容器外。所有其他情况都可以由用户作业处理
自己，使用分布式锁服务（或访问服务
提供内部锁定）。要求作业自行锁定打开
各种模式（固定分配，机会主义分配，“热
备件”等）和不可达/恢复策略（硬故障，
continue-with-last-known 等）。

我建议将一般资源围栏功能请求移出此
错误（我们只是通过提供运行的配方来实现围栏
k8s 上的各种分布式锁定服务，没有进一步的参与
k8s 本身）。

我不认为我们可以将目标分离来运行某些类型的
软件输出 - 设计说的是名义上的服务，但我们是用例
描述是重用身份和磁盘。我同意，击剑是一种财产
卷 - 但将卷的获取与特定的属性联系起来
pod 实例不是。

提醒一下：单个 VIP 后面有很多端口。我同意我们
不想迁移 IP，因为这在底层网络上听起来很难
大规模，并且网络难以处理临时重复项
在故障/恢复边缘情况下。不过，我认为_is_相当可行
为每个分片成员分配唯一的服务端口，并为每个分片成员分配代理数据
pod 实例 - 即使对于非常大的作业。（此建议假设
代理仍然是我们想要使用 k8s 的方向 - 我没有跟上
最近关于这个领域的任何讨论）

—
直接回复此邮件或在 GitHub 上查看
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -132451774
.

smarterclayton 于 2015-08-20

对@thockin的 ThingPool + Patches 想法略有改动：

模板：资源列表 + 参数和替换。请参阅https://github.com/openshift/origin/blob/master/pkg/template/api/types.go以获取灵感。参考编号 #503、#1743、#4210、#6487。

模板池。基本上是ThingPool。按需生成模板的密集索引实例，而不是按副本计数。

为了乐趣/一致性：v2 ReplicationController 可以复制任意模板，而不仅仅是 pod。参考 #170（有点）。如果所有分配都由 pod 复制驱动，则可能没有必要。

主要的替代方案是更特定于域的东西，专注于主机名和 PVC 池，但每个单独的池不起作用。单个池需要能够分配主机名和（可能是多个）PVC 的元组。 TemplatePool 的一个优点是有人可以使用它为每个副本分配一个服务（可能是外部的），自动化当前的 Zookeeper 解决方法。不知道是否还有其他资源，有人想用 Pod 进行类似的一对一复制，但考虑到我们 API 的增长速度，我敢打赌不会有。

bgrant0607 于 2015-08-20

@smarterclayton仅供参考，当您通过带有内嵌评论的电子邮件回复时，您的回复在 gmail 和 github 中都无法阅读。在 gmail 中，没有换行符，在 github 中没有引用前缀，因此您的回复很难与引用的文本分开。

bgrant0607 于 2015-08-20

是的，gmail + github + iPhones 有问题。

2015 年 8 月 20 日星期四下午 2:24，Brian Grant通知@github.com
写道：

@smarterclayton https://github.com/smarterclayton仅供参考
通过带有内嵌评论的电子邮件，您的回复是不可读的，无论是在
gmail 和 github 上。在 gmail 中，没有换行符，在 github 中有
没有引用前缀，所以除了
被引用的文本。
—
直接回复此邮件或在 GitHub 上查看
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -133108803
.

克莱顿科尔曼 | OpenShift 首席工程师

smarterclayton 于 2015-08-20

我们今天进行了快速聊天，有一些亮点：

谈了三类app：

无状态网络应用程序（仅适用于 RC）
使用外部母版并具有现有一致性的大型应用程序
协议（Cassandra、Infiniband）来处理共识
小型集群状态软件，如 Mongodb、rethinkdb、volt、etcd、
zookeeper, riak, redis 集群，需要一些模式才能正常工作
- 唯一身份（通常）
- 重复使用的每个实例的唯一持久卷（通常）
- 稳定的 IP 地址或 DNS 名称（通常）- DNS 名称通常是
  
  代表稳定的IP地址
- 稳定的主机名（很少）

今天，你可以通过拥有 N 来解决唯一标识和持久卷
复制控制器，具有 N 个服务的稳定 IP 地址。我们想
对于其中一些用例，不需要 N RC 和服务。

我们讨论了 Tim 和 Brian 的建议，没有特别的顺序：

TemplatePool 是有问题的，因为复制器需要有
在整个集群中创建对象的权限，并且必须知道
每个 api 端点所在的位置。
- 你可以有一个实例化模板端点，但仍然需要
  
  解决权限委托问题（使用服务帐户？）
- 定位对象和限制权限是长期的事情
我们讨论过的“pod 身份”又名 vuid 字段——争论已经成立
并且普遍同意它不需要是全球唯一的，只需要
在 pod 期望使用它的域中是唯一的。
- 假设的索引分配器（稀疏或密集）可以设置该值
  
  创建后，kubelet 可以等待启动 Pod，直到它们有一个
  
  身份（可能需要表明他们正在等待）
- 密集索引通常对简单的事情很有用，但因为这
  
  是创建后并与 kubelet 分离的，你可以有不同的
  
  分配算法的类型（密集数字，一致的哈希环，
  
  随机等）
Pod 上的简单模板似乎是一个不错的起点，但我们需要
使其与我们现有的工具链保持一致
彻底打破它
- 使用身份字段模板化其他字段
在 pod 规范上添加一个主机名字段，用户可以自行设置和
用身份参数化
允许无头服务响应端点的 dns 查询
身份（让端点控制器从 pod 中具体化身份
进入端点），保证一定的稳定性
以某种方式允许将持久卷声明参数化或更改为
从一个池中抽取（或有一个池控制器确保每个卷有一个
身份，或者让身份控制器从池中提取），需要考虑
需要可以轻松将环境/向下 api 转换为的工具
配置文件（正交，但应该更容易）
对格局仍有一些担忧

2015 年 8 月 20 日星期四下午 3:34，Clayton Coleman [email protected]
写道：

是的，gmail + github + iPhones 有问题。
2015 年 8 月 20 日星期四下午 2:24，Brian Grant通知@github.com
写道：
@smarterclayton https://github.com/smarterclayton仅供参考
通过带有内嵌评论的电子邮件，您的回复是不可读的，无论是在
gmail 和 github 上。在 gmail 中，没有换行符，在 github 中有
没有引用前缀，所以除了
被引用的文本。
—
直接回复此邮件或在 GitHub 上查看
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -133108803
.
克莱顿科尔曼 | OpenShift 首席工程师

克莱顿科尔曼 | OpenShift 首席工程师

smarterclayton 于 2015-08-20

另一个问题：名义服务成员的 TLS 证书

bgrant0607 于 2015-08-20

用于服务的 TLS 证书通常也是一件好事（签名
由集群 CA 根据请求自动执行）。

2015 年 8 月 20 日星期四下午 5:19，Brian Grant [email protected]写道：

另一个问题：名义服务成员的 TLS 证书
—
直接回复此邮件或在 GitHub 上查看。

克莱顿科尔曼 | OpenShift 首席工程师

smarterclayton 于 2015-08-20

是：#11725

bgrant0607 于 2015-08-21

回覆：

在 pod 规范上添加一个主机名字段，用户可以自行设置和
用身份参数化
允许无头服务响应端点的 dns 查询
身份（让端点控制器从 pod 中具体化身份
进入端点），保证一定的稳定性

我相信我们同意应该使用 pod 规范中设置的主机名来支持 dns（一旦我们添加了该功能，这些主机名可能会被它们的身份参数化），这样容器看到的主机名就可以被其他容器解析。

为了设置子域，我们必须明确或隐式地告诉 Pod 什么服务针对它。显式的缺点是它需要更多的配置胶水/模板。隐式的缺点是它容易受到系统中松散耦合的挑战：创建顺序竞争和不一致、一对一执行困难等。我倾向于显式。我们应该致力于改进交叉引用范围。

就像是：

Hostname string
Subdomain string

在 PodSpec 中的 HostNetwork 上方。

如果子域与正确类型的服务匹配，我们只会提供基于主机名的 DNS。我们也可以将两者合并为一个字段。

我认为我们应该为此重新调整问题 #4825 并让某人处理它。它比其他的要具体得多，工作量也少得多。

bgrant0607 于 2015-08-21

以某种方式允许将持久卷声明参数化或更改为
从一个池中抽取（或有一个池控制器确保每个卷有一个
身份，或者让身份控制器从池中提取），需要考虑

关于索赔的两件事我认为可以在这里提供帮助：

将绑定从 1:1 更改为 1:N
1. pvc.Spec.VolumeName 以 pvc.Spec.VolumeNames[] 作为绑定参考
pvc.Spec.Singelton 布尔值，表示是否应将声明绑定一次以进行共享或允许声明多次绑定。

RC 可以根据需要绑定到新卷。我想知道如何在活页夹中处理这个问题。

将正确的音量与正确的吊舱相匹配仍然很重要。

markturansky 于 2015-08-21

您必须有一个标识到卷名称的映射。

2015 年 8 月 21 日星期五下午 3:17，Mark Turansky通知@github.com
写道：

以某种方式允许将持久卷声明参数化或更改为
从一个池中抽取（或有一个池控制器确保每个卷有一个
身份，或者让身份控制器从池中提取），需要考虑
关于索赔的两件事我认为可以在这里提供帮助：
将绑定从 1:1 更改为 1:N

pvc.Spec.VolumeName 以 pvc.Spec.VolumeNames[] 作为绑定

参考

pvc.Spec.Singelton 布尔值，表示是否应绑定声明
只需一次共享或允许多次绑定声明。
RC 可以根据需要绑定到新卷。我想知道如何处理这个
在活页夹中。
将正确的音量与正确的吊舱相匹配仍然很重要。
—
直接回复此邮件或在 GitHub 上查看
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -133535336
.

克莱顿科尔曼 | OpenShift 首席工程师

smarterclayton 于 2015-08-21

2015 年 8 月 21 日星期五上午 12:56，Brian Grant [email protected]写道：

为了设置子域，我们必须告诉 pod 目标是什么服务，
显式或隐式。显式的缺点是它需要更多
配置胶水/模板。隐式的缺点是它会
容易面临系统中松散耦合的挑战：创建-
订单竞赛和不一致、一对一执法困难等。我倾向于
趋于明确。我们应该致力于改进交叉引用范围。

让我们明确一点 - 如果我们不设置子域，我们就不能让用户提供
他们自己的主机名。如果我们确实设置了子域，我们必须在一个
足够独特的方式（在 DNS 空间中，目前意味着跨
命名空间）。使子域成为服务的名称是
足够独特。

鉴于我们的 DNS（单个 TLD）的一些限制，这
实际上意味着我们给用户两个 DNS_LABEL 字段 - 主机名
和名义集。举个具体的例子：

pod.spec.metadata.name: my-pod-1bd3
pod.spec.metadata.namespace: my-app
pod.spec.identity.name: foo
pod.spec.identity.surname: bar

这将导致 pod 看到：

$ hostname
foo

$hostname -f
foo.bar.my-app.nom.cluster.local

和 DNS 为foo.bar.my-app.nom.cluster.local提供 A 和 PTR 记录

这比我们当前的 DNS 结构更深一层，但我认为
我们当前的 ndots=5 涵盖了这一点。或者，我们可以说一个
namespace 是姓氏，把它放回给用户分配唯一的
命名空间中的主机名。 DNS 结果将是
foo.my-app.pod.cluster.local反映了服务。我们甚至可以
通过向服务添加可选的主机名字段使它们更相似。

如果子域与以下内容匹配，我们只会提供基于主机名的 DNS
正确类型的服务。我们也可以将两者合并为一个字段。

我最不喜欢的部分是 Pod 声明“我是
服务“酒吧””（在上面的例子中）。在前面。先验。

滑坡一般为什么不允许这样呢？它会
简化一堆今天无法做出假设的事情（因为
松散耦合）即使在实践中我们很少看到单个 Pod
背后不止一项服务。如果每个 Pod 都低于零或一
服务，系统变得更简单了吗？

我认为我们应该为此重新调整问题 #4825 并让某人处理它。它比其他的要具体得多，工作量也少得多。

这当然是可以立即开始的事情，但是（对于那些
在家里跟着）它只是实现pod的机制
身份，而不是管理身份集的策略。

2015 年 8 月 21 日星期五下午 3:17，Mark Turansky通知@github.com 写道：

关于索赔的两件事我认为可以在这里提供帮助：
将绑定从 1:1 更改为 1:N

这是我开始的地方，但是......

2015 年 8 月 21 日星期五下午 12:38，克莱顿·科尔曼
通知@github.com写道：

您必须有一个标识到卷名称的映射。

是的。这实际上只是一个模板问题。
您是否将问题视为“pod 模板”，其中一些
字段具有由“替换元组”填充的占位符
在运行时从池中提取，或者您认为它是一个完全具体化的 pod
使用从池中提取的“替换元组”“修补”的规范
在运行时 - 它们是同构的，同样令人不快。

然而，我认为这是我们需要解决的更大问题之一。
我们应该开始为这些制定稻草人的建议吗？

thockin 于 2015-08-28

我们有几个 Pod 处于两三个服务之下的例子，一个用于
传播，一种用于暴露，一种用于测试暴露。

smarterclayton 于 2015-08-28

关于身份，守护进程控制器创建的每个 Pod 都应该分配一个身份，该身份源自节点身份和控制器身份。这可能是身份明显的情况（主机 y 上的 pod x 具有身份 f(y)）并且是守护进程的一部分责任。

smarterclayton 于 2015-09-11

@smarterclayton所以这里一个常见的（但不是普遍的）需要是维护一个稳定的、有序的组成员列表。当身份与 pod 恰好被安排在其上的节点相关联时，这将如何工作？

anguslees 于 2015-09-11

守护进程控制器 _only_ 在 pod 所在节点的上下文中具有标识
运行。复制控制器和服务是不同的。守护进程
控制器说“每个节点上都应该运行其中一个”。那里
除了它的节点之外，pod 没有其他身份。

2015 年 9 月 11 日星期五上午 1:13，Angus Lees [email protected]
写道：

@smarterclayton https://github.com/smarterclayton所以很常见（但不是
通用）这里需要维护一个稳定的、有序的组列表
成员。我认为这意味着身份应该_不_与
pod 恰好被调度到的节点。
—
直接回复此邮件或在 GitHub 上查看
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -139453809
.

克莱顿科尔曼 | OpenShift 首席工程师

smarterclayton 于 2015-09-11

@smarterclayton啊，这个问题显然已经演变成比最初的功能请求更重要的东西——我对这里试图构建的东西迷失了方向，所以我会退缩而不是继续增加噪音......

anguslees 于 2015-09-12

抱歉，并不是要暗示这点不相关。挑战在于我们需要定义集合并将其传播到 pod 中。我们需要 pod 对集合中的成员资格做出反应（安装与集合中的 pod 标识匹配的卷 X）。有一个悬而未决的问题 - 一个 pod 是否可以同时成为两个集合的成员并且在其中一个集合中具有唯一标识？

可能是由守护进程控制器运行的 Pod 具有“明显”的身份（守护进程控制器在一组节点上运行，RC 在一组 Pod 上运行）。

身份的一个要求是它在集合中是唯一的。我们能否利用 pod 名称和 pod 名称生成来确保唯一性？例如，RC 生成随机名称。 RC 能否根据它选择的 pod 集以确定性方式为 pod 生成名称？

考虑一个选择标签为 a=b 的 Pod 的 RC。为了计算要创建的下一个 Pod，它必须获取 Pod 并将它们减少到一个计数。如果我们将其简化为唯一的名称集，然后 RC 尝试遵循该集合中的名称生成模式会怎样？两个不重叠但将 pod 创建到服务标签中的 RC 将无法生成唯一名称（它们可能会为名称而斗争，但这是隐含的）。名称删除后可以重复使用

然后 pod 中的持久卷可以使用基于 pod 名称的 PVC。 pvc 池化器可以确保观察到的 RC 池有足够的声明。守护进程控制器可以选择节点名称确定的名称。我们还可以根据某种模式将 DNS 名称连接到服务中的 pod 名称。

这感觉比在 pod 上添加一个独特的标识字段更简洁。这意味着豆荚仍然不是宠物，但它们的名字可以是（这不是不合理的说法）。我们无法阻止同一 pod 进程的两个实例同时在集群上运行，但我们可以做出（并且确实）该名称今天仅在一个地方使用的硬保证。

smarterclayton 于 2015-09-12

上面的意思是“观察到的名称池”。端点 DNS 将是 hashpodname.ept.service.namespace.svc.cluster.local。我们已经在端点上有了 pod 名称，所以我们甚至不需要添加任何东西。

smarterclayton 于 2015-09-12

与https://github.com/kubernetes/contrib/tree/master/service-loadbalancer相关，它建议解决此问题作为可能的下一次迭代

jayunit100 于 2015-09-15

为什么我们在这里讨论 DaemonSet？这已由#12893，IMO 解决。

bgrant0607 于 2015-09-16

@smarterclayton让我们不要重新讨论从 pod 名称派生身份，也不要使用 RC 分配身份。此处讨论了这些方法的问题： https :

bgrant0607 于 2015-09-16

一种可能性是拥有一个 RC 选项，允许您根据需要以@smarterclayton描述的方式生成名称，并根据您设置选项的方式为您提供不同的功能集。因此，如果您启用该选项，那么使用“任务索引”方法难以实现的事情将不可用，但此处描述的功能将可用。相反，默认行为（禁用选项）将为您提供其他功能，但不会提供此处描述的功能。

似乎 Borg 任务索引抽象之类的东西的效用不断出现_对于某些用例_，我不清楚为什么我们不能提供它作为一个选项。

davidopp 于 2015-09-16

DaemonSet 我不认为解决分布式文件系统存储的情况
(Gluster) 每个主机都需要有一致的身份才能重新加入
集群。我会挖掘更多，但我认为它可能仍然需要一些东西
#260 的需求 - 我不知道如果你重新连接主机名是否足够
新实例上的主机磁盘。可能我没看懂什么是 DaemonSet
提供和#12893 交付，但我认为这不是问题
想要重用磁盘的系统主机。

2015 年 9 月 16 日星期三上午 12:22，Brian Grant通知@github.com
写道：

@smarterclayton https://github.com/smarterclayton让我们不要重访
从 pod 名称派生身份，也不使用 RC 分配身份。
此处讨论了这些方法的问题：#260（评论）
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -102107352
—
直接回复此邮件或在 GitHub 上查看
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140623023
.

克莱顿科尔曼 | OpenShift 首席工程师

smarterclayton 于 2015-09-16

作为一个具体的例子，想象一个 etcd 集群。它有 7 个实例，和 7 个
卷。我想要（为了论证），名称和卷 etcd-1
通过 etcd-7 和 etcd-pvc-1 到 etc-pvc-7。

滚动部署的 MaxUnavailable 为 90%（或等效值），MaxSurge 为 0%。它
缩小旧的 RC，并扩大新的 RC。优雅的旧RC
删除 etcd-5。它立即传递出有效的 RC 集。新的
RC 尝试创建 etcd-5（通过观察设置的间隙）。它收到一个
“已经存在异常”。它将其视为退避和重新排队。一次
etcd-5 真的消失了，它可以继续了。一旦 etcd-5 准备就绪，DC
移至下一步。

对于替代方案——在 pod 上设置身份——旧的 RC 被缩小。一个
使用新名称立即创建新 pod。新的吊舱无法启动
因为它需要设置身份来确定为其安装哪个 PVC
体积。它进入 Kubelet 上的等待循环。身份控制者
观察一些标签选择器集并观察到身份 etcd-5 不是
分配。它将身份 etcd-5 设置到新 pod 上。 kubelet 观察
更改然后可以确定要挂载哪个 PVC，启动 pod
（假设卷已与其他节点分离）。

在结构上，它们非常相似。后者允许开始重叠。
两者都需要映射 PVC。

2015 年 9 月 16 日星期三上午 12:39，Clayton Coleman [email protected]
写道：

DaemonSet 我不认为解决分布式文件系统存储的情况
(Gluster) 每个主机都需要有一致的身份才能重新加入
集群。我会挖掘更多，但我认为它可能仍然需要一些东西
#260 的需求 - 我不知道如果你重新连接主机名是否足够
新实例上的主机磁盘。可能我没看懂什么是 DaemonSet
提供和#12893 交付，但我认为这不是问题
想要重用磁盘的系统主机。
2015 年 9 月 16 日星期三上午 12:22，Brian Grant通知@github.com
写道：
@smarterclayton https://github.com/smarterclayton让我们不要重访
从 pod 名称派生身份，也不使用 RC 分配身份。
此处讨论了这些方法的问题：#260（评论）
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -102107352
—
直接回复此邮件或在 GitHub 上查看
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140623023
.
克莱顿科尔曼 | OpenShift 首席工程师

克莱顿科尔曼 | OpenShift 首席工程师

smarterclayton 于 2015-09-16

对我来说，使这个问题变得困难的事情不是生成稳定的唯一名称池或使用 PD 池。问题是同时进行。如果您将其扩展，为什么不能像这样汇集规范中的任何标识符？

据我所知（主要是二手的）打包索引的问题，我认为它们可能是宜居的（特别是如果我们按照大卫的建议去做，并使它们与其他功能相互排斥）。而且，我越炖它，我就越不讨厌某些白痴发布的补丁想法。

这个问题一直徘徊不去，恐怕我们已经陷入了分析瘫痪。

thockin 于 2015-09-16

我希望我们有更多其他池化用例的例子。我以为格鲁斯特
会有所不同，但它只是另一种变体
cassandra/etcd/mongo/zookeeper“我想重用一个卷，我需要
记得我之前说过我是谁”。我们还没有真正的基于角色的（我
想要制作前 N 个 pods 协调器和接下来的 M 个工人）示例
来杠杆。

2015 年 9 月 16 日星期三上午 12:46，Tim Hockin通知@ github.com
写道：

对我来说，使这个问题变得困难的事情不是产生稳定的
唯一的名称池或使用 PD 池。问题是同时做
同一时间。如果你把它扩展出来，为什么不能几乎任何
规范中的标识符会像这样合并吗？
据我所知（主要是二手的）打包索引的问题，我
认为它们可能是宜居的（特别是如果我们按照大卫的建议去做
它们与其他功能互斥）。而且，我越炖
它，我越不讨厌某些白痴发布的补丁想法。
这个问题缠绵缠绵怕是有分析了
麻痹。
—
直接回复此邮件或在 GitHub 上查看
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140625746
.

克莱顿科尔曼 | OpenShift 首席工程师

smarterclayton 于 2015-09-16

守护进程集：

12893 在使用主机网络时将 pod 主机名设置为节点的主机名，这对于 DaemonSet 使用是完全合理的，因为无论如何这些都会使用 hostPort。

此外，目的是将 DaemonSet 与节点控制器集成，以提供隐式无限宽恕#1574，并在为节点启用调度之前启用“调度”。隐式优先排序也可能是合理的。

对于集群存储系统，我可以想象在每个主机上配置额外的磁盘，这些磁盘只能由存储系统通过 hostPath 访问——它们不会被 Docker 或 emptyDir 使用。

bgrant0607 于 2015-09-16

关于身份，我看这里的提案没有问题： https :

bgrant0607 于 2015-09-16

这个问题一直存在，主要是由于缺乏足够的优先级，IMO。

bgrant0607 于 2015-09-16

对克莱顿进行即兴演奏（或者只是说同样的话，但更愚蠢）：

$ kubectl create -f -
kind: IdentityPool
apiVersion: v1
metadata:
  name: my-etcd-idents
  namespace: default
spec:
  identities:
    - etcd-0
    - etcd-1
    - etcd-2
^D

$ kubectl create -f -
kind: VolumePool
apiVersion: v1
metadata:
  name: my-etcd-volumes
  namespace: default
spec:
  volumes:
      - etcd-disk-0
      - etcd-disk-1
      - etcd-disk-2
^D

$ kubectl create -f -
kind: Replicationcontroller
apiVersion: v1
metadata:
  name: my-etcd-rc
  namespace: default
spec:
  selector:
    job: etcd
  identityPoolName: my-etcd-idents
  podTemplate:
    containers:
        - name: etcd
          image: coreos/etcd:2.0
          volumeMounts:
              - name: data
                path: /data
    volumes:
        - name: data
          identity:
              volumePoolName: my-etcd-volumes
^D

这意味着 RC（或其他东西）意识到这是一个身份集，从 identityPool 分配一个索引，将该身份分配给 pod 名称，然后向内窥视是否设置了任何其他以身份为中心的字段 - 身份在这种情况下的音量。

它不是完全通用的（您不能汇集任何随机字段）但我们可以根据需要添加更多识别身份的选项

thockin 于 2015-09-16

我有一种感觉，如果我们确定一个我们喜欢的规范，它可能会早日完成。

thockin 于 2015-09-16

即使编写规范也需要时间。

关于 IdentityPool/VolumePool，我们很久以前就已经决定多个池不起作用。

1.1 代码完成的截止日期是星期五。我们现在可以不这样做吗？

bgrant0607 于 2015-09-16

还相关：#170。这建议只拆分 pod 模板，但如果我们采用模板方案（我强烈喜欢而不是补丁），那么我们应该一起考虑它们。

bgrant0607 于 2015-09-16

我至少把设计放在 v1.2-candidate 上。

bgrant0607 于 2015-09-16

抱歉，我的草图中不清楚 - RC（或 IC？）有一个概念
主池或索引。一旦 pod 在 IC 中被分配了一个索引，那
index 用于索引所有以池为中心的字段。

如果我们将模板拆分出来，我假设假设 RC 不能
改变模板。那有点棘手。

这周我可以停止谈论这个了。它刚刚出现在我的
收件箱和我一直在咀嚼这个想法......

2015 年 9 月 15 日星期二晚上 10:09，Brian Grant通知@github.com
写道：

即使编写规范也需要时间。
关于IdentityPool/VolumePool，我们已经决定了很久
以前多个池不起作用。
1.1 代码完成的截止日期是星期五。我们现在可以不这样做吗？
—
直接回复此邮件或在 GitHub 上查看
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140627868
.

thockin 于 2015-09-16

是的，只有一些事情引发了我们的讨论。
客户问题等待没有发布过程。

2015 年 9 月 16 日星期三上午 1:14，Tim Hockin通知@ github.com
写道：

抱歉，我的草图中不清楚 - RC（或 IC？）有一个概念
主池或索引。一旦 pod 在 IC 中被分配了一个索引，那
index 用于索引所有以池为中心的字段。
如果我们将模板拆分出来，我假设假设 RC 不能
改变模板。那有点棘手。
这周我可以停止谈论这个了。它刚刚出现在我的
收件箱和我一直在咀嚼这个想法......
2015 年 9 月 15 日星期二晚上 10:09，Brian Grant通知@github.com
写道：
即使编写规范也需要时间。
关于IdentityPool/VolumePool，我们已经决定了很久
以前多个池不起作用。
1.1 代码完成的截止日期是星期五。我们能不能不要这样做
现在？
—
直接回复此邮件或在 GitHub 上查看
<
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140627868
.
—
直接回复此邮件或在 GitHub 上查看
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -140628241
.

克莱顿科尔曼 | OpenShift 首席工程师

smarterclayton 于 2015-09-16

讨论都是关于 IP 号和 Pod 的，但根据我对 Mongo 和 Zookeeper 的经验，IP Pod 应该保持无关（不要成为宠物）。持久性 _volume_ 需要一个名义数字，因为该卷记录了其他“卷”的 IP 号。无论挂载该卷的任何 Pod 都应该能够以某种方式使用该记录的 IP 号。音量是宠物...

我认为，一个 DNS 名称对于卷来说在时间上是恒定的并分配给挂载该卷的 Pod 会有很长的路要走。

在 Mongo 和 ZK 中更改集成成员将始终需要运行自定义代码，我希望大多数其他集成也是如此。所以复制控制器是错误的名字，这些宠物需要更多的会员船控制器。 Member Ship 控制器应该能够处理初始设置，然后对集成进行增量更改，最后将其关闭。

给定一个基于挂载卷的恒定 DNS 名称以及使用自定义代码处理整体成员的可能性，我认为应该可以处理这些类型的系统。

pkriens 于 2015-09-23

是的，pod IP 更像是一种短期黑客攻击。

这个提案的目标是高于 DNS 和容量的东西
可以利用保持耦合。关注的是定义 DNS 名称的卷
是我们已经建立的耦合的相反，我们也
想让 pod 规范的其他部分利用那个更高的概念
（身份）就像环境上的向下 API。这使得适应
更容易识别不同的集成软件（减少每个的自定义代码
类型）。

我们仍然需要确保除了合奏之外没有其他用例
在这里重叠（没有听到有人建议），然后尝试到达
感觉最小和合适的具体建议。蒂姆我认为有
最近总结了这里。

在2015年9月23日，11:33 AM，彼得柯瑞恩斯[email protected]写道：

讨论都是关于 IP 号码和 Pod，但根据我的经验
Mongo 和 Zookeeper Pod 应该保持无关的 IP（不要成为宠物）。
持久的 _volume_ 需要一个名义数字，因为这个卷记录
其他“卷”的 IP 号。挂载该卷的任何 Pod
应该能够以某种方式使用该记录的 IP 号码。体积是
宠物 ...

一个 DNS 名称，该名称在某个卷的时间上保持不变并分配给一个 Pod
我认为安装卷会有很长的路要走。

在 Mongo 和 ZK 中更改合奏成员将始终需要自定义
运行的代码，我希望它与大多数其他合奏相同。所以
复制控制器是错误的名字，这些宠物需要更多的成员
船舶管制员。成员船舶控制器应该能够处理
初始设置，然后对集成进行增量更改，最后
杀了它。

给定一个基于安装卷的恒定 DNS 名称以及
使用自定义代码处理整体成员应该可以
处理我认为的这些类型的系统。

—
直接回复此邮件或在 GitHub 上查看
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -142640825
.

smarterclayton 于 2015-09-23

/平

glerchundi 于 2015-10-05

您可以在https://hub.docker.com/r/elevy/zookeeper/找到使用现有功能在 Kubernetes 下设置 ZK 集群的示例

eliaslevy 于 2015-10-10

@smarterclayton @thockin

前几天骑车去办公室的想法：

我目前认为这是一个 PetSet 控制器，或者可能是 ShardSet 控制器，如果人们想这样想的话，正如开头所讨论的： https :

我们试图解决的情况是有 N 个相似的宠物，但它们仍然是宠物——它们不可替代。

我仍然认为将它绑定到 ReplicationController 是行不通的，部分原因是 ReplicationController 只有一个模板。 PetSet/ShardSet 需要是更高层次的抽象，更像是 Deployment 或 DaemonSet。 PetSet 可能会为每个实例生成一个 PodTemplate 对象。

我认为我们不能仅仅重用部署 API。除其他外，现在 kubectl 和 Deployment 中的滚动更新推出策略不适用于这种情况。大多数宠物可能想要重新创建更新，而任何想要滚动更新的宠物都无法处理超过其碎片数量的任何激增，并且会特别关注更新顺序。

尽管我喜欢这个想法，但我认为自下而上的身份分配不会奏效。太多的竞争条件将分配的身份返回到池中而不是分配新的身份。很像@erictune在探索将 RabbitMQ 与 Job 结合使用时遇到的问题。

我不想在多个地方表示 PetSet 的规模，例如在控制器和身份池中，或者在控制器和服务中，因为这会使扩展变得棘手/尴尬。

我认为我们不需要针对这种情况的通用模板。我们只需要删除具有相关存储和可预测、持久网络身份的 pod。粗略的等价物在 Borg 中已经足够了。因此，我强烈倾向于 #12450 的内容，但在 pod 模板中而不是在 pod 本身中。除了 podTemplate 之外，也许还有一个persistentVolumeClaimTemplates 数组。我不想为所有特定于云提供商的卷源添加花哨的替代品，尤其是因为我们无论如何都想弃用它们。向 PVC 添加额外的要求和/或选择器就足够了。我们还需要能够在某个时候以某种方式提供持久卷。

我们最终仍然需要对本地存储做一些事情，但我认为这是可以分离的。

然后上面提到的主机名和无头服务更改，这里：
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -133318903

bgrant0607 于 2015-11-06

现在正在制定提案，很快就会有草稿。

smarterclayton 于 2015-11-30

提案在https://github.com/kubernetes/kubernetes/pull/18016

smarterclayton 于 2015-12-01

...那么我们在哪里使用 PetSet？

我正在 Kubernetes 之上构建 HA 数据库解决方案。一些，特别是单主数据库，需要具有端点的服务，这些端点根据来自这些 pod 的事件映射到特定的 pod。例如：

服务“postgres”将循环映射到 ReplicaSet 中的所有 pod，但服务“postgres-master”仅映射到一个 pod。
主 Pod 死亡。
发生故障转移。作为故障转移的一部分，新的 master 通过 API 更新 Kube-master 以“抓取” postgres-master 服务。
当它这样做时，所有先前与 postgres-master 的连接都将终止。

jberkus 于 2016-05-03

@jberkus启用@ingvagabund将开始整理使用 PetSet 的示例，以查看哪些工作正常，哪些仍需要改进。如果您有一些想要组合和测试的特定用例，我建议您与他联系。

ncdc 于 2016-05-03

@ncdc在 v1.3 中是否已为此完成了所有工作？目前尚不清楚，因为该提案尚未合并，并且有一段时间没有其他 PR 引用此提案。

philips 于 2016-05-19

@bprashanth ^

ncdc 于 2016-05-19

我们正在登陆 e2es 并继续研究示例。它是在 alpha
现在，但该提案将进行第一轮 alpha 反馈
在合并之前。

2016 年 5 月 19 日上午 10:25，Brandon Philips通知@github.com
写道：

@ncdc https://github.com/ncdc在 v1.3 中是否已为此完成了所有工作？它是
不清楚，因为提案未合并，并且没有其他 PR
暂时参考这个。

—
你收到这个是因为你被提到了。
直接回复此邮件或在 GitHub 上查看
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -220340104

smarterclayton 于 2016-05-19

我在哪里可以找到这方面的文档？我想针对数据库故障转移用例对其进行测试。

jberkus 于 2016-05-19

👍2

啊哈，正是我们需要一个 postgres 专家:)

有关示例，请参见https://github.com/kubernetes/contrib/pull/921 ，我可以回答有关将 [db of choice] 原型化为 petset 的任何问题。我们在“apps/stateful”标签下有一堆草图（例如：https: //github.com/kubernetes/kubernetes/issues/23790，@philips一个 etcd 示例会很棒）。我还没有写文档，将在 1.3 的最后几周写（周五代码完成后还有 5 周时间发布）。

我猜你会尝试使用 postgres 自动进行故障转移，因为这很常见。我承认目前这仍然没有我希望的那么容易，您可能需要一个看门狗。 @jberkus我想听听关于哪些模式使这更容易的反馈。

为了让您快速回顾一下，今天的 petset 为您提供了与网络安装卷相匹配的一致网络标识（DNS、主机名），以及订购保证。因此，如果您使用replicas: 3创建一个 petset，您将获得：
管理服务：*.galear.default.svc.cluster.local
mysql-0 - 卷 0
mysql-1 - volume1：直到 0 运行并准备好才启动
mysql-2 - volume2：直到 0、1 运行准备好才开始

Pod 可以通过查找在管理服务下插入的 SRV 记录来使用 DNS 进行服务发现。这就是这个简单的 pod 的作用： https :

卷由动态供应商 (https://github.com/kubernetes/kubernetes/blob/release-1.2/examples/experimental/persistent-volume-provisioning/README.md) 供应，因此如果您没有在您的集群中运行但只想原型化，您可以简单地使用 emptyDir。 “数据引力” (https://github.com/kubernetes/kubernetes/issues/7562) 案例尚不适用，但最终会起作用。

bprashanth 于 2016-05-19

我要补充的是，目前通过 init 容器更容易提供带有对等列表的“启动时”通知。很明显，我们还需要“on-change”通知。当前要注意集群成员资格更改，您需要使用自定义 pid1。共享 pid 命名空间可能会使这更容易，因为您可以使用 sidecar，这也是需要工作的东西。

bprashanth 于 2016-05-19

我有一个看门狗，它是比我想要的更复杂的服务故障转移。测试一下，谢谢！

jberkus 于 2016-05-19

我还需要支持etcd，所以我以后可能会有很多测试。

jberkus 于 2016-05-19

@ncdc这个 alpha 代码的状态是什么？我想开始测试/实施。我们需要很快在这里部署一个 cassandra 集群。我可以用现有的代码库来做，但最好测试一下 petset 的东西。

paralin 于 2016-05-31

如果从 HEAD 构建，则可以获得它

bprashanth 于 2016-05-31

@bprashanth合并到主

paralin 于 2016-05-31

https://github.com/kubernetes/contrib/tree/master/pets

bprashanth 于 2016-05-31

在注释字符串中嵌入 yaml？哎呀，哎哟:(。不过，谢谢，会研究制作一个 cassandra 集。

paralin 于 2016-05-31

那是 json。这是添加到 GA 对象（Pod 中的初始化容器）的 alpha 功能。
@chrislovecnm正在研究 Cassandra，可能只是想等他出来。

bprashanth 于 2016-05-31

@paralin这就是我正在做的。现在没有时间记录并将其放入 k8s 存储库，但这是长期计划。 https://github.com/k8s-for-greeks/gpmr/tree/master/pet-race-devops/k8s/cassandra在 HEAD 本地为我工作。

演示中的最新 C* 图像运行良好。

我们确实有更多文档的问题。眨眼眨眼，敲击@bprashanth

chrislovecnm 于 2016-05-31

带有 etcd 集群的 PetSet 示例 [1]。

[1] https://github.com/kubernetes/contrib/pull/1295

ingvagabund 于 2016-06-30

完成审查后，请务必在提案文档中记录设计问题

在2016年6月30日，1:25 AM，扬查卢普卡[email protected]写道：

带有 etcd 集群的 PetSet 示例 [1]。

[1] kubernetes/contrib#1295
https://github.com/kubernetes/contrib/pull/1295

—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/kubernetes/kubernetes/issues/260#issuecomment -229594658，
或静音线程
https://github.com/notifications/unsubscribe/ABG_pwVgiaLvRKbtcJG9wzMEZcCNgae8ks5qQ32PgaJpZM4CIC6g
.

smarterclayton 于 2016-06-30

petset 文档是https://github.com/kubernetes/kubernetes.github.io/blob/release-1.3/docs/user-guide/petset.md和https://github.com/kubernetes/kubernetes.github。 io/tree/release-1.3/docs/user-guide/petset/bootstrapping ，我计划关闭这个问题并打开一个新的问题，解决将 petset 移至 beta 的问题，除非有人反对

bprashanth 于 2016-07-07

https://github.com/kubernetes/kubernetes/issues/28718

bprashanth 于 2016-07-09

Kubernetes: PetSet（是名义服务）

最有用的评论

所有160条评论

直接回复此邮件或在 GitHub 上查看
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57663926
.

直接回复此邮件或在 GitHub 上查看
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57749083
.

直接回复此邮件或在 GitHub 上查看
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57750769
.

6393）。

克莱顿科尔曼 | OpenShift 首席工程师

它们可能会为实际运行的 Pod 提供类似的元数据）。

克莱顿科尔曼 | OpenShift 首席工程师

克莱顿科尔曼 | OpenShift 首席工程师

克莱顿科尔曼 | OpenShift 首席工程师

克莱顿科尔曼 | OpenShift 首席工程师

克莱顿科尔曼 | OpenShift 首席工程师

克莱顿科尔曼 | OpenShift 首席工程师

克莱顿科尔曼 | OpenShift 首席工程师

克莱顿科尔曼 | OpenShift 首席工程师

克莱顿科尔曼 | OpenShift 首席工程师

克莱顿科尔曼 | OpenShift 首席工程师

12893 在使用主机网络时将 pod 主机名设置为节点的主机名，这对于 DaemonSet 使用是完全合理的，因为无论如何这些都会使用 hostPort。

克莱顿科尔曼 | OpenShift 首席工程师

相关问题

Kubernetes: PetSet（是名义服务）

最有用的评论

所有160条评论

直接回复此邮件或在 GitHub 上查看 https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57663926 .

直接回复此邮件或在 GitHub 上查看 https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57749083 .

直接回复此邮件或在 GitHub 上查看 https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57750769 .

6393）。

克莱顿科尔曼 | OpenShift 首席工程师

它们可能会为实际运行的 Pod 提供类似的元数据）。

克莱顿科尔曼 | OpenShift 首席工程师

克莱顿科尔曼 | OpenShift 首席工程师

克莱顿科尔曼 | OpenShift 首席工程师

克莱顿科尔曼 | OpenShift 首席工程师

克莱顿科尔曼 | OpenShift 首席工程师

克莱顿科尔曼 | OpenShift 首席工程师

克莱顿科尔曼 | OpenShift 首席工程师

克莱顿科尔曼 | OpenShift 首席工程师

克莱顿科尔曼 | OpenShift 首席工程师

克莱顿科尔曼 | OpenShift 首席工程师

12893 在使用主机网络时将 pod 主机名设置为节点的主机名，这对于 DaemonSet 使用是完全合理的，因为无论如何这些都会使用 hostPort。

克莱顿科尔曼 | OpenShift 首席工程师

相关问题

直接回复此邮件或在 GitHub 上查看
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57663926
.

直接回复此邮件或在 GitHub 上查看
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57749083
.

直接回复此邮件或在 GitHub 上查看
https://github.com/GoogleCloudPlatform/kubernetes/issues/260#issuecomment -57750769
.