Flink部署怎么选，自建还是托管？

Flink 怎么部署？Standalone、YARN 还是 K8s？

这不仅仅是技术选型，更是对运维成本和稳定性的权衡。本文基于生产环境经验，聊聊怎么选。

生产环境最怕什么？

跑 Demo 很容易，但上生产后，你会被这些问题折磨：

1. OOM：TaskManager 内存配少了，频繁 GC，甚至直接挂掉。
2. 积压：上游 Kafka 突然洪峰，Flink 扩容太慢，消费赶不上生产。
3. 丢数据：Checkpoint 没配好，任务一挂，状态全丢。

选型其实就是一道算术题：你愿意花多少人月来维护基础设施？

方案对比

1. Standalone

适合开发、测试、玩具项目。解压即用，无依赖。但相当于裸奔，没有资源隔离，一个任务挂了可能带崩整个集群，扩缩容基本靠重启。

2. YARN

适合家里有矿（现成的 Hadoop 集群）的团队。能蹭现有的资源池，利用率高。但 YARN 的调度对流计算不友好，资源争抢严重时 JobManager 容易失联。

3. Kubernetes

适合云原生团队。Operator 全自动管理生命周期，容器级隔离谁也别想抢谁的 CPU，yaml 一提交集群自动同步。

4. 托管服务

AWS Kinesis、Confluent 这类托管服务适合有钱、缺人、赶时间的团队。SLA 有保障，不用起夜修集群。但贵，而且是黑盒，出问题不好排查。

K8s 部署实战 (Operator 模式)

别用脚本去搞 K8s 部署了，Operator 才是正解。

# FlinkDeployment 示例
apiVersion: flink.apache.org/v1beta1
kind: FlinkDeployment
metadata:
  name: my-flink-cluster
spec:
  image: flink:1.18
  flinkVersion: v1_18
  jobManager:
    resource:
      memory: "2048m"
      cpu: 1
  taskManager:
    resource:
      memory: "2048m"
      cpu: 2
  job:
    jarURI: local:///opt/flink/examples/streaming/StateMachineExample.jar
    upgradeMode: savepoint # 自动 Savepoint，不怕丢状态

Operator 好在哪？

1. 自动 Savepoint：配置好 Cron，定时存盘。
2. 平滑升级：改一下 yaml 里的 Image 版本，Operator 自动执行 “Stop -> Savepoint -> Restart”。
3. 高可用：原生 K8s HA，不用折腾 Zookeeper。

关键参数避坑

不管用哪种模式，这几个参数一定要看：

1. RocksDB 内存：taskmanager.memory.managed.fraction。用 RocksDB 时，设为 0.4-0.6，给它留够 Off-heap 内存。
2. Checkpoint 超时：execution.checkpointing.timeout。别设太长，超时就让它挂，好过一直卡着拖死整个作业。

小结

小团队别折腾，用托管或 Standalone 先跑通。Hadoop 钉子户继续用 YARN，稳妥。现代团队上 K8s + Operator，运维效率最高。