kubernetes 部署 pod 选择器的目的是什么? [英] 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.例如，在这种特殊情况下，它们旨在识别属于部署副本集的 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 将查看 kubeclt apply 用于选择更改的一个或多个标签code>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`
如您所见，这是一个很大的缺点，因为这意味着您无法更改任何用作选择器标签的标签，否则会完全破坏您的部署流程.它在 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 部署 pod 选择器的目的是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
