K8S任务调度、HPA控制器

K8s控制器核心原理与常用控制器完整笔记（当日新课内容）

一、Job 一次性任务控制器

1.1 Job 核心特点

Job 控制器用于启动 Pod 执行一次性、短周期离线任务，任务执行完成后 Pod 正常退出，不会常驻集群。

两种核心 Pod 状态释义：

  • Completed：Pod 任务正常执行完毕，进程退出码为 0，任务执行成功。

  • CrashLoopBackOff：容器启动后反复崩溃，K8s 多次重启尝试均失败，代表任务脚本异常、镜像错误或配置错误。

1.2 Job 与常驻 Pod 核心区别

Job 同样使用 Pod 模板，但和 Deployment 常驻 Pod 有本质区别：

1、Job 容器必须是可执行、可主动退出的任务进程，不能是 Nginx、Java 这类前台常驻进程。

2、Job 的重启策略 仅支持 Never / OnFailure，禁止使用 Always。因为 Job 是一次性任务，无需永久重启。

1.3 Job 关键核心参数

1.3.1 activeDeadlineSeconds 任务超时时间

设置任务最大执行时长，一旦任务运行超时，Job 会强制终止 Pod，判定任务失败(Failed)。

补充示例：job.yaml

1.3.2 重启策略与 backoffLimit 重试机制

backoffLimit：任务失败最大重试次数，默认值为 6 次。

两种重启策略逻辑区别：

  • restartPolicy: OnFailure：Pod 运行失败后，重启当前 Pod，不会新建 Pod，最多重试 backoffLimit 次。

  • restartPolicy: Never：Pod 运行失败后，不重启当前 Pod，Job 控制器新建 Pod 重试，最多新建 backoffLimit 个 Pod。

补充：Job 重试间隔为指数递增，重试次数越多，间隔时间越长，避免频繁重试占用集群资源。

补充示例：job.yaml

1.3.3 parallelism 与 completions 并行任务参数

  • completions：任务需要成功完成的总次数（Job 完成标准）

  • parallelism：同一时间最大并行运行的 Pod 任务数

1.3.4 ttlSecondsAfterFinished 任务自动清理

Job 任务完成后，等待指定秒数，自动清理 Job 和对应 Pod 资源，避免集群残留大量历史任务资源。

1.4 Job 课堂完整实验 YAML

1.4.1 超时测试任务（job1.yaml）

功能：无限计数脚本，用于测试 activeDeadlineSeconds 超时机制

apiVersion: batch/v1
kind: Job
metadata:
  name: job-demo
spec:
  activeDeadlineSeconds: 15
  template:  
    spec:
      restartPolicy: Never
      containers:
      - name: counter
        image: busybox
        command:
        - "bin/sh"
        - "-c"
        - "i=0;while true; do echo $i; sleep 1;let i++;done"

1.4.2 失败重试测试任务（job2.yaml）

功能：倒计时任务，执行到指定步骤主动异常退出，测试 Job 失败重试机制

apiVersion: batch/v1
kind: Job
metadata:
  name: job-demo
spec:
  # backoffLimit: 6 默认重试6次
  template:
    spec: 
      restartPolicy: Never
      containers:
      - name: counter
        image: busybox
        command:
        - "bin/sh"
        - "-c"
        - "for i in 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1; do echo $i; sleep 1;if [ $i -eq 2 ];then exit -1;fi;done"

1.4.3 并行任务+自动清理测试（job3.yaml）

功能：多 Pod 并行执行任务，任务完成后自动清理资源

apiVersion: batch/v1
kind: Job
metadata:
  name: job-para-test
spec:
  ttlSecondsAfterFinished: 60
  parallelism: 2
  completions: 4
  template:
    spec:
      containers:
      - name: test-job
        image: busybox
        command: ["/bin/sh","-c","echo test;sleep 10"]
      restartPolicy: Never

二、CronJob 定时任务控制器

2.1 CronJob 核心特点

资源层级：CronJob → Job → Pod

CronJob 基于 Job 一次性任务，增加了 Linux Crontab 时间调度能力，用于周期性、定时执行运维任务，适用于定时备份、定时清理、定时巡检等场景。

2.2 核心并发策略 concurrencyPolicy

用于定义：上一次任务未执行完毕，下一次调度时间到达时，任务重叠的处理逻辑，包含三种策略。

2.2.1 Allow 允许并发（默认）

新旧任务可同时并发运行，适用于任务无状态、无数据冲突的场景。

apiVersion: batch/v1
kind: CronJob
metadata:
  name: my-cronjob
spec:
  schedule: "*/1 * * * *"
  concurrencyPolicy: Allow
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: my-container
            image: busybox
            command: ["sh","-c","for i in `seq 1 120`;do echo $i;sleep 1;done"]
          restartPolicy: OnFailure

2.2.2 Forbid 禁止并发

旧任务未结束，新调度任务直接跳过、不执行，保证同一时间只有一个任务实例运行。适用于独占式任务。

