1.1 命名空间概念与集群资源隔离
Kubernetes 命名空间（Namespace）是集群内实现逻辑隔离的核心机制。它并非物理或网络层面的硬隔离，而是通过资源对象的作用域限定与访问控制策略，将单个物理集群划分为多个虚拟集群。理解命名空间是掌握 Kubernetes 安全权限配置的第一步。
1.1.1 命名空间的核心作用
命名空间主要解决以下三类问题：
- 资源组织与分组：将同一团队、项目或环境（如 dev、staging、prod）的资源归入同一命名空间，避免命名冲突。
- 访问控制边界：结合 RBAC（基于角色的访问控制），为不同命名空间设置独立的权限策略，实现最小权限原则。
- 资源配额管理：通过 ResourceQuota 和 LimitRange 限制命名空间内的 CPU、内存、存储等资源总量，防止单个应用耗尽集群资源。
关键认知：命名空间是 Kubernetes 安全模型的第一道隔离边界。默认情况下，Pod 可以跨命名空间访问 Service（通过 DNS 名称），但 RBAC 策略、NetworkPolicy 和 ResourceQuota 均以命名空间为作用单位。
1.1.2 默认命名空间与特殊命名空间
Kubernetes 集群在创建时会自动生成以下四个命名空间：
| 命名空间名称 | 类型 | 主要用途 |
|---|---|---|
default |
用户默认 | 未指定命名空间时资源默认创建于此；生产环境建议显式指定命名空间 |
kube-system |
系统核心 | 运行控制平面组件（kube-apiserver、etcd、scheduler、controller-manager）及 CoreDNS 等 |
kube-public |
公共可读 | 所有用户（包括未认证用户）均可读取；通常存放集群公共信息，如集群 CA 证书 |
kube-node-lease |
节点心跳 | 存储节点心跳 Lease 对象，用于节点健康检测（Kubernetes v1.13+） |
安全警示：切勿在
kube-system 命名空间中部署用户应用。该命名空间拥有集群最高权限，误操作可能导致控制面崩溃。生产集群应通过 RBAC 限制普通用户对 kube-system 的写权限。
1.1.3 命名空间与集群资源隔离的关系
命名空间提供的隔离是多维度的，下表总结了不同资源类型的隔离行为：
| 资源类型 | 隔离范围 | 跨命名空间访问 | 安全影响 |
|---|---|---|---|
| Pod / Deployment / StatefulSet | 命名空间内 | 不允许直接访问 | Pod 名称仅在命名空间内唯一 |
| Service | 命名空间内 | 允许通过 <svc>.<ns>.svc.cluster.local 访问 |
需配合 NetworkPolicy 限制流量 |
| ConfigMap / Secret | 命名空间内 | 不允许直接引用 | 敏感数据隔离的关键机制 |
| PersistentVolumeClaim | 命名空间内 | 不允许跨命名空间绑定 | 存储隔离，防止数据泄露 |
| RBAC Role / RoleBinding | 命名空间内 | 仅作用于本命名空间 | 实现细粒度权限控制 |
| NetworkPolicy | 命名空间内 | 可设置跨命名空间规则 | 默认允许所有流量，需显式声明 |
| ResourceQuota / LimitRange | 命名空间内 | 不适用 | 防止资源争抢 |
以下 SVG 图展示了命名空间在集群中的逻辑位置及其与核心资源的关系：
1.1.4 命名空间操作实践
以下命令展示了命名空间的基本操作，这些操作是后续安全配置的基础：
# 查看所有命名空间
kubectl get namespaces
# 创建命名空间（方式一：命令式）
kubectl create namespace team-alpha
# 创建命名空间（方式二：声明式，推荐）
cat <<EOF | kubectl apply -f -
apiVersion: v1
kind: Namespace
metadata:
name: team-alpha
labels:
environment: development
team: alpha
EOF
# 在指定命名空间中创建资源
kubectl run nginx --image=nginx --namespace=team-alpha
# 切换默认命名空间上下文（避免每次指定 --namespace）
kubectl config set-context --current --namespace=team-alpha
# 查看当前上下文使用的命名空间
kubectl config view --minify | grep namespace:
最佳实践：始终使用声明式方式（YAML 文件）创建命名空间，并在
metadata.labels 中添加环境、团队、项目等标签。这些标签后续可用于 NetworkPolicy 选择器、成本分摊和审计报告。
1.1.5 命名空间隔离的局限性
理解命名空间的隔离边界同样重要，以下资源不受命名空间隔离：
- ClusterRole / ClusterRoleBinding：集群级别的 RBAC 资源，作用于所有命名空间。
- Node：节点是集群资源，不属于任何命名空间。
- PersistentVolume：PV 是集群资源，PVC 才是命名空间级别的。
- StorageClass：存储类定义是集群范围的。
- CustomResourceDefinition (CRD)：CRD 定义是集群范围的，但 CRD 实例可以限定在命名空间内。
以下 SVG 图展示了命名空间隔离的边界与例外：
安全陷阱：不要认为命名空间提供了网络隔离。默认情况下，Pod 可以通过 Service DNS 跨命名空间访问。真正的网络隔离需要额外配置 NetworkPolicy，且集群必须使用支持 NetworkPolicy 的 CNI 插件（如 Calico、Cilium、Weave Net）。