通过命名空间共享集群

通过命名空间共享集群

本页展示了如何查看、使用和删除namespaces命名空间是 Kubernetes 为了在同一物理集群上支持多个虚拟集群而使用的一种抽象。。本页同时展示了如何使用 Kubernetes 命名空间去细分集群。

准备开始

您已拥有一个配置好的 Kubernetes 集群.
您已对 Kubernetes 的 Pods, Services, 和 Deployments 有基本理解。

查看命名空间

列出集群中现有的命名空间：

kubectl get namespaces

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

初始状态下，Kubernetes 具有三个名字空间：

default 无命名空间对象的默认命名空间
kube-system 由 Kubernetes 系统创建的对象的命名空间
kube-public 自动创建且被所有用户可读的命名空间（包括未经身份认证的）。此命名空间通常在某些资源在整个集群中可见且可公开读取时被集群使用。此命名空间的公共方面只是一个约定，而不是一个必要条件。

您还可以通过下列命令获取特定命名空间的摘要：

kubectl get namespaces <name>

或获取详细信息：

kubectl describe namespaces <name>

Name:           default
Labels:         <none>
Annotations:    <none>
Status:         Active
No resource quota.
Resource Limits
 Type       Resource    Min Max Default
 ----               --------    --- --- ---
 Container          cpu         -   -   100m

请注意，这些详情同时显示了资源配额（如果存在）以及资源限制区间。

资源配额跟踪并聚合 Namespace 中资源的使用情况，并允许集群运营者定义 Namespace 可能消耗的 Hard 资源使用限制。

限制区间定义了单个实体在一个 Namespace 中可使用的最小/最大资源量约束。

参阅准入控制: 限制区间

命名空间可以处于下列两个阶段中的一个:

Active 命名空间使用中
Terminating 命名空间正在被删除，且不能被用于新对象。

参见设计文档查看更多细节。

创建命名空间

新建一个名为 my-namespace.yaml 的 YAML 文件，并写入下列内容：
```
apiVersion: v1
kind: Namespace
metadata:
name: <insert-namespace-name-here>
```

然后运行：

kubectl create -f ./my-namespace.yaml

或者，你可以使用下面的命令创建命名空间：
```
kubectl create namespace <insert-namespace-name-here>
```

请注意，命名空间的名称必须是 DNS 兼容的标签。

可选字段 finalizers 允许观察者们在命名空间被删除时清除资源。记住如果指定了一个不存在的终结器，命名空间仍会被创建，但如果用户试图删除它，它将陷入 Terminating 状态。

更多有关 finalizers 的信息请查阅设计文档中命名空间部分。

删除命名空间

删除命名空间使用命令

kubectl delete namespaces <insert-some-namespace-name>

警告：

这会删除命名空间下的 所有内容 ！

删除是异步的,所以有一段时间你会看到命名空间处于 Terminating 状态。

使用 Kubernetes 命名空间细分您的集群

理解默认命名空间

默认情况下，Kubernetes 集群会在配置集群时实例化一个默认命名空间，用以存放集群所使用的默认 Pods、Services 和 Deployments 集合。

假设您有一个新的集群，您可以通过执行以下操作来内省可用的命名空间

kubectl get namespaces

NAME      STATUS    AGE
default   Active    13m

创建新的命名空间

在本练习中，我们将创建两个额外的 Kubernetes 命名空间来保存我们的内容。

在某组织使用共享的 Kubernetes 集群进行开发和生产的场景中：

开发团队希望在集群中维护一个空间，以便他们可以查看用于构建和运行其应用程序的 Pods、Services 和 Deployments 列表。在这个空间里，Kubernetes 资源被自由地加入或移除，对谁能够或不能修改资源的限制被放宽，以实现敏捷开发。

运维团队希望在集群中维护一个空间，以便他们可以强制实施一些严格的规程，对谁可以或不可以操作运行生产站点的 Pods、Services 和 Deployments 集合进行控制。

该组织可以遵循的一种模式是将 Kubernetes 集群划分为两个命名空间：development 和 production。

让我们创建两个新的命名空间来保存我们的工作。

文件 namespace-dev.json 描述了 development 命名空间:

`admin/namespace-dev.json`
`{` `“apiVersion”: “v1”,` `“kind”: “Namespace”,` `“metadata”: {` `“name”: “development”,` `“labels”: {` `“name”: “development”` `}` `}` `}`

使用 kubectl 创建 development 命名空间。

kubectl create -f https://k8s.io/examples/admin/namespace-dev.json

让我们使用 kubectl 创建 production 命名空间。

kubectl create -f https://k8s.io/examples/admin/namespace-prod.json

为了确保一切正常，列出集群中的所有命名空间。

kubectl get namespaces --show-labels

NAME          STATUS    AGE       LABELS
default       Active    32m       <none>
development   Active    29s       name=development
production    Active    23s       name=production

在每个命名空间中创建 pod

Kubernetes 命名空间为集群中的 Pods、Services 和 Deployments 提供了作用域。

与一个命名空间交互的用户不会看到另一个命名空间中的内容。

为了演示这一点，让我们在 development 命名空间中启动一个简单的 Deployment 和 Pod。

我们首先检查一下当前的上下文：

kubectl config view

apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: REDACTED
    server: https://130.211.122.180
  name: lithe-cocoa-92103_kubernetes
