kubernetes - kubernetes 部署 pod 选择器的目的是什么？

Question

我不明白为什么 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:
      ...

Answer 1

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

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

您实际上不必隐式定义 .spec.selector使用 v1beta1 时扩展名。在这种情况下，它会默认为 .spec.template.labels .但是，如果不这样做，您可能会遇到 kubectl apply 的问题。一旦用于选择的一个或多个标签更改，因为 kubeclt 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 ，该字段将是强制性的。我希望这种回答你的问题，我没有让它变得更加困惑;)