獲取 metadata 過程詳解 - 天天5分鐘玩轉 OpenStack（167）

接上節，啓動 neutron router 後 instance c1 終於拿到了 metadata, 從下面 c1 的啓動日誌可知：

 

 

c1 所認爲的 metadata 服務地址是 169.254.169.254，端口爲 80。咱們在 c1 中嘗試訪問一下 metadata。

 

 

 

 

確實可以拿到 metadata。但咱們知道 nova-api-metadata 是運行在控制節點上的，IP並非 169.254.169.254，這是怎麼實現的呢？下面咱們分析一下這個過程。

 

從 c1 的路由表得訪問 169.254.169.254 的請求會走 17.17.17.1。
 

 

17.17.17.1 實際上就是 test_router 在 test_net 上的 interface IP。這條路由是 OpenStack 自動添加到 instance 中的，這樣就將 metadata 的請求轉發到 neutron router。

 

 

ip netns 是管理 linux network namespace 的命令，若是對 namespace 不熟悉，可參考教程前面相關章節。

 

test_router 接收到 c1 的請求，會經過 iptable 規則轉發到 9697 端口。

 

 

 

9697 端口是幹嗎的？這是 neutron-ns-metadata-proxy 的監聽端口。

 

 

 

到這裏咱們能夠把思路從新理一下了：

 

1. instance 經過預約義的 169.254.169.254 請求 metadata。
    

2. 請求被轉發到 neutron router。
    

3. router 將請求轉發給 neutron-ns-metadata-proxy。
    

4. 再後面就簡單了：neutron-ns-metadata-proxy 將請求經過 unix domain socket 發給 neutron-metadata-agent，後者再經過管理網絡發給 nova-api-metadata。

OpenStack 默認經過 l3-agent 建立和管理 neutron-ns-metadata-proxy。但不是全部環境都有 l3-agent，好比直接用物理 router 的場景。這時就須要讓 dhcp-agent 來管理 neutron-ns-metadata-proxy。

下一節咱們分析 dhcp-agent 如何處理 metadata 請求。