在 Kubernetes 部署 yaml 中，为什么我们必须将模板标签与选择器中的部署标签相匹配？

Question

我是 Kubernetes 新手，所以这可能是显而易见的，但在部署 yaml 中，为什么我们必须在部署元数据中定义标签，然后在模板元数据中定义相同的标签，但在选择器中单独匹配这些标签？

模板属于它所在的部署不是很明显吗？ 部署是否存在使用不匹配模板的用例？

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-backend
spec:
  replicas: 2
  selector:
    matchLabels:
      app: api-backend
  template:
    metadata:
      labels:
        app: api-backend
    spec:
      #...etc

我可能缺少对 k8s 或 yaml 的一些关键理解。

有没有标签的模板，它似乎可以工作，但我不明白为什么。 Kubernetes 可以自动神奇地插入标签。

Answer 1

让我们先简化标签、选择器和模板标签。

• 元数据部分中的标签分配给部署本身。

• .spec.template

  部分中的标签分配给部署创建的 Pod。这些实际上称为 PodTemplate 标签。
• 选择器为您的资源提供了唯一性。它用于识别与

  .spec.selector.matchLabels

  部分中的标签匹配的资源。

现在，不强制要求在 matchLabels 部分中包含所有 podTemplate 标签。一个 pod 可以有多个标签，但只有一个 matchLabels 就足以识别 pod。这是一个用例来理解为什么必须使用它

“假设您有部署 X，它创建两个带有标签

nginx-pods

和图像

nginx

的 pod，以及另一个部署 Y，它适用于具有相同标签

nginx-pods

但使用图像

nginx:alpine

的 pod。如果部署 X 正在运行然后运行部署 Y，它不会创建新的 pod，而是用

nginx:alpine

镜像替换现有的 pod。两个部署都会识别 pod，因为 pod 中的标签与两个部署中的标签都匹配

 .spec.selector.matchLabels

”

Answer 2

从技术上讲，参数

matchLabels

决定哪些Pod属于给定的Deployment（以及底层的ReplicaSet）。在实践中，我从未见过

labels

与

matchLabels

不同的部署。因此，原因可能是其他 Kubernetes 资源之间的一致性（例如服务，其中

matchLabels

更有意义）。

我建议阅读博客文章为初学者详细解释了匹配标签、标签和选择器。

Answer 3

因为 Deployment.metadata.labels 属于 Deployment 资源，而 Deployment.spec.template.metadata.labels 属于由 Deployment 控制器处理的 Pod。 Deployment 控制器根据 Pod 资源上的标签知道哪些 Pod 属于哪个 Deployment。

这就是为什么您必须以这种方式指定标签。