命名空间

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

命名空间定义

命名空间（namespace）是 Kubernetes 提供的组织机制，用于给集群中的任何对象组进行分类、筛选和管理。每一个添加到 Kubernetes 集群的工作负载必须放在一个命名空间中。命名空间为集群中的对象名称赋予作用域。虽然在命名空间中名称必须是唯一的，但是相同的名称可以在不同的命名空间中使用。这对于某些场景来说可能帮助很大。例如，如果使用命名空间来划分应用程序生命周期环境（如开发、staging、生产），则可以在每个环境中维护利用同样的名称维护相同对象的副本。

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

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

预置的命名空间

在默认情况下，新的集群上有三个命名空间：

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

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

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

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

命名空间的使用

我们可以通过资源文件的方式来定义命名空间：

// kubectl create -f https://k8s.io/examples/admin/namespace-dev.json
{
  "apiVersion": "v1",
  "kind": "Namespace",
  "metadata": {
    "name": "development",
    "labels": {
      "name": "development"
    }
  }
}

// kubectl create -f https://k8s.io/examples/admin/namespace-prod.json
{
  "apiVersion": "v1",
  "kind": "Namespace",
  "metadata": {
    "name": "production",
    "labels": {
      "name": "production"
    }
  }
}

# 查看命名空间
$ kubectl get namespaces

NAME          STATUS    AGE
default       Active    1d
kube-system   Active    1d
kube-public   Active    1d

# 设置命名空间
$ kubectl run nginx --image=nginx --namespace=<insert-namespace-name-here>
$ kubectl get pods --namespace=<insert-namespace-name-here>

# 设置默认的命名空间
$ kubectl config set-context --current --namespace=<insert-namespace-name-here>
# Validate it
$ kubectl config view --minify | grep namespace:

命名空间使用模式

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

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

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

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

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

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

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

重新使用对象名称的能力在这里很有帮助。在测试和发布对象时，可以把它们放到新环境中，同时保留其命名空间。这样可以避免因为环境中出现相似的对象而产生的混淆，并且减少认知开销。

使用命名空间隔离不同的使用者

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

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