Skip to content
Get packs

Guide · Agent skill

How to use the GKE Multi-Tenancy Planner agent skill

Updated · written with AI from the project's own documentation and checked against our catalogue data

The gke-multitenancy skill gives an AI agent guidance for sharing one Google Kubernetes Engine (GKE) cluster among several teams or environments. It helps you pick an isolation model, writes example Kubernetes manifests for namespaces, role-based access, quotas, limits and network policies, and shows how to turn on GKE cost allocation. This guide explains what the skill does, how to install it, how to ask for it, and what to check before running anything against a live cluster.

GKE Multi-Tenancy Plannergoogle/skills · Apache-2.0

Quick start

  1. 1Download the ZIP. Download the gke-multitenancy ZIP from this page. It is licensed under Apache-2.0.
  2. 2Unzip into a skills folder. Unzip it into ~/.claude/skills/ for personal use, or into .claude/skills/ in a project.
  3. 3Check the files. Confirm that SKILL.md and references/attribution.md are present in the gke-multitenancy folder.
  4. 4Prepare the tools. Install gcloud and kubectl, and make sure you can reach the target GKE cluster with permission to update it.
  5. 5Ask for a plan. Describe your teams and goals in plain language, such as sharing a cluster among three teams with quotas.
  6. 6Review the commands. Read each kubectl and gcloud command and manifest before allowing it to run, starting with a non-production cluster.
  7. 7Enable cost allocation. If you need cost breakdowns, label namespaces and run the gcloud update with --enable-cost-allocation, then view results under Cloud Billing > GKE Cost Allocation.

What is an agent skill and what does this one do?

An agent skill is a folder containing a SKILL.md file and optional reference files. When installed, the agent reads the skill when your request matches its description, and follows its instructions and examples. This skill is named gke-multitenancy and is categorised under Containers.

Once active, the agent can plan multi-tenancy on GKE. It covers namespace isolation, RBAC planning for teams, resource quotas, LimitRanges, network isolation and cost allocation.

  • Compares four models: namespace-per-team, namespace-per-environment, node pool-per-team and cluster-per-team, with isolation, complexity and cost for each.
  • Recommends starting with namespace-per-team and escalating only when compliance requires stronger isolation.
  • Writes example Role and RoleBinding manifests that bind to Google Groups.
  • Writes example ResourceQuota and LimitRange manifests.
  • Writes an example NetworkPolicy that allows same-namespace traffic and DNS.
  • Shows how to label namespaces for cost attribution and enable GKE cost allocation.

Install the skill in Claude

You can install the skill in one of three places. Download the ZIP file from this page and unzip it into a skills folder. For a personal install, use ~/.claude/skills/. For a single project, use the .claude/skills/ folder inside that project. Alternatively, upload the ZIP in the Claude apps under Settings → Capabilities → Skills.

After unzipping, the folder should contain SKILL.md and references/attribution.md. If the agent does not seem to use the skill, check that SKILL.md sits directly inside the gke-multitenancy folder.

  • Personal: ~/.claude/skills/
  • Project: .claude/skills/ inside your repository
  • Claude apps: Settings → Capabilities → Skills, then upload the ZIP

Trigger the skill with natural requests

You do not need a special command. The skill's description tells the agent when to use it, so ask in plain terms about the goal. Phrases from the description include designing GKE multi-tenancy, configuring GKE namespaces, setting up resource quotas and isolating GKE teams.

The skill is not meant for single-tenant clusters or general deployment instructions. For those, the description points to the gke-basics or gke-app-onboarding skills instead.

  • "Design a multi-tenancy setup on our GKE cluster for three teams."
  • "Set up resource quotas for the team-a namespace."
  • "Which isolation model should we use for dev, staging and prod in one cluster?"
  • "Help me turn on cost allocation so we can see costs by namespace."

Requirements and what the agent will run

The skill expects the gcloud CLI and kubectl, with access to the target GKE cluster. You also need a Google Cloud account with permission to update the cluster. The skill's instructions reference MCP Kubernetes tools named apply_k8s_manifest, get_k8s_resource, check_k8s_auth, describe_k8s_resource and delete_k8s_resource, but those tools are not defined in the skill files, so you must provide them yourself if you want the agent to use them.

