《Kubernetes 最佳实践》第二版

第 7 章 全球应用分布与分期 全球应用分布和分期

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

在本书的这一部分，我们已经了解了构建、开发和部署应用程序的许多不同实践，但在部署和管理具有全球影响的应用程序时，会出现一系列完全不同的问题。

应用程序需要扩展到全球部署有许多不同的原因。第一个也是最明显的一个原因就是规模问题，因为您的应用程序可能非常成功，或者任务非常关键，所以需要在全球范围内部署，以便为用户提供必要的容量。这类应用的例子包括公共云提供商的全球 API 网关、足迹遍布全球的大型物联网产品、非常成功的社交网络等等。

虽然我们中很少有人会建立需要全球规模的系统，但更多的应用需要全球范围的延迟。即使使用容器和 Kubernetes，也无法绕过光速。为了最大限度地减少客户与应用程序之间的延迟，有时有必要将应用程序分布到世界各地，以最大限度地减少应用程序与其用户之间的物理距离。

最后，全球分布的一个更常见的原因是地域性。 无论是出于带宽（如遥感平台）还是数据隐私（如地理限制）的原因，有时都需要在特定地点部署应用程序，这样才能使应用程序成为可能或取得成功。随着越来越多的国家和地区实施数据隐私和主权法律法规，在特定地点部署应用程序为居住在该地点的用户提供服务已成为一种普遍的业务需要。

在所有这些情况下，您的应用程序不再仅仅存在于少数几个生产集群中。相反，它分布在数十到数百个不同的地理位置。对这些地点的管理，以及推出全球可靠服务的要求，都是一个巨大的挑战。本章将介绍成功实现这一目标的方法和实践。

发布您的图像

之前，您甚至可以考虑在全球运行您的应用程序，您需要让位于全球各地的集群都能使用该镜像。首先要考虑的是您的镜像注册中心是否具有自动地理复制功能。云提供商提供的许多图像注册中心会自动将您的图像分发到世界各地，并将对该图像的请求解析到距离您从中提取图像的集群最近的存储位置。许多 Cloud 使您能够决定要在哪里复制镜像；例如，您可能知道一些您不会出现的地点。Microsoft Azure 容器注册中心就是此类注册中心的一个例子，其他注册中心也提供类似的服务。如果使用云提供的支持地理复制的注册表，在全球分发镜像就很简单。您只需将镜像推送到注册中心，选择地理分配的区域，注册中心就会处理剩下的工作。

如果您没有使用 Cloud 注册表，或者您的提供商不支持图像的自动地理分配，您就需要自己解决这个问题。一种方法是使用位于特定位置的注册中心。这种方法有几个值得关注的问题：映像拉取延迟通常决定了在集群中启动容器的速度。这反过来又会决定您对机器故障做出响应的速度，因为通常在机器故障的情况下，您需要将容器映像拉到新的机器上。

单一注册表的另一个问题是，它可能成为单点故障。如果注册表位于单一地区或单一数据中心，那么注册表就有可能因该数据中心发生大规模事故而离线。如果注册中心离线，您的 CI/CD 管道将停止工作，您将无法部署新代码。这显然会对开发人员的工作效率和应用程序的运行产生重大影响。此外，单个注册表的成本可能会更高，因为每次启动新容器时都会占用大量带宽，即使容器映像一般都比较小，带宽也会增加。尽管存在这些不利因素，但对于仅在全球少数地区运行的小规模应用程序来说，单一注册表解决方案可能是合适的解决方案。当然，它比全面镜像复制更易于设置。

如果您无法使用 Cloud 提供的地理复制服务，而又需要复制图像，那么您就需要自行设计一个图像复制解决方案。要实施这种服务，您有两种选择。第一种是为每个图像注册中心使用地理名称（如 ...