背景

在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。（之前打开的还可以用）