命名空间与访问控制Part 1Namespace 与资源配额概念引入想象一个大型写字楼。每层楼是一家公司公司之间互不干扰——A 公司不会占 B 公司的会议室B 公司的员工也不会跑进 A 公司的办公区。Namespace 就是 K8s 集群里的楼层。它把同一个集群划分成多个虚拟隔离区每个区域有自己的资源、权限和命名空间。K8s 集群一栋写字楼Namespace: prod8 楼Deployment: webService: web-svcNamespace: staging5 楼Deployment: webService: web-svcNamespace: dev3 楼Deployment: webService: web-svc不同 Namespace 里的资源名字可以相同互不影响为什么需要 Namespace场景没有 Namespace有 Namespace开发/测试/生产隔离全混在一起误操作风险大每个环境独立互不干扰团队资源分配一个团队可能占光所有资源用配额限制每个团队的资源上限权限管理所有人能操作所有资源每个团队只能操作自己的 Namespace原理讲解默认 NamespaceK8s 创建集群时自带几个 Namespacekubectl get namespaceNamespace用途default不指定 Namespace 时资源默认创建在这里kube-systemK8s 系统组件kube-proxy、CoreDNS 等kube-public公开可读的资源如集群信息 ConfigMapkube-node-lease节点心跳数据最佳实践永远不要把你的应用部署到kube-system也不要什么都塞在default里。为每个项目或环境创建专用 Namespace。ResourceQuota限制楼层的资源配额如果每层楼的用电不限量一家公司开 100 台服务器整栋楼就跳闸了。ResourceQuota 就是每层楼的用电限额。Namespace: dev限制限制拒绝创建ResourceQuotaCPU ≤ 4 核内存 ≤ 8GiPod ≤ 10 个Pod: 1 核 / 2GiPod: 1 核 / 2GiPod: ❌ 超出配额ResourceQuota 可以限制计算资源CPU、内存的总量对象数量Pod、Service、ConfigMap 的最大数量存储PVC 的总容量LimitRange限制单个 Pod 的资源ResourceQuota 管的是整层楼的总额但不管单个 Pod 用多少。LimitRange 管的是每个房间的用电上限——确保没有单个 Pod 占光整个 Namespace 的配额。Namespace: devpods检查检查拒绝Pod A: 0.5 核 ✅LimitRange每个 Pod 最多 2 核 / 4Gi每个 Pod 至少 0.1 核 / 128MiPod B: 2 核 ✅Pod C: 3 核 ❌ResourceQuota vs LimitRange维度ResourceQuotaLimitRange管什么整个 Namespace 的总量单个 Pod/容器的上下限类比楼层总用电额度每个房间的用电上限典型用途限制团队总资源防止单个 Pod 占光配额可以一起用✅ 推荐组合使用✅ 推荐组合使用动手实验配套实验位于docs/labs/beginner/namespace/步骤 1创建 Namespacekubectl create namespace dev kubectl create namespace staging# 查看kubectl get namespace步骤 2在 Namespace 中部署应用# 同一个名字不同 Namespace互不冲突kubectl create deployment web--imagenginx:1.27-ndev kubectl create deployment web--imagenginx:1.27-nstaging# 查看两个 Namespace 的 Podkubectl get pods-ndev kubectl get pods-nstaging# 跨 Namespace 查看所有 Podkubectl get pods --all-namespaces|grepweb步骤 3设置 ResourceQuotakubectl apply-f-EOF apiVersion: v1 kind: ResourceQuota metadata: name: dev-quota namespace: dev spec: hard: requests.cpu: 2 requests.memory: 4Gi limits.cpu: 4 limits.memory: 8Gi pods: 5 EOF# 查看配额使用情况kubectl describe resourcequota dev-quota-ndev# 清理kubectl delete deployment web-ndev kubectl delete deployment web-nstaging步骤 4测试配额限制⚠️kubectl run不支持直接设置requests需要用 YAML 声明。# 创建 5 个 Pod配额上限foriin$(seq15);dokubectl apply-f-EOF apiVersion: v1 kind: Pod metadata: name: test-$inamespace: dev spec: containers: - name: app image: busybox command: [sleep, 3600] resources: requests: cpu: 100m memory: 128Mi limits: cpu: 200m memory: 256Mi restartPolicy: Never EOFdone 因为 ResourceQuota 中包含了limits.cpu和limits.memory所以每个 Pod必须同时指定limits否则会被直接拒绝。验证配额使用量kubectl describe resourcequota dev-quota-ndev kubectl get pods-ndev# 第 6 个会被拒绝kubectl apply-f-EOF apiVersion: v1 kind: Pod metadata: name: test-6 namespace: dev spec: containers: - name: app image: busybox command: [sleep, 3600] resources: requests: cpu: 100m memory: 128Mi limits: cpu: 200m memory: 256Mi restartPolicy: Never EOF# 预期Error from server (Forbidden): exceeded quota步骤 5设置 LimitRange# 清理创建的 5 个 Podforiin$(seq15);dokubectl delete pod test-$i-ndevdonekubectl apply-f-EOF apiVersion: v1 kind: LimitRange metadata: name: dev-limits namespace: dev spec: limits: - default: # 默认 limit cpu: 500m memory: 256Mi defaultRequest: # 默认 request cpu: 100m memory: 128Mi max: # 单个 Pod 上限 cpu: 2 memory: 1Gi min: # 单个 Pod 下限 cpu: 50m memory: 64Mi type: Container EOF# 验证创建不指定资源的 Pod看 LimitRange 是否自动填充kubectl run auto-limit--imagebusybox--restartNever-ndev kubectl get pod auto-limit-ndev-ojsonpath{.spec.containers[0].resources}预期输出{limits:{cpu:500m,memory:256Mi},requests:{cpu:100m,memory:128Mi}}步骤 6清理kubectl delete namespace dev 删除 Namespace 会级联删除其中所有资源慎用Part 2RBAC 权限管理概念引入有了 Namespace 隔离资源但谁能操作哪些 Namespace 里的资源还需要控制。这就是 RBAC 的工作。想象一家公司的门禁系统工牌ServiceAccount标识你是谁权限卡Role规定你能做什么如只能看 3 楼的会议室门禁绑定RoleBinding把权限卡绑定到你的工牌上全楼通行证ClusterRole跨楼层跨 Namespace的权限K8s 的 RBACRole-Based Access Control就是这套门禁系统。它控制谁能对哪些资源做什么操作。请求关联引用检查权限允许或拒绝ServiceAccount工牌我是谁Role权限卡能做什么RoleBinding绑定把卡给谁API Server门禁闸机✅ 允许 / ❌ 拒绝原理讲解四个核心概念概念作用范围类比ServiceAccount标识身份Namespace 级别工牌Role定义权限能做什么Namespace 级别楼层权限卡ClusterRole定义权限能做什么全集群全楼通行证RoleBinding把 Role 绑定给 SANamespace 级别把卡发给某人的工牌ClusterRoleBinding把 ClusterRole 绑定给 SA全集群发全楼通行证集群级别Namespace: dev主体角色主体角色ServiceAccount: dev-saRole: pod-readerget/list/watch podsRoleBindingClusterRole: node-viewerget/list nodesClusterRoleBindingRBAC 的权限动词动词含义示例get获取单个资源kubectl get pod nginxlist列出资源列表kubectl get podswatch监听资源变化kubectl get pods -wcreate创建资源kubectl create podupdate修改资源kubectl edit podpatch部分修改kubectl patch poddelete删除资源kubectl delete pod最小权限原则⚠️只给需要的权限不多不少。场景❌ 过度授权✅ 最小权限应用只需要读 ConfigMapverbs: [*]verbs: [get, list]只在 dev Namespace 操作ClusterRoleBindingRoleBinding只需要操作特定 Podresources: [pods]无 resourceName加resourceNames: [my-pod]默认 ServiceAccount每个 Namespace 自动有一个defaultServiceAccount。如果你不指定Pod 就用它。但这个 SA 几乎没有权限——这是安全设计。# 查看默认 SAkubectl get serviceaccount-ndefault kubectl describe serviceaccount default动手实验配套实验位于docs/labs/beginner/rbac/步骤 1创建 ServiceAccount 和权限cddocs/labs/beginner/rbacbashsetup.sh步骤 2用受限身份访问 API 用kubectl --as模拟指定 ServiceAccount 的身份来测试权限。# ✅ 可以读 Podkubectl--assystem:serviceaccount:dev:readonly-sa get pods-ndev# ❌ 不能创建 Podkubectl--assystem:serviceaccount:dev:readonly-sa runtest--imagenginx-ndev# 预期Error from server (Forbidden)# ❌ 不能删除 Podkubectl--assystem:serviceaccount:dev:readonly-sa delete pod--all-ndev# 预期Error from server (Forbidden)ℹ️关于kubectl create token如果你需要给外部程序一个真实的 token如 CI/CD 用的 kubeconfig可以用kubectl create token readonly-sa -n dev生成。但用kubectl --token$TOKEN来测试权限不可靠——如果你的 kubeconfig 同时有 client 证书如 Kind证书认证的优先级高于 tokenRBAC 限制不会生效。测试权限用--as才准确。步骤 3查看 ClusterRole 和 ClusterRoleBinding# 查看集群内置的 ClusterRolekubectl get clusterrole|head-20# 查看 cluster-admin超级管理员绑定了谁kubectl get clusterrolebinding|grepcluster-admin步骤 4清理bashteardown.sh自检问题Namespace 和集群是什么关系删除 Namespace 会发生什么查看答案 Namespace 是集群内的**虚拟隔离区**共享同一个集群的物理资源但逻辑上互不干扰。删除 Namespace 会**级联删除**其中所有资源Pod、Service、ConfigMap 等且不可恢复。ResourceQuota 和 LimitRange 的区别是什么查看答案 ResourceQuota 限制**整个 Namespace 的资源总量**如总共 4 核 CPULimitRange 限制**单个容器的资源上下限**如每个容器最多 2 核。只用 ResourceQuota 不够——如果没有 LimitRange一个 Pod 可能申请走整个 Namespace 的配额导致其他 Pod 无法创建。推荐组合使用。Role 和 ClusterRole 的区别是什么什么时候用哪个查看答案 **Role** 只在单个 Namespace 内有效定义该 Namespace 内的权限。**ClusterRole** 在全集群范围有效可以访问所有 Namespace 的资源以及集群级资源如 Node、PV。当你的权限只涉及一个 Namespace 时用 Role需要跨 Namespace 或访问集群级资源时用 ClusterRole。不推荐把所有权限都绑定到 default ServiceAccount 上为什么查看答案 default SA 被该 Namespace 内所有不指定 SA 的 Pod 共享。如果给 default SA 过大权限意味着所有 Pod 都拥有这些权限——一个被入侵的 Pod 就能操作其他 Pod 的资源。应该为每个应用创建专用 SA只给最小权限。下一步资源隔离和权限管理搞定了。接下来让你的应用学会自我体检→ 07. 健康检查与资源管理本文来自 K8s Guide—— 开源免费的 Kubernetes 中文学习指南️ 初学者轨道 面试轨道从零基础到拿 Offer 一站式覆盖 每篇文章配套 Kind 实验脚本本地一键运行 本文源码docs/beginner/11-namespace.md / docs/beginner/14-rbac.md⭐如果对你有帮助欢迎 Stargithub.com/callmebg/k8s-guide