Flink Native Kubernetes實(shí)戰(zhàn)

歡迎訪問我的GitHub

這里分類和匯總了欣宸的全部原創(chuàng)(含配套源碼)：https://github.com/zq2599/blog_demos

回顧Flink Kubernetes

Flink Kubernetes

與

Flink Native Kubernetes

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

如下圖，從1.2版本到目前最新的1.10，F(xiàn)link官方都給出了Kubernetes上部署和運(yùn)行Flink的方案：

在kubernetes上有兩種方式運(yùn)行flink：

session cluster

和

job cluster

，其中session cluster是一套服務(wù)可以提交多個(gè)任務(wù)，而job cluster則是一套服務(wù)只對(duì)應(yīng)一個(gè)任務(wù)；

下圖是典型的session cluster部署操作，可見關(guān)鍵是準(zhǔn)備好service、deployment等資源的yaml文件，再用kubectl命令創(chuàng)建：

關(guān)于Flink Native Kubernetes

先對(duì)比官方的1.9和1.10版本文檔，如下圖和紅框和藍(lán)框所示，可見

Flink Native Kubernetes

是1.10版本才有的新功能：

看看Native Kubernetes是如何運(yùn)行的，如下圖，創(chuàng)建session cluster的命令來自Flink安裝包：

更有趣的是，提交任務(wù)的命令也來自Flink安裝包，就是我們平時(shí)提交任務(wù)用到

flink run

命令，如下圖：

結(jié)合官方給出的提交和部署流程圖就更清晰了：kubernetes上部署了Flink Master，由Flink Client來提交session cluster和job的請(qǐng)求：

Flink Kubernetes和Flink Native Kubernetes的區(qū)別

至此，可以小結(jié)Flink Kubernetes和Flink Native Kubernetes的區(qū)別：

Flink Kubernetes

自1.2版本首次出現(xiàn)，

Flink Native Kubernetes

自1.10版本首次出現(xiàn)；

Flink Kubernetes

是把JobManager和TaskManager等進(jìn)程放入容器，在kubernetes管理和運(yùn)行，這和我們把java應(yīng)用做成docker鏡像再在kubernetes運(yùn)行是一個(gè)道理，都是用kubectl在kubernetes上操作；

Flink Native Kubernetes

是在Flink安裝包中有個(gè)工具，此工具可以向kubernetes的Api Server發(fā)送請(qǐng)求，例如創(chuàng)建Flink Master，并且可以和Flink Master通訊，用于提交任務(wù)，我們只要用好Flink安裝包中的工具即可，無需在kubernetes上執(zhí)行kubectl操作；

Flink Native Kubernetes在Flink-1.10版本中的不足之處

Flink Native Kubernetes只是Beta版，屬于實(shí)驗(yàn)性質(zhì)（官方原話：still experimental），

請(qǐng)勿用于生產(chǎn)環(huán)境！

只支持session cluster模式（一個(gè)常駐session執(zhí)行多個(gè)任務(wù)），還不支持Job clusters模式(一個(gè)任務(wù)對(duì)應(yīng)一個(gè)session)

盡管還沒有進(jìn)入Release階段，但這種操作模式對(duì)不熟悉kubernetes的開發(fā)者來說還是很友好的，接下來通過實(shí)戰(zhàn)來體驗(yàn)吧；

官方要求

為了體驗(yàn)Native Kubernetes，flink官方提出了下列前提條件：

kubernetes版本不低于

1.9

kubernetes環(huán)境的DNS是正常的

KubeConfig文件，并且這個(gè)文件是有權(quán)對(duì)pod和service資源做增刪改查的（kubectl命令有權(quán)對(duì)pod和service做操作，也是因?yàn)樗褂昧藢?duì)應(yīng)的KubeConfig文件），這個(gè)文件一般在kubernetes環(huán)境上，全路徑：

~/.kube/config

pod執(zhí)行時(shí)候的身份是service account，這個(gè)service account已經(jīng)通過RBAC賦予了pod的增加和刪除權(quán)限；

