Question

我了解服务会使用选择器来识别通过其标签将流量路由至哪些吊舱。

apiVersion: v1
kind: Service
metadata:
  name: svc
spec:
  ports:
  - name: tcp
    protocol: TCP
    port: 443
    targetPort: 443
  selector:
    app: nginx

那很好。

现在，此选择器与部署中的spec.selector之一有什么区别。我知道使用它是为了使部署可以匹配和管理其pod。

但是我不明白为什么我需要额外的matchLabels声明，并且不能像在服务中那样做。在语义上有什么用？

apiVersion: apps/v1 
kind: Deployment
metadata:
  name: nginx
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 1 
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx

预先感谢

Answer 1

就这么简单-在服务spec.selector中，您可以仅通过标签来识别将哪些流量路由到哪些Pod。另一方面，在部署spec.selector中，您有两个选择来决定将Pod安排在哪个节点上，分别是：matchExpressions，matchLabels。

让我知道它是否回答了您的问题：）

Answer 2

部署如何使用spec.selector

更改Deployment时，将创建一个新的ReplicaSet。 ReplicaSet负责管理Pod。它使用spec.selector知道应该管理哪些Pod。

示例：

如果replicas: 1中的Deployment更改为例如replicas: 2创建了一个新的ReplicaSet，它使用spec.selector 观察 Pods，以将Pod与匹配标签进行匹配。最初只看到1个副本，但现在它的期望状态为replicas: 2，因此它负责从template中的Deployment创建一个Pod。

选择器语法

有两种方法可以在“部署”的labels下声明spec.selector。

matchLabels-您声明标签
matchExpressions-您为标签写一个表达式

有关kubectl explain deployment.spec.selector替代方案的完整说明，请参见spec.selector。

标签和选择器

Labels and Selectors是Kubernetes中的通用概念，并在多个地方使用。另一个示例是如何过滤kubectl中想要查看或使用的资源。例如。您可以通过以下方式为应用选择广告连播：

kubectl get pod -l=app=myappname

（如果您的Pod标有app: myappname。

Answer 3

<块引用>

为什么我需要额外的 matchLabels 声明并且不能像在服务中那样做。这在语义上有什么用？

因为 service 规范仅支持 equality-based 选择器，而 deployment 是一种支持两种语法（equality-based 和基于集合).

<块引用>

API 目前支持两种类型的选择器：基于相等和基于集合。标签选择器可以由多个以逗号分隔的要求组成。在多个要求的情况下，必须满足所有要求，因此逗号分隔符充当逻辑 AND (&&) 运算符。 Reference

Service 规范仅使用“基于相等性”的标签选择器语法。

<块引用>

较新的资源，例如 Job、Deployment、ReplicaSet 和 DaemonSet，支持基于集合的需求... Reference

我的理解是，之前唯一支持的语法是基于相等的语法，就像我们在 service 规范中所使用的那样，而现在，当您使用的资源支持新语法时，您需要使用 matchLabels 或 matchExpressions。

服务选择器与部署选择器匹配标签

3 个答案:

部署如何使用spec.selector

选择器语法

标签和选择器