1. 引言

在 Amazon EKS（Elastic Kubernetes Service）环境中，理解从 ALB（Application Load Balancer）到 Pod 的完整网络调用链对运维人员至关重要。本文将展示如何利用 Amazon Q CLI 这一 AI 助手工具，通过自然语言交互方式分析这一复杂网络路径。

📢限时插播：Amazon Q Developer 来帮你做应用啦！

🌟10分钟帮你构建智能番茄钟应用，1小时搞定新功能拓展、测试优化、文档注程和部署

⏩快快点击进入《Agentic Al 帮你做应用 -- 从0到1打造自己的智能番茄钟》实验

免费体验企业级 AI 开发工具的真实效果吧

构建无限，探索启程!

我们将重点关注外部请求经过 ALB、节点 iptables 规则，最终到达 Pod 的全过程，并演示运维人员如何通过向 Q CLI 提问来获取网络分析框架和技术解释，从而更高效地排查故障和优化性能。

同时，文章也将提供常见网络问题的解决方案与优化实践，帮助读者构建更稳定的 EKS 网络环境。

2. EKS 与 ALB Ingress 架构及 Amazon Q CLI 介绍

在深入探讨网络调用链之前，我们需要了解 Amazon EKS 与 ALB Ingress 的基本架构组件及其交互方式。

2.1 核心组件与数据流

主要组件：

• Amazon EKS：由亚马逊云科技管理的控制平面和用户管理的 EC2 工作节点组成，其中 VPC CNI 插件为 Pod 分配 VPC IP 地址。

• Amazon Load Balancer Controller：连接 Kubernetes 资源与亚马逊云科技负载均衡服务的桥梁，自动配置和管理相应的亚马逊云科技负载均衡器。

网络模式：

• Instance 模式：ALB 将流量发送到 EC2 节点的 NodePort，再由节点上的 iptables 规则 DNAT（Destination Network Address Translation）到目标 Pod。这种模式下，源 IP 会被 SNAT 为节点 IP。

• IP 模式：ALB 直接将流量发送到 Pod IP，绕过了 kube-proxy 和 NodePort，保留了客户端源 IP。

典型请求流程（Instance 模式）：

• 客户端请求 → ALB

• ALB 根据监听器规则 → EC2 节点 NodePort

• 节点 iptables 规则（kube-proxy 管理） → DNAT 到目标 Pod

• Pod 处理请求并生成响应

• 响应经 SNAT 处理 → ALB → 客户端

2.2 Amazon Q CLI 介绍与准备工作

在接下来的网络调用链分析中，我们将使用 Amazon Q CLI 作为辅助分析工具。Amazon Q CLI 是亚马逊云科技提供的一款 AI 助手命令行工具，它能够通过自然语言交互帮助运维人员理解复杂的亚马逊云科技环境和网络路径。

开始之前，请确保已经在本地电脑安装了必要的工具：

• Amazon Q CLI 已安装并配置，操作说明：安装适用于命令行的 Amazon Q

• Amazon CLI 已安装并配置，操作说明：安装或更新最新版本的 Amazon CLI

通过 Q 命令进入到与 Amazon Q CLI 的对话中。

Amazon Q CLI 的主要优势包括：

• 自然语言交互：可以使用自然语言描述问题，无需记忆复杂的命令语法

• 知识库支持：内置了亚马逊云科技服务和网络架构的知识，可以提供专业的解释和建议

• 上下文感知：能够理解亚马逊云科技资源之间的关系，提供连贯的分析视角

• 分析框架提供：针对复杂问题提供分析框架和思路，指导运维人员进行实际操作

通过使用 Amazon Q CLI，运维人员可以更快地理解从 ALB 到 Pod 的网络调用链，提高问题解决效率。

3. 使用 Amazon Q CLI 辅助分析网络调用链

本章将展示运维人员如何使用 Amazon Q CLI 工具辅助分析 EKS 环境中从 ALB 到 Pod 的完整网络路径。通过向 Q CLI 提出有针对性的问题，运维人员可以获得清晰的分析框架和技术解释，从而更好地理解复杂的网络路径。

3.1 从客户端经由 ALB 到 EC2 节点的流量路

当外部客户端发起请求时，流量首先到达 Amazon ALB，然后转发到 EC2 节点。我们可以通过向 Q CLI 提问来分析这个过程：

在 EKS 集群上部署了一个服务，通过 NodePort 的方式由 ALB 暴露给用户。分析这个场景下 HTTP 请求从客户端经过 ALB 到达 EC2 节点的完整流程。包括 DNS 解析、TCP 连接和请求处理。请以图表方式展示。

Q CLI 的分析结果如下：

它显示，这个过程包含以下关键步骤：

