上一篇【第09篇】Pod的YAML从入门到精通——每个字段都是干什么的下一篇【第11篇】Namespace——给你的K8s集群划地盘摘要你要是问K8s里哪个设计最简单却又最强大我肯定投Label一票。Label说白了就是KV对你往资源上随便贴比如appnginx,envprod,versionv1.25然后拿着Selector去筛选——就跟你在购物网站搜红色大码打折一样朴素。但就是这么一个简单的KV机制支撑起了K8s里Service找Pod、Deployment管Pod、灰度发布切流量、AB测试分用户等所有灵活编排的场景。本文从Label的本质讲起把等值选择器和集合选择器的区别讲清楚然后给你一套社区推荐的Label命名规范最后用两个实战案例灰度发布和AB测试让你看到Label的真正威力。看完这篇你会从随便贴标签进化到战略性贴标签。一、Label到底是个什么东西——“想贴什么贴什么”Label就是附加在K8s对象上的键值对Key-Value Pair没有任何预定义的Schema。你想加什么标签就加什么K8s不会拦你。【Label 就像超市货架上的标签】 没Label的世界 有Label的世界 ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ │ Pod A │ │ Pod B │ │ Pod C │ │ Pod A │ │ Pod B │ │ Pod C │ │ │ │ │ │ │ │ app:web│ │ app:web│ │app:db │ │ │ │ │ │ │ │ver:v1 │ │ver:v2 │ │ver:v1 │ │ │ │ │ │ │ │env:prod│ │env:prod│ │env:prod│ └────────┘ └────────┘ └────────┘ └────────┘ └────────┘ └────────┘ │ │ 找所有Web前端Pod └──────────┘ 不好意思我分不出来... appweb 的Pod就是这俩 根本没法灵活管理 筛选、分组、编排全搞定# Label 可以贴在任意K8s对象上apiVersion:v1kind:Podmetadata:name:nginx-v1labels:# Label 区域app:nginx# 应用名version:v1.25# 版本号environment:production# 环境tier:frontend# 层级team:platform# 所属团队release:stable# 发布通道---apiVersion:v1kind:Servicemetadata:name:nginx-servicelabels:# Service 也能贴标签app:nginxmanaged-by:terraform# 甚至可以标记谁创建的要点Label的Key和Value都没有预定义Schema——你写什么K8s就存什么。Key最长63字符带前缀最长253Value最长63字符可以包含字母、数字、连字符、下划线、点。Key可以带前缀如app.kubernetes.io/name但前缀必须以/结尾。Label的命名规则【Label Key 的两种写法】 不带前缀简单Key 带前缀DNS子域名前缀 app: nginx app.kubernetes.io/name: nginx version: v1.25 app.kubernetes.io/version: v1.25 environment: prod app.kubernetes.io/component: frontend 前缀规则 • 前缀必须是DNS子域名如app.kubernetes.io • 前缀和名称之间用 / 分隔 • 前缀最多253字符名称最多63字符 • 开头和结尾必须是字母数字二、Selector——拿着Label去寻人标签贴好了怎么根据标签找到目标答案就是Label Selector标签选择器。2.1 等值选择器Equality-based这是最常用的选择器——判断Label的值等于或不等于某个值# Service 用 Selector 找到目标PodapiVersion:v1kind:Servicemetadata:name:nginx-servicespec:selector:# 等值选择器app:nginx# app nginxenvironment:production# environment productionports:-port:80targetPort:80操作符含义示例或等于app nginx!不等于environment ! testingin值在给定集合中environment in (production, staging)notin值不在给定集合中environment notin (dev, local)# kubectl 中使用 Label Selector# 等值匹配kubectl get pods-lappnginx kubectl get pods-lappnginx,environmentproduction# 不等于kubectl get pods-lenvironment!testing# in 和 notinkubectl get pods-lenvironment in (production,staging)kubectl get pods-lenvironment notin (dev)2.2 集合选择器Set-based集合选择器更灵活——它不判断等于/不等于而是判断Key是否存在或值满足什么条件操作符含义示例existsKey存在不管值是什么appdoesnotexistKey不存在!versionin值在集合中environment in (prod, staging)notin值不在集合中environment notin (dev, test)# 集合选择器只能在特定资源中使用如 DeploymentapiVersion:apps/v1kind:Deploymentmetadata:name:nginx-deploymentspec:selector:matchLabels:# 等值选择器AND关系app:nginxmatchExpressions:# 集合选择器-{key:environment,operator:In,values:[production,staging]}-{key:tier,operator:NotIn,values:[backend]}-{key:version,operator:Exists}# 有version标签就行不管值要点matchLabels里的条件是AND关系全部满足才匹配matchExpressions里的多个条件也是AND关系。如果需要OR得把OR的条件放进同一个matchExpression的values里比如In: [prod, staging]。2.3 等值 vs 集合——对比维度等值选择器集合选择器语法key: value{key, operator, values}支持不等于✅!✅NotIn支持Key存在与否❌ 不支持✅Exists/DoesNotExist支持范围/正则❌ 不支持❌ 也不支持Label不是数据库查询适用资源kubectl命令行、ServiceDeployment、DaemonSet、StatefulSet复杂度简单直观更灵活但语法复杂三、社区推荐的Label规范——“千万别瞎贴”Label没有Schema约束是好事自由也是坏事容易乱。CNCF社区总结了一套推荐Label建议所有K8s应用都遵守【推荐Label规范】 app.kubernetes.io/name ← 应用名称如 nginx、mysql app.kubernetes.io/instance ← 应用实例的唯一标识 app.kubernetes.io/version ← 应用的当前版本 app.kubernetes.io/component ← 架构中的组件类型如 frontend、backend、database app.kubernetes.io/part-of ← 所属的更大应用如 wordpress app.kubernetes.io/managed-by ← 管理工具如 helm、kustomize、terraform app.kubernetes.io/created-by ← 创建者/控制器类型如 deployment-controller# 遵循推荐规范的PodapiVersion:v1kind:Podmetadata:name:wordpress-frontend-7b5f8c-abc12labels:# 推荐标签带 app.kubernetes.io 前缀app.kubernetes.io/name:wordpressapp.kubernetes.io/instance:wordpress-prodapp.kubernetes.io/version:6.4app.kubernetes.io/component:frontendapp.kubernetes.io/part-of:wordpressapp.kubernetes.io/managed-by:helm# 自定义标签environment:productionteam:platformspec:containers:-name:wordpressimage:wordpress:6.4要点推荐标签不是K8s强制要求的——你不加也不报错。但加上它们Prometheus自动发现、Helm管理、Istio流量控制、多团队协作都会变得非常丝滑。花两分钟加上这些标签后面能省两小时的排查时间。四、实战场景一用Label实现灰度发布灰度发布金丝雀发布是Label最经典的实战场景。思路很简单用Label区分stable版本和canary灰度版本的Pod然后用Service的Selector控制流量分配。【灰度发布架构】 ┌─────────────────┐ │ Ingress/ │ │ 外部流量 │ └────────┬────────┘ │ ┌────────▼────────┐ │ Service 总入口 │ │ selector: │ │ app: nginx │ ← 选中所有 nginx Pod └────────┬────────┘ │ ┌──────────────┼──────────────┐ ▼ ▼ ┌───────────────────────┐ ┌───────────────────────┐ │ Stable Service │ │ Canary Service │ │ selector: │ │ selector: │ │ app: nginx │ │ app: nginx │ │ track: stable │ │ track: canary │ └───────────┬───────────┘ └───────────┬───────────┘ │ │ ┌──────┴──────┐ ┌──────┴──────┐ ▼ ▼ ▼ ▼ ┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐ │nginx │ │nginx │ │nginx │ │nginx │ │v1.25 │ │v1.25 │ │v1.26 │ │v1.26 │ │stable │ │stable │ │canary │ │canary │ └─────────┘ └─────────┘ └─────────┘ └─────────┘ 90% 流量 10% 流量# Step 1: 部署Stable版本v1.25apiVersion:apps/v1kind:Deploymentmetadata:name:nginx-stablespec:replicas:9# 90%流量selector:matchLabels:app:nginxtrack:stabletemplate:metadata:labels:app:nginxtrack:stableversion:v1.25spec:containers:-name:nginximage:nginx:1.25---# Step 2: 部署Canary版本v1.26新版本apiVersion:apps/v1kind:Deploymentmetadata:name:nginx-canaryspec:replicas:1# 10%流量selector:matchLabels:app:nginxtrack:canarytemplate:metadata:labels:app:nginxtrack:canaryversion:v1.26spec:containers:-name:nginximage:nginx:1.26# 新版本镜像---# Step 3: Service 选中所有Podstable canaryapiVersion:v1kind:Servicemetadata:name:nginx-servicespec:selector:app:nginx# 不管track是什么都选进来ports:-port:80targetPort:80要点灰度发布的核心思路就两步——(1) 用Label区分不同版本的Pod(2) 通过调整副本数控制流量比例。新版本没问题把canary的replicas从1调到3再到9同时把stable的replicas从9减到6再到0就完成了平滑升级。另一种灰度策略Header/Cookie路由如果用的是Istio或NGINX Ingress还能做到更精细的灰度——根据请求Header或Cookie把特定用户路由到新版本# Istio VirtualService 按 Header 灰度apiVersion:networking.istio.io/v1beta1kind:VirtualServicemetadata:name:nginx-vsspec:hosts:-nginx.example.comhttp:-match:-headers:x-canary:exact:true# 带了这个Header的用户route:-destination:host:nginx-servicesubset:canary# 路由到canary Pod-route:-destination:host:nginx-servicesubset:stable# 其他用户路由到stable Podweight:100五、实战场景二AB测试分用户群AB测试跟灰度发布的关系是兄弟但不一样——灰度是看新版本稳不稳定AB是看两个版本哪个效果更好。【AB测试 vs 灰度发布】 灰度发布安全第一 AB测试数据驱动 ┌────────────────────────┐ ┌────────────────────────┐ │ 目标验证新版本不出Bug │ │ 目标比较两个版本的转化率 │ │ 方法逐步增加新版本流量 │ │ 方法固定比例分流用户 │ │ 判断系统稳定就全量 │ │ 判断数据说了算 │ └────────────────────────┘ └────────────────────────┘ Label 实现 track: canary → v2.0 Pod variant: A → 红色按钮版Pod track: stable → v1.0 Pod variant: B → 绿色按钮版Pod# AB测试同一个应用两个variant---apiVersion:apps/v1kind:Deploymentmetadata:name:app-variant-aspec:replicas:5selector:matchLabels:app:myapptest:abvariant:atemplate:metadata:labels:app:myapptest:abvariant:a# 实验组Aspec:containers:-name:myappimage:myapp:red-button# 红色按钮版---apiVersion:apps/v1kind:Deploymentmetadata:name:app-variant-bspec:replicas:5selector:matchLabels:app:myapptest:abvariant:btemplate:metadata:labels:app:myapptest:abvariant:b# 实验组Bspec:containers:-name:myappimage:myapp:green-button# 绿色按钮版# 查询AB测试结果# A组Pod数量kubectl get pods-ltestab,varianta --no-headers|wc-l# B组Pod数量kubectl get pods-ltestab,variantb --no-headers|wc-l# 结束测试后清理A组kubectl delete deployment app-variant-a kubectl scale deployment app-variant-b--replicas10# B组获胜扩全量六、Label的管理技巧——“防止标签混乱”6.1 批量加标签# 给所有Pod加标签kubectl label pods--allenvironmentproduction# 给符合特定条件的Pod加标签kubectl label pods-lappnginxtierfrontend# 强制覆盖已有标签kubectl label pods-lappnginxversionv1.25--overwrite6.2 按标签筛选# 列出所有生产环境的前端Podkubectl get pods-lenvironmentproduction,tierfrontend-A# 列出所有没有version标签的Podkubectl get pods-l!version# 按标签筛选并删除kubectl delete pods-lappnginx,versionv1.24# 按多列标签排序显示kubectl get pods-Lapp,version,environment# NAME READY STATUS APP VERSION ENVIRONMENT# nginx-abc 1/1 Running nginx v1.25 production# nginx-def 1/1 Running nginx v1.26 staging6.3 Label审计——你的标签合规吗# 找出没有app标签的Pod常见疏漏kubectl get pods-l!app-A# 找出既没有environment也没有tier标签的Podkubectl get pods-l!environment,!tier-A# 检查特定标签是否有非法值kubectl get pods-lenvironment notin (production,staging,development)-A要点随着集群里的Pod越来越多Label的混乱是必然的。建议定期跑上述审计命令确保标签合规。你也可以把这些检查写成CI/CD Pipeline的一步——每次部署前检查Label规范。本篇小结Label是K8s里小身材大能量的典型代表本质就是KV对没有任何预定义Schema你想贴什么就贴什么——但自由不等于任性选择器分两种等值选择器/!/in/notin简单直观集合选择器exists/doesnotexist更灵活但语法复杂推荐规范app.kubernetes.io/name、app.kubernetes.io/version等六大推荐标签是社区公认的最佳实践值得遵守灰度发布和AB测试全靠Label区分不同版本的Pod再通过Service的Selector和负载规则分配流量——Label是灵活编排的地基下一篇咱们聊Namespace——如果说Label是给你的资源打标签那Namespace就是给你的集群划地盘。上一篇【第09篇】Pod的YAML从入门到精通——每个字段都是干什么的下一篇【第11篇】Namespace——给你的K8s集群划地盘