托管式控制平面现代化改造
您必须在支持结束期限之前,将 Cloud Service Mesh 集群从已弃用的 ISTIOD 控制平面实现现代化改造为 TRAFFIC_DIRECTOR 实现。您可以自行安排现代化改造时间,也可以在组织符合条件后让 Google 自动安排。
有两种现代化改造途径,您也可以混搭使用:
- 客户触发的现代化改造(自助式):您可以使用 Google Cloud CLI 自行启动并控制舰队现代化改造的确切时间,而无需依赖 Google 驱动的安排。
- Google 驱动的现代化改造(默认):Google 会评估舰队兼容性,并根据维护时段和提前通知自动安排对您组织中的舰队进行现代化改造。 Google 会等待您组织中的所有舰队都兼容,因此单个不兼容的舰队会阻止您的现代化改造。
无论您选择哪种途径,都需要完成以下核心步骤来对控制平面进行现代化改造:
- 检查兼容性:启用兼容性检查,了解您的车队与现代化改造的兼容性。
- 规划和配置现代化:选择迁移途径,配置集群和舰队发布顺序,或延迟特定舰队。
- 弥合兼容性差距:在开始现代化改造之前,请确保您的车队满足所有兼容性要求。
- 启动现代化改造:按计划触发客户触发的现代化改造,或等待 Google 驱动的调度。
- 主动式集群现代化改造:在配置的维护窗口期间,双控制平面并行运行,并且 Deployment(工作负载和网关)会自动过渡到新的控制平面。您需要手动重启 StatefulSet 和 DaemonSet 工作负载。
- 监控状态、过渡和最终确定:监控条件进度,解决任何停滞问题,在过渡期(至少 6 个工作日)内观察工作负载,在最终确定舰队级配置之前提供完整的回滚支持。
检查车队的兼容性并弥合差距
无论是客户触发的现代化改造还是 Google 驱动的现代化改造,任何舰队都必须先经过验证,确认其兼容性,然后才能进行现代化改造。您必须启用兼容性报告,才能检查潜在的阻碍条件并弥合配置差距。如需了解详情,请参阅了解 Cloud Service Mesh 兼容性。
- 对于 Google 驱动的现代化改造:Google 只会安排所有非延迟舰队都兼容的组织。
- 对于客户触发的现代化改造:您必须先验证目标舰队是否报告
MODERNIZATION_COMPATIBLE,然后再启动现代化改造。
兼容性检查会评估舰队的 Istio CRD 配置、Pod 注释、基础架构依赖项(例如 Workload Identity)和规模参数。
处理不支持的功能
随着 ISTIOD 控制平面的弃用, Google Cloud 将不再支持与 TRAFFIC_DIRECTOR 控制平面实现不兼容的功能。请参阅 API 支持的详细信息。
如果您使用的是不受支持的功能,则必须在支持结束之前采取以下措施之一(请参阅弃用):
- 重构配置(推荐):移除不受支持的字段或将其替换为受支持的 Cloud Service Mesh 替代方案,以便您的舰队报告
MODERNIZATION_COMPATIBLE,然后现代化为TRAFFIC_DIRECTOR控制平面实现。 - 迁移到开源 (OSS) Istio:如果您的工作负载严格需要托管式 Cloud Service Mesh (
TRAFFIC_DIRECTOR) 不支持的功能,则无法将这些集群现代化为TRAFFIC_DIRECTOR。您必须将这些工作负载迁移到自行管理的开源 Istio。 - 卸载 Cloud Service Mesh:您可以卸载托管式 Cloud Service Mesh。
规划和配置现代化改造
制定舰队现代化改造方案。如果您不这样做,系统会以默认方式应用 Google 驱动的现代化改造。您必须采取行动,确保先对非生产环境舰队进行现代化改造,最后对关键舰队进行现代化改造。此外,在整个组织中所有非延迟舰队都兼容之前,Google 驱动的现代化改造不会安排组织的现代化改造,因此本地不兼容可能会导致现代化改造受阻。
在开始现代化改造之前,请查看相关选项,并为组织中的舰队和集群配置发布设置。
可用的途径
| 方法 | 说明 | 适用场景 | 范围 | 前提条件 | 提前通知 | 回滚功能 |
|---|---|---|---|---|---|---|
| 客户触发的现代化改造 | 您可以按照自己的时间表逐个舰队地启动现代化改造。 | 可精细控制舰队现代化改造时间(您可以在舰队级决定何时启动和回滚)。利用现有的应用监控功能,在需要回滚时向您发送提醒。 | 按舰队 (FLEET_PROJECT_ID)。 |
目标舰队必须与现代化兼容。 | 不适用。 | 使用 Google Cloud CLI 立即进行自助回滚。 |
| Google 驱动的现代化(默认) | Google 会自动安排组织范围内的现代化改造。 | 当组织中的所有舰队都兼容时,系统会自动进行现代化改造。 | 整个 Google Cloud 组织(所有非延迟舰队)。 | 组织中的所有非延迟舰队都必须与现代化改造兼容。 | 开始前 14 天以上的舰队通知 + 24 小时以上的集群通知。 | 如果标准化监控显示错误,Google 将回滚。如果应用监控显示错误,您必须与 Cloud Customer Care 联系。 |
管理组织中的多个车队
如果您的 Google Cloud 组织管理多个舰队,则无需为所有舰队选择单一方法。您可以组合使用多种策略,例如:
- 延迟复杂或关键舰队:使用
--modernization-strategy deferred将特定舰队固定到旧版实现,以便在您修复依赖项或规划客户触发的执行时,将这些舰队从 Google 驱动的调度中排除。 - 首先在所选舰队上启动客户触发的现代化改造:先对测试、开发或评估舰队进行现代化改造,以便在您自己的时间范围内验证行为。
- 允许 Google 对剩余舰队进行现代化改造:所有兼容且未延迟的舰队仍会选择加入 Google 驱动的调度。
推迟舰队现代化改造(选择不采用)
如需选择让单个舰队不进行 Google 驱动的现代化改造,请将其策略设置为 DEFERRED:
gcloud alpha container fleet mesh update \
--modernization-strategy deferred \
--project FLEET_PROJECT_ID
将 FLEET_PROJECT_ID 替换为舰队宿主项目的 ID。
建议通过设置 --modernization-strategy deferred 来执行以下操作:
- 将特定舰队排除在 Google 驱动的调度之外,因为您打算使用客户触发的现代化改造,按照自己的时间表对这些舰队进行现代化改造。
- 在您修复依赖项期间,暂时搁置复杂或关键舰队的现代化改造,以便组织中的其他兼容舰队继续进行 Google 驱动的调度。
请注意,系统仍会遵循旧版项目标签 mesh-modernization-mode=manual,但建议使用 --modernization-strategy deferred。组织中的其他非延迟舰队在全部兼容后,仍可由 Google 驱动的调度系统进行调度。
配置发布顺序
您可以使用 mesh-modernization-order 标签(early、default 或 late)控制集群和舰队的顺序推出顺序。
集群发布顺序(适用于两种途径)
如果舰队包含多个集群,您可以通过为每个集群应用 mesh-modernization-order 标签来控制集群的现代化顺序。当您或 Google 触发舰队的现代化改造时,系统会按顺序对每个集群组进行现代化改造,等待当前组的自动化现代化改造步骤完成后,再开始对下一个组进行现代化改造:
gcloud container clusters update CLUSTER_NAME \
--location LOCATION \
--update-labels="mesh-modernization-order=VALUE"
将 CLUSTER_NAME 替换为集群的名称,将 LOCATION 替换为集群的位置,并将 VALUE 替换为以下值之一:
early:集群在第一波次现代化改造中完成现代化改造。default:集群在第二波次现代化改造中完成现代化改造。late:集群在第三波也是最后一波现代化改造中完成现代化改造。
舰队发布顺序(仅限 Google 驱动)
在有多个舰队正在进行 Google 驱动的现代化改造的组织中,您可以通过在舰队宿主项目上设置项目级标签来控制 Google 对舰队进行现代化改造的顺序:
gcloud alpha projects update FLEET_PROJECT_ID \
--update-labels="mesh-modernization-order=VALUE"
将 FLEET_PROJECT_ID 替换为舰队宿主项目的 ID,并将 VALUE 替换为以下值之一:
early:舰队在第一波现代化改造中完成现代化改造。default:相应舰队在第二波次现代化改造中完成现代化改造。late:舰队在第三波也是最后一波现代化改造中完成现代化改造。
Google 会先完成每个舰队层级的现代化改造,然后再开始下一个层级的现代化改造,层级顺序为:抢先版、默认版(无标签)、延迟版。标记为“延迟”的车队不包含在此排序中。
例如,您可以将非生产舰队设置为 early,将特别关键的舰队设置为 late,而将其他舰队保留为默认值。
如果您不使用 Google Cloud 组织,那么您的舰队将独立地进行安排和现代化改造,您无法控制排序。
客户触发的现代化改造(自助服务)
客户触发的现代化改造可让您直接控制单个舰队的现代化改造开始时间。
触发舰队现代化改造
当目标舰队报告
MODERNIZATION_COMPATIBLE 时,使用以下命令触发现代化改造:
gcloud alpha container fleet mesh update \
--modernization-strategy automatic \
--project FLEET_PROJECT_ID
将 FLEET_PROJECT_ID 替换为舰队宿主项目的 ID。
- 维护窗口:Google 会遵守配置的集群维护窗口和排除项。集群现代化改造会在集群的下一个开放维护窗口期间开始。
- 集群排序:如果您在集群上配置了
mesh-modernization-order标签,Google 会遵循该排序。
监控进度
按照检查现代化改造状态中的说明监控舰队和集群现代化改造的进度。请监控应用,以确定是否需要回滚,尤其是在 MODERNIZATION_PREPARING 和 MODERNIZATION_MIGRATING_WORKLOADS 状态下。
回滚客户触发的现代化改造
如果您在活跃集群现代化改造期间或在舰队过渡期(在舰队级最终确定之前)检测到问题,可以触发立即回滚:
gcloud alpha container fleet mesh update \
--modernization-strategy deferred \
--project FLEET_PROJECT_ID
将 FLEET_PROJECT_ID 替换为舰队宿主项目的 ID。
这样一来,您的舰队将处于延迟状态,也就是说,系统不会考虑对该舰队进行 Google 驱动的现代化改造。准备好重试现代化改造后,重新运行该命令以触发舰队现代化改造。
Google 驱动的现代化改造(自动默认)
如果您不启动客户触发的现代化改造,Google 会自动管理您组织中的现代化改造。
组织级安排
Google 会持续监控您的舰队。当组织中所有启用了网格的舰队(不包括任何延迟的舰队)都与现代化改造兼容后,Google 会安排对您的组织进行现代化改造。
提前通知和时间安排
Google 会在开始现代化改造之前提供两个级别的提前通知:
舰队级通知
首先,如果您的舰队被确定为与现代化改造兼容,并被选择在未来进行 Google 驱动的现代化改造,您会收到通知。
您的集群现代化改造最早可在收到通知后,在当月美国第一个工作日后的第 14 天开始。例如,如果 Google 确定您的组织已于 2027 年 1 月 10 日做好准备,我们会在 2027 年 1 月 31 日之前通知您,您的最早现代化改造开始日期为 2027 年 2 月 15 日。
您将同时收到有关组织中每个舰队(不包括您已延迟的舰队)的通知。您可以在舰队级功能状态条件 (
MODERNIZATION_WILL_BE_SCHEDULED) 中查看此通知。
集群级通知
在集群现代化改造开始至少 1 天(24 小时)前,您会收到集群级通知,其中包含对该集群进行 Google 驱动的现代化改造的预计开始日期。
在收到舰队级通知后,这使您可以更精确地确定各个集群的现代化改造时间。您可以在集群级功能状态条件 (MODERNIZATION_SCHEDULED) 中查看此通知。
为 Google 驱动的现代化改造请求回滚
如果在 Google 驱动的现代化舰队上进行主动现代化或浸泡期间出现问题,请与 Cloud Customer Care 联系以请求回滚。
主动式现代化期间会发生什么
本部分介绍了在对舰队和集群进行现代化改造期间会发生什么情况。
对舰队进行现代化改造
对于正在进行现代化改造的每个舰队(无论是 Google 驱动的还是客户触发的),我们都会根据排序(早期 → 默认 → 晚期)为所有集群启用新的控制平面实现。
为所有集群启用控制平面后,我们会根据排序(早期 → 默认 → 晚期)将所有集群的流量转移到新的控制平面实现。
如需检查当前状态,请参阅检查舰队现代化改造状态。
舰队过渡期
所有集群的流量都转移后,舰队会进入浸泡期。在所有集群完成现代化改造后,舰队会继续处于过渡期 (MODERNIZATION_MODERNIZED),至少 6 个工作日,然后才会过渡到 MODERNIZATION_FINALIZED。在整个浸泡期间,完整的回滚功能得以保留。现代化改造完成后,将无法再回滚,并且 ISTIOD 组件可能会被取消配置。
对集群进行现代化改造
在集群的主动式现代化改造过程中,两个控制平面实现会暂时并行运行,并以安全可控的方式处理以下任务:
- 启用新的控制平面实现。如果您为集群配置了维护窗口,则此步骤将在维护窗口期间开始,并持续到完成为止。请注意以下细节:
- 为了启用健康检查,在集群的
kube-system命名空间中创建snk守护程序集,并创建按集群应用的防火墙规则。 - 为了启用网络端点组 (NEG) 注入,将注解
cloud.google.com/neg添加到所有 Kubernetes 服务。 - 在集群中创建新的 Google Cloud 资源,例如网格、路由、后端服务和健康检查。
- 对部分新资源进行配额限制。您可以查看配额并根据需要申请更多配额。
- 在进入下一步之前的过渡时间内监控集群。
- 为了启用健康检查,在集群的
- 将流量转移到新的控制平面实现。如果您为集群配置了维护窗口,则此步骤将在维护窗口期间开始,并持续到完成为止。请注意以下细节:
- 重启由 Kubernetes 部署管理且包含 Cloud Service Mesh 代理的 Pod,以便它们重新连接到新的控制平面。
- 以越来越大的波次重启 Pod,并在每个波次后留出过渡时间以进行监控。
非部署的手动工作负载重启(需要客户采取行动)。
- Google 会自动重启由 Kubernetes Deployment 管理的工作负载。由其他类型的 Kubernetes 资源(例如 StatefulSet 和 DaemonSet)管理的工作负载必须手动重启。
- 在集群状态报告
MODERNIZATION_COMPLETED后(即集群处于浸泡期时),重新启动这些工作负载。 - 您必须在完成舰队现代化之前重启这些工作负载,否则这些代理将继续连接到计划停用的旧版 Istiod 控制平面。
- 使用标准 Kubernetes 方法(例如
kubectl rollout restart ...)重启工作负载
当集群中的所有工作负载都完成过渡后,集群会等待舰队过渡期。
如需监控集群的主动式现代化改造状态,请参阅检查现代化改造状态。
查看现代化状态并采取行动
您可以使用 Google Cloud CLI 监控舰队和集群的现代化进度:
gcloud container fleet mesh describe --project FLEET_PROJECT_ID
将 FLEET_PROJECT_ID 替换为舰队宿主项目的 ID。
输出类似于以下内容:
membershipStates:
projects/123456789/locations/global/memberships/cluster-1:
servicemesh:
conditions:
- code: MODERNIZATION_MIGRATING_WORKLOADS
documentationLink: https://cloud.google.com/service-mesh/v1.30/docs/...
severity: INFO
state:
servicemesh:
conditions:
- code: MODERNIZATION_MODERNIZING
documentationLink: https://cloud.google.com/service-mesh/v1.30/docs/...
severity: INFO
现代化改造状态在 state.servicemesh.conditions(舰队级)和 membershipStates.<MEMBERSHIP_NAME>.servicemesh.conditions(集群级)字段中报告:
成功实现舰队现代化的状态
在成功的舰队现代化改造中,舰队的状态将从 MODERNIZATION_MODERNIZING 开始。
然后,每个集群都会经历以下状态:
MODERNIZATION_SCHEDULEDMODERNIZATION_PREPARINGMODERNIZATION_PREPAREDMODERNIZATION_MIGRATING_WORKLOADSMODERNIZATION_COMPLETED
舰队中的所有集群完成现代化改造后,舰队将经历以下状态:
MODERNIZATION_MODERNIZEDMODERNIZATION_FINALIZED
回滚
在整个现代化改造过程中,Google 驱动的现代化改造会监控部署就绪情况和健康状况,并在检测到问题时自动触发回滚。如果您检测到问题,请与 Cloud Customer Care 联系以请求回滚。
对于客户触发的现代化改造,您可以随时触发回滚。
在回滚期间,舰队显示状态 MODERNIZATION_ROLLING_BACK_FLEET,集群显示状态 MODERNIZATION_ROLLING_BACK_CLUSTER。
集群回滚完成后,会暂时显示状态 MODERNIZATION_ABORTED。
处理错误和停滞(仅限客户触发)
在客户触发的现代化改造期间,如果集群遇到阻止其向前推进的问题,其状况会转换为 MODERNIZATION_STALLED。对于客户触发的现代化改造,Google 不会触发回滚。您必须对问题进行初步诊断,并决定是向前修复还是触发回滚。
当集群报告 MODERNIZATION_STALLED 时,请检查条件详情,以获取相关错误部分的直接链接:
用户可操作的错误
如果我们检测到不兼容的网格或集群配置,将停止现代化。确保已启用兼容性报告,并按照了解 Cloud Service Mesh 兼容性中的说明,查看舰队级和集群级条件是否存在差距。
- 立即重试:一旦解决阻塞问题,我们会检测到相应更改并立即恢复现代化,而无需等待下一个维护窗口。
内部错误
Google 工程师会审核 Google 内部服务问题,并尽可能恢复您的现代化改造。请注意,现代化可能会在维护窗口之外恢复,就像用户可操作的错误一样。为避免这种情况,您可以触发回滚。
如果现代化改造停滞超过 24 小时,并且不存在兼容性差距,请与 Cloud Customer Care 联系以了解详情,或者在生产工作负载受到影响时触发回滚。
舰队级条件参考文档
| 条件 | 说明 |
|---|---|
MODERNIZATION_COMPATIBLE |
舰队与新的控制平面实现兼容。 |
MODERNIZATION_WILL_BE_SCHEDULED |
Google 驱动的现代化改造:组织中的所有非延迟舰队均兼容,并且已排队等待安排。 |
MODERNIZATION_MODERNIZING |
舰队中的一个或多个集群正在积极进行现代化改造。 |
MODERNIZATION_MODERNIZED |
所有集群都已完成主动式现代化改造。相应舰队处于浸泡期。 |
MODERNIZATION_FINALIZED |
现代化改造已完成并最终确定。旧版 Istiod 组件将被移除。无法再回滚。 |
MODERNIZATION_ROLLING_BACK_FLEET |
正在进行舰队级回滚。 |
集群级条件参考文档
| 条件 | 说明 |
|---|---|
MODERNIZATION_SCHEDULED |
集群已安排在条件中指定的日期或之后进行现代化改造。如果为集群配置了维护窗口/排除项,则该日期将指示目标维护窗口。 |
MODERNIZATION_PREPARING |
启用新的控制平面实现。 |
MODERNIZATION_PREPARED |
新的控制平面实现已启用。工作负载迁移尚未开始。 |
MODERNIZATION_MIGRATING_WORKLOADS |
集群正在主动将工作负载迁移到新的控制平面实现。 |
MODERNIZATION_COMPLETED |
集群已完成现代化改造,目前处于过渡期。 |
MODERNIZATION_STALLED |
由于出现错误,现代化进程停滞不前(仅限客户触发)。请查看条件详情以了解解决方案。 |
MODERNIZATION_ROLLING_BACK_CLUSTER |
集群正在积极回滚。 |
MODERNIZATION_ABORTED |
集群已回滚到旧版控制平面。报告时间较短。 |