kubernetes部署吊舱选择器的用途是什么？

我不明白为什么kubernetes在只能包含一个pod模板的部署语句中需要一个pod选择器？请随意告诉我为什么kubernetes工程师在部署定义中引入了选择器语句，而不是从模板中自动选择pod

---
apiVersion: v1
kind: Service
metadata:
  name: grpc-service

spec:
  type: LoadBalancer
  ports:
  - name: grpc
    port: 8080
    targetPort: 8080
    protocol: TCP
  selector:
    app: grpc-test

---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: grpc-deployment

spec:
  replicas: 1
  revisionHistoryLimit: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0

  selector:
    matchLabels:
      app: grpc-test

  template:
    metadata:
      labels:
        app: grpc-test

    spec:
      containers:
      ...

为什么不简单地定义这样的东西呢

---
apiVersion: v1
kind: Service
metadata:
  name: grpc-service

spec:
  type: LoadBalancer
  ports:
  - name: grpc
    port: 8080
    targetPort: 8080
    protocol: TCP
  selector:
    app: grpc-test

---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: grpc-deployment

spec:
  replicas: 1
  revisionHistoryLimit: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 0

  template:
    metadata:
      labels:
        app: grpc-test

    spec:
      containers:
      ...

---

据我所知，部署中的选择器是一个可选属性

模板是规范的唯一必填字段

---

因此，您不需要在部署中使用标签选择器，在您的示例中，我不明白您为什么不能使用后一部分？

啊！有趣的是，我以前也曾尝试过围绕标签选择器的概念进行思考。所以，它来了

首先，这些标签到底是用来干什么的？kubernetes中的标签是识别对象的核心手段。控制器根据吊舱的标签而不是名称来控制吊舱。在这种特殊情况下，它们用于识别属于部署副本集的POD

使用

v1beta1

扩展时，实际上不必隐式定义

.spec.selector

。在这种情况下，它将默认为

.spec.template.labels

。但是，如果你不这样做，一旦用于选择更改的一个或多个标签出现问题，

kubectl apply

，您就会遇到问题，因为在比较更改时，

kubectl apply

将查看

kubectl.kubernetes.io/last applied configuration

，并且该注释仅在用户创建资源时包含用户输入，而不包含任何内容默认字段的名称。您将得到一个错误，因为它无法计算差异，如：

spec.template.metadata.labels: Invalid value: {"app":"nginx"}: `selector` does not match template `labels`

如您所见，这是一个相当大的缺点，因为这意味着您无法更改任何用作选择器标签的标签，否则将完全中断部署流程。在

apps/v1beta2

中，它被“修复”，要求明确定义选择器，不允许在这些字段上发生突变

因此，在您的示例中，您实际上不必定义它们！创建工作正常，默认情况下将使用

.spec.template.labels

。但是，是的，在不久的将来，当您必须使用

v1beta2

时，该字段将是必需的。我希望这类问题能回答你的问题，我没有让它变得更混乱；）

但是，如果你不这样做，一旦用于选择更改的一个或多个标签出现问题，kubectl apply就会出现问题，因为kubectl apply在比较更改时会查看kubectl.kubernetes.io/last-applied-configuration，并且该注释只包含用户在创建资源时的输入，而不包含任何默认字段

引用图恩的回答

---

我的解释是，这在逻辑上根本没有必要。只是由于Kubernetes当前实现的局限性，它有一些奇怪的“行为”，因为它用于“比较”两个部署/对象的功能没有考虑“默认值”

通过谷歌来到这里，我觉得这个答案并不令人满意。我完全可以理解将标签用于服务、节点选择器等的动机。但是，Kubernetes规定pod模板本身必须与选择器匹配，因此它只能比指定的标签更松散。然而，这种自由是没有价值的，因为它还规定命名空间中的部署选择器不得重叠。因此，实际的问题是：为什么甚至可以自由指定选择器，而不强制使用自动生成的pod标签和选择器，例如

拥有部署=

？问题是选择器标签的用途是什么，以及为什么在部署规范中要求它。我相信我回答了这个问题。关于你的问题，标签选择器并不是为了提供唯一性，这就是UID的用途。它们仅提供对对象进行分组的方法。这些物体不一定非得是独一无二的。但是是的，在这种情况下，让它可配置并对人为错误开放确实没有多大意义，因为您不希望您的部署控制比您的规范中的POD更多的POD。@ToonLamberigts您可以提供一些到kubernetes官方文档的链接，其中明确说明哪些API必须使用matchLabels选择器吗“为什么？”奥利弗，你可能想再读一遍我的答案。他们强制使用选择器字段来禁止对其进行变异。@user2896438，部署实际上并没有直接管理其pod，这可能会让我的解释感到困惑。部署创建复制集，其目的是维护所述部署的“副本集”。ReplicaSet拥有的每个pod都将获得唯一的“metadata.ownerReferences”字段，其中包含该ReplicaSet的ID。这里有趣的是，当有一个pod实际上与RS的选择器标签匹配，而没有有效的ownerReferences字段时，RS将假定该pod是其集合的一部分。所以理论上你可以用它；）这适用于扩展/v1beta1部署，但不适用于应用/v1部署。显然，在v1beta2中，OP的问题中也需要。如果template.metadata定义了2个标签，那么我们应该在选择器中定义所有标签吗？规格：副本：1模板：元数据：标签：app:foo-bar弹性实例：foo