Google Cloud Code: How to Build, Debug, and Deploy Cloud Applications

The app listens on all interfaces because it will run inside a container. Binding only to 127.0.0.1 inside the container can leave the process looking healthy while preventing the Kubernetes Service from reaching it.

4. Define the Container Image

A simple Dockerfile for the service could be:

FROM python:3.12-slim

WORKDIR /app

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY . .

EXPOSE 8080

CMD ["python", "app.py"]

Use the following dependencies:

Flask>=3.0,<4.0
debugpy

Including debugpy makes the Python debug adapter available when Cloud Code starts a supported Kubernetes debugging session in Visual Studio Code.

If you are starting with an existing project, build the image locally once before involving Kubernetes. That keeps early failures focused on application dependencies, file paths, and Dockerfile instructions.

IDE-Specific Notes

Visual Studio Code: Use the Command Palette to search for Cloud Code commands, including Kubernetes run and debug actions. The extension’s status information can help identify missing local prerequisites.

IntelliJ: After installing the plugin, look for Cloud Code run configurations and Kubernetes-related tool windows. If a run configuration is not created automatically, start with the plugin’s project or Kubernetes actions instead of a generic application run configuration.

2. Configure the Application for Cloud Code’s Kubernetes Workflow

Cloud Code works best when the application, container image, and Kubernetes resources agree on the basics: image name, labels, ports, environment variables, namespace, and target context. A mismatch in any of these can leave you with a deployment that appears active but does not do anything useful.

1. Create the Kubernetes Namespace

The example sends all namespaced resources to greeting. Include the Namespace manifest so Skaffold can create it as part of the workflow:

apiVersion: v1
kind: Namespace
metadata:
  name: greeting

Save this as k8s/namespace.yaml.

2. Create a Kubernetes Deployment

The Deployment describes the application container and the state Kubernetes should maintain.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: greeting
  namespace: greeting
  labels:
    app: greeting
spec:
  replicas: 1
  selector:
    matchLabels:
      app: greeting
  template:
    metadata:
      labels:
        app: greeting
    spec:
      containers:
        - name: greeting
          image: greeting-service
          ports:
            - containerPort: 8080
          env:
            - name: GREETING_PREFIX
              value: "Hello"
          resources:
            requests:
              cpu: "100m"
              memory: "128Mi"
            limits:
              cpu: "250m"
              memory: "256Mi"
          readinessProbe:
            httpGet:
              path: /health
              port: 8080
            initialDelaySeconds: 3
            periodSeconds: 5

One replica is generally enough for local development. Resource settings should still be realistic enough to expose obvious startup or memory problems before they appear in a later environment.

The greeting-service image name deliberately matches the Skaffold artifact defined below. Skaffold replaces this manifest reference with the tagged image it builds, including the configured remote repository when the remote profile is active.

3. Create a Kubernetes Service

The Service gives the Deployment’s pods a stable endpoint.

apiVersion: v1
kind: Service
metadata:
  name: greeting
  namespace: greeting
spec:
  selector:
    app: greeting
  ports:
    - name: http
      port: 80
      targetPort: 8080
  type: ClusterIP

A request follows this path:

Local browser or test client
        ↓
Forwarded local port
        ↓
Kubernetes Service on port 80
        ↓
Container port 8080
        ↓
Python application

The Service selector, Deployment labels, and container port must agree. If the Service selects app: greetings while the Deployment labels its pods app: greeting, Kubernetes creates both resources, but the Service has no usable endpoints.

4. Add a Skaffold Configuration

Create skaffold.yaml with a local default workflow and a separate remote profile:

apiVersion: skaffold/v4beta11
kind: Config
metadata:
  name: greeting

build:
  tagPolicy:
    gitCommit: {}
  artifacts:
    - image: greeting-service
      context: .
      docker:
        dockerfile: Dockerfile
  local:
    push: false

manifests:
  rawYaml:
    - k8s/namespace.yaml
    - k8s/deployment.yaml
    - k8s/service.yaml

deploy:
  kubectl: {}

profiles:
  - name: remote
    build:
      local:
        push: true

The default configuration supports local development:

• It builds the greeting-service artifact from the supplied Dockerfile.
• It does not push the image to a registry.
• It deploys the namespace, Deployment, and Service manifests.
• It relies on a local cluster that can access images built by the selected local container runtime.

If your local cluster does not share Docker’s image store, configure its supported image-loading method before starting the workflow.

The remote profile supports a remote development workflow, keeping the same manifests and artifact but pushing the generated image. Provide the approved remote repository as Skaffold’s default repository when deploying remotely:

export REMOTE_IMAGE_REPOSITORY='REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY'

