Cloud Code is designed to make Kubernetes and Cloud Build configuration easier by linting schema for both structure and valid values and providing descriptive errors. Cloud Code comes with out-of-the-box solutions for common schema, smart completions, and documentation on hover.
Supported YAML configuration files
- Anthos Config Management
- Cloud Build
- Config Connector
- Migrate for Anthos and GKE
Cloud Code also supports popular Kubernetes custom resource definitions (CRDs), like Kubeflow, out-of-the-box.
Using custom schema
With Cloud Code, you can provide your own CRD schema with the
cloudcode.yaml.crdSchemaLocations setting in your
You can point to either a local file or a URL. URLs pointing to
automatically converted to
Pulling schema from a cluster
When you switch to a cluster running Kubernetes v1.16 and above in the Kubernetes Explorer, Cloud Code automatically pulls the schema of all installed CRDs.
Configuring with snippets
Out-of-the-box snippets for common YAML schema (using
view options) make it easy to start a new YAML file or add to an existing one
without errors, while still following best practices. Cloud Code makes
it easier to work with repetitive fields; fill in one and Cloud Code
fills out the remaining instances.
Cloud Code offers the following snippets:
Anthos Config Management - Cluster
Anthos Config Management - Cluster Selector
Anthos Config Management - Config Management
Anthos Config Management - Namespace Selector
Cloud Build - Cloud Run deployment
Cloud Build - Docker container build
Cloud Build - GKE deployment
Cloud Build - GKE Skaffold deployment
Cloud Build - Go build
Cloud Build - Terraform plan + apply
Config Connector - BigQueryDataset
Config Connector - BigQueryTable
Config Connector - BigtableCluster
Config Connector - BigtableInstance
Config Connector - PubSubSubscription
Config Connector - PubSubTopic
Config Connector - RedisInstance
Config Connector - SpannerInstance
Kubernetes - ConfigMap
Kubernetes - Deployment
Kubernetes - Ingress
Kubernetes - Pod
Kubernetes - Secret
Kubernetes - Service
Migrate for Anthos - Export
Migrate for Anthos - PersistentVolumeClaim
Migrate for Anthos - StatefulSet
Skaffold - Bazel
Skaffold - Getting-started
Skaffold - Helm deployment
Skaffold - Kaniko
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 a matter of 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 for the artifact
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)
The following sample
sync section in a skaffold.yaml file specifies a
sync to synchronize all
/static-html HTML files to the
static folder in a
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.
Completing with context
Based on the current schema, Cloud Code provides contextual completions and relevant docs to help you choose the right option.
Validating YAML schema
Cloud Code offers schema validation support by flagging invalid tags and values in your YAML files and suggesting fixes when possible.
Discovering documentation on hover
Cloud Code surfaces relevant documentation when you hover over a value in the schema.
Accessing resource definitions
Quickly view definitions for resources by right-clicking and choosing Go to Definition or Peek Definition.
Applying a YAML file
To apply a configuration change using the current file, you can run Cloud Code: Apply the current JSON/YAML file with Kubernetes deployed resource from the Command Palette (click Manage > Command Palette).
This command brings up a diff view for you to review changes. Click Apply
when prompted whether to apply this change. This runs
kubectl apply -f.
Viewing differences between YAML files
To view the differences between a YAML file in source control and a deployed YAML file, you can use Cloud Code: Diff the current JSON/YAML file with Kubernetes deployed resource from the Command Palette (click Manage > Command Palette).
Performing a dry-run of a YAML file
To perform a dry run of your configuration and check its validity, you can run Cloud Code: Dry-run current config for server-side validation and Cloud Code: Dry-run current config for client-side validation from the Command Palette (click Manage > Command Palette).
kubectl apply -f dry-run=server
kubectl apply -f dry-run=client, for the Client option) and displays
successful validation (or an error message, if your config file isn't valid)
as a toast notification.
In the following example, server-side dry-run validation of the configuration
file, hello.deployment.yaml, returns an error when trying to create a
deployment because the specified namespace,
random-namespace, doesn't exist.
Working with secrets
Using configuration maps and secrets is a key part of working with Kubernetes. To view the context of a base64 secret with Cloud Code, hover over the secret to decode it.