组织

命名空间为 Kubernetes 集群中的许多对象限定范围。两个团队都可以创建名为 settings 的 ConfigMap，因为包含命名空间后的完整身份不同。这种组织边界很有价值，但不会自动提供网络隔离、独立内核、专属节点容量或完整租户隔离。工作负载实际需要哪一种保障，就应确认额外由什么政策和执行机制落实，而不是把它们都归因于命名空间。 名称范围取决于资源类型 Pod、Service、ConfigMap 和许多工作负载控制器属于命名空间资源。Node、命名空间本身以及其他集群级资源，则不会因为客户端指定了某个命名空间，就被划分成另一份独立副本。应查看具体资源的 API 范围，不能假定所有对象都住在某个房间里面。命名空间也不是由独立子集群构成的嵌套层级。 在 Pod 内部，服务短名称通常按所在命名空间解析。带限定的名称可以指向别处，例如默认集群域下的 api.other.svc.cluster.local。这种约定负责定位目的地址，并不决定允许还是拒绝连接。集群域也可以另行配置，因此示例中的后缀不是所有安装都必须采用的常量。诊断 DNS 时需要结合实际域和工作负载所在位置。 自动化中的命名空间选择应保持明确。对象名称即使正确，如果当前活动命名空间错误，仍然会访问另一个资源。尤其是修改操作，应有意指定 kubeconfig、上下文和命名空间，而不是依赖操作者终端之前留下的状态。对象范围让身份更清楚，但具有广泛权限的管理员依然能够跨范围修改内容，不能因此省略权限审查。 坏掉的样子 没有适用网络政策的命名空间，仍然按照集群网络本身的行为保持连通。仅创建命名空间，或在 DNS 中加入它的名称，并不会拒绝其他 Pod。网络隔离需要正确的政策，以及真正执行这些政策的网络实现。应用认证还是另一层：域名能解析，只说明找到了地址，并不能证明某个调用者应该获准读取返回内容。 RBAC 则单独控制 API 操作。一个 RoleBinding 可以让账号读取本命名空间的 ConfigMap，而不给它读取其他范围的能力。但权限是叠加的，另一个广泛绑定仍可能授予更多访问。应以目标身份实际验证允许和拒绝的请求，不能认为添加一份较小角色，就自动取消先前更大的授权。网络流量政策也不会代替这一层 API 权限。 ResourceQuota 主要在准入阶段约束对象数量，以及汇总的资源请求或限制等指标。它本身不会节流正在运行的进程，也不会预留物理节点容量。LimitRange 可以为新接纳的工作负载提供默认值和边界，运行时资源限制则由其他机制执行。这些政策都需要明确配置；只有一个命名空间，并不能让会争抢共享资源的邻居自动变得无害。 快速验证 准备使用默认 cluster.local 域的临时 Kubernetes 集群，确保 kubectl 管理员能够执行测试 impersonation，节点已有 python:3.11-slim-bookworm 镜像。把代码保存为 namespaces.py，执行 python3 namespaces.py KUBECONFIG_PATH CONTEXT，明确传入测试配置。实测集群是 Kubernetes 1.34.11，采用 kind 网络。脚本创建两个唯一命名空间，并在结束后删除两者。 ...