Manages GKE application onboarding, covering containerization, deployment manifests, and migration. Use when onboarding or deploying an application to GKE for the first time, or containerizing an app for GKE. Don't use for general GKE cluster administration or upgrades (use gke-basics or gke-upgrades instead).
Permissions
Files
SKILL.md
gke-app-onboarding
Manages GKE application onboarding, covering containerization, deployment manifests, and migration. Use when onboarding or deploying an application to GKE for the first time, or containerizing an app for GKE. Don't use for general GKE cluster administration or upgrades (use gke-basics or gke-upgrades instead).
metadata.category
Containers
GKE App Onboarding
This reference provides workflows for containerizing and deploying applications
to GKE for the first time.
Dependencies: List required libraries and external services
Configuration: How is the app configured? (env vars, config files,
secrets)
Statefulness: Does it need persistent storage? (databases, file storage)
Networking: Port mapping and protocol (HTTP, gRPC, TCP)
Health endpoints: Does the app expose health check endpoints?
2. Containerization
Create a container image. A Dockerfile with a multi-stage build is recommended
for most apps — see the Go Dockerfile in
references/go-example.md for a worked example.
Best practices:
Use multi-stage builds to keep production images small
Use distroless or minimal base images to reduce attack surface
Run as non-root user
Log to stdout and stderr for Cloud Logging collection
A complete worked Node.js example is provided in assets/:
Dockerfile (non-root node user),
index.js (implements distinct /healthz and /readyz
endpoints), package.json, and
deployment.yaml (hardened Deployment plus
ClusterIP Service, probes wired to /healthz and /readyz).
For applications where writing a Dockerfile is not preferred, you can use
Cloud Native Buildpacks to automatically detect
the language and build a container image:
Generate Kubernetes manifests for the application. A baseline Deployment +
ClusterIP Service manifest (probes, resource requests/limits, 2 replicas) is in
references/go-example.md.
Checklist for manifests:
Resource requests and limits set
Liveness and readiness probes configured
At least 2 replicas for production
Service type appropriate (ClusterIP for internal, use Gateway API for
external)
See assets/deployment.yaml for a hardened worked
example. A production-hardened pod spec must include ALL of: runAsNonRoot: true, readOnlyRootFilesystem: true, allowPrivilegeEscalation: false,
capabilities.drop: ["ALL"], seccompProfile: {type: RuntimeDefault},
automountServiceAccountToken: false (unless the pod needs the token — then say
why), resource requests, digest-pinned image, and a ClusterIP Service.
That checklist is the baseline for any pod spec produced here. For manifest work
beyond it — Gateway API routes, GCS FUSE and secret volume mounting, subPath
overlays, Spot VM targeting, or AI/inference serving specs — see
gke-manifest-generation.
