Siempre Listo Escuela
← Volver al listado de tecnologías ← Índice de Google Skills

Skills de infraestructura: GKE, Cloud Run y Firebase

Por: Artiko
agent-skillsplugins-de-agentesia-agentesgoogle-cloudgkekubernetescloud-runfirebase

Skills de infraestructura: GKE, Cloud Run y Firebase

Si el capítulo anterior mostró la parte más vistosa del catálogo —los 18 skills de AI/ML—, este muestra la parte más densa. GKE es, de lejos, el producto con más superficie cubierta en google/skills: 28 directorios cuyo nombre empieza por gke- dentro de skills/cloud/. Ningún otro producto se acerca.

A eso se suman dos skills de hosting de aplicaciones que el README agrupa aparte: cloud-run-basics y firebase-basics.

Recuerda que el repositorio se declara under active development: los conteos y las rutas de este capítulo corresponden al estado del clon analizado y pueden cambiar.

Primer aviso: “Infrastructure” no es lo que parece

El README organiza el catálogo en 12 secciones. La sección Infrastructure tiene 23 entradas, pero no son 23 skills de GKE:

Composición de la sección InfrastructureCantidad
Skills gke-*20
google-cloud-global-frontend-configuration1
google-cloud-networking-observability1
google-cloud-storage-basics1
Total23

Y a la inversa: hay 8 skills gke-* que no están en Infrastructure. El README los reparte por función, no por producto:

  • Management tools contiene gke-cost-analysis, gke-cost-optimization, gke-observability, gke-tpu-metrics-monitoring, gke-ai-troubleshooting-handle-disruption-gpu-tpu y gke-ai-troubleshooting-tpu-vbar-oom.
  • Security and identity contiene gke-platform-security y gke-workload-security.

20 + 6 + 2 = 28, que cuadra con el árbol real.

Cloud Run y Firebase tampoco están en Infrastructure: viven en la sección Web and app hosting, que tiene exactamente dos entradas.

flowchart TD
    R[README de google/skills] --> I[Seccion Infrastructure - 23 entradas]
    R --> M[Seccion Management tools - 13 entradas]
    R --> S[Seccion Security and identity - 3 entradas]
    R --> W[Seccion Web and app hosting - 2 entradas]
    I --> I1[20 skills gke-*]
    I --> I2[3 skills de red y storage no GKE]
    M --> M1[6 skills gke-* de costo y observabilidad]
    S --> S1[2 skills gke-* de seguridad]
    W --> W1[cloud-run-basics]
    W --> W2[firebase-basics]

Si buscas un skill de GKE por la sección del README y no lo encuentras, búscalo por prefijo de directorio. Es la única vista fiable, como vimos en el mapa del catálogo.

El árbol completo de GKE

Los 28 directorios, verificados con ls:

skills/cloud/
├── gke-ai-troubleshooting-handle-disruption-gpu-tpu/
├── gke-ai-troubleshooting-jobset-interruption/
├── gke-ai-troubleshooting-tpu-vbar-oom/
├── gke-app-onboarding/
├── gke-backup-dr/
├── gke-basics/
├── gke-batch-hpc/
├── gke-cluster-autoscaler/
├── gke-cluster-creation/
├── gke-compute-classes/
├── gke-cost-analysis/
├── gke-cost-optimization/
├── gke-golden-path/
├── gke-inference/
├── gke-manifest-generation/
├── gke-multitenancy/
├── gke-networking/
├── gke-observability/
├── gke-platform-security/
├── gke-productionize/
├── gke-reliability/
├── gke-service-networking/
├── gke-storage/
├── gke-tpu-metrics-monitoring/
├── gke-upgrades/
├── gke-workload-scaling/
├── gke-workload-security/
└── gke-workload-troubleshooting/

Agrupados por ciclo de vida:

