在AWS EKS上部署UDS Core时解决SSO重定向问题

在AWS EKS上部署UDS Core时解决SSO重定向问题

uds-core A secure runtime platform for mission-critical capabilities 项目地址: https://gitcode.com/gh_mirrors/ud/uds-core

背景介绍

在AWS EKS(Kubernetes 1.32)环境中部署UDS Core时，开发者遇到了单点登录(SSO)重定向问题。具体表现为当访问podinfo.domain.name时，系统会重定向到sso.domain.name，但返回503服务不可用错误，提示"upstream connect error or disconnect/reset before headers. reset reason: connection termination"。

问题分析

这个问题主要涉及AWS EKS环境中负载均衡器类型的选择对Istio服务网格的影响。默认情况下，UDS Core部署使用ALB(应用负载均衡器)，但ALB会终止TLS连接，而不是将TLS连接透传给Istio，这导致了SSO重定向失败。

解决方案

通过修改uds-bundle.yaml配置文件中的负载均衡器类型可以解决此问题：

1. 将aws-load-balancer-type注解的值从"external"改为"nlb-ip"
2. NLB(网络负载均衡器)会保持TLS连接的完整性，将加密流量直接传递给Istio

技术细节

为什么ALB会导致问题

ALB工作在OSI模型的第7层(应用层)，它会：

• 终止TLS/SSL连接
• 解析HTTP/HTTPS流量
• 执行基于路径或主机的路由

这种特性使得ALB不适合需要端到端加密的场景，特别是当服务网格(如Istio)需要处理原始TLS流量时。

NLB的优势

NLB工作在OSI模型的第4层(传输层)，它：

• 保持TLS连接的完整性
• 不检查或修改应用层数据
• 提供更高的吞吐量和更低的延迟
• 支持源IP保持

这些特性使其成为服务网格入口控制器的理想选择。

实施建议

对于在AWS EKS上部署UDS Core的用户，建议：

1. 在部署前明确网络架构需求
2. 对于需要服务网格功能的场景优先选择NLB
3. 监控负载均衡器的性能指标，必要时调整配置
4. 考虑使用NLB的IP模式("nlb-ip")以获得更好的兼容性

总结

在云原生环境中，负载均衡器的选择会直接影响服务网格功能的正常运行。通过将ALB替换为NLB，成功解决了UDS Core在AWS EKS上的SSO重定向问题。这个案例也提醒我们，在复杂的基础设施环境中，理解各组件的工作层次和交互方式对于问题排查至关重要。

uds-core A secure runtime platform for mission-critical capabilities 项目地址: https://gitcode.com/gh_mirrors/ud/uds-core