选择器

标签是 Kubernetes 用于选择对象的键值元数据。Service 选择器、运维查询和工作负载控制器都可能依赖标签，但每个消费者有自己的 API 和处理方式。因此，标签变化可能改变对象所属集合，同时底层进程仍然健康。审阅时应把标签视为真实消费者的输入，而不是仅用于展示的贴纸，否则看似简单的文字修改也可能改变路由。 确认正在使用哪一种选择语言 标签键采用限定名称格式，值也有字符和长度约束。标签值可以为空；不为空时，其允许字符及首尾位置受到限制，最大长度为六十三个字符。任意长段落或不受约束的 JSON 并不适合放在标签值里。描述性信息可以采用 annotation，但仍然要遵守对应格式和消费契约，不能把换字段当成取消所有限制。 等值条件检查某个键是否具有指定值，集合条件还支持成员关系与存在性检查。同一个选择器里的多个条件需要同时满足。有一个容易忽略的细节：track!=canary 也会匹配根本没有 track 键的对象。如果不允许键缺失，应另外要求这个键存在，不能认为“不等于某值”就已经隐含“这个键肯定存在”。 不同资源的选择字段结构并不相同。普通带选择器的 Service 使用等值映射，不能把完整集合表达式随意塞进某个映射值。另一些 API 提供 LabelSelector 结构，而 kubectl 列表查询能够接受选择表达式。把命令行中方便使用的查询转换成清单之前，应核对目标字段的真实结构，避免把同一个概念误当成完全相同的输入格式。 坏掉的样子 Service 选择器会识别本命名空间中匹配的 Pod，端点机制再跟踪地址与就绪状态。标签匹配本身不证明服务已经准备好，也不证明端口配置正确。在普通就绪策略下，路由可用目标还取决于端点条件。检查时应查看相应 EndpointSlice 和应用探测结果，不能在一次标签查询成功后就停止验证。 publishNotReadyAddresses 设置会改变服务发现对就绪状态的处理。在这种配置下，不能仅凭端点被标成就绪，就断言对应容器已经通过应用探测。下面实验采用普通默认行为，没有测试这个覆盖设置，因此结果也不应无条件推广到使用该选项的服务。 给健康 Pod 修改标签，可能把它移出 Service，却并不终止进程。过宽的条件则可能把原本不该提供服务的工作负载加入后端。如果 Pod 由控制器管理，手工改标签还可能影响所属关系与协调行为。应通过负责的控制器更新预期状态，并在改变共享键含义之前核对主要消费者，避免修好一个查询却破坏另一条路由。 选择器不是网络授权。某个 Pod 即使不属于一个 Service，也可能继续通过自身地址或其他 Service 被访问，除非另有控制阻止。NetworkPolicy、应用授权和路由分别解决不同部分，不能把选择器描述成能够拒绝所有未选中对象直连流量的访问名单。对象是否被发现，与请求最终是否允许，必须分别成立。 ...