Menu
Guidance on implementing multi-tenancy and governance in Google Kubernetes Engine (GKE) clusters.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
Systematically diagnose GKE JobSet interruptions, restarts, and preemptions for AI/ML training workloads. Identifies preemption events, maintenance interruptions, bad host VMs, unhealthy pods, and coordinator worker failures.
Diagnose and predict node disruption during Compute Engine host maintenance for GPU and TPU workloads.
Diagnose and prevent `vbar_control_agent` segfaults and OOMs caused by race conditions during TPU device resets and frequent metrics collection (e.g. every 3s). Use when TPU slice initialization fails or `vbar_control_agent` crashes on TPU v6e nodes.
Verifies if a GKE or Kubernetes cluster is unused (no active compute, external exposure, or persistent data) before allowing deletion. Evaluates external exposure (LoadBalancer Service, Ingress, Gateway, MultiClusterIngress), persistent data (Bound PVC), and active compute (Running/Pending Pods in user namespaces) with low-overhead queries and fail-close timeouts.
Monitor and manage GKE TPU Dynamic Slices custom resources. Use when checking slice lifecycle states, troubleshooting failed slice creations (e.g. SliceCreationFailed, FAILED), running single or multi-slice workloads, or safely deleting/disabling slices.
Monitor and troubleshoot GKE TPU workloads using GKE system metrics and PromQL.
| name | gke-multi-tenancy |
| description | Guidance on implementing multi-tenancy and governance in Google Kubernetes Engine (GKE) clusters. |
This skill provides guidance on implementing multi-tenancy and governance in Google Kubernetes Engine (GKE) clusters.
Multi-tenancy allows you to share a single GKE cluster among multiple teams or applications securely. Governance ensures that policies and resource limits are enforced.
Namespaces provide a scope for names and are the primary unit of isolation in Kubernetes.
Steps:
Example Namespace Manifest:
apiVersion: v1
kind: Namespace
metadata:
name: tenant-a
labels:
team: alpha
Role-Based Access Control (RBAC) allows you to control who has access to what resources within a namespace.
Steps:
Role with specific permissions.Role to a user or group using a RoleBinding.Example Role and RoleBinding Manifest:
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: tenant-a
name: pod-reader
rules:
- apiGroups: [""] # "" indicates the core API group
resources: ["pods"]
verbs: ["get", "watch", "list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: read-pods
namespace: tenant-a
subjects:
- kind: User
name: user@example.com # Name is case sensitive
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: pod-reader
apiGroup: rbac.authorization.k8s.io
Resource quotas prevent a single tenant from consuming all resources in the cluster.
Example ResourceQuota Manifest:
apiVersion: v1
kind: ResourceQuota
metadata:
name: tenant-a-quota
namespace: tenant-a
spec:
hard:
requests.cpu: "2"
requests.memory: 4Gi
limits.cpu: "4"
limits.memory: 8Gi