FaseSkills
Diseño y creación de clustergke-basics, gke-golden-path, gke-cluster-creation, gke-networking
Llevar la app al clustergke-app-onboarding, gke-manifest-generation, gke-service-networking, gke-storage
Escalado y capacidadgke-workload-scaling, gke-cluster-autoscaler, gke-compute-classes, gke-batch-hpc
Cargas de AI/MLgke-inference, gke-tpu-metrics-monitoring, los tres gke-ai-troubleshooting-*
Producción y operacióngke-productionize, gke-reliability, gke-upgrades, gke-observability, gke-backup-dr
Seguridad y aislamientogke-platform-security, gke-workload-security, gke-multitenancy
Costogke-cost-analysis, gke-cost-optimization
Diagnósticogke-workload-troubleshooting

gke-basics: el skill de gotchas críticos

El título interno del SKILL.md es literal: “GKE Basics & Critical Gotchas”. Y es un buen ejemplo de que un skill útil no necesita ser largo: son 70 líneas de SKILL.md más cinco references/.

Su description delimita la frontera con cirugía:

Don't use for specialized GKE networking (use gke-networking), advanced security
hardening (use gke-platform-security or gke-workload-security), or cluster
upgrades (use gke-upgrades).

Lo primero que fija es una postura por defecto: “Defaults to Autopilot mode unless Standard is explicitly required”. Y enumera los tres únicos motivos válidos para elegir Standard:

  • parámetros de kernel del nodo mediante sysctl,
  • taints personalizados o node pools de hardware específico,
  • DaemonSets que necesitan montajes hostPath crudos al sistema de archivos del host.

Además exige justificar la desviación: “explicitly cite all matching restrictions”.

Los cuatro gotchas críticos que documenta:

  1. Clusters Autopilot privados: --enable-private-nodes para IPs privadas de nodo, --enable-private-endpoint para quitar la IP pública del control plane, y --enable-master-authorized-networks con --master-authorized-networks=CIDR_BLOCK.
  2. Workload Identity: “Never mount raw GCP Service Account JSON keys in Pods”. En su lugar, anotar la ServiceAccount de Kubernetes con iam.gke.io/gcp-service-account.
  3. Requests en Autopilot: las CPU requests deben ir en incrementos de 250m. Si el usuario pide 300m, el skill instruye redondear hacia arriba a 500m. Y como en Autopilot los requests igualan a los limits automáticamente, recomienda omitir limits.
  4. Credenciales: siempre pasar --region o --zone explícitos al hacer get-credentials.
gcloud container clusters create-auto CLUSTER_NAME --region=REGION \
  --enable-private-nodes \
  --enable-private-endpoint \
  --enable-master-authorized-networks \
  --master-authorized-networks=CIDR_BLOCK

Sus cinco references/ reparten el detalle: core-concepts.md, cli-reference.md, client-library-usage.md, mcp-usage.md e iac-usage.md. El de MCP describe “the 23 structured GKE MCP tools”, y cli-reference.md documenta una jerarquía de preferencia de herramientas que reaparece en varios skills de GKE.

gke-golden-path y gke-cluster-creation: el “camino dorado”

gke-golden-path es la tabla de valores por defecto que el resto de skills asume. Sus reglas son cuatro y merecen leerse enteras:

  1. Default to the golden path: usar los valores del camino dorado salvo petición explícita; al desviarse, anotar el trade-off pero respetar la decisión del usuario.
  2. Day-0 vs Day-1: marcar de forma prominente las decisiones Day-0 —networking, nodos privados, subredes, asignación de IPs— porque son “hard/impossible to change after creation”.
  3. Tool preference: MCP > gcloud > kubectl, porque MCP habla directo con las APIs de GKE con datos estructurados y reduce errores de sintaxis de shell. Si el usuario dice “usa gcloud”, se respeta durante la sesión.
  4. Documentar decisiones y su justificación.

