針對來自 AKS 叢集的輸出連線進行基本疑難排解

發行項
12/18/2024

本文討論如何對來自 Microsoft Azure Kubernetes Service （AKS）叢集的輸出連線進行基本疑難解答，並識別錯誤的元件。

必要條件

Kubernetes kubectl 工具，或連線至叢集的類似工具。若要使用 Azure CLI 安裝 kubectl，請執行 az aks install-cli 命令。
用於處理封裝的 apt-get 命令行工具。
用戶端 URL （cURL）工具或類似的命令行工具。
nslookup用於檢查 DNS 解析的命令行（dnsutils）工具。

Azure Kubernetes Service 中輸出流量的案例

來自 AKS 叢集內的流量，無論是來自 Pod 或背景工作節點，都會被視為來自叢集的輸出流量。如果 AKS 叢集的輸出流程發生問題，該怎麼辦？在進行疑難解答之前，請先查看輸出流量的案例。

AKS 叢集的輸出流量可以分類為下列類別：

相同叢集中 Pod 或服務的流量（內部流量）。
相同虛擬網路或不同虛擬網路中裝置或端點的流量會使用虛擬網路對等互連。
透過 VPN 連線或 Azure ExpressRoute 連線，流向內部部署環境的流量。
透過 Azure Load Balancer（公用輸出流量）在 AKS 網路外部的流量。
透過 Azure 防火牆或 Proxy 伺服器（公用輸出流量）的 AKS 網路外部流量。

內部流量

AKS 叢集內部流量的基本要求流程類似於下圖所示的流程。

透過 Azure Load Balancer 的公用輸出流量

如果流量適用於因特網上的目的地，則預設方法是透過 Azure Load Balancer 傳送流量。

透過 Azure 防火牆或 Proxy 伺服器的公用輸出流量

在某些情況下，必須篩選輸出流量，而且可能需要 Azure 防火牆。

使用者可能會想要新增 Proxy 伺服器，而不是防火牆，或為輸出流量設定 NAT 閘道。基本流程會維持與圖表中顯示的相同。

請務必瞭解叢集的輸出流程本質，以便繼續進行疑難解答。

疑難解答時的考慮

檢查您的輸出裝置

當您針對 AKS 中的輸出流量進行疑難解答時，請務必知道輸出裝置是什麼（也就是流量通過的裝置）。在這裡，輸出裝置可以是下列其中一個元件：

Azure Load Balancer
Azure 防火牆或自定義防火牆
網路位址轉換（NAT）閘道
Proxy 伺服器

流程也可能根據目的地而有所不同。例如，內部流量（也就是叢集內）不會通過輸出裝置。內部流量只會使用叢集網路。針對公用輸出流量，判斷是否有輸出裝置通過並檢查該裝置。

檢查流量內的每個躍點

識別輸出裝置之後，請檢查下列因素：

要求的來源和目的地。
來源與目的地之間的躍點。
要求-回應流程。
由額外的安全性層級增強的躍點，例如下列層：
- 防火牆
- 網路安全性群組 (NSG)
- 網路原則

若要識別有問題的躍點，請在回應碼之前和之後檢查回應碼。若要檢查封包是否正確地抵達特定躍點，您可以繼續進行封包擷取。

檢查 HTTP 回應碼

當您檢查每個元件時，取得並分析 HTTP 回應碼。這些程式代碼有助於識別問題的本質。在應用程式回應 HTTP 要求的案例中，這些程式代碼特別有用。

從客戶端和伺服器擷取封包

如果其他疑難解答步驟未提供任何決定性的結果，請從客戶端和伺服器擷取封包。當客戶端與伺服器之間涉及非 HTTP 流量時，封包擷取也很有用。如需如何收集 AKS 環境封包擷取的詳細資訊，請參閱數據收集指南中的下列文章：

疑難解答檢查清單

如需 AKS 叢集輸出流量的基本疑難解答，請遵循下列步驟：

