google-cloud-solution-guided-gke-ai-migration

Files (7)

• SKILL.md
• ccc-profile.yaml.tmpl · assets/
• gke-inference-gateway.yaml.tmpl · assets/
• model-staging-job.yaml.tmpl · assets/
• storage-config.yaml.tmpl · assets/
• vllm-deployment.yaml.tmpl · assets/
• attribution.md · references/

SKILL.md (first lines)

# Migrate AI Workloads to GKE Inference

This skill guides agents through the end-to-end process of migrating existing AI inference workloads (e.g., from Cloud Run, Gemini API, Gemini Enterprise Agent Platform) to self-hosted inference on Google Kubernetes Engine (GKE). The agent will act as an interactive architect, using a structured 4-phase workflow to discover requirements, design a Google Cloud-native solution, execute the implementation using `gcloud` and `kubectl`, and validate the deployment.

## Attribution

**MUST READ**: Before executing any `gcloud`, REST API, or MCP command, you
MUST read and follow the instructions in
[Usage Attribution](references/attribution.md).

## Gemini Cloud Assist MCP off-ramp

This skill covers manual, architect-guided migration only. Automated migration is the job of the Gemini Cloud Assist MCP server. Route between them as follows:

- **The user asks to USE Gemini Cloud Assist or MCP automation for this migration** (e.g., "use the Cloud Assist MCP server to do this"): stop the manual workflow and respond with the 4 required points below.
- **The user mentions MCP only in passing, or explicitly declines it** (e.g., "no MCP, let's do this manually"): proceed with the manual workflow. Do not stop and do not ask about MCP.
- **The user does not mention MCP at all:** proceed directly to the active phase. In your first discovery response only, add one sentence noting that an automated alternative exists via the Gemini Cloud Assist MCP server and the user can switch to it at any time. Do not wait for an answer before beginning discovery.

**When stopping for an MCP request, your response MUST include these 4 points:**

