Kubernetes 入门教程之三

发表于 2025-09-10 阅读次数：评论数：本文字数： 12k 阅读时长 ≈ 11 分钟

大纲

Kubernetes 核心技术

Controller 的介绍

Pod 与 Controller（控制器）的关系

Pod 通过 Controller 进行运维管理，包括创建、扩缩容、滚动更新等操作。
Pod 与 Controller 之间是通过 Label（标签）和 Label Selector（标签选择器）机制建立关联关系。
Controller 通过识别 Pod 的 Label（标签）来实现对一组 Pod 的集中管理。

Replication Controller（RC）

RC 的概念

Replication Controller（RC）是 Kubernetes 系统中的核心概念之一。当定义一个 RC 并将其提交到 Kubernetes 集群后，Master 节点上的 Controller Manager 组件会接收到通知，并持续监控集群中 Pod 的运行状态。

RC 的作用

Pod 的副本数量管理
- 确保集群中实际运行的 Pod 副本数量与 RC 定义的期望值（spec.replicas）保持一致：
  - 如果运行的 Pod 副本数量过多，RC 会自动停止并删除多余的 Pod；
  - 如果运行的 Pod 副本数量不足，RC 会自动创建新的 Pod 来补足数量。
Pod 的自动修复能力
- 当 Pod 因故障或异常退出时，RC 会自动创建新的 Pod 来替代，确保服务始终可用。
Pod 的弹性伸缩能力
- 用户可以通过调整 RC 定义中的副本数，实现 Pod 的动态扩缩容（Scaling），从而根据业务需求灵活提升或降低服务处理能力。
- 比如：kubectl scale rc nginx --replicas=5

RS 替代 RC

从 Kubernetes 1.2 版本开始，Replica Set（RS）已经逐渐取代 Replication Controller（RC），成为更常用的 Pod 副本管理控制器。二者的演进说明如下：

命名冲突
- 由于 Replication Controller 与 Kubernetes 代码模块中同名，在 Kubernetes 1.2 版本中，RC 升级为新的概念 Replica Set ，官方将其定义为 RC 的下一代版本。
主要区别
- Replication Controller：只支持基于等式的 Label Selector，如 app=nginx。
- Replica Set ：除了支持等式的 Label Selector 外，还支持基于集合式的 Label Selector，如 in、notin、exists 等更复杂的匹配规则。
使用场景
- 在实际工作中，很少单独使用 Replica Set，它通常由 Deployment 管理。Deployment 提供了更高层次的功能，包括 Pod 创建、删除、更新的完整编排与滚动升级机制。
- 在生产环境中，通常通过 Deployment → Replica Set → Pod 这一管理链路进行编排和管理。

使用 RC / RS 管理 Pod 的原因

避免直接创建 Pod
- 不建议越过 RC / RS 直接创建 Pod，因为直接创建的 Pod 无法自动修复或扩缩容。
- RC 或 RS 通过副本管理机制，可以实现 Pod 的自动创建、补足、替换和删除。
提升容灾能力
- 当节点故障或 Pod 异常退出时，RC / RS 会自动创建新的 Pod，确保服务稳定可用，减少因节点崩溃等意外带来的损失。
适用于单副本场景
- 即使应用只有一个 Pod 副本，也强烈建议使用 RC / RS 来管理 Pod，以获得自动恢复和高可用能力。

Replica Set（RS）

RS 的概念

从 Kubernetes 1.2 版本开始，Replica Set（RS）已经逐渐取代 Replication Controller（RC），成为更常用的 Pod 副本管理控制器。Replica Set 是 Replication Controller 的升级版本，支持更强大的 Label Selector，二者的关系如下：

功能一致
- Replica Set 与 Replication Controller 在功能上没有本质的区别，二者的核心作用都是确保 Pod 副本数量与预期值保持一致。
用法差异
- Replication Controller 只支持基于等式的 Label Selector，例如 app=nginx。
- Replica Set 除了支持等式的 Label Selector 外，还支持基于集合式的 Label Selector，如 in、notin、exists 等更复杂的匹配规则。
官方建议
- Kubernetes 官方强烈建议避免直接使用 Replica Set，而是通过 Deployment 来创建和管理 Replica Set 及其 Pod，以此获得滚动更新、回滚等高级功能。
- 在生产环境中，通常通过 Deployment → Replica Set → Pod 这一管理链路进行编排和管理。

