解决 Kubernetes 多租户难题：HNC 如何实现资源隔离与权限控制-港品优选

解决 Kubernetes 多租户难题：HNC 如何实现资源隔离与权限控制

【免费下载链接】hierarchical-namespacesHome of the Hierarchical Namespace Controller (HNC). Adds hierarchical policies and delegated creation to Kubernetes namespaces for improved in-cluster multitenancy.项目地址: https://gitcode.com/gh_mirrors/hi/hierarchical-namespaces

在 Kubernetes 集群管理中，多租户环境下的资源隔离与权限控制一直是运维团队面临的核心挑战。随着团队规模扩大和业务复杂度提升，传统的命名空间管理方式往往导致权限配置繁琐、资源分配混乱等问题。Hierarchical Namespace Controller（HNC）通过引入命名空间层级结构，为这一难题提供了优雅的解决方案，实现了更精细的资源隔离和更灵活的权限管理。

为什么需要 HNC？传统命名空间的局限性

Kubernetes 的命名空间（Namespace）是实现资源隔离的基础单位，但在多租户场景下存在显著不足：

权限管理繁琐：RBAC 策略需在每个命名空间单独配置，跨命名空间的权限同步困难。例如，为团队成员授予多个命名空间的访问权限时，需手动创建多个 RoleBinding。
资源分配僵化：ResourceQuota 仅作用于单个命名空间，无法实现团队级别的资源总量控制。
命名空间创建权限集中：普通用户需申请集群管理员创建命名空间，缺乏自主性。

HNC 通过将命名空间组织为树形结构，解决了上述痛点。正如 docs/user-guide/concepts.md 所述，HNC 允许命名空间继承父级的策略和资源，同时支持子命名空间的自主管理。

HNC 核心功能：构建层级化的命名空间体系

1. 命名空间层级与继承关系

HNC 引入父/子命名空间概念，形成树状结构（称为“森林”）。每个命名空间可指定一个父命名空间，从而继承其策略和资源。例如：

acme-org ├── team-a │ ├── service-1 │ └── service-2 └── team-b

通过kubectl hns set命令可轻松配置层级关系：

kubectl hns set team-a --parent acme-org kubectl hns set service-1 --parent team-a

层级结构通过 HierarchyConfiguration 自定义资源维护，每个命名空间包含一个名为hierarchy的配置对象，定义其父级和子级关系。

2. 策略自动传播：简化权限与配置管理

HNC 支持对象自动传播，父命名空间中的 RBAC 角色、Secret、ConfigMap 等资源会自动复制到子命名空间。例如，在team-a中创建的 RoleBinding 会被传播到service-1和service-2：

# 在 team-a 创建角色和绑定 kubectl -n team-a create role team-sre --verb=update --resource=deployments kubectl -n team-a create rolebinding team-sres --role team-sre --serviceaccount=team-a:default # 在 service-1 中验证传播结果 kubectl -n service-1 get rolebindings

默认情况下，HNC 传播 RBAC 资源，可通过 HNCConfiguration 扩展支持其他类型（如 Secret、NetworkPolicy）：

kubectl hns config set-resource secrets --mode Propagate

3. 子命名空间： delegated 命名空间创建

HNC 允许普通用户通过子命名空间（Subnamespace）创建命名空间，无需集群管理员权限。子命名空间的生命周期与其父命名空间绑定，删除父命名空间时子命名空间也会被自动清理：

# 在 team-a 下创建子命名空间 service-3 kubectl hns create service-3 -n team-a # 查看层级结构 kubectl hns tree team-a

子命名空间在层级树中以[s]标识，如[s] service-3，表示其由 HNC 管理而非直接通过kubectl create namespace创建。

4. 层级资源配额（HRQ）：跨命名空间资源管控

HNC 提供HierarchicalResourceQuota（HRQ），允许为整个命名空间树设置资源总量限制。例如，限制acme-org及其所有子命名空间的服务总数不超过 5 个：

apiVersion: hnc.x-k8s.io/v1alpha2 kind: HierarchicalResourceQuota metadata: name: acme-org-hrq namespace: acme-org spec: hard: services: 5

HRQ 通过自动创建子命名空间的 ResourceQuota 实现限制，确保资源使用不超出父级配额。可通过kubectl get hrq查看配额使用情况：

kubectl get hrq -n acme-org

实战案例：构建多团队隔离环境

场景：企业级多团队资源隔离

某公司需要为 3 个团队（Team A、Team B、Team C）提供独立的 Kubernetes 环境，同时共享部分基础配置（如监控 Secret），并限制每个团队的资源使用。

1. 创建根命名空间与层级结构

# 创建根命名空间 kubectl create namespace company-root # 创建团队子命名空间 kubectl hns create team-a -n company-root kubectl hns create team-b -n company-root kubectl hns create team-c -n company-root

2. 配置跨团队共享资源

# 在根命名空间创建共享 Secret kubectl -n company-root create secret generic monitoring-creds --from-literal=token=abc123 # 配置 HNC 传播 Secret kubectl hns config set-resource secrets --mode Propagate

3. 设置团队资源配额

# 为 Team A 设置资源配额 kubectl apply -f - << EOF apiVersion: hnc.x-k8s.io/v1alpha2 kind: HierarchicalResourceQuota metadata: name: team-a-hrq namespace: team-a spec: hard: cpu: "4" memory: "8Gi" EOF

4. 验证隔离效果

# Team A 无法访问 Team B 的资源 kubectl -n team-a get secrets | grep team-b-secret # 无结果 # 子命名空间继承父级配额 kubectl -n team-a-service-1 describe quota hrq.hnc.x-k8s.io

HNC 最佳实践与注意事项

避免循环依赖：HNC admission controller 会阻止创建循环层级（如 A 是 B 的父级，B 又是 A 的父级），但需注意手动修改时可能出现的冲突。
谨慎使用级联删除：删除包含子命名空间的父命名空间时，需通过--allowCascadingDeletion显式确认，避免误删：
```
kubectl hns set team-a --allowCascadingDeletion kubectl delete subns team-a -n company-root
```
合理规划传播策略：通过传播例外控制敏感资源的传播范围，例如排除特定子命名空间：
```
kubectl annotate secret sensitive-creds -n company-root propagate.hnc.x-k8s.io/treeSelect='!team-c'
```

总结：HNC 如何提升多租户管理效率

HNC 通过层级化命名空间设计，解决了 Kubernetes 多租户环境中的三大核心问题：

简化权限管理：策略自动传播减少 80% 的重复配置工作。
灵活资源分配：HRQ 实现团队级资源总量控制，避免资源滥用。
降低管理门槛：子命名空间允许团队自主管理命名空间，减轻集群管理员负担。

如需进一步探索 HNC 的高级功能，可参考官方文档：

HNC 概念详解
快速入门指南
最佳实践

通过 HNC，运维团队可以更专注于业务需求而非基础设施配置，为企业 Kubernetes 集群的规模化管理提供有力支持。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考

企业官网建设流程全解析