使用 Kubernetes 实现异构部署模式

本文介绍使用 Kubernetes 创建生产级异构部署的常见模式。本文回顾了三个用例,并介绍了可用于为其创建部署的架构的详细信息。架构介绍包括关于 Kubernetes 的总体介绍,以及关于 Google Kubernetes Engine (GKE) 的具体介绍。

异构部署

异构部署通常涉及连接两个或多个不同的基础架构环境或区域,以满足特定的技术或运营需求。根据部署的具体情况,异构部署可分为“混合”、“多云”和“公私”部署。就本文而言,异构部署包括跨单个云环境、多个公有云环境(多云),或本地和公有云环境(混合或公私)组合的区域的部署。

仅限于单一环境或区域的部署中可能会存在各种业务和技术挑战:

  • 有限的资源:在任何单一环境中,尤其是在本地环境中,您可能没有充足的计算、网络和存储资源来满足生产需求。
  • 有限的地理覆盖范围:单一环境中的部署要求地理位置相距较远的人员访问同一个部署。他们的流量可能会途经世界各地再抵达中心位置。
  • 有限的可用性:Web 级的流量模式要求应用保持容错性和弹性。
  • 供应商锁定:供应商级层的平台和基础架构抽象可能会妨碍您移植应用。
  • 不够灵活的资源:您的资源可能仅限于一组特定的计算、存储或网络服务。

异构部署可以帮助应对这些挑战,但必须使用程序化和确定性流程和过程进行构建。一次性或临时部署过程可能导致部署或流程变得脆弱且不耐故障。临时流程可能会丢失数据或使流量下降。良好的部署流程必须是可重复的,并使用经过验证的方法来管理预配、配置和维护。

异构部署的三种常见场景为多云部署、前置本地数据以及持续集成/持续交付 (CI/CD) 流程。

以下部分介绍了异构部署的一些常见使用场景,以及使用 Kubernetes 和其他基础架构资源的结构良好的方法。

多云

所有部署都较为相似的多云部署是 Kubernetes 使用的一些最常见的异构部署模式。

多云部署的一个用途为选择流量的定向方式。在最简单的部署中,您可以选择将特定百分比的入站流量发送到特定部署。在使用本地和公有云基础架构构建的部署中,您可以向云端基础架构发送更多流量,以简化长期迁移或绕过受限制的本地资源。

多云部署的另一个常见用途是配置能够应对任何单一环境故障的高可用性部署。在这些场景中,您可以将相同的 Kubernetes 部署编排到每个所需的环境中。如果任意一个环境出现故障,每个部署都应该能够扩充以满足所有流量的需求。

最后,您可以使用多云部署来创建在地理上更靠近用户的部署。尽可能将部署放置在用户附近可以最大限度地缩短请求和响应延迟时间。

定向流量

强大的多云部署使用 DNS 流量管理服务来解析对各个部署的 DNS 查询。对于常规的流量拆分使用场景,您可以配置 DNS 流量管理机制,以按百分比拆分各个部署的流量。

拆分流量

对于高可用性部署,您可以使用每个环境中的自定义运行状况检查来配置 DNS 机制。当环境运行状况不佳时,它会停止发送良好状态更新,并且 DNS 机制可以将流量转移到运行状况仍然良好的部署。

当延迟时间对用户至关重要时,DNS 机制可以使用入站请求的 IP 地址来确定其大致位置,然后将流量定向到最靠近该地理区域的部署。您可以使用 DNS 基础架构服务提供商(如 NS1DynAkamai 等)来跨多个部署引导流量。

处理请求

当 DNS 将流量定向到特定部署时,负载平衡器应接收传入请求,然后将它们定向到 Kubernetes 集群。Kubernetes 提供了两种将 pod 提供给传入流量的机制,即服务Ingress

当 pod 部署于 Kubernetes 集群中时,集群内部或外部的其他应用或系统便无法轻易访问它们。要使 pod 可被访问,必须先创建服务。默认情况下,服务会自动接受来自集群内部的连接,但也可以将其配置为接受来自集群外部的连接。

配置服务以接受外部请求时,请将服务类型配置为 NodePortLoadBalancer

将服务类型设置为 NodePort 会为 Kubernetes 集群中所有节点上的每个服务公开一个唯一端口。此唯一端口允许每个节点接受连接并将负载平衡传入请求代理到相应的 pod。

