共計 1345 個字符，預計需要花費 4 分鐘才能閱讀完成。
這篇文章將為大家詳細講解有關如何通過 dhcp-agent 訪問 Metadata，文章內容質量較高，因此丸趣 TV 小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。
OpenStack 默認通過 l3-agent 創建和管理 neutron-ns-metadata-proxy，進而與 nova-metadata-api 通信。但不是所有環境都有 l3-agent，比如直接用物理 router 的場景。這時就需要走另一條路：讓 dhcp-agent 來創建和管理 neutron-ns-metadata-proxy。
打開 /etc/neutron/dhcp_agent.ini，設置 force_metadata
重啟 dhcp-agent 后，可以看到控制節點上多了一個 neutron-ns-metadata-proxy 進程。
此進程通過 –network_id 關聯到 test_net，這就是 dhcp-agent 啟動的 neutron-ns-metadata-proxy，用于接收 test_net 網絡上 instance 的 metadata 請求。每一個 network 都有一個與之對應的 neutron-ns-metadata-proxy。
重啟 instance c1，查看路由表。
請注意，現在訪問 169.254.169.254 的路由已由之前的 17.17.17.1 變為 17.17.17.2。這里的 17.17.17.2 是 dhcp-agent 在 test_net 上的 IP。這條路由是由 dhcp-agent 添加進去的。正是因為這條路由的存在，即便 l3-agent 與 dhcp-agent 同時提供 neutron-ns-metadata-proxy 服務，metadata 請求也只會發送給 dhcp-agent。
同時我們也看到，dhcp-agent 已經將 IP 169.254.169.254 配置到了自己身上。也就是說：c1 訪問 metadata 的請求 http://169.254.169.254 實際上是發送到了 dhcp-agent 的 80 端口。而監聽 80 端口的正是 dhcp-agent 啟動的 neutron-ns-metadata-proxy 進程。
后面的數據流向就與 l3-agent 的場景一樣了：neutron-ns-metadata-proxy 將請求通過 unix domain socket 發給 neutron-metadata-agent，后者再通過管理網絡發給 nova-api-metadata。
到這里，我們已經分別討論了通過 l3-agent 和 dhcp-agent 訪問 metadata 的實現方法。對于 169.254.169.254：
l3-agent 用 iptables 規則來轉發。
dhcp-agent 則是將此 IP 配置到自己的 interface 上。
不知道大家有沒有這樣一個疑問：
nova-api-metadata 是怎么知道應該返回哪個 instance 的 metadata？c1 只是向 169.254.169.254 發送了一個 http 請求。
關于如何通過 dhcp-agent 訪問 Metadata 就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。
