序
补充上一篇没有讲到的内容。
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包。
由于项目过去一段时间，具体操作未及时更新，后面再补。
以上