OpenStack Metadata Service 提供 instance 的配置信息（這些信息被統稱為 metadata）。instance 啟動時向 Metadata Service 請求并獲得自己的 metadata，instance 的 cloud-init根據 metadata 完成個性化配置工作。
nova-api-metadata
nova-api-metadata是nova-api的子服務，它是metadata的實際提供者，虛擬機的啟動時，可以選擇通過nova-api-metadata的REST API來獲取metadata信息
nova-api-metadata服務運行在控制節點上，服務端口8775(可以通過nova的配置修改)
開啟metadata服務
nova-api-metadata與nova-api服務是合并在一起的，可以通過nova.conf的enabled_apis配置來指定是否啟用nova-api-metadata
neutron-metadata-agent
nova-api-metadata走管理網絡，虛擬機走業務網絡，所以虛擬機無法直接和nova-api-metadata進行通信，在這個時候就需要借助到運行在網絡節點上的neutron-metadata-agent服務。
在網絡節點上運行兩個組件 l3 agent和dhcp agent，他們會創建一個haproxy進程，運行在各自的namespace中，用來接收虛擬機發送的metadata請求，并將該請求通過Unix Domain Socket的方式轉發給neutron-metadata-agent服務，再由neutron-metadata-agent轉發給nova-api-metadata。
整個流程可以總結為：
a、instance將metadata請求發送給router或者dhcp agent創建的haproxy進程
b、haproxy進程通過Unix Domian Socket將請求發送給neutron-metadata-agent
c、neutron-metadata通過內部管理網絡將請求發送給nova-api-metadata服務
上述描述中提到，L3 agent和dhcp agent均可以創建haproxy進程，進而實現metadata請求的轉發，那么兩種方案該如何選擇呢？
事實上，兩者各有各的應用場景，甚至兩種方案可以并存，下文將詳細分析兩者的區別。
說在前面，l3-agent 和 dhcp-agent 訪問 metadata 的實現方法是不同的。
對于 169.254.169.254：
a、l3-agent 用 iptables 規則來轉發。
b、dhcp-agent 則是將此 IP 配置到自己的 interface 上。
創建一個網絡test1，啟用dhcp，暫時不連接到router，然后啟動一個instance，然后觀察instance的啟動日志：
從上面的啟動log中，我們可以發現，intance從dhcp獲取到ip地址之后，向169.254.169.254發送了request請求，但是20次均失敗
那么169.254.169.254到底是什么？
事實上，這個ip地址就是metadata service的ip地址，instance在啟動的時候會向它發送metadata的請求。
現在我們發現，instance請求是失敗的，這個是為什么呢？
上文提到，OpenStack通過L3 agent或者dhcp agent創建haproxy進程，進而實現metadata的轉發，我們首先檢查下網絡節點上的haproxy進程。
發現并沒有haproxy進程運行，這個也就解釋了，為什么instance會請求失敗。但是到底是哪里出了問題？
根本原因是：默認情況下，haproxy進程由L3 agent來創建（dhcp agent則是關閉狀態），由于當前test1網絡并沒有掛載router上，所以沒有創建haproxy進程。
創建router，并將test1掛載router上之后。我們發現haproxy進程已經在網絡節點啟動。
重啟instance test1，看會發生什么變化。
根據instance日志顯示，虛擬機已經成功從169.254.169.254獲取到了metadata。
這個過程中到底發生了什么？
a、instance在啟動之后，會向168.254.169.254的80端口發起metadata請求，根據
instance的路由可以發現，該請求會從instance的eth0發出，送往路由器上的qr-設備。
b、metadata請求到達路由，進入PREROUTING鏈，將目的地址為169.254.169.254，進入qr-口，目的port是80的請求，重定向到9697。
c、為什么是9697？
因為router創建的haproxy進程正是監聽在9697端口上
d、在后面就簡單了：haproxy進程將請求通過Unix Domain Socket轉發給neutron-metadata-agent，后者再通過管理網關轉發給nova-api-metadata。
OpenStack默認通過L3 agent管理metadata的實現，進而和nova-api-metadata通信，但是并不是所有的環境都有L3 agent，比如直接使用物理router的場景，這樣場景如何實現metadata呢？
答案就是DHCP agent
a、打開dhcp agent的metadata功能
vim /etc/neutron/dhcp_agent.ini
重啟dchp agent服務
b、檢查網絡節點上的haproxy進程情況，會發現開啟dhcp功能的網絡，會創建一個對應的haproxy進程，并將169.254.169.254配置在對應的dhcp port上。
c、重啟instance，instance會向169.254.169.254的80端口發送metadata請求，根據instance內部路由，請求會到達dhcp_port端口上。
c、metadata請求到達dhcp的namespace，會被haproxy進程監聽到（haproxy進程在dhcp namespace中監聽80端口）
d、后面流程和L3 agent完全相同：haproxy進程將請求通過Unix Domain Socket轉發給neutron-metadata-agent，后者再通過管理網關轉發給nova-api-metadata。
要從 nova-api-metadata 獲得 metadata，需要指定 instance 的 id
而instance在啟動的時候，是無法知道自己的id的，所以http請求中不會包含id，
instance id是neutron-metadata-agent添加進去的。對于L3 agent和DHCP agent
兩種方案上實現又略有不同，下文會針對兩者進行說明。
獲取metadata流程如下：
instance -> haproxy-> neutron-metadata-agent -> nova-api-metadata
L3 agent
a、haproxy進程接受到metadata請求，在轉發給neutron-metadata-agent之前，會將ip和router id添加到http的head中。
b、neutron-metadata-agent接受到請求后，會查詢instance的id，然后將instance id添加到http的head中，然后轉發給nova-api-metadata。
c、nova-api-metadata響應請求到指定的instance。
DHCP agent
a、haproxy進程接受到metadata請求，在轉發給neutron-metadata-agent之前，會將ip和network id添加到http的head中。
b、neutron-metadata-agent接受到請求后，會查詢instance的id，然后將instance id添加到http的head中，然后轉發給nova-api-metadata。
c、nova-api-metadata響應請求到指定的instance。
這樣，不管 instance 將請求發給 l3-agent 還是 dhcp-agent，nova-api-metadata 最終都能獲知 instance 的 id，進而返回正確的 metadata。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
