📚 课程目录第4章项目与命名空间自助管理

4. 项目与命名空间自助管理

在 OpenShift 中，项目（Project）是面向开发者的自助服务入口，它在底层对应一个 Kubernetes 命名空间（Namespace），但额外附加了权限、配额、注解和生命周期管理能力。理解“项目 = 命名空间 + 自助管理语义”这一层关系，是掌握资源隔离与团队协作的起点。开发者无需集群管理员介入，即可通过 oc new-project 或 Web 控制台创建项目，并自动成为该项目的 admin 角色成员。

创建项目时，OpenShift 会执行一系列自动化动作：生成命名空间对象、绑定默认的 admin、edit、view 角色到创建者、附加默认的 LimitRange 与 ResourceQuota（若集群启用了默认模板）、并注册项目元数据。下面这张图展示了从开发者发起请求到项目可用的完整对象关系与资源隔离边界。

创建项目与初始配置

使用命令行创建项目非常直接：

oc new-project my-app-dev \
  --description="订单服务开发环境" \
  --display-name="订单服务-开发"

执行后，OpenShift 会返回项目概览，并自动将当前上下文切换到新项目。此时创建者被绑定为 admin，拥有该命名空间内除配额调整外的绝大部分管理权限。若集群管理员配置了默认项目模板，新项目还会自动附带一组初始的 ResourceQuota 和 LimitRange，例如限制总 CPU 请求为 4 核、内存 8Gi，并为未声明资源的 Pod 设置默认请求值。

配额与限制范围的分工

很多初学者容易混淆 ResourceQuota 和 LimitRange。两者的作用层级不同：

ResourceQuota 作用于整个命名空间，限制该空间内所有 Pod、Service、PVC 等对象的总量或资源请求/限制之和。例如 requests.cpu: "4" 表示该命名空间内所有 Pod 的 CPU 请求总和不得超过 4 核。一旦超出，新的 Pod 创建会被拒绝。
LimitRange 作用于单个 Pod 或容器，定义默认的 requests/limits 以及允许的最小/最大值。例如 default.cpu: 500m 表示如果 Pod 没有显式声明 CPU 请求，则自动注入 500m；max.cpu: "2" 表示单个容器 CPU 上限不得超过 2 核。

两者配合使用，才能既控制总量，又规范单个工作负载的资源声明。下面是一个典型的配额与限制范围配置示例：

apiVersion: v1
kind: ResourceQuota
metadata:
  name: dev-quota
spec:
  hard:
    requests.cpu: "4"
    requests.memory: 8Gi
    limits.cpu: "8"
    limits.memory: 16Gi
    pods: "20"
    services: "10"
---
apiVersion: v1
kind: LimitRange
metadata:
  name: dev-limits
spec:
  limits:
  - type: Container
    default:
      cpu: 500m
      memory: 512Mi
    defaultRequest:
      cpu: 200m
      memory: 256Mi
    max:
      cpu: "2"
      memory: 2Gi
    min:
      cpu: 50m
      memory: 64Mi

应用后，可以通过 oc describe quota -n my-app-dev 查看当前用量与硬限制的对比，通过 oc describe limitrange -n my-app-dev 确认默认值是否生效。

成员角色与权限模型

OpenShift 在命名空间层面提供了三个开箱即用的角色：

角色	权限范围	典型使用者
`admin`	管理命名空间内所有资源，包括角色绑定、配额查看	项目负责人
`edit`	创建、修改、删除工作负载和配置，不能管理角色绑定	开发人员
`view`	只读访问命名空间内大部分资源	测试、审计、观察者

添加成员使用 oc adm policy add-role-to-user：

oc adm policy add-role-to-user edit zhangsan -n my-app-dev
oc adm policy add-role-to-user view lisi -n my-app-dev

移除成员则使用 remove-role-from-user。需要注意的是，这些操作需要当前用户在该命名空间具有 admin 权限，或由集群管理员执行。

资源隔离与生命周期操作

命名空间天然提供了资源隔离：不同项目中的 Pod、Service、ConfigMap 互不可见，网络策略（NetworkPolicy）可以进一步限制跨命名空间的流量。默认情况下，同一集群内不同命名空间的 Pod 可以通过 Service IP 互相访问，但通过 NetworkPolicy 可以实现更严格的隔离。

项目生命周期管理包括日常操作和最终清理：

查看项目状态：oc get projects 列出当前用户可访问的所有项目；oc status 查看当前项目内资源概况。
切换项目：oc project my-app-dev 切换当前上下文。
删除项目：oc delete project my-app-dev 会触发命名空间及其所有资源的级联删除。这是一个不可逆操作，执行前应确认数据已备份或迁移。
归档与回收：在生产实践中，通常先通过 oc get all -o yaml 导出资源清单，再删除项目；部分企业会保留项目元数据用于审计。

注意：删除项目会级联删除该命名空间下的所有资源，包括 PVC 和其中的数据。执行 oc delete project 前，务必确认持久化数据已完成备份或迁移。

实践建议：为每个环境（开发、测试、预发布、生产）创建独立项目，配合不同的配额和限制范围。开发环境可以放宽配额以便快速迭代，生产环境则应设置更严格的 LimitRange 和 NetworkPolicy，避免资源争抢和意外暴露。

通过以上机制，OpenShift 将命名空间从单纯的隔离单元提升为具备自助服务能力的项目：开发者可以自主创建、配置成员、申请资源，而集群管理员则通过配额和限制范围保持对整体资源使用的可控性。这种“自助 + 管控”的平衡，正是 OpenShift 开发者平台的核心价值之一。