Run a Kubernetes application in Cloud Code for VS Code

Cloud Code allows you to easily run your application on a Kubernetes cluster and view it live, by leveraging skaffold dev. You can run your application on a local cluster (like minikube or Docker Desktop), Google Kubernetes Engine, or any other Cloud provider.

Running your application

  1. Open the Command Palette (press Ctrl/Cmd+Shift+P) and then run the Cloud Code: Run on Kubernetes command.
  2. Confirm whether to use the current Kubernetes context to run the app in (or switch to a preferred one). For more information about setting up a Kubernetes context, see setting up configuration.
  3. If you chose a remote cluster as the context, when prompted, choose an image registry to push the images to. If you're using Container Registry, you can browse to an existing registry or specify the name of a registry to create. 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 Registry {region}-docker.pkg.dev/{project_id}/{repo-name}
    Container Registry gcr.io/{project_id}
    Docker Hub docker.io/{account}
    Make sure that you're properly authenticated if you're using a private Docker Hub repository.
    AWS Container Repository (ECR) {aws_account_id}.dkr.ecr.{region}.amazonaws.com/{my-app}
    Azure Container Registry (ACR) {my_acr_name}.azurecr.io/{my-app}

    Cloud Code concatenates this image registry with the image name specified in the Kubernetes manifests to generate the final image repository name.

    For more information, see the image registry handling guide.

    This choice is stored in your cloudcode.kubernetes launch configuration (found in .vscode/launch.json).

    Cloud Code builds your containers, pushes them to the registry, applies Kubernetes configurations to the cluster, and waits for the rollout.

    After the rollout completes, 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.

  4. After your session completes, you can use the following contextual menu commands:

    • Open Deployment Logs: Open the application logs of a specific deployment with the Cloud Code Logs Explorer
    • Open Service URL: Open the application service URL of a specific service in a web browser
  5. 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 icon Rebuild and redeploy the application.

  6. To stop running the application, click Debug stop icon Stop in the Debug Toolbar.

    After you stop the application, all deployed Kubernetes resources are deleted from the cluster. You can change this behavior using the cleanUp flag in your launch configuration.

Enabling Skaffold file sync and hot reloading

To improve the efficiency of your local development workflow and avoid having to rebuild, redeploy, and restart your pods, Skaffold supports copying changed files to a deployed container. This means that when you're making changes to static and source code files, you can see your changes take effect in seconds, making for an accelerated feedback loop.

For static files (like HTML and CSS files), this file copying behavior is called file syncing.

For source code files, this behavior is called as hot reloading and supports the following file types:

  • Go: *.go
  • Java: *.java, *.kt, *.scala, *.groovy, *.clj
  • NodeJS: *.js, *.mjs, *.coffee, *.litcoffee, *.json

With hot reloading configured, Skaffold detects changes to supported files and syncs these changes to the running container on your cluster. Changes to file types that don't support hot reloading trigger an image rebuild and pod restart.

Automatic file-syncing and hot reloading are enabled by default when you're working with Buildpacks as your preferred builder. For other builders like Docker, you can specify a sync section in your skaffold.yaml file for the artifact you're customizing.

Your sync setting can be one of (in order of preference):

  • auto (only for Jib and Buildpacks artifacts. This is the default if not specified for Buildpacks)
  • infer
  • manual

The following sample sync section in a skaffold.yaml file specifies a manual sync to synchronize all /static-html HTML files to the static folder in a container:

build:
  artifacts:
    - image: gcr.io/k8s-skaffold/node-example
      context: node
      sync:
        manual:
          - src: 'static-html/*.html'
            dest: static

For a detailed look at file syncing and specifying sync rules, see the Skaffold guide on file sync.

Deploying from a system with Apple M-series silicon

Google Kubernetes Engine only supports x86 images. While support for Apple M-series chips is being worked on, you must build an image that can run on an x86 architecture. For steps to build an x86 image using Cloud Build for deployment to GKE, see Choosing a builder and build environment.

Storing secrets

If your code includes potentially sensitive data like API keys, passwords, and certificates, it is recommended you store them as secrets. With Cloud Code, you can securely store these secrets in Secret Manager and programmatically fetch them when you need them. For a detailed look at how you can create and manage secrets with Cloud Code, see the Secret Manager guide.

Choosing a builder and build environment

In a project that doesn't contain a skaffold.yaml file at the root or doesn't reference skaffold.yaml in its .vscode/launch.json file, you can use the Cloud Code UI to choose a builder and build environment. Building locally is free of charge since it uses your own resources. Building with Cloud Build is good for slower machines or machines that don't match the processor architecture of the target cluster. For information about the cost of building your application using Cloud Build, see Cloud Build Pricing.

If you're using one of the samples, to use the UI, delete the skaffold.yaml file before running a build action. For steps to choose a builder and build environment without the UI, see Manually creating a Skaffold configuration.

  1. In a project without a skaffold.yaml file, open the Command Palette (press Ctrl/Cmd+Shift+P) and then run Cloud Code: Run on Kubernetes or Cloud Code: Debug on Kubernetes.

  2. Choose a build environment.

    If you're developing on Apple M-series silicon, you must build an image that can run on an x86 architecture. To use Cloud Build to build an x86 image, select the Cloud Build option.

    If you choose Cloud Build, specify the image registry.

  3. Specify a builder (Docker or Buildpack) for each image and its settings.

  4. Check or uncheck any of the configuration options and then click Debug or Run.

The options you choose are saved to a skaffold.yaml file that you can edit directly for further customization.

Customizing launch configuration

To configure how your application is run, you can customize your skaffold.yaml file

You can also configure your launch by specifying the following fields in the cloudcode.kubernetes configuration in your .vscode/launch.json file:

  • skaffoldConfig: Specify the Skaffold configuration file that contains the build and deploy settings.
  • profile: Specify your preferred Skaffold profile. If not defined, the default profile is used.
  • imageRegistry: Specify the image registry to push images to.
  • watch: Specify whether to watch for changes in the workspace and rerun the application. Unless explicitly set to false, true by default.
  • cleanUp: Specify whether to delete deployed Kubernetes resources in the cluster after the application is terminated. Unless explicitly set to false, true by default.
  • portForward: Specify whether to forward ports for exposed Kubernetes resources on your cluster to your local machine. Unless explicitly set to false, true by default.

Getting Support

To send feedback, report issues on GitHub, or ask a question on Stack Overflow.