Deployment

Deployment 的概念

Deployment 控制器是 Kubernetes 在 1.2 版本中引入的新概念，主要目的是为了更好地解决 Pod 的编排问题。

主要功能
- 部署和管理无状态应用；
- 维护期望数量的 Pod 实例，支持自动修复异常 Pod；
- 提供滚动升级、灰度发布、快速回滚等版本管理功能；
- 支持自动扩缩容（结合 HPA 使用）；
- 与 Service 配合，实现应用的高可用与负载均衡。
实现机制
- Deployment 内部通过 Replica Set 管理 Pod 副本：
  - Replica Set 负责 Pod 的实际创建、扩容和缩容；
  - Deployment 作为更高一层控制器，可以管理多个 Replica Set，从而支持版本管理和回滚。
- 当更新镜像或配置时，Deployment 会创建新的 Replica Set 并逐步替换旧 Pod，实现平滑升级。
定义特点
- 定义结构与 Replica Set 类似，但提供了更高层的编排能力：
  - Replica Set 的 Kind 类型：ReplicaSet；
  - Deployment 的 Kind 类型：Deployment，支持滚动更新、回滚、暂停、恢复、历史版本管理等高级功能。
- 可通过 YAML 文件、命令行等多种方式定义，易于集成到 CI/CD 流水线中。
适用场景
- 部署无状态 Web 应用，如 Nginx、前端服务、API 网关；结合 Service 实现高可用和负载均衡，支持滚动更新不中断访问；
- 部署微服务中的业务服务实例，支持自动扩缩容，满足不同流量需求；通过滚动更新和灰度发布，保证服务持续迭代；
- 部署无状态的计算或处理任务，如日志收集、ETL、数据清洗等；
- 部署一些无状态的基础设施，如 Prometheus、Grafana、Fluentd；
- 通过 Deployment 的版本控制能力，实现持续交付流程；支持分批滚动更新、A/B 测试和金丝雀发布。

StatefulSet

StatefulSet 的概念

StatefulSet 控制器是 Kubernetes 在 1.5 版本中引入的控制器，主要用于管理有状态应用，为每个 Pod 提供固定身份标识、稳定的网络标识符和持久化存储，确保 Pod 的部署和管理有序进行。

主要功能
- 部署和管理有状态应用；
- 保证每个 Pod 具有固定的标识符（名称、网络标识）；
- 按照顺序有序创建、有序扩容、有序删除 Pod；
- 结合 PersistentVolume 为每个 Pod 提供独立的持久化存储；
- 确保 Pod 在重启或迁移后仍能保持原有的存储和网络标识。
实现机制
- StatefulSet 内部通过 Headless Service 实现固定 DNS 解析，为 Pod 提供稳定的网络标识；
- 每个 Pod 会被分配一个有序的编号，例如 mysql-0、mysql-1；
- Pod 与 PersistentVolumeClaim（PVC）绑定，确保数据不会因 Pod 重建而丢失；
- Pod 创建、扩容、更新、删除等操作严格按照顺序进行，保证集群一致性。
定义特点
- StatefulSet 的定义与 Deployment 类似，但支持更多有状态特性：
  - Pod 命名固定：Pod 名称由 StatefulSet 名称 + 编号组成，如 mysql-0；
  - 网络标识稳定：通过 Headless Service 绑定，Pod 拥有固定 DNS，如 mysql-0.mysql；
  - 持久化存储：每个 Pod 自动绑定独立 PVC，与 Pod 生命周期解耦；
  - 严格的顺序控制：Pod 启动、扩容和删除过程严格有序。
