Stay organized with collections Save and categorize content based on your preferences.
Note: Debugging support is available for Node.js, Python, Go, Java, and .NET.Cloud Code lets you debug an application deployed to a Google Kubernetes Engine (GKE) cluster by leveraging skaffold debug.
You can debug your application on a local cluster (like minikube or Docker Desktop), GKE, or any other cloud provider.
With Cloud Code's debugging support, you don't have to complete manual setup like setting up port forwarding or injecting language-specific debug arguments. Debugging requires a Cloud Code-ready GKE application that includes a skaffold.yaml configuration file and a cloudcode.kubernetes launch configuration.
To begin debugging your GKE application, follow these steps:
In the Cloud Code status bar, click the active project name.
In the Quick Pick menu that appears, select Debug on Kubernetes.
If prompted, authenticate your credentials to run and debug an application locally.
If your application doesn't have the necessary Skaffold configuration or cloudcode.kubernetes launch configuration, Cloud Code helps you set these up.
Confirm whether to use the current Kubernetes context to run the app in (or switch to a preferred one).
If you chose a remote cluster as the context, when prompted, choose an image registry to push the images to.
If your project has Artifact Registry API enabled and at least one Artifact Registry repository, you can browse to and select an existing Artifact Registry repository.
The following samples demonstrate how to specify where container images are stored for some common registries:
Artifact RegistryREGION-docker.pkg.dev/PROJECT_ID/REPO_NAME Docker Hub docker.io/ACCOUNT AWS_ACCOUNT_ID.dkr.ecr.REGION.amazonaws.com/APP Azure Container Registry (ACR) ACR_NAME.azurecr.io/APP
To generate the final image repository name, Cloud Code concatenates this image registry with the image name specified in the Kubernetes manifests. This choice is stored in your cloudcode.kubernetes launch configuration (found in .vscode/launch.json).
For more information, see the image registry handling guide.
Cloud Code builds your containers, pushes them to the registry, applies Kubernetes configurations to the cluster, and waits for the rollout.
After the rollout, Cloud Code automatically port-forwards all declared container ports to your machine and displays the URLs in the output window so that you can browse your live application.
For each debuggable container in your application, confirm or enter the directory in the remote container where the program you want to debug is located.
Alternatively, you can press ESC to skip debugging the container.
Cloud Code attaches a debug session for each debuggable container in the application.
You can now perform the same tasks you normally do when debugging local code, like setting breakpoints and stepping through code, against a live Kubernetes cluster.
By default, when you save a change to your application, Cloud Code redeploys your application and sets up a new debug session. You can toggle this feature with the watch flag in your project's launch configuration.
To inspect variables and stack info, use the Debug Sidebar. To interact with the debugging session, use the Debug Console in the bottom pane debugger.
After your session completes, you can use the following contextual menu commands:
If you've turned off watch mode in your launch configuration and you want to make changes to your application and rebuild and redeploy the application, in the Development sessions pane, pause on the run action and then click Rebuild and redeploy the application.
To end the debugging session, click Stop in the Debug Toolbar.
After you end the debugging session, all the deployed Kubernetes resources are deleted from the cluster.
Cloud Code, powered by Skaffold, automatically handles the following configuration details for all supported languages:
skaffold.yaml, then a debugger is attached to each debuggable container..vscode/launch.json file directly.Cloud Code also handles the following language-specific configuration details:
Node.jsRewriting the entrypoint to invoke:
node --inspect=localhost:9229
Installing the ptvsd module using an Init Container and rewriting the entrypoint to invoke:
python -m ptvsd --host localhost --port 5678
Installing the dlv debugger using an Init Container and rewriting the entrypoint such that the launched debug session runs with a debug server only (in headless mode), continues the debugged process on start, accepts multiple client connections, and listens at localhost:56268:
dlv exec --headless --continue --accept-multiclient --listen=localhost:56268 --api-version=2, <app> --
Adding an environment JAVA_TOOLS_OPTIONS with the appropriate Java Debug Wire Protocol (JDWP) configuration such that the JDWP debugging agent listens for a socket connection on port 5005 and allows the VM to begin executing before the debugger is attached:
jdwp=transport=dt_socket,server=y,suspend=n,address=5005,quiet=y
For more details on Skaffold-powered debugging, see the skaffold debug documentation.
To prepare your container for debugging, follow the instructions for the language you're using:
Node.js--inspect=<debugPort> where debugPort comes from the attach configuration. For example: CMD ["node", "--inspect=9229", "index.js"]ptvsd module installed on your machine and in your container.ptvsd. Match the port specified to the debugPort field in the attach configuration. For example:
CMD ["python", "-m", "ptvsd", "--port", "", "app.py"]
dlv package installed on your machine and your Go container.Start your Go application through dlv debug.
The port specified in the starting command should be the same as the debugPort attribute value in the attach configuration. For example:
CMD ["dlv", "debug", "--headless", "--listen=:<debugPort>", "--log"]
Troubleshooting Tip: When debugging a Go application, the application will stop and wait for a debugger to attach. Attach a debugger for the service to start.
Start the Java application with the following options, where debugPort comes from the attach configuration.
-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=,quiet=y
For example, to start the Java application in debug mode and listen on port debugPort for connection:
ENTRYPOINT ["java","-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=<debugPort>,quiet=y", "-jar", "my-app-1.0.jar"]
Make sure that you have the vsdbg, the .NET Core command line debugger from Microsoft, installed on your Kubernetes container.
For example:
RUN apt-get update
&& apt-get install -y --no-install-recommends unzip
&& apt-get install -y procps
&& rm -rf /var/lib/apt/lists/*
&& curl -sSL https://aka.ms/getvsdbgsh | bash /dev/stdin -v latest -l /dbg/netcore/vsdbg
To attach to a debuggable container, you need to have an attach configuration of type cloudcode.kubernetes.
If your project doesn't have a launch.json file in its .vscode folder, you can add one using the Debug panel.
To navigate to the Debug panel, click Run and Debug in the Activity bar.
Select Add Configuration from the drop-down menu.
Select Cloud Code: Kubernetes as the environment.
Select the Attach to Kubernetes Pod option.
Select the programming language you're using.
This creates and opens a launch.json file for your project and creates an attach configuration for you.
Update configuration attributes in the launch.json file to match those of your project. For more information on configuration attributes, see Configuration attributes.
To add a new attach configuration to an existing .vscode/launch.json file:
launch.json file.podSelector:
"podSelector": { "app": <deployment-name> }
Cloud Code for VS Code supports attaching a debugger to a Kubernetes pod for Node.js, Python, Go, Java and .NET. All you need is a debuggable container and an attach configuration of type cloudcode.kubernetes.
For information about how attaching to a Kubernetes pod differs from debugging a Kubernetes application, see How attaching a debugger to a pod differs from debugging a Kubernetes application.
To attach a debugger to your Kubernetes pod, perform the following tasks:
Select and launch the configuration by pressing F5.
localhost:${debugPort} is port-forwarded to debugPort on the container while debugging.The debugging session is now successfully set up. You can perform the tasks you normally do when debugging local code, like setting breakpoints and stepping through code.
To inspect variables and stack info, use the Debug Sidebar. To interact with the debugging session, use the Debug Console in the bottom pane debugger.
To end the debugging session, click Stop in the Debug Toolbar.
cloudcode.kubernetes and request attach. Uses configuration (.vscode/launch.json) of type cloudcode.kubernetes and request launch.
{
"name": "Attach to Kubernetes Pod (NodeJS)",
"type": "cloudcode.kubernetes",
"request": "attach",
"language": "Node",
"debugPort": 9229,
"podSelector": {
"app": "hello-world"
},
"localRoot": "${workspaceFolder}",
"remoteRoot": "/app"
}
Sample Config:
{
"name": "Run/Debug on Kubernetes",
"type": "cloudcode.kubernetes",
"request": "launch",
"skaffoldConfig": "${workspaceFolder}/skaffold.yaml",
"watch": true,
"cleanUp": true,
"portForward": true
}
This configuration can't be used to run the application. This configuration can be used to run or debug the application. This configuration is language specific. This configuration is not language specific. No dedicated command. Debug on Kubernetes command. Watch mode isn't available, so after making changes you restart the debugger manually. Watch mode lets Cloud Code restart the debugger after you save changes. What's next
To send feedback, report issues on
GitHub, or ask a question on
Stack Overflow.
Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 4.0 License, and code samples are licensed under the Apache 2.0 License. For details, see the Google Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.
Last updated 2025-08-07 UTC.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-07 UTC."],[[["Cloud Code supports debugging applications deployed to Google Kubernetes Engine (GKE) clusters, as well as local clusters, using `skaffold debug` for Node.js, Python, Go, Java, and .NET applications."],["Cloud Code simplifies the debugging process by handling port forwarding and language-specific debug arguments, requiring only a Cloud Code-ready GKE application with a `skaffold.yaml` file and a `cloudcode.kubernetes` launch configuration."],["To begin debugging, you select \"Debug on Kubernetes\" in the Cloud Code status bar, and the tool will guide you through authenticating credentials, configuring Skaffold, and selecting an image registry."],["Cloud Code automates tasks such as building and pushing containers, applying Kubernetes configurations, and port-forwarding container ports, and allows you to set breakpoints and step through code in a live Kubernetes cluster."],["You can choose to attach to a specific Kubernetes Pod which requires the application to already be running in the Pod, or you can choose to debug a Kubernetes application which will then run the application for you and debug all the debuggable containers, and they also have different configuration requirements."]]],[]]
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4