标签是附加到对象(例如窗格)的键/值对。标签旨在用于指定对用户有意义且相关的对象的标识属性,但不直接暗示核心系统的语义。标签可用于组织和选择对象的子集。标签可以在创建时附加到对象,随后可以随时添加和修改。每个对象都可以定义一组键/值标签。每个Key对于给定对象必须是唯一的。
"metadata": {
"labels": {
"key1" : "value1",
"key2" : "value2"
}
}标签允许高效的查询和监视,非常适合在UI和CLI中使用。应使用注释记录非识别信息。
标签使用户能够以松散耦合的方式将他们自己的组织结构映射到系统对象,而无需客户端存储这些映射。
服务部署和批处理流水线通常是多维实体(例如,多个分区或部署,多个释放轨道,多个层,每层多个微服务)。管理通常需要交叉操作,这打破了严格的层次表示的封装,特别是由基础设施而不是用户确定的严格的层次结构。
示例标签:
"release" : "stable", "release" : "canary""environment" : "dev","environment" : "qa","environment" : "production""tier" : "frontend","tier" : "backend","tier" : "cache""partition" : "customerA", "partition" : "customerB""track" : "daily", "track" : "weekly"这些只是常用标签的例子; 你可以自由地制定自己的约定。请记住,标签Key对于给定对象必须是唯一的。
标签是键/值对。有效标签键有两个段:可选前缀和名称,用斜杠(/)分隔。名称段是必需的,必须是63个字符或更少,以字母数字字符([a-z0-9A-Z])开头和结尾,带有破折号(-),下划线(_),点(.)和字母数字之间。前缀是可选的。如果指定,前缀必须是DNS子域:由点(.)分隔的一系列DNS标签,总共不超过253个字符,后跟斜杠(/)。
如果省略前缀,则假定标签Key对用户是私有的。自动化系统组件(例如kube-scheduler,kube-controller-manager,kube-apiserver,kubectl,或其他第三方自动化),它添加标签终端用户对象都必须指定一个前缀。
在kubernetes.io/和k8s.io/前缀保留给Kubernetes核心组件。
有效标签值必须为63个字符或更少,并且必须为空或以字母数字字符([a-z0-9A-Z])开头和结尾,并带有短划线(-),下划线(_),点(.)和字母数字。
与名称和UID不同,标签不提供唯一性。通常,我们希望许多对象携带相同的标签。
通过标签选择器,客户端/用户可以识别一组对象。标签选择器是Kubernetes中的核心分组原语。
目前,API支持两种类型的选择:基于平等,和基于集的。标签选择器可以由逗号分隔的多个要求组成。在多个要求的情况下,必须满足所有要求,因此逗号分隔符充当逻辑AND(&&)运算符。
空或非指定选择器的语义取决于上下文,使用选择器的API类型应记录它们的有效性和含义。
注意:对于某些API类型(例如ReplicaSet),两个实例的标签选择器不得在命名空间内重叠,或者控制器可以将其视为冲突的指令,并且无法确定应存在多少副本。
基于平等或不平等的要求允许按标签键和值进行过滤。匹配对象必须满足所有指定的标签约束,尽管它们也可能有其他标签。三种运营商都承认=,==,!=。前两个代表平等(简单地说是同义词),而后者代表不平等。例如:
environment = production
tier != frontend前者选择密钥等于environment和值等于的所有资源production。后者选择密钥等于tier和值不同的frontend所有资源,以及没有带tier密钥标签的所有资源。可以过滤使用逗号运算符production排除的资源frontend:environment=production,tier!=frontend
基于等同的标签要求的一种使用场景是Pods指定节点选择标准。例如,下面的示例Pod选择标签为“ accelerator=nvidia-tesla-p100”的节点。
apiVersion: v1
kind: Pod
metadata:
name: cuda-test
spec:
containers:
- name: cuda-test
image: "k8s.gcr.io/cuda-vector-add:v0.1"
resources:
limits:
nvidia.com/gpu: 1
nodeSelector:
accelerator: nvidia-tesla-p100基于集合的标签要求允许根据一组值过滤密钥。三种运营商的支持:in,notin和exists(仅密钥标识符)。例如:
environment in (production, qa)
tier notin (frontend, backend)
partition
!partition第一个示例选择键等于environment和值等于production或的所有资源qa。第二个示例选择密钥等于tier和除了frontend和之外的值的backend所有资源,以及没有带tier密钥标签的所有资源。第三个例子选择所有资源,包括带密钥的标签partition; 没有检查值。第四个示例选择没有带键的标签的所有资源partition; 没有检查值。类似地,逗号分隔符充当AND运算符。因此,使用partition密钥(无论值)和environment不同的 过滤资源qa都可以实现partition,environment notin (qa)。基于集合标签选择器是一种平等的一般形式,因为environment=production它等同于environment in (production); 同样的!=和notin。
基于集合的需求可以与基于相等的需求相结合。例如:partition in (customerA, customerB),environment!=qa。
LIST和WATCH操作可以指定标签选择器来过滤使用查询参数返回的对象集。这两个要求都是允许的(在此处显示为出现在URL查询字符串中):
两种标签选择器样式都可用于通过REST客户端列出或查看资源。例如,靶向apiserver与kubectl和使用基于平等-一个可写:
kubectl get pods -l environment=production,tier=frontend或使用基于集合的要求:
kubectl get pods -l 'environment in (production),tier in (frontend)'如前所述,基于集合的要求更具表现力。例如,他们可以在值上实现OR运算符:
kubectl get pods -l 'environment in (production, qa)'或限制负匹配通过存在操作者:
kubectl get pods -l 'environment,environment notin (frontend)'某些Kubernetes对象(例如services和replicationcontrollers)也使用标签选择器来指定其他资源集,例如pod。
service使用标签选择器定义目标的一组pod 。类似地,replicationcontroller应该管理的pod的数量也用标签选择器定义。
两个对象的标签选择器在使用映射定义json或yaml文件中定义,并且仅支持基于等同的需求选择器:
"selector": {
"component" : "redis",
}要么
selector: component: redis这个选择器(分别以json或yaml格式)相当于component=redis或component in (redis)。
较新的资源,如Job,Deployment,Replica Set,和Daemon Set,支持基于集合的要求也是如此。
selector:
matchLabels:
component: redis
matchExpressions:
- {key: tier, operator: In, values: [cache]}
- {key: environment, operator: NotIn, values: [dev]}matchLabels是对的地图{key,value}。一个单一的{key,value}在matchLabels地图相当于一个元件matchExpressions,其key字段是“键”,则operator是“以”和values阵列仅包含“值”。matchExpressions是一个pod选择器要求列表。有效的运算符包括In,NotIn,Exists和DoesNotExist。在In和NotIn的情况下,设置的值必须是非空的。所有的要求,从两者matchLabels和matchExpressionsAND一起 - 他们必须满足,以匹配。
用于选择标签的一个用例是约束pod可以调度的节点集。有关更多信息,请参阅有关节点选择的文档。
本文翻译Kubernetes官方文
本文分享自 kubernetes中文社区 微信公众号,前往查看
如有侵权,请联系 cloudcommunity@tencent.com 删除。
本文参与 腾讯云自媒体同步曝光计划 ,欢迎热爱写作的你一起参与!