NLB与HAProxy：SSL终止的最优实现位置探讨

架构背景 #

HTTPS请求流转流程：

1. 客户端发起HTTPS请求，经Route53完成DNS解析
2. 解析后的请求转发至Network Load Balancer（NLB）
3. NLB将流量转发至Kubernetes集群内的HAProxy Pod
4. HAProxy通过读取特定请求头，将流量路由至对应后端集群（实际存在多套后端集群，图中仅展示一套）

1. 最优TLS终止位置选择 #

最优方案是在HAProxy（橙色框）进行TLS终止，核心原因是HAProxy需要读取请求头完成路由决策，而请求头属于HTTPS加密报文内容，只有解密后才能获取，直接在HAProxy终止TLS可完美适配业务路由逻辑。

2. 两种方案的优缺点对比 #

方案一：在NLB（绿色框）终止TLS

优点

• 简化证书管理：仅需在NLB层面维护一套TLS证书，无需在K8s集群内的HAProxy实例重复部署，减少证书更新、轮换的运维工作量
• 原生性能优势：AWS NLB是托管式负载均衡服务，具备硬件级加密/解密能力，高吞吐量、低延迟，可承担大规模流量的TLS处理压力
• 节省集群资源：TLS解密工作由NLB承担，HAProxy Pod无需消耗CPU资源处理加密/解密操作，降低集群计算资源占用

缺点

• 无法适配核心路由需求：NLB终止TLS后转发明文流量给HAProxy，若后续需基于HTTPS请求头路由，NLB无法在加密状态下读取请求头；若NLB解密后转发，HAProxy虽能拿到请求头，但后端集群若需HTTPS传输，还需HAProxy重新加密，增加额外开销
• TLS配置灵活性不足：NLB的TLS配置相对基础，无法支持HAProxy那样丰富的策略（如自定义加密套件、会话复用规则、SNI路由等）
• 内部流量安全风险：NLB到HAProxy的流量为明文，若集群内部网络存在安全隐患，可能导致数据泄露

方案二：在HAProxy（橙色框）终止TLS

优点

• 适配核心路由逻辑：HAProxy直接完成TLS解密，可直接读取请求头内容，基于头信息完成多后端集群的路由转发，完全匹配业务需求
• 细粒度TLS控制：HAProxy支持丰富的TLS配置，可自定义加密套件、会话超时、SNI路由、证书链管理等，满足复杂的安全和业务场景
• 端到端加密支持：可实现客户端到HAProxy的HTTPS加密，同时HAProxy到后端集群也可继续使用HTTPS加密，保障内部网络流量安全
• K8s生态适配性强：借助K8s Secret资源可轻松管理HAProxy的TLS证书，结合证书管理器工具能实现证书自动轮换、更新

缺点

• 证书管理复杂度提升：需在每个K8s集群的HAProxy实例上部署TLS证书，多集群场景下需额外运维机制（如证书同步工具）保障一致性
• 集群资源消耗增加：TLS解密操作会占用HAProxy Pod的CPU资源，高流量场景下需预留足够的集群计算资源，或横向扩容HAProxy Pod数量
• 性能上限依赖HAProxy：相比NLB的硬件级处理，HAProxy的软件级TLS处理性能上限更低，高流量场景下需做好扩容规划

内容的提问来源于stack exchange，提问作者Kapil Khandelwal