如果您是使用托管式控制平面或集群内控制平面的 Anthos Service Mesh 持续客户,本文档适合您。本文档介绍了控制平面实现以及控制平面可能的迁移。
如果您是 Traffic Director 的持续客户或新客户,则无需阅读本文档。
控制平面概览
在服务网格中,控制平面提供流量管理、Envoy 代理使用时的代理管理以及其他网络功能。
Anthos Service Mesh 提供了两个控制平面:托管式控制平面和集群内控制平面。仅使用 Envoy 代理作为数据平面。
新的托管式控制平面
新的托管式控制平面称为 Traffic Director (TD) 实现。新的控制平面对您来说意味着什么?
从 Anthos Service Mesh 产品迁移到 Cloud Service Mesh 的一个重大更改是迁移到多租户全球控制平面。
Anthos Service Mesh 中使用的托管式控制平面专用于单个集群。虽然用于 GKE 的 API (Istio CRD) 相同,并且发送到边车的 xDS 配置兼容且没有行为差异,但控制平面的差异导致了您(最终用户)可见的一些特征。
配置更改响应时间。使用新控制平面时,部署新服务或更改服务政策所需的时间略长。
配置流水线会执行两遍配置提交,以提高可靠性。第一遍会执行验证,以检查配置是否正确。后续阶段会将配置全局传播到您的服务部署。为了支持使用 Google Cloud 服务(例如全球跨可用区或跨区域负载均衡、集中式健康检查、流量驱动型自动扩缩和托管式速率限制),系统会将配置传播到这些系统,并对其正确性进行独立验证。此配置还会以一种方式在内部存储,以便 Google 站点可靠性工程在任何生产紧急情况下可靠且高效地执行产品操作。
这些操作提供了更高的可靠性,但会导致配置推送速度比 Anthos Service Mesh 当前用户观察到的延迟更慢。
使用新控制平面测量发现,任何新 Pod 提取现有配置的延迟都会略有改善。慢速配置推送适用于首次传播创建的任何新服务或为服务推送的任何新政策。端点传播延迟在功能上类似。
扩缩事件和对端点进行的其他更改的速度。使用新控制平面至少可以同样快速地处理这些问题。这些事件包括由于 Pod 横向自动扩缩而启动或停止的新 Pod,以及由于移动到集群中的其他节点而使用新 IP 地址重启的 Pod。
如果您是 Traffic Director 用户,您的控制平面将保持不变。您无需阅读本指南的其余部分。有关 Cloud Service Mesh 实现的文档在使用Google Cloud API 进行配置下。
如果您是 Anthos Service Mesh 用户,则现有部署中控制平面的后续步骤取决于您是使用托管式控制平面还是集群内控制平面。
如果您使用的是托管式控制平面,则除某些例外情况外,您的现有舰队将迁移到 Cloud Service Mesh 中称为托管式控制平面(Traffic Director 或 TD 实现)的新控制平面。请阅读以下部分:对现有网格和舰队进行控制平面迁移。如果您使用的功能不受 Traffic Director 控制平面实现支持,则您暂时仍使用之前的控制平面。您应该继续阅读本指南。
如果您使用的是集群内控制平面,则控制平面保持不变。您无需阅读本指南的其余部分。
如果您没有 Google Cloud 组织,且在无组织的项目中使用托管式控制平面,则会收到 TD 控制平面。
如果您是 Anthos Service Mesh 客户,且要创建新的舰队,则会收到 Traffic Director 控制平面实现。您应该继续阅读本指南。
membershipStates:
projects/656460026795/locations/us-central1/memberships/cluster:
servicemesh:
conditions:
- code: MODERNIZATION_SCHEDULED
details: This cluster has been scheduled for modernization on or after (date ~ at least 2 weeks).
documentationLink:
severity: INFO
使用 meshconfig.googleapis.com API 注册的任何旧版托管式控制平面集群都将通过 gkehub.googleapis.com Membership API 自动注册到集群项目中的舰队。如果您有任何自动化功能会取消注册集群,则必须在进行迁移之前移除该功能,否则迁移会出现问题。为了让托管式产品能够正常运行,必须将其注册到已启用网格功能的舰队。
[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC):2025-08-28。"],[],[],null,["# Managed control plane for continuing customers\n==============================================\n\nThis document is for you if you're a continuing Anthos Service Mesh customer\nusing the managed control plane or in-cluster control plane. This document\ndiscusses your control plane implementation and the possible migration of your\ncontrol plane.\n\nIf you're a continuing Traffic Director customer or a new customer, you\ndon't need to read this document.\n\nControl plane overview\n----------------------\n\nIn service meshes, the control plane provides traffic management, proxy\nmanagement when the Envoy proxy is in use, and other networking capabilities.\n\nAnthos Service Mesh offered two control planes: a managed control plane and an\nin-cluster control plane. Only Envoy proxies are used as the data plane.\n\nNew managed control plane\n-------------------------\n\nThe new managed control plane is called the Traffic Director (TD)\nimplementation. What does the new control plane mean for you?\n\nOne of the most significant changes from the Anthos Service Mesh product to\nCloud Service Mesh is the move to a multi-tenant, global control plane.\n\nThe managed control plane used in Anthos Service Mesh is dedicated to a single\ncluster. Although the APIs (Istio CRDs) used for GKE are the same, and the xDS\nconfiguration sent to the sidecars is compatible with no behavioral differences,\nthe control plane differences result in a few characteristics that are\nvisible to you, the end user.\n\n- Configuration change response time. New service deployments, or changes to service policies, take slightly longer with the new control plane.\n - The configuration pipeline performs a two-pass configuration commit for reliability purposes. The first pass performs validations to check whether the configuration is well formed. The subsequent phase propagates the configuration globally to your service deployments. To enable use of Google Cloud services, such as global cross-zonal or cross-region load balancing, centralized health checking, traffic-driven autoscaling, and managed rate limiting, the configuration is propagated to these systems and independently validated for correctness. The configuration is also stored internally in a manner that allows Google site reliability engineering to reliably and efficiently perform product operations during any production emergencies.\n - These operations provide better reliability, but they result in a config push that is slower than the latency observed by current users of Anthos Service Mesh.\n - The latency for any new Pod to fetch existing configuration is measured to be slightly better with the new control plane. The slow configuration push is for the first-time propagation of any new service created or any new policies pushed for the service. Endpoint propagation latencies are functionally similar.\n- Speed of scaling events and other changes to the endpoints. These are handled at least as quickly with the new control plane. These events include new Pods starting or stopping because of horizontal Pod autoscaling, and Pods restarting with new IP addresses because they were moved to a different node in the cluster.\n- Scaling the number of endpoints. With the new global control plane, the endpoints of the mesh are sent directly from each cluster to the control plane from across all clusters in the mesh. This is a simpler, faster, and more scalable approach than the previous managed control plane uses. In older managed control plane (dedicated control plane) model, each Istiod must communicate with every other cluster in the mesh to determine the endpoints available in every other cluster. With the global control plane, the endpoints are propagated directly to the global control plane. This results in better reliability and performance in meshes with large numbers of endpoints and allows the meshes to scale to a larger number of endpoints.\n\nHow does the new control plane affect you?\n------------------------------------------\n\nHow the new control plane affects you depends on the APIs and control plane that\nyou are using.\n\n- If you are a Traffic Director user, your control plane remains the same. You don't need to read the rest of this guide. Documentation for your Cloud Service Mesh implementation is under **Configure with\n Google Cloud APIs**.\n- If you are an Anthos Service Mesh user, the next steps for the control plane in your existing deployment depend on whether you use the managed control plane or the in-cluster control plane.\n - If you use the managed control plane, with some exceptions your existing fleets will be migrated to the new control plane, referred to in the Cloud Service Mesh as managed control plane (Traffic Director, or TD, implementation). Read the following section, [Control plane\n migration for existing meshes and fleets](#control-plane-migration). If you are using a feature that isn't supported by the Traffic Director control plane implementation, you remain temporarily on the previous control plane. You should continue reading this guide.\n - If you use the in-cluster control plane, your control plane remains the same. You don't need to read the rest of this guide.\n - If you don't have a Google Cloud Organization, and you use the managed control plane on an organization-less project, you will receive the TD control plane.\n- If you are an Anthos Service Mesh customer and you are creating new fleets, you will receive the Traffic Director control plane implementation. You should continue reading this guide.\n - You will be notified about [the date](#control-plane-new-meshes) when new fleets receive the TD control plane.\n\nControl plane migration for existing meshes and fleets\n------------------------------------------------------\n\nStarting on July 22, 2024, Google will gradually update existing clusters to use\nthe managed control plane with TD implementation. You will be notified before we\nupdate your meshes.\n\nYou can review the capabilities of the Istiod and Traffic Director control plans\non the page that describes [Supported features using Istio APIs (managed control\nplane)](/service-mesh/v1.21/docs/supported-features-managed).\n\nYou should receive notification that a cluster is scheduled to be updated at least two\nweeks before the update. Notifications are available in your cluster-level\nfeature state conditions.\n\nUse the following Google Cloud CLI command to check the notification: \n\n```\ngcloud container hub mesh describe --project=[PROJECT_ID]\n```\n\nYou see results similar to the following: \n\n```\nmembershipStates:\n projects/656460026795/locations/us-central1/memberships/cluster:\n servicemesh:\n conditions:\n - code: MODERNIZATION_SCHEDULED\n details: This cluster has been scheduled for modernization on or after (date ~ at least 2 weeks).\n documentationLink: \n severity: INFO\n```\n\nAny legacy managed control plane clusters that were onboarded using the\n`meshconfig.googleapis.com` API will be automatically registered to the fleet\nin the cluster's project with the `gkehub.googleapis.com` Membership API. If\nyou have any automation that deregisters a cluster, you must remove it before\nmigration or the migration will have issues. For the managed product\nto work successfully, it must be registered to a fleet with the mesh feature\nenabled.\n\n[Contact support](/service-mesh/v1.21/docs/getting-support) if you need to customize\nyour migration or if you have questions about whether you are using unsupported\nfeatures.\n\nDuring the migration, in a safe and controlled way, the following changes take\nplace:\n\n- To enable health checking, the `snk` daemonset is created in the `kube-system` namespace of the cluster and a per-cluster a firewall rule is created.\n- To enable [network endpoint group (NEG)](/load-balancing/docs/negs) ingestion, the annotation `cloud.google.com/neg` is added to all Kubernetes services.\n- New Google Cloud resources such as [`Mesh`](/service-mesh/v1.21/docs/service-routing/service-routing-overview), [`Routes`](/service-mesh/v1.21/docs/service-routing/service-routing-overview), [backend\n services](/load-balancing/docs/backend-service), and [health\n checks](/load-balancing/docs/health-check-concepts) are created in the cluster.\n- Pods managed by Kubernetes deployments are restarted to reconnect to the Traffic Director control plane.\n\nSome of the new resources are quota-limited. You can\n[view quotas and request more if necessary](/load-balancing/docs/quotas).\n\n### Check control plane compatibility\n\nReview [differences in supported features between managed control plane\nimplementations](/service-mesh/v1.21/docs/supported-features-managed) to determine\nwhether your current usage of Cloud Service Mesh will require changes.\n\nControl plane for new meshes\n----------------------------\n\nStarting on July 1, 2024, most existing users of the managed `istiod` control\nplane implementation will begin to receive the updated managed control plane\nwith Google's globally available implementation - the Traffic Director (TD)\ncontrol plane, in *new* fleets.\n\nUsers whose existing usage of managed Cloud Service Mesh with the `istiod`\ncontrol plane implementation is not compatible with the Traffic Director\nimplementation without changes will continue to get the `istiod` implementation\nuntil September 8, 2024. If this applies to your organization then you received\na Service Announcement.\n\nIf you onboard a new fleet to managed Cloud Service Mesh, and this fleet is not\nin a Google Cloud Organization or it is in a new Google Cloud Organization,\nthen you will get the new managed control plane with the TD implementation from\nthe Cloud Service Mesh launch date.\n\nWhat's next\n-----------\n\n- If you're a continuing Anthos Service Mesh customer, your documentation is in the left-hand table of contents under **Configure service mesh with Istio APIs**.\n- If you're a continuing Traffic Director customer, your documentation is under **Configure service mesh with Google Cloud APIs**."]]