耗時很長時間解決了一個spark in docker的問題，記錄一下。

成都創新互聯IDC提供業務:聯通機房服務器托管,成都服務器租用,聯通機房服務器托管,重慶服務器租用等四川省內主機托管與主機租用業務;數據中心含:雙線機房,BGP機房,電信機房,移動機房,聯通機房。

這是個非常奇怪的問題，找遍谷歌都找不到答案，與其說是分析出來倒不如說是偶然發現。

先介紹一下架構和環境。

Z機器是docker的宿主機，在每個docker里面都跑了一個Zeppelin用作數據分析，之所以這樣弄，是客戶要求每個人的環境都必須是獨立的。

Zdocker假設是Z上面跑著zeppelin的運行的一個docker鏡像。

Zdocker使用默認的bridge方式連接到外部集群

Hadoop集群按照加入集群的先后順序分為兩部分進行觀察。A為先加入集群的機器有31臺，B為后加入集群的機器15臺。

Spark使用client方式提交，用YARN做資源管理。

表象：

Zdocker里面通過Zeppelin頁面提交的Spark計算任務一直都是正常的，直到B的15臺加入到集群里

B的15臺配置從操作系統到網絡到JVM到hadoop全部一模一樣，沒有區別。

B加入后，所有從Zdocker里面提交的Spark任務全部不能跑，executor在15臺機器執行時會報 NoRouteToHost gateway: 7337

B加入后，所有在Zdocker外面提交的Spark任務全部正常。

B加入后，所有executor不運行在B機器上的全部正常

B加入后，Zdocker內外所有MapReduce任務正常。

在YARN里去掉B的15臺機器，一切正常。

分析：

7337為spark的yarn shuffle端口

第一階段

既然是NoRouteToHost，第一反應是DNS問題，檢查所有DNS和hosts文件，沒有發現問題，檢查iptables，route表，全部無問題，解決失敗。

第二階段

懷疑是spark bug，我想知道 gateway 是從哪冒出來的，翻閱了spark里面報錯相關的scala和java代碼，沒有找到這個跟gateway相關的東西。

第三階段

因為B加入前是正常的，B加入后就不正常了，檢查docker里面的DNS和hosts，全部正常，繼續失敗。

第四階段

懷疑環境變量不同，檢查所有A,B機器配置，環境變量完全一樣。

因為是yarn shuffle，懷疑spark-assembly問題，檢查后發現無問題。

第五階段

嘗試暴力解決，將gateway加入DNS解析，強行指到B集群的一臺機器上。也就是所有的spark 外部shuffle會指向到一臺機器的 7337端口。好，跑了一天沒問題，第二天就有問題了，那臺被強行指定的機器報找不到作業在本地shuffle的index文件。

第六階段

嘗試在docker里面發現問題，看了一下docker的路由表，發現172.17.42.1是docker的網關，抱著死馬心態在docker里面ping了一下gateway主機名，發現通的。于是襠下一緊，感覺有門可入。

docker內部默認的網關是172.17.42.1，然后默認還給了個hostname叫gateway，或許這就是了。

于是跑到A找了一臺機器ping gateway主機名，ping卡死，因為無論DNS還是hosts，在任何hadoop的節點都是沒有解析過gateway這個主機名的。然后到B找了一臺機器ping，直接退出報 ping: unknown host gateway。

于是開始琢磨，兩個機器網絡環境不同，或許這就是問題點了。

A的幾十臺機器，因為安全需要，沒有開放任何外網訪問。所以在A的機器上ping gateway時，根本連域名都解析不了，所以會卡死。而B的十幾臺機器因為是新加的，運維忘了關閉外網訪問，所以能找到公網的域名解析服務器，但是公網解析不了gateway域名，于是直接返回 unknown host 并退出。

讓運維關閉B機器的公網訪問，再從Zdocker上面提交作業，一切正常。

原因：

解決了問題再回來分析一下應該是因為zeppelin從docker里面提交spark作業，spark是client方式跑，driver是跑在docker里面的，driver在向docker外的yarn申請資源分配executor的時候，在哪里帶上了gateway這個主機名作為環境變量傳遞給了executor的container。如果沒有外網訪問，executor會使用本機的 7337作為yarn shuffle的端口，而有了外網訪問，executor會去查詢gateway的ip，但是DNS返回錯誤，于是就會造成executor執行錯誤。這也很好的解釋了為什么docker外面的spark作業無論B是否啟動都不會報錯正常執行。

所以這他媽其實是一個很低端的錯誤，只是誰都不會想到，spark執行的失敗還能跟是否訪問公網有關。就跟上次解決MR速度慢一樣，誰能想到網卡能他媽自己跳成10Mbps啊。

后續還需要繼續研究docker的網絡機制和spark的driver和executor之間的傳參機制，才能徹底干掉這個問題。