序
補充上一篇沒有講到的內容。
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包。
由於項目過去一段時間，具體操作未及時更新，后面再補。
以上