kubernetes部署容器选择器的目的是什么? [英] What is the purpose of a kubernetes deployment pod selector?

问题描述

我看不到为什么kubernetes在只能包含一个Pod模板的部署语句中需要Pod选择器?随意教我为什么kubernetes工程师为什么会在部署定义中引入选择器语句，而不是自动从模板中选择pod?

I fail to see why kubernetes need a pod selector in a deployment statement that can only contain one pod template? Feel free to educate me why kubernetes engineers introduced a selector statement inside a deployment definition instead of automatically select the pod from the template?

---
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:
      ...

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

Why not simply define something like this?

---
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:
      ...

推荐答案

啊！有趣的是，我曾经尝试过绕过标签选择器的概念.所以，就在这里...

Ah! Funny enough, I have once tried wrapping my head around the concept of label selectors as well before. So, here it goes...

首先，这些标签的用途是什么? kubernetes中的标签是识别对象的核心手段.控制器根据吊舱的标签而不是其名称来控制吊舱.例如，在这种特定情况下，它们旨在标识属于部署副本集的Pod.

First of all, what the hell are these labels used for? Labels within kubernetes are the core means of identifying objects. A controller controls pods based on their label instead of their name. In this particular case they are for example meant to identify the pods belonging to the deployment’s replica set.

使用v1beta1扩展名时，您实际上不必隐式定义.spec.selector.在这种情况下，它将默认为.spec.template.labels.但是，如果您不这样做，则一旦使用一个或多个用于选择更改的标签，就会遇到kubectl apply的问题，因为kubeclt apply在比较更改时会查看kubectl.kubernetes.io/last-applied-configuration，并且该注释将仅包含用户在创建资源时输入的信息，但没有默认字段.您会收到一个错误消息，因为它无法像以下那样计算差异:

You actually didn’t have to implicitly define .spec.selector when using the v1beta1 extensions. It would in that case default from .spec.template.labels. However, if you don’t, you can run into problems with kubectl apply once one or more of the labels that are used for selecting change because kubeclt apply will look at kubectl.kubernetes.io/last-applied-configuration when comparing changes and that annotation will only contain the user input when he created the resource and none of the defaulted fields. You’ll get an error because it cannot calculate the diff like:

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

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

如您所见，这是一个很大的缺点，因为它意味着您无法更改用作选择器标签的任何标签，否则将完全破坏您的部署流程.通过要求明确定义选择器，在apps/v1beta2中对其进行了修复"，不允许在这些字段上进行更改.

As you can see, this is a pretty big shortcoming since it means you can not change any of the labels that are being used as a selector label or it would completely break your deployment flow. It was "fixed" in apps/v1beta2 by requiring selectors to be explicitly defined, disallowing mutation on those fields.

因此，在您的示例中，您实际上不必定义它们！创建将正常工作，并且默认情况下将使用您的.spec.template.labels.但是，是的，在不久的将来，当您必须使用v1beta2时，该字段将为必填字段.我希望这种回答能回答您的问题，但我并没有使它更加令人困惑；)

So in your example, you actually don’t have to define them! The creation will work and will use your .spec.template.labels by default. But yeah, in the near future when you have to use v1beta2, the field will be mandatory. I hope this kind of answers your question and I didn’t make it any more confusing ;)

这篇关于kubernetes部署容器选择器的目的是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！