獲取 metadata 的完整例子 - 天天5分鐘玩轉 OpenStack（166）

咱們將經過實驗詳細分析 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。

下一節咱們詳細分析 c1 是如何拿到 metadata 的。