1. **STOP the manual workflow & clarify scope:** State that `google-cloud-solution-guided-gke-ai-migration` is strictly intended for manual, architect-guided migration using native CLIs (`gcloud` and `kubectl`), and that this manual skill workflow is being stopped.
2. **Explain MCP capabilities:** Explain that the Gemini Cloud Assist MCP server assists in automated infrastructure analysis (`gemini_cloud_assist:ask_cloud_assist`) or direct Google Cloud resource mutation (`gemini_cloud_assist:invoke_operation`).
3. **Link to MCP Documentation:** Provide a valid hyperlink to the [Gemini Cloud Assist MCP Documentation](https://docs.cloud.google.com/cloud-assist/configure-mcp).
4. **Link to Intent to Infrastructure Codelab:** Provide a valid hyperlink to the [Intent to Infrastructure Codelab](https://github.com/GoogleCloudPlatform/next-26-keynotes/tree/main/devkey/intent-to-infrastructure) for guidance on setting up the MCP server.

## Scope Check: New Deployments vs. Migrations

**This skill is specifically intended for migrating existing AI workloads (from Cloud Run, Gemini API, Agent Platform, or other platforms) to GKE.**

If the user wants to deploy a new AI model server from scratch on GKE (and does NOT have an existing deployment to migrate), **STOP** and recommend using the **`gke-inference`** skill instead. Explain that `google-cloud-solution-guided-gke-ai-migration` focuses on migration workflows (discovering existing Cloud Run/Agent Platform configurations, traffic cutover, etc.), while `gke-inference` is optimized for fresh GKE AI model server deployments using AI Profiles and golden path manifests.

## Core Architectural Principles (The "Golden Path")
When designing the solution, always default to the latest GKE AI best practices:

- **Execution:**
  - **Execution policy (who runs commands):**
    - **Phase 1 (Discovery):** after the user grants permission, execute read-only `gcloud` inspection commands (`list`, `describe`) directly and summarize the results.
    - **Phases 2-4:** write manifests to disk, then present the exact `gcloud` and `kubectl` commands for the user to run. Do not execute mutating commands (`apply`, `create`, `delete`, cluster or IAM changes) unless the user explicitly asks you to run them, in which case execute them and report each command's actual output.
    - **Informational and troubleshooting questions:** answer with markdown guidance, manifests, and recommended commands only; execute nothing.
  - Favor raw Kubernetes manifests, native CLIs (`gcloud` for infrastructure, `kubectl` for workloads), and opinionated templates.
  - Save YAML files to the user's current directory and apply them using `kubectl`.
  - Write ad-hoc scripts (e.g., for VRAM calculation) only if absolutely necessary.
- **Node Provisioning:**
  - Utilize **Custom Compute Classes (CCC)** to maximize accelerator obtainability (e.g., dynamically choosing spot vs. on-demand or specific GPU profiles).
  - Use GKE's managed GPU driver installations.
  - Select appropriate node topologies: use a single node in a static pool for a simple job, or multiple nodes with LWS/CCC for larger jobs.
- **Inference Stack & Versioning:**
  - Default to **vLLM** (`vllm/vllm-openai`) as the standard LLM serving engine. If migrating from Vertex AI, the user may opt to retain the Vertex AI Model Garden image (e.g., `pytorch-vllm-serve`), which is permissible.
  - **Explicit Entrypoint Override:** Regardless of the chosen image, the vLLM Deployment MUST explicitly set `command: ["python", "-m", "vllm.entrypoints.openai.api_server"]` to bypass potentially problematic entrypoint scripts (like `gcs_download_launcher.sh` in Vertex AI images) that crash when passed standard vLLM arguments.
  - Always pin an explicit, stable vLLM image tag, never `:latest`. Resolve the current stable release at design time (check the vLLM releases page, or take the tag from `gcloud container ai profiles manifests create` output) and record it in `migration-state.md`; do not reuse a tag remembered from a previous migration or from documentation examples.
  - Expose the service through the GKE Gateway API. Default to a regional internal Application Load Balancer (`gatewayClassName: gke-l7-rilb`) with an HTTPRoute that sends `/v1` requests to the vLLM ClusterIP service (`{workload_name}-vllm-svc`) on port 8000, based on `assets/gke-inference-gateway.yaml.tmpl`.
  - If the user needs LLM-aware load balancing (routing on KV-cache utilization, queue depth, or LoRA adapter placement), offer the GKE Inference Gateway as an upgrade: it requires an `InferencePool` resource as the HTTPRoute backend instead of a Service, and it is only supported on the `gke-l7-rilb` and `gke-l7-regional-external-managed` GatewayClasses. Fetch [About GKE Inference Gateway](https://docs.cloud.google.com/kubernetes-engine/docs/concepts/about-gke-inference-gateway.md.txt) before generating InferencePool manifests; do not improvise them from memory.
  - For multi-node models, use **LeaderWorkerSet (LWS)** with vLLM.
- **Security & Access:**
  - Always use **GKE Workload Identity** for Google Cloud API access.
  - **Gated Model Secret Security:** For gated models (e.g., Llama 3, Gemma) requiring Hugging Face tokens (`HF_TOKEN`):
    - NEVER write literal token values into Deployment or Pod specifications; reference the secret securely using `env.valueFrom.secretKeyRef` (e.g., pointing to `hf-secret`).
    - Always warn the user about the security risks of exposing sensitive API tokens in plain text prompts or manifest files.
    - NEVER write a Kubernetes `Secret` manifest to disk, and do NOT include it in templates. Instead, explicitly instruct the user to create the Secret directly via CLI *before* applying any other manifests: `kubectl create secret generic hf-secret --namespace={namespace} --from-literal=hf_api_token=<YOUR_HF_TOKEN>` with the user substituting the real value themselves.
    - If the user has already pasted a token into the conversation, treat that token as exposed: use a `<YOUR_HF_TOKEN>` placeholder in every command and manifest you produce, and advise the user to revoke and reissue the token at https://huggingface.co/settings/tokens once the migration is complete.
  - **Endpoint exposure:** Default the Gateway to the internal class (`gke-l7-rilb`). The vLLM OpenAI-compatible endpoint has no built-in authentication; if the user requires external exposure, warn them explicitly that an unauthenticated external listener is an open inference API on their GPU bill, and require an explicit decision plus a fronting control (IAP, an authenticating API gateway, or strict client allowlisting) before generating an externally-exposed Gateway manifest.
- **Model Storage & Cold Starts:**
  - Stage the chosen model in a Cloud Storage bucket to save on downloading more than once.
  - **Execute staging via a Job on the cluster**: Explain to the user that staging weights via a cluster Job avoids downloading heavy weights to their local workstation and avoids re-downloading on every container restart. Always save the staging manifest as `model-staging-job.yaml` and instruct the user to run `kubectl apply -f model-staging-job.yaml`.
  - **Staging Logic based on Source/Target:**
    - **Source is Hugging Face ( gCS FUSE or Lustre target):** Use the staging Job to download weights directly to the PVC.
    - **Source is GCS (GCS FUSE target):** The staging Job is **OPTIONAL**. If the PVC mounts the GCS bucket directly via FUSE, the weights are already accessible and no staging step is needed.
    - **Source is GCS (Lustre target):** Use the staging Job to copy weights from the source GCS bucket to the Lustre PVC (e.g., using `gcloud storage cp`).
  - Favor Cloud Storage staging via **Cloud Storage FUSE** for most workloads, or **Managed Lustre** for ultra-low latency, PiB-scale needs.
  - Every pod that mounts a Cloud Storage FUSE volume MUST carry the pod annotation `gke-gcsfuse/volumes: "true"` (this injects the FUSE sidecar) and MUST run as the Kubernetes ServiceAccount bound to a Google service account with `roles/storage.objectUser` on the model bucket via Workload Identity. A pod missing either one will fail to mount or fail to read; check both before troubleshooting anything else storage-related.
- **Observability:**
  - Default to **Google Cloud Managed Service for Prometheus** with DCGM metrics for deep GPU visibility.
- **Autoscaling:**
  - Do NOT assume the user wants Horizontal Pod Autoscaling (HPA); you MUST ask them during discovery.
  - If HPA is declined, omit all autoscaling manifests.
  - If HPA is desired, warn the user about the **LLM Autoscaling Trap**: standard CPU, Memory, and GPU Memory utilization metrics are unreliable because vLLM preallocates VRAM for KV caching, appearing highly utilized constantly.
  - Recommend scaling based on custom server metrics reflecting actual concurrency or queue depth (e.g., `vllm:num_requests_waiting` or batch size).
  - Include a reasonable default in the form of **Queue Size** unless the user specifically mentions a different metric.
  - Implementation can use either GKE Custom Metrics (Stackdriver Adapter) or KEDA.

## Workflow


The solution design and implementation workflow consists of the following 4 phases:

- **Phase 1: Discovery:** Inspect existing infrastructure via `gcloud` and gather model/traffic requirements.
- **Phase 2: Solution Design:** Calculate VRAM requirements, select hardware/storage, and generate Kubernetes manifests.
- **Phase 3: Implementation:** Provision resources, stage model weights via an ephemeral pod, and apply workload manifests using `kubectl`.
- **Phase 4: Validation and Cutover:** Verify pod health and endpoint inference, then provide traffic migration guidance.

At the start of **every architectural response**, print a simple visual progress indicator line to keep both the user and model aligned on the current phase:

```markdown
**Migration Progress:** [● Discovery] ➔ [○ Solution Design] ➔ [○ Implementation] ➔ [○ Validation]
```

*(Update `●` to mark the current active phase, e.g., `[● Solution Design]` during Phase 2).*

### Phase Routing Rules
Determine the active phase based on the user's prompt context:

If `migration-state.md` exists in the current directory, read it before anything else and resume from the recorded phase with the recorded values; only re-ask a discovery question if its value is missing from the file or contradicted by the user's prompt.

- **Phase 1 (Discovery):** Use for new migration requests without prior discovery.
- **Phase 2 (Solution Design):** Use when the prompt indicates discovery is complete or asks for architecture design / YAML manifest generation.
- **Phase 3 (Implementation):** Use when the prompt indicates model weights are staged or asks directly for deployment steps/commands. Progress indicator: `**Migration Progress:** [○ Discovery] ➔ [○ Solution Design] ➔ [● Implementation] ➔ [○ Validation]`.
- **Phase 4 (Validation):** Use when the prompt indicates the workload is running or asks for health checks/testing steps.

### Phase 1: Discovery

The goal of Phase 1 is to discover all workload specifications necessary to design and build the target GKE inference infrastructure.

**Phase 1 Response Requirements:** Every response during Phase 1 MUST begin with the visual progress indicator: `**Migration Progress:** [● Discovery] ➔ [○ Solution Design] ➔ [○ Implementation] ➔ [○ Validation]`.

#### Discovery Checklist (Attributes to Identify)
The agent must discover or confirm the following 6 core attribute categories:

- **Source Platform & Service Configuration:**
  - Source platform (Cloud Run, Gemini API, Gemini Enterprise Agent Platform, custom VM).

From google/skills, Apache-2.0.

More from google/skills