skaffold run -p remote --default-repo="$REMOTE_IMAGE_REPOSITORY"

With that command, Skaffold builds and pushes an image under the approved repository, such as:

REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY/greeting-service:TAG

It also substitutes that final image reference for greeting-service in the Deployment before applying it. Configure Cloud Code’s remote run or deploy action to select the remote profile and use the same default repository. The command above is the equivalent direct Skaffold invocation.

For local development, Cloud Code uses the default profile. Its equivalent command is:

skaffold dev

Cloud Code’s Kubernetes debug action uses the same build and deployment inputs while starting a debug-capable workload.

5. Select a Local Kubernetes Target

Before starting the application, confirm that the active Kubernetes context points to your local cluster:

kubectl config current-context
kubectl get nodes
kubectl get namespace greeting

Cloud Code uses the Kubernetes context selected by your project or command configuration. Give local, staging, and production contexts clear names. A vague context name is easy to overlook until it sends a change to the wrong place.

Also confirm how your local cluster receives container images:

• Some local Kubernetes setups can use images built directly by the local container runtime.
• Others require images to be loaded into the cluster.
• Remote clusters need images pushed to an accessible registry.

6. Use Validation Before Running

Cloud Code can provide YAML diagnostics and Kubernetes-aware validation as you edit manifests. Use those checks to catch malformed YAML, unsupported fields, missing references, and structural errors early.

Validation cannot establish every runtime detail. For example:

• A malformed targetPort may be highlighted quickly.
• A valid but incorrect image name may not fail until Kubernetes tries to pull it.
• A readiness probe path can be syntactically valid but still return 404 when the container starts.

Treat IDE validation as the first check, not the final one.

3. Run, Debug, and Inspect the Application Without Leaving the IDE

Running through Cloud Code involves more than starting a container. The workflow ties together the build, Kubernetes workload, logs, port forwarding, and debugging tools, making it easier to see where a failure starts.

1. Start the Application on the Local Cluster

Use Cloud Code’s Kubernetes run action for the current project. This normally starts the default Skaffold development workflow:

1. Build or rebuild the application image.
2. Make the image available to the selected cluster.
3. Apply the Namespace, Deployment, and Service manifests.
4. for the workload to start.
5. Stream application output and Kubernetes status into the IDE.

Watch the application log alongside the Kubernetes resource state. A Python stack trace points toward application code. A pod stuck in image-pull status points toward image availability or permissions. They are different problems, even though both can leave a browser without a response.

2. Test the Service Through a Forwarded Port

Cloud Code may create a port forward automatically, depending on the project configuration. You can also run the equivalent local command:

kubectl -n greeting port-forward service/greeting 8080:80

Then test the application:

curl http://localhost:8080/greet/Ada

Expected output:

{"message":"Hello, Ada!"}

The request reaches the Service on port 80, which forwards traffic to port 8080 in the container. Testing through the Service checks more than the application process by itself.

3. Start a Supported Debugging Session

Python breakpoint debugging in this guide is limited to Cloud Code for Visual Studio Code. Cloud Code for Visual Studio Code supports Python Kubernetes debugging, including breakpoints in the running containerized application.

Cloud Code for IntelliJ does not provide the equivalent Cloud Code Python breakpoint workflow. IntelliJ users can still build, deploy, inspect Kubernetes resources, and view logs for this Python service, but should use Visual Studio Code for the Python breakpoint steps below. Cloud Code debugging in IntelliJ should be limited to the languages and debugger workflows supported by that IDE and plugin version.

In Visual Studio Code, choose Cloud Code’s Kubernetes debug action instead of the standard local run action. For supported runtimes, Cloud Code prepares the workload and connects the IDE debugger.

Set a breakpoint in the request handler:

@app.get("/greet/

curl http://localhost:8080/greet/Ada

env:
  - name: GREETING_PREFIX
    value: "Welcome"

curl http://localhost:8080/greet/Ada

{"message":"Welcome, Ada!"}

kubectl -n greeting logs deployment/greeting
kubectl -n greeting logs deployment/greeting --previous

kubectl -n greeting get pods -l app=greeting
kubectl -n greeting get service greeting
kubectl -n greeting get endpointslice -l kubernetes.io/service-name=greeting

kubectl config current-context
kubectl get namespace greeting
kubectl get nodes

export REMOTE_IMAGE_REPOSITORY='REGION-docker.pkg.dev/PROJECT_ID/REPOSITORY'

skaffold run -p remote --default-repo="$REMOTE_IMAGE_REPOSITORY"

kubectl -n greeting rollout status deployment/greeting
kubectl -n greeting get pods,service

kubectl -n greeting logs deployment/greeting --tail=100