kubernetes - k8s - ReplicaSet matchLabel 选择器的意义

Question

假设部署，replicaSet 和 pod 都是 1:1:1 映射。

deployment ==> replicaSet ==> Pod

当我们进行部署时，replicaSet 增加了 pod-template-hash标签到 pod 。所以，这看起来足以让一个 replicaSet 检查是否有足够的 pod 正在运行。那么replicaSet matchLabels的意义何在？选择器？为什么是强制性的？
解释以便更好地理解
例如:我使用这些标签部署了一个应用程序。 2 个 Pod 正在运行

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

现在将 pod-template-hash 的标签值更改为其中一个 pod 的其他值(此处更改为 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 并且仅使用它就完全没问题。
在阅读了所有评论和所有讨论后，我决定查看 kubernetes 文档。
我将允许自己引用有关副本集的 k8s 文档:How a ReplicaSet works

How a ReplicaSet works:

[...]

A ReplicaSet is linked to its Pods via the Pods'metadata.ownerReferences field, which specifies what resource thecurrent object is owned by. All Pods acquired by a ReplicaSet havetheir owning ReplicaSet's identifying information within theirownerReferences field. It's through this link that the ReplicaSetknows of the state of the Pods it is maintaining and plansaccordingly.

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

A ReplicaSet identifies new Pods to acquire by using its selector. Ifthere is a Pod that has no OwnerReference or the OwnerReference is nota Controller and it matches a ReplicaSet's selector, it will beimmediately acquired by said ReplicaSet

哦，所以看起来它只是将选择器用作第一种方法的替代方法。
让我们继续阅读。这里引用自 Pod Selector部分:

Pod Selector

The .spec.selector field is a label selector. Asdiscussed earlier these are the labels used to identify potential Podsto acquire

看起来这些标签不是用来跟踪 ReplicaSet 拥有的 Pod 的主要方法，它们用于“识别要获取的潜在 Pod”。但是这是什么意思？
为什么 ReplicaSet 会获取它不拥有的 Pod？文档中有一个部分试图回答这个问题: Non-Template Pod acquisition

Non-Template Pod acquisitions

While you can create bare Pods with no problems, it is stronglyrecommended to make sure that the bare Pods do not have labels whichmatch the selector of one of your ReplicaSets. The reason for this isbecause a ReplicaSet is not limited to owning Pods specified by itstemplate-- it can acquire other Pods in the manner specified in theprevious sections.

[...]

As those Pods do not have a Controller (or any object) as their ownerreference and match the selector of the [...] ReplicaSet, they willimmediately be acquired by it.

很好，但这仍然没有回答这个问题:为什么我需要提供选择器？它不能只使用那个哈希吗？
回到过去，当 k8s 出现错误时:
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 冲突的情况下重叠标签的机会。