K8s多租户特性未来展望：HNC会成为多租户的标准吗？
作者：ÁNGEL BARRERA SÁNCHEZ
译者：王御林
Hierarchical Namespace Controller (HNC) 将会带来一种更好的k8s多租户模型。这篇文章将要探索这个项目的当前状态以及一些有用的落地场景。
Hierarchical Namespace Controller (HNC) 是google公司为了改善k8s多租户体验所驱动的一个项目。到今天为止，k8s的资源由集群级别的资源(namespace)来组织。遗憾的是，安全地将不同用户托管到同一集群中需要高度的自动化知识。HNC通过传递“parent namespace” 的配置到所属的”child namespace”的思路，尝试弥补这一遗憾。
Hierarchical namespaces 通过创建功能强大的namespace从而使你的集群管理更加容易。例如，你能在你所属团队的team namespace下创建另外的“child namespace”,即使你没有创建集群级别的namespace的权限。这将很轻松的应用策略例如RBAC/Network Policies到你的team namespace下的所有的child namespace 中。
摘自：multi-tenancy sig repository（https://github.com/kubernetes-sigs/multi-tenancy/tree/hnc-v0.5.1/incubator/hnc）
我们测试了HNC最新的版本(0.5.1), 可以看到很多有价值的东西。不幸的是，开发工作最近才开始，尽管社区已经讨论了很长时间。
HNC 在今年应该还不能被正式使用。
准备开始
你必须拥有一个 Kubernetes 的集群，同时你的 Kubernetes 集群必须带有 kubectl 命令行工具。如果你还没有集群，你可以通过 Minikube 构建一个你自己的集群。
开始
感谢HNC 幕后团队出色的工作，使得hnc已经可以在本地开发和测试，并且是如此的easy!
| 1 2 3 4 5 6 7 | $ kubectl apply -f https://github.com/kubernetes-sigs/multi-tenancy/releases/download/hnc-v0.5.1/hnc-manager.yaml $ curl -L https://github.com/kubernetes-sigs/multi-tenancy/releases/download/hnc-v0.5.1/kubectl-hns -o ./kubectl-hns $ chmod +x ./kubectl-hns $ export PATH=${PWD}:${PATH} |
注意：国内用户拉取google的镜像可能有点麻烦，可以将
gcr.io/k8s-staging-multitenancy/hnc/controller:v0.5.1 替换成：luohua13/hnc-controller
gcr.io/kubebuilder/kube-rbac-proxy:v0.4.0 替换成：luohua13/kube-rbac-proxy
然后你可以开始测试：
13 14 15 16 17 18 19 20 21 22 23 24 25 | $ kubectl create ns hnc-parent namespace/hnc-parent created $ kubectl create ns hnc-child-1 namespace/hnc-child-1 created $ kubectl create ns hnc-child-2 namespace/hnc-child-2 created $ kubectl hns set hnc-child-1 -p hnc-parent Setting the parent of hnc-child-1 to hnc-parent Succesfully updated 1 property of the hierarchical configuration of hnc-child-1 $ kubectl hns set hnc-child-2 -p hnc-parent Setting the parent of hnc-child-2 to hnc-parent Succesfully updated 1 property of the hierarchical configuration of hnc-child-2 $ kubectl hns tree -A default hnc-parent ├── hnc-child-1 └── hnc-child-2 hnc-system kube-node-lease kube-public kube-system local-path-storage |
默认情况下， parent namespace下的所属的Role 和 RoleBinding 对象会传递给 child 命名空间对象。
| 1 2 3 | $ kubectl create role pod-reader --verb=get --verb=list --verb=watch --resource=pods -n hnc-parent role.rbac.authorization.k8s.io/pod-reader created |
所以，让我们验证下 hnc-child-{1,2} 命名空间下是否能看到相同的 role：
| 1 2 3 4 5 6 7 | $ kubectl get role -n hnc-child-1 --show-labels NAME CREATED AT LABELS pod-reader 2020-08-24T08:13:00Z hnc.x-k8s.io/inheritedFrom=hnc-parent $ kubectl get role -n hnc-child-2 --show-labels NAME CREATED AT LABELS pod-reader 2020-08-24T08:13:00Z hnc.x-k8s.io/inheritedFrom=hnc-parent |
怎么样？够酷炫吧！它能满足我们很多年梦寐以求的使用场景。
使用案例
kubernetes 是 SIGHUP 业务的核心部分。我们在很多大规模的公司工作，因为k8s没有多租户特性使我们遇到了很多难以解决的挑战。
在这篇文章中将展示 HNC 两种不同的使用案例。
Namespace自给（self provisioning）
有时开发者为了开发的工作需要创建新的 namespace。因为 namespace是集群级别的对象，集群管理员需要赋予开发者相应的权限。在赋予创建 namespace的权限之后，你（作为集群管理员）可能还想附加一些默认的配置，例如：
NetworkPolicies
Roles and RoleBindings
ResourceQuotas
LimitRanges
否则，你将很快面临一个混乱的集群。那么你该怎么办呢？
HNC 能满足这个使用场景。你可以定义一个 parent 命名空间，所有的对象在 其 child 命名空间下， 并且不要去手动传递对象。换句话说，就是开发者不需要有任何的集群级别权限。使用 HNC时，你需要被赋予在 parent命名空间下管理 child命名空间的权限。
应用模版
Frontend
Backend
DB
如果你要开发一个新的 Frontend feature，你能受益于有一个完整的 Backend 模版，用来在一个稳定和隔离的环境来测试你的 Frontend change!
在这个案例中，你可以在 parent 命名空间下定义如下公有的应用组件：
DB Deployments and Services
Backend Deployments and Services
Frontend Services
重要提示： 不要把 frontend deployment 放在parent 命名空间中。你需要的修改不应该在 parent 命名空间
然后创建一个 child 命名空间，将你修改的frontend deployment 放在这个命名空间下。
关于这个场景如果你想了解更多，follow our guide（https://github.com/sighupio/hnc-example-use-cases/blob/master/use-cases/application-template/README.md）
结论
HNC尝试去弥补k8s多租户特性缺失的遗憾。这个underlying的想法是一个足够好的出发点。它需要更多来自社区的爱和众多开发者的反馈。
下面是一些我们正在积极提的的issues和features:
将 HNCConfiguration 对象从集群级别(cluster-level)的资源转换为（parent）命名空间范围（namespace scope）的配置。另一种做法是保留集群级别的HNCConfiguration同时开发一种命名空间范围的 HNCConfiguration。
如果 child 命名空间中的对象和 parent 命名空间中的对象重名，则使 child 命名空间中的同名对象无效。假定你在child 命名空间定义一个名为developer的 RBAC Role, 如果你在 parent 命名空间设置了一个同名的 Role, parent 命名空间的 Role 就应该覆盖掉 child 命名空间的 Role。
Fix 掉 parent命名空间和 child 命名空间传递集群级别的数据和属性（不可重复）时候出现的一些问题。举个栗子：Service 对象就不能被传递，因为 HNC 会复制 Service 对象的每个属性到 child 命名空间，包括 spec.ClusterIP （集群中的唯一数据）。
你可以通过加入 google 多租户特性工作组
（https://github.com/kubernetes/community/blob/master/wg-multitenancy/README.md）, 来及时了解 HNC 的开发过程。
结尾
SIGHUP 把 HNC 捐献出去的兴趣是非常浓厚的，因为很有可能在未来成为标准。在讨论这项评估期间，有很多基于k8s实现多租户特性的替代品，但是，它仍将很快在未来的某个时间点成为一个标准。
不要忘了访问我们的网站，诸如:
https://sighup.io/
https://github.com/sighupio
以及本文中所有材料的来源：
https://github.com/sighupio/hnc-example-use-cases
原文链接：
Hierarchical Namespace Controller (HNC): a look into the future of Kubernetes Multitenancy
加入云原生技术交流群，或报名社区志愿者，
请加小助手微信：horizon96 或 fudan3070 详询！！
活动推荐：
扫图上二维码了解大会信息和报名👆👆
11月19-21日CNBPS 2020将全新启动！
作为国内最有影响力的云原生盛会之一，
至今已举办三届。
大会将诠释云原生的升维定义--云原生全栈。
了解云原生趋势和最佳实践，
来这一场就够了！