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中的标签是识别物体的核心手段.控制器根据标签而不是名称控制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,这个领域将是强制性的.我希望这样的答案可以回答你的问题而且我没有让它更加混乱;)

Answer 2

\n

但是，如果您不这样做\xe2\x80\x99t，一旦用于选择更改的一个或多个标签被 kubectl apply 时，您可能会遇到问题，因为 kubectl apply 将查看 kubectl.kubernetes.io/last-applied-configuration比较更改时，该注释将仅包含用户创建资源时的输入，而不包含任何默认字段。

\n

\n\n

引用Toon的回答。

\n\n

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

\n