好的，各位Kubernetes探险家们，欢迎来到今天的"资源大冒险"特别节目！我是你们的导游，人称"K8s老司机"，今天咱们要聊聊Kubernetes世界里两个非常重要的“管家”：资源配额 (Resource Quotas) 和限制范围 (LimitRanges)。
想象一下，你是一家宇宙级餐厅的老板，你的K8s集群就是你的厨房，跑着各种美味可口的应用（Pod），而你的客户就是用户。如果厨房没有规则，大厨们（开发者）想用多少食材（资源）就用多少，那你的餐厅很快就会破产。这时候，资源配额和限制范围就派上用场了，它们就像你的餐厅经理，帮你维持秩序，保证所有人都吃得上饭，而且餐厅还能盈利。
第一幕：资源配额 (Resource Quotas) – 总经理的预算大权
资源配额就像餐厅的总经理，负责制定整个餐厅的预算。它定义了在一个命名空间 (Namespace) 内，可以使用的总资源量，例如 CPU、内存、存储等等。
什么是命名空间？
咱们先来个小插曲，说说命名空间。你可以把命名空间想象成餐厅里的不同区域，比如大堂、包间、后厨等等。每个区域都有不同的用途，资源配额可以针对不同的命名空间设置不同的预算。
资源配额能做什么？
资源配额可以限制以下资源的使用：
- CPU: 可以限制 CPU 的总请求量 (requests) 和总限制量 (limits)。
- 内存: 同样可以限制内存的总请求量和总限制量。
- 存储: 可以限制 PersistentVolumeClaim (PVC) 的总数量和总存储容量。
- Pod 和 Service 等对象数量: 可以限制 Pod、Service、ReplicationController 等对象的总数量。
如何使用资源配额？
咱们来看一个资源配额的 YAML 文件：
apiVersion: v1
kind: ResourceQuota
metadata:
name: compute-resources
spec:
hard:
pods: "4" # 最多创建4个 Pod
requests.cpu: "2" # CPU 请求总量不能超过 2 核
requests.memory: "4Gi" # 内存请求总量不能超过 4GB
limits.cpu: "4" # CPU 限制总量不能超过 4 核
limits.memory: "8Gi" # 内存限制总量不能超过 8GB
persistentvolumeclaims: "2" # 最多创建 2 个 PVC
requests.storage: "10Gi" # 存储请求总量不能超过 10GB这个 YAML 文件定义了一个名为 compute-resources 的资源配额，限制了命名空间内 Pod 的数量、CPU 和内存的请求和限制总量，以及 PVC 的数量和存储请求总量。
应用这个资源配额：
kubectl apply -f resource-quota.yaml -n <your-namespace>资源配额的注意事项：
- 强制性： 资源配额一旦启用，就会强制执行。如果你的应用尝试请求超过配额的资源，Kubernetes 会拒绝创建该应用。
- 默认值： 如果你的 Pod 没有指定 CPU 和内存的请求和限制，Kubernetes 会使用默认值。如果命名空间没有设置默认值，Pod 可能会因为超出配额而无法创建。
资源配额的优势：
- 成本控制： 可以有效控制资源的使用，避免浪费。
- 资源公平性： 确保所有应用都能获得足够的资源，避免资源饥饿。
- 安全性： 可以限制恶意应用消耗过多资源，影响其他应用的运行。
第二幕：限制范围 (LimitRanges) – 大堂经理的单品定价
限制范围就像餐厅的大堂经理，负责制定每个菜品的定价策略。它定义了在一个命名空间内，每个 Pod、容器或 PVC 可以请求的资源的最小值、最大值和默认值。
限制范围能做什么？
限制范围可以限制以下资源的使用：
- CPU: 可以限制 CPU 的最小请求量、最大请求量、最小限制量、最大限制量和默认请求量/限制量。
- 内存: 同样可以限制内存的最小请求量、最大请求量、最小限制量、最大限制量和默认请求量/限制量。
- 存储: 可以限制 PVC 的最小存储容量和最大存储容量。
如何使用限制范围？
咱们来看一个限制范围的 YAML 文件：
apiVersion: v1
kind: LimitRange
metadata:
name: cpu-mem-limit-range
spec:
limits:
- default:
cpu: 500m # 默认 CPU 限制为 500m
memory: 512Mi # 默认内存限制为 512Mi
defaultRequest:
cpu: 250m # 默认 CPU 请求为 250m
memory: 256Mi # 默认内存请求为 256Mi
max:
cpu: "1" # 最大 CPU 限制为 1 核
memory: 1Gi # 最大内存限制为 1GB
min:
cpu: 100m # 最小 CPU 请求为 100m
memory: 100Mi # 最小内存请求为 100Mi
type: Container # 限制类型为容器这个 YAML 文件定义了一个名为 cpu-mem-limit-range 的限制范围，限制了命名空间内每个容器的 CPU 和内存的最小请求量、最大请求量、最小限制量、最大限制量和默认请求量/限制量。
应用这个限制范围：
kubectl apply -f limit-range.yaml -n <your-namespace>限制范围的注意事项：
- 自动填充： 如果你的 Pod 或容器没有指定 CPU 和内存的请求和限制，Kubernetes 会自动填充默认值。
- 验证： Kubernetes 会验证你的 Pod 或容器的资源请求是否符合限制范围。如果超出限制，Kubernetes 会拒绝创建该应用。
限制范围的优势：
- 简化配置： 可以简化应用配置，避免开发者忘记设置资源请求和限制。
- 资源合理利用： 确保所有应用都能获得足够的资源，避免资源浪费。
- 最佳实践： 可以强制执行最佳实践，例如设置合理的 CPU 和内存限制。
第三幕：资源配额 vs 限制范围 – 两位管家的分工合作
资源配额和限制范围虽然都是用来管理资源的，但它们的分工不同。
- 资源配额： 管理整个命名空间的总资源使用量，就像总经理管理餐厅的总预算。
- 限制范围： 管理每个 Pod、容器或 PVC 的资源使用量，就像大堂经理管理每个菜品的定价策略。
它们可以一起工作，共同维护 Kubernetes 集群的资源秩序。
举个例子：
假设你的命名空间有一个资源配额，限制了 CPU 的总请求量为 4 核。同时，你还有一个限制范围，限制了每个容器的 CPU 请求量最小为 100m，最大为 1 核，默认请求量为 250m。
如果你的应用尝试创建一个 Pod，其中包含 5 个容器，每个容器的 CPU 请求量都为 1 核，那么这个 Pod 将无法创建，因为它的 CPU 请求总量将达到 5 核，超过了资源配额的限制。
如果你的应用尝试创建一个 Pod，其中包含 2 个容器，其中一个容器没有指定 CPU 请求量，另一个容器的 CPU 请求量为 50m，那么 Kubernetes 会自动将第一个容器的 CPU 请求量设置为默认值 250m，并将第二个容器的 CPU 请求量拒绝，因为低于限制范围的最小值 100m。
资源配额与限制范围的对比：
| 特性 | 资源配额 (Resource Quotas) | 限制范围 (LimitRanges) |
|---|---|---|
| 作用域 | 命名空间 (Namespace) | 命名空间 (Namespace) |
| 目的 | 限制总资源使用量 | 限制每个 Pod、容器或 PVC 的资源使用量 |
| 限制类型 | CPU、内存、存储、Pod 和 Service 等对象数量 | CPU、内存、存储 |
| 策略 | 限制总资源使用量 | 限制最小/最大资源请求和限制，并提供默认值 |
| 使用场景 | 控制命名空间的总资源使用量，防止资源浪费 | 强制执行资源使用最佳实践，简化应用配置 |
| 侧重点 | 宏观调控，总量控制 | 微观管理，单体控制 |
| 好比 | 餐厅总经理管理总预算 | 餐厅大堂经理管理菜品定价策略 |
| 使用难度 | 相对简单，易于理解 | 相对复杂，需要理解最小/最大值和默认值的概念 |
| 适用对象 | 运维人员，集群管理员 | 开发者，应用管理员 |
| 举个栗子 | 命名空间总共只能创建 10 个 Pod，总 CPU 请求不能超过 8 核 | 每个容器必须请求至少 100m CPU，最多 1 核 CPU，默认 250m CPU |
总结：
资源配额和限制范围是 Kubernetes 集群中两个非常重要的资源管理工具。它们可以帮助你控制资源的使用，确保所有应用都能获得足够的资源，并强制执行最佳实践。掌握了它们，你就可以像一位经验丰富的餐厅老板一样，轻松管理你的 Kubernetes 集群，让你的应用跑得更稳、更快、更省钱！
最后的彩蛋：
记住，资源管理是一门艺术，需要根据你的实际情况进行调整。不要害怕尝试，不断学习，才能成为真正的 Kubernetes 资源管理大师！💪
希望今天的"资源大冒险"特别节目对你有所帮助。下次再见！ 👋