Flink Native Kubernetes實戰

程式設計師欣宸發表於2020-11-18

歡迎訪問我的GitHub

https://github.com/zq2599/blog_demos

內容：所有原創文章分類彙總及配套原始碼，涉及Java、Docker、Kubernetes、DevOPS等；

Flink Kubernetes與Flink Native Kubernetes是不同的概覽，先回顧一下Flink Kubernetes：

  1. 如下圖，從1.2版本到目前最新的1.10，Flink官方都給出了Kubernetes上部署和執行Flink的方案：
    在這裡插入圖片描述
  2. 在kubernetes上有兩種方式執行flink：session cluster和job cluster，其中session cluster是一套服務可以提交多個任務，而job cluster則是一套服務只對應一個任務；
  3. 下圖是典型的session cluster部署操作，可見關鍵是準備好service、deployment等資源的yaml檔案，再用kubectl命令建立：
    在這裡插入圖片描述
  1. 先對比官方的1.9和1.10版本文件，如下圖和紅框和藍框所示，可見Flink Native Kubernetes是1.10版本才有的新功能：
    在這裡插入圖片描述
  2. 看看Native Kubernetes是如何執行的，如下圖，建立session cluster的命令來自Flink安裝包：
    在這裡插入圖片描述
  3. 更有趣的是，提交任務的命令也來自Flink安裝包，就是我們平時提交任務用到flink run命令，如下圖：
    在這裡插入圖片描述
  4. 結合官方給出的提交和部署流程圖就更清晰了：kubernetes上部署了Flink Master，由Flink Client來提交session cluster和job的請求：
    在這裡插入圖片描述

至此，可以小結Flink Kubernetes和Flink Native Kubernetes的區別：

  1. Flink Kubernetes自1.2版本首次出現，Flink Native Kubernetes自1.10版本首次出現；
  2. Flink Kubernetes是把JobManager和TaskManager等程式放入容器，在kubernetes管理和執行，這和我們把java應用做成docker映象再在kubernetes執行是一個道理，都是用kubectl在kubernetes上操作；
  3. Flink Native Kubernetes是在Flink安裝包中有個工具，此工具可以向kubernetes的Api Server傳送請求，例如建立Flink Master，並且可以和Flink Master通訊，用於提交任務，我們只要用好Flink安裝包中的工具即可，無需在kubernetes上執行kubectl操作；
  1. Flink Native Kubernetes只是Beta版，屬於實驗性質（官方原話：still experimental），請勿用於生產環境！
  2. 只支援session cluster模式（一個常駐session執行多個任務），還不支援Job clusters模式(一個任務對應一個session)

儘管還沒有進入Release階段，但這種操作模式對不熟悉kubernetes的開發者來說還是很友好的，接下來通過實戰來體驗吧；

官方要求

為了體驗Native Kubernetes，flink官方提出了下列前提條件：

  1. kubernetes版本不低於1.9
  2. kubernetes環境的DNS是正常的
  3. KubeConfig檔案，並且這個檔案是有權對pod和service資源做增刪改查的（kubectl命令有權對pod和service做操作，也是因為它使用了對應的KubeConfig檔案），這個檔案一般在kubernetes環境上，全路徑：~/.kube/config
  4. pod執行時候的身份是service account，這個service account已經通過RBAC賦予了pod的增加和刪除許可權；

前面兩點需要您自己保證已達到要求，第三和第四點現在先不必關心，後面有詳細的步驟來完成；

實戰環境資訊

本次實戰的環境如下圖所示，一套kubernetes環境（版本是1.15.3），另外還有一臺CentOS7電腦，上面已部署了flink-1.10（這裡的部署是說把安裝包解壓，不啟動任何服務）：
在這裡插入圖片描述
準備完畢，開始實戰了~

實戰內容簡介

