3.3 Namespace与Label：分田到户

3.3 Namespace 与 Label：分田到户

本节摘要：Namespace 是集群内的"责任田"边界，把资源按团队或环境分片管理；Label 是贴在资源上的苗牌键值对，配合 Label Selector 实现跨资源的认领与批量操作。两者一纵一横：Namespace 划大块，Label 做精细分组，绿荫书屋的开发与生产环境将按此落位。本节还辨析"同名不同田"与默认命名空间的使用卫生。

为什么一块田要划片

书屋的迁移继续推进：开发同事要在集群里试新功能，测试要一套独立环境，生产跑着正式服务。如果全挤在同一片地里，名字先撞车——两个环境都想叫 greenlib-web；权限也没法分——不能给实习生动生产的权力；配额更没法算——谁也说不清哪部分资源归谁。这三个诉求指向同一个机制：Namespace（命名空间），手册里叫责任田。

责任田的本质是一层"名字的作用域"：每块田里有自己的资源名单，同名资源在不同田里互不干扰。它还顺带成为权限与配额的作用域——第八章 RBAC 的授权、第七章 ResourceQuota 的限额，都天然以田为边界落地。

# 建两块责任田：一块开发 一块生产
kubectl create namespace greenlib-dev
# namespace/greenlib-dev created
kubectl create namespace greenlib-prod
# namespace/greenlib-prod created

kubectl get namespaces
# NAME              STATUS   AGE
# default           Active   60d
# greenlib-dev      Active   12s
# greenlib-prod     Active   8s
# kube-system       Active   60d    集群自家的系统田，别动它
# kube-public       Active   60d
​

# 责任田也可以用清单建（生产环境推荐一切皆清单）
apiVersion: v1
kind: Namespace
metadata:
  name: greenlib-dev
  labels:
    team: greenlib        # 田本身也能贴标签
    env: dev
---
# 把网页种进开发田：在资源 metadata 里写 namespace 即可
apiVersion: apps/v1
kind: Deployment
metadata:
  name: greenlib-web      # 与生产田里的同名也不冲突
  namespace: greenlib-dev
spec:
  replicas: 1             # 开发田种一株就够
  selector:
    matchLabels:
      app: greenlib-web
  template:
    metadata:
      labels:
        app: greenlib-web
    spec:
      containers:
        - name: web
          image: greenlib/web:0.10.0-rc.2   # 开发田试的是候选版本
​

kubectl apply -f dev-web.yaml
kubectl get pods -n greenlib-dev
# NAME                           READY   STATUS    AGE
# greenlib-web-5c8d9b7f4-t2wqk   1/1     Running   40s
# 注意：查苗必须带 -n 指田，不带时查的是 default 田
​

图：一块大田的两级划分

Label：苗牌的学问

Namespace 划的是"大块"，块内还会横向分组：书屋的苗有前台后台之分、有正式候选之分，这些维度不该再靠多建田解决——田会碎片化。**Label（标签）**是贴在任何资源上的键值对苗牌，一个资源可以贴多块牌，查询与操作时用 Label Selector 按牌圈苗：

# 给现成的苗补一块牌（比如标记负责人）
kubectl label pod -n greenlib-prod greenlib-web-7d9b6c5f4-8xzqm owner=lin
# pod/greenlib-web-7d9b6c5f4-8xzqm labeled

# 按牌圈苗：所有后台苗
kubectl get pods -n greenlib-prod -l tier=backend
# NAME              READY   STATUS    AGE
# greenlib-api-...  1/1     Running   3h

# 多条件与排除
kubectl get pods -A -l tier=backend,env!=dev
# -A 表示全田扫描：列出除开发田外的所有后台苗

# Deployment 的 selector 本质就是长期生效的圈苗规则
# Deployment 只认领 selector 匹配的苗，这是第三章反复出现的机制
​

标签体系值得一开始就定好规矩。书屋定的版本是：app（属于哪个应用）、tier（前台还是后台）、env（环境）、owner（负责人）。四个键足够入门期使用，原则是少而稳：键名定了就别改，所有清单统一使用，否则圈苗规则会悄悄漏苗。

两套坐标系的配合

一个容易踩的直觉坑：Namespace 不提供网络隔离。两块田里的苗默认网络互通，"开发田摸不到生产田"要靠网络策略实现，那超出入门范围，但这个边界必须现在讲清，否则会给出错误的安全感。

⚠️ 常见坑：什么东西都往 default 田里堆。default 是公共草地，没有配额约束也没有权限边界，三十个团队混用一块草地，出了事连"这是谁的苗"都查不清。哪怕单人学习，也建议从第一块自己的田开始养成习惯。

常用的标签键惯例

社区沉淀了一些约定俗成的键名，起步照用能省不少沟通成本：app（应用名）、tier（层次，如 frontend 与 backend）、env（环境）、track（轨道，如 stable 与 canary）、owner（负责人）。书屋的四键方案就是从这份惯例里挑的。定键的真正原则只有一条：键要在全团队口径统一，宁可少而稳，不要多而乱。

本节要点回顾

• Namespace 是名字、权限、配额三重作用域，按团队或环境分田
• Label 加 Selector 是跨资源的认领与圈选机制，Deployment 的认苗规则即源于此
• 两套坐标系正交：田管边界，牌管维度，不要用田去模拟维度
• Namespace 不做网络隔离，安全边界要靠网络策略另建
• 绿荫书屋现在有了 dev 与 prod 两块田，后续章节的操作都会注明种在哪块田