如何对 Amazon EKS 中 Network Load Balancer 的运行状况不佳目标进行故障排除？

简短描述

以下是 Network Load Balancer 的目标运行状况不佳的常见原因：

• 运行状况检查配置不正确。要解决此问题，请从在 Amazon Virtual Private Cloud (Amazon VPC) 中运行的主机手动启动运行状况检查。
• Pod 中出现了意外的异常。要解决此问题，请按照“检查 Pod 中是否存在意外异常解决方案”部分中的故障排除步骤进行操作。
• 使用 externalTrafficPolicy 设置为 Local（来自 Kubernetes 网站）的 Network Load Balancer，并在 DHCP 选项中设置自定义 Amazon VPC DNS。要解决此问题，请使用主机名覆盖标志修补 kube-proxy。

**注意：**您可以通过查看服务注释 service.beta.kubernetes.io/aws-load-balancer-nlb-target-type 是否存在来确定目标组类型是 IP 地址还是实例。

解决方案

验证目标组是否为 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.

如果前面的注释配置不正确，则目标可能运行状况不佳。

从在 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 的端口。

检查 Pod 中是否有意外异常

实例目标类型

查看当前运行状况检查配置注释的服务规范（来自 GitHub 网站）：

kubectl get service service_name -o yaml

检查是否有端点可验证服务背后存在 Pod：

kubectl get endpoints service_name -o yaml

如果服务没有端点，请检查 Pod 标签和服务标签是否相符：

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

注意：将 pod_name 替换为您的 Pod 的名称。

检查 Pod 是否处于运行状态：

kubectl get pod -o wide

检查 Pod 的状态以验证其是否在没有重新启动的情况下正常运行：

kubectl get pods -o wide

如果存在重新启动，则收集 Pod 日志以确定原因：

kubectl logs pod_name
kubectl logs pod_name --previous

登录 Amazon VPC 中的主机，您可以在其中与该节点进行通信。

使用带有 NodePort 的 curl 命令来检查 Pod 是否返回了预期的 HTTP 状态码：

curl node_IP:NodePort

如果 curl 命令没有返回预期的 HTTP 状态码，那么后端 Pod 也不会返回预期的 HTTP 状态码。

使用同一台主机连接到 Pod 的 IP 地址，并检查 Pod 的配置是否正确：

curl pod_IP:pod_port

如果 curl 命令没有返回预期的 HTTP 状态码，则表明 Pod 配置不正确。

**注意：**如果服务的 externalTrafficPolicy（来自 Kubernetes 网站）设置为 Local，那么只有运行该服务的后端 Pod 的节点才会被视为健康目标。

IP 地址目标类型

查看当前运行状况检查配置注释的服务规范（来自 GitHub 网站）：

kubectl get service service_name -o yaml

登录 Amazon VPC 中的主机，然后使用 curl 命令与 Pod 的 IP 地址进行通信：

curl pod_IP:pod_port

如果 curl 命令没有返回预期的 HTTP 状态码，则表明 Pod 配置不正确。

使用主机名覆盖标志修补 kube-proxy

使用以下命令修改 kube-proxy 守护进程集规范命令、参数和环境：

---
spec:
  template:
    spec:
      containers:
      - name: kube-proxy
        command: [ "/bin/sh" ]
        args:
        - -c
        - |
          kube-proxy --v=2 --hostname-override=$(NODE_NAME) --config=/var/lib/kube-proxy-config/config
        env:
        - name: NODE_NAME
          valueFrom:
            fieldRef:
              apiVersion: v1
              fieldPath: spec.nodeName

对于实例目标类型，如果 externalTrafficPolicy 设置为 Cluster 或 Local，则节点安全组针对 NodePort 的默认入口设置为 0.0.0.0/0。此外，当 externalTrafficPolicy 设置为 Local 时，将配置额外的运行状况检查 NodePort 以允许子网 CIDR IP 地址范围。

要控制 NodePort 节点安全组上的源 IP 地址，请在规范中添加 loadBalancerSourceRanges 并包括以下范围：

spec:
loadBalancerSourceRanges:
- "143.231.0.0/16"
- "xx.yy.zz.zz/24"

**注意：**如果未设置 .spec.loadBalancerSourceRanges，则 Kubernetes 会允许从 0.0.0.0/0 到节点安全组的流量。如果节点具有公有 IP 地址，则非 Network Load Balancer 流量也可以到达已修改安全组中的每个实例。

---