Holos项目中Istio Gateway配置优化实践

Holos项目中Istio Gateway配置优化实践

holos Holistic platform manager 项目地址: https://gitcode.com/gh_mirrors/hol/holos

背景介绍

在Holos项目的Kubernetes集群中，我们使用Istio作为服务网格解决方案来处理入口流量管理。近期在开发环境中遇到了一个典型问题：当用户访问类似https://jeff.app.dev.k2.holos.run/这样的子域名时，会导致主域名https://app.dev.k2.holos.run/返回404 Not Found响应。

问题现象分析

通过检查Istio的访问日志，我们发现了一个关键现象：请求中的requested_server_name(实际请求的服务器名)与authority(HTTP头中的主机名)不一致。具体表现为：

• requested_server_name: "app.dev.k2.holos.run"
• authority: "jeff.app.dev.k2.holos.run"

这种不匹配导致了Istio无法正确路由请求，从而返回404 NR(No Route)错误。

根本原因

这个问题实际上是Istio中一个已知的配置问题。当存在多个Gateway配置时，如果请求的SNI(Server Name Indication)与HTTP Host头不匹配，Istio可能会错误地选择Gateway配置，导致路由失败。

在Holos 0.74.0版本中，我们的Gateway配置采用了为每个子域名单独定义的方式，这违反了Istio的最佳实践。当前的配置包含了大量独立的服务器定义，每个都对应特定的主机名，例如：

- hosts:
  - jeff-holos/jeff.app.dev.k2.holos.run
  - dev-holos-system/jeff.app.dev.k2.holos.run
  port:
    name: https-jeff-app-dev-k2-holos-run
    number: 443
    protocol: HTTPS
  tls:
    credentialName: app.dev.holos.run
    mode: SIMPLE

解决方案

根据Istio官方文档的建议，正确的做法是使用单个通配符Gateway配置，而不是为每个子域名创建单独的配置。具体优化方案包括：

1. 创建一个统一的Gateway配置，使用通配符主机名(如*.dev.k2.holos.run)
2. 为这个Gateway配置使用通配符证书
3. 将所有相关的VirtualService绑定到这个统一的Gateway上

这种配置方式有以下优势：

• 简化配置管理
• 避免SNI与Host头不匹配导致的路由问题
• 减少Istio配置的复杂度
• 提高系统的可维护性

实施细节

在开发环境中，我们已经使用了支持通配符的证书。通过检查证书内容，可以确认证书包含了必要的通配符域名：

*.app.dev.core1.holos.run
*.app.dev.core2.holos.run
*.app.dev.holos.run
*.app.dev.k1.holos.run
*.app.dev.k2.holos.run
*.app.dev.k3.holos.run
*.app.dev.k4.holos.run
*.app.dev.k5.holos.run

这为实施统一的通配符Gateway配置提供了基础条件。

后续改进

在AWS2环境中，这个问题已经通过配置优化得到了解决。我们需要将这一优化方案推广到所有环境中，确保整个系统的稳定性和一致性。

总结

在Istio的Gateway配置中，遵循"单一通配符Gateway"的最佳实践可以避免许多路由问题。Holos项目通过优化Gateway配置，解决了子域名访问导致主域名404的问题，提高了系统的可靠性和用户体验。这一实践也为其他使用Istio的项目提供了有价值的参考。

holos Holistic platform manager 项目地址: https://gitcode.com/gh_mirrors/hol/holos