Los valores por defecto que aplica siempre incluyen autopilot.enabled: true, privateClusterConfig.enablePrivateNodes: true, secretManagerConfig.enabled con rotationInterval: 120s, networkConfig.datapathProvider: ADVANCED_DATAPATH, dnsConfig.clusterDns: CLOUD_DNS, autoscalingProfile: OPTIMIZE_UTILIZATION, verticalPodAutoscaling.enabled: true y enableSecureBoot: true. Trae además un assets/golden-path-autopilot.yaml listo para copiar.

gke-cluster-creation es el ejecutor. Su descripción menciona cuatro plantillas: Autopilot, Standard Regional, GPU/AI Inference y AI Hypercompute. Su workflow de 8 pasos termina siempre igual: “Verify: Use get_cluster with readMask=”*” to confirm golden path settings applied”. Es decir, verificación posterior explícita, no confianza ciega en el comando de creación.

gke-app-onboarding: de código a Pod

Este es el skill que el enunciado del capítulo pide mirar de cerca, y es el mejor ejemplo del patrón workflow numerado + assets.

Estructura real:

gke-app-onboarding/
├── SKILL.md
└── assets/
    ├── deployment.yaml
    ├── Dockerfile
    ├── index.js
    └── package.json

Los assets/ no son documentación: son una aplicación Node.js mínima completa con su Dockerfile y su Deployment, para que el agente tenga un punto de partida ejecutable.

El workflow tiene cinco pasos:

  1. App Assessment: antes de contenerizar, evaluar lenguaje y framework, dependencias, configuración, si es stateful, puertos y protocolo, y si expone endpoints de health.
  2. Containerization: Dockerfile multi-stage con imagen base distroless y USER nonroot:nonroot. Buenas prácticas explícitas: imágenes mínimas, no ejecutar como root, y “Log to stdout and stderr for Cloud Logging collection”. Ofrece también Cloud Native Buildpacks con pack build <image> --builder gcr.io/buildpacks/builder:latest para quien no quiera escribir Dockerfile.
  3. Image Management: gcloud auth configure-docker <REGION>-docker.pkg.dev, build y push a Artifact Registry, más escaneo de vulnerabilidades con --show-package-vulnerability.
  4. Manifest Generation: Deployment más Service con un checklist de cuatro puntos —requests y limits, probes de liveness y readiness, mínimo 2 réplicas en producción, y tipo de Service adecuado (ClusterIP interno, Gateway API para externo).
  5. Deploy: primero las herramientas MCP apply_k8s_manifest, get_k8s_rollout_status y get_k8s_resource; kubectl aparece explícitamente etiquetado como fallback.

Y cierra con una sección Next Steps que enumera los cuatro skills siguientes por nombre: gke-workload-scaling, gke-observability, gke-workload-security y gke-reliability. Esa lista es, en la práctica, un grafo de encadenamiento escrito a mano.

gke-inference: modelos servidos sobre GKE

Ya lo rozamos en el capítulo de AI/ML; aquí lo vemos desde la infraestructura. Su categoría interna no es AiAndMachineLearning sino Containers, lo que confirma que el criterio de clasificación es el producto operado, no el dominio del problema.

El corazón del skill es Inference Quickstart (GIQ), expuesto por CLI. El flujo es descubrir, generar y desplegar:

# Descubrir modelos soportados
gcloud container ai profiles models list --quiet

# Combinaciones validas de acelerador y servidor para un modelo
gcloud container ai profiles list --model=gemma-2-9b-it --quiet

# Generar el manifiesto optimizado
gcloud container ai profiles manifests create \
  --model=gemma-2-9b-it \
  --model-server=vllm \
  --accelerator-type=nvidia-l4 \
  --target-ntpot-milliseconds=50 --quiet > inference.yaml

--target-ntpot-milliseconds es el objetivo de Normalized Time Per Output Token: latencia por token generado, no latencia de request. El skill anota que estos comandos son CLI-only, sin equivalente MCP, a diferencia del resto de operaciones de GKE.

