除錯 Ingress
虛擬私有雲 傳統基礎設施
您已在叢集中為您的應用程式建立了一個 Ingress 資源，藉此將該應用程式對外公開。 不過，當您嘗試透過 Ingress 子網域或 ALB 的 IP 位址連接至應用程式時，連線會失敗或逾時。
下列各節中的步驟可協助您除錯 Ingress 設定。
開始之前，請確定您具有 IBM Cloud Kubernetes Service的下列 IBM Cloud IAM 存取原則: - 該叢集的「編輯者」或「管理員」平台存取角色 -「 撰寫者」或「管理員」服務存取角色
步驟 1: 檢查應用程式部署
在對 Ingress 進行除錯之前，請先移出 對應用程式部署進行除錯。
Ingress 問題通常是由應用程式部署或公開應用程式的 ClusterIP 服務中的基礎問題所導致。 例如，您的應用程式標籤與服務選取器可能不相符，或者您的應用程式與服務目標埠可能不相符。
步驟 2：檢查 Ingress 部署及 ALB Pod 日誌中的錯誤訊息
從檢查 Ingress 資源部署事件及 ALB Pod 日誌中的錯誤訊息開始。 這些錯誤訊息可協助您找出失敗的根本原因，並在以下各節中進一步除錯您的 Ingress 設定。
-
請檢查您的 Ingress 資源部署狀況，並查看是否有任何警告或錯誤訊息。
kubectl describe ingress <myingress>在輸出的 Events 區段中，您可能會看到關於您使用之 Ingress 資源或某些註釋中含有無效值的警告訊息。 關於基於 Ingress- NGINX 的 ALB，請參閱 Ingress 資源配置文件 或 註解文件。 對於基於 Traefik 的 ALB，請參閱 Ingress 資源設定文件 或 Ingress Controller 設定文件。
NAME: myingress Namespace: default Address: 169.xx.xxx.xxx,169.xx.xxx.xxx Default backend: <default> Rules: Host Path Backends ---- ---- -------- mycluster-<hash>-0000.us-south.containers.appdomain.cloud /tea myservice1:80 (<none>) /coffee myservice2:80 (<none>) Annotations: <none> Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Sync 26s (x8 over 19m) nginx-ingress-controller Scheduled for sync Normal Sync 26s (x8 over 19m) nginx-ingress-controller Scheduled for sync -
檢查 ALB Pod 的狀態。
- 取得在叢集裡執行的 ALB Pod。
kubectl get pods -n kube-system | grep alb ``` 2. 檢查 **STATUS** 直欄，確定所有 Pod 都正在執行。 3. 如果某個 pod 的狀態並非「`Running`」，您可以停用並重新啟用 ALB。 在以下指令中，請將 `<ALB_ID>` 替換為該 Pod 的 ALB 識別碼。 例如，如果未執行的 Pod 具有名稱 `public-crb2f60e9735254ac8b20b9c1e38b649a5-alb1-5d6d86fbbc-kxj6z`，則 ALB ID 為 `public-crb2f60e9735254ac8b20b9c1e38b649a5-alb1`。 * 標準叢集： ```sh {: pre} ibmcloud ks ingress alb disable --alb <ALB_ID> -c <cluster_name_or_ID> ``` ```sh {: pre} ibmcloud ks ingress alb enable classic --alb <ALB_ID> -c <cluster_name_or_ID> ``` * VPC 叢集： ```sh {: pre} ibmcloud ks ingress alb disable --alb <ALB_ID> -c <cluster_name_or_ID> ``` ```sh {: pre} ibmcloud ks ingress alb enable vpc-gen2 --alb <ALB_ID> -c <cluster_name_or_ID> ``` -
檢查 ALB 的日誌。
- 取得在叢集裡執行的 ALB Pod ID。
kubectl get pods -n kube-system | grep alb ``` 1. 對於基於 Ingress- NGINX 的 ALB，請取得每個 ALB Pod 中 `nginx-ingress` 容器的日誌。 對於基於 Traefik 的 ALB，請取得每個 ALB Pod 中 `traefik` 容器的日誌。 ```sh {: pre} kubectl logs <ingress_pod_ID> <nginx-ingress/traefik> -n kube-system ``` 1. 尋找 ALB 日誌中的錯誤訊息。
步驟 3：連線測試 ALB 子網域及公用 IP 位址
請檢查 Ingress 子網域及 ALB 之公用 IP 位址的可用性。 此外，請確保 IBM NS1 能存取您的 ALB，以便對其進行健康檢查。
-
取得公用 ALB 所接聽的 IP 位址 (標準) 或主機名稱 (VPC)。
ibmcloud ks ingress alb ls --cluster <cluster_name_or_ID>以下為經典多區域叢集的輸出範例，其工作節點位於
dal10和dal13：ALB ID Enabled Status Type ALB IP Zone Build ALB VLAN ID NLB Version private-cr24a9f2caf6554648836337d240064935-alb1 false disabled private - dal13 ingress:1.1.2_2507_iks 2294021 - private-cr24a9f2caf6554648836337d240064935-alb2 false disabled private - dal10 ingress:1.1.2_2507_iks 2234947 - public-cr24a9f2caf6554648836337d240064935-alb1 true enabled public 169.62.196.238 dal13 ingress:1.1.2_2507_iks 2294019 - public-cr24a9f2caf6554648836337d240064935-alb2 true enabled public 169.46.52.222 dal10 ingress:1.1.2_2507_iks 2234945 -- 如果公用 ALB 沒有 IP 位址 (標準) 或主機名稱 (VPC)，請參閱 Ingress ALB 不會部署在區域中。
-
驗證 ALB 性能檢查可以呼叫到您的 ALB IP 位址。
-
經典：如果您使用 Calico pre-DNAT 網路政策或其他自訂防火牆來封鎖群集的入站流量，您必須允許從 Kubernetes 控制平面的連接埠 80 或 443 的入站存取，並 IBM NS1 ' IPv4 IP 位址到您的 ALB 的 IP 位址，以便 Kubernetes 控制平面可以檢查 ALB 的健康狀況。 例如，如果您使用 Calico 策略，請 建立 Calico pre-DNAT 策略，以允許從 IBM NS1 's 來源 IP 位址在 80 連接埠和 群集所在區域的控制平面子網，對您的 ALB IP 位址進行入線存取。
-
VPC：如果您在用於叢集入口的 VPC LBaaS ( LoadBalancer-as-a-Service ) 實例上有一個自訂安全群組，請確保安全群組規則允許從Kubernetes控制平面 IP 位址到連接埠的必要運作狀況檢查流量443.
-
-
檢查 ALB IP (標準) 或主機名稱 (VPC) 的性能。
- Ping 每個公共 ALB 的 IP 位址（經典）或主機名稱（VPC），以確保每個 ALB 能夠成功接收資料包。 如果您使用的是私有 ALB，則只能從私有網路對其 IP 位址（經典型）或主機名稱（VPC 型）執行 ping 操作。
ping <ALB_IP> ``` * 如果 CLI 傳回超時錯誤，且您有自訂防火牆在保護工作節點，請務必在防火牆中允許 ICMP 通訊。 * 如果您沒有防火牆或防火牆未封鎖連線測試，且連線測試仍會逾時，請 [檢查 ALB Pod 的狀態](#check_pods)。 * 僅限多區域叢集：您可以使用 MZLB 狀態檢查來確認 ALB IP 位址（經典版）或主機名稱（VPC）的狀態。 下列 HTTP cURL 指令使用 `albhealth` 主機，其由 IBM Cloud Kubernetes Service 配置成傳回 ALB IP 的 `healthy` 或 `unhealthy` 狀態。 ```sh {: pre} curl -X GET http://<ALB_IP>/ -H "Host: albhealth.<ingress_subdomain>" ``` 範例指令： ```sh {: pre} curl -X GET http://169.62.196.238/ -H "Host: albhealth.mycluster-<hash>-0000.us-south.containers.appdomain.cloud" ``` 輸出範例 ```sh {: screen} healthy ``` 如果有一個以上的 IP 傳回 `unhealthy`，則請[檢查 ALB Pod 的狀態](#check_pods)。 -
取得 IBM 提供的 Ingress 子網域。
ibmcloud ks cluster get --cluster <cluster_name_or_ID> | grep Ingress輸出範例
Ingress Subdomain: mycluster-<hash>-0000.us-south.containers.appdomain.cloud Ingress Secret: mycluster-<hash>-0000 -
請確保在本節第 1 步驟中取得的每個公開 ALB 的 IP 位址（經典模式）或主機名稱（VPC 模式），已註冊至您叢集的 IBM 所提供的 Ingress 子網域中。 例如，在典型的多區域叢集環境中，每個包含工作節點的區域中的公共 ALB IP 位址，都必須註冊在同一個子網域之下。
kubectl get ingress -o wide輸出範例
NAME HOSTS ADDRESS PORTS AGE myingressresource mycluster-<hash>-0000.us-south.containers.appdomain.cloud 169.46.52.222,169.62.196.238 80 1h
步驟 4：檢查網域對映及 Ingress 資源配置
- 如果您使用自訂網域，請驗證您已使用 DNS 提供者將自訂網域對映至 IBM 提供的子網域或 ALB 的公用 IP 位址。 請注意，最好使用 CNAME，因為 IBM 會在 IBM 子網域上提供自動性能檢查，並從 DNS 回應移除任何失敗的 IP。
- IBM- 提供的子網域 CNAME: 請確認您的自訂網域已在規範名稱記錄（CNAME）中，映射至叢集的 IBM 所提供的子網域。
host www.my-domain.com ``` 輸出範例 ```sh {: screen} www.my-domain.com is an alias for mycluster-<hash>-0000.us-south.containers.appdomain.cloud mycluster-<hash>-0000.us-south.containers.appdomain.cloud has address 169.46.52.222 mycluster-<hash>-0000.us-south.containers.appdomain.cloud has address 169.62.196.238 ``` * **公共 IP 位址的 A 記錄**：請確認您的自訂網域已透過 A 記錄映射至 ALB 的可攜式公共 IP 位址。 IP 應該符合您在[前一節](#ping)步驟 1 中所取得的公用 ALB IP。 ```sh {: pre} host www.my-domain.com ``` 輸出範例 ```sh {: screen} www.my-domain.com has address 169.46.52.222 www.my-domain.com has address 169.62.196.238 ``` - 檢查叢集的 Ingress 資源配置檔。
kubectl get ingress -o yaml-
確定您只在一個 Ingress 資源中定義主機。 如果在多個 Ingress 資源中定義一個主機，則 ALB 可能不會適當地轉遞資料流量，而且您可能會遭遇錯誤。
-
確認子網域及 TLS 憑證正確無誤。 若要查找由 IBM 提供的 Ingress 子網域及 TLS 憑證，請執行
ibmcloud ks cluster get --cluster <cluster_name_or_ID>。 -
確定應用程式接聽與 Ingress 之 path 區段中配置相同的路徑。 如果您的應用程式設定成接聽根路徑，請使用
/作為路徑。 如果發往此路徑的傳入流量必須路由至您應用程式所監聽的另一條路徑，請在**Ingress-NGINX**上使用[重新撰寫路徑](/docs/containers?topic=containers-comm-ingress-annotations#alb-rewrite-paths)註解。 若要存取 Traefik，請使用ReplacePath中介軟體。 -
視需要編輯資源配置 YAML。 當您關閉編輯器時，即會儲存並自動套用您的變更。
kubectl edit ingress <myingressresource> ``` -
在 Classic 環境中為進行除錯而從 DNS 中移除 ALB
如果您無法透過特定的 ALB IP 來存取應用程式，則可以停用其 DNS 登錄，以從正式作業暫時移除 ALB。 然後，您可以使用 ALB 的 IP 位址，對該 ALB 執行除錯測試。
例如，假設您在 2 個區域中有某個多區域叢集，而且 2 個公用 ALB 都有 IP 位址 169.46.52.222 及 169.62.196.238。 雖然性能檢查針對第二個區域的 ALB 傳回性能良好，但是無法直接透過它連接您的應用程式。 您決定從正式作業移除該 ALB 的 IP 位址 169.62.196.238 以進行除錯。 第一個區域的 ALB IP 169.46.52.222 會向您的網域登錄，並在除錯第二個區域的 ALB 時繼續遞送資料流量。
-
請使用以下指令將 IP 位址從網域名稱中移除。 「update」指令會完全取代已登錄的 IP 位址，因此您只需在指令中定義正常運作的 IP 位址即可：
ibmcloud ks ingress domain update --cluster <cluster_name> --domain <cluster domain> --ip 169.46.52.222 -
請透過檢查 IBM NS1 伺服器，確認 ALB IP 位址已從您的網域 DNS 記錄中移除。 請注意，DNS 登錄可能需要幾分鐘的時間才能更新。
host mycluster-<hash>-0000.us-south.containers.appdomain.cloud dns1.p02.nsone.net確認只有性能良好的 ALB IP
169.46.52.222保留在 DNS 登錄中，並已移除性能不佳的 ALB IP169.62.196.238的範例輸出：mycluster-<hash>-0000.us-south.containers.appdomain.cloud has address 169.46.52.222 -
現在，已從正式作業移除 ALB IP，您可以透過它對應用程式執行除錯測試。 若要透過此 IP 來測試與應用程式的通訊，您可以執行下列 cURL 指令，並將範例值取代為您自己的值：
curl -X GET --resolve mycluster-<hash>-0000.us-south.containers.appdomain.cloud:443:169.62.196.238 https://mycluster-<hash>-0000.us-south.containers.appdomain.cloud/- 如果已正確配置所有項目，則會從應用程式取得預期回應。
- 如果您在回應中收到錯誤，則您的應用程式或只套用至此特定 ALB 的配置中可能發生錯誤。 請檢查您的應用程式程式碼、Ingress 資源設定檔 （ Ingress- NGINX ），或 Traefik 的 Ingress Controller 設定文件，以及您僅針對此 ALB 所套用的任何其他設定。
-
完成除錯後，請使用以下指令恢復 ALB 的 DNS 註冊：
ibmcloud ks ingress domain update --cluster <cluster_name> --domain <cluster domain> --ip 169.46.52.222 --ip 169.62.196.238 -
請透過檢查 IBM NS1 伺服器，確認 ALB IP 位址已恢復至您的網域 DNS 記錄中。 請注意，DNS 登錄可能需要幾分鐘的時間才能更新。
host mycluster-<hash>-0000.us-south.containers.appdomain.cloud dns1.p02.nsone.net輸出範例
mycluster-<hash>-0000.us-south.containers.appdomain.cloud has address 169.46.52.222 mycluster-<hash>-0000.us-south.containers.appdomain.cloud has address 169.62.196.238