区域之间的 Kubernetes 入口控制器代理请求答案

【问题标题】：Kubernetes ingress controller proxy requests between regions区域之间的 Kubernetes 入口控制器代理请求
【发布时间】：2022-07-17 22:20:45
【问题描述】：

traefik / traefik 网格是否可以处理多区域架构来解决对正确用户区域的请求？

还有其他自托管解决方案推荐吗？

规则：

每个区域都是独立的，一个区域的停机时间不会影响其他区域
跨所有区域复制用户身份验证元数据
带有身份验证令牌的请求可以从任何区域进入网络并被验证
身份验证请求的默认入口点是 usa-region-1
入口控制器/服务网格确定用户是谁以及他们的帐户托管在哪个区域
身份验证服务将 \"user_region\" 标头添加到请求和 \"precedence_region\" 以防止内部循环
检测到目标区域不是当前区域，并将请求代理到添加了额外标头的正确区域

图表：

                                   ┌───────────────────────────────────────────────┐
                                   │                                               │
                                   │ usa-region-1                                  │
                                   │                                  ┌───►/app-1/*│
                                   │                                  │            │
                               ┌───┼──► Load  ──────► ┌── Ingress ────┤            │
                               │   │   Balancer       │ Controller    ├───►/app-2/*│
                               │   │                  │     │         │            │
                               │   │                  │     │         │            │
                               │   │                  │     │         └───►/app-3/*│
                               │   │                  │     │                      │
                               │   │                  │     │                      │
                               │   │                  │     └─Authentication       │
 User──────► Cloudflare ──────►│   │                  │          Service           │
Request                        │   │                  │                            │
                               │   └──────────────────┼────────────────────────────┘
                               │                      │ *proxie the request*
                               │   ┌──────────────────┼────────────────────────────┐
                               │   │                  │                            │
                               │   │ europe-region-1  │                            │
                               │   │                  │               ┌───►/app-1/*│
                               │   │                  │               │            │
                               └───┼──► Load ───────► └── Ingress ────┤            │
                                   │   Balancer         Controller    ├───►/app-2/*│
                                   │                        │         │            │
                                   │                        │         │            │
                                   │                        │         └───►/app-3/*│
                                   │                        │                      │
                                   │                        │                      │
                                   │                        └─Authentication       │
                                   │                             Service           │
                                   │                                               │
                                   └───────────────────────────────────────────────┘

您是否了解跨区域、跨区域和跨区域流量之间的延迟和成本差异？
是的，区域间的流量只会发生在尚未识别用户的请求（身份验证服务）上，之后来自用户的每个请求都将到达他们的特定区域。
您将如何确保用户在停机时请求正确的区域？
目前，停机时间会影响该地区的所有用户。未来的计划是在同一位置区域（usa-region-2，europe-region-2）拥有复制区域

标签： kubernetes kubernetes-ingress traefik self-hosting servicemesh

【解决方案1】：

本地数据存储要求

在某些市场中，将用户数据存储在其本国区域内可能存在监管原因。因此，如果欧洲用户前往美国，他们应该继续被路由到欧洲服务器，他们的数据将保留在欧洲。

基于报头的简单路由

首先，您需要在每个 HTTP 请求中添加一些内容，例如您提到的 user_region 标头。入口控制器是执行此操作的逻辑位置，而不是针对每个服务。这是Traefik header based routing example。

入口控制器中的路由

如果您需要更复杂的逻辑，则可以使用入口控制器的可扩展性功能或放置在 API 前面的专用 API 网关来编写插件。示例参见this NGINX configuration file，它根据this Lua plugin 设置目标主机名。

更多信息

这些链接也可能很有趣。特别注意如何处理unauthenticated requests，首先识别用户，然后将用户转移到他们的家庭区域，以便在那里进行身份验证。这可以允许用户的凭据仅存储在他们的家庭区域中。

【讨论】：

非常感谢您的链接，这正是我的场景

【解决方案2】：

您所描述的通常称为“全局服务器负载平衡”。虽然 Traefik 本身不支持此类功能，但可以利用它与高级 DNS 提供商结合提供全球服务器负载平衡。

在实践中，您可能希望设置基于位置的 DNS 设置，以将用户推荐到最近的 Ingress Controller，而不是在您的 Ingress Controller 之间重新路由。来自 nginx 的This article 详细介绍了如何使用 NS1 作为 DNS 提供程序设置全局服务器负载平衡，并且可以适用于 Trafik。

【讨论】：

Cloudflare 在集群前面，但我正在寻找具有多集群通信的 kubernetes ingress/mesh 解决方案。我更新了图表以更准确。