如何對 Amazon EKS 中 Network Load Balancer 的運作狀態不良的目標進行疑難排解？

簡短描述

以下是 Network Load Balancer 的目標運作狀態不良的的常見原因：

• 運作狀態檢查設定不正確。
• Pod 中存在非預期的例外狀況。
• 將 externalTrafficPolicy 設定為本機的 Network Load Balancer，並在 DHCP 選項集上設定自訂 Amazon VPC DNS。

解決方法

確認目標群組為 IP 位址或執行個體

執行下列命令：

kubectl get service service_name -o yaml

**注意：**將 service_name 取代為您的服務名稱。

如果 service.beta.kubernetes.io/aws-load-balancer-nlb-target-type 註釋不存在，則預設目標類型為執行個體。

確認已正確設定運作狀態檢查

檢查已針對您的服務設定哪些 Elastic Load Balancing (ELB) 註釋。如需有關註釋的詳細資訊，請參閱 Kubernetes 網站上的服務。

執行下列命令以取得註釋清單：

kubectl get service service_name -o yaml

範例輸出：

service.beta.kubernetes.io/aws-load-balancer-healthcheck-healthy-threshold: "2"# The number of successive successful health checks required for a backend to be considered healthy for traffic. Defaults to 2, must be between 2 and 10

service.beta.kubernetes.io/aws-load-balancer-healthcheck-unhealthy-threshold: "3"
# The number of unsuccessful health checks required for a backend to be considered unhealthy for traffic. Defaults to 6, must be between 2 and 10

service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval: "20"
# The approximate interval, in seconds, between health checks of an individual instance. Defaults to 10, must be between 5 and 300

service.beta.kubernetes.io/aws-load-balancer-healthcheck-timeout: "5"
# The amount of time, in seconds, during which no response means a failed health check. This value must be less than the service.beta.kubernetes.io/aws-load-balancer-healthcheck-interval value. Defaults to 5, must be between 2 and 60

service.beta.kubernetes.io/aws-load-balancer-healthcheck-protocol: TCP
service.beta.kubernetes.io/aws-load-balancer-healthcheck-port: traffic-port
# can be integer or traffic-port

service.beta.kubernetes.io/aws-load-balancer-healthcheck-path: "/"
# health check path for HTTP(S) protocols

如果註釋未正確設定，則表示目標運作狀態可能不良。

從 Amazon VPC 中執行的主機手動啟動運作狀態檢查

對於執行個體目標類型，請使用 NodePort 執行下列 curl 命令：

curl-ivk node_IP:NodePort

**注意：**將 node_IP 取代為您節點的 IP 位址。

對於 IP 位址目標類型，請執行下列 curl 命令：

curl -ivk pod_IP:pod_port

**注意：**將 pod_IP 取代為您 Pod 的 IP 位址。將 pod_port 取代為應用程式在容器內接聽的連接埠名稱。

檢查 Pod 中是否存在非預期的例外狀況

執行個體目標類型

1. 檢查目前運作狀態檢查組態註釋的服務規格。如需完整清單，請參閱 GitHub 網站上的運作狀態檢查組態註釋：

   kubectl get service service_name -o yaml

2. 檢查是否存在端點，來驗證服務後面是否有 Pod：

   kubectl get endpoints service_name -o yaml

3. 如果服務不存在端點，請檢查 Pod 標籤和服務標籤是否相符：

   kubectl describe servicekubectl describe pod pod_name or kubectl get pod --show-labels

   注意： 將 pod_name 取代為您的 Pod 名稱。

4. 檢查 Pod 是否處於執行中狀態：

   kubectl get pod -o wide

5. 檢查 Pod 的狀態，以確認 Pod 可以在不重新啟動的情況下執行：

   kubectl get pods -o wide

6. 如果存在重新啟動，請收集 Pod 日誌以確定原因：

   kubectl logs pod_namekubectl logs pod_name --previous

7. 登入 Amazon VPC 中的主機，您可以在其中與節點進行通訊。然後，將 curl 命令與 NodePort 搭配使用，以檢查 Pod 是否傳回預期的 HTTP 狀態代碼：

   curl node_IP:NodePort

   如果 curl 命令沒有傳回預期的 HTTP 狀態代碼，則後端 Pod 不會傳回預期的 HTTP 狀態代碼。

8. 使用相同的主機連接至 Pod 的 IP 位址，並檢查 Pod 是否已正確設定：

   curl pod_IP:pod_port

   如果 curl 命令沒有傳回預期的 HTTP 狀態代碼，則表示 Pod 未正確設定。

注意：如果服務的 externalTrafficPolicy (來自 Kubernetes 網站) 設定為本機，則只有執行服務後端 Pod 的節點才會視為運作狀態良好的目標。

IP 位址目標類型

1. 檢查目前運作狀態檢查組態註釋的服務規格。如需清單，請參閱 GitHub 網站上的運作狀態檢查組態註釋。

   kubectl get service service_name -o yaml

2. 登入 Amazon VPC 中的主機，然後使用 curl 命令與 Pod 的 IP 位址進行通訊：

   curl pod_IP:pod_port

   如果 curl 命令沒有傳回預期的 HTTP 狀態代碼，則表示 Pod 未正確設定。