如果Kubernetes提供者提供了一个网络拓扑插件来解析数据的位置以及spark节点应该运行的位置，那么基本数据的位置就可以正常工作。* 并且您构建了包含code here * 的Kubernetes
有一个测试this data locality的方法。为了完整起见，我将它复制到这里：
下面介绍如何检查namenode中的数据局部性是否正常。
启动HDFS客户端单元并进入单元内部。

$ kubectl run -i --tty hadoop --image=uhopper/hadoop:2.7.2
--generator="run-pod/v1" --command -- /bin/bash

在单元中，在HDFS上创建一个简单的文本文件。

$ hadoop fs
-fs hdfs://hdfs-namenode-0.hdfs-namenode.default.svc.cluster.local
-cp file:/etc/hosts /hosts

将文件的副本数设置为群集节点数。这可确保在运行客户端Pod的群集节点中有文件的副本。请等待一段时间，直到出现此情况。

`$ hadoop fs -setrep NUM-REPLICAS /hosts`

运行下面的hdfs cat命令。从调试消息中，查看正在使用哪个datanode。确保它是您的本地datanode。（您可以从$ kubectl get pods hadoop -o json获得此命令|grep hostIP。请在机架外部执行此操作）

$ hadoop --loglevel DEBUG fs
-fs hdfs://hdfs-namenode-0.hdfs-namenode.default.svc.cluster.local
-cat /hosts ... 17/04/24 20:51:28 DEBUG hdfs.DFSClient: Connecting to datanode 10.128.0.4:50010 ...

如果不是，您应该检查您的本机数据节点是否在上述两柴消息的清单中。如果不是，则是因为步骤（3）尚未完成。请稍候。（如果可能，您可以使用较小的丛集进行此测试）

`17/04/24 20:51:28 DEBUG hdfs.DFSClient: newInfo = LocatedBlocks{ fileLength=199 underConstruction=false blocks=[LocatedBlock{BP-347555225-10.128.0.2-1493066928989:blk_1073741825_1001; getBlockSize()=199; corrupt=false; offset=0; locs=[DatanodeInfoWithStorage[10.128.0.4:50010,DS-d2de9d29-6962-4435-a4b4-aadf4ea67e46,DISK], DatanodeInfoWithStorage[10.128.0.3:50010,DS-0728ffcf-f400-4919-86bf-af0f9af36685,DISK], DatanodeInfoWithStorage[10.128.0.2:50010,DS-3a881114-af08-47de-89cf-37dec051c5c2,DISK]]}] lastLocatedBlock=LocatedBlock{BP-347555225-10.128.0.2-1493066928989:blk_1073741825_1001;`

重复hdfs cat命令多次。检查是否始终使用相同的数据节点。