建議團隊成員使用 Connect Gateway 的特殊叢集憑證，透過 kubectl 存取團隊範圍叢集。Connect Gateway 是一項安全穩定的服務，可讓使用者透過 Google ID 登入機群中的任何叢集，包括使用 Google 群組進行授權。雖然並非必要，但使用閘道憑證可簡化機群成員叢集的驗證程序，即使跨專案也適用。 Google Cloud車隊團隊管理目前不支援第三方身分識別提供者。
[[["容易理解","easyToUnderstand","thumb-up"],["確實解決了我的問題","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["難以理解","hardToUnderstand","thumb-down"],["資訊或程式碼範例有誤","incorrectInformationOrSampleCode","thumb-down"],["缺少我需要的資訊/範例","missingTheInformationSamplesINeed","thumb-down"],["翻譯問題","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["上次更新時間：2025-09-04 (世界標準時間)。"],[],[],null,["A common task for platform admins is making sure that application and service teams have the infrastructure resources they need to run their workloads. Depending on your organization, teams may need to use specific clusters, or they may need to run workloads on every cluster in a fleet, with appropriate access control set up for each team. Fleet team management features make it easier for admins to provision and manage infrastructure resources like this for teams, with each team acting as a separate \"tenant\" on your fleet. Teams can run and manage their workloads, as well as view logs, resource utilization, error rates, and other metrics, all scoped to their own set of clusters and namespaces.\n\nThis page is for platform admins and application team members who want to learn about fleet team management features.\n\nFleet team management overview\n\nFleet team management is based around two key concepts that give admins a \"team-level\" abstraction to use when managing fleets:\n\n- **Team scopes** let you define subsets of fleet resources on a per-team basis, with each scope associated with one or more fleet member clusters. Team scopes can include clusters on Google Cloud or outside Google Cloud, though all the clusters must be members of the same fleet. A cluster can be associated with more than one team scope, letting different teams run workloads on the same cluster.\n- **Fleet namespaces** provide a way to control who has access to specific namespaces within your fleet. By default, any namespaces with the same name defined on clusters in the fleet are treated as if they were the same namespace. However, fleet team management provides a way to add more granular control over namespaces. You can create fleet namespaces within specific team scopes, and then grant team members access to them *only on clusters within their team scope*. Fleet namespaces can be used in the same way as any other Kubernetes namespace on the member clusters in the team scope. Platform admins can create fleet namespaces themselves, or, with some extra permissions, delegate namespace creation to team admins.\n\nTeam management example\n\nFor example, suppose you are a platform admin for the company Cymbal Group setting up resources for two teams on a single fleet.\n\n- The **Backend team** consists of one Google Group, `backend-team@cymbalgroup.com`. You decide that this team can run workloads on cluster 1 and cluster 2, using their namespace `backend`. You create a team scope including the two clusters, and define a `backend` fleet namespace within that scope.\n- The **Frontend team** consists of two Google Groups, `frontend-admin@cymbalgroup.com` and `frontend-dev@cymbalgroup.com`. You decide that the frontend team can run workloads on cluster 2 and cluster 3, using the namespaces `frontend-foo` and `frontend-bar`. Again you create a team scope with the two clusters, and define two fleet namespaces within that scope.\n\nAs you can see in the diagram, once you have set up the teams, both teams can use cluster 2, with each team using their own namespaces. In addition, the Backend team can use their namespace on cluster 1, and the Frontend team can use their namespaces on cluster 3. Both teams can run their workloads on the clusters and view their own resources without having to consider the other team.\n\nIn each case, you specify that the team leads (individual user Dana in the case of the Backend team, `frontend-admin` group members in the case of the Frontend team) have `admin` access to the team scope, meaning that they can create roles and role bindings within the scope, while the remaining team members have `editor` access.\n\nWhile you could set up all this configuration manually with `kubectl` or other tools, using team management features makes it easier to quickly onboard the teams, and lets admins and team members use additional features based on team scopes, such as team-scoped metrics.\n\nIn a real life situation, you would also probably have separate fleets for your production, development, and test environments. You would create team scopes for the Frontend and Backend teams within each of these fleets, providing the teams with their own production, development, and test clusters. You can find out more about this in our fleet [best practices](/kubernetes-engine/fleet-management/docs/fleet-concepts/best-practices) and [examples](/kubernetes-engine/fleet-management/docs/fleet-concepts/examples).\n\nTeam-enabled features\n\nAfter team scopes are set up, application operators and admins can view team-scoped information such as resource utilization, logs, errors by namespace, and other metrics from across their scope, making it easier for them to assess how they're using their total resources, troubleshoot problems, and more. You can find out more about these in [Use the team overview](/kubernetes-engine/fleet-management/docs/team-management-overview). Team scopes can also be used for [sequencing upgrade rollouts](/kubernetes-engine/docs/concepts/about-rollout-sequencing).\n\nAccessing team scopes\n\nWe recommend that team members access their team scope clusters with `kubectl` using the special cluster credentials for the [Connect Gateway](/kubernetes-engine/enterprise/multicluster-management/gateway). The Connect Gateway is a consistent, secured service that lets users log in with their Google IDs to any cluster in the fleet, including using Google Groups for authorization. While this isn't strictly required to authenticate to GKE clusters on Google Cloud, using the gateway credentials provides a simple, consistent way to authenticate to fleet member clusters, even across projects. Fleet team management does not currently support third-party identity providers.\n\nExisting resources\n\nFleet team management can also be used to \"onboard\" existing namespaces and clusters used by your organization's teams, letting admins and teams start using team-based features with existing workloads. If you create a fleet namespace and there is an existing Kubernetes namespace with that name on one of the clusters associated with its team scope, that namespace will be considered to be an instantiation of the fleet namespace, and hence part of the team scope.\n| **Note:** There are currently no warnings or other notifications provided if you create a fleet namespace that has the same name as an existing Kubernetes namespace in your scope. Be careful!\n\nWhat's next?\n\n- If you're a platform admin, follow the instructions in [Set up teams](/kubernetes-engine/fleet-management/docs/setup-teams) to set up, configure, and manage team scopes and namespaces.\n- Learn how to view team-level metrics and other team-specific information in [Use the team overview](/kubernetes-engine/fleet-management/docs/team-management-overview) (limited preview only)."]]