适用场景
- 部署数据库服务，如 MySQL 主从、PostgreSQL；
- 部署分布式存储，如 HDFS、Ceph；
- 部署分布式协调服务，如 ZooKeeper、Etcd；
- 部署需要稳定网络标识的集群，如 Kafka、RabbitMQ。

DaemonSet

DaemonSet 的概念

DaemonSet 控制器是 Kubernetes 在 1.2 版本中引入的重要控制器，主要用于确保集群中每个（或指定）Node（工作节点）上都运行一个 Pod，非常适合运行节点级的后台服务或守护进程。

主要功能
- 在每个节点上运行一个指定的 Pod
  - 自动在集群中每个符合条件的节点上部署且只运行一个指定的 Pod 实例。
- 节点加入自动部署
  - 当新节点加入集群时，DaemonSet 会自动在该节点上调度并启动 Pod。
- 节点移除自动回收
  - 节点被移除或不可用时，对应 Pod 会自动删除，保持一致性。
- 不支持手动扩容 / 缩容
  - Pod 的副本数量与节点数量直接关联，不支持手动管理 replicas。
- 支持滚动更新与回滚
  - 可平滑升级版本，并在出现问题时快速回滚。
- 可结合节点选择器、节点亲和性、污点 / 容忍等使用
  - 支持精确控制 DaemonSet Pod 部署在哪些节点上。
- 与 Deployment 区别
  - Deployment：通常用于无状态服务，副本数固定，由用户定义。
  - DaemonSet：与节点数量绑定，强调 “每个节点一个 Pod”。
- 删除行为可控
  - 使用 kubectl delete daemonset 删除 DaemonSet 时，可通过 --cascade=orphan 参数控制是否保留关联的 Pod。
实现机制
- DaemonSet 控制器实时监听集群节点变化：
  - 当新节点加入时，DaemonSet 会根据调度规则自动为该节点创建一个 Pod；
  - 当节点下线或被删除时，DaemonSet 会清理对应的 Pod；
  - 通过 updateStrategy 配置支持滚动更新，保证节点上的 Pod 平滑升级；
- 一个 DaemonSet 只能管理一组相同功能的 Pod，不会像 Deployment 那样创建多个 Replica Set（RS）；
- 与 Deployment 不同，DaemonSet 的 Pod 不通过调度器进行普通调度，而是直接绑定到目标节点。
定义特点
- Kind 类型是 DaemonSet；
- Pod 数量等于匹配规则的节点数量；
- 支持的更新策略：
  - RollingUpdate：逐个节点更新 Pod，保证服务连续性；
  - OnDelete：需要手动删除旧 Pod 时，DaemonSet 才会创建新 Pod；
- 可通过节点标签、节点亲和性、污点 / 容忍等配置精确控制 Pod 的分布；
- YAML 文件定义结构与 Deployment 类似，但 spec.strategy 配置略有不同。
- 使用 kubectl delete daemonset 删除 DaemonSet 时，可通过 --cascade=orphan 参数控制是否保留关联的 Pod。
适用场景
- 日志收集：如 Fluentd、Logstash、Filebeat，保证每个节点日志都能被采集。
- 监控代理：如 Prometheus Node Exporter、Datadog Agent、cAdvisor 等，采集节点和 Pod 的监控指标。
- 网络插件：如 Flannel、Calico、Cilium 等 CNI 插件，需要在所有节点上运行网络代理；
- 存储插件：如 Ceph、GlusterFS、CSI Driver 等，部署存储卷管理进程；
- 安全与合规审计：如 Falco、Sysdig Secure 等安全审计、防护 Agent；
- 节点运维任务：自动在每个节点运行健康检查、系统运维脚本或运维工具；
- 边缘计算场景：在特定节点部署边缘服务或代理。

总结对比

特性	Deployment	DaemonSet
Pod 数量控制	支持自定义 Pod 的副本数量	每个节点部署 1 个 Pod，自动匹配节点
调度机制	由调度器调度	直接绑定到目标节点
适用场景	无状态应用、微服务、Web 服务	节点级服务、日志、监控、网络插件等
支持扩缩容	支持 HPA 自动扩缩容	不支持扩缩容，Pod 数量由节点数决定
更新策略	滚动更新、回滚、暂停、恢复	滚动更新，或者手动删除更新

