超长干货 | Kubernetes命名空间详解

K8s使用命名空间的概念帮助解决集群中在管理对象时的复杂性问题。在本文中，会讨论命名空间的工做原理，介绍经常使用实例，并分享如何使用命名空间来管理K8s对象。最后，介绍名为projects的Rancher特性是如何构建并扩展命名空间的概念的。

---

本文中，咱们将探索Kubernetes命名空间，它是集群中组织和管理对象的一种方式。

介 绍

Kubernetes集群能够同时管理大量互不相关的工做负载，而组织一般会选择将不一样团队建立的项目部署到共享集群上。随着数量的增长，部署对象经常很快就会变得难以管理，拖慢操做响应速度，而且会增长危险错误出现的几率。

Kubernetes使用命名空间的概念帮助解决集群中在管理对象时的复杂性问题。命名空间容许将对象分组到一块儿，便于将它们做为一个单元进行筛选和控制。不管是应用自定义的访问控制策略，仍是为了测试环境而分离全部组件，命名空间都是一个按照组来处理对象、强大且灵活的概念。

在本文中，咱们会讨论命名空间的工做原理，介绍一些经常使用实例，并分享如何使用命名空间来管理Kubernetes对象。最后，咱们还会介绍一个叫作projects（项目）的Rancher特性，看它是如何构建并扩展命名空间的概念的。

什么是命名空间，为何它很重要？

命名空间（namespace）是Kubernetes提供的组织机制，用于给集群中的任何对象组进行分类、筛选和管理。每个添加到Kubernetes集群的工做负载必须放在一个命名空间中。

命名空间为集群中的对象名称赋予做用域。虽然在命名空间中名称必须是惟一的，可是相同的名称能够在不一样的命名空间中使用。这对于某些场景来讲可能帮助很大。例如，若是使用命名空间来划分应用程序生命周期环境（如开发、staging、生产），则能够在每一个环境中维护利用一样的名称维护相同对象的副本。

命名空间还可让用户轻松地将策略应用到集群的具体部分。你能够经过定义ResourceQuota对象来控制资源的使用，该对象在每一个命名空间的基础上设置了使用资源的限制。相似地，当在集群上使用支持网络策略的CNI（容器网络接口）时，好比Calico或Canal（calico用于策略，flannel用于网络）。你能够将NetworkPolicy应用到命名空间，其中的规则定义了pod之间如何彼此通讯。不一样的命名空间能够有不一样的策略。

使用命名空间最大的好处之一是可以利用Kubernetes RBAC（基于角色的访问控制）。RBAC容许您在单个名称下开发角色，这样将权限或功能列表分组。ClusterRole对象用于定义集群规模的使用模式，而角色对象类型（Role object type）应用于具体的命名空间，从而提供更好的控制和粒度。在角色建立后，RoleBinding能够将定义的功能授予单个命名空间上下文中的具体具体用户或用户组。经过这种方式，命名空间可使得集群操做者可以将相同的策略映射到组织好的资源集合。

常见的命名空间使用模式

命名空间是一种很是灵活的特性，它不强制使用特定的结构或组织模式。不过尽管如此，仍是有许多在团队内常使用的模式。

将命名空间映射到团队或项目上

在设置命名空间时有一个惯例是，为每一个单独的项目或者团队建立一个命名空间。这和咱们前面提到的许多命名空间的特性很好的结合在了一块儿。

经过给团队提供专门的命名空间，你能够用RBAC策略委托某些功能来实现自我管理和自动化。好比从命名空间的RoleBinding对象中添加或删除成员就是对团队资源访问的一种简单方法。除此以外，给团队和项目设置资源配额也很是有用。有了这种方式，你能够根据组织的业务需求和优先级合理地访问资源。

使用命名空间对生命周期环境进行分区

命名空间很是适合在集群中划分开发、staging以及生产环境。一般状况下咱们会被建议将生产工做负载部署到一个彻底独立的集群中，来确保最大程度的隔离。不过对于较小的团队和项目来讲，命名空间会是一个可行的解决方案。

