Running a Kubernetes application

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.

To optimize your development loop by quickly picking up changes to files of supported types without having to perform an image rebuild, you can enable file syncing and hot reloading.

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 ensure that you're building 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.

Running your application

  1. From the command palette (accessible with Cmd/Ctrl+ Shift+P), run Cloud Code: Run on Kubernetes.
  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 your Kubernetes context is a remote cluster, you're prompted to provide an image registry to push the images to.

    Here are examples of how to specify where container images are stored for some common registries:

    Docker Hub docker.io/{account}
    Ensure that you're properly authenticated if you're using a private Docker Hub repository.
    Container Registry gcr.io/{project_id}
    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.

    Running the Guestbook app and viewing logs returned from the live application

    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.

    Port-forwards and displays the URLs in the output window

  4. After your session completes, additional contextual menu options are available to monitor your application and its resources using the Cloud Code status bar, including:

    • Open Deployment Logs: Open the application logs of a specific deployment with the Cloud Code Logs Viewer
    • Open Service URL: Open the application service URL of a specific service in a web browser
    • Turn on/off watch mode: Toggle watch mode for the current session (not available for debug sessions). By default, Cloud Code continuously watches the file system for changes to your files, such as Kubernetes config or code, rebuilds the container(s), and redeploys the application to the cluster so that your edits are reflected in near real time.

      Options available via the Cloud Code status bar: Open Deployment Logs, Open Service URL, and Turn on Watch mode, in addition to regular Cloud Code actions

  5. To stop running the application, click the stop icon on 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.

    Stop running the Kubernetes application

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, from the command palette (accessible with Cmd/Ctrl+ Shift+P), 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.