昨天講的是 VPN 那條線。今天講雲端內部的另一條線。我們的資料庫是私有的，沒有對外的網址，只有一個內部 IP。而要用它的服務跑在 Kubernetes 叢集裡，那個叢集在另一個虛擬網路。兩個網路要先接起來，服務才連得到資料庫。

Azure 接兩個虛擬網路的做法叫做對等互連（peering），在入口網站上點兩下就好。

我以為做完了

對等互連建好之後，我從叢集裡對著資料庫的私有 IP 測，通了。

這個結果看起來很紮實：兩個虛擬網路之間的路確實打通了，封包送得過去、也回得來。我把它當成做完了，去做下一件事。

三天後，在寫連線設定的時候

三天後我開始準備服務的切換設定，要把每個服務連資料庫的那一行換成新的那台。打開設定檔，我看到那一行寫的不是 IP，是一長串網址。

然後才想到一個三天前完全沒想過的問題：這個名字，叢集裡查得到嗎？

兩件被我當成一件的事

問題在於我把「網路通了」和「連得上資料庫」畫上等號，但中間還隔著一步：把名字換成 IP。這件事叫做 DNS 解析。

平常我們不太會意識到它，因為公開網站的名字全世界都查得到。但這台資料庫是私有的，它只有一個內部位址，而內部位址不能放進公開的 DNS。像 10.10.x.x 這種位址在幾百萬個網路裡同時存在，公開地告訴全世界「這個名字對應到 10.10.1.4」不但沒意義，還會指錯人。

所以它的名字和 IP 的對應關係被放在另一個地方，叫「私有 DNS 區域」。而這個區域必須明確地跟某個虛擬網路綁定，那個網路裡的機器才查得到。

建立資料庫的時候，Azure 會自動把這個區域綁到資料庫所在的那個網路。但叢集在另一個網路，而對等互連只打通了「封包送得到」這件事，不會順便把 DNS 也接過去。

所以當時的狀態是：用 IP 連得通，用網址查不到。而服務用的，是網址。

為什麼這一步特別容易漏

我後來在 runbook 上寫了一句：對等互連和 DNS 連結，這兩件事常常被誤以為是同一件事。

會誤會是有原因的。它們在入口網站上長得很像，都是「把 A 接到 B」的設定，位置也相鄰。做完對等互連，畫面會顯示狀態為已連線，看起來就是一副接好了的樣子。

但真正騙到我的是驗證方式。對等互連建完，最自然的驗證動作就是拿 IP 去測，而 IP 本來就會通，因為對等互連負責的就只有這件事。它做完了它該做的，是我對它的範圍有誤解。

前天講的那個坑也是驗證出的問題，但錯的地方不一樣。那次我測的方法是對的，只是測錯了對象（挑到全機房唯一不需要那條路由的機器）。這次我測對了對象，就在叢集裡測，但測的方法和服務實際用的方法不同。

一個是測錯人，一個是問錯問題。

確認的方法

補上那個連結之後，我沒有直接相信入口網站顯示的狀態，而是在叢集裡開一個臨時的容器，直接查那個網址：

kubectl run dns-test --image=busybox:1.36 --rm -i --restart=Never -n backend \
  --command -- nslookup mysql-test.mysql.database.azure.com

回傳的是 10.10.1.4，資料庫的私有位址。到這裡才算真的通了。

這行指令有三個地方值得說。--rm 讓容器跑完就自動刪掉，不會在叢集裡留垃圾。-n 指定命名空間，是為了在服務真正會跑的那個位置測，而不是在別的地方測完就當作沒事。至於 nslookup，它查的是名字不是 IP，這正是重點：我要驗的就是服務會做的那個動作。

後來建生產環境的時候，我把這行原封不動抄過去，只換掉網址和命名空間。它已經變成建完網路之後的例行動作。

帶得走的東西

「能不能連到」其實是好幾層疊起來的，任何一層斷了，症狀看起來都一樣。

從下往上大概是：封包送得到嗎（網路層）、名字查得到嗎（DNS）、對方願意接嗎（防火牆、權限）、帳號密碼對嗎。

排查的時候如果沒有意識到這是分層的，就會在同一層裡反覆繞。而我這次是連排查都還沒排到：「IP 通了」給了我太強的信心，讓我根本沒想到上面還有一層。

這次算運氣好，是在寫設定的時候自己撞見的，不是等服務上線之後才被使用者撞見。

用 IP 測通了，只證明最底下那層是好的。 服務用的是名字，就要用名字測。

明天要講的是為什麼測試環境和生產環境長得不一樣。同一套架構，我們在兩個環境做了兩種設計，而今天講的這個坑，在生產環境裡根本不會發生。