这个时候 Flink 的 ResourceManager 会直接跟 K8s 的 API Server 通信,将这些请求资源直接下发给 K8s Cluster,告诉它需要多少个 TaskManger,每个 TaskManager 多大。当任务运行完之后,它也会告诉 K8s Cluster 释放没有使用的资源。相当于 Flink 用很原生的方式了解到 K8s Cluster 的存在,并知晓何时申请资源,何时释放...
这个集群目前由我们和运维团队一起维护,里面的 k8s 资源由 Flink 计算平台维护,子网地址等其他外部云服务资源由基础运维团队维护。 第三部分是我们依赖的一些基础组件。比如利用公司的持续集成CICD 来构建docker镜像;日志采集工具用来收集每个 K8s Node 上的日志;搜索引擎 ES 用来搜索近期的 Flink 日志;HDFS 用来存储...
Flink slave 的 failover,Flink task 的 failover,确保这些在 K8s 环境下能正常恢复;2. K8s 发生异常对系统的影响,包括 ETCD 存储异常,Kubelet 异常,master 节点异常等;3.集群硬件异常,包括机器假死,磁盘故障,网络异常,确保在这些情况下,Flink 能正常恢复。
随着Flink 实例的迁移下云以及新增需求接入,自建 Flink 平台规模逐渐壮大,当前总计已超 4 万核运行在自建的 K8S 集群中,然而 Flink 任务数的增加,特别是大状态任务,每次 Checkpoint 时会产生脉冲式带宽占用,峰值流量超过 100Gb/s,早期使用 OSS 作为 Checkpoint 数据存储,单个 Bucket 每 1P 数据量只有免费带宽 10G...
目前最佳实践还是得基于专业的任务调度和资源管理框架如yarn、k8s、mesos。 使用前面部署服务器hadoop1、hadoop2、hadoop3,利用前面部署Hadoop环境包括HDFS和YARN,Flink运行在所有类unix环境中如Linux、Mac OS X和Cygwin(用于Windows)可使用安装JDK环境,JDK8也是可以的,但官方上最新写的是Java 11。
Savepoint）的存储地址，但是由于仅使用了其HDFS作为状态快照存储地址，且Hadoop框架较重，在K8s集群中占用...
最底层是资源层和存储层,资源层使用 K8s 和 Yarn,存储采用 HDFS 和 Kwaistore; 计算层,基于 Flink Streaming&Batch 来提供统一的 runtime 层支持; 应用层,分为在线平台和离线平台; 最上层为业务层,涵盖公司的各大部门。 02 生产改造 为了适应云原生的大趋势,我们进行了 Flink on k8s 的开发和迁移。
目前在K8S中执行Flink任务的方式有两种,一种是Standalone,一种是原生模式。 Standalone模式 在K8S中启动Flink集群 Flink onKubernetes的架构如图所示,Flink 任务在 Kubernetes 上运行的步骤有: 首先往 Kubernetes 集群提交了资源描述文件后,会启动 Master 和 Worker 的 container。
因为项目需要,之前基于Hadoop+yarn+flink+hdfs+hive 构建一套文件存储体系,但是由于Hadoop商业发行版cdh和hdp开始收费,开始思考如何构建没有hadoop生态的数据湖,搜集网上资料,尝试基于现代存储S3或者OSS来代替HDFS,使用k8s + kafka + Flink + iceberg + trino构建实时计算体系。 网上的教程大多问题很多,记录下来以作参...
创建集群后,JRC 平台通过 K8s 客户端向 K8s master 发出请求,创建 Jobmanager 的 deployment,这里使用 ZK 保证高可用,使用 HDFS 和 OSS 进行状态存储,集群创建完成后就可以提交任务了。 但是在我们实践的过程中发现该方案存在一些不足,它需要业务提前预估出所需要的资源,对业务不太友好,无法满足灵活多变的业务场景...