本文档旨在帮助您规划、设计和实现从 OpenShift 到 GKE Enterprise 的迁移。如果操作不当,那么将工作负载从一个环境迁移到另一个环境可能会遭遇挑战,因此请谨慎规划和执行迁移。
本文档是关于迁移到 Google Cloud 的系列文章中的一篇。如果您想要了解该系列文章,请参阅迁移到 Google Cloud:选择迁移路径。
本文档是一系列文章中的一篇,介绍了如何将容器迁移到 Google Cloud:
- 将容器迁移到 Google Cloud:将 Kubernetes 迁移到 Google Kubernetes Engine (GKE)
- 将容器迁移到 Google Cloud:从 OpenShift 迁移到 GKE Enterprise(本文档)
- 将容器迁移到 Google Cloud:将 OpenShift 项目迁移到 GKE Enterprise
- 从 OpenShift 迁移到 GKE Enterprise:将 OpenShift SCC 迁移到 Policy Controller 限制条件
如果您计划从在本地、私有托管环境或其他云服务商服务中运行的 OpenShift 迁移到 GKE Enterprise,本文档会非常有用。如果您正在评估迁移的时机并希望了解潜在的情况,本文档也可以提供帮助。目标环境可以是以下任意一种:
- 完全在 Google Cloud 上的托管环境。
- 混合环境,这种情况下,您将部分工作负载保留在本地或私有托管环境中,将其余工作负载迁移到 Google Cloud。
如需确定哪种环境符合您的需求,请先明确您的要求。例如,您可以通过迁移到公有云环境并将部分责任分包给 Google,专注于提高业务价值,而不是担心基础设施。您可以受益于弹性使用模式,从而优化支出和资源使用情况。如果您有任何要求,比如必须将某些工作负载保留在 Google Cloud 之外,则可能需要考虑使用混合环境,例如,如果您需要将部分工作负载保留在当前环境中,以符合数据位置政策和法规。或者,您可以实施改进并迁移这一迁移策略,即先原地对工作负载进行现代化改造,然后再迁移到 Google Cloud。
无论您的目标环境是哪种类型,此迁移的目标都是使用 GKE Enterprise 管理在该环境中运行的工作负载。通过采用 GKE Enterprise,您可以使用一系列服务,其中包括:
- 多集群管理,可帮助您和您的组织从一个位置集中管理整个云端和本地环境中的集群、基础设施和工作负载。
- Config Sync 和 Policy Controller,可在所有基础设施中创建通用配置和政策,并将其同时应用于本地和云端。
- Cloud Service Mesh:可采用全托管式服务网格,从而简化运营服务、流量管理、遥测操作以及保护服务之间的通信。
- Binary Authorization,可帮助确保您在环境中部署的容器受到信任。
- Knative serving,可为 GKE Enterprise 环境中的无服务器工作负载提供支持。
我们建议您在迁移过程中尽早评估这些服务,还在进行迁移设计时就要进行评估。现在,您可以更轻松地采用这些服务,无需稍后修改您的流程和基础架构。您可以立即开始使用这些服务,也可以在准备好对工作负载进行现代化改造时使用。
在此迁移中,您将按照迁移到 Google Cloud:使用入门中定义的迁移框架进行操作。 该框架包含四个阶段:
- 评估和发现工作负载。
- 规划和构建基础。
- 部署工作负载。
- 优化您的环境。
下图说明了迁移过程的路径。
本文档涉及将容器迁移到 Google Cloud:将 Kubernetes 迁移到 GKE中介绍的概念,因此会适时提供跳转到该文档的链接。
评估和发现工作负载
在评估阶段,您需要确定将工作负载从 OpenShift 迁移到 GKE Enterprise 的要求和依赖项:
- 构建流程和应用的完整清单。
- 根据流程和应用的属性和依赖项为其编制目录。
- 为您的团队开展 Google Cloud 培训和指导
- 在 Google Cloud 上构建实验和概念验证。
- 计算目标环境的总拥有成本 (TCO)。
- 选择您首先要迁移的工作负载。
以下部分依赖迁移到 Google Cloud:评估和发现工作负载,但提供了专门的信息供您用于评估要从 OpenShift 迁移到 GKE Enterprise 的工作负载。
构建您的清单
如需构建环境组件的清单,请考虑以下事项:
- 服务交付和平台管理模式
- OpenShift 项目
- 构建和部署流程
- 工作负载、要求和依赖项
- OpenShift 集群配置
服务交付和平台管理模式
如需将工作负载从 OpenShift 迁移到 GKE Enterprise,请评估 OpenShift 环境的当前服务交付和平台管理模式。此模式可能反映了您当前的组织结构和需求。如果发现当前模式无法满足组织需求,您可以借助此次迁移改进此模式。
首先,您需要收集以下几个方面负责团队的信息:
- 应用开发和部署,包括所有 OpenShift 用户,通常是开发或工作负载发布团队。
- OpenShift 平台管理,包括创建 OpenShift 项目、向用户分配角色、配置安全上下文以及配置 CI/CD 流水线。
- OpenShift 安装和集群管理,包括 OpenShift 安装、升级、集群扩缩和容量管理。
- 基础架构管理。这些团队管理物理服务器、存储空间、网络、虚拟化平台和操作系统。
服务交付和平台管理模式可以由以下团队组成:
- 开发团队。此团队负责开发工作负载并将它们部署到 OpenShift 上。处理复杂的生产环境时,部署工作负载的团队可能与开发团队不同。 方便起见,在本文档中,我们将这个团队视为开发团队的成员。在自助环境中,开发团队还负责创建 OpenShift 项目。
- 平台团队。此团队负责 OpenShift 平台管理,通常称为 OpenShift 集群管理员。该团队为不同的开发团队配置 OpenShift 项目模板,并在更多代管环境中创建 OpenShift 项目。该团队还分配角色和权限,配置安全上下文和基于角色的访问控制 (RBAC),定义计算资源和对象的配额,以及定义构建和部署策略。他们有时被称为“DevOps 团队”或“中间件团队”(如果他们为开发者管理中间件和应用服务器配置的话)。平台团队和基础架构团队可能亦参与低级别的 OpenShift 集群管理活动,例如软件安装和升级、集群扩缩以及容量管理。
- 基础架构团队。该团队负责管理支持 OpenShift 环境的底层基础架构。例如,他们负责服务器、存储空间、网络、虚拟化平台和基本操作系统。此团队有时称为“数据中心团队”或“运营团队”。如果 OpenShift 部署在公有云环境中,则此团队负责公有云服务商提供的基础架构即服务 (IaaS) 服务。
此外,请务必评估您是否针对不同的环境采用专用 OpenShift 集群。例如,您可能采用不同的环境进行开发、质保和生产,或者采用不同的环境来分隔不同的网络和安全区域,例如分隔内部区域和非军事区域。
OpenShift 项目
OpenShift 项目是一个 Kubernetes 命名空间,具有额外的注解,可让开发者独立于其他团队管理资源,从而以逻辑方式分隔资源。如需构建 OpenShift 项目的清单,请针对每个项目考虑以下方面:
- 集群角色和本地角色。OpenShift 支持 OpenShift 项目的本地角色或集群范围角色。您需要评估自己是否创建了集群和本地角色,用于在目标环境中设计有效的访问权限控制机制。
- 集群角色和本地角色的角色绑定。通过向用户和群组分配角色绑定,向他们授予对 OpenShift 项目执行操作的权限。角色可以处于集群级层或本地级层。通常而言,本地角色绑定会绑定到预定义的集群角色。 例如,默认的 OpenShift 项目管理员角色绑定可能会绑定到默认集群管理员角色。
- ResourceQuotas。为了限制总资源的消耗,OpenShift 可让您同时定义 OpenShift 项目级配额和多个 OpenShift 项目的配额。 您需要评估它们与 Kubernetes 资源配额的对应情况,并填充您在 OpenShift 环境中预配和配置的所有资源配额的列表。
评估环境介绍如何评估 Kubernetes 资源(例如 ServiceAccount 和 PersistentVolume)。
构建和部署流程
收集服务交付和平台管理模式以及 OpenShift 项目的信息后,您可以评估如何构建工作负载并将其部署到您的环境中。
在现有 OpenShift 环境中,您可能针对所有工作负载具有相同的构建和部署流程,也有可能需要评估不同的流程。容器映像是容器化工作负载构建流程的工件。在 OpenShift 环境中,您可能会构建容器映像,存储它们并以不同方式部署它们:
- 容器映像构建流程完全在 OpenShift 之外运行。 构建流程可以基于手动步骤,也可以基于将容器映像和 Kubernetes 清单作为最终产品的自动化持续集成和持续部署 (CI/CD) 流水线。
- 容器映像构建流程在 OpenShift 中运行。 OpenShift 支持不同的方案,例如提供 Dockerfile 和构建容器映像所需的所有工件,配置源代码转映像构建,配置流水线构建或配置自定义构建。 这些构建策略会创建一个 BuildConfig 资源,用于定义构建选择、来源工件位置、目标容器映像以及可触发容器映像构建流程的事件。
构建每个容器映像后,您可以将其存储在稍后可以部署的 Container Registry 中。您的 Container Registry 可以托管在 OpenShift 上,也可以托管在 OpenShift 环境之外。 请进行此方面的评估,因为您可能需要在目标环境中使用类似的系统。
工作负载、要求和依赖项
每个 OpenShift 应用都包含以下组件:
- OpenShift DeploymentConfig 或 Kubernetes Deployment 对象。如需详细了解这些对象之间的差异,请参阅比较 Deployment 和 DeploymentConfig。
- Kubernetes Service 可让客户端访问您的应用,而 OpenShift Route 用于从集群外部连接到该 Kubernetes Service。
- OpenShift ImageStream 提供引用容器映像的抽象。OpenShift ImageStream 包含一个或多个容器映像(每个容器映像都由标签标识),并显示相关映像的单个抽象视图,与容器映像存储库类似。
- OpenShift BuildConfig,用于在 OpenShift 中构建该 OpenShift 应用的容器映像。
根据应用的用途,您可以使用不同的对象来定义应用,而不是使用 Deployment 或 DeploymentConfig 对象:
- 使用 Job 或Cron 作业定义批量应用。
- 使用 StatefulSets 定义有状态应用。
- 如果您有需要在每个节点上运行或与特定节点绑定的操作相关工作负载,则可以使用 DaemonSets 对它们进行定义。
下表列出了您为了将应用迁移到目标 GKE Enterprise 环境而从 OpenShift 资源收集的最重要的规范和参数。
来源 OpenShift 资源清单 | 最重要的规范和参数 |
---|---|
Deployment、DeploymentConfig、StatementSet、Job、Cron 作业 | 容器映像和代码库、容器端口、Pod 副本数、ConfigMap、Secret、PersistentVolumeClaim、资源请求和限制、更新策略、StatefulSet 服务名称、Cron 作业时间表 |
ImageStream | 容器映像、映像拉取政策、容器映像存储库 |
Pod 横向自动扩缩器 | 自动扩缩条件 |
Service | 用于从集群内部连接到应用的主机名、IP 地址和公开服务的端口、为外部资源创建的端点 |
Route | 用于从集群外部连接到应用的主机名和资源路径、路由规则、加密、证书链信息 |
评估环境介绍如何评估 Kubernetes 资源,例如以下资源:
- 其他 Kubernetes 控制器
- 横向 Pod 自动扩缩器
- Pod 安全上下文
- 无状态和有状态工作负载
- 存储
- 配置和 Secret 注入
- Ingress
- 日志记录和监控
OpenShift 4 引入了 Operator Framework。 如果您使用的是此 OpenShift 版本,则可能已使用安装的 Operator 部署了一些应用。 在这种情况下,您将获取已安装 Operator 的列表,并为每个 Operator 收集有关已部署 Operator 实例的信息。这些实例是 Operator 定义的自定义资源,用于部署之前列出的一些 Kubernetes 资源。
除了评估这些资源之外,您还需要评估以下内容:
- 应用的网络连接要求。例如,您的 Service 或 Pod 是否需要公开给特定网络?它们是否需要访问特定的后端系统?
- 需要在特定位置运行工作负载的限制条件比如,为了符合某些要求,例如与其他工作负载通信的延迟时间要求,与数据位置相关的政策要求,以及与用户之间的距离要求,是否有需要保留在本地的工作负载或数据集?
OpenShift 集群配置
接下来,您需要评估 OpenShift 集群。为了完成此任务,请收集以下信息:
- OpenShift 版本。本文档中的 OpenShift 主要版本是 OpenShift 3 和 OpenShift 4。不同的 OpenShift 版本可能具有不同的功能。您可以评估自己正在运行的是哪个版本的 OpenShift,以便了解您是否使用的有任何 OpenShift 版本特有的特性。
- 用于身份验证的身份提供商。身份验证方面,您可能使用的是内置 OAuth 服务器以及一个或多个身份提供商。
- 安全上下文限制。评估您在集群中定义的 OpenShift 安全上下文限制、其配置以及将其分配给的用户、群组和服务账号。
- 网络政策和隔离。评估网络政策、配置 Pod 网络隔离的方式以及您在集群中配置的 OpenShift SDN 模式。
监控。评估当前的监控要求以及预配和配置当前监控系统的方法,以确定如何在目标环境中设计和实现监控解决方案。此评估可以帮助您确定是使用新的监控解决方案,还是可以继续使用现有解决方案。许多 OpenShift 版本都包含一个基于 Prometheus 的监控堆栈,用于监控系统组件,也可用于监控应用。设计目标解决方案时,请考虑以下事项:
- 您目前在 OpenShift 环境中使用的监控解决方案,例如由 OpenShift 托管的 Prometheus、独立的 Prometheus - Grafana 堆栈、Zabbix、InfluxData 或者 NagiOS。
- 如何生成和收集指标,例如拉取或推送机制。
- OpenShift 集群中部署的任何组件的依赖项。
- 您的监控系统的位置,例如部署在云环境中还是本地。
- 您当前为工作负载收集的指标。
- 您在当前的监控系统中针对指标配置的任何提醒。
日志记录。评估当前的日志记录要求以及预配和配置当前日志记录系统的方法,以确定如何在目标环境中设计和实现日志记录解决方案。此评估可以帮助您确定是使用新的日志记录解决方案,还是可以继续使用现有解决方案。许多 OpenShift 版本都附带基于 Elasticsearch、Fluentd 和 Kibana (EFK) 堆栈的日志记录解决方案,用于从系统组件收集日志。此解决方案还可用于应用日志记录。设计目标解决方案时,请考虑以下事项:
- 您当前在 OpenShift 环境中使用的日志记录系统,例如 OpenShift 托管的 EFK 堆栈,独立的 EFK 堆栈还是 Splunk。
- OpenShift 集群中部署的任何组件的依赖项。
- 日志存储组件的架构和容量。
- 您的日志记录系统的位置,例如部署在云环境中还是本地。
- 日志保留政策和配置。
评估环境介绍如何评估以下内容:
- 集群数量
- 每个集群的节点数量和类型
- 关于日志记录、监控和跟踪的其他注意事项
- 自定义 Kubernetes 资源
完成评估
构建与 OpenShift 流程和工作负载相关的清单后,请完成迁移到 Google Cloud:评估和发现工作负载中所述评估阶段的其余活动。
规划和构建基础
在规划和构建阶段,您需要预配和配置支持您的工作负载的基础架构和服务:
- 构建资源层次结构。
- 配置身份和访问权限管理。
- 设置结算功能。
- 设置网络连接。
- 强化安全性。
- 设置监控和提醒。
本部分提供的信息专用于在 GKE Enterprise 上构建基础,这些信息基于迁移到 Google Cloud:构建您的基础中所述内容。
在 Google Cloud 中构建基础之前,请阅读 GKE Enterprise 技术概览,了解 GKE Enterprise 的工作原理以及您可能需要哪些 GKE Enterprise 组件。根据您在评估阶段中收集的工作负载和数据位置要求,您可以在 Google Distributed Cloud、Google Cloud 上的 GKE 集群或 GKE on AWS 上部署工作负载。您的集群可能分布在不同的环境中。如需详细了解如何为 Google Cloud 上的 GKE 构建基础,请参阅规划和构建基础。
如需为 Google Distributed Cloud 构建基础,请了解其核心概念,然后在安装 Google Distributed Cloud 时考虑以下事项:
- 确保您的本地环境符合 Anthos GKE On-Prem 的要求。您需要在 VMware vSphere 环境中提供足够的容量,以满足管理员集群和用户集群的要求。这些要求的具体情况取决于您的工作负载资源请求数量以及您需要的集群数量。您在评估阶段对这两个方面都进行过评估。
设置网络。除了满足 Google Distributed Cloud 的安装要求之外,您还需要配置本地网络以满足评估过程中所收集的应用的网络连接要求。请考虑以下网络需求:
如需为 GKE on AWS 构建基础,请了解其核心概念,例如 GKE on AWS 架构和 GKE on AWS 存储空间。安装 GKE on AWS 时,请考虑以下事项:
- 确保您的 Amazon Web Services (AWS) 和 Google Cloud 环境满足 GKE on AWS 的要求。GKE on AWS 需要具有命令行访问权限的 (AWS) 账号和 AWS Key Management Service (KMS) 密钥(用于为集群中的应用层 Secret 加密)。您需要 Terraform 和 kubectl。
- 配置 AWS 环境。您需要配置 AWS 环境,安装工具(例如 AWS 命令行界面 (CLI)),配置 AWS IAM 凭据并在 AWS 环境中预配资源(例如 AWS KMS 密钥)。
- 配置 Google Cloud 环境。您需要配置 Google Cloud 环境,创建必要的 Google Cloud 项目和服务账号,并配置 IAM。
部署您的工作负载
在部署阶段,您将工作负载部署到 GKE Enterprise 上:
- 预配和配置您的运行时平台和环境。
- 将数据从旧环境迁移到新环境。
- 部署工作负载。
以下部分提供的信息专用于将工作负载部署到 GKE Enterprise 上,这些信息基于迁移到 Google Cloud:传输大型数据集、迁移到 Google Cloud:部署工作负载以及迁移到 Google Cloud:从手动部署迁移到自动化容器化部署中所述内容。
预配和配置您的运行时平台和环境
在部署任何工作负载之前,请先预配和配置必要的 GKE Enterprise 集群。
您可以预配 Google Cloud 上的 GKE 集群、Google Distributed Cloud 集群或 GKE on AWS 集群。例如,如果您有必须在本地部署的工作负载,则可以预配一个或多个 Google Distributed Cloud 集群。如果您的工作负载没有任何位置要求,您可以预配 Google Cloud 上的 GKE 集群。在以上两种情况下,您都可以使用 GKE Enterprise 管理和监控集群。如有任何多云要求,则您可以预配 GKE on AWS 集群以及其他 GKE Enterprise 集群。
首先,您定义所需的 GKE Enterprise 集群数量和类型。这些方面的要求主要取决于您在评估阶段收集的信息,例如您要实现的服务模式以及您希望如何隔离不同的环境。如果目前多个开发团队共享 OpenShift 集群,则您必须在 GKE Enterprise 上实现多租户模式:
- 使用不同的 Kubernetes 命名空间。平台团队为每个 OpenShift 项目创建一个 Kubernetes 命名空间,并实现集群多租户模式。 此模式与您在 OpenShift 环境中可能采用的模式非常相似,因此需要的 GKE Enterprise 集群数量可能与 OpenShift 集群数量类似。如果需要,您仍然可以为不同的环境创建专用集群。
- 使用不同的 GKE Enterprise 集群。基础架构团队为每个开发团队提供一个 GKE Enterprise 集群,这些集群全部由平台团队进行管理。此模式需要的 GKE Enterprise 集群数量可能多于 OpenShift 集群数量,因为它为您的开发提供更大的灵活性和隔离。
- 使用不同的 Google Cloud 项目。基础架构团队为每个开发团队创建一个 Google Cloud 项目,并在该 Google Cloud 项目中预配 GKE Enterprise 集群。然后由平台团队管理这些集群。此模型需要的 Open Enterprise 集群数量可能多于 OpenShift 集群数量,因为它为您的开发团队提供最大的灵活性和隔离。
确定所需的集群数量以及在哪些环境中预配这些集群后,请定义集群大小、配置和节点类型。然后,根据您在评估阶段收集的工作负载要求,预配集群和节点池。举例来说,您的工作负载可能需要某些性能和可伸缩性保证以及其他一些要求,例如 GPU 和 TPU 方面的需求。
如需详细了解如何预配和配置集群,请参阅以下内容:
- 为 Google Cloud 上的 GKE 集群预配和配置运行时平台和环境。
- 为 Google Distributed Cloud 集群创建管理员集群和用户集群。
- 为 GKE on AWS 集群安装管理集群并创建用户集群。
创建集群后,在部署工作负载之前,请配置以下组件,以满足您在 OpenShift 项目和集群评估阶段收集的要求:
- 身份和访问权限管理。您可以按照配置身份和访问权限管理中所述配置身份和访问权限管理。 您可以迁移到 Cloud Identity 作为您的主身份提供方,或使用 Google Cloud Directory Sync 将 Cloud Identity 与现有 LDAP 或 Active Directory 服务器同步。Google Distributed Cloud 支持 OpenID Connect (OIDC),可使用命令行对用户集群进行身份验证。按照使用 OIDC 和 Google 进行身份验证中的说明,将命令行身份验证与 Cloud Identity 集成。
- 监控。您可以根据自己的限制和要求,调整当前的监控解决方案以适应目标 GKE Enterprise 环境。如果您当前的解决方案托管在 OpenShift 上,您可以按照构建您的基础中所述实现 Cloud Monitoring,您也可以实现 Prometheus 和 Grafana 与 Google Distributed Cloud 搭配使用。
- 日志记录。您可以根据自己的限制和要求,调整当前的日志记录解决方案以适应目标 GKE Enterprise 环境。如果您当前的解决方案托管在 OpenShift 上,您可以按照构建您的基础 - 监控和提醒中所述内容实现 Cloud Logging。
使用 Config Sync,您可以在符合 Git 标准的通用代码库中集中定义以下资源的配置,并将该配置同时应用于本地和云端的所有集群:
- 基于角色的访问控制 (RBAC)。配置身份验证后,您可以混合使用 Identity and Access Management 和 Kubernetes RBAC 来实现您的授权政策。这些政策符合您在 OpenShift 项目评估中收集的要求和您选择的多租户模式。
- 资源配额。您可以将资源配额应用于命名空间,以便根据需要向开发者团队分配配额。
- 工作负载的安全上下文。您可以使用 Policy Controller 创建限制条件,以根据您的要求以及在评估阶段收集的 OpenShift 安全上下文限制条件配置强制执行 Pod 安全性。
- 网络政策和隔离。您可以使用 Kubernetes 网络政策在命名空间或工作负载之间实现所需的网络隔离。
如需安装 Config Sync,请参阅安装 Config Sync。如需安装 Policy Controller,请参阅安装 Policy Controller。
从旧环境中迁移数据
现在,您可以将数据从来源环境迁移到目标环境。
如果您的 OpenShift 有状态应用在 Kubernetes 永久性卷上托管数据,则可以使用不同的策略将数据迁移到目标环境。 选择哪种策略合适取决于各种因素,例如您的来源和目标后端存储提供商以及部署位置:
- 依赖于存储提供商的卷克隆、导出和导入功能。如果您正在本地环境中使用 VMware vSphere 卷,并且要迁移到 Google Distributed Cloud,请克隆 PersistentVolume 底层 VMDK 虚拟磁盘,并将其装载为目标环境中的卷。如果要迁移到 GKE,请将虚拟磁盘作为 Compute Engine 永久性磁盘import,然后将其用作永久性卷。
- 使用操作系统工具或数据库工具备份来源环境中的数据。将数据托管在可从这两种环境访问的临时位置,然后在目标环境中恢复数据。
- 使用远程复制工具(例如 rsync)将数据从来源环境复制到目标环境。
- 使用独立于存储的备份解决方案,例如带有 restic 集成的 Velero。
如需了解详情,请参阅迁移到 Google Cloud:传输大型数据集。
如需详细了解如何迁移数据以及在 GKE 中管理存储的策略,请参阅将数据从旧环境迁移到新环境以及关于存储配置的 GKE 文档。
借助 Google Distributed Cloud,您可以选择与外部存储系统集成的不同方案,例如通过 VMware vSphere 存储、Kubernetes 树内卷插件和容器存储接口 (CSI) 驱动程序。选择哪种方案取决于您需要集成的外部存储系统、支持的访问模式以及是否需要动态卷预配。
GKE on AWS 会自动部署适用于 Amazon Elastic Block Store (EBS) 的 CSI 驱动程序、通过 EBS 卷支持 PersistentVolumeClaim 的默认 StorageClass 和适用于其他 EBS 卷类型的 StorageClass。您还可以安装其他 CSI 驱动程序和自定义 StorageClass。如果您想要在 GKE on AWS 中导入 EBS 卷,则可以通过它创建 PersistentVolume。
部署工作负载
预配 GKE Enterprise 集群并迁移数据后,您现在可以构建和部署工作负载了。您可以选择不同的方案,从手动部署到完全自动化方案均可。
如果您需要使用 Operator 来部署在您的 OpenShift 环境中使用此部署方法的工作负载,则需要在部署工作负载之前安装该 Operator。您可以通过以下来源验证所需 Operator 的可用性:
- Google Cloud Marketplace
- operatorhub.io
- 特定软件供应商网站或 GitHub 代码库
手动部署
如果要在 OpenShift 环境中手动部署工作负载,您可以根据新的 GKE Enterprise 环境调整此手动部署流程。例如,您可以将在工作负载、要求和依赖项中评估的 OpenShift 资源清单手动转换为相应的 GKE Enterprise 资源清单。
下表是本文档工作负载、要求和依赖项部分中表格的扩展,添加了您可以在其中使用它们的目标 GKE Enterprise 资源的相关信息。
来源 OpenShift 资源清单 | 最重要的规范和参数 | 目标 GKE Enterprise 资源清单 |
---|---|---|
Deployment、DeploymentConfig、StatementSet、Job、Cron 作业 | 容器映像和存储库、容器端口、Pod 副本数、ConfigMap、Secret、PersistentVolumeClaim、资源请求和限制、更新策略、StatefulSet 服务名称、Cron 作业时间表 | Deployment、StatefulSet、Job、Cron 作业 |
ImageStream | 容器映像、映像拉取政策、容器映像存储库 | Deployment |
Pod 横向自动扩缩器 | 自动扩缩条件 | Pod 横向自动扩缩器 |
Service | 用于从集群内部连接到应用的主机名、IP 地址和公开服务的端口、为外部资源创建的端点 | Service |
Route | 用于从集群外部连接到应用的主机名和资源路径、路由规则 | Ingress |
设计和实现自动部署流程
如需自动构建和部署工作负载,请设计和实现构建和部署流程,或调整现有流程以支持新环境。如果您需要在混合环境中部署工作负载,则部署流程必须同时支持 GKE on Google Cloud 和 Google Distributed Cloud。
如需实现构建和部署流程,您可以使用 Cloud Build。 如果要自动执行构建和部署流程,您可以配置构建触发器或 GitHub 应用触发器,或者通过 Google Cloud 控制台设置自动部署。如果您使用任何 Policy Controller 限制条件,则可以对照 Cloud Build 作业中的政策检查 Kubernetes 和 GKE Enterprise 描述符,以便向开发者提供反馈。
如果您需要在本地运行构建作业或存储源代码,则可以使用 GitLab。 GitLab 提供源代码库、协作平台、CI/CD 功能以及容器映像注册表。您可以直接通过 Cloud Marketplace 在 GKE Enterprise 集群上部署 GitLab,也可以使用其他可用的安装选项。
如果您目前使用其中一项 OpenShift 设施构建或自动部署工作负载,则可以根据当前流程采用以下策略之一:
- Jenkins 流水线。如果您使用 Jenkins 流水线自动执行构建和部署流程,则可以将流水线迁移到 Cloud Build,使用现有的 Jenkins 环境或在 Google Cloud 中部署 Jenkins。
- 从 Dockerfile 进行的构建和部署以及所需的工件。 您可以通过 Dockerfile 或 build 配置文件使用 Cloud Build 构建容器映像。如果要在本地集群上执行构建,则可以使用 GitLab。
- 源代码转映像构建。在 Cloud Build 中,您必须执行一个初步步骤,以构建生成的容器映像所需的工件。如果您的源代码转映像作业构建 Python 应用并生成容器映像,则您需要配置自定义构建步骤来构建 Python 应用,然后再构建容器映像。此方法还要求您提供 Dockerfile;如果您不想提供 Dockerfile,则可以使用 Google Cloud 的 Buildpack 或 Jib 构建 Java 应用。
- 自定义构建。您可以像现在一样在 OpenShift 中创建自定义 Cloud Build 构建器。如果您的自定义构建器未使用任何 OpenShift 特有特性,您可能能够像在 Cloud Build 中一样使用它们。
无论选择哪种方法构建容器映像,您都需要将其存储在容器映像存储库中。您有以下几种选择:
- 保留现有容器映像存储库。如果您使用并非在 OpenShift 上运行的外部容器映像存储库,并且您尚未准备好进行迁移,则可以继续使用该存储库来存储您的容器映像。
- Container Registry。如果您更喜欢全托管式服务,则可以使用 Container Registry 存储容器映像。如果您需要其他安全层,则可以自行管理 Container Registry 加密密钥,配置安全边界以访问 Container Registry,增强软件供应链的安全性,并使用 Artifact Analysis 扫描容器映像是否存在已知漏洞。Container Registry 还支持由 Google 维护的托管式基础映像,作为您容器映像的基础。
- 本地存储库。如果您因为当前存储库托管在 OpenShift 上而需要迁出,并且需要本地存储容器映像,则可以选择随 GitLab 提供的注册表。
- 混合方式。您可以综合使用前面所述方案,以充分利用每种方案的优势。举例来说,您可以将 Container Registry 用作主存储库,并将其镜像到本地存储库。这种情况下,您将使用 Container Registry 功能,同时享受具有本地存储库而带来的优势。
无论您选择如何存储容器映像,都需要为集群预配和配置凭据以访问容器映像存储库。
如果您需要向用户或第三方服务发送有关构建状态和容器映像的通知,则可以使用 Cloud Functions 响应 Cloud Build 和 Container Registry 生成的事件。
OpenShift 与 GKE Enterprise 功能对应情况汇总表
下表总结了 GKE Enterprise 功能与您在 OpenShift 上所用功能的对应情况。
OpenShift | GKE Enterprise |
---|---|
OpenShift 项目 |
|
OpenShift SDN 和网络隔离 |
|
OpenShift 安全上下文限制 |
|
OpenShift 流水线 |
|
OpenShift 源代码转映像 |
|
身份集成 |
|
优化您的环境
优化是迁移的最后一个阶段。在此阶段,您将使环境比以前更高效,同时,您将对可重复的循环执行多次迭代,直到您的环境满足优化要求。这种可重复的循环步骤如下:
- 评估您的当前环境、团队和优化循环。
- 确定优化要求和目标。
- 优化您的环境和团队。
- 调整优化循环。
以下部分依赖于《迁移到 Google Cloud:优化您的环境》。
评估您的当前环境、团队和优化循环
首次评估侧重于从您的环境到 GKE Enterprise 的迁移,但这里的评估则是针对优化阶段的。
确定优化要求
关于 GKE on Google Cloud 优化要求,请查看在优化环境中制定的优化要求。
查看针对 GKE Enterprise 环境的以下优化要求:
- 开始在无服务器环境中部署工作负载。如果需要减少运营团队的压力,您可以开始使用全托管式无服务器平台,例如 Cloud Run 和 Knative serving。
- 对部署流程进行现代化改造。 迁移到 Google Cloud:部署您的工作负载介绍典型的端到端部署流程以及如何对现有流程进行现代化改造。如果您要对现有部署流程进行现代化改造,或要设计新的部署流程,请参阅迁移到 Google Cloud:从手动部署迁移到自动容器化部署以获取指导。
- 使用 Spinnaker 进行部署。如果您需要实现部署逻辑(例如 Canary 部署和蓝绿部署)以提高环境的可靠性并减少对用户的影响,则可以使用 Spinnaker。如需使用适用于 Google Cloud 的 Spinnaker,您需要安装它。 之后,您可以使用 Spinnaker 实现部署流程。例如,您可以在 Spinnaker 中注册现有 GKE 集群,为 Spinnaker 启用 Kustomize 支持,或使用 Spinnaker 和 GKE 实现持续交付流水线。
- 实现安全软件供应链。对于安全关键型工作负载,您可以使用 Binary Authorization 在 GKE Enterprise 集群中实现安全软件供应链。
- 切换到 Cloud Service Mesh。如果您已经在使用 OpenShift Service Mesh,或者您正在寻求服务网格提供的流量管理、可观测性和安全功能,则可以采用 Cloud Service Mesh。Cloud Service Mesh 提供 GKE Enterprise 测试和支持的 Istio 分布,以及由 Google 管理的后端功能,这些功能可实现可观测性、mTLS 证书管理以及与 Identity Aware Proxy (IAP) 的集成。
完成优化
填充优化要求列表后,请完成迁移到 Google Cloud:优化您的环境中所述优化阶段的其余活动。
寻求帮助
Google Cloud 提供了各种选项和资源,方便您获取必要的帮助和支持,以充分利用 Google Cloud 服务:
- 自助资源。如果您不需要专属支持,则可以按照自己的进度使用各种选项。
- 技术合作伙伴。 Google Cloud 已与多家公司达成合作,便于您使用 Google Cloud 产品和服务。
- Google Cloud 专业服务。我们的专业服务可以帮助您充分利用在 Google Cloud 中的投资。
Google Cloud Migration Center 提供了更多资源来帮助您将工作负载迁移到 Google Cloud。
如需详细了解这些资源,请参阅迁移到 Google Cloud:使用入门中的寻求帮助部分。
后续步骤
- 迁移到 Google Cloud:使用入门。
- 详细了解 GKE Enterprise 和 Migrate to Containers。
- 了解如何使用 Istio 网格扩展功能为迁移提供支持。
- 探索有关 Google Cloud 的参考架构、图表和最佳实践。查看我们的 Cloud Architecture Center。