Su tabla de aceleradores cubre desde NVIDIA T4 (16 GB, costo más bajo) hasta GB200/A4X, pasando por L4 en G2, RTX PRO 6000 en G4 con 96 GB, y las TPU v5e, v5p, v6e Trillium con 32 GB por chip y v7x Ironwood con 192 GB por chip.

Los cuatro gotchas de troubleshooting que documenta:

ProblemaCausaSolución del skill
Combinación modelo/acelerador inválidaTupla no soportadaRe-ejecutar gcloud container ai profiles list --model=<MODEL>
Cuota de GPU excedidaLímite regionalPedir aumento de cuota o cambiar de región
OOM en GPUModelo demasiado grandeGPU mayor, cuantización o tensor parallelism
Arranque en frío lentoCarga del modelo desde el registryLocal SSD para cachear el modelo y pre-pull de imágenes

Y una advertencia práctica sobre autoescalado: “LLM model loading is slow; use longer stabilization windows”. También sugiere escalar por profundidad de cola en vez de por utilización de GPU cuando la latencia importa.

gke-backup-dr: el gotcha que evita colgar la sesión

Este skill son 68 líneas sin references/ ni assets/, y aun así contiene uno de los gotchas más interesantes del catálogo entero.

Su alcance: proteger cargas stateful con Backup for GKE, que captura tanto los recursos de Kubernetes —manifiestos, configuraciones y secrets— como los datos de los volúmenes persistentes.

El bloque de comandos cubre el ciclo completo: habilitar el addon, crear Backup Plan con --retention-days y --cron-schedule, disparar un backup manual, crear un Restore Plan y ejecutar el restore.

Sus cinco buenas prácticas:

  1. CMEK: cifrar los planes con --backup-encryption-key=<KEY>.
  2. Alcance: preferir --included-namespaces=<ns1>,<ns2> sobre respaldar el cluster completo.
  3. Consistencia de aplicación: recomendar quiescing de la base de datos o pausa de escrituras antes del backup.
  4. CSI Volume Snapshots: asegurar que los backups stateful usen el driver CSI para capturar los datos del volumen.
  5. Terminología: siempre decir Backup for GKE, para distinguirlo del servicio más amplio Backup and Disaster Recovery de Google Cloud.

Y el gotcha, marcado como > [!IMPORTANT] y CRITICAL:

Enabling GKE Backup (--enable-gke-backup) triggers a slow Google Cloud control
plane cluster update that takes several minutes.
* Rule: Do not run a terminal loop waiting for the GKE Backup addon to become active.
* Action: Provide the command to enable the addon, explain that the operation will
  proceed in the background, and immediately proceed to write the backup plan
  configs. Do not block.

Es una instrucción de comportamiento del agente, no de infraestructura. Alguien vio a un agente quemar contexto en un bucle de sleep y describe durante diez minutos, y lo escribió en el skill. Este tipo de regla es exactamente lo que el formato SKILL.md permite capturar y que la documentación de producto no captura; el mecanismo está explicado en el curso hermano de Agent Skills.

Cloud Run Basics: la regla que salva el despliegue

cloud-run-basics es el SKILL.md más largo de los tres de este capítulo: 381 líneas, con siete references/.

Modela Cloud Run en tres tipos de recurso, y esa taxonomía gobierna todo el skill:

RecursoPara qué
ServicesResponden a peticiones HTTP en un endpoint estable, con instancias sin estado que autoescalan
JobsTareas paralelizables que se ejecutan manualmente o por calendario y corren hasta completarse
Worker poolsCargas de fondo siempre activas de tipo pull: consumidores de Kafka, colas pull de Pub/Sub, consumidores de RabbitMQ

El gotcha central va marcado como CRITICAL RULE y es el error número uno de quien despliega en Cloud Run por primera vez:

Any deployed code MUST listen on 0.0.0.0 (not 127.0.0.1) and use the injected
$PORT environment variable (defaults to 8080), or it will crash on boot.

