k8s - ReplicaSet matchLabel 选择器的意义

Question

假设deployment，replicaSet和pod都是1:1:1的映射。

deployment ==> replicaSet ==> Pod

当我们进行部署时，replicaSet 将pod-template-hash 标签添加到 pod。因此，这看起来足以让副本集检查是否有足够的 pod 正在运行。那么replicaSetmatchLabels选择器有什么意义呢？为什么是强制性的？

解释以便更好地理解

例如：我部署了一个带有这些标签的应用程序。 2 个 pod 正在运行

spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx-app

现在将其中一个 pod 的 pod-template-hash 的标签值更改为其他值（此处更改为 testing）。现在我们立即看到另一个 pod 启动了。所以replicaSet似乎并不关心selector.matchLabels

NAME                            READY   STATUS    RESTARTS   AGE   LABELS
pod/nginx-app-b8b875889-cpnnr   1/1     Running   0          53s   app=nginx-app,pod-template-hash=testing
pod/nginx-app-b8b875889-jlk6m   1/1     Running   0          53s   app=nginx-app,pod-template-hash=b8b875889
pod/nginx-app-b8b875889-xblqr   1/1     Running   0          11s   app=nginx-app,pod-template-hash=b8b875889

NAME                 TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE    LABELS
service/kubernetes   ClusterIP   10.96.0.1    <none>        443/TCP   151d   component=apiserver,provider=kubernetes

NAME                        READY   UP-TO-DATE   AVAILABLE   AGE   LABELS
deployment.apps/nginx-app   2/2     2            2           53s   app=nginx-app

NAME                                  DESIRED   CURRENT   READY   AGE   LABELS
replicaset.apps/nginx-app-b8b875889   2         2         2       53s   app=nginx-app,pod-template-hash=b8b875889

Answer 1

让我总结一下。整个讨论是关于：为什么部署迫使我设置 matchLabels 选择器，即使没有它也可以轻松生存，因为它添加了 pod-template-hash 并且只使用它就可以了。

在阅读了所有 cmets 和所有讨论后，我决定查看 kubernetes 文档。

我将允许自己引用关于副本集的 k8s 文档：How a ReplicaSet works

ReplicaSet 的工作原理：

[...]

ReplicaSet 通过 Pod 链接到它的 Pod metadata.ownerReferences 字段，它指定什么资源 当前对象的拥有者。 ReplicaSet 获取的所有 Pod 都有 他们在他们的内部拥有 ReplicaSet 的识别信息 所有者参考字段。正是通过这个链接，ReplicaSet 知道它正在维护和计划的 Pod 的状态 相应地。

这是否意味着它根本不使用标签？嗯，不完全是。让我们继续阅读：

ReplicaSet 使用其选择器标识要获取的新 Pod。如果 有一个 Pod 没有 OwnerReference 或者 OwnerReference 不是 一个 Controller 并且它匹配一个 ReplicaSet 的选择器，它将是 立即被所述ReplicaSet获取

哦，看来它只是将选择器用作第一种方法的替代方法。

让我们继续阅读。这是Pod Selector部分的引述：

Pod 选择器

.spec.selector 字段是一个标签选择器。作为 前面讨论过这些是用于识别潜在 Pod 的标签 获取

看起来这些标签并没有用作跟踪 ReplicaSet 拥有的 pod 的主要方法，它们用于“识别要获取的潜在 Pod”。但这是什么意思？

为什么 ReplicaSet 会获取它不拥有的 pod？文档中有一个部分试图回答这个问题：Non-Template Pod acquisition

非模板 Pod 收购

虽然您可以毫无问题地创建裸 Pod，但它非常强大 建议确保裸豆荚没有标签 匹配您的副本集之一的选择器。这样做的原因是 因为 ReplicaSet 不限于拥有其指定的 Pod template-- 可以按照模板中指定的方式获取其他 Pod 前几节。

[...]

因为这些 Pod 没有控制器（或任何对象）作为它们的所有者 引用并匹配 [...] ReplicaSet 的选择器，它们将 立即被它收购。

很好，但这仍然不能回答问题：为什么我需要提供选择器？它不能只使用那个哈希吗？

过去当 k8s 出现 bug 时： https://github.com/kubernetes/kubernetes/issues/23170 所以有人建议需要验证：https://github.com/kubernetes/kubernetes/issues/23218 于是验证出现了： https://github.com/kubernetes/kubernetes/pull/23530

它一直伴随着我们直到今天，即使今天我们可能没有它也可以生活。

虽然我认为它在那里更好，因为它最大限度地减少了在不同 RS 的 pod-template-hash 冲突的情况下重叠标签的机会。

Answer 2

我们使用 pod-label "AND" pod-template-hash 作为 Selector 的一个用例可能是在更新/回滚等期间处理副本集。

例如：-

在您的场景中，副本集当前使用 Selector app=nginx-app,pod-template-hash=b8b875889。 考虑部署正在更新到更高版本的 nginx 映像，作为升级的一部分，它会在后台创建一个新的副本集，该副本集使用相同的选择器但具有新的 pod-template-hash，这意味着新副本集的选择器将是“应用程序 = nginx 应用程序，pod 模板哈希 = XXXXXXX”。作为升级的一部分，旧副本集中的 pod 将被终止，新的 pod 将在新副本集中创建。由于 pod 标签 (app=nginx-app) 对于这两个副本集都是通用的，为了有效和独立地管理它们，我们需要使用另一个对这些副本集唯一的选择器。这是通过使用 pod-template-hash 和 pod-label 作为选择器来实现的。