本页展示了如何查看、操作和删除 命名空间。本页还展示了如何使用 Kubernetes 命名空间来细分集群。
使用以下命令列出集群中的当前命名空间：
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：该命名空间包含与每个节点关联的 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
请注意，这些详情显示了资源配额（如果存在）以及资源限制范围。
资源配额 (Resource quota) 会跟踪命名空间中资源的聚合使用情况，并允许集群管理员定义命名空间可能消耗的硬性资源使用限制。
限制范围 (Limit range) 定义了单个实体在命名空间中可以消耗的资源量的最小/最大约束。
参阅 准入控制：限制范围
命名空间可能处于以下两个阶段之一：
Active：该命名空间正在使用中。Terminating：该命名空间正在被删除，不能再用于创建新对象。更多详细信息，请参阅 API 参考中的 Namespace。
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 集群在配置集群时会实例化一个默认命名空间，以存放集群使用的默认 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
Kubernetes 命名空间为集群中的 Pod、服务和部署提供了作用域。与一个命名空间交互的用户看不到另一个命名空间中的内容。为了演示这一点，让我们在 development 命名空间中启动一个简单的部署和 Pod。
kubectl create deployment snowflake \
--image=registry.k8s.io/serve_hostname \
-n=development --replicas=2
我们已经创建了一个副本大小为 2 的部署，它运行名为 snowflake 的 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），所以让我们创建一些“牛”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 集群。
它通过提供以下内容来实现这一点：
使用多个命名空间是可选的。
每个用户社区都希望能够独立于其他社区工作。每个用户社区都有自己的：
集群管理员可以为每个唯一用户社区创建一个命名空间。
命名空间为以下内容提供了唯一的作用域：
使用场景包括：
当您创建 服务 (Service) 时，它会创建一个对应的 DNS 条目。该条目的格式为 <service-name>.<namespace-name>.svc.cluster.local，这意味着如果容器使用 <service-name>，它将解析到该命名空间本地的服务。这对于在多个命名空间（如开发、测试和生产）中重用相同的配置非常有用。如果您想跨命名空间访问，则需要使用完全限定域名 (FQDN)。