部署选择器未选择 Pod答案

【问题标题】：Pod is not getting selected by Deployment selector部署选择器未选择 Pod
【发布时间】：2021-05-17 05:47:40
【问题描述】：

我有这个部署对象：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: deployment-webserver-nginx
  annotations:
    description: This is a demo deployment for nginx webserver 
  labels:
    app: deployment-webserver-nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: deployment-webserver-pods
  template:
    metadata:
      labels:
        app: deployment-webserver-pods
    spec:
      containers:
      - name: nginx
        image: nginx:alpine
        ports:
        - containerPort: 80

我对这个 Deployment 对象的理解是，任何带有app:deployment-webserver-pods 标签的 Pod 都会被选中。当然，这个 Deployment 对象是创建了 3 个副本，但是我想像这样显式地再添加一个 Pod，所以我创建了一个 Pod 对象，它的标签为app:deployment-webserver-pods，下面是它的 Pod 定义：

apiVersion: v1
kind: Pod
metadata:
  name: deployment-webserver-nginx-extra-pod
  labels:
    app: deployment-webserver-pods
spec:
  containers:
  - name: nginx-alpine-container-1
    image: nginx:alpine
    ports:
      - containerPort: 81

我的期望是持续运行的 Deployment Controller 会选择这个新的 Pod，当我选择 kubectl get deploy 时，我会看到 4 个 Pod 正在运行。但这并没有发生。

我什至尝试先用这个标签创建这个 pod，然后创建我的 Deployment，并认为现在可能会选择这个显式的 Pod，但仍然没有发生。

标签和选择器不是这样工作的吗？我知道我可以通过部署扩展到 4 个副本，但我试图了解如何使用标签和选择器选择 Pod/其他 Kubernetes 对象。

【问题讨论】：

标签： kubernetes google-kubernetes-engine kubernetes-pod kubernetes-deployment

【解决方案1】：

来自official docs：

注意：您不应该创建标签与此匹配的其他 Pod 选择器，或者直接，通过创建另一个部署，或者通过创建另一个控制器，例如 ReplicaSet 或复制控制器。如果你这样做，第一个 Deployment 认为它创建了这些其他 Pod。 Kubernetes 不会阻止你做这个。

如文档中进一步所述，不建议使用上述方法扩展部署的副本。

从文档的同一部分需要注意的另一个重要点：

如果您有多个具有重叠选择器的控制器，则控制器会互相争斗，并且行为不正确。

【讨论】：

【解决方案2】：

我的期望是持续运行的 Deployment Controller 会选择这个新的 Pod，当我执行 kubectl get deploy 时，我会看到 4 个 Pod 在运行。但这并没有发生。

部署控制器不是这样工作的，它侦听Deployment-resources 并将它们“驱动”到所需的状态。这通常意味着，如果 template: 部分发生任何更改，则会使用副本数创建一个新的 ReplicaSet。除了更改 replicas: 之外，您无法通过其他方式将 Pod 添加到 Deployment - 每个实例都是从相同的 Pod 模板创建的并且是相同的。

标签和选择器不是这样工作的吗？

...但我想了解如何使用标签和选择器选择 Pod / 其他 Kubernetes 对象。

是的，标签和选择器在 Kubernetes 中用于很多事情，但不是所有事情。当您创建一个带有标签的部署、一个具有相同标签的 Pod 以及最后一个带有选择器的 Service 时，发往该服务的流量会将流量分配到您的部署实例以及额外的 Pod。

例子：

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: deployment-webserver-pods
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080

Labels and Selector 在使用例如kubectl。您可以为团队添加标签，例如应用程序，然后您可以选择属于该团队或应用程序的所有部署或 Pod（例如，如果应用程序由应用程序部署和缓存部署组成），例如：

kubectl get pods -l team=myteam,app=customerservice

【讨论】：

【解决方案3】：

我的期望是持续运行的部署控制器将选择这个新 Pod，当我执行 kubectl get deploy 时，我会看到 4 个 pod 正在运行。但这并没有发生。

Kubernetes 是一个“Declaratively”而非“Imperatively”运行的系统，这意味着您通常通过 YAML 文件记下集群中应用程序的所需状态，并且这些声明的期望状态定义了应用程序的所有部分。

如果集群按照您期望的方式进行命令式配置，则很难理解和复制集群是如何进入该状态的。

【讨论】：

【解决方案4】：

只是在上面的解释中添加，如果我们试图手动创建 pod 和管理，那么在 K8s 中拥有控制器的目的是什么。

我的期望是持续运行的部署控制器将选择这个新 Pod，当我执行 kubectl get deploy 时，我会看到 4 个 pod 正在运行。但这并没有发生。

根据您的 yaml replicas:3 已设置，因此部署不会将新 pod 作为第 4 个副本。

【讨论】：