LoadBalancer 服务类型是 NodePort 的超集。除了在每个节点上提供端口配置之外,将类型设置为 LoadBalancer 还会自动预配外部负载平衡器并对其进行配置,以将流量定向到集群和后续 pod。

Kubernetes 中的服务为第 4 层结构,这意味着它们只能通过使用 IP 地址和端口号来进行访问。Ingress 是一种 HTTP(S)(第 7 层)负载平衡机制,是一组允许入站连接到达后端 Kubernetes 集群服务的规则。您可以配置 Ingress 机制,以便为服务提供其他应用层功能,例如外部可访问的网址、入站流量负载平衡、SSL 终止或基于名称的虚拟托管。可以使用 HTTP 主机头或 HTTP 网址路径将入站流量定向到通过服务公开的 pod。

定向到 pod 的流量

共享服务

运行多云部署时,可能需要在每个部署中运行一个或多个共享服务,例如数据库。共享服务之间的通信需要低延迟且安全可靠。

对于低延迟、高带宽的连接,您可以使用直接对等互连或第三方托管网络互连来连接每个部署中的底层网络。GCP 通过在任何一个可用的网络边缘位置与 Google 直接对等互连来提供直接连接。为使直接对等互连更方便,有许多技术要求需要满足。如果无法满足这些要求,您可以采用 Cloud Interconnect。使用 Cloud Interconnect 服务提供商可以通过企业级连接来连接 Google 的网络边缘。

连接完成后,下一步是使用 VPN 保护每个环境之间的链接。在每个部署中,您都需要使用 VPN 网关来保护部署之间的流量。在 GCP 中,Cloud VPN 使用 IPSec VPN 连接来保护流量。Cloud VPN 支持多个 VPN 隧道来聚合带宽,它支持使用 Cloud Router 进行静态或动态路由。

集群管理

在多云部署中,您可能希望将每个 Kubernetes 集群作为单个实体进行管理和控制。为此,您必须在每个集群中手动创建 pod 和服务。这样做的好处是,虽然每个部署可能都有一些共享应用和服务,但它也可能拥有仅适用于自身的应用和服务。

例如,您可能需要根据地理位置分布部署,但可能有一些特定于国家或地区的服务并不适用于所有地理位置。

流量拆分分布不均匀的部署可能需要基于每个集群部署 pod 和服务,以确保正确处理传入流量和请求。

服务发现

多云部署应使用服务发现来确保不同应用和服务能够在运行时轻松找到彼此。服务发现消除了在部署前可能必须了解的复杂或脆弱命名方案或惯例的需要。服务发现机制需要对源应用和目标应用保持透明。在多云部署中,这些机制必须使应用和服务能够发现其他集群中在本地和远程运行的服务。

在作为独立的单个集群构建和部署的部署中,服务发现机制需要能够识别数据中心。也就是说,它们必须能够作为协调的分布式系统运行,并能够根据传入请求、本地可用性和负载容量将请求发送到适当的集群。诸如 ConsulLinkerd 等第三方系统可以通过多云 Kubernetes 部署使跨集群和跨环境的服务发现更容易实现。

Kubernetes 可为解析 Kubernetes 集群中的专用 DNS 地区提供支持。此支持在混合或多云场景中非常有用,在这些场景中,其他集群的完全限定域名是已知的,并且可以轻松将流量路由到这些域名。您可以使用 ConfigMap 设置专用“存根”网域的访问权限。您可以将 Kubernetes 对解析专用 DNS 地区的支持用作一项独立机制,以向特定 Kubernetes 集群发送请求,也可以与 Consul 等外部系统一起使用。

架构

下图展示了一个示例多云部署架构。

多云部署

前置本地数据

您可以构建云端部署,以获得更多专用或本地部署不具备的功能。例如,您可以构建和部署有权访问私有数据系统或基础架构的基于云端的应用。

回想一下,专用或本地部署可能在可用性、可移植性或资源灵活性方面存在限制。迁移到基于云端的部署可以突破这些限制,但由于传统架构、安全合规性或其他软件要求,这可能无法实现。在这种情况下,您可以构建新应用并将其部署到云端环境中,从而提供比专用或本地环境更好的灵活性或更多功能。

架构

下图展示了一个示例架构,演示了前置本地数据基础架构的云应用。

前置本地数据

网络

