命名空间演练
Kubernetes 命名空间 帮助不同的项目、团队或客户去共享 Kubernetes 集群。
名字空间通过以下方式实现这点：
- 为名字 设置作用域.
- 为集群中的部分资源关联鉴权和策略的机制。
使用多个命名空间是可选的。
此示例演示了如何使用 Kubernetes 命名空间细分群集。
准备开始
您必须拥有一个 Kubernetes 集群，并且必须使用 kubectl 命令行工具与你的集群进行通信。如果您还没有一个集群，您可以通过 Minikube 创建一个集群，或者使用这些 Kubernetes playground ：
To check the version, enter kubectl version.
环境准备
此示例作如下假设：
- 您已拥有一个 配置好的 Kubernetes 集群。
- 您已对 Kubernetes 的 Pods, Services 和 Deployments 有基本理解。
- 理解默认命名空间
默认情况下，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
|
|---|
|
使用 kubectl 创建 development 命名空间。
$ kubectl create -f https://k8s.io/examples/admin/namespace-dev.json将下列的内容保存到文件 namespace-prod.json 中，这些内容是对 production 命名空间的描述：
admin/namespace-prod.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默认地，上述命令会添加两个上下文到 .kube/config 文件中。
您现在可以查看上下文并根据您希望使用的命名空间并在这两个新的请求上下文之间切换。
查看新的上下文：
$ 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
- context:
cluster: lithe-cocoa-92103_kubernetes
namespace: development
user: lithe-cocoa-92103_kubernetes
name: dev
- context:
cluster: lithe-cocoa-92103_kubernetes
namespace: production
user: lithe-cocoa-92103_kubernetes
name: prod
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让我们切换到 development 命名空间进行操作。
$ kubectl config use-context dev您可以使用下列命令验证当前上下文：
$ kubectl config current-context
dev此时，我们从命令行向 Kubernetes 集群发出的所有请求都限定在 development 命名空间中。
让我们创建一些内容。
$ kubectl run snowflake --image=kubernetes/serve_hostname --replicas=2我们刚刚创建了一个副本大小为2的 deployment，该 deployment 运行名为 snowflake 的 pod，其中包含一个仅提供主机名服务的基本容器。请注意，kubectl run 仅在 Kubernetes 集群版本 >= v1.2 时创建 deployment。如果您运行在旧版本上，则会创建 replication controller。如果期望执行旧版本的行为，请使用 --generator=run/v1 创建 replication controller。 参见 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 prodproduction 命名空间应该是空的，下列命令应该返回的内容为空。
$ kubectl get deployment
$ kubectl get pods生产环境需要运行 cattle，让我们创建一些名为 cattle 的 pods。
$ kubectl run cattle --image=kubernetes/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 中的策略支持的发展，我们将扩展此场景，以展示如何为每个命名空间提供不同的授权规则。
反馈
此页是否对您有帮助？
Thanks for the feedback. If you have a specific, answerable question about how to use Kubernetes, ask it on Stack Overflow. Open an issue in the GitHub repo if you want to report a problem or suggest an improvement.