You need to enable JavaScript to run this app.
优惠活动
大模型
产品
解决方案
定价
更多

Pod级TLS终止配置故障排查:Ingress至Pod链路配置无效求助

Pod级别TLS终止配置问题排查

问题背景

链路架构为 Ingress(NLB) -> Service(ClusterIP) -> Pod,需在Pod级别实现TLS终止。已为Ingress添加SSL透传注解,但不确定Pod侧所需配置,且疑惑是否只能通过mTLS实现(仅需为命名空间内2个Pod配置该功能)。当前尝试的配置未生效,请求排查遗漏点。

已配置内容

  1. Nginx Ingress控制器:
enabled ssl-passthrough 
  1. Ingress注解:
annotations:
  nginx.ingress.kubernetes.io/backend-protocol: HTTPS
  nginx.ingress.kubernetes.io/force-ssl-redirect: "true"
  nginx.ingress.kubernetes.io/ssl-passthrough: "true"
  nginx.ingress.kubernetes.io/ssl-redirect: "true"
  1. Ingress规格:
spec:
  rules:
  - host: xyz.test.com
    http:
      paths:
      - backend:
          service:
            name: xyz
            port:
              number: 443
        path: /
        pathType: Prefix
  1. Service端口配置:
ports:
- name: https
  port: 443
  protocol: TCP
  targetPort: 1443
  1. Pod侧Nginx Sidecar配置:
ports:
- containerPort: 1443
  name: https
  protocol: TCP

volumeMounts:
- name: secret
  mountPath: /etc/nginx/ssl
  readOnly: true

volumes:
- name: secret
  secret:
    secretName: xyz-tls 
  1. Nginx配置文件:
server {
  listen 1443 default_server ssl;
  listen [::]:1443 default_server ipv6only=on;
  ssl_certificate /etc/nginx/ssl/tls.crt;
  ssl_certificate_key /etc/nginx/ssl/tls.key;
  # 其他配置...
}

已确认Pod内/etc/nginx/ssl目录下存在tls.crt和tls.key文件。

问题分析与排查点

首先明确:Pod级别TLS终止不需要强制使用mTLS,只要Pod内的服务(此处为Nginx Sidecar)能正确加载证书并处理HTTPS请求即可。以下是可能的遗漏或错误点:

1. Ingress控制器的SSL透传功能是否真正启用

ssl-passthrough需要Ingress控制器启动时通过参数开启,而非仅靠Ingress注解。如果是通过Helm安装的Nginx Ingress,需确认values.yaml中配置了:

controller:
  extraArgs:
    enable-ssl-passthrough: true

若直接部署控制器Pod,需确保启动命令包含--enable-ssl-passthrough参数。仅写enabled ssl-passthrough可能不符合配置格式,导致功能未生效。

2. Ingress注解与模式冲突

ssl-passthrough是基于TCP层的流量透传,Ingress控制器不会解析HTTP协议,因此nginx.ingress.kubernetes.io/backend-protocol: HTTPS注解是多余的,甚至可能干扰流量转发,建议移除。

3. Ingress是否配置了多余的TLS字段

若Ingress资源中存在spec.tls配置块,控制器会尝试在Ingress层面终止SSL,与ssl-passthrough的透传逻辑冲突,需移除该配置块。

4. Nginx Sidecar的配置与运行状态验证

  • 检查Nginx日志:执行命令查看Sidecar的错误日志,确认是否有配置错误导致无法启动:
    kubectl exec -it <你的Pod名称> -c <Nginx Sidecar容器名称> -- tail -f /var/log/nginx/error.log
    
  • 验证端口监听:确认Nginx确实在监听1443端口:
    kubectl exec -it <你的Pod名称> -c <Nginx Sidecar容器名称> -- netstat -tulpn | grep 1443
    
  • 证书有效性:确认证书文件内容完整,可执行以下命令检查:
    kubectl exec -it <你的Pod名称> -c <Nginx Sidecar容器名称> -- openssl x509 -in /etc/nginx/ssl/tls.crt -text -noout
    

5. 集群内连通性测试

先绕过Ingress和Service,直接测试Pod的HTTPS服务是否正常:

curl -v https://<Pod的IP地址>:1443 --insecure

若此测试失败,说明Pod侧的Nginx配置存在问题;若测试成功,再测试Service的连通性:

curl -v https://xyz.test.com:443 --resolve xyz.test.com:443:<Service的ClusterIP> --insecure

逐步排查流量链路中的问题。

内容的提问来源于stack exchange,提问作者Rad4

相关产品推荐
方舟 Agent Plan

超全模态模型 × Harness 升级,最新支持 Deepseek-V4.1-Flash、GLM-5.3 系列、Doubao-Seedream-5.0-pro、Kimi-K3 (部分), 限时 9.9 元起

最近更新时间:2026.07.19 18:54:54