【flink】flink1.12 application mode on k8s
序
补充上一篇没有讲到的内容。
k8s节点之间的通信
k8s有一个名为kube-apiserver的进程,该进程运行在Master上。这个进程提供了一个rest服务,所有的操作例如pod、service的增删改查watch的操作都是基于此接口执行的。agent机器上的kubectl其实也是基于该rest接口操作的。所以其实无论spark还是flink,它的命令提交都是通过http的方式去提交指令的。这意味着启动flink和spark的client不需要k8s的master或者agent上运行。在目前使用的库上,flink和spark都是先去~/.kube里面去找认证文件,然后通过http的方式携带认证提交命令的。
flink on k8s简单原理
flink client会创建一个deployment,该deployment会创建jobmanager和一个rest用于访问的页面。然后会挂载一个configMap,该configMap中包含了提交任务的命令和提交任务的client的conf里面相关内容。
deployment创建jobmanager的pod,然后根据configMap在jobmanager的pod启动taskmanager的pod。整个机制大概是这样的
日志回收问题
按照官方说法,为了节省资源,tm在运行完成之后,所在pod会被直接销毁。
所以简单的方式是将flink的log方式改为logback,默认是log4j。然后追加es或者kafka的appender
这里操作比较复杂,需要删除原本镜像的log4j包。
由于项目过去一段时间,具体操作未及时更新,后面再补。
以上