本次實戰是在kubernetes環境建立一個session cluster，然後提交任務到這個sessionc cluster執行，與官方教程不同的是本次實戰使用自定義namespace和service account，畢竟生產環境一般是不允許使用default作為namespace和service account的；

實戰

  1. 在CetnOS7電腦上操作時使用的是root賬號；
  2. 在kubernetes的節點上，確保有權執行kubectl命令對pod和service進行增刪改查，將檔案~/.kube/config複製到CentOS7電腦的~/.kube/目錄下；
  3. 在kubernetes的節點上，執行以下命令建立名為flink-session-cluster的namespace：
kubectl create namespace flink-session-cluster
  1. 執行以下命令建立名為flink的serviceaccount：
kubectl create serviceaccount flink -n flink-session-cluster
  1. 執行以下命令做serviceaccount和角色的繫結：
kubectl create clusterrolebinding flink-role-binding-flink \
  --clusterrole=edit \
  --serviceaccount=flink-session-cluster:flink
  1. SSH登入部署了flink的CentOS7電腦，在flink目錄下執行以下命令，即可建立名為session001的session cluster，其中-Dkubernetes.namespace引數指定了namespace，另外還指定了一個TaskManager例項使用一個CPU資源、4G記憶體、內含6個slot：
./bin/kubernetes-session.sh \
  -Dkubernetes.namespace=flink-session-cluster \
  -Dkubernetes.jobmanager.service-account=flink \
  -Dkubernetes.cluster-id=session001 \
  -Dtaskmanager.memory.process.size=8192m \
  -Dkubernetes.taskmanager.cpu=1 \
  -Dtaskmanager.numberOfTaskSlots=4 \
  -Dresourcemanager.taskmanager-timeout=3600000
  1. 如下圖，控制檯提示建立成功，並且紅框中提示了flink web UI的訪問地址是http://192.168.50.135:31753：
    在這裡插入圖片描述
  2. 下載映象和啟動容器需要一定的時間，可以用kubectl get和kubectl describe命令觀察對應的deployment和pod的狀態：

Flink Native Kubernetes實戰
9. pod啟動成功後訪問flink web，如下圖，此時還沒有建立TaskManager，因此Slot為零：
在這裡插入圖片描述
10. 回到CentOS7電腦，在flink目錄下執行以下命令，將官方自帶的WindowJoin任務提交到session cluster：

./bin/flink run -d \
  -e kubernetes-session \
  -Dkubernetes.namespace=flink-session-cluster \
  -Dkubernetes.cluster-id=session001 \
  examples/streaming/WindowJoin.jar
  1. 控制檯提示提交任務成功：
    在這裡插入圖片描述
  2. 頁面上也會同步顯示增加了一個TaskManager，對應6個slot，已經用掉了一個：
    在這裡插入圖片描述
  3. 再連續提交5次相同的任務，將此TaskManager的slot用光：
    在這裡插入圖片描述
  4. 這時候再提交一次任務，按理來說應該增加一個TaskManager，可是頁面如下圖所示，TaskManager數量還是1，並沒有增加，並且紅框中顯示新增的任務並沒有正常執行起來：

在這裡插入圖片描述
15. 在kubernetes環境檢視pod情況，如下圖紅框所示，有個新建的pod狀態是Pending，看來這就是第七個任務不能執行就是因為這個新建的pod無法正常工作導致的：
在這裡插入圖片描述
16. 再看看這個namespace的事件通知，如下圖紅框所示，名為session001-taskmanager-1-2的pod有一條通知資訊：由於CPU資源不足導致pod建立失敗：
在這裡插入圖片描述
17. 窮到沒錢配置kubernetes環境，連一核CPU都湊不齊：

