译者|康绍景策划|YunZhao在众多的NoSQL存储中，Cassandra是最受企业和开发者欢迎的选择之一。它使用AmazonDynamo引入的架构特性来支持BigTable数据模型。优点非常明显：高扩展性和高可用性、无单点故障的NoSQL列族实现、非常高的写入吞吐量和良好的读取吞吐量、二级索引支持搜索、可调一致性、灵活的复制支持模式等。另外，它还实现了在Kubernetes集群中运行数据库（或其他应用程序）的一个非常棘手的问题，这里供大家参考。全球应用程序需要一个与其服务的用户一样分布式的数据层，而ApacheCassandra在这方面做得很好，目前可以处理Apple、Netflix和Sony等公司的数据需求。传统上，分布式应用程序的数据平面管理有专门的团队来管理数千个节点（本地和云端）的部署和操作。为了减轻DevOps团队的大部分负担，我们在K8ssandra中开发了许多这样的实践和模式，利用Kubernetes(K8s)提供的公共控制区域。但是，有一个问题是，如果没有适当的关注和预先计划，跨多个区域或K8s集群运行数据库（或与此相关的任何应用程序）是很棘手的。为了向您展示这是如何在此处完成的，我们将从查看在单独的K8s集群上运行的单区域K8ssandra部署开始。它由分布在区域内三个可用区的六个Cassandra节点组成，每个可用区中有两个Cassandra节点。在此示例中，我们将使用GoogleCloudPlatform(GCP)区域名称。然而，这里的示例同样适用于其他云，甚至在线云。这就是我们现在所处的位置：云数据库的现有部署针对两个区域，每个区域都有一个Cassandra数据中心。在我们这里的云管理K8s部署中，这转化为两个K8s集群——每个都有一个单独的控制平面，但使用一个公共的虚拟私有云(VPC)网络。通过将Cassandra集群扩展到多个数据中心，我们在区域中断的情况下获得冗余，并在本地访问数据时改善客户端应用程序的响应时间和延迟。这是我们的目标：拥有两个区域，每个区域都有自己的Cassandra数据中心。从表面上看，我们似乎可以通过简单地启动另一个部署相同K8sYAML的K8s集群来实现这一点。然后对可用区名称添加一些调整，我们就完成了，对吧？最终，这些资源具有非常相似的形状，都是K8s对象。那么，这不应该起作用吗？或许。根据您的环境，此方法可能有效。如果不使用完全分布式的数据库部署，就会避免很多问题。但不幸的是，事情很少那么简单。即使其中一些障碍很容易消除，还有许多其他无害的事情可能会出错并导致状态下降。你选择的云提供商、K8s发行版、命令行标志，是的，甚至是DNS——这些都会让你陷入黑暗的深渊。因此，让我们探讨一下您可能会遇到的一些最常见的问题，以避免出现这种情况。常见障碍即使您的某些部署开始时很好，但随着您发展到多云环境、升级到另一个K8s版本或开始使用不同的发行版和免费工具，您可能会遇到一两个障碍。当涉及分布式数据库时，它具有更多低级功能。了解K8s如何在一系列硬件上运行容器将有助于开发高级解决方案——最终将满足您的确切需求。Cassandra节点需要唯一的IP地址您可能遇到的第一个障碍涉及基本网络。回到我们的第一个集群，让我们看一下涉及的网络层。在下面显示的VPC中，我们有一个无类域间路由(CIDR)范围，代表K8s工作实例的地址。在K8s集群范围内，有单独的地址空间用于操作Pod和运行容器。Pod是共享某些资源（如存储、网络和进程空间）的容器集合。在某些云环境中，这些子网绑定到特定的可用区。因此，K8sworker启动到的每个子网可能都有一个CIDR范围。VPC中可能还有其他虚拟机，但在这种情况下，我们将坚持使用K8s作为唯一租户。VPC与K8s层使用的CIDR范围在我们的例子中是节点的10.100.x.x和K8s层的10.200.x.x。每个K8sworker都会获得10.200.x.x的一部分，这是在该单个实例上运行的Pod的CIDR范围。回想一下我们的目标结构，如果两个集群使用相同或重叠的CIDR地址范围会怎样？当您第一次接触网络时，您可能还记得这些错误消息：尝试连接两个网络时的常见错误消息K8s错误看起来不像这样。不会弹出集群无法有效通信的警告。如果您有一个具有IP空间的集群和另一个具有相同IP空间或重叠位置的集群，那么每个集群如何知道特定数据包何时需要离开其自己的地址空间并通过VPC网络路由到另一个集群，以及然后进入该集群的网络？通常，这里没有提示。有办法解决这个问题；但在高层次上，如果你有重叠，你就是在自找麻烦。这里的重点是你需要了解每个集群的地址空间，然后仔细规划那些IP的分配和使用。这允许Linux内核（K8s路由发生的地方）和VPC网络层根据需要转发和路由数据包。但是，如果您没有足够的IP怎么办？在某些情况下，您无法为每个pod提供自己的IP地址。所以在这种情况下，你需要退后一步，确定哪些服务绝对必须有唯一的地址，哪些服务可以在同一个地址空间中一起运行。例如，如果您的数据库需要能够与每个其他pod通信，它可能需要自己的唯一地址。但是，如果东海岸和西海岸的应用层只是与本地数据层通信，则它们可以拥有自己专用的具有相同地址范围的K8s集群以避免冲突。扁平化网络在我们的参考部署中，我们将K8s集群中的非重叠范围专用于基础设施层，该层必须是唯一的并且重叠服务不通信的CIDR范围。最终，我们在这里所做的是扁平化网络。有了不重叠的IP范围，数据包现在可以继续路由到每个集群中的pod。在上图中，您可以看到西海岸是10.100，东海岸是10.150，K8spod从这些范围接收IP。K8s集群有自己的IP空间，200vs250，pod和之前一样拆分。如何处理Cassandra数据中心之间的路由我们有一堆IP地址，我们对这些地址具有唯一性。现在，我们如何处理这些数据的路由以及所有这些的通信和发现？发往集群A的数据包无法知道它们需要如何路由到集群B。当我们尝试跨集群边界发送数据包时，本地Linux网络堆栈会发现这不是该主机或内部任何主机的本地数据包本地K8s集群，并将数据包转发到VPC网络。从这里开始，我们的云提供商必须有一个路由表条目来知道这个数据包需要去哪里。在某些情况下，这是开箱即用的。VPC路由表使用pod和服务CIDR范围进行更新，以告知应路由哪些主机数据包。在其他环境中，包括混合和本地环境，这可能采取通过BGP将路由通告到网络层的形式。雅虎！日本有一篇很棒的文章描述了这种确切的部署方法。但是，这些选项可能并不总是最佳答案，具体取决于您的多集群架构在单个云提供商中的样子。它是混合云还是多云，结合本地和两个不同的云提供商？虽然您当然可以在所有这些不同的环境中检测到这些，但您可以指望它需要大量时间和维护。考虑覆盖网络的一些解决方案一个更简单的答案是使用覆盖网络，您可以在其中为您的应用程序构建一个单独的IP地址空间——在本例中为Cassandra数据库。然后，您可以使用代理、边车和网关在现有的Kube网络上运行它。在这篇文章中，我们不会深入探讨，但我们有一些关于如何跨K8s集群连接有状态工作负载的重要内容，这些内容将向您展示如何在高层次上做到这一点。下一个是什么？数据包在流动，但现在有一些新的K8s技巧需要处理。假设您已经准备好您的网络并且所有路由都已到位，那么在IP层这些集群之间至少有一些连接。您有IP连接的Pod，集群1可以与Pod和集群2通信，但您现在需要考虑一些新的东西。服务发现在K8s网络中，身份是短暂的。由于集群事件，Pod可能会被重新安排并接收新的网络地址。在某些应用程序中，这不是问题。在其他情况下，比如数据库，网络地址就是身份——这可能会导致意外行为。虽然IP地址可能会发生变化，但我们的存储和每个pod代表的数据会随着时间的推移保持不变。我们必须有一种方法来维护地址到应用程序的映射。这就是服务发现的用武之地。在大多数情况下，服务发现是通过DNS在K8s中实现的。即使pod的IP地址可能会更改，它也可以具有一个基于DNS的持久身份，该身份会在集群事件发生时更新。这听起来不错，但是随着我们进入多集群世界，我们必须确保我们的服务可以跨集群边界被发现。作为集群1中的一个pod，我应该能够获得集群2中的pod的地址。DNS存根解决这个难题的一种方法是DNS存根。在此配置中，我们配置K8sDNS服务以将对特定域后缀的请求路由到远程集群。有了一个完全合格的域名，我们就可以将DNS查找请求转发到适当的集群进行解析和最终路由。这里的问题是每个集群都需要通过kubelet标志设置单独的DNS后缀，这在所有K8s中都不是一个选项。一些用户通过使用命名空间名称配置存根作为FQDN的一部分来解决此问题。这可行，但有点hack，没有正确设置集群后缀。托管DNS另一种类似于DNS存根的解决方案是使用托管DNS产品。就GCP而言，有CloudDNS产品可将本地DNS条目复制到VPC级别，供外部集群甚至同一VPC内的虚拟机解析。此选项提供许多好处，包括：消除管理集群托管DNS服务器的开销-CloudDNS不需要扩展、监控或管理DNS实例，因为它是一项托管的Google服务。在每个GoogleK8s引擎(GKE)节点上本地解析DNS查询——类似于NodeLocalDNSCache，CloudDNS在本地存储DNS响应以提供低延迟和高可扩展性的DNS解析。与GoogleCloud的操作套件集成-提供DNS监控和日志记录。VPC-wideDNS——提供多集群、多环境、VPC-wideK8s业务解析。用于多集群服务发现的复制托管DNSCloudDNS抽象掉了大部分传统开销。云提供商将管理可扩展性、监控和安全补丁，以及您期望从托管产品中获得的所有其他方面。对于某些供应商，GKE还提供节点本地DNS缓存，它通过在较低级别运行DNS缓存来减少延迟，因此您不必等待DNS响应。从长远来看，如果您只在一个云中，专用于DNS的托管服务就可以正常工作。但是，如果您的集群跨越多个云提供商和本地环境，托管产品可能只是解决方案的一部分。云原生计算基金会https://www.cncf.io/(CNCF)提供了多种选择，并且有大量的开源项目在帮助缓解这些痛点方面取得了长足的进步，尤其是跨云、多-云或混合云类型的场景。译者介绍康少京，社区编辑，目前从事通信行业，从事底层驱动开发岗位，学过数据结构，Python，现对操作系统、数据库等相关领域感兴趣。原标题：TakingYourDatabaseBeyondaSingleKubernetesCluster，作者：ChristopherBradford链接：https://dzone.com/articles/taking-your-database-beyond-a-single-kubernetes-cl
