共計 1022 個字符，預計需要花費 3 分鐘才能閱讀完成。

獲取 metadata 過程是怎樣的，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面丸趣 TV 小編將為大家詳細講解，有這方面需求的人可以來學習下，希望你能有所收獲。

啟動 neutron router 后 instance c1  終于拿到了 metadata

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 的監聽端口。

到這里我們可以把思路重新理一下了：

instance 通過預定義的  169.254.169.254  請求 metadata。

請求被轉發到 neutron router。

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

再后面就簡單了：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。

看完上述內容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注丸趣 TV 行業資訊頻道，感謝您對丸趣 TV 的支持。