Job

Job 的概念

Job 控制器是 Kubernetes 中用于一次性任务管理的重要控制器，适合运行批处理作业或有限执行次数的任务。Job 会确保指定数量的 Pod 成功执行完成（即运行到 Completed 状态），通常用于离线计算、数据处理或临时任务。

主要功能
- 执行一次性任务，保证任务至少成功执行一次
  - Job 会确保定义的 Pod 按照预期执行，直到成功完成（运行状态为 Completed）。
  - Pod 运行失败时，Job 会根据重试策略自动重新创建新的 Pod 继续执行任务。
- 支持并行或串行执行
  - 可以通过 spec.parallelism 控制同时运行的 Pod 数量；
  - 可以通过 spec.completions 控制任务总共需要成功完成的 Pod 数量。
- 适合一次性任务，执行完成后不会再次运行
  - Job 完成后，Pod 不会被自动删除，但状态保持为 Completed；
  - 可以通过配置 TTL 控制器自动清理已完成的 Job 及 Pod。
实现机制
- Job 控制器实时监听任务的执行状态：
  - 创建 Pod：Job 根据并发配置启动一个或多个 Pod；
  - 失败重试：如果 Pod 执行失败（运行状态为 Failed），Job 会根据 backoffLimit 限制重试次数；
  - 完成判断：当成功完成的 Pod 数量达到 spec.completions 时，Job 进入 Completed 状态；
  - 清理策略：可通过 ttlSecondsAfterFinished 设置任务完成后延迟删除资源。
- Pod 调度：Job 创建的 Pod 由调度器进行普通调度，可结合节点选择策略运行在特定节点。
- Job 控制器本身不做并发同步逻辑，任务并发控制需通过应用自身或外部工具实现。
定义特点
- Kind 类型：Job
- 核心参数：
  - spec.completions：任务需要成功完成的 Pod 总数量；
  - spec.parallelism：允许同时运行的 Pod 数量；
  - spec.backoffLimit：Pod 失败时的最大重试次数，超过该次数后 Job 会被标记为失败；
  - spec.ttlSecondsAfterFinished：Job 完成后延迟清理的时间（秒）；
  - spec.template.spec.restartPolicy：Pod 的重启策略，Job 必须设置为：
    - Never：Pod 失败时，不会在同一个 Pod 内重启，而是由 Job 创建新的 Pod；
    - OnFailure：Pod 失败时，会在同一个 Pod 内重启一次，仍未成功则由 Job 重新创建 Pod。
- YAML 定义结构与 Deployment 类似，但 spec.strategy 等部署策略不适用。
更新策略
- Job 通常不支持直接滚动更新：
  - 如果需要修改 Job 逻辑，通常是删除旧 Job 后重新创建新 Job；
  - 可以通过 kubectl replace 或者 kubectl apply 覆盖更新。
适用场景
- 一次性批处理作业
  - 数据清理、日志分析、批量数据转换等。
- 离线计算任务
  - 机器学习模型训练、视频转码、大数据计算等。
- 自动化任务
  - 备份数据库、生成报表、执行临时脚本等。
- 测试任务
  - 压力测试、集成测试或单次验证任务。

CronJob

CronJob 的概念

CronJob 控制器是 Kubernetes 中用于定时任务调度的重要控制器，适合周期性执行任务或在特定时间点自动运行一次性任务。CronJob 基于 Linux 的 cron 语法定义任务调度规则，本质上是按时间计划自动创建 Job 资源，由 Job 再去管理 Pod 的执行与重试。

主要功能
- 周期性任务调度
  - 使用 cron 表达式定义执行计划，精确到分钟；
  - 可在每天、每周、每月或特定时间点自动运行任务。
- 自动创建 Job
  - CronJob 在到达调度时间后，会自动创建对应的 Job 资源；
  - CronJob 不直接创建和运行 Pod，所有 Pod 都由其生成的 Job 进行管理；
  - Job 负责任务的执行、失败重试和状态维护。