確定端點的網域名稱系統 (DNS) 解析正常運作。
確保您可以透過 IP 位址連線到端點。
請確定您可以從另一個來源連線到端點。
確保端點正常運作。
檢查叢集是否可以連線到任何其他外部端點。
檢查網路原則是否封鎖流量。
檢查 NSG 是否封鎖流量。
檢查防火牆或 Proxy 是否封鎖流量。
檢查 AKS 服務主體或受控識別是否具有對 Azure 資源進行網路變更所需的 AKS 服務權限。

注意

當您進行基本疑難解答時，假設沒有服務網格。如果您使用 Istio 之類的服務網格，則會產生 TCP 型流量的異常結果。

檢查 Pod 和節點是否可以連線到端點

從 Pod 內，您可以對端點執行 DNS 查詢。

如果您無法執行 kubectl exec 命令來連線到 Pod 並安裝 DNS Utils 套件，該怎麼辦？在此情況下，您可以在與有問題的 Pod 相同的命名空間中啟動測試 Pod，然後執行測試。

注意

如果 DNS 解析或輸出流量無法讓您安裝必要的網路套件，您可使用 rishasi/ubuntu-netutil:1.0 docker 映像。在此映像中，已安裝必要的套件。

檢查 Linux Pod DNS 解析的範例程式

在與有問題的 Pod 相同的命名空間中啟動測試 Pod：

kubectl run -it --rm aks-ssh --namespace <namespace> --image=debian:stable --overrides='{"spec": { "nodeSelector": {"kubernetes.io/os": "linux"}}}'

測試 Pod 執行之後，您將取得 Pod 的存取權。

執行下列 apt-get 命令來安裝其他工具套件：

# Update and install tool packages
apt-get update && apt-get install -y dnsutils curl

安裝套件之後，執行 nslookup 命令來測試端點的 DNS 解析：

$ nslookup microsoft.com # Microsoft.com is used as an example
Server:         <server>
Address:        <server IP address>#53
...
...
Name:   microsoft.com
Address: 20.53.203.50

直接嘗試上游 DNS 伺服器的 DNS 解析。此範例使用 Azure DNS：

$ nslookup microsoft.com 168.63.129.16
Server:         168.63.129.16
Address:        168.63.129.16#53
...
...
Address: 20.81.111.85

有時候，端點本身而不是叢集 DNS 發生問題。在這種情況下，請考慮下列檢查：

檢查遠端主機上是否開啟所需的埠：
```
curl -Ivm5 telnet://microsoft.com:443
```
檢查 HTTP 回應碼：
```
curl -Ivm5 https://microsoft.com
```
檢查您是否可以連線到任何其他端點：
```
curl -Ivm5 https://kubernetes.io
```

若要確認端點可從有問題的Pod所在的節點連線，然後驗證 DNS 設定，請遵循下列步驟：

輸入有問題的Pod透過偵錯Pod所在的節點。如需如何執行這項操作的詳細資訊，請參閱連線到 Azure Kubernetes Service （AKS）叢集節點以進行維護或疑難解答。

測試端點的 DNS 解析：

$ nslookup  microsoft.com
Server:         168.63.129.16
Address:        168.63.129.16#53

Non-authoritative answer:
Name:   microsoft.com
Address: 20.112.52.29
Name:   microsoft.com
Address: 20.81.111.85
Name:   microsoft.com
Address: 20.84.181.62
Name:   microsoft.com
Address: 20.103.85.33
Name:   microsoft.com
Address: 20.53.203.50

檢查 resolv.conf 檔案，以判斷是否新增預期的名稱伺服器：
```
cat /etc/resolv.conf
cat /run/systemd/resolve/resolv.conf
```

檢查 Windows Pod DNS 解析的範例程式

在 Windows 節點集區中執行測試 Pod：

