《Apache Flink 案例集（2022版）》——4.云原生——小红书-Native Flink on Kubernetes 在小红书的实践（1） https://developer.aliyun.com/article/1228082

生产实践

1. Helm 集群管理模式  

在正式迁入到 Native Flink on K8s 之前很长一段时间内，小红书都是基于 Helm 来进行集群管理的。Helm 是一个 K8s 上的包管理器，它可以定义、安装和升级 K8s 应用和服务，具有以下几个特点：  

可以管理比较复杂的 K8s 应用，创建 Flink 集群时会创建很多 K8s 相关的资源，例如 service 或者 config map 以及 Deployment 等， Helm 可以将这些资源统一打包成一个 Helm chart，然后进行统一管理，从而不需要感知每一种资源对应的底层描述文件；

比较方便升级和回滚，只需要执行一条简单命令就可以进行升级或者回滚。同时因为它的代码是和 Flink Client 的代码做了隔离，因此在升级过程中不需要去修改 Flink Client 的代码，实现了代码解耦；

非常易于共享，将 Helm chart 部署在公司私有服务器上之后，已经可以同时支持多个云产品的 Flink 集群管理。

上图可以看到 Helm Client 里面集成了各大云厂商提供的 K8s 相关配置，当它接收到创建任务的参数时，会根据这些参数去渲染出不同的 Helm 模板，并提交到不同的云上执行，创建出对应的集群资源。  

不过使用Helm集群管理模式在实际生产过程中也遇到了不少问题：  

第一是 K8s 资源瓶颈问题。因为每启动一个 JobManager 就会创建一个 NodePort Service，而这个 Service 会在整个集群范围内占用一个端口和一个 ClusterIP。当作业规模达到一定程度的时候，这些端口资源以及 IP 资源就会遇到性能瓶颈；

第二个是 ServiceMesh 配置成本过高。由于 TaskManager 内部会访问第三方服务，比如说小红书自研的 redkv service，那么每增加一个 redkv service，就需要去修改对应的配置并完成发版，成本是很高的；

第三个是存在一定的资源泄露问题。所有的资源创建以及销毁都是通过执行 Helm 命令来完成的，在某些异常情况下，job 失败会导致 Helm delete 命令没有被执行，这个时候就有可能会存在资源泄露的问题；

第四个是镜像版本比较难以收敛。在日常的生产过程中，某些线上任务出现了问题，会临时出一个 hotfix 版本镜像并上线运行，久而久之线上就会存在很多版本镜像在运行，这对于后面的运维工作以及问题排查产生了非常大的挑战；

最后一个问题是 UDF 管理复杂度比较高，这是任何分布式计算平台都会遇到的一个问题。  

针对上述这些问题，小红书在 Native Flink on K8s 模式下逐一进行了优化解决。  

《Apache Flink 案例集（2022版）》——4.云原生——小红书-Native Flink on Kubernetes 在小红书的实践（3） https://developer.aliyun.com/article/1228079