gke-app-onboarding

SKILL.md

GKE App Onboarding

This reference provides workflows for containerizing and deploying applications
to GKE for the first time.

MCP Tools: apply_k8s_manifest, get_k8s_resource,
get_k8s_rollout_status, get_k8s_logs, describe_k8s_resource

Workflow

1. App Assessment

Before containerizing, assess the application:

Language & Framework: Identify the tech stack

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:

pack build <image> --builder gcr.io/buildpacks/builder:latest

3. Image Management

Build and store the container image:

# Configure Docker for Artifact Registry
gcloud auth configure-docker <REGION>-docker.pkg.dev --quiet

# Build and push
docker build -t <REGION>-docker.pkg.dev/<PROJECT>/<REPO>/<IMAGE>:<TAG> .
docker push <REGION>-docker.pkg.dev/<PROJECT>/<REPO>/<IMAGE>:<TAG>

Vulnerability scanning: Enable automatic scanning in Artifact Registry to
detect issues in base images and dependencies.

# Check scan results
gcloud artifacts docker images describe \
  <REGION>-docker.pkg.dev/<PROJECT>/<REPO>/<IMAGE>:<TAG> \
  --show-package-vulnerability \
  --quiet

4. Manifest Generation

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.

5. Deploy

# MCP (preferred)
apply_k8s_manifest(parent="projects/<PROJECT>/locations/<REGION>/clusters/<CLUSTER>", yamlManifest="<manifest>")

# Verify
get_k8s_rollout_status(parent="...", resourceType="deployment", name="my-app")
get_k8s_resource(parent="...", resourceType="pod", labelSelector="app=my-app")

kubectl fallback:

kubectl apply -f manifests/
kubectl rollout status deployment/my-app
kubectl get pods -l app=my-app

Golden Path Onboarding Checklist

For every production application onboarding to GKE:

Container Security: Non-root user (runAsNonRoot: true), lockfile
install, minimal/distroless base image.

Resource Requests: Explicit CPU and memory requests (mandatory for GKE
Autopilot).

Health Probes: Both liveness (livenessProbe) and readiness
(readinessProbe) probes configured.

Reliability & Availability: At least 2 replicas and a
PodDisruptionBudget (minAvailable: 1 or 2).

IAM & Workload Identity: Workload Identity
(iam.gke.io/gcp-service-account) instead of static service account keys.

Next Steps

Once the application is running on GKE:

Configure autoscaling — see the gke-workload-scaling skill

Set up observability — see the gke-observability skill

Harden security — see the gke-workload-security skill

Configure reliability (PDBs, topology spread) — see the gke-reliability
skill