Otros detalles operativos que documenta y que no son obvios:

  • Cloud Run importa la imagen durante el despliegue y conserva esa copia mientras una revisión la use. Las imágenes no se vuelven a traer del registry cuando arranca una instancia nueva.
  • Las imágenes de Docker Hub se cachean hasta una hora; Google recomienda Artifact Registry, y para registries externos, un remote repository de Artifact Registry.
  • Los roles necesarios son cuatro: roles/run.admin, roles/run.sourceDeveloper, roles/iam.serviceAccountUser sobre la identidad del servicio y roles/logging.viewer. Y para que Cloud Build compile, hay que darle roles/run.builder.
  • En Jobs, cada tarea recibe CLOUD_RUN_TASK_INDEX y CLOUD_RUN_TASK_COUNT. --tasks llega a 10.000, --max-retries acepta de 0 a 10 con default 3, y --task-timeout va hasta 168 horas —salvo tareas con GPU, donde el máximo es 1 hora.

El skill cierra con un triaje de fallos de despliegue de tres ramas:

flowchart TD
    F[Fallo en gcloud run deploy] --> A{Tipo de error}
    A -->|IAM o permisos| B[Leer references/iam-security.md]
    A -->|Crash al arrancar o healthcheck| C[gcloud logging read con filtro por service_name y limit 20]
    A -->|Dependencia nativa Node o Python| D[Cambiar --no-build por --source y usar Buildpacks]

La rama de dependencias nativas es fina: si usas --no-build y tu paquete compila extensiones nativas, el binario no queda compilado para Linux; volver a Buildpacks lo arregla.

Firebase Basics: un skill que instala otros skills

firebase-basics es el caso más raro del capítulo. Su description es agresivamente restrictiva:

Use ONLY for CLI login, project creation/switching, or downloading app config
files. Don't use for Firebase Hosting deploy, Firestore, Auth, App Hosting,
Data Connect, Crashlytics, or Remote Config.

Es decir: cubre el arranque y nada más. Pero buena parte de sus 19 archivos de references/ no son sobre Firebase: son sobre entornos de agente. Tiene un references/setup/ con un archivo por harness —gemini_cli.md, antigravity.md, android_studio.md, claude_code.md, cursor.md, github_copilot.md, other_agents.md— y un references/refresh/ con cinco equivalentes para actualizar esa instalación —gemini-cli.md, antigravity.md, android_studio.md, claude.md, other-agents.md—. Los siete restantes sí son de Firebase: firebase-cli-guide.md, firebase-service-init.md, local-env-setup.md y las guías por plataforma android_setup.md, ios_setup.md, web_setup.md y flutter_setup.md.

La instrucción que lo explica todo:

DO NOT SKIP this step: if 'firebase-basics' is the only Firebase skill available
to you, you must follow the reference for your agent environment to set up the
full suite of Firebase skills.

firebase-basics es un bootstrap: detecta que es el único skill de Firebase presente y guía la instalación del resto. El propio SKILL.md remata con npx skills add genkit-ai/skills para Genkit. Coherente con esto, el README de google/skills enlaza repositorios externos con más skills de Google: Flutter, Dart, Advanced Google Cloud Storage, ADK, Firestore y Genkit.

Sus principios de uso incluyen dos reglas duras:

  • Siempre npx -y firebase-tools@latest, nunca el comando firebase pelado: “NEVER suggest the naked firebase command as an alternative”.
  • Nunca mandar al usuario a la consola a descargar google-services.json o GoogleService-Info.plist; usar apps:sdkconfig ANDROID <APP_ID> o apps:sdkconfig IOS <APP_ID>.

Y un punto de pausa obligatorio: antes de configurar el proyecto, el agente debe preguntar si se usa un Project ID existente o se crea uno nuevo. No adivina.

Cómo se conectan con los skills de solución

Los skills de solución del capítulo 6 no reimplementan infraestructura: la delegan. La relación es de orquestador a especialista, y está escrita explícitamente en los SKILL.md.

