在Kubernetes的pod中使用yarn-client调用远

2019-08-08  本文已影响0人  小毛1221

背景

在k8s的pod中使用yarn-client模式调用spark集群,从pod到spark网络是通的,但是当spark回调pod时,无法解析到pod的ip,导致失败。
又尝试pod的svc使用nodePort暴露端口,然后将k8s集群ip传给spark。但是由于使用的是yarn-client模式,需要先在pod本地启动driver,如果我此时将k8s集群ip传递给spark,本地driver启动不成功(监听的IP和本机IP不匹配),也会失败。

方案1

修改pod本地的hosts文件,将pod被调度到的node节点hostname映射为pod clusterIP。
此时将spark.driver.port设置为节点的hostname传递给spark集群。本地driver启动成功(监听的hostname被映射为了本机IP)。
修改pod的svc为nodePort模式,暴露spark.driver.port和spark.blockManager.port。

优点

可以随心所欲,创建多个notebook使用spark。

缺点

修改了本地的hosts映射,如果pod内想使用node节点的hostname访问,会发生问题。但是现在这种场景看起来不多。
配置较为繁琐,spark.driver.port和spark.blockManager.port只暴露两个端口不知道能否满足所有要求,如果spark有其他组件需要回调,会导致无法连接。
修改pod暴露端口后,apigateway中会多注册一条转发信息,导致前端页面无法访问notebook。(之前打开的还可以用)

方案2

与方案1类似,只不过不修改pod本地的hosts文件,而是修改spark集群的dns,将pas-xxxx-notebook-xxxx映射为node IP。

优点

可以随心所欲,创建多个notebook使用spark。
不用修改pod本地hosts,不影响使用。

缺点

配置较为繁琐,spark.driver.port和spark.blockManager.port只暴露两个端口不知道能否满足所有要求,如果spark有其他组件需要回调,会导致无法连接。
修改pod暴露端口后,apigateway中会多注册一条转发信息,导致前端页面无法访问notebook。(之前打开的还可以用)

方案3

将pod修改为hostNetwork模式,容器可以使用宿主机的网络协议栈,复用宿主机的IP,可以监听端口,Spark也可以回调。
每次启动pod时修改nginx、jupyter notebook监听端口,修改svc的targetPort,这样可在同一个node上启动多个pod。
这个方案看起来不错,但是需要考虑下如何动态修改svc映射的port。

优点

配置简单,所有端口与宿主机共用,无需担心spark回调端口问题。
不用修改pod本地hosts,不影响使用。
不用修改spark集群dns。
不用在apigateway中生成记录,前端页面可以正常访问notebook。

缺点

由于与宿主机共用端口,部署多个pod时,pod中启动的nginx和jupyter notebook会造成端口冲突,从而导致启动失败。目前一个node只能部署成功启动一个可调用spark集群的pod。
如果集群有多个node的话,pod启动时由于端口冲突造成失败,k8s检测不到pod启动失败原因,无法自动把pod调度到其他node。
每次启动pod时修改nginx、jupyter notebook监听端口,修改svc的targetPort,这样可在同一个node上启动多个pod。

方案4

还在进行中,没通。
修改pyspark源码,发送集群IP给spark,监听本地IP启动driver。
其他与方案1类似。

优点

可以随心所欲,创建多个notebook使用spark。
不用修改pod本地hosts,不影响使用。
不用修改spark集群dns。

缺点

配置较为繁琐,spark.driver.port和spark.blockManager.port只暴露两个端口不知道能否满足所有要求,如果spark有其他组件需要回调,会导致无法连接。
修改pod暴露端口后,apigateway中会多注册一条转发信息,导致前端页面无法访问notebook。(之前打开的还可以用)

上一篇下一篇

猜你喜欢

热点阅读