如果我给 pod 一些特定的标签并定义副本集以包含具有相同标签的 pod，它会将那个 pod 包含在其中。这一切都很好..
（我知道 pod 不是单独创建的，而是应该使用部署或副本集创建的。但部署/副本集仍然如何包含标签匹配定义中的 pod，如果它们出于某种原因已经存在）
但是，这在幕后是如何工作的？副本集如何知道要包含该 pod，因为它具有相同的标签？比方说，我已经有一个带有这些标签的 pod，如果新创建的副本集的 pod 少于所需的 pod 数量，它如何知道要包含该 pod？
它是否从 etcd 获得这些信息？或者豆荚以某种方式暴露标签？这件事在幕后是如何运作的？
【问题讨论】：
标签： kubernetes
如 Kubernetes 文档中关于 ReplicaSet 所述。
ReplicaSet 由字段定义，包括指定如何识别可以获取的 Pod 的选择器、指示它应该维护多少个 Pod 的副本数以及指定它应该创建的新 Pod 的数据的 Pod 模板。满足副本数标准。然后，ReplicaSet 通过根据需要创建和删除 Pod 以达到所需数量来实现其目的。当一个 ReplicaSet 需要创建新的 Pod 时，它会使用它的 Pod 模板。
建议使用Deployments 而不是ReplicaSets。
Deployment是一个对象，它可以拥有 ReplicaSet 并通过声明性的服务器端滚动更新来更新它们及其 Pod。虽然 ReplicaSet 可以独立使用，但如今它们主要被 Deployments 用作协调 Pod 创建、删除和更新的机制。当您使用部署时，您不必担心管理它们创建的 ReplicaSet。部署拥有并管理它们的 ReplicaSet。因此，建议您在需要 ReplicaSet 时使用 Deployment。
就像你提到的，如果你有一个标签与ReplicaSet 标签匹配的Pod，ReplicaSet 将控制 pod。如果您使用 3 个副本部署 ReplicaSet 并且在此之前部署了 Pod，则 RS 将仅生成 2 个具有匹配标签的 Pods。在Non-Template Pod acquisitions上有详细说明和示例。
至于它是如何在幕后工作的，你可以看看幻灯片 #47-56 of Kubernetes Architecture - beyond a black box - Part 1
【讨论】：