Kong网关代理HTTPS流量至MinIO的故障排查与解决方案

背景介绍

在使用Kong网关作为Kubernetes入口控制器时，将HTTPS流量代理至MinIO对象存储服务时遇到了连接问题。具体表现为两种错误模式：一种是"Connection reset by peer"（连接被对端重置），另一种是"Client sent an HTTP request to an HTTPS server"（客户端发送HTTP请求到HTTPS服务器）。

问题现象分析

在Kong 3.9.0版本中配置了Gateway、HTTPRoute和ReferenceGrant资源后，当尝试通过Kong访问MinIO服务时，系统表现出以下异常行为：

1. 在Kong日志中可见"readv() failed (104: Connection reset by peer)"错误，表明上游连接被意外终止
2. 使用curl测试时，出现SSL/TLS重协商现象，最终返回400错误，提示HTTP/HTTPS协议不匹配

配置细节解析

典型的Kong网关配置包含几个关键部分：

网关定义：

• 监听80端口的HTTP流量
• 监听443端口的HTTPS流量，并配置TLS终止
• 使用通配符证书进行加密通信

MinIO路由配置：

• 为MinIO API服务(端口9000)和Console服务(端口9443)分别配置路由
• 显式指定后端协议为HTTPS
• 配置主机名和路径匹配规则

根本原因诊断

经过深入分析，发现问题核心在于服务级别的协议配置缺失。虽然HTTPRoute资源中通过注解指定了后端协议为HTTPS，但这一配置并未完整传递至服务级别。

Kong网关在处理流量时需要明确知道：

1. 入口流量协议（通过Gateway定义已明确）
2. 出口流量协议（需要服务级别明确声明）

解决方案

完整的解决方案需要以下配置调整：

1. 服务注解补充： 在MinIO的Service定义中添加协议注解，明确指定使用HTTPS协议：

metadata:
  annotations:
    konghq.com/protocol: https

2. 路由配置优化： 确保HTTPRoute资源中协议相关注解的一致性：

metadata:
  annotations:
    konghq.com/backend-protocol: "https"
    konghq.com/protocols: "https"

3. TLS验证配置： 考虑是否需要跳过TLS验证（仅限测试环境）：

metadata:
  annotations:
    konghq.com/verify: "off"

最佳实践建议

1. 协议一致性检查：

• 确保Gateway、Route和Service三个层次的协议配置一致
• 特别注意混合协议场景下的配置

2. 日志监控：

• 配置Kong的详细日志级别以捕获更多连接细节
• 监控TLS握手过程中的异常

3. 测试验证：

• 使用不同工具(如curl、Postman)进行协议兼容性测试
• 验证不同路径的协议处理是否正确

技术原理深入

Kong网关在处理HTTPS流量时涉及多层协议转换：

1. 入口层：

• 接收客户端HTTPS请求
• 终止TLS连接（当配置为TLS终止模式时）
• 解析HTTP请求内容

2. 路由层：

• 根据主机名和路径匹配路由规则
• 应用插件和转换规则

3. 代理层：

• 根据配置重新建立与上游的连接
• 决定使用HTTP还是HTTPS协议与上游通信
• 处理可能的协议转换和TLS验证

当这些层次间的协议配置不一致时，就会导致上述的连接问题。理解这一流程有助于快速定位类似问题。

总结

Kong网关作为云原生环境下的API网关，其协议处理能力强大但配置需要精确。特别是在处理MinIO这类同时提供API和Console服务的系统时，更需要仔细检查各层级的协议配置。通过本文的分析和解决方案，开发者可以系统性地解决HTTPS代理问题，并建立起完整的协议处理认知模型。