Kubernetes非特异性spec.selector不能阻止Kubernetes正确工作

Question

当我和库伯内特斯在一起的时候，我经历了一种令人惊讶的行为，我想知道这背后是否有什么好的解释。

我已经注意到，当使用相同的标签和相同的spec.selector创建两个Kubernetes部署时，部署仍然正确工作，尽管使用相同的选择器“应该”会使它们对与每个库相关的豆荚感到困惑。

示例配置，它提供了-

example_deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
    extra_label: one
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

example_deployment_2.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment-2
  labels:
    app: nginx
    extra_label: two
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

我希望这些部署不能正常工作，因为他们会从对方中选择豆荚，并假设这是他们的。实际结果是，部署似乎是正确创建的，但是从k9s输入部署将返回所有的吊舱。这两种部署都是如此。

有人能解释一下为什么会发生这种事吗？在Kubernetes中是否有额外的内部过滤，以防止部署没有真正创建的豆荚与之关联？

我将注意到，我在AWS中看到了这种行为，并在Minikube中复制了它。

Answer 1

当您创建一个K8S部署时，K8S创建一个ReplicaSet来管理豆荚，然后这个ReplicaSet根据hpa提供或修补的副本的数量来创建豆荚。除了您提供的标签和注释之外，ReplicaSet添加了包含其名称和uid的ownerReferences，因此即使您有4个具有相同标签的荚，每个ownerReferences也将有一个ReplicaSet用来管理它们的不同ownerReferences：

apiVersion: v1
kind: Pod
metadata:
  ownerReferences:
  - apiVersion: apps/v1
    blockOwnerDeletion: true
    controller: true
    kind: ReplicaSet
    name: <replicaset name>
    uid: <replicaset uid>
...