k8s - ReplicaSet matchLabel选择器的意义

Question

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

deployment ==> replicaSet ==> Pod

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

为了更好地理解

我部署了一个带有这些标签的应用程序。两个吊舱在运行

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

现在，将pods散列的标签值更改为其中一个荚的其他值(此处更改为testing )。现在我们立刻看到另一个吊舱开始了。所以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选择器，尽管它可以很容易地生活没有它，因为它添加了荚-模板散列，而且它将完全可以只使用它。

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

我将引用关于复制集的k8s文档：ReplicaSet是如何工作的

ReplicaSet是如何工作的： ..。 A ReplicaSet通过Pods的 metadata.ownerReferences字段链接到其Pods，该字段指定当前对象所属的资源。ReplicaSet获得的所有Pods都在其ownerReferences字段中拥有ReplicaSet的标识信息。正是通过这个链接，ReplicaSet知道了它正在维护的Pods的状态，并相应地进行了计划。

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

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

Ouh，所以看起来它只使用选择器作为第一种方法的替代。

我们继续读书吧。以下是荚式选择器部分的引文：

荚式选择器 .spec.selector字段是一个标签选择器。正如前面讨论过的，是用来识别潜在的Pods 以获取的标签。

这些标签似乎不是用来跟踪ReplicaSet拥有的pod的主要方法，而是用来“识别需要获取的潜在Pods”。但这意味着什么呢？

为什么ReplicaSet要收购它不拥有的豆荚呢？文档中有一节试图回答这个问题：非模板Pod捕获

非模板Pod采购 虽然您可以无问题地创建裸Pods，但强烈建议确保裸Pods没有与您的ReplicaSets之一的选择器匹配的标签。之所以这样做，是因为ReplicaSet不限于拥有它的模板指定的Pods --它可以以前面章节中指定的方式获得其他Pods。 ..。 由于这些Pods没有控制器(或任何对象)作为它们的所有者引用并匹配.ReplicaSet，他们马上就会被它收购。

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

回到过去，当k8s：https://github.com/kubernetes/kubernetes/issues/23170中有一个bug时，有人建议需要验证：https://github.com/kubernetes/kubernetes/issues/23218和所以验证出现了：https://github.com/kubernetes/kubernetes/pull/23530

它一直陪伴着我们直到今天，即使今天我们可能没有它也能活下去。

虽然我认为它在那里更好，因为它最大限度地减少了标签重叠的可能性，以防不同的RSs发生结荚-模板-散列冲突。

Answer 2

一个用例，为什么我们使用荚标签“和”荚-模板-散列作为选择器，可能是在更新/回滚等过程中处理副本。

例：-

在您的场景中，复制集当前使用Selector =nginx、pod散列=b8b875889。考虑到部署正在更新为nginx映像的更高版本，作为升级的一部分，它在后台创建一个新的副本集，该副本集使用相同的选择器，但使用新的pod-template-散列，这意味着新副本集的选择器将是"app=nginx-app，pod-template-散列=XXXXXXXX“。作为升级的一部分，旧副本集中的豆荚将被终止，新副本集中将创建新的荚。由于pod标签(app=nginx)对这两个副本集都很常见，为了有效和独立地管理它们，我们需要使用另一个选择器，这对于这些副本集来说是独一无二的。这是通过使用荚模板散列和荚标签作为选择器来实现的。