使用命名空间共享集群
本页介绍如何查看、使用和删除命名空间。本页还介绍如何使用 Kubernetes 命名空间来细分你的集群。
准备开始
- 拥有一个现有的 Kubernetes 集群。
- 你对 Kubernetes 的Pod、服务和部署有基本的了解。
查看命名空间
使用以下命令列出集群中当前的命名空间
kubectl get namespaces
NAME STATUS AGE
default Active 11d
kube-node-lease Active 11d
kube-public Active 11d
kube-system Active 11d
Kubernetes 启动时带有四个初始命名空间
default没有其他命名空间的对象使用的默认命名空间kube-node-lease此命名空间保存与每个节点关联的租约对象。节点租约允许 kubelet 发送心跳，以便控制平面可以检测节点故障。kube-public此命名空间是自动创建的，并且所有用户（包括未经身份验证的用户）都可读取。此命名空间主要保留用于集群使用，以防某些资源在整个集群中应公开可见和可读。此命名空间的公共方面只是一种约定，而不是要求。kube-system用于 Kubernetes 系统创建的对象的命名空间
你还可以使用以下命令获取特定命名空间的摘要
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
请注意，这些详细信息显示了资源配额（如果存在）以及资源限制范围。
资源配额跟踪命名空间中资源的总使用量，并允许集群操作员定义命名空间可以消耗的 硬性 资源使用限制。
限制范围定义了单个实体在命名空间中可以消耗的资源量的最小/最大约束。
请参阅准入控制：限制范围
命名空间可以处于以下两种阶段之一
Active命名空间正在使用中Terminating命名空间正在被删除，不能用于新对象
有关更多详细信息，请参阅 API 参考中的命名空间。
创建一个新的命名空间
注意
避免创建带有前缀kube- 的命名空间，因为它保留用于 Kubernetes 系统命名空间。创建一个名为 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，它允许可观察对象在命名空间被删除时清除资源。请记住，如果你指定不存在的 finalizer，则会创建命名空间，但如果用户尝试删除它，则该命名空间会停留在 Terminating 状态。
有关 finalizers 的更多信息，请参阅命名空间设计文档。
删除命名空间
使用以下命令删除命名空间
kubectl delete namespaces <insert-some-namespace-name>
警告
这将删除该命名空间下的所有内容！此删除是异步的，因此你会在一段时间内看到命名空间处于 Terminating 状态。
使用 Kubernetes 命名空间细分你的集群
默认情况下，在配置集群时，Kubernetes 集群将实例化一个默认命名空间，以保存集群使用的默认 Pod、服务和部署集。
假设你有一个新的集群，你可以通过执行以下操作来查看可用的命名空间
kubectl get namespaces
NAME STATUS AGE
default Active 13m
创建新的命名空间
在本练习中，我们将创建两个额外的 Kubernetes 命名空间来保存我们的内容。
在组织使用共享 Kubernetes 集群进行开发和生产用例的场景中
开发团队希望在集群中维护一个空间，以便他们可以查看用于构建和运行其应用程序的 Pod、服务和部署列表。在这个空间中，Kubernetes 资源来来往往，并且放宽了对谁可以或不可以修改资源的限制，以实现敏捷开发。
运营团队希望在集群中维护一个空间，他们可以在其中强制执行严格的程序，以决定谁可以或不可以操作运行生产站点的 Pod、服务和部署集。
该组织可以遵循的一种模式是将 Kubernetes 集群划分为两个命名空间：development 和 production。让我们创建两个新的命名空间来保存我们的工作。
使用 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 命名空间为集群中的 Pod、服务和部署提供了作用域。与一个命名空间交互的用户看不到另一个命名空间中的内容。为了演示这一点，让我们在 development 命名空间中启动一个简单的部署和 Pod。
kubectl create deployment snowflake \
--image=registry.k8s.io/serve_hostname \
-n=development --replicas=2
我们创建了一个副本大小为 2 的部署，该部署运行名为 snowflake 的 Pod，该 Pod 带有提供主机名的基本容器。
kubectl get deployment -n=development
NAME READY UP-TO-DATE AVAILABLE AGE
snowflake 2/2 2 2 2m
kubectl get pods -l app=snowflake -n=development
NAME READY STATUS RESTARTS AGE
snowflake-3968820950-9dgr8 1/1 Running 0 2m
snowflake-3968820950-vgc4n 1/1 Running 0 2m
这很好，开发人员能够做他们想做的事情，并且他们不必担心会影响 production 命名空间中的内容。
让我们切换到 production 命名空间，并展示一个命名空间中的资源如何对另一个命名空间隐藏。production 命名空间应该为空，并且以下命令应该不返回任何内容。
kubectl get deployment -n=production
kubectl get pods -n=production
生产环境喜欢运行 cattle，所以让我们创建一些 cattle Pod。
kubectl create deployment cattle --image=registry.k8s.io/serve_hostname -n=production
kubectl scale deployment cattle --replicas=5 -n=production
kubectl get deployment -n=production
NAME READY UP-TO-DATE AVAILABLE AGE
cattle 5/5 5 5 10s
kubectl get pods -l app=cattle -n=production
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 集群。
它通过提供以下内容来实现这一点
- 名称的作用域。
- 将授权和策略附加到集群子部分的机制。
使用多个命名空间是可选的。
每个用户社区都希望能够与其他社区隔离地工作。每个用户社区都有自己的
- 资源（Pod、服务、复制控制器等）
- 策略（谁可以或不可以在其社区中执行操作）
- 约束（此社区允许的配额，等等）
集群操作员可以为每个唯一的用户社区创建一个命名空间。
命名空间为以下内容提供了一个独特的范围：
- 命名资源（以避免基本的命名冲突）
- 向受信任用户委派管理权限
- 限制社区资源消耗的能力
使用场景包括：
- 作为集群操作员，我希望在单个集群上支持多个用户社区。
- 作为集群操作员，我希望将集群的分区管理权限委派给这些社区中受信任的用户。
- 作为集群操作员，我希望限制每个社区可以消耗的资源量，以限制对使用该集群的其他社区的影响。
- 作为集群用户，我希望与我的用户社区相关的资源进行交互，而不会受到集群上其他用户社区活动的影响。
理解命名空间和 DNS
当你创建一个服务（Service）时，它会创建一个相应的DNS 条目。这个条目的形式是 <service-name>.<namespace-name>.svc.cluster.local，这意味着如果一个容器使用 <service-name>，它将解析为命名空间本地的服务。这对于在多个命名空间（例如开发、暂存和生产）中使用相同的配置非常有用。如果你想跨命名空间访问，你需要使用完全限定域名（FQDN）。