What does this skill do, and when should you use it?
This skill is for multiple teams sharing a single GKE cluster. It provides reference patterns for namespace-based tenancy, RBAC, ResourceQuota, LimitRange, NetworkPolicy, and cost allocation. It recommends starting with namespace-per-team for cost efficiency, then adopting stronger isolation when compliance requires it. It is not intended for single-tenant cluster configuration or general deployment guidance.
It provides kubectl commands for creating and labeling namespaces, plus Kubernetes YAML examples for namespace-scoped Roles and RoleBindings, ResourceQuota, LimitRange, and NetworkPolicy. It explains Google Group bindings, default-deny networking, DNS allowance, cost-center labels, and the gcloud command for enabling GKE cost allocation. It also names MCP tools for applying, inspecting, authenticating to, describing, and deleting Kubernetes resources.
- A platform team is giving several development teams namespaces in one shared GKE cluster.
- An enterprise needs to separate development, staging, and production workloads within one cluster.
- A cluster administrator wants quotas and default resource constraints to prevent one team from exhausting shared capacity.
- A security team is implementing namespace-level least-privilege access and network segmentation.
- A cloud cost owner needs namespace and label-based attribution for GKE spending.
How do you install this skill?
- The examples can affect cluster authorization, network isolation, and billing configuration; confirm the target cluster, namespaces, groups, quotas, and rollback plan before execution.
- The document does not establish NetworkPolicy support in the target GKE networking implementation or provide verification and troubleshooting steps.
- Namespace-per-team is soft isolation and should not be treated as sufficient for strong compliance or mutually untrusted tenants.
- Chinese-language support, overseas-service dependencies, and mainland-China network reachability are not documented.
- Shell / CLI
- MCP Server
kubectlGoogle Cloud CLI (gcloud)GKE cluster
Run npx skills add google/skills, then select the specific skill from the repository during installation. The README does not document a separate command that installs only gke-multitenancy.
tmp="$(mktemp -d)"
git clone --depth 1 https://github.com/google/skills.git "$tmp"
mkdir -p ~/.claude/skills
cp -R "$tmp/skills/cloud/gke-multitenancy" ~/.claude/skills/
rm -rf "$tmp"Generated from the source repository and skill path; it copies only this skill's folder. If the author's install steps above differ, follow those first. To scope it to one project, replace ~/.claude/skills with that project's .claude/skills.
How do you use this skill?
Once installed, send your agent any of these to trigger it:
- Design a namespace-based multi-tenancy setup for teams sharing a GKE cluster, including RBAC, resource quotas, LimitRanges, default-deny networking, and cost labels.
After placing the skill where the Agent Skills client can discover it, use a request such as: “Design a namespace-based multi-tenancy setup for teams sharing a GKE cluster, including RBAC, resource quotas, LimitRanges, default-deny networking, and cost labels.” The source does not document client-specific trigger behavior.
What are this skill's strengths and limitations?
- Covers the main tenancy controls: namespaces, RBAC, quotas, default resource constraints, network segmentation, and cost attribution.
- Includes copyable kubectl, gcloud, and Kubernetes YAML examples.
- Gives a clear cost-efficiency starting point with namespace-per-team.
- Calls out the important requirement to define default and defaultRequest values when LimitRange min or max constraints are used.
- The material is configuration guidance and examples; no test suite or validation results are provided.
- Practical use depends on a GKE cluster, kubectl, gcloud, or the listed MCP tools, while complete authentication and environment setup are not documented.
- Full network-security and RBAC-hardening guidance is referenced in sibling skills rather than included here.
- Client-specific installation directories and invocation behavior are not documented.
How does this skill compare with similar options?
Side by side with related skills; every score comes from the same FSRS standard.
| Skill | FS score | Stars | Last updated | License |
|---|---|---|---|---|
| GKE Multi-Tenancy Planner this page ✓ Google · Official | 52 · Use with care | ★ 21k | 12d ago | Apache-2.0 |
| GKE Cost Optimization ✓ Google · Official | 47 · Use with care | ★ 21k | 12d ago | Apache-2.0 |
| GKE Platform Security Hardening ✓ Google · Official | 39 · Not recommended | ★ 21k | 12d ago | Apache-2.0 |
| GKE ComputeClasses Advisor ✓ Google · Official | 57 · Use with care | ★ 21k | 12d ago | Apache-2.0 |
| GKE Production Golden Path ✓ Google · Official | 54 · Use with care | ★ 21k | 12d ago | Apache-2.0 |
Compared with gke-basics and gke-app-onboarding, this skill focuses specifically on tenancy isolation, access control, quotas, and cost allocation for shared GKE clusters rather than single-tenant setup or general application deployment. It also compares namespace-per-team, namespace-per-environment, node-pool-per-team, and cluster-per-team models.
How did FollowSkills review this skill?
The skill promotes namespace-scoped least privilege, avoids binding system:authenticated, recommends Google Groups, quotas, and default-deny network policy, showing basic security awareness. It does not define user confirmation, credential or sensitive-data handling, data-flow disclosure, rollback, or change auditing; its listed delete_k8s_resource capability also lacks authorization boundaries, so points are deducted.
The namespace, RBAC, quota, LimitRange, NetworkPolicy, and cost-allocation paths are broadly coherent, and the LimitRange default-value caveat is useful. However, there are no tests, compatibility matrix, command failure handling, permission-check diagnostics, or abnormal-input feedback; static evidence does not support a higher score.
The scope clearly covers GKE multi-tenancy for teams or environments, RBAC, quotas, isolation, and cost allocation, while excluding single-tenant and general deployment work. Boundaries for cluster models, compliance-grade isolation, networking implementations, and Autopilot versus Standard are under-specified, and Chinese-language or mainland-China network fit is not addressed.
The document is organized around scenarios, tenancy models, configuration steps, and cost allocation, with YAML and command examples. Repository context supplies an Apache-2.0 license, installation method, issue path, and active-development notice. The skill lacks versioning, changelog, named maintenance responsibility, dependency notes, FAQs, and systematic limitations; its comparison table is also visibly malformed.
The commands and snippets are directly reusable starting points for namespaces, RBAC, quotas, LimitRanges, NetworkPolicy, and cost attribution, covering the core planning task. There is no complete end-to-end deployable output, verification procedure, rollback path, cloud prerequisites, or comprehensive safety validation, so substantial review and supplementation remain necessary.
Evidence consists mainly of the skill text plus repository README and license context. There are no committed tests, CI coverage, execution logs, third-party validation, or corroborating sources, so auditability is limited and the static score remains low.
Open a dimension to read why it scored that way
Evidence confidence：Low — Mostly static review, author material or a limited demo; useful for discovery, not high-risk decisions.
See the full review method →