1、客户端到 ALB 阶段：

• DNS 解析获取 ALB 的 IP 地址

• TCP 三次握手建立连接

• HTTP 请求发送到 ALB

• ALB 根据监听器规则处理请求

2、ALB 到 EC2 节点阶段：

• ALB 根据目标组配置选择目标 EC2 实例

• ALB 将请求转发到 EC2 节点的 NodePort

• 请求通过 VPC 网络到达 EC2 实例

3.2 节点内部的 iptables 处理机制

当请求到达 EC2 节点的 NodePort 后，节点内部的 iptables 规则负责将流量转发到正确的 Pod。这是 Kubernetes 网络模型中最复杂的部分之一。

向 Q CLI 提问：

EKS 节点的 ssh 密钥是/Users/guanzl/.ssh/masterconn.pem，请连到 EKS cluster zhili-cluster-1 的节点上分析 EKS 节点上的 iptables 规则链如何处理从 NodePort 进入的流量，直到转发到正确的服务 sample-app-service 关联 Pod。绘制一个完整的规则链流程图，包括从 PREROUTING 到最终的 DNAT。

Q CLI 的分析结果显示：

此外，在图表后 Q CLI 还给出了完整流程总结：

1. 流量入口：ALB 将请求发送到 EKS 节点的 31564 端口（NodePort）

2. PREROUTING 处理：流量进入PREROUTING链，然后转发到KUBE-SERVICES链

3. NodePort 识别：在 KUBE-SERVICES 链中，识别为 NodePort 流量，转发到 KUBE-NODEPORTS 链

4. 服务匹配：在 KUBE-NODEPORTS 链中，匹配端口 31564，转发到 KUBE-EXT-LV7ZA3PWSGGQGJTO 链

5. 标记与转发：在 KUBE-EXT-LV7ZA3PWSGGQGJTO 链中，标记需要 SNAT 的包，并转发到 KUBE-SVC-LV7ZA3PWSGGQGJTO 链

6. 负载均衡：在 KUBE-SVC-LV7ZA3PWSGGQGJTO 链中，通过随机概率选择一个后端 Pod

7. DNAT 转换：在选定的 Pod端点链（KUBE-SEP-QSIPBIKVUMNQOTRL或KUBE-SEP-2IPGHRKMWR3QOKOC）中，执行 DNAT，将目标地址转换为 Pod 的 IP 和端口

8. SNAT 处理：在 POSTROUTING 链中，对标记的包执行 SNAT，确保返回流量能正确路由

这个过程中，特别值得注意的是 KUBE-SVC 链中的负载均衡机制：

-A KUBE-SVC-XXX -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-1
-A KUBE-SVC-XXX -j KUBE-SEP-2

这种基于概率的负载均衡在高流量场景下可能导致分布不均，是后续优化的重点之一。

3.3 Pod 通信与响应返回路径

经过 iptables 的 DNAT 处理后，数据包需要从节点网络栈到达目标 Pod，处理完成后再返回客户端。这个双向过程涉及多个网络组件的协同工作。向 Q CLI 提问：

“分析数据包经过 iptables DNAT 后如何到达目标 Pod，以及响应如何返回客户端。”

Q CLI 的分析结果显示：

1、DNAT 后，数据包到达 Pod 的路径：

• DNAT 转换：数据包经过 iptables 的 DNAT 规则，目标地址被修改为 Pod 的 IP 和端口

• 路由决策：内核根据新的目标地址重新进行路由决策

• 网络转发：数据包转发到目标 Pod

• 连接跟踪：内核的 conntrack 模块记录连接信息，包括原始地址和转换后地址

• 到达 Pod：数据包最终到达 Pod 的网络命名空间，被应用程序接收处理

2、响应返回的路径：

• Pod 生成响应数据包，此时源地址为 Pod IP，目标为客户端 IP

• 响应数据包离开 Pod 网络命名空间，进入节点网络栈

• conntrack 模块自动进行反向 NAT，将源地址从 Pod IP 改回服务 IP（如 NodePort 对应的地址和端口）

• 数据包通过节点网卡发送到 ALB

• ALB 将响应转发给原始客户端

这个过程中，Linux 内核的 conntrack 模块起着至关重要的作用，它维护了 NAT 转换的状态表，确保响应数据包能够正确返回。

3.4 conntrack 连接跟踪状态分析

conntrack 模块是 Linux 网络栈的核心组件，对于理解 NAT 环境中的连接状态至关重要。

向 Q CLI 提问：

“分析 Linux conntrack 模块在 Kubernetes 服务网络中的作用。”

Q CLI 的分析指出：

