当外部客户端通过 HTTPS 访问 Kubernetes 集群中的服务时，流量首先到达一个入口组件，比如 Ingress Controller、Service 类型的 LoadBalancer 或者独立的反向代理。此时面临一个关键决定：TLS 会话应该在哪里结束？如果选择在入口处解密，就是 TLS 终止（TLS termination）；如果让入口只做四层转发、不解密，把密文直接送到后端 Pod，就是 TLS 透传（TLS passthrough）。这两种模式不仅影响证书管理方式，也决定代理能提供哪些功能以及安全边界在哪里。
下面从工作原理、能力差异和实际配置三个层面展开对比，帮助你在不同场景下做出合理选择。
一、TLS 终止：在入口处解密并转发
TLS 终止的核心思路是把证书和私钥集中放在集群入口。客户端与入口控制器完成 TLS 握手，入口控制器解密请求内容，然后以明文 HTTP 的形式将请求转发给后端 Service 对应的 Pod。这是 Nginx Ingress 默认的工作方式，也是大多数七层负载均衡器的标准行为。证书通常存储在 Kubernetes Secret 中，由 Ingress 资源通过 spec.tls 字段引用，入口控制器会监听 Secret 变化并自动加载新证书。
这种模式最大的优势在于七层处理能力。由于代理能够看到完整的 HTTP 请求，它可以基于 Host、路径、Header、Cookie 等维度做精细路由，还能实现请求重写、认证、限流、缓存、灰度发布等功能。比如同一个入口 IP 下托管多个域名，终止模式下可以根据 Host 头把不同域名的请求分发到不同后端服务，同时路径 /api 和 /web 也可以分给不同 Service。证书统一管理也降低了运维成本：只需要在入口处更新一张证书，后端应用无需关心 TLS 细节。
不过，缺点同样明显。一旦入口解密，代理与后端 Pod 之间的流量就变成了明文 HTTP。如果集群内部网络不可信，或者某个 Pod 被攻破后进行流量嗅探，请求中的用户名、密码、令牌等敏感信息就可能泄露。对于合规要求严格的场景，仅靠终止模式还不够，需要引入 Service Mesh 或 mTLS 对内网流量重新加密。另外，终止模式下所有 TLS 加解密压力都集中在入口控制器上，高并发场景下可能成为 CPU 瓶颈。
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: tls-termination-example
spec:
tls:
- hosts:
- api.ipipp.com
secretName: tls-secret
rules:
- host: api.ipipp.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: backend-svc
port:
number: 80
上面这个例子中，入口控制器会使用 tls-secret 中的证书与客户端协商 TLS，然后把解密后的请求转发到 backend-svc 的 80 端口。注意后端 Service 端口是 80 而不是 443，因为此时后端收到的是明文 HTTP，不再需要 TLS 监听。
二、TLS 透传：让密文直达后端
与终止模式相反，TLS 透传要求入口控制器不解密流量，而是根据 TLS 握手时的 SNI（Server Name Indication）信息或四层目标端口，把完整的加密数据包转发到后端 Pod。这意味着后端 Pod 必须自己监听 443 端口、持有证书、并完成与客户端的 TLS 握手。Nginx Ingress 需要显式开启透传功能，通常通过注解 nginx.ingress.kubernetes.io/ssl-passthrough: "true" 启用，同时后端 Service 的端口必须配置为 443 或实际 TLS 端口。
透传模式的核心价值是端到端加密。代理只看到加密后的字节流和 SNI 中的域名，无法获取请求路径、Header 或正文内容。这在零信任架构中更受欢迎，因为即使入口控制器被攻破，攻击者也无法直接读取用户数据。证书管理责任下放到各个服务团队，每个后端应用独立维护自己的证书和私钥，避免了单点证书泄露影响所有服务的问题。
但透传的代价是放弃了七层处理能力。代理无法基于 URL 路径做路由，也不能做请求改写或认证，只能通过 SNI 区分不同域名并转发到对应后端。如果多个服务共用同一个入口 IP，路由粒度基本局限在域名级别。此外，由于代理无法解析 HTTP，也就不能做连接复用、响应缓存或请求压缩，后端需要直接面对每个客户端的完整 TLS 握手和 TCP 连接，连接管理和加解密压力会转移到应用实例上。
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: tls-passthrough-example
annotations:
nginx.ingress.kubernetes.io/ssl-passthrough: "true"
spec:
rules:
- host: secure.ipipp.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: backend-svc
port:
number: 443
在这个配置中，虽然仍然定义了 path 字段，但在透传模式下 Nginx Ingress 会忽略路径匹配，只根据 host 的 SNI 信息将密文流转发给 backend-svc 的 443 端口。后端 Service 本身必须已经部署了 TLS 证书，否则客户端握手会失败。
三、安全边界、性能与运维对比
从安全角度看，终止模式的代理是明文可见的，这为审计、WAF、入侵检测提供了便利，但同时也意味着代理本身成为高价值攻击目标。一旦代理被攻破，所有经过它的明文流量都可能被窃取。透传模式则大大缩小了代理的可读范围，攻击者即使控制代理也只能获取 SNI 和目标地址，实际请求内容仍然加密。不过，透传模式下代理无法做应用层防护，恶意请求需要由后端应用自行过滤。
性能方面，两种模式各有侧重。终止模式在入口处完成加解密，后端 Pod 只处理明文 HTTP，省去了 TLS 计算，而且代理可以与后端建立并复用 HTTP 长连接，减少握手开销。但入口控制器需要处理所有 TLS 会话，CPU 消耗高，尤其在证书密钥长度较大或并发连接数极高时。透传模式则把加解密压力分散到每个后端 Pod，入口只做数据包转发，CPU 负担很小，但后端需要为每个客户端维护独立的 TLS 会话，无法通过代理聚合连接，可能导致大量短连接和较高的内存占用。
运维上的差异也很直观。终止模式证书集中管理，更新和轮换只需改一处，适合统一安全策略；透传模式证书分散在多个服务中，需要更完善的自动化证书分发和监控机制，否则容易出现证书过期不一致的问题。此外，终止模式更容易接入现有监控和日志系统，因为代理可以记录完整的 HTTP 访问日志；透传模式下代理日志只有四层信息，排障时需要依赖后端应用自身的日志。
| 对比维度 | TLS 终止 | TLS 透传 |
|---|---|---|
| 证书位置 | 入口控制器 | 后端 Pod |
| 七层路由/认证/限流 | 支持 | 不支持 |
| 端到端加密 | 否，内网明文 | 是 |
| 入口 CPU 压力 | 高 | 低 |
| 后端加解密压力 | 无 | 高 |
| 证书运维复杂度 | 低，集中管理 | 高，分散管理 |
四、选型建议与混合方案
如果你的业务需要在入口做统一认证、限流、灰度发布、路径路由，或者后端应用本身不具备 TLS 处理能力，选择 TLS 终止会更加务实。例如一个前端应用需要接入 OAuth2 代理，由入口控制器完成身份校验后再把请求转发给后端，此时终止模式几乎是必需的选择。如果后端是一个简单的内部 API，对明文内网流量没有额外安全顾虑，终止模式也能减轻后端开发负担。
反过来，如果数据保密性要求很高，后端服务已经能处理 TLS（例如 gRPC over TLS、数据库协议或自带证书的应用），或者希望把私钥严格控制在服务团队手中，透传模式更合适。典型的场景是金融、医疗等合规领域，要求数据在传输全链路都不落明文。另外，当入口只承担四层负载均衡职责，不需要任何 HTTP 层操作时，透传也能简化代理配置。
实际生产中还常见一种混合方案：外层使用 TLS 终止以满足七层路由和 WAF 需求，内网再通过 Service Mesh 的 mTLS 对 Pod 间流量重新加密。这样既保留了入口的七层能力，又弥补了内网明文的问题。不过这种方案增加了系统复杂度，需要引入 Istio、Linkerd 或 Consul Connect 等组件，并仔细管理两套证书体系。最终选择应基于团队对安全、性能、运维成本的综合评估，而不是盲目追求某一种模式。
TLS终止TLS透传Kubernetes Ingress修改时间：2026-10-06 17:25:46