使用命名空间共享集群
此页面展示了如何查看、操作和删除 命名空间。该页面还展示了如何使用 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，它允许可观察者在删除命名空间时清除资源。请记住，如果您指定了一个不存在的最终器，则命名空间将被创建，但如果用户尝试删除它，则会卡在 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
生产喜欢运行牛，所以让我们创建一些牛 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
当您创建 服务 时，它会创建一个相应的 DNS 条目。此条目格式为 <service-name>.<namespace-name>.svc.cluster.local，这意味着如果容器使用 <service-name>，它将解析到该命名空间中的本地服务。这对于在多个命名空间（如开发、暂存和生产）中使用相同的配置很有用。如果您想跨命名空间访问，则需要使用完全限定域名 (FQDN)。