首页 » K8s » 第8章 命名空间与权限

第8章 命名空间与权限

　
评论关闭　3次浏览

本章目录（点击跳转）：

本章目标：理解 Namespace 的资源隔离与配额（ResourceQuota / LimitRange），掌握 RBAC 四大对象（ServiceAccount、Role、ClusterRole、Binding），能给不同团队/应用配上"最小权限"。

8.1 Namespace（命名空间）

Namespace 是集群内的逻辑隔离：同一个集群里划出多个"房间"，资源名在各自房间里独立。

典型用法：

default/      默认房间（测试用的东西别放这）
kube-system/  K8s 自己的组件（别动！）
dev/          开发环境
test/         测试环境
prod/         生产环境
team-a/       按团队划分

8.1.1 基本操作

# 创建
kubectl create namespace dev

# 在指定 namespace 里操作（三种方式）
kubectl apply -f web-deploy.yaml -n dev
kubectl get pods -n dev
kubectl config set-context --current --namespace=dev   # 设默认 ns，以后免写 -n

# 查看所有 namespace
kubectl get ns
kubectl get pods -A          # 所有 ns

# 删除（会删除 ns 内所有资源，危险操作）
kubectl delete namespace dev

8.1.2 带标签创建（配合后续调度）

kubectl create namespace staging \
  --labels=env=staging,team=infra
kubectl get ns --show-labels

8.2 ResourceQuota：给命名空间"定量"

防止某个团队/环境把整个集群资源吃光：

# quota-dev.yaml
apiVersion: v1
kind: ResourceQuota
metadata:
  name: dev-quota
  namespace: dev
spec:
  hard:
    requests.cpu: "4"          # 该 ns 下所有 Pod 的 CPU requests 总和 ≤ 4 核
    requests.memory: 8Gi
    limits.cpu: "8"
    limits.memory: 16Gi
    pods: "30"                 # 最多 30 个 Pod
    services: "10"
    persistentvolumeclaims: "10"
kubectl apply -f quota-dev.yaml
kubectl get resourcequota -n dev

# 超额体验：在 dev 里建一个 requests 10 核的 Pod → 直接被拒绝
# 报错： exceeded quota: dev-quota, requested: requests.cpu=10

8.3 LimitRange：给"单个容器"定默认值

ResourceQuota 管总量，LimitRange 管个体——比如"这个 ns 里任何容器不写 requests/limits 时，默认给多少"：

# limitrange-dev.yaml
apiVersion: v1
kind: LimitRange
metadata:
  name: dev-limits
  namespace: dev
spec:
  limits:
    - type: Container
      default:              # 不写 limits 时的默认值
        cpu: 500m
        memory: 512Mi
      defaultRequest:       # 不写 requests 时的默认值
        cpu: 100m
        memory: 128Mi
      max:                  # 单个容器上限
        cpu: "2"
        memory: 4Gi
      min:                  # 单个容器下限
        cpu: 10m
        memory: 16Mi
kubectl apply -f limitrange-dev.yaml
# 在 dev 里建一个没写 resources 的 Pod：
kubectl run demo2 --image=nginx:1.27 -n dev
kubectl describe pod demo2 -n dev | grep -A6 "Limits"
# 会发现 requests/limits 被自动填上了默认值
kubectl delete pod demo2 -n dev

生产建议：quota + limitrange 一起配，再要求所有 Deployment 显式写 resources。

8.4 ServiceAccount（服务账号）

  • 人通过 kubeconfig + RBAC 操作集群；
  • Pod 里的程序如果要调 K8s API（比如查自己的配置、动态发现服务），就得用 ServiceAccount（SA）。

每个 Pod 默认绑定 default SA。SA 的凭证会以 token 形式挂载进容器：

kubectl get sa -n default
# 看 Pod 里挂载的 token（1.24+ 是投影卷，路径固定）
kubectl exec -it <pod> -- cat /var/run/secrets/kubernetes.io/serviceaccount/token

创建专用 SA 并绑定到工作负载：

apiVersion: v1
kind: ServiceAccount
metadata:
  name: web-sa
  namespace: dev
---
# 在 Deployment 的 spec 里：
# spec:
#   template:
#     spec:
#       serviceAccountName: web-sa

8.5 RBAC：Role、ClusterRole、Binding

RBAC 四件套：

对象 作用域 说明
Role 单命名空间 定义"能对这个 ns 里的哪些资源做什么"
ClusterRole 全集群 定义集群级权限（或作为模板）
RoleBinding 单命名空间 把 Role 授予谁（User/Group/SA），在这个 ns 生效
ClusterRoleBinding 全集群 把 ClusterRole 授予谁，全集群生效

核心原则：最小权限——只给完成任务需要的最小权限。

8.5.1 示例：让 dev 团队的 SA 只能读 dev 的 Pod

# rbac-demo.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: pod-reader
  namespace: dev
rules:
  - apiGroups: [""]          # 核心组（pod、svc 等）
    resources: ["pods"]
    verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: pod-reader-binding
  namespace: dev
subjects:
  - kind: ServiceAccount
    name: web-sa
    namespace: dev
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io
kubectl apply -f rbac-demo.yaml
# 验证：用该 SA 的 token 只能 list pod，不能 delete

8.5.2 给"人"授权（User/Group）

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: dev-user-viewer
subjects:
  - kind: User
    name: alice@example.com     # 用户名需与认证方式一致（见下文）
    apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: ClusterRole
  name: view                   # 内置角色：全集群只读
  apiGroup: rbac.authorization.k8s.io

内置 ClusterRole 常用几个：cluster-admin（全部权限，慎给）、admin（ns 内管理员）、edit、view（只读）。

8.5.3 验证权限

# 当前用户能做什么（最实用的命令）
kubectl auth can-i delete pods -n dev
kubectl auth can-i get secrets -A
kubectl auth can-i --list              # 列出当前用户所有权限

# 以某个 SA 的身份验证
kubectl auth can-i list pods --as=system:serviceaccount:dev:web-sa -n dev

8.5.4 用户名从哪来？（认证方式）

RBAC 管的是"授权"，前提是先"认证"。常见认证方式：

  • kubeconfig 证书（minikube/kind 默认）：用户名形如 admin 或 minikube。
  • OIDC（生产主流）：接 Google/Keycloak/GitHub 等，用户名是邮箱。
  • 云厂商 IAM（云上集群）：直接认云账号。
# 看当前身份
kubectl whoami                # 新版 kubectl 支持；或：
kubectl config view --minimize -o jsonpath='{.users[0].name}'

8.6 多租户实践建议（小结式）

  1. 环境隔离：dev / test / prod 各一个 ns，prod 的 quota 单独配。
  2. 每个 ns 配 LimitRange（默认值）+ ResourceQuota（总量）。
  3. 每个应用一个 SA，禁止 Pod 用 default SA 调 API。
  4. 开发只能 view 或 dev ns 的 edit；prod 只给值班角色 edit，cluster-admin 收敛到 2-3 个账号。
  5. 定期审计：kubectl auth can-i --list + 云平台审计日志。

8.7 本章小结

  • Namespace 是逻辑隔离，配合 quota/limitrange 防资源滥用。
  • RBAC 四件套：Role（ns 级规则）、ClusterRole（集群级规则）、两种 Binding（授予）。
  • 最小权限 + kubectl auth can-i 验证，是最实用的两条纪律。

下一章：可观测性与排障——日志、指标、事件一网打尽。

原文链接：第8章 命名空间与权限，转载请注明来源！

赞 0