序

補充上一篇沒有講到的內容。

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包。

由於專案過去一段時間，具體操作未及時更新，後面再補。

以上