instance 的網卡是如何被配置并拉起的？這是了解和用好 cloud-init 非常關鍵的一步。我們先讨論一個最簡單基礎的場景：鏡像中沒有安裝 cloud-init。
此時 instance 啟動時網卡能不能被拉起來完全 靠運氣！是的，就是運氣。
因為這種情況下網卡的配置是死的，完全依賴于鏡像中 /etc/network/interfaces 原有的配置。比如原鏡像中的配置是：
auto eth0
iface eth0 inet dhcp
instance 隻有滿足下面所有條件網卡才能被拉起來：
正好隻有一塊網卡
正好網卡就叫 eth0
正好 subnet 開了 DHCP
隻要出現下面任意一種情況就會失敗：
還有其他網卡，比如 eth1，或者
網卡不叫 eth0 ，比如 ens3，或者
沒有 DHCP
不同 instance 的網絡配置差别很大，在 image 中寫死的方法幾乎是無效的，隻能依靠 cloud-init 動态寫入，接下來我們詳細分析 cloud-init 的解決方案。
先考慮 subnet 有 DHCP 服務的情況。
部署成功後，登入 instance，<code>ip a</code> 顯示網卡 <code>ens3</code> 已經正确配置。
下面分析這個 IP 是怎樣配置上去的。
上一節我們讨論到，cloud-init 是在 local 階段完成網絡配置的，cloud-init 的執行過程被詳細記錄在 /var/log/cloud-init.log 中，讓我們找找相關操作。
這裡可以看到，cloud-init 會做如下工作：
① 掃描出 instance 中的所有網卡（這裡是 ens3）
② 擷取該網卡的配置資訊。 因為沒有 config drive，無法得知網卡的詳細配置資訊，隻能采用預設的 fallback 配置，即 dhcp 配置。
③ 将配置資訊寫入 /etc/network/interfaces.d/50-cloud-init.cfg，内容為：
這樣網卡就以 dhcp 模式拉起來，正好與 subnet 的 dhcp 服務對接上，IP、網關等資訊就配上去了。
幾點說明：
instance 上的每一塊網卡都會被 cloud-init 掃描出來。
如果沒有 config drive 将采用 fallback 配置，将掃描出來的第一塊 （隻有這一塊）網卡配置成 dhcp 模式。請注意：這是 cloud-init 預設行為，跟這塊網卡對應的 subnet 是否開啟了 DHCP 沒有任何關系。
cloud-init 會根據 instance 作業系統類型生成網卡配置檔案。例如作業系統是 centos 的話則會将配置寫到 /etc/sysconfig/network-scripts 目錄下。
現在請大家思考一個問題：如果 subnet 沒有開 DHCP，會是怎樣一個情況？下節将分析這個問題。