对于云端应用前置本地数据基础架构的部署,您需要安全可靠、低延迟的连接,以最大限度地缩短用户的整体应用响应时间。您可以使用 Cloud Interconnect直接对等互连,最大限度地缩短延迟时间以及提高本地环境与云环境之间的可用带宽。建立连接后,每个部署都必须具有 VPN 网关,以保护部署之间的流量。在 GCP 中,Cloud VPN 使用 IPSec VPN 连接来保护流量。Cloud VPN 支持多个 VPN 隧道来聚合带宽,它支持使用 Cloud Router 进行静态或动态路由。由于安全性在前置本地数据基础架构时非常重要,因此您应配置路由和本地防火墙,以仅允许来自特定 GCP 实例组的流量。

云端架构

在此类混合部署的云端部分中,架构组件必须包括合适的负载平衡器、应用托管基础架构、VPN 网关以及服务发现机制。负载平衡器的选择取决于面向最终用户的应用的要求。对于 GCP 上的部署,Cloud Load Balancing 可通过单个全球可用的 Anycast IP 提供对 HTTP(S)、TCP 和 UDP 的支持。

在诸如此类的混合场景中,您可以在 GKE 上部署 pod 和服务。GKE 是 GCP 中可用的托管 Kubernetes 部署,可将出站流量定向到本地基础架构。GKE 使用 Cloud VPN 保护流量,并使用 Cloud Router 配置静态或动态路由。此配置可确保只有来自 GKE 集群的流量才能遍历 VPN 连接。

本地架构

此类部署的本地部分包含支持云端应用的数据基础架构。对于此类性质的大多数部署,在数据系统前部署 CRUD API 具有多种优势。

如果数据系统需要高安全性或合规性,则 CRUD API 可用于帮助审核和记录入站连接和查询。如果数据基础架构在旧系统上运行,则 CRUD API 有助于为更新的应用提供更现代的连接选项。

在这两种情况下,CRUD API 都有助于将内置数据库身份验证和授权机制与应用所需的机制分离,并且只提供应用所需的 CRUD 功能。具体而言,如果只需要将一部分数据公开给下游应用,则 API 可用于管理对数据的访问。

通过审核连接和查询,API 还有助于定义底层数据的长期迁移策略。如果只需要一部分数据,并且该数据不受严格的安全性或合规性政策限制,则可以将该数据迁移到云端平台。

上面的架构图展示了在本地运行的 Kubernetes 中托管的 CRUD API。从技术上来讲,在本地使用 Kubernetes 并不是必需的,但却可以带来以下优势:随着越来越多的团队将 Kubernetes 视为云端基础架构中的部署目标,他们可以在使用和操作该系统时拓展专业知识,从而受益。

本地基础架构必须配置 VPN 网关和防火墙,以仅允许来自已知来源的流量到达 CRUD API,从而最大限度地减少潜在的安全问题。

服务发现

在混合部署场景中,您应使用服务发现来确保不同应用和服务能够在运行时轻松连接彼此。随着时间的推移,系统可能会部署其他云端应用,这些应用利用本地 CRUD API 的不同组件。CRUD API 可能会随着时间的推移添加其他功能,例如特定于任务的 API 或支持其他本地数据基础架构的 API。在这些类型的部署场景中,云端应用与本地 CRUD 功能的发布周期可能会有很大差异。您可以使用外部服务发现机制(例如 ConsulLinkerd)提供资源和版本的松散耦合,以便它们在每个环境中独立迭代。

如果您计划仅在 GKE 或 Kubernetes 中部署云端应用,则可以配置内部 Kubernetes DNS 机制 kube-dns 以将专用 DNS 网域解析为本地环境中的专用 IP 地址。在该配置中,运行于云端环境中的 pod 可以使用标准 DNS 查询轻松访问在本地环境中运行的服务。如需了解详情,请参阅在 Kubernetes 中配置专用 DNS 地区和上游域名服务器

CI/CD 工作负载

从现有本地部署起步的多云工作负载能够受益于将更集中的工作负载迁移到云端环境这一过程。

持续集成 (CI) 工作负载是迁移的理想选择,因为云端环境自动扩充计算资源的能力有助于缩短从代码补全到构建工件的时间。

持续交付 (CD) 工作负载也可以受益于在云端环境中运行,这使得测试环境的预配和部署更容易。迁移可以增加单元测试的并行构建流程的数量。另一个潜在的好处是增加了端到端集成测试和其他自动化测试的测试部署数量。

