instance 怎麼得到本身的 Metadata - 天天5分鐘玩轉 OpenStack（169）

要想從 nova-api-metadata 得到 metadata，須要指定 instance 的 id。但 instance 剛啓動時沒法知道本身的 id，因此 http 請求中不會有 instance id 信息，id 是由 neutron-metadata-agent 添加進去的。針對 l3-agent 和 dhcp-agent 這兩種狀況在實現細節上有所不一樣，下面分別討論。
 

l3-agent

 

下面是 l3-agent 參與狀況下 metadata http 請求的處理流程圖。

大的流程爲：instance -> neutron-ns-metadata-proxy -> neutron-metadata-agent -> nova-api-metadata，處理細節說明以下：

① neutron-ns-metadata-proxy 接收到請求，在轉發給 neutron-metadata-agent 以前會將 instance ip 和 router id 添加到 http 請求的 head 中，這兩個信息對於 l3-agent 來講很容易得到。

② neutron-metadata-agent 接收到請求後，會查詢 instance 的 id，具體作法是：

1) 經過 router id 找到 router 鏈接的全部 subnet，而後篩選出 instance ip 所在的 subnet。

2）在 subnet 中找到 instance ip 對應的 port。

3）經過 port 找到對應的 instance 及其 id。

③ neutron-metadata-agent 將 instance id 添加到 http 請求的 head 中，而後轉發給 nova-api-metadata，這樣 nova-api-metadata 就能返回指定 instance 的 metadata 了。

咱們再來看 dhcp-agent 的狀況。

 

dhcp-agent

 

① neutron-ns-metadata-proxy 在轉發請求以前會將 instance ip 和 network id 添加到 http 請求的 head 中，這兩個信息對於 dhcp-agent 來講很容易得到。

② neutron-metadata-agent 接收到請求後，會查詢 instance 的 id，具體作法是：

1) 經過 network id 找到 network 全部的 subnet，而後篩選出 instance ip 所在的 subnet。

2）在 subnet 中找到 instance ip 對應的 port。

3）經過 port 找到對應的 instance 及其 id。

③ neutron-metadata-agent 將 instance id 添加到 http 請求的 head 中，而後轉發給 nova-api-metadata，這樣 nova-api-metadata 就能返回指定 instance 的 metadata 了。

這樣，無論 instance 將請求發給 l3-agent 仍是 dhcp-agent，nova-api-metadata 最終都能獲知 instance 的 id，進而返回正確的 metadata。

從獲取 metadata 的流程上看，有一步是相當重要的：instance 必須首先可以正確獲取 DHCP IP，不然請求發送不到 169.254.169.254。但不是全部環境都會啓用 dhcp，更極端的，有些環境可能連 nova-api-metadata 服務都不會啓用。那麼 instance 還能得到 metadata 嗎？

這就是下一節咱們要討論的主題：config drive。