Google拥有]这个很酷的工具kubemci-Command line tool to configure L7 load balancers using multiple kubernetes clusters，您基本上可以使用它进行HA多区域Kubernetes设置。哪个很棒。
但是，我们有这样的基本架构：
所以我可以在GKE上创建两个Kubernetes集群，将后端和前端都放在它们上（例如在伦敦和比利时），并且一切都很好。
直到我们考虑数据库。 PostgreSQL仅是单主机，因此必须仅放置在其中一个区域中。而且，如果伦敦地区的后端开始与比利时地区的PostgreSQL对话，那么考虑到这些地区之间的6ms +延迟，性能将真的很差。
这样整个HA设置没有任何意义吗？还是我错过了什么？一种稍微缓解该问题的方法是在“ slave”区域中有一个只读副本，并在那里直接进行只读查询（PostgreSQL甚至可以吗？）
答案 0 :(得分：2)
这是经典的架构方案，没有简单的解决方案。在多个地区提供数据是一个具有挑战性的问题，大型公司要花费大量时间和金钱来解决。
PostgreSQL本身不支持多主写。您的想法是将副本放在其他区域，并在您的应用中使用逻辑来读写正确的数据库。这将为您提供快速的本地读取，但在一个区域中的写入速度较慢。应用程序中的代码也更加复杂，需要进行更多工作来处理主服务器的故障转移。带宽和成本也可能是大量更新的问题。
使用多方Postgres的第三方解决方案（例如Postgres-BDR by 2nd Quadrant）将工作分流到数据库层。这可能会很昂贵，并且您的应用程序仍必须管理两个区域中同时覆盖相同数据的数据冲突。
选择另一个支持多主复制的多区域复制的数据库。 Cassandra（或ScyllaDB）是不错的选择，也可以是Google Spanner，Azure CosmosDB，AWS DynamoDB Global Tables等托管选项。一个有趣的选项是CockroachDB，它支持PostgreSQL协议，但它是可伸缩的关系数据库，并且支持多个区域。
如果这些选项都不起作用，则必须创建自己的复制系统。一些公司使用事件源/ CQRS架构来执行此操作，其中每次写入都是将消息发送到中央日志，然后应用于每个位置。这是一项更多的工作，但提供了最大的灵活性。此时，您基本上还正在构建自己的数据库复制系统。
答案 1 :(得分：-2)
如果您在不同区域的两个集群上设置了multi cluster ingress，则多集群入口只会将流量发送到用户最近的区域。
如果最近的区域出现故障，则这是将流量路由到其他区域中的群集的时间。
因此，使用您提供的示例，如果有流量发送到后端并且该用户离伦敦较近，则只要该区域启动并运行，该用户发送的流量将始终发送到伦敦。
关于延迟，在这种情况下，您将不得不处理延迟，因为您无法在另一个区域内创建只读副本。
此功能（多集群入口）的好处是，如果一个区域出现故障，那么您将有另一个区域将流量路由至。