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

創新互聯專業為企業提供水富網站建設、水富做網站、水富網站設計、水富網站制作等企業網站建設、網頁設計與制作、水富企業網站模板建站服務，10年水富做網站經驗，不只是建網站，更提供有價值的思路和整體網絡服務。

我們將通過實驗詳細分析 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 獲取信息有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注創新互聯行業資訊頻道，感謝大家的支持。