El caso más claro es google-cloud-solution-guided-gke-ai-migration, que abre con un scope check que redirige fuera de sí mismo:

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.

Es decir: el skill de solución cubre migraciones —descubrir la configuración actual en Cloud Run o Agent Platform, dimensionar hardware, preparar el modelo, generar manifiestos, hacer el corte de tráfico—; los despliegues nuevos son territorio de gke-inference.

Dentro de la propia familia GKE existe un orquestador equivalente: gke-productionize, que se autodescribe como “a meta-skill or orchestrator skill” y lo dice sin ambigüedad:

Do not attempt to implement all production readiness features directly within
this skill; instead, use this skill to assess the environment and then delegate
to the specific skills for each domain.

Su fase 2 lista ocho dominios, y en cada uno usa el imperativo “You MUST run the … skill”:

flowchart TD
    P[gke-productionize] --> A[A. gke-app-onboarding]
    P --> B[B. gke-workload-scaling]
    P --> C[C. gke-observability]
    P --> D[D. gke-reliability]
    P --> E[E. gke-platform-security y gke-workload-security]
    P --> F[F. gke-backup-dr]
    P --> G[G. gke-service-networking]
    P --> H[H. gke-cost-optimization]

La fase 3 produce un scoring RAG —Red, Amber, Green— por área más una puntuación global de preparación, para priorizar la remediación.

Hay tres niveles de composición, entonces:

NivelEjemploQué hace
Solución multi-productogoogle-cloud-solution-guided-gke-ai-migrationDiseña la arquitectura y decide qué productos entran
Meta-skill de productogke-productionizeAudita un cluster y delega por dominio
Skill de dominiogke-reliability, gke-backup-drImplementa una sola cosa bien

Sesión de ejemplo: llevar una app a GKE encadenando skills

Escenario: una API en Node.js que corre en VMs y hay que llevarla a GKE lista para producción, incluyendo respaldos. Ningún skill hace esto solo.

Turno 1 — decidir el modo del cluster.

> Necesito llevar nuestra API Node a GKE. Usa sysctl para tunear
> net.core.somaxconn. ¿Autopilot o Standard?

Se activa gke-basics. Su regla de selección detecta que los sysctl personalizados están en la lista de tres excepciones, y por la instrucción “explicitly cite all matching restrictions” el agente no responde “Standard” a secas: nombra la restricción concreta que fuerza la decisión y pregunta si el tuning es realmente necesario, porque volver a Autopilot después implica recrear el cluster.

Turno 2 — crear el cluster.

> Sin sysctl entonces. Crea el cluster en us-central1.

Entra gke-golden-path para los valores por defecto y gke-cluster-creation para ejecutar. El agente marca las decisiones Day-0 —nodos privados, subred, rangos de IP— antes de crear nada, presenta el bloque de configuración del camino dorado y pide confirmación. Tras crear, verifica con get_cluster y readMask="*".

Turno 3 — contenerizar y desplegar.

> Aquí está el repo. Contenerízalo y despliégalo.

gke-app-onboarding recorre sus cinco pasos: evaluación, Dockerfile multi-stage sobre distroless con USER nonroot:nonroot, push a Artifact Registry con escaneo de vulnerabilidades, manifiestos con requests, limits y probes, y despliegue vía MCP apply_k8s_manifest. Si hay que afinar el YAML, gke-manifest-generation aporta las reglas de namespace explícito y ServiceAccount dedicada.

Turno 4 — el pod no arranca.

> El pod queda en CrashLoopBackOff.

gke-workload-troubleshooting toma el control. Extrae el contexto de forma no interactiva —project_id, cluster_name, namespace por defecto default— centra una ventana de consulta de una hora alrededor del incidente, y opera dentro de un límite explícito de solo lectura antes de proponer correcciones. Si el cluster no responde, cambia a modo dry-run y entrega la secuencia exacta de comandos kubectl para que la ejecute un humano.

Turno 5 — producción.

> Ya funciona. Prepáralo para producción.

