欢送拜访我的GitHub
https://github.com/zq2599/blog_demos
内容:所有原创文章分类汇总及配套源码,波及Java、Docker、Kubernetes、DevOPS等;
回顾Flink Kubernetes
<font color=”blue”>Flink Kubernetes</font>与<font color=”blue”>Flink Native Kubernetes</font>是不同的概览,先回顾一下Flink Kubernetes:
- 如下图,从1.2版本到目前最新的1.10,Flink官网都给出了Kubernetes上部署和运行Flink的计划:
- 在kubernetes上有两种形式运行flink:<font color=”blue”>session cluster</font>和<font color=”blue”>job cluster</font>,其中session cluster是一套服务能够提交多个工作,而job cluster则是一套服务只对应一个工作;
- 下图是典型的session cluster部署操作,可见要害是筹备好service、deployment等资源的yaml文件,再用kubectl命令创立:
对于Flink Native Kubernetes
- 先比照官网的1.9和1.10版本文档,如下图和红框和蓝框所示,可见<font color=”blue”>Flink Native Kubernetes</font>是1.10版本才有的新性能:
- 看看Native Kubernetes是如何运行的,如下图,创立session cluster的命令来自Flink安装包:
- 更乏味的是,提交工作的命令也来自Flink安装包,就是咱们平时提交工作用到<font color=”blue”>flink run</font>命令,如下图:
- 联合官网给出的提交和部署流程图就更清晰了:kubernetes上部署了Flink Master,由Flink Client来提交session cluster和job的申请:
Flink Kubernetes和Flink Native Kubernetes的区别
至此,能够小结Flink Kubernetes和Flink Native Kubernetes的区别:
- <font color=”blue”>Flink Kubernetes</font>自1.2版本首次呈现,<font color=”red”>Flink Native Kubernetes</font>自1.10版本首次呈现;
- <font color=”blue”>Flink Kubernetes</font>是把JobManager和TaskManager等过程放入容器,在kubernetes治理和运行,这和咱们把java利用做成docker镜像再在kubernetes运行是一个情理,都是用kubectl在kubernetes上操作;
- <font color=”red”>Flink Native Kubernetes</font>是在Flink安装包中有个工具,此工具能够向kubernetes的Api Server发送申请,例如创立Flink Master,并且能够和Flink Master通信,用于提交工作,咱们只有用好Flink安装包中的工具即可,无需在kubernetes上执行kubectl操作;
Flink Native Kubernetes在Flink-1.10版本中的不足之处
- Flink Native Kubernetes只是Beta版,属于试验性质(官网原话:still experimental),<font color=”red”>请勿用于生产环境!</font>
- 只反对session cluster模式(一个常驻session执行多个工作),还不反对Job clusters模式(一个工作对应一个session)
只管还没有进入Release阶段,但这种操作模式对不相熟kubernetes的开发者来说还是很敌对的,接下来通过实战来体验吧;
官网要求
为了体验Native Kubernetes,flink官网提出了下列前提条件:
- kubernetes版本不低于<font color=”blue”>1.9</font>
- kubernetes环境的DNS是失常的
- KubeConfig文件,并且这个文件是有权对pod和service资源做增删改查的(kubectl命令有权对pod和service做操作,也是因为它应用了对应的KubeConfig文件),这个文件个别在kubernetes环境上,全门路:<font color=”blue”>~/.kube/config</font>
- 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的;
实战
- 在CetnOS7电脑上操作时应用的是root账号;
- 在kubernetes的节点上,确保有权执行kubectl命令对pod和service进行增删改查,将文件<font color=”blue”>~/.kube/config</font>复制到CentOS7电脑的<font color=”blue”>~/.kube/</font>目录下;
- 在kubernetes的节点上,执行以下命令创立名为<font color=”blue”>flink-session-cluster</font>的namespace:
kubectl create namespace flink-session-cluster
- 执行以下命令创立名为<font color=”blue”>flink</font>的serviceaccount:
kubectl create serviceaccount flink -n flink-session-cluster
- 执行以下命令做serviceaccount和角色的绑定:
kubectl create clusterrolebinding flink-role-binding-flink \
--clusterrole=edit \
--serviceaccount=flink-session-cluster:flink
- SSH登录部署了flink的CentOS7电脑,在flink目录下执行以下命令,即可创立名为<font color=”blue”>session001</font>的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
- 如下图,控制台提醒创立胜利,并且红框中提醒了flink web UI的拜访地址是<font color=”blue”>http://192.168.50.135:31753</font>:
- 下载镜像和启动容器须要肯定的工夫,能够用<font color=”blue”>kubectl get</font>和<font color=”blue”>kubectl describe</font>命令察看对应的deployment和pod的状态:
- pod启动胜利后拜访flink web,如下图,此时还没有创立TaskManager,因而Slot为零:
- 回到CentOS7电脑,在flink目录下执行以下命令,将官网自带的<font color=”blue”>WindowJoin</font>工作提交到session cluster:
./bin/flink run -d \
-e kubernetes-session \
-Dkubernetes.namespace=flink-session-cluster \
-Dkubernetes.cluster-id=session001 \
examples/streaming/WindowJoin.jar
- 控制台提醒提交工作胜利:
- 页面上也会同步显示减少了一个TaskManager,对应6个slot,曾经用掉了一个:
- 再间断提交5次雷同的工作,将此TaskManager的slot用光:
- 这时候再提交一次工作,按理来说应该减少一个TaskManager,可是页面如下图所示,TaskManager数量还是1,并没有减少,并且红框中显示新增的工作并没有失常运行起来:
- 在kubernetes环境查看pod状况,如下图红框所示,有个新建的pod状态是Pending,看来这就是第七个工作不能执行就是因为这个新建的pod无奈失常工作导致的:
- 再看看这个namespace的事件告诉,如下图红框所示,名为session001-taskmanager-1-2的pod有一条告诉信息:<font color=”blue”>因为CPU资源有余导致pod创立失败</font>:
- 穷到没钱配置kubernetes环境,连一核CPU都凑不齐:
- 一时半会儿也找不出多余的CPU资源,惟一能做的就是升高TaskManager的CPU要求,方才配置的是一个TaskManager应用一核CPU,我打算升高一半,即<font color=”red”>0.5核</font>,这样就够两个TaskManager用了;
- 您可能会纳闷:怎么会有0.5个CPU这样的配置?这个和kubernetes的资源限度无关,kubernetes对pod的CPU限度粒度是千分之一个CPU,也是就是在kubernetes中,配置1000单位的CPU示意应用1核,咱们配置0.5核,不过是配置了500单位而已(所以我还能够更穷….)
- 接下来的操作是先停掉以后的session cluster,再从新创立一个,创立的时候参数<font color=”blue”>-Dkubernetes.taskmanager.cpu</font>的值从1改为<font color=”red”>0.5</font>
- 在CentOS7电脑上执行以下命令,将session cluster停掉,开释所有资源:
echo 'stop' | \
./bin/kubernetes-session.sh \
-Dkubernetes.namespace=flink-session-cluster \
-Dkubernetes.cluster-id=session001 \
-Dexecution.attached=true
- 控制台提醒操作胜利:
- 稍等一分钟左右,再去查看pod,发现曾经全副不见了:
- 在CentOS7电脑的flink目录下,执行以下命令,和之前相比,惟一变动就是<font color=”blue”>-Dkubernetes.taskmanager.cpu</font>参数的值:
./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
- 从控制台提醒失去新的flink web UI端口值,再拜访网页,发现启动胜利了:
- 像之前那样提交工作,间断提交7个,这一次很顺利,在提交了第七个工作后,新的TaskManager创立胜利,7个工作都胜利执行了:
- 用<font color=”blue”>kubectl describe pod</font>命令查看TaskManager的pod,如下图红框所示,可见该pod的CPU用量是<font color=”red”>500单位</font>,合乎之前的揣测:
这里再揭示一下,升高CPU用量,意味着该pod中的过程获取的CPU执行工夫被升高,会导致工作执行变慢,所以这种办法不可取,正确的思路是确保硬件资源能满足业务需要(像我这样穷到一核CPU都凑不齐的状况还是不多的….)
清理资源
如果已实现Flink Native Kubernetes体验,想彻底清理掉后面的所有资源,请依照以下步骤操作:
- 在web页面点击Cancel Job进行正在运行的工作,如下图红框:
- 在CentOS7电脑上进行session cluster:
echo 'stop' | \
./bin/kubernetes-session.sh \
-Dkubernetes.namespace=flink-session-cluster \
-Dkubernetes.cluster-id=session001 \
-Dexecution.attached=true
- 在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
- 所有cluster session相干的ConfigMap、Service、Deployment、Pod等资源,都通过kubernetes的<font color=”blue”>ownerReferences</font>配置与service关联,因而一旦service被删除,其余资源被被主动清理掉,无需解决;
至此,Flink Native Kubernetes相干的实战就实现了,如果您也在关注这个技术,心愿本文能给您一些参考
欢送关注公众号:程序员欣宸
微信搜寻「程序员欣宸」,我是欣宸,期待与您一起畅游Java世界…
https://github.com/zq2599/blog_demos