标签（Labels） 是附加到 Kubernetes （比如 Pod）上的键值对。 标签旨在用于指定对用户有意义且相关的对象的标识属性，但不直接对核心系统有语义含义。 标签可以用于组织和选择对象的子集。标签可以在创建时附加到对象，随后可以随时添加和修改。 每个对象都可以定义一组键/值标签。每个键对于给定对象必须是唯一的。
标签能够支持高效的查询和监听操作，对于用户界面和命令行是很理想的。 应使用注解记录非识别信息。
标签使用户能够以松散耦合的方式将他们自己的组织结构映射到系统对象，而无需客户端存储这些映射。
服务部署和批处理流水线通常是多维实体（例如，多个分区或部署、多个发行序列、多个层，每层多个微服务）。 管理通常需要交叉操作，这打破了严格的层次表示的封装，特别是由基础设施而不是用户确定的严格的层次结构。
示例标签：
- ,
- , ,
- , ,
- ,
- ,
有一些常用标签的例子；你可以任意制定自己的约定。 请记住，标签的 Key 对于给定对象必须是唯一的。
标签是键值对。有效的标签键有两个段：可选的前缀和名称，用斜杠（）分隔。 名称段是必需的，必须小于等于 63 个字符，以字母数字字符（）开头和结尾， 带有破折号（），下划线（），点（ ）和之间的字母数字。 前缀是可选的。如果指定，前缀必须是 DNS 子域：由点（）分隔的一系列 DNS 标签，总共不超过 253 个字符， 后跟斜杠（）。
如果省略前缀，则假定标签键对用户是私有的。 向最终用户对象添加标签的自动系统组件（例如 、、 、 或其他第三方自动化工具）必须指定前缀。
和 前缀是为 Kubernetes 核心组件保留的。
有效标签值：
- 必须为 63 个字符或更少（可以为空）
- 除非标签值为空，必须以字母数字字符（）开头和结尾
- 包含破折号（）、下划线（）、点（）和字母或数字
例如，以下是一个清单 (manifest)，适用于具有 和 这两个标签的 Pod：
与名称和 UID 不同， 标签不支持唯一性。通常，我们希望许多对象携带相同的标签。
通过标签选择算符，客户端/用户可以识别一组对象。标签选择算符是 Kubernetes 中的核心分组原语。
API 目前支持两种类型的选择算符：基于等值的和基于集合的。 标签选择算符可以由逗号分隔的多个需求组成。 在多个需求的情况下，必须满足所有要求，因此逗号分隔符充当逻辑与（）运算符。
空标签选择算符或者未指定的选择算符的语义取决于上下文， 支持使用选择算符的 API 类别应该将算符的合法性和含义用文档记录下来。
基于等值或基于不等值的需求允许按标签键和值进行过滤。 匹配对象必须满足所有指定的标签约束，尽管它们也可能具有其他标签。 可接受的运算符有 、 和 三种。 前两个表示相等（并且是同义词），而后者表示不相等。例如：
前者选择所有资源，其键名等于 ，值等于 。 后者选择所有资源，其键名等于 ，值不同于 ，所有资源都没有带有 键的标签。 可以使用逗号运算符来过滤 环境中的非 层资源：。
基于等值的标签要求的一种使用场景是 Pod 要指定节点选择标准。 例如，下面的示例 Pod 选择存在 标签且值为 的节点。
基于集合的标签需求允许你通过一组值来过滤键。 支持三种操作符：、 和 （只可以用在键标识符上）。例如：
- 第一个示例选择了所有键等于 并且值等于 或者 的资源。
- 第二个示例选择了所有键等于 并且值不等于 或者 的资源，以及所有没有 键标签的资源。
- 第三个示例选择了所有包含了有 标签的资源；没有校验它的值。
- 第四个示例选择了所有没有 标签的资源；没有校验它的值。
类似地，逗号分隔符充当与运算符。因此，使用 键（无论为何值）和 不同于 来过滤资源可以使用 来实现。
基于集合的标签选择算符是相等标签选择算符的一般形式，因为 等同于 ； 和 也是类似的。
基于集合的要求可以与基于相等的要求混合使用。例如：。
对于 list 和 watch 操作，你可以指定标签选择算符过滤返回的对象集；你可以使用查询参数来指定过滤条件。 （了解 Kubernetes 中的 watch 操作细节，请参阅 高效检测变更）。 两种需求都是允许的。（这里显示的是它们出现在 URL 查询字符串中）
- 基于等值的需求：
- 基于集合的需求：
两种标签选择算符都可以通过 REST 客户端用于 list 或者 watch 资源。 例如，使用 定位 ，可以使用基于等值的标签选择算符可以这么写：
或者使用基于集合的需求：
正如刚才提到的，基于集合的需求更具有表达力。例如，它们可以实现值的或操作：
或者通过notin运算符限制不匹配：
一些 Kubernetes 对象，例如 和 ， 也使用了标签选择算符去指定了其他资源的集合，例如 pods。
Service 和 ReplicationController
一个 指向的一组 Pod 是由标签选择算符定义的。同样，一个 应该管理的 Pod 的数量也是由标签选择算符定义的。
两个对象的标签选择算符都是在 或者 文件中使用映射定义的，并且只支持 基于等值需求的选择算符：
或者
这个选择算符（分别在 或者 格式中）等价于 或 。
支持基于集合需求的资源
比较新的资源，例如 、 、 和 ， 也支持基于集合的需求。
是由 对组成的映射。 映射中的单个 等同于 的元素， 其 字段为 "key"， 为 "In"，而 数组仅包含 "value"。 是 Pod 选择算符需求的列表。 有效的运算符包括 、、 和 。 在 和 的情况下，设置的值必须是非空的。 来自 和 的所有要求都按逻辑与的关系组合到一起 -- 它们必须都满足才能匹配。
选择节点集
通过标签进行选择的一个用例是确定节点集，方便 Pod 调度。 有关更多信息，请参阅选择节点文档。
到目前为止我们使用的示例中的资源最多使用了一个标签。 在许多情况下，应使用多个标签来区分不同集合。
例如，不同的应用可能会为 标签设置不同的值。 但是，类似 guestbook 示例 这样的多层应用，还需要区分每一层。前端可能会带有以下标签：
Redis 的主从节点会有不同的 标签，甚至还有一个额外的 标签：
以及
标签使得我们能够按照所指定的任何维度对我们的资源进行切片和切块：
有时需要要在创建新资源之前对现有的 Pod 和其它资源重新打标签。 这可以用 完成。 例如，如果想要将所有 NGINX Pod 标记为前端层，运行：
首先用标签 "app=nginx" 过滤所有的 Pod，然后用 "tier=fe" 标记它们。 想要查看你刚设置了标签的 Pod，请运行：
此命令将输出所有 "app=nginx" 的 Pod，并有一个额外的描述 Pod 所在分层的标签列 （用参数 或者 标明）。
想要了解更多信息，请参考标签和 命令文档。
- 学习如何给节点添加标签
- 查阅众所周知的标签、注解和污点
- 参见推荐使用的标签
- 使用名字空间标签来实施 Pod 安全性标准
- 阅读为 Pod 标签编写控制器的博文
版权声明：
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！
转载请注明出处，原文链接：https://www.xkablog.com/hd-nodejs/42668.html