- 控制并发执行
  - 可通过 concurrencyPolicy 控制多次调度的 Job 是否允许并发执行：
    - Allow：允许多个任务并发运行；
    - Forbid：禁止并发，若上一个任务未完成，跳过新的调度；
    - Replace：如果上一个任务未完成，先删除旧任务，再启动新任务。
- 支持任务历史管理
  - 可以配置保留的成功任务和失败任务历史数量，避免资源无限增长。
- 支持一次性定时任务
  - 通过指定一次性运行的时间点，实现一次性定时触发的 Job。
实现机制
- CronJob 控制器周期性检查当前时间是否符合 schedule 定义的规则：
  - (1) 到达调度时间点 → 创建新的 Job；
  - (2) Job 执行任务 → 根据 Pod 模板启动 Pod；
  - (3) 任务执行失败 → 根据 Job 的重试策略进行管理；
  - (4) 任务历史清理 → 按配置保留一定数量的成功和失败记录。
- CronJob 仅负责调度和 Job 创建，实际的 Pod 管理由 Job 负责；
- 当控制器或 API Server 不可用时，会在恢复后补偿执行任务（可通过 startingDeadlineSeconds 控制补偿的时间窗口）。
定义特点
- Kind 类型：CronJob
- 核心参数：
  - spec.schedule：调度时间，使用标准 cron 表达式；
  - spec.concurrencyPolicy：任务并发执行策略；
  - spec.startingDeadlineSeconds：任务延迟启动的容忍时间（秒）；
  - spec.successfulJobsHistoryLimit：保留的成功 Job 数量；
  - spec.failedJobsHistoryLimit：保留的失败 Job 数量；
  - spec.jobTemplate：定义要运行的 Job 模板
    - spec.jobTemplate.spec.template.spec.restartPolicy：Pod 的重启策略，CronJob 必须设置为：
      - Never：Pod 失败后不重启（常用于一次性任务）；
      - OnFailure：Pod 失败后自动重启，直到成功或超过 backoffLimit 限制。
更新策略
- CronJob 更新时：
  - 新的调度规则在应用后立即生效；
  - 已经创建的 Job 不会被中断或自动更新；
  - 修改任务逻辑需更新 jobTemplate 并等待下一个调度周期生效。
- 如果需要中断已生成的 Job，需要手动删除 Job 或 Pod。
适用场景
- 定时数据处理
  - 每天凌晨自动跑批处理作业，生成统计报表；
  - 定时清理临时文件或过期数据。
- 数据库备份
  - 每天或每小时自动执行数据库备份任务。
- 日志归档
  - 定期收集、压缩和上传日志文件到集中存储。
- 周期性健康检查
  - 定时执行诊断脚本或检查任务，输出报告。
- 定时通知或消息推送
  - 定时触发消息发送、告警提醒或业务事件。
- 一次性延时执行任务
  - 通过设置特定时间点，完成一次性延时任务的执行。
Linux 的 Cron 表达式规则
- 常用示例（仅支持精确到分钟）：
  - "*/5 * * * *" → 每 5 分钟执行一次；
  - "0 0 * * *" → 每天 0 点执行；
  - "0 2 * * 1" → 每周一凌晨 2 点执行。
  字段位置含义取值范围
  第 1 位分钟 0–59
  第 2 位小时 0–23
  第 3 位日期（日） 1–31
  第 4 位月份 1–12
  第 5 位星期 0–7（0 和 7 都表示星期日）

字段位置	含义	取值范围
第 1 位	分钟	0–59
第 2 位	小时	0–23
第 3 位	日期（日）	1–31
第 4 位	月份	1–12
第 5 位	星期	0–7（0 和 7 都表示星期日）

Horizontal Pod Autoscaler

HPA 的概念

Horizontal Pod Autoscaler（Pod 横向自动扩容，简称 HPA）与 Replication Controller（RC）、Deployment 一样，都是 Kubernetes 的资源对象。HPA 的实现原理是：通过持续追踪和分析 Replication Controller（RC）或 Deployment 控制的目标 Pod 的负载变化，判断是否需要针对性地调整 Pod 的副本数量（自动扩容和缩容）。