Before any gcloud, REST API or MCP command, the skill tells the agent to read its attribution reference and tag the command with an environment variable that identifies the skill and its version.

  • gcloud CLI
  • kubectl with access to the GKE cluster
  • Google Cloud account with permission to update the cluster
  • MCP Kubernetes tools (referenced but not defined in the files)
gcloud container clusters update <CLUSTER_NAME> --region <REGION> \ --enable-cost-allocation

Safety notes before you run anything

This skill runs scripts and uses the network. Its commands change live infrastructure: kubectl creates namespaces, labels, roles and quotas, and gcloud updates the cluster. Review every command before it runs, and test in a non-production cluster first.

The skill itself says namespace-level separation is soft isolation. If you need hard security isolation or strict compliance, consider a node pool or cluster-per-team model, and check with your security team. The skill also points to gke-platform-security for RBAC hardening and gke-workload-security for default-deny network policies.

  • Review each kubectl and gcloud command before approving it.
  • Test in a non-production cluster first.
  • Do not treat namespace separation as hard isolation for compliance.
  • Confirm the LimitRange rule: if you set min or max, also set default and defaultRequest, or pods without explicit resources will be rejected.

Tips for getting useful output

Give the agent your cluster's situation: how many teams, whether you have environments in one cluster, and whether you need cost reports. The skill's golden path is namespace-per-team, so state early if you need a stronger model.

Ask for manifests to be reviewed rather than applied directly. The manifests are examples, so replace placeholders such as team names and Google Group addresses with your own values.

  • Name your teams and their Google Group addresses up front.
  • Ask for a plan first, then the manifests, then the apply commands separately.
  • Remember the NetworkPolicy example allows DNS to kube-dns, so check it against your cluster setup.

What people use it for

  • Setting up namespace-per-team isolation for several engineering teams on one GKE cluster.
  • Creating ResourceQuota and LimitRange manifests so no single team can consume all cluster resources.
  • Planning dev, staging and prod separation inside one shared cluster.
  • Labelling namespaces with cost-center values and enabling GKE cost allocation for billing breakdowns.
  • Drafting a default-deny-style NetworkPolicy that allows same-namespace traffic and DNS.

Frequently asked questions

How do I install the gke-multitenancy agent skill?

Download the ZIP from this page and unzip it into ~/.claude/skills/ for personal use or .claude/skills/ inside a project. You can also upload the ZIP in the Claude apps under Settings → Capabilities → Skills.

Is the gke-multitenancy skill free?

The skill is licensed under Apache-2.0, as stated on this page. The skill itself does not describe pricing, but running GKE and its cost allocation is billed under your Google Cloud account.

What do I need to use this skill?

You need the gcloud CLI, kubectl with access to the target GKE cluster, and a Google Cloud account with permission to update the cluster. The MCP Kubernetes tools it references are not defined in the skill files.

Is it safe to run on a production cluster?

The skill issues kubectl and gcloud commands that change live infrastructure, so it should not be run unreviewed against production. Test in a non-production cluster first and review every command.

Does this skill provide hard isolation between teams?

No. The skill describes namespace-level separation as soft isolation. For hard isolation or strict compliance, it points to stronger models such as node pool-per-team or cluster-per-team.

Should I use this skill for a single-team cluster?

No. The skill is aimed at shared clusters and its description says not to use it for single-tenant cluster configuration. Use gke-basics or gke-app-onboarding for general deployment instructions.

New agent skills, repos and AI tools — every week

The best new skills and open-source projects, the fastest-growing repos, and one free prompt. Five minutes to read. Unsubscribe anytime.

Our verdict

This skill suits platform or DevOps engineers who run one shared GKE cluster for several teams and want a clear starting point for namespaces, quotas and cost breakdowns. It is not the right choice for single-team clusters, for strict compliance needs that require hard isolation, or for anyone who wants changes applied to production without review.

Download the skill