在這裡插入圖片描述
18. 一時半會兒也找不出多餘的CPU資源，唯一能做的就是降低TaskManager的CPU要求，剛才配置的是一個TaskManager使用一核CPU，我打算降低一半，即0.5核，這樣就夠兩個TaskManager用了；
19. 您可能會疑惑：怎麼會有0.5個CPU這樣的配置？這個和kubernetes的資源限制有關，kubernetes對pod的CPU限制粒度是千分之一個CPU，也是就是在kubernetes中，配置1000單位的CPU表示使用1核，我們配置0.5核，不過是配置了500單位而已（所以我還可以更窮....）
20. 接下來的操作是先停掉當前的session cluster，再重新建立一個，建立的時候引數-Dkubernetes.taskmanager.cpu的值從1改為0.5
21. 在CentOS7電腦上執行以下命令，將session cluster停掉，釋放所有資源：

echo 'stop' | \
  ./bin/kubernetes-session.sh \
  -Dkubernetes.namespace=flink-session-cluster \
  -Dkubernetes.cluster-id=session001 \
  -Dexecution.attached=true
  1. 控制檯提示操作成功：
    在這裡插入圖片描述
  2. 稍等一分鐘左右，再去檢視pod，發現已經全部不見了：
    在這裡插入圖片描述
  3. 在CentOS7電腦的flink目錄下，執行以下命令，和之前相比，唯一變化就是-Dkubernetes.taskmanager.cpu引數的值：
./bin/kubernetes-session.sh \
  -Dkubernetes.namespace=flink-session-cluster \
  -Dkubernetes.jobmanager.service-account=flink \
  -Dkubernetes.cluster-id=session001 \
  -Dtaskmanager.memory.process.size=4096m \
  -Dkubernetes.taskmanager.cpu=0.5 \
  -Dtaskmanager.numberOfTaskSlots=6 \
  -Dresourcemanager.taskmanager-timeout=3600000
  1. 從控制檯提示得到新的flink web UI埠值，再訪問網頁，發現啟動成功了：
    在這裡插入圖片描述
  2. 像之前那樣提交任務，連續提交7個，這一次很順利，在提交了第七個任務後，新的TaskManager建立成功，7個任務都成功執行了：
    在這裡插入圖片描述
  3. 用kubectl describe pod命令檢視TaskManager的pod，如下圖紅框所示，可見該pod的CPU用量是500單位，符合之前的推測：
    在這裡插入圖片描述
    這裡再提醒一下，降低CPU用量，意味著該pod中的程式獲取的CPU執行時間被降低，會導致任務執行變慢，所以這種方法不可取，正確的思路是確保硬體資源能滿足業務需求(像我這樣窮到一核CPU都湊不齊的情況還是不多的....)

清理資源

如果已完成Flink Native Kubernetes體驗，想徹底清理掉前面的所有資源，請按照以下步驟操作：

  1. 在web頁面點選Cancel Job停止正在執行的任務，如下圖紅框：
    在這裡插入圖片描述
  2. 在CentOS7電腦上停止session cluster：
echo 'stop' | \
  ./bin/kubernetes-session.sh \
  -Dkubernetes.namespace=flink-session-cluster \
  -Dkubernetes.cluster-id=session001 \
  -Dexecution.attached=true
  1. 在kubernetes節點清理service、clusterrolebinding、serviceaccount、namespace：
kubectl delete service session001 -n flink-session-cluster
kubectl delete clusterrolebinding flink-role-binding-flink
kubectl delete serviceaccount flink -n flink-session-cluster
kubectl delete namespace flink-session-cluster
  1. 所有cluster session相關的ConfigMap、Service、Deployment、Pod等資源，都通過kubernetes的ownerReferences配置與service關聯，因此一旦service被刪除，其他資源被被自動清理掉，無需處理；

至此，Flink Native Kubernetes相關的實戰就完成了，如果您也在關注這個技術，希望本文能給您一些參考

歡迎關注公眾號：程式設計師欣宸

微信搜尋「程式設計師欣宸」，我是欣宸，期待與您一同暢遊Java世界...
https://github.com/zq2599/blog_demos

相關文章