HPA 的两种模式

Kubernetes 对 Pod 的扩容与缩容提供了手动和自动两种模式。

手动扩容和缩容：
- 通过 kubectl scale 命令对 Deployment 或 Replication Controller 的 Pod 副本数量进行设置；
- 比如：kubectl scale deployment frontend --replicas 1。
自动扩容和缩容（HPA）：
- 用户需要根据某个性能指标或自定义业务指标，指定 Pod 副本数量的最小值和最大值范围，Kubernetes 会根据实时指标变化，在这个范围内自动调整 Pod 的副本数量。
- HPA 控制器通过 Master 节点的 kube-controller-manager 服务的启动参数 --horizontal-pod-autoscaler-sync-period（默认值为 30 秒）来周期性运行，包括：
  - HPA 控制器会定期监测目标 Pod 的 CPU 使用率；
  - 当 Pod 的 CPU 平均使用率达到用户设定的阈值条件时，HPA 控制器会自动调整 Replication Controller 或 Deployment 中的 Pod 副本数量，以使实际 Pod 副本数满足用户定义的 CPU 平均使用率要求。

HPA 的扩容配置示例

配置示例

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx
          resources:
            requests:
              cpu: 50m
          ports:
            - containerPort: 80

---

apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
spec:
  ports:
    - port: 80
      targetPort: 80
  selector:
    app: nginx

---

apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: nginx-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx-deployment
  minReplicas: 1
  maxReplicas: 10
  targetCPUUtilizationPercentage: 50    # 当 Pod 的 CPU 平均使用率超过 50% 时扩容

配置说明：
- Deployment（nginx-deployment）
  - 核心作用：
    - 创建并管理 Nginx Pod，实现副本管理、自动恢复。
  - 核心配置：
    - replicas: 1：初始创建 1 个 Pod 副本。
    - selector.matchLabels：用于匹配 Pod 的标签，这里为 app: nginx，确保 Deployment 管理正确的 Pod。
    - template.metadata.labels：Pod 模板的标签，与 selector 对应。
    - containers：定义容器信息
      - name / image：容器名称及镜像（nginx）
      - resources.requests.cpu: 50m：CPU 请求资源，保证 Pod 调度时的资源预留（50m 表示 0.05 个 CPU 核心）
      - ports.containerPort: 80：容器端口
- Service（nginx-svc）
  - 核心作用：
    - 为 Pod 提供统一访问入口，实现负载均衡。
  - 核心配置：
    - ports.port: 80：Service 暴露的端口
    - ports.targetPort: 80：转发到 Pod 的容器端口
    - selector.app: nginx：Service 选择带有 app=nginx 标签的 Pod 作为后端
- HorizontalPodAutoscaler（nginx-hpa）
  - 核心作用：
    - 基于 CPU 使用率自动调整 Pod 副本数量，实现弹性伸缩（自动扩容和缩容）。
  - 核心配置：
    - scaleTargetRef：指定 HPA 控制器管理的对象，这里为 Deployment/nginx-deployment
    - minReplicas: 1：Pod 副本数量的最小值
    - maxReplicas: 5：Pod 副本数量的最大值
    - targetCPUUtilizationPercentage: 50：HPA 控制器会根据 Pod 的 CPU 平均使用率是否达到 50% 来自动扩缩容

HPA 的扩容高级配置

在 HPA 中，除了 targetCPUUtilizationPercentage 这种基于 CPU 使用率的扩缩容条件外，还可以配置更多维度的指标，例如内存、Pod 自定义指标、外部 Kubernetes 对象指标、外部监控系统指标等。

API 版本 autoscaling/v1（最基础版本）
- 核心作用：
  - 只支持 CPU 使用率指标；
  - 无法基于内存或自定义指标来扩容或缩容，只适用于简单场景。
- 配置字段：
  1
  2
  spec:
  targetCPUUtilizationPercentage: 50 # 当 Pod 的 CPU 平均使用率超过 50% 时扩容