和前面的用例同样，网络策略、RBAC策略以及配额是实现用例的重要因素。在管理环境时，经过将网络隔离来控制和组件之间的通讯能力是颇有必要的。一样，命名空间范围的RBAC策略容许运维人员为生产环节设置严格的权限。配额可以确保对最敏感环境的重要资源的访问。

从新使用对象名称的能力在这里颇有帮助。在测试和发布对象时，能够把它们放到新环境中，同时保留其命名空间。这样能够避免由于环境中出现类似的对象而产生的混淆，而且减小认知开销。

使用命名空间隔离不一样的使用者

另外一个命名空间能够解决的用例是根据使用者对工做负载进行分段。好比，若是你的集群为多个客户提供基础设施，那么按命名空间进行分段就可以实现管理每一个客户，同时跟踪帐单的去向。

另外，命名空间的特性可让你控制网络和访问策略，为你的使用者定义不一样的配额。在通用的状况下，命名空间容许你为每一个用户开发和部署相同模板化环境的不一样实例。这种一致性能够大大简化管理和故障诊断的过程。

理解预配置的Kubernetes命名空间

在咱们进行建立命名空间以前，先讨论一下Kubernetes是如何自动设置它的。在默认状况下，新的集群上有三个命名空间：

• default：向集群中添加对象而不提供命名空间，这样它会被放入默认的命名空间中。在建立替代的命名空间以前，该命名空间会充当用户新添加资源的主要目的地，没法删除。

• kube-public：kube-public命名空间的目的是让全部具备或不具备身份验证的用户都能全局可读。这对于公开bootstrap组件所需的集群信息很是有用。它主要是由Kubernetes本身管理。

• kube-system：kube-system命名空间用于Kubernetes管理的Kubernetes组件，通常规则是，避免向该命名空间添加普通的工做负载。它通常由系统直接管理，所以具备相对宽松的策略。

虽然这些命名空间有效地将用户工做负载与系统管理的工做负载隔离，但它们并不强制使用任何额外的结构对应用程序进行分类和管理。比较友好的是，建立和使用额外的命名空间很是简单

使用命名空间

使用kubectl管理命名空间及其包含的资源至关简单。在这一节中，咱们将演示一些最多见的命名空间操做，便于你开始有效地分割资源。

查看现有的命名空间

要显示集群中可用的全部命名空间，使用kubectl get namespaces命令：

该命令显示了全部可用的命名空间，不管它们是不是活跃的。此外还有资源的时长（age）。

若是想得到更详细的信息，使用kubectl describe命令：

Name: default

Labels: field.cattle.io/projectId=p-cmn9g

