Kubernetes 资源请求与限制：一场精打细算的房产游戏 🏡
大家好，欢迎来到今天的“云原生房产中介”讲座！我是你们的金牌讲师，人称“K8s小诸葛”，今天咱们就来聊聊 Kubernetes 资源请求与限制，这个听起来高深莫测，实际上却和咱们买房、租房息息相关的概念。
别一听“资源请求”、“资源限制”就觉得枯燥，这可不是什么财务报表，而是关系到你的应用在 Kubernetes 集群里住得舒不舒服，跑得快不快的关键！想想看，你辛辛苦苦写的代码，如果跑在一个拥挤不堪、资源不足的“蜗居”里，那效率能高吗？肯定不行！
所以，今天咱们就用最通俗易懂的语言，把这个资源分配的问题给彻底讲透，让你的应用都能住上“豪宅”，跑得飞起！🚀
Part 1：为什么要进行资源请求与限制？—— 告别“公地悲剧”
想象一下，一个共享的办公室，每个人都可以随意占用资源，想用多少电脑就用多少，想开多少个浏览器标签就开多少个。结果会怎样？🤔
- 资源争抢： 每个人都想多占资源，导致其他人运行缓慢，甚至崩溃。
- 性能下降： 资源不足，应用运行效率低下，用户体验糟糕。
- 浪费资源： 有些应用可能过度申请资源，但实际上根本用不完，造成资源浪费。
这就是“公地悲剧”的典型表现！Kubernetes 集群也是一个共享资源的环境，如果没有合理的资源管理机制，就会出现上述问题。
资源请求 (Requests) 就像你租房时向房东提出的“我需要多大的面积，需要什么样的家具”的需求。它告诉 Kubernetes 调度器：“我这个 Pod 至少需要这么多的 CPU 和内存才能正常运行。”
资源限制 (Limits) 就像房东对你的约束：“你最多只能用这么多的水电，超出部分要额外收费。”它告诉 Kubernetes 运行时：“这个 Pod 最多只能使用这么多的 CPU 和内存，超出部分会被限制。”
通过设置资源请求和限制，我们可以：
- 保证应用的基本运行需求： 确保应用在资源充足的环境下运行，避免因资源不足而崩溃。
- 防止资源过度占用： 限制应用使用的资源上限，避免某个应用占用过多资源，影响其他应用的运行。
- 提高资源利用率： 合理分配资源，避免资源浪费，让集群的整体性能得到提升。
- 提升集群稳定性： 避免因资源争抢导致集群不稳定，提高应用的可用性。
简单来说，资源请求与限制就是 Kubernetes 的“交通规则”，让每个应用都能在集群里“安全驾驶”，避免“交通事故”。🚥
Part 2：CPU 和内存——应用的“粮草”
在 Kubernetes 中，CPU 和内存是最常见的两种资源。它们就像应用的“粮草”，没有足够的“粮草”，应用就无法生存和发展。
2.1 CPU：应用的“算力引擎”
CPU 是中央处理器，负责执行程序的指令。对于需要大量计算的应用，例如机器学习、图像处理等，CPU 资源尤为重要。
- 单位： CPU 的单位通常是“核 (core)”。 Kubernetes 允许你指定 CPU 的数量，例如
0.5表示半个 CPU 核，2表示两个 CPU 核。 - 请求 (Requests)： 告诉 Kubernetes 调度器：“我这个 Pod 至少需要多少 CPU 核才能正常运行。”
- 限制 (Limits)： 告诉 Kubernetes 运行时：“这个 Pod 最多可以使用多少 CPU 核。”
举个例子：
apiVersion: v1
kind: Pod
metadata:
name: cpu-demo
spec:
containers:
- name: cpu-demo-container
image: busybox
resources:
requests:
cpu: "0.5" # 请求 0.5 个 CPU 核
limits:
cpu: "1" # 限制使用 1 个 CPU 核在这个例子中，我们定义了一个名为 cpu-demo 的 Pod，它包含一个名为 cpu-demo-container 的容器。
requests.cpu: "0.5"表示该容器至少需要 0.5 个 CPU 核才能正常运行。Kubernetes 调度器会尽量将该 Pod 调度到 CPU 资源充足的节点上。limits.cpu: "1"表示该容器最多可以使用 1 个 CPU 核。如果该容器试图使用超过 1 个 CPU 核，Kubernetes 运行时会对其进行限制，例如降低其 CPU 使用优先级。
CPU 的单位还可以使用 milliCPU (m)：
- 1 core = 1000m
所以，0.5 core 也可以表示为 500m。
2.2 内存：应用的“仓库”
内存是随机存取存储器 (RAM)，用于存储程序运行时的数据。对于需要大量数据的应用，例如数据库、缓存等，内存资源尤为重要。
- 单位： 内存的单位通常是字节 (bytes)，可以使用 KB、MB、GB、TB 等表示。 Kubernetes 允许你指定内存的大小，例如
128Mi表示 128MB，1Gi表示 1GB。 - 请求 (Requests)： 告诉 Kubernetes 调度器：“我这个 Pod 至少需要多少内存才能正常运行。”
- 限制 (Limits)： 告诉 Kubernetes 运行时：“这个 Pod 最多可以使用多少内存。”
举个例子：
apiVersion: v1
kind: Pod
metadata:
name: memory-demo
spec:
containers:
- name: memory-demo-container
image: busybox
resources:
requests:
memory: "128Mi" # 请求 128MB 内存
limits:
memory: "256Mi" # 限制使用 256MB 内存在这个例子中，我们定义了一个名为 memory-demo 的 Pod，它包含一个名为 memory-demo-container 的容器。
requests.memory: "128Mi"表示该容器至少需要 128MB 内存才能正常运行。Kubernetes 调度器会尽量将该 Pod 调度到内存资源充足的节点上。limits.memory: "256Mi"表示该容器最多可以使用 256MB 内存。如果该容器试图使用超过 256MB 内存，Kubernetes 运行时会对其进行限制，例如将其杀死 (OOMKilled)。
记住：
- Requests 就像你的最低生活保障，Limits 就像你的收入上限。
- Requests 决定了你的 Pod 是否能被调度，Limits 决定了你的 Pod 能否稳定运行。
Part 3：如何设置资源请求与限制？—— 精打细算，量体裁衣
设置资源请求与限制，就像给你的应用量体裁衣，既要保证它穿得舒服，又要避免浪费布料。
3.1 确定资源需求
在设置资源请求与限制之前，我们需要了解应用的资源需求。这可以通过以下方法实现：
- 性能测试： 通过性能测试工具，例如 Apache Bench、JMeter 等，模拟真实用户场景，测试应用的 CPU 和内存使用情况。
- 监控数据： 通过监控工具，例如 Prometheus、Grafana 等，收集应用在生产环境中的 CPU 和内存使用数据。
- 经验判断： 根据应用的类型和功能，结合经验进行判断。例如，数据库通常需要更多的内存，而计算密集型应用通常需要更多的 CPU。
3.2 设置资源请求
资源请求应该设置为应用正常运行所需的最小资源量。设置过小会导致应用运行缓慢，设置过大则会浪费资源。
建议：
- 从较低的数值开始，逐步增加。
- 根据应用的实际运行情况进行调整。
3.3 设置资源限制
资源限制应该设置为应用可以使用的最大资源量。设置过小会导致应用无法处理峰值流量，设置过大则会浪费资源，并可能影响其他应用的运行。
建议：
- 设置一个合理的上限，防止应用过度占用资源。
- 根据应用的实际运行情况进行调整。
3.4 请求与限制的关系
- Requests <= Limits 这是最基本的原则。如果 Requests 大于 Limits，Kubernetes 会拒绝创建 Pod。
- Requests == Limits 这是一种常见的做法，可以简化资源管理，避免资源浪费。
- Requests < Limits 这是一种更灵活的做法，允许应用在需要时使用更多的资源，但需要仔细监控应用的资源使用情况，避免资源过度占用。
想象一下：
- Requests = 100MB, Limits = 200MB: 就像你租了一个 100 平米的房子，但是房东允许你偶尔可以扩展到 200 平米，但超出部分要额外付费。
- Requests = 200MB, Limits = 200MB: 就像你租了一个 200 平米的房子，一切都刚刚好。
3.5 示例：Deployment 中的资源请求与限制
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 3
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
spec:
containers:
- name: my-app-container
image: my-app-image
resources:
requests:
cpu: "200m"
memory: "256Mi"
limits:
cpu: "500m"
memory: "512Mi"在这个例子中，我们定义了一个名为 my-app 的 Deployment，它包含 3 个副本。每个副本的资源请求和限制如下：
requests.cpu: "200m"：请求 0.2 个 CPU 核requests.memory: "256Mi"：请求 256MB 内存limits.cpu: "500m"：限制使用 0.5 个 CPU 核limits.memory: "512Mi"：限制使用 512MB 内存
Part 4：最佳实践—— 打造高效稳定的 Kubernetes 集群
除了上述基本概念和方法，还有一些最佳实践可以帮助你更好地管理 Kubernetes 集群的资源：
- 使用 ResourceQuota： ResourceQuota 可以限制一个 Namespace 中所有 Pod 的资源总和，防止某个 Namespace 占用过多资源，影响其他 Namespace 的运行。这就像给每个租户分配固定的“房产份额”，避免“富豪”占用过多“公共资源”。
- 使用 LimitRange： LimitRange 可以为 Namespace 中的所有 Pod 设置默认的资源请求和限制，简化资源管理，并确保所有 Pod 都设置了合理的资源限制。这就像给每个租户提供“标准装修方案”，确保每个“房子”都符合基本标准。
- 监控和告警： 使用监控工具，例如 Prometheus、Grafana 等，监控集群的资源使用情况，并设置告警规则，及时发现资源瓶颈和异常情况。这就像给你的“房产”安装了“智能安防系统”，随时监控“房屋”状态。
- 根据实际情况进行调整： 资源请求和限制不是一成不变的，需要根据应用的实际运行情况进行调整。定期回顾应用的资源使用情况，并根据需要进行调整。这就像定期对“房屋”进行“维护升级”，确保“房屋”始终处于最佳状态。
-
Pod QoS: Kubernetes 使用 QoS (Quality of Service) 类来对 Pod 进行优先级排序，以便在资源紧张时进行调度和驱逐。常见的 QoS 类有：
- Guaranteed: 当一个 Pod 中的所有容器都设置了 equal 的 Requests 和 Limits，并且 CPU 和 Memory 都有设置时，该 Pod 属于 Guaranteed QoS 类。这是优先级最高的 QoS 类。
- Burstable: 当一个 Pod 设置了资源请求，但没有设置资源限制，或者 Requests 不等于 Limits 时，该 Pod 属于 Burstable QoS 类。
- BestEffort: 当一个 Pod 既没有设置资源请求，也没有设置资源限制时，该 Pod 属于 BestEffort QoS 类。这是优先级最低的 QoS 类。
在资源紧张时，Kubernetes 会按照 BestEffort -> Burstable -> Guaranteed 的顺序驱逐 Pod。
Part 5：常见问题与解答
Q：我应该如何选择合适的资源请求和限制值？
A：没有一个通用的答案。最好的方法是进行性能测试和监控，并根据应用的实际运行情况进行调整。
Q：如果我的应用超过了资源限制会发生什么？
A：对于 CPU 资源，Kubernetes 会降低应用的 CPU 使用优先级，导致应用运行缓慢。对于内存资源，Kubernetes 可能会杀死应用 (OOMKilled)。
Q：我可以使用哪些工具来监控我的应用的资源使用情况？
A：有很多工具可以选择，例如 Prometheus、Grafana、Heapster、cAdvisor 等。
Q：我的资源请求和限制设置得很高，但我的应用仍然运行缓慢，这是为什么？
A：可能的原因有很多，例如：
- 节点资源不足： 即使你的 Pod 设置了很高的资源请求和限制，如果节点上的资源不足，应用仍然会受到影响。
- 网络问题： 网络延迟或带宽限制也可能导致应用运行缓慢。
- 代码问题： 应用本身的代码可能存在性能问题。
结语：资源管理，永无止境
Kubernetes 资源请求与限制是一个复杂而重要的概念，它关系到你的应用在集群中的运行效率和稳定性。希望通过今天的“云原生房产中介”讲座，大家能够更好地理解和应用这个概念，打造高效稳定的 Kubernetes 集群！
记住，资源管理是一个持续的过程，需要不断地监控、调整和优化。就像经营一家“云原生房产公司”，需要不断地学习和进步，才能在激烈的市场竞争中脱颖而出！ 💪
最后，祝大家都能在 Kubernetes 的世界里，找到属于自己的“豪宅”，跑出最高的效率！ 🚀 感谢大家的聆听！ 😊