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.
This page is for platform admins and application team members who want to learn about fleet team management features. Fleet team management features are only available for users who have enabled the entire GKE Enterprise platform.
Fleet team management overview
Fleet team management is based around two key concepts that give admins a "team-level" abstraction to use when managing fleets:
- 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.
- 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.
Team management example
For example, suppose you are a platform admin for the company Cymbal Group setting up resources for two teams on a single fleet.
- The Backend team consists of one Google Group,
[email protected]. You decide that this team can run workloads on cluster 1 and cluster 2, using their namespacebackend. You create a team scope including the two clusters, and define abackendfleet namespace within that scope. - The Frontend team consists of two Google Groups,
[email protected]and[email protected]. You decide that the frontend team can run workloads on cluster 2 and cluster 3, using the namespacesfrontend-fooandfrontend-bar. Again you create a team scope with the two clusters, and define two fleet namespaces within that scope.
As 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.
In 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.
While 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.
In 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 and examples.
Team-enabled features
After 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. Team scopes can also be used for sequencing upgrade rollouts.
Accessing team scopes
We recommend that team members access their team scope clusters with kubectl using the special cluster credentials for the Connect 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.
Existing resources
Fleet 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.
What's next?
- If you're a platform admin, follow the instructions in Set up teams to set up, configure, and manage team scopes and namespaces.
- Learn how to view team-level metrics and other team-specific information in Use the team overview (limited preview only).