使用命名空间共享集群
此页面展示了如何查看、操作和删除 命名空间。该页面还展示了如何使用 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，其中包含一个基本的容器，用于提供主机名。
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)。