플랫폼 관리자의 일반적인 태스크는 애플리케이션 및 서비스 팀이 자신의 워크로드를 실행하는 데 필요한 인프라 리소스를 이용할 수 있도록 보장하는 것입니다. 조직에 따라 팀은 각 팀에 설정된 적절한 액세스 제어를 통해 특정 클러스터를 사용하거나 Fleet의 모든 클러스터에서 워크로드를 실행해야 할 수 있습니다. Fleet팀 관리 기능은 각 팀이 Fleet에서 별개의 "테넌트"로 작동하는 상황에서 관리자가 팀에 대해 이와 같은 인프라 및 리소스를 쉽게 프로비저닝하고 관리할 수 있게 도와줍니다. 팀은 워크로드 실행 및 관리는 물론 자신의 클러스터 및 네임스페이스 집합으로 범위가 지정된 로그, 리소스 사용률, 오류율, 기타 측정항목을 확인할 수 있습니다.
이 페이지는 Fleet팀 관리 기능에 대해 알아보려는 플랫폼 관리자 및 애플리케이션팀 구성원을 대상으로 합니다. Fleet팀 관리 기능은 전체 GKE Enterprise 플랫폼을 사용 설정한 사용자에게만 제공됩니다.
Fleet팀 관리 개요
Fleet팀 관리는 Fleet을 관리할 때 사용할 '팀 수준' 추상화를 관리자에게 제공하는 두 가지 주요 개념을 기반으로 합니다.
팀 범위를 사용하면 팀별로 Fleet 리소스의 하위 집합을 정의할 수 있으며, 각 범위는 하나 이상의 Fleet 구성원 클러스터와 연결됩니다. 팀 범위에는 Google Cloud 의 클러스터 또는 Google Cloud외부의 클러스터가 포함될 수 있지만 모든 클러스터가 동일한 Fleet의 구성원이어야 합니다. 다른 팀이 동일한 클러스터에서 워크로드를 실행할 수 있도록 클러스터를 둘 이상의 범위와 연결할 수 있습니다.
Fleet 네임스페이스는 Fleet 내에서 특정 네임스페이스에 액세스할 수 있는 사용자를 제어하는 방법을 제공합니다. 기본적으로 Fleet의 클러스터에 정의된 동일한 이름의 모든 네임스페이스가 동일한 네임스페이스인 것처럼 처리됩니다. 하지만 Fleet팀 관리는 네임스페이스보다 세부적인 제어를 추가할 수 있는 방법을 제공합니다. 특정 팀 범위 내에서 Fleet 네임스페이스를 만든 후 팀 구성원에게 해당 팀 범위 내의 클러스터에 대해서만 액세스 권한을 부여할 수 있습니다. Fleet 네임스페이스는 팀 범위의 구성원 클러스터에서 다른 Kubernetes 네임스페이스와 동일한 방식으로 사용될 수 있습니다. 플랫폼 관리자는 스스로 Fleet 네임스페이스를 만들 수 있고, 추가 권한이 부여된 경우 팀 관리자에게 네임스페이스 만들기를 위임할 수 있습니다.
팀 관리 예시
예를 들어 귀하가 단일 Fleet에서 2개 팀을 위해 리소스를 설정하는 Cymbal Group 회사의 플랫폼 관리자라고 가정해 보세요.
백엔드팀은 하나의 Google 그룹인 backend-team@cymbalgroup.com으로 구성됩니다. 귀하는 이 팀이 자신의 네임스페이스 backend를 사용해서 클러스터 1 및 클러스터 2에서 워크로드를 실행하도록 결정합니다. 귀하는 2개의 클러스터가 포함된 팀 범위를 만들고 이 범위 내에서 backend Fleet 네임스페이스를 정의합니다.
프런트엔드팀은 2개의 Google 그룹인 frontend-admin@cymbalgroup.com 및 frontend-dev@cymbalgroup.com으로 구성됩니다. 귀하는 프런트엔드팀이 frontend-foo 및 frontend-bar 네임스페이스를 사용해서 클러스터 2와 클러스터 3에서 워크로드를 실행할 수 있도록 결정합니다. 다시 2개의 클러스터를 사용해서 팀 범위를 만들고 이 범위 내에 2개의 Fleet 네임스페이스를 정의합니다.
다이어그램에서 볼 수 있듯이 팀을 설정한 후에는 두 팀 모두 클러스터 2를 사용할 수 있고 각 팀이 자신의 고유 네임스페이스를 사용합니다. 또한 백엔드팀은 클러스터 1에서 자신의 네임스페이스를 사용할 수 있고 프런트엔드팀은 클러스터 3에서 자신의 네임스페이스를 사용할 수 있습니다. 두 팀 모두 클러스터에서 자신의 워크로드를 실행할 수 있고 상대 팀을 고려할 필요 없이 자신의 고유 리소스를 볼 수 있습니다.
어느 경우에든 팀장(백엔드팀에서는 개별 사용자인 다나, 프런트엔드팀에서는 frontend-admin 그룹 구성원)이 팀 범위에 대해 admin 액세스 권한을 갖도록 지정합니다. 즉, 팀장이 해당 범위 내에서 역할 및 역할 바인딩을 만들 수 있고, 남은 팀 구성원은 editor 액세스 권한을 갖습니다.
kubectl 또는 기타 도구를 사용해서 수동으로 이 구성을 모두 설정할 수 있지만 팀 관리 기능을 사용하는 것이 팀을 더 쉽고 빠르게 온보딩할 수 있는 방법이며, 관리자 및 팀 구성원이 팀 범위의 측정항목과 같은 팀 범위에 따라 추가 기능을 사용할 수 있습니다.
실제 상황에서는 프로덕션, 개발, 테스트 환경에 대해 별개의 Fleet를 만들어야 할 것입니다. 이러한 각 Fleet 내에서 프런트엔드 및 백엔드 팀에 대한 팀 범위를 만들고 각 팀에 자체적인 프로덕션, 개발, 테스트 클러스터를 제공해야 합니다. 자세한 내용은 Fleet 권장사항 및 예시를 참조하세요.
팀 기반 기능
팀 범위가 설정된 다음 애플리케이션 운영자와 관리자는 리소스 사용률, 로그, 네임스페이스별 오류, 해당 범위 전반의 기타 측정항목과 같은 팀 범위의 정보를 확인할 수 있으므로, 총 리소스 사용, 문제 해결 등의 방식을 보다 쉽게 평가할 수 있습니다. 자세한 내용은 팀 개요 사용을 참조하세요. 팀 범위는 업그레이드 배포 순서를 제어하는 데에도 사용할 수 있습니다.
팀 범위 액세스
팀 구성원은 Connect Gateway에 대한 특수 클러스터 사용자 인증 정보를 사용해서 kubectl로 자신의 팀 범위 클러스터에 액세스하는 것이 좋습니다. Connect Gateway는 사용자가 Google 그룹스를 사용하여 승인을 포함하여 Fleet의 모든 클러스터에 Google ID로 로그인할 수 있게 해주는 일관되고 안전한 서비스입니다. Google Cloud의 GKE 클러스터를 인증하는 데 반드시 필요한 것은 아니지만 게이트웨이 사용자 인증 정보를 사용하여 프로젝트 전반에 걸쳐 Fleet 구성원 클러스터를 인증할 수 있는 간단하고 일관된 방법을 제공합니다. Fleet팀 관리는 현재 서드 파티 ID 공급업체를 지원하지 않습니다.
기존 리소스
또한 Fleet팀 관리를 사용해서 조직의 팀에 사용되는 기존 네임스페이스 및 클러스터를 '온보딩'하여, 관리자 및 팀이 기존 워크로드로 팀 기반 기능을 사용하도록 지원할 수 있습니다. Fleet 네임스페이스를 만들 때 해당 팀 범위와 연결된 클러스터 중 하나에 해당 이름의 기존 Kubernetes 네임스페이스가 있으면 이 네임스페이스가 Fleet 네임스페이스의 인스턴스화로 고려되며, 따라서 팀 범위의 일부가 됩니다.
다음 단계
플랫폼 관리자의 경우 팀 설정 안내에 따라 팀 범위 및 네임스페이스를 설정, 구성, 관리합니다.
팀 개요 사용에서 팀 수준 측정항목 및 기타 팀별 정보를 확인하는 방법을 알아봅니다(제한된 미리보기만).
[[["이해하기 쉬움","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-01(UTC)"],[],[],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)."]]