API 版本 autoscaling/v2beta2 或者 autoscaling/v2（推荐版本）

核心作用：
- 支持基于多种指标类型来扩容或缩容，通过 metrics 字段配置。
四种核心指标类型：

指标类型	用途	示例场景	是否需要结合 Metrics Adapter（比如 Prometheus Adapter）使用
Resource	基于 Pod 资源指标（CPU、内存等）	当 Pod 的 CPU 平均使用率超过 `50%` 时扩容	不需要
Pods	基于每个 Pod 计算出的指标	当每个 Pod 处理的业务请求数超过 1000 时扩容	需要
Object	基于外部 Kubernetes 对象指标	根据某个 Service 的 QPS 来扩容	需要
External	基于外部监控系统指标	根据 Prometheus 或外部监控系统的 QPS 扩容	需要

基于资源指标（CPU / 内存）自动扩容和缩容，不需要结合 Metrics Adapter（比如 Prometheus Adapter）使用

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: nginx-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx-deployment
  minReplicas: 1
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 50   # 当 Pod 的 CPU 平均使用率超过 50% 时扩容
    - type: Resource
      resource:
        name: memory
        target:
          type: AverageValue
          averageValue: 200Mi      # 当 Pod 的内存平均使用量超过 200Mi 时扩容

配置字段	配置作用
`averageUtilization`	百分比，基于 Pod CPU 或内存的使用率
`averageValue`	绝对值，基于 Pod CPU 或内存的使用量

基于每个 Pod 的自定义指标来自动扩容和缩容，需要结合 Metrics Adapter（比如 Prometheus Adapter）使用，适用于：根据每个 Pod 处理的业务请求数、活跃连接数等指标来扩容

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: nginx-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx-deployment
  minReplicas: 1
  maxReplicas: 10
  metrics:
    - type: Pods
      pods:
        metric:
          name: requests_per_second    # Prometheus Adapter 暴露的指标名称
        target:
          type: AverageValue
          averageValue: "1000"   # 当每个 Pod 每秒所处理的业务请求数大于 1000 时扩容

基于外部 Kubernetes 对象指标来自动扩容和缩容，需要结合 Metrics Adapter（比如 Prometheus Adapter）使用，适用于：根据 Service、Ingress 等对象的指标来扩容

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: nginx-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx-deployment
  minReplicas: 1
  maxReplicas: 10
  metrics:
    - type: Object
      object:
        describedObject:
          apiVersion: networking.k8s.io/v1
          kind: Ingress
          name: my-ingress
        metric:
          name: requests_per_second    # Prometheus Adapter 暴露的指标名称
        target:
          type: Value
          value: "1000"   # 当该 Ingress 的每秒请求数超过 1000 时扩容

基于外部监控系统指标来自动扩容和缩容，需要结合 Metrics Adapter（比如 Prometheus Adapter）使用，适用于：根据 Prometheus、CloudWatch、阿里云 ARMS 等外部监控系统指标来扩容

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: nginx-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx-deployment
  minReplicas: 1
  maxReplicas: 10
  metrics:
    - type: External
      external:
        metric:
          name: nginx_ingress_qps   # Prometheus Adapter 暴露的指标名称
        target:
          type: AverageValue
          averageValue: "2000"  # 当外部系统的 QPS 大于 2000 时扩容

总结说明

Kubernetes 的 Metrics Server：仅提供 CPU、内存指标，适用于简单扩缩容场景。
推荐使用 Prometheus + Prometheus Adapter：采集并适配 QPS、连接数、延迟等复杂业务指标供 HPA 使用。
多个指标组合使用：HPA 支持同时配置 CPU、内存、QPS 等多个指标，最终副本数取最大值，确保系统稳定性。
生产最佳实践：统一部署 Metrics Server + Prometheus + Prometheus Adapter，构建完整的自动扩缩容体系。

HPA 的缩容高级配置