1、连接状态跟踪。conntrack 维护了所有网络连接的状态表，记录了每个连接的详细信息，这使得 Linux 内核能够了解哪些数据包属于已建立的连接，哪些是新连接请求。

• 源 IP：端口和目标 IP：端口

• 协议类型（TCP/UDP/ICMP 等）

• 连接状态（NEW, ESTABLISHED, RELATED, INVALID 等）

• 连接超时时间

2、支持 NAT 功能。在 Kubernetes 中，conntrack 为 kube-proxy 的 iptables 模式提供了关键支持。没有 conntrack，Kubernetes 的 Service 网络模型将无法正常工作。

• 当请求通过 Service IP 访问后端 Pod 时，iptables 执行 DNAT 操作

• conntrack 记录这个 NAT 映射关系

• 当 Pod 返回响应时，conntrack 自动执行反向 NAT，确保数据包能正确返回客户端

3、会话保持与负载均衡。conntrack 确保来自同一客户端的连续请求能够被路由到同一 Pod，提供会话亲和性。这对于有状态应用尤为重要。

4、潜在挑战

• 表容量限制：高流量环境可能导致 conntrack 表满，新连接被丢弃

• 连接粘性：Service 更新 selector 后，已有连接仍会路由到旧 Pod

• 性能开销：大量连接时可能成为性能瓶颈

通过使用 Amazon Q CLI 辅助分析，运维人员可以更快地理解 EKS 网络调用链的复杂机制，获得分析思路和排查方向，从而提高问题解决效率。Q CLI 提供的分析框架和技术解释，结合实际的命令验证，为运维工作提供了有力支持。

4. 常见问题与优化实践

在 EKS 环境中运行生产级应用时，我们可能会遇到各种网络相关的挑战。本章将深入探讨四个常见问题，分析其根本原因，并提供实用的解决方案和优化建议。

4.1 Pod负载不均衡

4.1.1 问题描述

EKS 的 kube-proxy 默认使用 iptables 模式。基于前文对网络调用链的分析，我们了解到 iptables 模式下流量是基于固定概率分配的。这种机制存在几个明显的局限性：

• 连接级别的随机性：负载均衡在连接级别，导致短连接场景下分布不均

• 忽略实际负载状态：分配机制没有考虑 Pod 的实际负载、连接数或处理能力

• 连接持久性问题：长连接可能导致某个 Pod 长时间”粘住”大量请求

这些限制在高并发或短连接场景下尤为明显，可能出现某些 Pod 被“打爆”，而其他几乎空闲的现象，形成严重的负载倾斜。

4.1.2 优化策略

如果在 EKS 上遇到负载倾斜问题，可以考虑切换到 IPVS（IP Virtual Server） 模式：将 kube-proxy 配置为 IP Virtual Server (IPVS) 模式，相比 iptables 模式有以下优势：

• 使用哈希表而非线性搜索处理数据包，性能更高

• 提供多种负载均衡算法，如 Round Robin，Weighted Round Robin 等。

4.2 连接跟踪表溢出

4.2.1 问题症状

在 EKS 集群高流量场景下，节点可能出现连接跟踪表（conntrack）溢出的情况，表现为：

• 间歇性的连接超时或请求被拒绝

• 系统日志中出现”nf_conntrack: table full, dropping packet”错误

• 更新 Service 的 selector 后，流量仍然导向旧的 Pod 长达几十秒

4.2.2 问题原因

EKS 节点使用 Linux 内核的 conntrack 模块跟踪所有网络连接状态。当连接数超过 net.netfilter.nf_conntrack_max 设置的最大值时，新的连接会被丢弃。默认配置通常不足以应对高流量生产环境。

4.2.3 诊断方法

可通过以下命令诊断 conntrack 表状态：

# 查看当前conntrack表使用情况
sudo sysctl net.netfilter.nf_conntrack_count
# 查看最大conntrack表大小
sudo sysctl net.netfilter.nf_conntrack_max
# 检查是否有溢出日志
sudo dmesg | grep conntrack

4.2.4 优化策略

针对 conntrack 表溢出问题，可以采取以下优化措施：

1、增加 conntrack 表容量：

# 临时修改
sudo sysctl -w net.netfilter.nf_conntrack_max=1048576
sudo sysctl -w net.netfilter.nf_conntrack_buckets=262144
# 永久修改
echo 'net.netfilter.nf_conntrack_max=1048576' | sudo tee -a /etc/sysctl.conf
echo 'net.netfilter.nf_conntrack_buckets=262144' | sudo tee -a /etc/sysctl.conf

2、优化 conntrack 超时设置：

# 已建立连接的超时时间
sudo sysctl -w net.netfilter.nf_conntrack_tcp_timeout_established=86400
# TIME_WAIT 状态的超时时间（默认 120 秒，可减少）
sudo sysctl -w net.netfilter.nf_conntrack_tcp_timeout_time_wait=30

