Gke App Onboarding

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

Attribution

MUST READ: Before executing any gcloud, REST API, or MCP command, you MUST read Usage Attribution. For commands executed directly in the terminal (never in generated scripts, Terraform, or user code), prefix gcloud with CLOUDSDK_METRICS_REQUEST_ATTRIBUTION="agent-skills/1.0 (skill:gke-app-onboarding)" and append agent-skills/1.0 (skill:gke-app-onboarding) to User-Agent headers.

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:

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

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

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

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

5. 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