Aquí entra gke-productionize como orquestador y recorre sus ocho dominios delegando: escalado, observabilidad, fiabilidad, seguridad de plataforma y de carga, backup, ingress y costo. Devuelve el scoring RAG.

Turno 6 — respaldos.

> Falta el backup de los volúmenes.

gke-backup-dr habilita el addon y, gracias a su gotcha, no se queda esperando: lanza el --enable-gke-backup, explica que la operación sigue en segundo plano y pasa de inmediato a escribir los Backup Plans con namespaces acotados y CMEK.

sequenceDiagram
    participant U as Usuario
    participant A as Agente
    participant S as Catalogo de skills
    U->>A: Llevar la API a GKE
    A->>S: gke-basics
    S-->>A: Autopilot por defecto y sus tres excepciones
    A->>S: gke-golden-path y gke-cluster-creation
    S-->>A: Defaults y avisos Day-0
    A->>S: gke-app-onboarding
    S-->>A: Dockerfile, Artifact Registry y manifiestos
    A->>S: gke-workload-troubleshooting
    S-->>A: Diagnostico de solo lectura y fix propuesto
    A->>S: gke-productionize
    S-->>A: Delegacion a ocho dominios y scoring RAG
    A->>S: gke-backup-dr
    S-->>A: Backup Plans sin bloquear la sesion
    A-->>U: Aplicacion en produccion con respaldo

Seis turnos, ocho skills, cero saltos a la documentación. Ese encadenamiento es posible porque cada description declara qué cubre y qué no, con el nombre del skill sustituto. Es el mismo mecanismo de descubrimiento que analizamos en la anatomía de un skill.

Instalación

Los skills de este capítulo se instalan como cualquier otro del catálogo, con los comandos exactos del README:

# skills.sh
npx skills add google/skills

# Claude Code
claude plugin marketplace add google/skills
claude plugin install <plugin>@google-plugins

# Codex
codex plugin marketplace add google/skills

# Antigravity CLI
agy plugin install https://github.com/google/skills/<plugin-path>

El empaquetado en plugins distribuibles lo cubre el curso hermano de Agent Plugins Spec, y lo veremos aplicado al marketplace de Google en el capítulo 11.

Resumen

  • GKE domina el catálogo con 28 directorios gke-* en skills/cloud/. La sección Infrastructure del README tiene 23 entradas, de las cuales solo 20 son de GKE; los otros 8 skills de GKE aparecen en Management tools (6) y Security and identity (2).
  • Cloud Run y Firebase no están en Infrastructure: son las dos únicas entradas de la sección Web and app hosting.
  • gke-basics se titula “GKE Basics & Critical Gotchas” y fija Autopilot por defecto, con tres excepciones tasadas: sysctl, taints o hardware específico, y hostPath crudos.
  • gke-golden-path fija los valores por defecto y obliga a marcar las decisiones Day-0, irreversibles tras la creación. gke-cluster-creation las ejecuta y verifica con readMask="*".
  • gke-app-onboarding lleva la app de código a Pod en cinco pasos con assets/ ejecutables, y termina nombrando los cuatro skills siguientes.
  • gke-inference usa Inference Quickstart por CLI para generar manifiestos optimizados por acelerador y por objetivo de latencia por token.
  • gke-backup-dr documenta un gotcha de comportamiento del agente: no hacer bucles de espera al habilitar el addon.
  • cloud-run-basics modela Services, Jobs y Worker pools, y su regla crítica es escuchar en 0.0.0.0 con $PORT.
  • firebase-basics es un bootstrap: su alcance es mínimo, pero sus references/setup/ y references/refresh/ guían la instalación del resto del ecosistema de skills de Firebase, con un archivo por harness.
  • La composición ocurre en tres niveles: soluciones multi-producto, meta-skills de producto como gke-productionize, y skills de dominio.

Siguiente: Skills de datos y analítica

← Volver al listado de tecnologías ← Índice de Google Skills