在 Kubernetes 的 Horizontal Pod Autoscaler（HPA）中，自动缩容实际上是自动扩容机制的一部分，一般不需要单独写一个专门的 “缩容配置”。HPA 会根据用户设定的 Metrics 指标，自动计算目标 Pod 副本数量，既包括扩容，也包括缩容。

缩容的核心逻辑
- HPA 会根据当前负载和目标值计算期望 Pod 副本数量：
  - 计算公式：desiredReplicas = ceil(currentReplicas × currentMetricValue ÷ targetMetricValue)
  - 如果 desiredReplicas > currentReplicas，HPA 会进行扩容
  - 如果 desiredReplicas < currentReplicas，HPA 会进行缩容
- 假设配置里有以下内容，这意味着 Pod 缩容最小会缩到 1 个副本，不会被缩容到 0 个副本
  1
  2
  minReplicas: 1
  maxReplicas: 10

如何让缩容生效

(1) HPA 默认就支持缩容，一般不需要额外配置
- 比如，当 CPU 或内存使用率持续低于目标值时，Pod 的数量会被逐步缩减，直到达到 minReplicas 限制

(2) 如果想控制 Pod 缩容的速度和行为，可以在 spec.behavior 中配置策略

必须使用 API 版本 autoscaling/v2 或者 autoscaling/v2beta2

配置示例：

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: nginx-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx-deployment
  minReplicas: 1
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 50             # 当 Pod 的 CPU 平均使用率超过 50% 时扩容
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300        # 缩容前观察 5 分钟，避免波动
      policies:
        - type: Percent
          value: 50                          # 每次最多缩减 50%
          periodSeconds: 60                  # 每 60 秒评估一次缩容

配置字段：
- stabilizationWindowSeconds：稳定窗口，只有指标持续低于目标值这段时间后才缩容，避免频繁抖动
- policies：定义缩容速率，可以按百分比或固定数量缩减 Pod 的数量
- periodSeconds：缩容策略评估的时间间隔

Pod 缩容为 0 个副本
- 在 Kubernetes 中，当 Pod 缩容到 0 个副本时，指的是 Pod 数量为 0，即一个 Pod 都不会存在（相当于删除所有正在运行的 Pod）。
- 如果希望 Pod 完全缩到 0 个副本，HPA 本身做不到，需要配合 KEDA 或 VPA 或 Deployment 的 scale-to-zero 机制。
- 但是，如果只是普通业务场景，直接设置 minReplicas: 0 即可让 HPA 在负载极低时将 Pod 缩到 0 个副本：
  1
  2
  3
  spec:
  minReplicas: 0
  maxReplicas: 10
- 注意：当 Pod 缩容到 0 个副本后
  - 如果没有请求进来，这个服务将处于完全停机状态
  - 如果之后有请求到达，Kubernetes 不会自动重建 Pod
  - 必须由 HPA 再次检测到指标上升，将 Pod 的副本数量从 0 调整为 1 或更多，Pod 才会被重新启动
  - 这期间会有冷启动延迟（Pod 拉取镜像、启动应用、健康检查等）

完整的扩缩容配置示例

配置示例：

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: nginx-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: nginx-deployment
  minReplicas: 1
  maxReplicas: 10
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 50             # 当 Pod 的 CPU 平均使用率超过 50% 时扩容
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300        # 缩容前观察 5 分钟，避免波动
      policies:
        - type: Percent
          value: 50                          # 每次最多缩减 50%
          periodSeconds: 60                  # 每 60 秒评估一次缩容

配置效果
- 当 Pod 的 CPU 平均使用率超过 50% 时扩容
- 当 Pod 的 CPU 平均使用率低于 50% 且持续 5 分钟时，每 60 秒最多缩容 50%，直到达到 minReplicas 限制
验证缩容
- 实时查看 HPA 的决策过程：kubectl get hpa nginx-hpa -w，命令的输出结果如下：
  1
  2
  NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE
  nginx-hpa Deployment/nginx 10%/50%, 80Mi 1 10 3 10m
- TARGETS：当前值 VS 目标值
- 当 10%/50% 持续低于目标值，REPLICAS（Pod 的副本数量）会逐步减少。