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

今天就跟大家聊聊有關 instance 如何從 nova-api-metadata 獲取信息，可能很多人都不太了解，為了讓大家更加了解，丸趣 TV 小編給大家總結了以下內容，希望大家根據這篇文章可以有所收獲。

我們將通過實驗詳細分析 instance 從 nova-api-metadata 獲取信息的完整過程。

環境介紹

1. 一個 all-in-one 環境（多節點類似）。
 

2. 已創建 neutron 網絡  test_net，DHCP 已啟動。在這個 metadata 實驗中， test_net  的 type 不重要，flat、vlan、vxlan 都可以。

3. 暫無 neutron router。

準備就緒，開始實驗。

啟動 instance 通過 cirros 鏡像部署一個 instance，命名為  c1，選擇網絡  test_net。啟動過程中，查看 instance 的啟動日志。

上面的 log 中我們看到兩個信息：

① instance 從 DHCP 拿到了 IP 17.17.17.5，這個好理解，因為我們在 test_net  上開啟的 DHCP 服務。

② instance 會去訪問  http://169.254.169.254/2009-04-04/instance-id，嘗試了  20 次都失敗了。

神奇的 169.254.169.254

169.254.169.254  是個什么地址？

這是 metadata service 的 IP。

這個地址來源于 AWS，當年亞馬遜在設計公有云的時候，為了讓 instance 能夠訪問 metadata，就將  169.254.169.254  這個特殊的 IP 作為 metadata 服務器的地址，instance 啟動時就會向  169.254.169.254  請求 metadata。OpenStack 之后也沿用了這個設計。

我們現在遇到的問題是  169.254.169.254  沒法訪問啊！cirros 的 cloud-init 顯然是沒有拿到 metadata 的，這點至少可以從 instance 的 hostname 沒有被設置為  c1  判斷出來。

前面我們在 Metadata Service 架構部分介紹了，instance 首先會將 metadata 請求發送給 DHCP agent 或者 L3_agent 管理的 neutron-ns-metadata-proxy。那目前到底是誰在管理 neutron-ns-metadata-proxy 呢？我們先在控制節點上查看一下 neutron-ns-metadata-proxy 的進程。

盡然沒有 neutron-ns-metadata-proxy 在運行！

其原因是：默認配置下，neutron-ns-metadata-proxy 是由 L3_agent 管理的（后面會討論讓 DHCP 來管理），由于當前  test_net  并沒有掛在 neutron router 上，所以沒有啟動 neutron-ns-metadata-proxy。

添加 router 要解決這個問題很簡單：創建虛擬路由器  test_router  并連接  test_net。

現在控制節點上已經能夠看到  test_router  管理的 neutron-ns-metadata-proxy 了。

重啟 instance c1，看會發生怎樣的變化。

instance 成功訪問到  169.254.169.254。從結果看，cloud-init 已經獲取到 metadata，因為 hostname 已經設置為  c1。

看完上述內容，你們對 instance 如何從 nova-api-metadata 獲取信息有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注丸趣 TV 行業資訊頻道，感謝大家的支持。