Kubernetes 资源调度与弹性伸缩：Schedule、Metric、HPA 与 Quota

xianyuCcCcCCCcc2026-10-28 12:45

Kubernetes 资源调度与弹性伸缩：Schedule、Metric、HPA 与 Quota

引言

在 Kubernetes 集群中，计算资源（CPU、内存）是有限的，而应用的需求是动态多变的。如何让 Pod 精准地运行在最合适的硬件节点上？如何根据业务的峰谷自动扩缩容？如何防止某个核心业务因资源超卖而拖垮整个集群？这些都是云原生架构中必须解决的核心痛点。

本文将结合底层原理与大量的实战演练，深入拆解 K8s 的调度机制（Node 亲和、污点容忍、节点维护）、资源监控基础设施（Metrics Server）、自动伸缩利器（HPA 及其行为策略）以及命名空间级别的资源配额管控（ResourceQuota/LimitRange），带你全面构建一个稳定、高效的 K8s 资源管理体系。

### 文章目录

  • [Kubernetes 资源调度与弹性伸缩：Schedule、Metric、HPA 与 Quota](#文章目录 Kubernetes 资源调度与弹性伸缩：Schedule、Metric、HPA 与 Quota 引言 @[toc] 一、Pod 调度控制策略深度解析 1.1 nodeName（最暴力的强制绑定） 1.2 nodeSelector（基于标签的硬性约束） 1.3 亲和性（Affinity）深度实践 二、高级调度机制：Taint 与 Toleration 2.1 污点的三种 Effect 2.2 多污点与多容忍的匹配逻辑 三、集群节点维护：Cordon 与 Drain 3.1 cordon（标记不可调度） 3.2 drain（驱逐节点） 四、Metrics Server 与 HPA 自动伸缩 4.1 Metrics Server 部署与避坑 4.2 HPA 基于 CPU 压测扩缩容 4.3 HPA 基于内存压测与 OOMKilled 4.4 HPA 精细管控行为（Behavior） 五、资源配额与限制：Quota 与 Limits 5.1 ResourceQuota 命名空间配额 5.2 LimitRange 默认值与边界 5.3 Request 与 Limits 的底层原理)
  • [引言](#文章目录 Kubernetes 资源调度与弹性伸缩：Schedule、Metric、HPA 与 Quota 引言 @[toc] 一、Pod 调度控制策略深度解析 1.1 nodeName（最暴力的强制绑定） 1.2 nodeSelector（基于标签的硬性约束） 1.3 亲和性（Affinity）深度实践 二、高级调度机制：Taint 与 Toleration 2.1 污点的三种 Effect 2.2 多污点与多容忍的匹配逻辑 三、集群节点维护：Cordon 与 Drain 3.1 cordon（标记不可调度） 3.2 drain（驱逐节点） 四、Metrics Server 与 HPA 自动伸缩 4.1 Metrics Server 部署与避坑 4.2 HPA 基于 CPU 压测扩缩容 4.3 HPA 基于内存压测与 OOMKilled 4.4 HPA 精细管控行为（Behavior） 五、资源配额与限制：Quota 与 Limits 5.1 ResourceQuota 命名空间配额 5.2 LimitRange 默认值与边界 5.3 Request 与 Limits 的底层原理)
  • [@toc](#文章目录 Kubernetes 资源调度与弹性伸缩：Schedule、Metric、HPA 与 Quota 引言 @[toc] 一、Pod 调度控制策略深度解析 1.1 nodeName（最暴力的强制绑定） 1.2 nodeSelector（基于标签的硬性约束） 1.3 亲和性（Affinity）深度实践 二、高级调度机制：Taint 与 Toleration 2.1 污点的三种 Effect 2.2 多污点与多容忍的匹配逻辑 三、集群节点维护：Cordon 与 Drain 3.1 cordon（标记不可调度） 3.2 drain（驱逐节点） 四、Metrics Server 与 HPA 自动伸缩 4.1 Metrics Server 部署与避坑 4.2 HPA 基于 CPU 压测扩缩容 4.3 HPA 基于内存压测与 OOMKilled 4.4 HPA 精细管控行为（Behavior） 五、资源配额与限制：Quota 与 Limits 5.1 ResourceQuota 命名空间配额 5.2 LimitRange 默认值与边界 5.3 Request 与 Limits 的底层原理)
  • [一、Pod 调度控制策略深度解析](#文章目录 Kubernetes 资源调度与弹性伸缩：Schedule、Metric、HPA 与 Quota 引言 @[toc] 一、Pod 调度控制策略深度解析 1.1 nodeName（最暴力的强制绑定） 1.2 nodeSelector（基于标签的硬性约束） 1.3 亲和性（Affinity）深度实践 二、高级调度机制：Taint 与 Toleration 2.1 污点的三种 Effect 2.2 多污点与多容忍的匹配逻辑 三、集群节点维护：Cordon 与 Drain 3.1 cordon（标记不可调度） 3.2 drain（驱逐节点） 四、Metrics Server 与 HPA 自动伸缩 4.1 Metrics Server 部署与避坑 4.2 HPA 基于 CPU 压测扩缩容 4.3 HPA 基于内存压测与 OOMKilled 4.4 HPA 精细管控行为（Behavior） 五、资源配额与限制：Quota 与 Limits 5.1 ResourceQuota 命名空间配额 5.2 LimitRange 默认值与边界 5.3 Request 与 Limits 的底层原理)
  • [1.1 nodeName（最暴力的强制绑定）](#文章目录 Kubernetes 资源调度与弹性伸缩：Schedule、Metric、HPA 与 Quota 引言 @[toc] 一、Pod 调度控制策略深度解析 1.1 nodeName（最暴力的强制绑定） 1.2 nodeSelector（基于标签的硬性约束） 1.3 亲和性（Affinity）深度实践 二、高级调度机制：Taint 与 Toleration 2.1 污点的三种 Effect 2.2 多污点与多容忍的匹配逻辑 三、集群节点维护：Cordon 与 Drain 3.1 cordon（标记不可调度） 3.2 drain（驱逐节点） 四、Metrics Server 与 HPA 自动伸缩 4.1 Metrics Server 部署与避坑 4.2 HPA 基于 CPU 压测扩缩容 4.3 HPA 基于内存压测与 OOMKilled 4.4 HPA 精细管控行为（Behavior） 五、资源配额与限制：Quota 与 Limits 5.1 ResourceQuota 命名空间配额 5.2 LimitRange 默认值与边界 5.3 Request 与 Limits 的底层原理)
  • [1.2 nodeSelector（基于标签的硬性约束）](#文章目录 Kubernetes 资源调度与弹性伸缩：Schedule、Metric、HPA 与 Quota 引言 @[toc] 一、Pod 调度控制策略深度解析 1.1 nodeName（最暴力的强制绑定） 1.2 nodeSelector（基于标签的硬性约束） 1.3 亲和性（Affinity）深度实践 二、高级调度机制：Taint 与 Toleration 2.1 污点的三种 Effect 2.2 多污点与多容忍的匹配逻辑 三、集群节点维护：Cordon 与 Drain 3.1 cordon（标记不可调度） 3.2 drain（驱逐节点） 四、Metrics Server 与 HPA 自动伸缩 4.1 Metrics Server 部署与避坑 4.2 HPA 基于 CPU 压测扩缩容 4.3 HPA 基于内存压测与 OOMKilled 4.4 HPA 精细管控行为（Behavior） 五、资源配额与限制：Quota 与 Limits 5.1 ResourceQuota 命名空间配额 5.2 LimitRange 默认值与边界 5.3 Request 与 Limits 的底层原理)
  • [1.3 亲和性（Affinity）深度实践](#文章目录 Kubernetes 资源调度与弹性伸缩：Schedule、Metric、HPA 与 Quota 引言 @[toc] 一、Pod 调度控制策略深度解析 1.1 nodeName（最暴力的强制绑定） 1.2 nodeSelector（基于标签的硬性约束） 1.3 亲和性（Affinity）深度实践 二、高级调度机制：Taint 与 Toleration 2.1 污点的三种 Effect 2.2 多污点与多容忍的匹配逻辑 三、集群节点维护：Cordon 与 Drain 3.1 cordon（标记不可调度） 3.2 drain（驱逐节点） 四、Metrics Server 与 HPA 自动伸缩 4.1 Metrics Server 部署与避坑 4.2 HPA 基于 CPU 压测扩缩容 4.3 HPA 基于内存压测与 OOMKilled 4.4 HPA 精细管控行为（Behavior） 五、资源配额与限制：Quota 与 Limits 5.1 ResourceQuota 命名空间配额 5.2 LimitRange 默认值与边界 5.3 Request 与 Limits 的底层原理)
  • [二、高级调度机制：Taint 与 Toleration](#文章目录 Kubernetes 资源调度与弹性伸缩：Schedule、Metric、HPA 与 Quota 引言 @[toc] 一、Pod 调度控制策略深度解析 1.1 nodeName（最暴力的强制绑定） 1.2 nodeSelector（基于标签的硬性约束） 1.3 亲和性（Affinity）深度实践 二、高级调度机制：Taint 与 Toleration 2.1 污点的三种 Effect 2.2 多污点与多容忍的匹配逻辑 三、集群节点维护：Cordon 与 Drain 3.1 cordon（标记不可调度） 3.2 drain（驱逐节点） 四、Metrics Server 与 HPA 自动伸缩 4.1 Metrics Server 部署与避坑 4.2 HPA 基于 CPU 压测扩缩容 4.3 HPA 基于内存压测与 OOMKilled 4.4 HPA 精细管控行为（Behavior） 五、资源配额与限制：Quota 与 Limits 5.1 ResourceQuota 命名空间配额 5.2 LimitRange 默认值与边界 5.3 Request 与 Limits 的底层原理)
  • [2.1 污点的三种 Effect](#文章目录 Kubernetes 资源调度与弹性伸缩：Schedule、Metric、HPA 与 Quota 引言 @[toc] 一、Pod 调度控制策略深度解析 1.1 nodeName（最暴力的强制绑定） 1.2 nodeSelector（基于标签的硬性约束） 1.3 亲和性（Affinity）深度实践 二、高级调度机制：Taint 与 Toleration 2.1 污点的三种 Effect 2.2 多污点与多容忍的匹配逻辑 三、集群节点维护：Cordon 与 Drain 3.1 cordon（标记不可调度） 3.2 drain（驱逐节点） 四、Metrics Server 与 HPA 自动伸缩 4.1 Metrics Server 部署与避坑 4.2 HPA 基于 CPU 压测扩缩容 4.3 HPA 基于内存压测与 OOMKilled 4.4 HPA 精细管控行为（Behavior） 五、资源配额与限制：Quota 与 Limits 5.1 ResourceQuota 命名空间配额 5.2 LimitRange 默认值与边界 5.3 Request 与 Limits 的底层原理)
  • [2.2 多污点与多容忍的匹配逻辑](#文章目录 Kubernetes 资源调度与弹性伸缩：Schedule、Metric、HPA 与 Quota 引言 @[toc] 一、Pod 调度控制策略深度解析 1.1 nodeName（最暴力的强制绑定） 1.2 nodeSelector（基于标签的硬性约束） 1.3 亲和性（Affinity）深度实践 二、高级调度机制：Taint 与 Toleration 2.1 污点的三种 Effect 2.2 多污点与多容忍的匹配逻辑 三、集群节点维护：Cordon 与 Drain 3.1 cordon（标记不可调度） 3.2 drain（驱逐节点） 四、Metrics Server 与 HPA 自动伸缩 4.1 Metrics Server 部署与避坑 4.2 HPA 基于 CPU 压测扩缩容 4.3 HPA 基于内存压测与 OOMKilled 4.4 HPA 精细管控行为（Behavior） 五、资源配额与限制：Quota 与 Limits 5.1 ResourceQuota 命名空间配额 5.2 LimitRange 默认值与边界 5.3 Request 与 Limits 的底层原理)
  • [三、集群节点维护：Cordon 与 Drain](#文章目录 Kubernetes 资源调度与弹性伸缩：Schedule、Metric、HPA 与 Quota 引言 @[toc] 一、Pod 调度控制策略深度解析 1.1 nodeName（最暴力的强制绑定） 1.2 nodeSelector（基于标签的硬性约束） 1.3 亲和性（Affinity）深度实践 二、高级调度机制：Taint 与 Toleration 2.1 污点的三种 Effect 2.2 多污点与多容忍的匹配逻辑 三、集群节点维护：Cordon 与 Drain 3.1 cordon（标记不可调度） 3.2 drain（驱逐节点） 四、Metrics Server 与 HPA 自动伸缩 4.1 Metrics Server 部署与避坑 4.2 HPA 基于 CPU 压测扩缩容 4.3 HPA 基于内存压测与 OOMKilled 4.4 HPA 精细管控行为（Behavior） 五、资源配额与限制：Quota 与 Limits 5.1 ResourceQuota 命名空间配额 5.2 LimitRange 默认值与边界 5.3 Request 与 Limits 的底层原理)
  • [3.1 cordon（标记不可调度）](#文章目录 Kubernetes 资源调度与弹性伸缩：Schedule、Metric、HPA 与 Quota 引言 @[toc] 一、Pod 调度控制策略深度解析 1.1 nodeName（最暴力的强制绑定） 1.2 nodeSelector（基于标签的硬性约束） 1.3 亲和性（Affinity）深度实践 二、高级调度机制：Taint 与 Toleration 2.1 污点的三种 Effect 2.2 多污点与多容忍的匹配逻辑 三、集群节点维护：Cordon 与 Drain 3.1 cordon（标记不可调度） 3.2 drain（驱逐节点） 四、Metrics Server 与 HPA 自动伸缩 4.1 Metrics Server 部署与避坑 4.2 HPA 基于 CPU 压测扩缩容 4.3 HPA 基于内存压测与 OOMKilled 4.4 HPA 精细管控行为（Behavior） 五、资源配额与限制：Quota 与 Limits 5.1 ResourceQuota 命名空间配额 5.2 LimitRange 默认值与边界 5.3 Request 与 Limits 的底层原理)
  • [3.2 drain（驱逐节点）](#文章目录 Kubernetes 资源调度与弹性伸缩：Schedule、Metric、HPA 与 Quota 引言 @[toc] 一、Pod 调度控制策略深度解析 1.1 nodeName（最暴力的强制绑定） 1.2 nodeSelector（基于标签的硬性约束） 1.3 亲和性（Affinity）深度实践 二、高级调度机制：Taint 与 Toleration 2.1 污点的三种 Effect 2.2 多污点与多容忍的匹配逻辑 三、集群节点维护：Cordon 与 Drain 3.1 cordon（标记不可调度） 3.2 drain（驱逐节点） 四、Metrics Server 与 HPA 自动伸缩 4.1 Metrics Server 部署与避坑 4.2 HPA 基于 CPU 压测扩缩容 4.3 HPA 基于内存压测与 OOMKilled 4.4 HPA 精细管控行为（Behavior） 五、资源配额与限制：Quota 与 Limits 5.1 ResourceQuota 命名空间配额 5.2 LimitRange 默认值与边界 5.3 Request 与 Limits 的底层原理)
  • [四、Metrics Server 与 HPA 自动伸缩](#文章目录 Kubernetes 资源调度与弹性伸缩：Schedule、Metric、HPA 与 Quota 引言 @[toc] 一、Pod 调度控制策略深度解析 1.1 nodeName（最暴力的强制绑定） 1.2 nodeSelector（基于标签的硬性约束） 1.3 亲和性（Affinity）深度实践 二、高级调度机制：Taint 与 Toleration 2.1 污点的三种 Effect 2.2 多污点与多容忍的匹配逻辑 三、集群节点维护：Cordon 与 Drain 3.1 cordon（标记不可调度） 3.2 drain（驱逐节点） 四、Metrics Server 与 HPA 自动伸缩 4.1 Metrics Server 部署与避坑 4.2 HPA 基于 CPU 压测扩缩容 4.3 HPA 基于内存压测与 OOMKilled 4.4 HPA 精细管控行为（Behavior） 五、资源配额与限制：Quota 与 Limits 5.1 ResourceQuota 命名空间配额 5.2 LimitRange 默认值与边界 5.3 Request 与 Limits 的底层原理)
  • [4.1 Metrics Server 部署与避坑](#文章目录 Kubernetes 资源调度与弹性伸缩：Schedule、Metric、HPA 与 Quota 引言 @[toc] 一、Pod 调度控制策略深度解析 1.1 nodeName（最暴力的强制绑定） 1.2 nodeSelector（基于标签的硬性约束） 1.3 亲和性（Affinity）深度实践 二、高级调度机制：Taint 与 Toleration 2.1 污点的三种 Effect 2.2 多污点与多容忍的匹配逻辑 三、集群节点维护：Cordon 与 Drain 3.1 cordon（标记不可调度） 3.2 drain（驱逐节点） 四、Metrics Server 与 HPA 自动伸缩 4.1 Metrics Server 部署与避坑 4.2 HPA 基于 CPU 压测扩缩容 4.3 HPA 基于内存压测与 OOMKilled 4.4 HPA 精细管控行为（Behavior） 五、资源配额与限制：Quota 与 Limits 5.1 ResourceQuota 命名空间配额 5.2 LimitRange 默认值与边界 5.3 Request 与 Limits 的底层原理)
  • [4.2 HPA 基于 CPU 压测扩缩容](#文章目录 Kubernetes 资源调度与弹性伸缩：Schedule、Metric、HPA 与 Quota 引言 @[toc] 一、Pod 调度控制策略深度解析 1.1 nodeName（最暴力的强制绑定） 1.2 nodeSelector（基于标签的硬性约束） 1.3 亲和性（Affinity）深度实践 二、高级调度机制：Taint 与 Toleration 2.1 污点的三种 Effect 2.2 多污点与多容忍的匹配逻辑 三、集群节点维护：Cordon 与 Drain 3.1 cordon（标记不可调度） 3.2 drain（驱逐节点） 四、Metrics Server 与 HPA 自动伸缩 4.1 Metrics Server 部署与避坑 4.2 HPA 基于 CPU 压测扩缩容 4.3 HPA 基于内存压测与 OOMKilled 4.4 HPA 精细管控行为（Behavior） 五、资源配额与限制：Quota 与 Limits 5.1 ResourceQuota 命名空间配额 5.2 LimitRange 默认值与边界 5.3 Request 与 Limits 的底层原理)
  • [4.3 HPA 基于内存压测与 OOMKilled](#文章目录 Kubernetes 资源调度与弹性伸缩：Schedule、Metric、HPA 与 Quota 引言 @[toc] 一、Pod 调度控制策略深度解析 1.1 nodeName（最暴力的强制绑定） 1.2 nodeSelector（基于标签的硬性约束） 1.3 亲和性（Affinity）深度实践 二、高级调度机制：Taint 与 Toleration 2.1 污点的三种 Effect 2.2 多污点与多容忍的匹配逻辑 三、集群节点维护：Cordon 与 Drain 3.1 cordon（标记不可调度） 3.2 drain（驱逐节点） 四、Metrics Server 与 HPA 自动伸缩 4.1 Metrics Server 部署与避坑 4.2 HPA 基于 CPU 压测扩缩容 4.3 HPA 基于内存压测与 OOMKilled 4.4 HPA 精细管控行为（Behavior） 五、资源配额与限制：Quota 与 Limits 5.1 ResourceQuota 命名空间配额 5.2 LimitRange 默认值与边界 5.3 Request 与 Limits 的底层原理)
  • [4.4 HPA 精细管控行为（Behavior）](#文章目录 Kubernetes 资源调度与弹性伸缩：Schedule、Metric、HPA 与 Quota 引言 @[toc] 一、Pod 调度控制策略深度解析 1.1 nodeName（最暴力的强制绑定） 1.2 nodeSelector（基于标签的硬性约束） 1.3 亲和性（Affinity）深度实践 二、高级调度机制：Taint 与 Toleration 2.1 污点的三种 Effect 2.2 多污点与多容忍的匹配逻辑 三、集群节点维护：Cordon 与 Drain 3.1 cordon（标记不可调度） 3.2 drain（驱逐节点） 四、Metrics Server 与 HPA 自动伸缩 4.1 Metrics Server 部署与避坑 4.2 HPA 基于 CPU 压测扩缩容 4.3 HPA 基于内存压测与 OOMKilled 4.4 HPA 精细管控行为（Behavior） 五、资源配额与限制：Quota 与 Limits 5.1 ResourceQuota 命名空间配额 5.2 LimitRange 默认值与边界 5.3 Request 与 Limits 的底层原理)
  • [五、资源配额与限制：Quota 与 Limits](#文章目录 Kubernetes 资源调度与弹性伸缩：Schedule、Metric、HPA 与 Quota 引言 @[toc] 一、Pod 调度控制策略深度解析 1.1 nodeName（最暴力的强制绑定） 1.2 nodeSelector（基于标签的硬性约束） 1.3 亲和性（Affinity）深度实践 二、高级调度机制：Taint 与 Toleration 2.1 污点的三种 Effect 2.2 多污点与多容忍的匹配逻辑 三、集群节点维护：Cordon 与 Drain 3.1 cordon（标记不可调度） 3.2 drain（驱逐节点） 四、Metrics Server 与 HPA 自动伸缩 4.1 Metrics Server 部署与避坑 4.2 HPA 基于 CPU 压测扩缩容 4.3 HPA 基于内存压测与 OOMKilled 4.4 HPA 精细管控行为（Behavior） 五、资源配额与限制：Quota 与 Limits 5.1 ResourceQuota 命名空间配额 5.2 LimitRange 默认值与边界 5.3 Request 与 Limits 的底层原理)
  • [5.1 ResourceQuota 命名空间配额](#文章目录 Kubernetes 资源调度与弹性伸缩：Schedule、Metric、HPA 与 Quota 引言 @[toc] 一、Pod 调度控制策略深度解析 1.1 nodeName（最暴力的强制绑定） 1.2 nodeSelector（基于标签的硬性约束） 1.3 亲和性（Affinity）深度实践 二、高级调度机制：Taint 与 Toleration 2.1 污点的三种 Effect 2.2 多污点与多容忍的匹配逻辑 三、集群节点维护：Cordon 与 Drain 3.1 cordon（标记不可调度） 3.2 drain（驱逐节点） 四、Metrics Server 与 HPA 自动伸缩 4.1 Metrics Server 部署与避坑 4.2 HPA 基于 CPU 压测扩缩容 4.3 HPA 基于内存压测与 OOMKilled 4.4 HPA 精细管控行为（Behavior） 五、资源配额与限制：Quota 与 Limits 5.1 ResourceQuota 命名空间配额 5.2 LimitRange 默认值与边界 5.3 Request 与 Limits 的底层原理)
  • [5.2 LimitRange 默认值与边界](#文章目录 Kubernetes 资源调度与弹性伸缩：Schedule、Metric、HPA 与 Quota 引言 @[toc] 一、Pod 调度控制策略深度解析 1.1 nodeName（最暴力的强制绑定） 1.2 nodeSelector（基于标签的硬性约束） 1.3 亲和性（Affinity）深度实践 二、高级调度机制：Taint 与 Toleration 2.1 污点的三种 Effect 2.2 多污点与多容忍的匹配逻辑 三、集群节点维护：Cordon 与 Drain 3.1 cordon（标记不可调度） 3.2 drain（驱逐节点） 四、Metrics Server 与 HPA 自动伸缩 4.1 Metrics Server 部署与避坑 4.2 HPA 基于 CPU 压测扩缩容 4.3 HPA 基于内存压测与 OOMKilled 4.4 HPA 精细管控行为（Behavior） 五、资源配额与限制：Quota 与 Limits 5.1 ResourceQuota 命名空间配额 5.2 LimitRange 默认值与边界 5.3 Request 与 Limits 的底层原理)
  • [5.3 Request 与 Limits 的底层原理](#文章目录 Kubernetes 资源调度与弹性伸缩：Schedule、Metric、HPA 与 Quota 引言 @[toc] 一、Pod 调度控制策略深度解析 1.1 nodeName（最暴力的强制绑定） 1.2 nodeSelector（基于标签的硬性约束） 1.3 亲和性（Affinity）深度实践 二、高级调度机制：Taint 与 Toleration 2.1 污点的三种 Effect 2.2 多污点与多容忍的匹配逻辑 三、集群节点维护：Cordon 与 Drain 3.1 cordon（标记不可调度） 3.2 drain（驱逐节点） 四、Metrics Server 与 HPA 自动伸缩 4.1 Metrics Server 部署与避坑 4.2 HPA 基于 CPU 压测扩缩容 4.3 HPA 基于内存压测与 OOMKilled 4.4 HPA 精细管控行为（Behavior） 五、资源配额与限制：Quota 与 Limits 5.1 ResourceQuota 命名空间配额 5.2 LimitRange 默认值与边界 5.3 Request 与 Limits 的底层原理)

一、Pod 调度控制策略深度解析

Kubernetes 的默认调度器会自动为 Pod 寻找节点，但在特定业务场景下，我们需要人为干预。

1.1 nodeName（最暴力的强制绑定）

nodeName 直接指定节点名称，完全绕过调度器。

具体配置：

yaml 复制代码 
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: webapp
  name: webapp
spec:
  replicas: 2
  template:
    spec:
      # 添加nodeName配置
      nodeName: worker32.xianyu.cloud
      containers:
      - image: hub.xianyu.cloud/library/nginx
        name: nginx

现象观察：

text 复制代码 
NAME                        READY   STATUS    NODE
webapp-55c6b896bc-ns9m5     1/1     Running   worker32.xianyu.cloud
webapp-55c6b896bc-qr892     1/1     Running   worker32.xianyu.cloud

如果指定的节点不存在或资源不足，Pod 将不会运行，并报 OutOfmemory 错误。

1.2 nodeSelector（基于标签的硬性约束）

nodeSelector 通过匹配节点的 Label 决定调度位置。

操作演示：

bash 复制代码 
# 1. 查看节点标签
kubectl get node --show-labels 

# 2. 给 worker31 打上 SSD 标签
kubectl label node worker31.xianyu.cloud disktype=ssd

具体配置：

yaml 复制代码 
spec:
  # 添加 nodeSelector
  nodeSelector:
    disktype: ssd
  containers:
  - image: hub.xianyu.cloud/library/nginx
    name: nginx

现象观察 ：两个 Pod 均被调度到了 worker31。如果删除节点标签，此时不会触发重新部署 ；只有删除 Deployment 的 nodeSelector（kubectl patch deployment webapp --type json -p '[{"op":"remove","path":"/spec/template/spec/nodeSelector"}]'），才会自动触发重新部署，Pod 将重新均衡到多个节点。

1.3 亲和性（Affinity）深度实践

nodeSelector 只能做等值匹配，Affinity 支持硬性（Required）和软性（Preferred）策略。

节点亲和性：

yaml 复制代码 
spec:
  affinity:
    nodeAffinity:
      # 硬性要求：节点必须带有 CPU=L1 或 CPU=L2 的标签
      requiredDuringSchedulingIgnoredDuringExecution: 
        nodeSelectorTerms:
        - matchExpressions:
          - key: CPU
            operator: In
            values: [L1, L2]
      # 软性偏好：节点如果有 MEM=L2 的标签，得分权重更高（权重1-100）
      preferredDuringSchedulingIgnoredDuringExecution: 
      - weight: 1
        preference:
          matchExpressions:
          - key: MEM
            operator: In
            values: [L2]

现象观察：

  1. 节点未打标签时：Pod 为 Pending。
  2. 给 worker31 打 CPU=L1 标签后：Pod 被调度到 worker31。
  3. 给 worker32 也打上 CPU=L2 后重新部署：Pod 均衡调度到两个节点。
  4. 给 worker32 打上 MEM=L2 后重新部署：因为软性偏好，Pod 全部优先调度到了 worker32。

Pod 间亲和与反亲和（高可用必配） ：

具体配置：确保同一个应用的多个副本必须分散在不同物理节点上。

yaml 复制代码 
spec:
  affinity:
    podAntiAffinity:
      requiredDuringSchedulingIgnoredDuringExecution:
      - labelSelector:
          matchExpressions:
          - key: app
            operator: In
            values: [store]
        topologyKey: "kubernetes.io/hostname"

现象观察 ：由于集群只有 2 个 worker 节点，当你创建 3 个副本时，前两个分别运行在 worker31 和 worker32，第 3 个处于 Pending 状态。事件日志会提示：didn't match pod anti-affinity rules。

二、高级调度机制：Taint 与 Toleration

污点是节点主动拒绝 Pod，容忍度是 Pod 声明能接受的污点。

2.1 污点的三种 Effect

  • NoSchedule：硬性限制，未容忍的 Pod 无法调度。
  • PreferNoSchedule：软性限制，尽量避开。
  • NoExecute：驱逐。已在此节点且未容忍的 Pod 会被立刻踢走。

操作演示：给节点打上污点。

bash 复制代码 
kubectl taint nodes worker31.xianyu.cloud CPU=L1:NoSchedule
kubectl taint nodes worker32.xianyu.cloud CPU=L2:NoSchedule

具体配置：Pod 声明容忍度。

yaml 复制代码 
spec:
  tolerations:
  - key: "CPU"
    operator: "Equal"
    value: "L1" # 如果写L3，将无法调度
    effect: "NoSchedule"

现象观察 ：如果写容忍 L3，Pod 状态为 Pending，事件提示：0/3 nodes are available: 1 node(s) had untolerated taint {CPU: L1}, 1 node(s) had untolerated taint {CPU: L2}...。改成 L1 后，Pod 成功分配到 worker31。

2.2 多污点与多容忍的匹配逻辑

当节点有多个污点（CPU=L1:NoSchedule、CPU=L1:NoExecute、MEM=L2:NoSchedule），Pod 必须配置对应的所有容忍度才能调度成功。漏掉任何一个污点的容忍度，都会导致 Pod 无法运行。

三、集群节点维护：Cordon 与 Drain

3.1 cordon（标记不可调度）

bash 复制代码 
kubectl cordon worker31.xianyu.cloud 
kubectl get nodes
# worker31.xianyu.cloud   Ready,SchedulingDisabled   <none>   9d    v1.30.2

此时新建的 Pod 会自动避开该节点。

3.2 drain（驱逐节点）

bash 复制代码 
# 默认情况下会报错，因为不能直接删除 DaemonSet 控制的 Pod
kubectl drain worker31.xianyu.cloud 
# error: cannot delete DaemonSet-managed Pods (use --ignore-daemonsets to ignore)

# 正确姿势：
kubectl drain worker31.xianyu.cloud --ignore-daemonsets
# 输出：
# evicting pod xianyu/web-59b9bb7664-jkb5q
# node/worker31.xianyu.cloud evicted

维护完成后，使用 kubectl uncordon worker31.xianyu.cloud 恢复调度。

四、Metrics Server 与 HPA 自动伸缩

4.1 Metrics Server 部署与避坑

kubectl top 依赖 Metrics Server 采集 Kubelet 数据。

核心排错 ：因为 K8s 是自签证书，必须修改部署 YAML 增加启动参数 - --kubelet-insecure-tls，否则 Pod 会不断 CrashLoopBackOff。

验证是否成功：

text 复制代码 
NAME                  CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%   
master30.xianyu.cloud   97m          4%     1328Mi          35%       
worker31.xianyu.cloud   49m          2%     912Mi           24%

4.2 HPA 基于 CPU 压测扩缩容

操作演示：创建 HPA（最少 2 个，最多 5 个，CPU 目标 80%）。

bash 复制代码 
kubectl autoscale deployment web --max=5 --min=2 --cpu-percent=80

必须为 Pod 指定 requests，否则 HPA 的 TARGETS 会显示 cpu: <unknown>/80%。

yaml 复制代码 
        resources:
          limits: 
            cpu: 100m
            memory: 200Mi

压测与现象观察：

bash 复制代码 
# 开启 100 并发，总请求数 300000
ab -n 300000 -c 100 http://10.100.255.92/

观察过程（每 20 秒左右触发一次扩容）：

  1. 初始状态：cpu: 100%/80%，REPLICAS 为 2。
  2. 触发扩容：REPLICAS 变 3，新建 Pod。
  3. 持续负载：REPLICAS 变 4，再变 5。
  4. 停止压测：负载降低，受冷却窗口影响，稍后自动缩减回 2。

4.3 HPA 基于内存压测与 OOMKilled

实战环境：挂载 200M 大文件，让 Nginx 返回大响应体。

yaml 复制代码 
        volumeMounts:
        - name: big-file
          mountPath: /usr/share/nginx/html
      volumes:
      - name: big-file
        hostPath:
          path: /www

HPA 配置：

yaml 复制代码 
  metrics:
  - resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 60
    type: Resource

压测现象 ：使用 ab 压测 http://<ip>/big.img。内存飙升触发扩容，REPLICAS 从 2 依次升至 5。如果压测过于猛烈，超过 Limits 限制，Pod 会触发 OOM：

text 复制代码 
NAME                  READY   STATUS      RESTARTS     AGE
web-88cff78bb-2b7vh   0/1     OOMKilled   1 (2s ago)   3s

4.4 HPA 精细管控行为（Behavior）

通过 behavior 字段控制扩缩容的节奏。

平滑扩容（scaleUp）：

yaml 复制代码 
behavior:
  scaleUp:
    stabilizationWindowSeconds: 60 # 稳定 60 秒确认持续高负载才扩容
    policies:
    - type: Percent
      value: 20
      periodSeconds: 30 # 每 30s 最多扩容 20%
    - type: Pods
      value: 4
      periodSeconds: 30 # 每 30s 最多新增 4 个
    selectPolicy: Min # 保守扩容

激进缩容（scaleDown）：

yaml 复制代码 
  scaleDown:
    stabilizationWindowSeconds: 30 # 负载下降 30 秒即开始缩容
    policies:
    - type: Percent
      value: 100
      periodSeconds: 15 # 每 15s 允许直接缩容 100%
    selectPolicy: Max

五、资源配额与限制：Quota 与 Limits

5.1 ResourceQuota 命名空间配额

具体配置：

yaml 复制代码 
apiVersion: v1
kind: ResourceQuota
metadata:
  name: myquota
spec:
  hard:
    pods: "2"
    requests.cpu: 1000m
    requests.memory: "2048Mi"

现象观察：当部署 3 个副本时，因为配额限制最多 2 个 Pod，第 3 个 Pod 创建失败，Deployment 事件中会报错：

text 复制代码 
Error creating: pods "web-96d5df5c8-xg6c9" is forbidden: exceeded quota: myquota, requested: pods=1, used: pods=2, limited: pods=2

5.2 LimitRange 默认值与边界

具体配置：

yaml 复制代码 
apiVersion: v1
kind: LimitRange
metadata:
  name: mylimit
spec:
  limits:
    - type: Container
      max:
        cpu: 1
        memory: 1024Mi
      min:
        cpu: 100m
        memory: 128Mi
      default:
        cpu: 500m
        memory: 512Mi
      defaultRequest:
        cpu: 200m
        memory: 256Mi

核心约束 ：min <= defaultRequest <= default <= max。

  • 未指定 resources ：Pod 自动注入 default 为 limits，defaultRequest 为 requests。压测 CPU 时，kubectl top 显示稳定在 501m 左右。
  • 只指定 limits 且大于 max ：直接报错 maximum cpu usage per Container is 1, but limit is 1100m。
  • 只指定 limits 且在范围内：requests 自动等于 limits。
  • 只指定 requests 且在范围内：limits 自动取 default 值。

5.3 Request 与 Limits 的底层原理

  • requests：调度依据，保障 Pod 能拿到的最低资源。
  • limits ：Cgroup 限制。
    • CPU 超限：进程变慢，不会被杀。
    • 内存超限 ：触发 OOM Killer ，Pod 状态变 OOMKilled 并重启。
  • QoS 等级：节点资源吃紧时，优先驱逐 BestEffort（无 requests/limits）的 Pod，最后驱逐 Guaranteed（requests 严格等于 limits）的 Pod。
相关推荐
分布式存储与RustFS2 小时前
在 1Panel 应用商店部署 RustFS：安装、配置与验证步骤
云原生·开源·对象存储·分布式存储·s3·rustfs·性能基准
我不会起名字3222 小时前
滚动更新时请求 502：Pod 终止与 endpoint 摘除的时间差
kubernetes·滚动更新·排查·优雅停机
知已难寻3 小时前
第 5 篇 · 云原生生态与实践：微服务、DevOps、可观测性与 Serverless
大数据·linux·服务器·微服务·云原生·云计算·devops
孔令飞3 小时前
AI 时代岗位调研分析：调研了近3000份AI岗位描述，分享下调研结果
云原生·go·ai编程
L0208245 小时前
Kubernetes Service 与 kube‑proxy 深度详解
运维·算法·云原生·容器·贪心算法·kubernetes
SatanII5 小时前
Kubernetes Ingress
kubernetes·ingress
SatanII5 小时前
kubernetes service && proxy
云原生·容器·kubernetes
艾伦_耶格宇5 小时前
【kubernetes - 1.28版本】-1 kubernetes基础
云原生·容器·kubernetes
时间售卖铺5 小时前
MySQL存储过程流程控制全解析
运维·数据库·mysql·云原生
热门推荐
01如何新建文件夹？ 电脑新建文件夹的4种方法02国内可直接用、免费额度/永久免费的大模型API清单（含 SiliconFlow、火山、阿里、智谱、百度、Kimi、DeepSeek、DMXAPI 等）03历年考研数学一、数学二、数学三真题试卷及答案PDF04GitHub 镜像站点05几个好用的ip纯净度检测网站06昇腾910B系列芯片完全指南：四款型号对比、服务器选型与大模型部署实战07苹果iPA游戏软件资源下载网站08CVE-2026-91403 高危漏洞预警：Java JSSE 信任链被攻破 全场景修复方案与Linux系统级彻底清理实操09蜘蛛磁力 搜索引擎大全，如何使用蜘蛛磁力查找磁力链接10微信历史版本含下载地址（ Windows PC | 安卓 | MAC ）及设置微信不更新