contexts:
- context:
    cluster: lithe-cocoa-92103_kubernetes
    user: lithe-cocoa-92103_kubernetes
  name: lithe-cocoa-92103_kubernetes
current-context: lithe-cocoa-92103_kubernetes
kind: Config
preferences: {}
users:
- name: lithe-cocoa-92103_kubernetes
  user:
    client-certificate-data: REDACTED
    client-key-data: REDACTED
    token: 65rZW78y8HbwXXtSXuUw9DbP4FLjHi4b
- name: lithe-cocoa-92103_kubernetes-basic-auth
  user:
    password: h5M0FtUUIflBSdI7
    username: admin

kubectl config current-context

lithe-cocoa-92103_kubernetes

下一步是为 kubectl 客户端定义一个上下文，以便在每个命名空间中工作。”cluster” 和 “user” 字段的值将从当前上下文中复制。

kubectl config set-context dev --namespace=development --cluster=lithe-cocoa-92103_kubernetes --user=lithe-cocoa-92103_kubernetes
kubectl config set-context prod --namespace=production --cluster=lithe-cocoa-92103_kubernetes --user=lithe-cocoa-92103_kubernetes

上述命令提供了两个可以替代的请求上下文，具体取决于您希望使用的命名空间。

让我们切换到 development 命名空间进行操作。

kubectl config use-context dev

您可以使用下列命令验证当前上下文：

kubectl config current-context
dev

此时，我们从命令行向 Kubernetes 集群发出的所有请求都限定在 development 命名空间中。

让我们创建一些内容。

kubectl run snowflake --image=k8s.gcr.io/serve_hostname --replicas=2

我们刚刚创建了一个副本大小为 2 的 deployment，该 deployment 运行名为 snowflake 的 pod，其中包含一个仅提供主机名服务的基本容器。请注意，kubectl run 仅在 Kubernetes 集群版本 >= v1.2 时创建 deployment。如果您运行在旧版本上，则会创建 replication controllers。如果期望执行旧版本的行为，请使用 --generator=run/v1 创建 replication controllers。参见 kubectl run 获取更多细节。

kubectl get deployment

NAME        DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
snowflake   2         2         2            2           2m

kubectl get pods -l run=snowflake

NAME                         READY     STATUS    RESTARTS   AGE
snowflake-3968820950-9dgr8   1/1       Running   0          2m
snowflake-3968820950-vgc4n   1/1       Running   0          2m

这很棒，开发人员可以做他们想要的事情，而不必担心影响 production 命名空间中的内容。

让我们切换到 production 命名空间，展示一个命名空间中的资源如何对另一个命名空间不可见。

kubectl config use-context prod

production 命名空间应该是空的，下列命令应该返回的内容为空。

kubectl get deployment
kubectl get pods

生产环境需要运行 cattle，让我们创建一些名为 cattle 的 pods。

kubectl run cattle --image=k8s.gcr.io/serve_hostname --replicas=5
kubectl get deployment

NAME      DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
cattle    5         5         5            5           10s

kubectl get pods -l run=cattle

NAME                      READY     STATUS    RESTARTS   AGE
cattle-2263376956-41xy6   1/1       Running   0          34s
cattle-2263376956-kw466   1/1       Running   0          34s
cattle-2263376956-n4v97   1/1       Running   0          34s
cattle-2263376956-p5p3i   1/1       Running   0          34s
cattle-2263376956-sxpth   1/1       Running   0          34s

此时，应该很清楚的展示了用户在一个命名空间中创建的资源对另一个命名空间是隐藏的。

随着 Kubernetes 中的策略支持的发展，我们将扩展此场景，以展示如何为每个命名空间提供不同的授权规则。

理解使用命名空间的动机

单个集群应该能满足多个用户及用户组的需求（以下称为 “用户社区”）。

Kubernetes 命名空间 帮助不同的项目、团队或客户去共享 Kubernetes 集群。

名字空间通过以下方式实现这点：

为名字设置作用域.
为集群中的部分资源关联鉴权和策略的机制。

使用多个命名空间是可选的。

每个用户社区都希望能够与其他社区隔离开展工作。

每个用户社区都有:

资源（pods, services, replication controllers, 等等）
策略（谁能或不能在他们的社区里执行操作）
约束（该社区允许多少配额，等等）

集群运营者可以为每个唯一用户社区创建命名空间。

命名空间为下列内容提供唯一的作用域：

命名资源（避免基本的命名冲突）
将管理权限委派给可信用户
限制社区资源消耗的能力

用例包括:

作为集群运营者, 我希望能在单个集群上支持多个用户社区。
作为集群运营者，我希望将集群分区的权限委派给这些社区中的受信任用户。
作为集群运营者，我希望能限定每个用户社区可使用的资源量，以限制对使用同一集群的其他用户社区的影响。
作为群集用户，我希望与我的用户社区相关的资源进行交互，而与其他用户社区在该集群上执行的操作无关。

理解命名空间和 DNS

当您创建 Service 时，它会创建相应的 DNS 条目。此条目的格式为 <service-name>。<namespace-name> .svc.cluster.local，这意味着如果容器只使用 <service-name>，它将解析为本地服务到命名空间。这对于在多个命名空间（如开发，暂存和生产）中使用相同的配置非常有用。如果要跨命名空间访问，则需要使用完全限定的域名（FQDN）。

接下来

了解更多设置命名空间首选项的内容。
了解更多设置请求的命名空间的内容。
参见命名空间设计。