# For a Windows environment, use the Resolve-DnsName cmdlet.
kubectl run dnsutil-win --image='mcr.microsoft.com/windows/servercore:ltsc2022' --overrides='{"spec": { "nodeSelector": {"kubernetes.io/os": "windows"}}}' -- powershell "Start-Sleep -s 3600"

執行 kubectl exec 命令，以使用 PowerShell 連線到 Pod：
```
kubectl exec -it dnsutil-win -- powershell
```

在 PowerShell 中執行 Resolve-DnsName Cmdlet，以檢查 DNS 解析是否適用於端點：

PS C:\> Resolve-DnsName www.microsoft.com 

Name                           Type   TTL   Section    NameHost
----                           ----   ---   -------    --------
www.microsoft.com              CNAME  20    Answer     www.microsoft.com-c-3.edgekey.net
www.microsoft.com-c-3.edgekey. CNAME  20    Answer     www.microsoft.com-c-3.edgekey.net.globalredir.akadns.net
net
www.microsoft.com-c-3.edgekey. CNAME  20    Answer     e13678.dscb.akamaiedge.net
net.globalredir.akadns.net

Name       : e13678.dscb.akamaiedge.net 
QueryType  : AAAA
TTL        : 20
Section    : Answer
IP6Address : 2600:1408:c400:484::356e   


Name       : e13678.dscb.akamaiedge.net 
QueryType  : AAAA
TTL        : 20
Section    : Answer
IP6Address : 2600:1408:c400:496::356e 


Name       : e13678.dscb.akamaiedge.net
QueryType  : A
TTL        : 12
Section    : Answer
IP4Address : 23.200.197.152

在涉及 DNS 解析的一個不尋常的案例中，DNS 查詢會從節點取得正確的回應，但從 Pod 失敗。在此案例中，您可能會考慮從 Pod 內部檢查 DNS 解析失敗，但不要從背景工作節點檢查。如果您想要檢查叢集上端點的 DNS 解析，可以考慮檢查整個叢集的 DNS 解析狀態。

如果 DNS 解析成功，請繼續進行網路測試。否則，請確認叢集的 DNS 組態。

協力廠商連絡資訊免責聲明

Microsoft 提供協力廠商連絡資訊，以協助您尋找有關此主題的其他資訊。此連絡資訊可能會變更而不另行通知。 Microsoft 不保證協力廠商連絡資訊的準確性。

與我們連絡，以取得說明

如果您有問題或需要相關協助，請建立支援要求，或詢問 Azure community 支援。您也可以向 Azure 意見反應社群提交產品意見反應。

共用方式為

針對來自 AKS 叢集的輸出連線進行基本疑難排解

必要條件

Azure Kubernetes Service 中輸出流量的案例

內部流量

透過 Azure Load Balancer 的公用輸出流量

透過 Azure 防火牆或 Proxy 伺服器的公用輸出流量

疑難解答時的考慮

檢查您的輸出裝置

檢查流量內的每個躍點

檢查 HTTP 回應碼

從客戶端和伺服器擷取封包

疑難解答檢查清單

檢查 Pod 和節點是否可以連線到端點

檢查 Linux Pod DNS 解析的範例程式

檢查 Windows Pod DNS 解析的範例程式

與我們連絡，以取得說明

意見反應

其他資源

共用方式為

針對來自 AKS 叢集的輸出連線進行基本疑難排解

必要條件

Azure Kubernetes Service 中輸出流量的案例

內部流量

透過 Azure Load Balancer 的公用輸出流量

透過 Azure 防火牆 或 Proxy 伺服器的公用輸出流量

疑難解答時的考慮

檢查您的輸出裝置

檢查流量內的每個躍點

檢查 HTTP 回應碼

從客戶端和伺服器擷取封包

疑難解答檢查清單

檢查 Pod 和節點是否可以連線到端點

檢查 Linux Pod DNS 解析的範例程式

檢查 Windows Pod DNS 解析的範例程式

與我們連絡，以取得說明

意見反應

其他資源

透過 Azure 防火牆或 Proxy 伺服器的公用輸出流量