基于云端、以容器为中心的 CI/CD 工作负载通常采用以下高级流程:

  • 开发。 开发者提交代码更改并将其推送到本地或远程托管的源代码库。
  • 构建。 构建服务不断轮询源代码库。在看到新的更改后,该服务将启动构建流程。
  • 单元测试。此流程构建源代码、执行单元测试,并构建生成的容器映像。
  • 集成测试。此流程创建测试集群、使用其关联的工件部署容器映像,并执行集成测试。
  • 烘焙。 成功完成此流程后,容器映像将标记为发行版本元数据。
  • 部署。 (可选)开发者或管理员可以将新工件部署到生产环境中。

用例

最常用于 GCP 的 CI/CD 工具是 JenkinsSpinnaker。Jenkins 是一个热门开源 CI/CD 系统,可以部署在独立的计算实例上,也可以部署在 Kubernetes 的一系列 pod 和服务中。Spinnaker 是一个开源 CD 系统,能够编排和自动化软件交付到多个目标。Spinnaker 可以利用 Jenkins 等 CI 系统或 Cloud Build 等其他工具。

Jenkins 和 Kubernetes

对于使用 Jenkins 和 Kubernetes 的 CI/CD 工作负载,请参阅以下文档,其中介绍了最佳做法、常见配置模式和持续交付编排:

Spinnaker

Spinnaker 是一个开源多云 CD 平台,可以编排软件部署工作流和集群管理。Spinnaker 的集群管理功能提供了预配和控制云端资源(如实例组、实例、防火墙和负载平衡器)的功能。软件部署工作流由流水线组成,每个流水线由一系列操作组成,称为“阶段”。Spinnaker 流水线中的一个阶段可以将参数传递给下一个阶段。流水线可以手动启动,也可以通过自动触发器启动,例如外部 CI 系统、cron 脚本或其他流水线。Spinnaker 集成了几个预封装的阶段,用于烘焙映像、部署映像,使用实例组以及请求用户输入。下图介绍了 Spinnaker 流水线如何发布软件。

Spinnaker 流水线

软件需要先进行构建,然后进行测试。如果通过了所有测试,则会烘焙不可变映像并使其在云端可用。映像可用后,可以将其部署到集群以更新其运行中的软件。

架构

使用容器部署时,Spinnaker 利用 Jenkins 或 Cloud Build 等外部 CI 系统来执行构建、测试和烘焙步骤。然后,Spinnaker 使用标准流水线阶段来编排目标部署。下图展示了此类系统的架构。

Spinnaker 和 Jenkins

如需了解如何在 GCP 上部署 Spinnaker,请参阅在 Compute Engine 上运行 Spinnaker

使用 Jenkins 进行构建

Jenkins 与 Spinnaker 对触发器启动流水线的支持非常契合。您可以使用 Jenkins 构建来自动触发 Spinnaker 流水线。在 Spinnaker 流水线中,Jenkins 脚本阶段可以执行发布流程的测试和烘焙阶段。Spinnaker 的内置集群管理阶段可以编排目标部署。如需了解详情,请参阅 Spinnaker Hello Deployment 示例。

使用 Cloud Build 进行构建

Cloud Build 是一个全托管式 GCP 服务,可在快速、一致且可靠的环境中构建容器映像。Cloud Build 与 Cloud Source Repositories 直接集成,可根据源代码或代码库标记的更改自动触发构建。Cloud Build 在 Docker 容器中执行构建,并且支持能够在容器中打包的任何自定义构建步骤。Cloud Build 中的构建可深度自定义,支持步骤排序和并发。构建流程中的阶段更改会自动发布到 Cloud Pub/Sub 主题。

虽然 Spinnaker 不直接支持 Cloud Build,但它可为 Container Registry 提供支持,Container Registry 是 Cloud Build 自动使用的容器注册代码库。您可以配置 Spinnaker 以轮询 Container Registry 并根据检测更新的容器映像版本或标记来启动流水线。在这种情况下,您应该配置 Cloud Build 以执行发布流程的构建、测试和烘焙阶段。如需详细了解如何配置 Spinnaker 以使用 Container Registry,请参阅 Spinnaker 文档

编排 Kubernetes 部署

Spinnaker 的内置集群管理机制支持 Kubernetes。Spinnaker 中的服务器组和负载平衡器分别对应于 Kubernetes 中的副本集和服务。

以下文档介绍了配置 Spinnaker 以将 Pod 和服务部署到 Kubernetes 所需的步骤:

后续步骤

  • 亲自试用其他 Google Cloud Platform 功能。查阅我们的教程
此页内容是否有用?请给出您的反馈和评价:

发送以下问题的反馈:

此网页
Solutions