前面兩點(diǎn)需要您自己保證已達(dá)到要求，第三和第四點(diǎn)現(xiàn)在先不必關(guān)心，后面有詳細(xì)的步驟來完成；

實(shí)戰(zhàn)環(huán)境信息

本次實(shí)戰(zhàn)的環(huán)境如下圖所示，一套kubernetes環(huán)境（版本是1.15.3），另外還有一臺(tái)CentOS7電腦，上面已部署了flink-1.10（這里的部署是說把安裝包解壓，不啟動(dòng)任何服務(wù)）：

準(zhǔn)備完畢，開始實(shí)戰(zhàn)了~

實(shí)戰(zhàn)內(nèi)容簡介

本次實(shí)戰(zhàn)是在kubernetes環(huán)境創(chuàng)建一個(gè)session cluster，然后提交任務(wù)到這個(gè)sessionc cluster運(yùn)行，與官方教程不同的是本次實(shí)戰(zhàn)使用自定義namespace和service account，畢竟生產(chǎn)環(huán)境一般是不允許使用default作為namespace和service account的；

實(shí)戰(zhàn)

在CetnOS7電腦上操作時(shí)使用的是root賬號(hào)；

在kubernetes的節(jié)點(diǎn)上，確保有權(quán)執(zhí)行kubectl命令對(duì)pod和service進(jìn)行增刪改查，將文件

~/.kube/config

復(fù)制到CentOS7電腦的

~/.kube/

目錄下；

在kubernetes的節(jié)點(diǎn)上，執(zhí)行以下命令創(chuàng)建名為

flink-session-cluster

的namespace：

kubectl create namespace flink-session-cluster

執(zhí)行以下命令創(chuàng)建名為

flink

的serviceaccount：

kubectl create serviceaccount flink -n flink-session-cluster

執(zhí)行以下命令做serviceaccount和角色的綁定：

kubectl create clusterrolebinding flink-role-binding-flink \ --clusterrole=edit \ --serviceaccount=flink-session-cluster:flink

SSH登錄部署了flink的CentOS7電腦，在flink目錄下執(zhí)行以下命令，即可創(chuàng)建名為

session001

的session cluster，其中-Dkubernetes.namespace參數(shù)指定了namespace，另外還指定了一個(gè)TaskManager實(shí)例使用一個(gè)CPU資源、4G內(nèi)存、內(nèi)含6個(gè)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

如下圖，控制臺(tái)提示創(chuàng)建成功，并且紅框中提示了flink web UI的訪問地址是

http://192.168.50.135:31753

：

下載鏡像和啟動(dòng)容器需要一定的時(shí)間，可以用

kubectl get

和

kubectl describe

命令觀察對(duì)應(yīng)的deployment和pod的狀態(tài)：

9. pod啟動(dòng)成功后訪問flink web，如下圖，此時(shí)還沒有創(chuàng)建TaskManager，因此Slot為零：

10. 回到CentOS7電腦，在flink目錄下執(zhí)行以下命令，將官方自帶的

WindowJoin

任務(wù)提交到session cluster：

./bin/flink run -d \ -e kubernetes-session \ -Dkubernetes.namespace=flink-session-cluster \ -Dkubernetes.cluster-id=session001 \ examples/streaming/WindowJoin.jar

控制臺(tái)提示提交任務(wù)成功：

頁面上也會(huì)同步顯示增加了一個(gè)TaskManager，對(duì)應(yīng)6個(gè)slot，已經(jīng)用掉了一個(gè)：

再連續(xù)提交5次相同的任務(wù)，將此TaskManager的slot用光：

這時(shí)候再提交一次任務(wù)，按理來說應(yīng)該增加一個(gè)TaskManager，可是頁面如下圖所示，TaskManager數(shù)量還是1，并沒有增加，并且紅框中顯示新增的任務(wù)并沒有正常運(yùn)行起來：

在kubernetes環(huán)境查看pod情況，如下圖紅框所示，有個(gè)新建的pod狀態(tài)是Pending，看來這就是第七個(gè)任務(wù)不能執(zhí)行就是因?yàn)檫@個(gè)新建的pod無法正常工作導(dǎo)致的：

