Apache Flink 在 Kubernetes 上的高效部署与优化实践

本文档旨在为在 Kubernetes（K8s）环境中部署和优化 Apache Flink 作业提供一套系统性、可落地的最佳实践，涵盖镜像构建、弹性调度、日志管理、启动性能及调度策略等关键维度。

一. 镜像优化

1.1 合并多阶段构建命令，减少中间层数

Flink 作业镜像应采用 多阶段构建（multi-stage build） 并尽可能合并 RUN 指令，以减少 Docker 镜像层数和最终体积：

复制代码

# 构建阶段
FROM maven:3.8-openjdk-11 AS builder
WORKDIR /app
COPY pom.xml .
COPY src ./src
RUN mvn clean package -DskipTests

# 运行阶段
FROM flink:1.17-scala_2.12-java11
COPY --from=builder /app/target/my-flink-job.jar /opt/flink/usrlib/

最佳实践：

使用 && 合并多个命令（如 apt-get update && apt-get install -y ... && rm -rf /var/lib/apt/lists/*），避免产生冗余层。
利用 .dockerignore 排除无关文件（如 .git, target/ 等）。
尽量复用官方 Flink 基础镜像，避免重复打包 Flink 二进制。

1.2 基础镜像与作业镜像分离

将 Flink Runtime 基础环境 与 用户作业 JAR 分离：

基础镜像 ：包含 Flink 二进制、依赖库、配置模板（如 flink-conf.yaml），由平台团队维护，版本稳定。
作业镜像：仅包含用户 JAR 和少量定制脚本，体积小、构建快。

优势：

用户每次只需推送轻量级作业镜像，节省网络带宽。
基础镜像可被多个作业共享，提升节点缓存命中率。
便于统一升级 Flink 版本或安全补丁。

二、潮汐调度：基于节点标签的弹性伸缩

潮汐调度核心是根据业务负载变化，动态调整集群资源分配，结合K8s节点标签与弹性扩缩容算法，实现资源按需分配，提升资源利用率。

2.1 K8s节点标签管理：区分固定与弹性节点

首先对K8s集群节点进行标签划分，明确固定节点与弹性节点的角色，为调度策略提供依据：

固定节点：用于部署Flink集群的JobManager、History Server等核心组件，以及关键业务作业，确保服务稳定性。标签示例：`node-role.kubernetes.io/flink-fixed=true`。
弹性节点：用于承载非核心业务作业或高峰期扩容的TaskManager任务，闲时可释放资源，降低成本。标签示例：`node-role.kubernetes.io/flink-elastic=true`。

通过K8s的节点亲和性（NodeAffinity）规则，配置Flink任务的调度策略：核心组件与关键作业强制调度到固定节点，普通作业优先调度到弹性节点，实现负载隔离与资源精准分配。

配置示例（Flink Deployment亲和性设置）：

复制代码

affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: node-role.kubernetes.io/flink-fixed
          operator: In
          values:
          - "true"

2.2 弹性扩缩容算法：基于负载的动态调整

结合Flink作业负载与K8s弹性能力，采用针对性的扩缩容算法，实现资源动态适配：

扩容触发条件：当TaskManager的CPU使用率超过阈值（如70%）、内存使用率超过阈值（如80%），或Flink作业的任务积压数超过设定阈值时，触发弹性节点扩容，新增节点后调度TaskManager任务至新节点。
缩容触发条件：当弹性节点上的TaskManager负载持续低于阈值（如30%），且无任务积压时，逐步缩减弹性节点数量，释放闲置资源。
算法优化：采用"预测式扩缩容"结合"渐进式调整"策略，通过历史负载数据预测业务高峰，提前扩容储备资源；缩容时逐步减少节点，避免因资源突然释放导致作业异常。

实践工具：开源的flink operator里面具有弹性扩缩autoscale功能。

三、日志上传与 History Server

3.1 日志持久化

启用 Flink 的 日志归档 功能：yaml

复制代码

# flink-conf.yaml
jobmanager.archive.fs.dir: hdfs:///flink/completed-jobs/
historyserver.archive.fs.dir: hdfs:///flink/completed-jobs/
historyserver.web.address: 0.0.0.0

在 K8s 中通过 Sidecar 容器 或 Init Container 将本地日志同步至对象存储（如 S3、OSS）。

3.2 History Server 部署

以 Deployment + Service 形式独立部署 History Server：yaml

复制代码

apiVersion: apps/v1
kind: Deployment
metadata:
  name: flink-history-server
spec:
  template:
    spec:
      containers:
      - name: history-server
        image: flink:1.17
        command: ["/opt/flink/bin/historyserver.sh"]
        args: ["start-foreground"]
        volumeMounts:
          - name: archive-dir
            mountPath: /opt/flink/archive
      volumes:
        - name: archive-dir
          persistentVolumeClaim: { claimName: flink-archive-pvc }

通过 Ingress 或 LoadBalancer 暴露 Web UI，供用户查询已完成作业的拓扑、指标与日志。

四、启动速度与K8s调度优化

通过远程提交优化启动速度，结合K8s软硬亲和性规则优化调度策略，实现Flink作业快速部署与资源高效利用。

4.1 远程提交：提升作业启动效率

传统方式中，作业jar包需打包进镜像或在节点本地读取，导致作业启动依赖本地资源，启动速度较慢。采用远程提交方式，可大幅优化启动效率：

jar包远程存储：将Flink作业jar包上传至HDFS、S3等远程存储平台，避免jar包在本地或镜像中重复存储。
远程提交命令：通过Flink客户端的`flink run-remote`命令，指定远程JobManager地址与远程jar包路径，直接向JobManager提交作业，无需在本地加载jar包，缩短启动时间。
优化延伸：结合Flink的Session模式，复用已启动的集群资源，避免每次作业启动都创建新的集群，进一步提升启动效率。

4.2 K8s调度：软硬亲和性精准适配资源

K8s的亲和性与反亲和性规则，可实现Flink任务与节点资源的精准匹配，提升作业运行稳定性与资源利用率，分为软亲和性与硬亲和性：

硬亲和性（nodeAffinity/ podAffinity）：强制任务调度到满足条件的节点或Pod附近，如GPU作业必须调度到具备GPU资源的节点，JobManager与TaskManager尽量调度到同一机架的节点，降低网络延迟。
软亲和性（preferredDuringSchedulingIgnoredDuringExecution）：优先调度到满足条件的节点，若无满足条件的节点则降级调度，如普通作业优先调度到弹性节点，闲时资源节点优先调度低优先级作业。

同时，通过污点（Taint）与容忍度（Toleration）规则，对固定节点添加污点，仅允许核心Flink组件与关键作业容忍该污点，防止非核心任务占用固定节点资源，实现资源隔离。

五、总结与实践建议

本文从镜像优化、潮汐调度、日志管理、启动与调度优化四大维度，提供了Flink on K8s的部署优化方案。实践中，需结合业务场景与集群规模，灵活调整优化策略：

小规模集群可优先优化镜像与日志管理，降低部署成本与排查难度；
大规模集群需重点落地潮汐调度与软硬亲和性，提升资源利用率与作业稳定性；
长期运维中，需结合监控指标（如镜像拉取时间、节点负载、日志上传延迟）持续迭代优化方案，构建高效、稳定的Flink on K8s运行环境。