如何在Kubernetes集群中通过ingress-nginx实现HTTP/2正常工作？

我来帮你梳理清楚这个HTTP/2配置的问题，一步步拆解：

先给你明确答案：不需要端到端HTTPS就能让HTTP/2生效。

HTTP/2本身支持两种模式：一种是基于TLS的h2（也就是浏览器常用的HTTPS+HTTP/2），另一种是明文的h2c（主要用于服务端之间的内部通信）。浏览器因为安全限制几乎只支持h2，但服务端之间的内部通信完全可以用h2c。

对你的场景来说，只要客户端和ingress-nginx之间的HTTPS连接能跑HTTP/2，前端就已经能享受到HTTP/2的加速收益——后端服务和网关之间用HTTP/1.1，只会影响内部通信效率，不会导致前端的HTTP/2连接降级。

1. 最初的AWS ELB是核心瓶颈 #

你已经发现了：早期的AWS Elastic Load Balancer（不管是Classic还是旧版本的ALB）不支持HTTP/2。当客户端发起HTTP/2请求时，ELB会直接把它降级为HTTP/1.1转发给后端的ingress-nginx，这就导致整个链路从客户端开始就只能用HTTP/1.1，完全没机会用到HTTP/2。

2. 换成NLB后仍不生效的可能原因 #

既然换成了Network Load Balancer（四层负载均衡，会透传TCP数据包，理论上不会影响HTTP/2协商），但还是没生效，结合你用的ASP.NET Core 2.2 Kestrel服务器，大概率是这几个问题：

• NLB监听配置或客户端验证问题：先确认客户端和NLB之间是否真的协商了HTTP/2。你可以用浏览器开发者工具的Network面板（看每个请求的Protocol列），或者用curl -v --http2 https://你的域名来测试——如果返回的是HTTP/1.1，说明协商失败了。
• Kestrel的HTTP/2配置没到位：虽然Kestrel在HTTPS下默认启用HTTP/2，但如果你的API网关是用HTTP监听的（之前和nginx之间用HTTP），Kestrel默认不会启用明文HTTP/2（h2c），需要显式配置：
  打开你的appsettings.json，检查Kestrel的端点配置：

  "Kestrel": {
    "Endpoints": {
      "Http": {
        "Url": "http://*:80",
        "Protocols": "Http1AndHttp2"
      }
    }
  }
  

  如果网关用的是HTTPS，也要确保明确指定了支持HTTP/2：

  "Kestrel": {
    "Endpoints": {
      "Https": {
        "Url": "https://*:443",
        "Protocols": "Http1AndHttp2"
      }
    }
  }
  

• SSL/ALPN配置问题：如果网关用HTTPS，要确保Kestrel的SSL配置支持ALPN（HTTP/2协商依赖ALPN扩展）。你用的OpenSSL 1.1.1是支持的，ASP.NET Core 2.2也会默认启用，但如果证书有问题（比如不是有效的SSL证书），或者Kestrel的SSL配置遗漏了ALPN，也会导致协商失败降级为HTTP/1.1。
• 客户端兼容性问题：比如用了旧版本的浏览器、curl或者其他工具，不支持HTTP/2，自然会协商成HTTP/1.1。

如果你的业务有合规要求，或者需要内部服务之间也用HTTPS，推荐这几个方案：

• 内部CA颁发证书：搭建企业内部CA，给API网关和所有后端服务颁发内部证书。只要ingress-nginx、网关、后端服务都信任内部CA的根证书，就能实现安全的端到端HTTPS通信，还不用花公网证书的钱。
• 用cert-manager自动化管理：在Kubernetes集群里部署cert-manager，它可以自动签发、续期证书。对于公网的ingress，用Let's Encrypt等公网CA；对于内部服务，配置cert-manager用内部CA颁发证书，全程自动化，不用手动维护证书。
• 不推荐：共享公网证书：把公网证书复制给内部服务虽然能凑合用，但证书泄露风险高，续期也麻烦，不建议在生产环境用。

内容的提问来源于stack exchange，提问作者Chris Swinchatt