apiVersion: batch/v1
kind: CronJob
metadata:
  name: my-cronjob
spec:
  schedule: "*/1 * * * *"
  concurrencyPolicy: Forbid
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: my-container
            image: busybox
            command: ["sh","-c","for i in `seq 1 120`;do echo $i;sleep 1;done"]
          restartPolicy: OnFailure

2.2.3 Replace 替换旧任务

新任务调度到达时，强制终止正在运行的旧任务，用新任务替换旧任务，保证始终运行最新调度任务。

apiVersion: batch/v1
kind: CronJob
metadata:
  name: my-cronjob
spec:
  schedule: "*/1 * * * *"
  concurrencyPolicy: Replace
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: my-container
            image: busybox
            command: ["sh","-c","for i in `seq 1 120`;do echo $i;sleep 1;done"]
          restartPolicy: OnFailure

2.3 历史任务保留限制

用于控制集群历史任务资源数量，避免大量废弃 Job、Pod 堆积占用资源。

  • successfulJobsHistoryLimit：保留成功任务历史个数

  • failedJobsHistoryLimit：保留失败任务历史个数

apiVersion: batch/v1
kind: CronJob
metadata:
  name: my-cronjob
spec:
  schedule: "*/1 * * * *"
  concurrencyPolicy: Allow
  successfulJobsHistoryLimit: 3 
  failedJobsHistoryLimit: 1
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: my-container
            image: busybox
            command: ["sh","-c","for i in `seq 1 120`;do echo $i;sleep 1;done"]
          restartPolicy: OnFailure

三、HPA 弹性扩缩容控制器

3.1 HPA 基础认知

3.1.1 什么是 HPA

HPA 全称 Horizontal Pod Autoscaler，即 Pod 水平自动扩缩器，可根据集群监控指标自动增减 Pod 副本数量，实现业务弹性伸缩。

3.1.2 为什么需要 HPA

传统运维：人工监控负载、手动扩缩容，滞后且低效。

K8s 自动化：HPA 实时采集指标、自动计算副本数、完成扩缩容，全程无人干预。

3.1.3 HPA 版本区别

  • HPA v1：依赖 Heapster 获取监控指标

  • HPA v2：依赖 Metrics Server 获取 CPU、内存核心指标（当前主流版本）

3.2 HPA 完整工作机制

3.2.1 HPA 整体工作流程

整体链路：hpa --> metrics api --> metrics server --> kubelet

辅助组件说明：api Aggregator 是 api 中允许扩展功能的插件，使得自定义 api 资源可以注册并通过 api 访问。metrics server 仅用于监控节点和 Pod 基础资源指标，功能轻量化。

分步工作逻辑：

1、metrics server 负责持续采集所有 pod 的指标数据

2、hpa 控制器负责周期性读取指标、计算副本数、执行扩缩容操作

3.2.2 HPA 扩缩容核心算法

1、收集指标：周期性采集目标 Deployment 所有 Pod 的资源指标数据

2、计算平均指标值：会根据 Pod 资源 requests 的值计算 cpu 使用率，limits 字段不直接参与计算。

3、计算所需的 pod 数量：根据指标阈值自动匹配最优副本数

4、副本数量限制：通过 minReplicas / maxReplicas 限制扩缩容范围，最终副本数不会超出该区间

3.2.3 HPA 防抖与冷却机制

为避免指标波动导致副本频繁抖动，HPA 内置防抖、冷却、多指标适配机制：

1、扩容防抖：若指标比例接近1.0、负载波动极小，会放弃扩缩容操作，避免无效扩容

2、缩容冷却延迟：缩容操作默认5分钟冷却时间，防止瞬时低负载导致频繁缩容

3、多指标适配：当配置 CPU、内存等多个扩缩容指标时，多个指标分别计算副本数，最终取最大值执行扩缩容

3.3 HPA 三大指标来源

3.3.1 常规资源指标

由 Metrics Server 提供，包含 CPU 使用率、内存使用率，是 HPA 最常用的扩缩容依据。

3.3.2 自定义指标（Custom metrics）

从业务应用、Prometheus 等监控系统采集，与业务自身性能相关，如 QPS、连接数、请求延迟等。

3.3.3 外部指标（External metrics）

取自集群外部资源，如消息队列堆积量、第三方接口响应时长、外部监控告警指标等，适配复杂业务场景。

3.4 Metrics Server 部署（HPA 前置依赖）

3.4.1 前置配置

修改 apiserver 配置开启路由聚合，在 kube-apiserver.yaml 中添加参数：

--enable-aggregator-routing=true

配置文件路径：/etc/kubernetes/manifests/kube-apiserver.yaml，修改后 apiserver 自动重启生效。

3.4.2 部署资源修改要点

官方下载地址：https://github.com/kubernetes-sigs/metrics-server/releases/download

下载官方组件 YAML 后需要两处修改：

1、新增启动参数：--kubelet-insecure-tls，跳过自签名证书校验

2、替换国内镜像，解决外网镜像拉取失败问题

3.4.3 可用镜像地址