再看看這個(gè)namespace的事件通知，如下圖紅框所示，名為session001-taskmanager-1-2的pod有一條通知信息：

由于CPU資源不足導(dǎo)致pod創(chuàng)建失敗

：

窮到?jīng)]錢配置kubernetes環(huán)境，連一核CPU都湊不齊：

一時(shí)半會(huì)兒也找不出多余的CPU資源，唯一能做的就是降低TaskManager的CPU要求，剛才配置的是一個(gè)TaskManager使用一核CPU，我打算降低一半，即

0.5核

，這樣就夠兩個(gè)TaskManager用了；

您可能會(huì)疑惑：怎么會(huì)有0.5個(gè)CPU這樣的配置？這個(gè)和kubernetes的資源限制有關(guān)，kubernetes對(duì)pod的CPU限制粒度是千分之一個(gè)CPU，也是就是在kubernetes中，配置1000單位的CPU表示使用1核，我們配置0.5核，不過是配置了500單位而已（所以我還可以更窮…）

接下來的操作是先停掉當(dāng)前的session cluster，再重新創(chuàng)建一個(gè)，創(chuàng)建的時(shí)候參數(shù)

-Dkubernetes.taskmanager.cpu

的值從1改為

0.5

在CentOS7電腦上執(zhí)行以下命令，將session cluster停掉，釋放所有資源：

echo 'stop' | \ ./bin/kubernetes-session.sh \ -Dkubernetes.namespace=flink-session-cluster \ -Dkubernetes.cluster-id=session001 \ -Dexecution.attached=true

控制臺(tái)提示操作成功：

稍等一分鐘左右，再去查看pod，發(fā)現(xiàn)已經(jīng)全部不見了：

在CentOS7電腦的flink目錄下，執(zhí)行以下命令，和之前相比，唯一變化就是

-Dkubernetes.taskmanager.cpu

參數(shù)的值：

./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

從控制臺(tái)提示得到新的flink web UI端口值，再訪問網(wǎng)頁，發(fā)現(xiàn)啟動(dòng)成功了：

像之前那樣提交任務(wù)，連續(xù)提交7個(gè)，這一次很順利，在提交了第七個(gè)任務(wù)后，新的TaskManager創(chuàng)建成功，7個(gè)任務(wù)都成功執(zhí)行了：

用

kubectl describe pod

命令查看TaskManager的pod，如下圖紅框所示，可見該pod的CPU用量是

500單位

，符合之前的推測：

這里再提醒一下，降低CPU用量，意味著該pod中的進(jìn)程獲取的CPU執(zhí)行時(shí)間被降低，會(huì)導(dǎo)致任務(wù)執(zhí)行變慢，所以這種方法不可取，正確的思路是確保硬件資源能滿足業(yè)務(wù)需求(像我這樣窮到一核CPU都湊不齊的情況還是不多的…)

清理資源

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

在web頁面點(diǎn)擊Cancel Job停止正在運(yùn)行的任務(wù)，如下圖紅框：

在CentOS7電腦上停止session cluster：

echo 'stop' | \ ./bin/kubernetes-session.sh \ -Dkubernetes.namespace=flink-session-cluster \ -Dkubernetes.cluster-id=session001 \ -Dexecution.attached=true

在kubernetes節(jié)點(diǎn)清理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

所有cluster session相關(guān)的ConfigMap、Service、Deployment、Pod等資源，都通過kubernetes的

ownerReferences

配置與service關(guān)聯(lián)，因此一旦service被刪除，其他資源被被自動(dòng)清理掉，無需處理；

至此，F(xiàn)link Native Kubernetes相關(guān)的實(shí)戰(zhàn)就完成了，如果您也在關(guān)注這個(gè)技術(shù)，希望本文能給您一些參考。

歡迎關(guān)注華為云博客：程序員欣宸

學(xué)習(xí)路上，你不孤單，欣宸原創(chuàng)一路相伴…

Flink Kubernetes 容器

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請(qǐng)聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請(qǐng)聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。