简介
Kubernetes 集群就像一栋大型公寓楼。
如果所有人都住在大堂里，场面会非常混乱。你无法分清家具属于谁，而且一个吵闹的邻居可能会影响所有人。
命名空间（Namespace）会在逻辑上划分集群，使不同的团队、环境或应用能够分别组织资源。
ResourceQuota 会限制某个命名空间可以使用的特定资源数量。这有助于防止某个团队或工作负载耗尽集群共享容量。
在本实验中，你将：
- 创建一个名为
dev的新「公寓」（命名空间）。 - 为这个公寓设置严格的「用电上限」（ResourceQuota）。
- 尝试将家具（Pod）搬入公寓，并检查是否超出限制。
创建命名空间
在此步骤中，你将创建一个新的命名空间，为开发团队隔离资源。
命名空间是同一个集群内部的逻辑边界，并不是独立的集群。团队仍然共享同一个控制平面和底层节点，但名称、策略以及许多资源视图可以分开管理，从而保持工作井然有序。
默认情况下，所有资源都会进入 default 命名空间，也就是大堂。先查看当前已有的命名空间：
kubectl get namespaces
你应该能看到 default、kube-system（大楼管理员所在的位置）以及其他几个命名空间。
现在创建 dev 公寓：
kubectl create namespace dev
确认它已经创建：
kubectl get namespaces
你会在列表中看到 dev。此时它还是一个没有隔断和限制的空公寓，可以向其中放入任何资源。
应用资源限制
现在需要设置规则。我们不希望 dev 团队耗尽整个集群的 CPU 和内存。
接下来创建一个 ResourceQuota 对象，用它规定：「在 dev 命名空间中，最多可以使用 2 个 CPU 和 2Gi 内存。」
在共享集群中，配额尤其重要，因为 CPU 和内存都是有限资源。如果没有配额，某个资源使用量过高的工作负载可能会占用超过合理份额的资源，使整个集群对其他用户都变得不可靠。因此，配额不仅用于统计资源使用量，也是保障稳定性的工具。
创建名为 quota.yaml 的文件：
nano quota.yaml
粘贴以下配置：
apiVersion: v1
kind: ResourceQuota
metadata:
name: dev-quota
namespace: dev
spec:
hard:
requests.cpu: "1"
requests.memory: 1Gi
limits.cpu: "2"
limits.memory: 2Gi
保存并退出（按 Ctrl+X、Y、Enter）。
将此规则应用到集群：
kubectl apply -f quota.yaml
查看规则详情。输出会显示「Hard」限制（你设置的上限）和「Used」用量（当前为 0）。
kubectl describe resourcequota dev-quota --namespace=dev
部署 Pod
规则设置完成后，尝试把家具搬进来。
重要规则：当公寓存在资源限制时，搬入的每件家具都必须声明自己的大小。在 Kubernetes 中，这意味着：如果命名空间设置了配额，每个 Pod 都必须明确指定 resources（请求量和限制量）。如果没有指定，楼宇管理员 Kubernetes 会在入口处阻止 Pod 创建。
这里会涉及两个相关概念。请求量（request）告诉调度器，Pod 被放置时应获得多少资源保障。限制量（limit）是容器最多可以使用的资源量。配额会汇总命名空间中所有 Pod 的请求量和限制量，确保总量符合策略。
创建名为 pod.yaml 的文件：
nano pod.yaml
粘贴以下内容。注意，其中明确声明了这个 Pod 的资源大小：
apiVersion: v1
kind: Pod
metadata:
name: dev-pod
namespace: dev ## <-- Putting it in the 'dev' apartment
spec:
containers:
- name: nginx
image: nginx
resources:
requests:
memory: "128Mi"
cpu: "250m"
limits:
memory: "256Mi"
cpu: "500m"
保存并退出（按 Ctrl+X、Y、Enter）。
部署 Pod：
kubectl apply -f pod.yaml
检查它是否正在 dev 命名空间中运行：
kubectl get pods --namespace=dev
等待状态显示为 Running。
现在再次检查配额使用情况。你会看到「Used」列中的数值已经增加！
kubectl describe resourcequota dev-quota --namespace=dev
这表示你已经成功根据资源预算跟踪资源使用情况。
验证隔离
最后，验证我们的「公寓」隔断确实生效。
命名空间隔离主要体现在名称、策略和操作范围上。默认情况下，它并不意味着工作负载会运行在物理上完全分开的硬件上。之后学习节点选择和更强的隔离机制时，这一区别非常重要。
我们已经将 dev-pod 放入 dev。从大堂（default）中应该看不到它。
列出 default 命名空间中的 Pod：
kubectl get pods
你应该看到「No resources found in default namespace」（或者至少看不到 dev-pod）。
现在查看 default 命名空间中的配额：
kubectl get resourcequota
你应该看不到任何内容。我们设置的用电上限只适用于 dev 公寓，不适用于整栋大楼。
这表明命名空间可以为不同团队提供真正的资源隔离。
总结
在本实验中，你成为了 Kubernetes 集群的楼宇管理员。
你已经成功完成以下任务：
- 为团队创建了一个私有的命名空间（
dev）。 - 设置了严格的 ResourceQuota（用电上限），防止资源被过度消耗。
- 部署了一个遵守这些限制的应用。
- 验证了命名空间之间的隔断能够保持资源隔离。
大型组织正是通过这种方式，让数百个团队共享同一个 Kubernetes 集群，同时避免互相影响。