3、定期清理 conntrack 表

# 例如清除特定服务端口的 conntrack 记录
sudo conntrack -D -p tcp --dport <service-port>

4.3 滚动更新期间出现 5xx 错误

4.3.1 问题描述

在 EKS 环境中，使用 Amazon Load Balancer Controller 的应用在滚动更新期间出现 502 Bad Gateway 或 504 Gateway Timeout 错误。这一现象在使用 target-type: ip 模式（ALB 直接路由到 Pod IP）时尤为明显。

4.3.2 问题分析

这些 5xx 错误本质上是由 Amazon ALB 控制面与数据面之间的异步更新机制，以及 Kubernetes Pod 终止过程的时序不匹配导致的。具体流程如下：

1. 滚动更新开始，Kubernetes 向旧 Pod 发送 SIGTERM 信号，启动终止序列

2. Amazon Load Balancer Controller 检测到 Pod 终止事件，向 ALB 控制面发送目标注销请求

3. ALB 控制面将目标标记为 “draining” 状态，但这一状态变更需要时间传播到所有 ALB 数据面节点

4. 在这个传播窗口期（通常为几秒到几十秒），ALB 数据面节点仍可能将新请求路由到正在终止的 Pod

5. 此时 Pod 可能已关闭其监听端口或终止应用进程，导致请求失败并触发 ALB 返回 502/504 错误

4.3.3 优化策略

可以采取以下措施来缓解这个问题。

1、给容器添加 preStop 钩子延迟，这会在 Pod 终止前增加一个延迟，给负载均衡器足够的时间将目标标记为排空状态并停止发送新请求。

lifecycle:preStop:exec:command: [ "sh", "-c", "sleep 30" ]

2、设置 terminationGracePeriodSeconds。这为 Pod 提供了更长的”优雅退出”时间，确保有足够的时间处理现有请求并完成清理工作。

3、减少 ALB 的注销延迟。加快目标从 ALB 目标组中移除的速度。

annotations:alb.ingress.kubernetes.io/target-group-attributes: deregistration_delay.timeout_seconds=30

4、启用 Pod Readiness Gates。确保 Pod 只有在成功注册到 ALB 目标组后才被标记为就绪，同样，只有在成功从 ALB 目标组中注销后才会被终止。

kubectl label namespace <your_namespace> elbv2.k8s.aws/pod-readiness-gate-inject=enabled

4.4 Service 更新 selector 后流量延迟切换问题

4.4.1 问题描述

当用户部署了新的 deployment 并通过更新 Service 的 pod selector 切换到新 deployment 时，会出现一个持续数秒到数分钟的时间窗口，流量仍然会导向旧的 Pod，导致应用行为不一致或错误。这个问题在高并发环境中尤为明显。

4.4.2 问题原因

这是因为当更新 Service 的 selector 时，kube-proxy 更新 iptables 规则，但 Linux 内核的 conntrack 模块会保持现有的连接记录，直到这些连接超时或被显式清除。这些保持的连接状态会导致已建立的流量继续被发送到旧的 Pod。

4.4.3 优化策略

针对这个问题，可以采取以下策略：

1. 停止旧 Deployment 断开 conntrack 中的连接

2. 主动清除 EKS 节点上相关的 conntrack 表项

3. 蓝绿部署策略。创建新的 Service 指向新的 deployment，并更新 Ingress 指向新的 Service。这种方法避免了修改现有 Service，而是创建新的 Service 并更新入口层配置，完全绕过了 conntrack 连接粘性问题。

5. 总结

本文深入分析了 Amazon EKS 环境中 ALB Ingress Controller 的 Instance 模式网络调用链，从外部请求到内部 Pod 的完整流程。此外，我们还分析了四个常见网络问题及响应的优化策略。

通过理解这些网络机制，您可以更有效地排查 EKS 环境中的网络问题，优化应用性能，并设计更健壮的云原生架构，为构建稳定高效的 Kubernetes 应用提供技术支持。

*前述特定亚马逊云科技生成式人工智能相关的服务仅在亚马逊云科技海外区域可用，亚马逊云科技中国仅为帮助您了解行业前沿技术和发展海外业务选择推介该服务。

本篇作者

本期最新实验为《Agentic AI 帮你做应用 —— 从0到1打造自己的智能番茄钟》

✨ 自然语言玩转命令行，10分钟帮你构建应用，1小时搞定新功能拓展、测试优化、文档注释和部署

💪 免费体验企业级 AI 开发工具，质量+安全全掌控

⏩️[点击进入实验] 即刻开启 AI 开发之旅

构建无限, 探索启程！