回顾Flink Kubernetes
Flink Kubernetes
关于Flink Native Kubernetes
先对比官方的1.9和1.10版本文档,如下图和红框和蓝框所示,可见Flink Native Kubernetes是1.10版本才有的新功能:Flink Kubernetes和Flink Native Kubernetes的区别
至此,可以小结Flink Kubernetes和Flink Native Kubernetes的区别:
Flink Kubernetes自1.2版本首次出现,Flink Native Kubernetes自1.10版本首次出现;Flink Kubernetes是把JobManager和TaskManager等进程放入容器,在kubernetes管理和运行,这和我们把java应用做成docker镜像再在kubernetes运行是一个道理,都是用kubectl在kubernetes上操作;Flink Native Kubernetes是在Flink安装包中有个工具,此工具可以向kubernetes的Api Server发送请求,例如创建Flink Master,并且可以和Flink Master通讯,用于提交任务,我们只要用好Flink安装包中的工具即可,无需在kubernetes上执行kubectl操作;Flink Native Kubernetes在Flink-1.10版本中的不足之处
Flink Native Kubernetes只是Beta版,属于实验性质(官方原话:still experimental),请勿用于生产环境!只支持session cluster模式(一个常驻session执行多个任务),还不支持Job clusters模式(一个任务对应一个session)尽管还没有进入Release阶段,但这种操作模式对不熟悉kubernetes的开发者来说还是很友好的,接下来通过实战来体验吧;
官方要求
为了体验Native Kubernetes,除了flink版本不能低于1.10,flink官方还还提出了下列前提条件:
kubernetes版本不低于1.9kubernetes环境的DNS是正常的KubeConfig文件,并且这个文件是有权对pod和service资源做增删改查的(kubectl命令有权对pod和service做操作,也是因为它使用了对应的KubeConfig文件),这个文件一般在kubernetes环境上,全路径:~/.kube/configpod执行时候的身份是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的;
实战
在CetnOS7电脑上操作时使用的是root账号;在kubernetes的节点上,确保有权执行kubectl命令对pod和service进行增删改查,将文件<code>kubectl create namespace flink-session-cluster/<code>执行以下命令创建名为flink的serviceaccount:
<code>kubectl create serviceaccount flink -n flink-session-cluster/<code>执行以下命令做serviceaccount和角色的绑定:
<code>kubectl create clusterrolebinding flink-role-binding-flink \\
--clusterrole=edit \\
--serviceaccount=flink-session-cluster:flink/<code>SSH登录部署了flink的CentOS7电脑,在flink目录下执行以下命令,即可创建名为session001的session cluster,其中-Dkubernetes.namespace参数指定了namespace,另外还指定了一个TaskManager实例使用一个CPU资源、4G内存、内含6个slot:
<code>./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/<code>如下图,控制台提示创建成功,并且红框中提示了flink web UI的访问地址是http://192.168.50.135:31753:
<code>./bin/flink run -d \\
-e kubernetes-session \\
-Dkubernetes.namespace=flink-session-cluster \\
-Dkubernetes.cluster-id=session001 \\
examples/streaming/WindowJoin.jar/<code>控制台提示提交任务成功:
<code>echo 'stop' | \\
./bin/kubernetes-session.sh \\
-Dkubernetes.namespace=flink-session-cluster \\
-Dkubernetes.cluster-id=session001 \\
-Dexecution.attached=true/<code>控制台提示操作成功:
<code>./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/<code>从控制台提示得到新的flink web UI端口值,再访问网页,发现启动成功了:
这里再提醒一下,降低CPU用量,意味着该pod中的进程获取的CPU执行时间被降低,会导致任务执行变慢,所以这种方法不可取,正确的思路是确保硬件资源能满足业务需求(像我这样穷到一核CPU都凑不齐的情况还是不多的....)
清理资源
如果已完成Flink Native Kubernetes体验,想彻底清理掉前面的所有资源,请按照以下步骤操作:
在web页面点击Cancel Job停止正在运行的任务,如下图红框:<code>echo 'stop' | \\
./bin/kubernetes-session.sh \\
-Dkubernetes.namespace=flink-session-cluster \\
-Dkubernetes.cluster-id=session001 \\
-Dexecution.attached=true/<code>在kubernetes节点清理service、clusterrolebinding、serviceaccount、namespace:
<code>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/<code>所有cluster session相关的ConfigMap、Service、Deployment、Pod等资源,都通过kubernetes的ownerReferences配置与service关联,因此一旦service被删除,其他资源被被自动清理掉,无需处理;
至此,Flink Native Kubernetes相关的实战就完成了,如果您也在关注这个技术,希望本文能给您一些参考。