ctr image pull registry.cn-hangzhou.aliyuncs.com/google_containers/metrics-server:v0.7.1

3.4.4 修改后完整部署片段

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    k8s-app: metrics-server
  name: metrics-server
  namespace: kube-system
spec:
  template:
    spec:
      containers:
      - args:
        - --cert-dir=/tmp
        - --secure-port=10250
        - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
        - --kubelet-use-node-status-port
        - --metric-resolution=15s
        - --kubelet-insecure-tls
        image: registry.cn-hangzhou.aliyuncs.com/google_containers/metrics-server:v0.7.1

3.5 Metrics 部署验证命令

# 查看帮助
kubectl top --help

# 查看节点资源占用
kubectl top node

# 查看默认命名空间Pod资源
kubectl top pod

# 查看所有命名空间Pod资源
kubectl top pod -A

# 查看指定Pod资源
kubectl -n kube-system top pod coredns-7c445c467-4f9dx

# 查看metrics api资源是否正常注册
kubectl get --raw /apis/metrics.k8s.io/v1beta1 | python -m json.tool

3.6 基于 CPU 的 HPA 实战实验

实验目的：创建 Deployment 业务负载，通过 HPA 实现基于 CPU 使用率的自动扩缩容

3.6.1 业务 Deployment 资源清单

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hpa-demo
spec:
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx
          ports:
            - containerPort: 80
          resources:
            requests:
              memory: 50Mi
              cpu: 50m

3.6.2 命令行快速创建 HPA

创建hpa资源，监控CPU使用率实现自动扩缩容

kubectl autoscale deployment hpa-demo --cpu-percent=10 --min=1 --max=10

3.6.3 业务 Service 暴露

apiVersion: v1
kind: Service
metadata:
  name: nginx
  namespace: default
spec:
  ports:
  - name: web
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: nginx
  type: ClusterIP

3.6.4 压力测试（触发扩容）

kubectl run -it --image busybox test-hpa --restart=Never --rm /bin/sh
# 循环访问nginx制造压力
while true; do wget -q -O- http://nginx.default.svc.cluster.local; done

3.6.5 HPA v2 完整标准 YAML

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: hpa-nginx
spec:
  maxReplicas: 10
  minReplicas: 1
  metrics:
  - resource:
      name: cpu
      target:
        averageUtilization: 40
        type: Utilization
    type: Resource
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: hpa-nginx
---
apiVersion: v1
kind: Service
metadata:
  name: hpa-nginx
spec:
  type: NodePort
  ports:
    - name: "http"
      port: 80
      targetPort: 80
      nodePort: 30080
  selector:
    service: hpa-nginx
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: hpa-nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      service: hpa-nginx
  template:
    metadata:
      labels:
        service: hpa-nginx
    spec:
      containers:
        - name: hpa-nginx
          image: nginx:latest
          resources:
            requests:
              cpu: 100m
              memory: 100Mi
            limits:
              cpu: 200m
              memory: 200Mi

3.7 基于内存的 HPA 实战实验

3.7.1 内存压力脚本 ConfigMap

apiVersion: v1
kind: ConfigMap
metadata:
  name: increase-mem-config
data:
  increase-mem.sh: |
    #!/bin/bash
    mkdir /tmp/memory
    mount -t tmpfs -o size=40M tmpfs /tmp/memory
    dd if=/dev/zero of=/tmp/memory/block
    sleep 60
    rm /tmp/memory/block
    umount /tmp/memory
    rmdir /tmp/memory

3.7.2 挂载脚本的业务 Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: hpa-mem-demo
spec:
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      volumes:
        - name: increase-mem-script
          configMap:
            name: increase-mem-config
      containers:
        - name: nginx
          image: nginx:1.18
          ports:
            - containerPort: 80
          volumeMounts:
            - name: increase-mem-script
              mountPath: /etc/script
          resources:
            requests:
              memory: 50Mi
              cpu: 50m
          securityContext:
            privileged: true

3.7.3 内存 HPA 规则配置

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: hpa-mem-demo
  namespace: default
spec:
  maxReplicas: 5
  minReplicas: 1
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: hpa-mem-demo
  metrics:
  - resource:
      name: memory
      target:
        averageUtilization: 30
        type: Utilization
    type: Resource

3.8 HPA 核心重点总结

当 HPA 同时配置 CPU、内存等多个扩容指标时，控制器会分别计算所需副本数，最终以计算出的最大副本数为准，保证服务负载稳定。hpa 可能有多个，以算出来最大的那一个为准。

四、今日核心控制器总结

1、Job：一次性离线任务控制器，支持超时、重试、并行执行，任务完成自动退出。

2、CronJob：定时任务控制器，基于 crontab 规则周期调度 Job，支持并发策略、历史资源清理。

3、HPA：弹性扩缩容控制器，依赖 Metrics Server 采集指标，根据 CPU/内存/业务指标自动扩缩 Pod 副本。

posted @ 2026-07-14 10:53  cuckooyang  阅读(15)  评论(0)    收藏  举报