Annotations: cattle.io/status={"Conditions":[{"Type":"ResourceQuotaInit","Status":"True","Message":"","LastUpdateTime":"2018-12-17T23:17:48Z"},{"Type":"InitialRolesPopulated","Status":"True","Message":"","LastUpda... field.cattle.io/projectId=c-7tf7d:p-cmn9g lifecycle.cattle.io/create.namespace-auth=true

Status: Active

No resource quota.

No resource limits.

该命令用于显示与命名空间关联的标签和注释，以及已经应用了的全部配额或资源限制。

建立命名空间

咱们使用kubectl create namespace命令来建立命名空间。用命名空间的名称做为该命令的参数。

你还能够经过文件，使用manifest来建立命名空间。例如，下面的文件定义了咱们和上面如出一辙的命名空间。

假设上面的规范保存在demo-namespace.yml文件中。你能够输入指令来使用它：

不管咱们采用哪一种方法建立命名空间，在咱们再次检查可用命名空间时，应该能列出新的命名空间（咱们使用ns——命名空间的缩写，第二次进行查询）：

咱们新建立的命名空间已经变为可以使用。

根据命名空间筛选和执行操做

若是咱们将一个工做负载对象部署到集群而不指定命名空间，它将被添加到默认命名空间：

咱们可使用kubectl来验证部署是否建立在默认的命名空间：

若是咱们尝试再次使用相同的名称建立部署，会获得命名空间冲突的错误。

要将操做应用于不一样的命名空间，咱们必须在命令中包含—namespace=这一选项。下面咱们在demo-namespace命名空间上建立具备相同名称的部署：

此次部署成功了，尽管咱们仍然使用的是相同的部署名称。命名空间为资源名称提供了不一样的做用域，避免了前面所经历的命名冲突。

若是想查看新部署的详细信息，咱们再次使用—namespace=选项指定命名空间：

这说明咱们已经在demo-namespace命名空间建立了另外一个名为demo-nginx的部署。

经过设置Context选择命名空间

若是但愿避免为每一个命令提供一样的命名空间，能够经过配置kubectl的context来改变命令做用的默认命名空间。这会修改操做在context活跃时应用到的命名空间。

列出context配置的细节，输入：

上图说明咱们使用了一个名为Default的context，context没有指定命名空间，所以使用了默认命名空间。

想要将该context使用的命名空间修改为demo-context，咱们输入：

咱们能够在此查看context配置来验证当前是否选择了demo-namespace：

验证咱们的kubectl describe命令如今默认使用demo-namespace，它会请求咱们的demo-nginx部署而不须要指定命名空间：

删除命名空间并清理

若是不须要命名空间了，咱们能够删除它。

删除命名空间这一功能很是强大，由于它不只删除命名空间，还会清理其中部署了的全部资源。这一功能很是方便，可是同时若是你一不当心，也会很是危险。

在删除以前，最好列出和命名空间相关的资源，肯定想要删除的对象：

一旦肯定了要操做的范围，能够输入下面的命令删除demo-namespace命名空间和其中的全部资源：

命名空间及其资源将从集群中删除

若是你以前在kubectl上下文中更改了所选的命名空间，那么输入下面的命令清除所选的命名空间：

在清理demo资源时，请记住删除咱们最初提供给默认命名空间的原始demo-nginx部署：

如今你的集群应该处于一开始的状态了。

使用Rancher的Project扩展命名空间

若是你使用Rancher来管理Kubernetes集群，那么你就可使用projects特性提供的扩展功能。Rancher里的Project是一个额外的组织层，用于将多个命名空间绑定在一块儿。

Rancher的project在命名空间上覆盖了一个控制结构，容许你将命名空间分组成逻辑单元并对其应用相应的策略。Project在大多数状况下反映了命名空间，但它是做为命名空间的容器而不是单独的工做负载资源。Rancher中的每一个命名空间只存在于一个project中，命名空间继承应用于该项目的全部策略。

在默认状况下，Rancher集群定义了两个project：

• Default：该project包含了默认命名空间
• System：该project包含全部其余预配置的命名空间，包括kube-public、kube-system和系统提供的全部命名空间

在选择了集群以后，你能够经过访问Projects/Namespaces选项卡来查看集群中可用的项目：

在这里，单击Add Project按钮来添加project。在新建project时，你能够配置project成员及其访问权限，还能够配置安全策略和资源配额。

你还能够点击project的Add Namespace按钮向现有的项目添加命名空间。若是要将命名空间移动到不一样的project上，请先选择命名空间，单击Move按钮。将命名空间移动到新project中的开关会当即修改应用于该命名空间的权限和策略。

Rancher的project没有引入新的组织模型，而是简单地将相同的抽象应用到了命名空间上，而命名空间做用于工做负载对象。若是你喜欢使用命名空间，可是又须要额外的控制层的话，那么它们就可以填补这一使用上的空白。

总 结

在本文中，咱们介绍了Kubernetes命名空间的概念以及它们是如何帮助管理集群资源的。咱们讨论了集群中命名空间是如何为资源名称分段和分做用域的，以及在命名空间层面应用的策略如何影响用户权限和资源分配。

以后，咱们介绍了团队用命名空间将集群分段成逻辑块的一些经常使用模式，描述了Kubernetes预配置的命名空间及其用途。而后，咱们还了解了如何在集群中建立和使用命名空间。最后，咱们还介绍了Rancher项目以及它们是如何经过对命名空间自己进行分组来扩展命名空间的。

命名空间是一个很是简单又重要的概念，能够帮助团队管理集群资源而且下降复杂性。花一些时间熟悉它们的优势和特性能够帮助你有效地配置集群，避免未来遇到麻烦。