我有这个部署对象:
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都会被选中。当然，这个部署对象创建了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
我的期望是持续运行的部署控制器将选择这个新的Pod，当我做kubectl get deploy时，我会看到4个Pod正在运行。但这并没有发生。
我甚至尝试先用这个标签创建这个pod，然后创建我的部署，并认为也许现在这个显式的pod将被选中，但仍然没有发生。
标签和选择器不这样工作吗?我知道我可以通过部署扩展到4个副本，但我试图了解如何使用标签和选择器选择pod/其他Kubernetes对象。
来自官方文档:
注意:您不应该创建其他标签与此匹配的pod选择器，可以直接创建另一个Deployment，也可以通过创建另一个控制器，如ReplicaSet或ReplicationController。如果这样做，第一个部署就会这样认为它创造了其他的pod。Kubernetes不会阻止你这样做这个。
正如文档中进一步描述的那样，不建议使用上述方法扩展部署的副本。
另一个需要注意的重要点来自文档的同一部分:
如果您有多个具有重叠选择器的控制器，则控制器之间会相互争斗，无法正常工作。
我的期望是持续运行的部署控制器将选择这个新的Pod，当我做kubectl得到部署时，我将看到4个Pod正在运行。但这并没有发生。
部署控制器不是这样工作的，它监听部署资源和"驱动";它们达到理想状态。这通常意味着，如果template:部分发生任何更改，那么将创建一个具有副本数量的新ReplicaSet。除了更改replicas:之外，您不能以其他方式将Pod添加到部署中——每个实例都是从相同的Pod模板创建的，并且是相同的。
标签和选择器不是这样工作的吗?
…但我试图了解如何使用标签和选择器选择pod/其他Kubernetes对象。
是的，标签和选择器在Kubernetes中被用于很多事情，但不是所有的事情。当你创建一个带有标签的部署，一个带有相同标签的Pod，最后是一个带有选择器的服务，那么发送到该服务的流量将分配到你的部署实例以及额外的Pod。
的例子:
apiVersion: v1
kind: Service
metadata:
name: my-service
spec:
selector:
app: deployment-webserver-pods
ports:
- protocol: TCP
port: 80
targetPort: 8080
标签和选择器在使用kubectl时对管理也很有用。你可以为Teams或App添加标签，然后你可以选择属于该Team或App的所有deployment或Pods(例如，如果应用由App-deployment和cache-deployment组成)，例如:
kubectl get pods -l team=myteam,app=customerservice
我的期望是持续运行部署控制器我会选择这个新的Pod，当kubectl得到部署时，我就会看到4个pod在运行。但这并没有发生。
Kubernetes是一个以声明方式操作的系统";而非">命令式";这意味着您通常通过YAML文件在集群中写下应用程序的期望状态，这些声明的期望状态定义了应用程序的所有部分。
如果集群按照您期望的方式命令式配置，那么理解和复制集群是如何进入该状态的将是非常困难的。
只是在上面的解释中添加，如果我们试图手动创建pod并管理，那么在k8中拥有控制器的目的是什么?
我的期望是持续运行部署控制器我会选择这个新的Pod，当kubectl得到部署时，我就会看到4个pod在运行。但这并没有发生。
根据您的yaml,replicas:3已经设置，因此部署不会将新pod作为第四个副本。