Cloud Code for Cloud Shell 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 later 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 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)
The following sample
sync section in a
skaffold.yaml file specifies a
manual sync to synchronize all
/static-html HTML files to the
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.
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 hold the pointer over a value in the schema.
Accessing resource definitions
To view definitions for a resource, right-click the resource and then choose Go to Definition or Peek Definition.
Applying a YAML file
To apply a configuration change using the current file, open the Command
P) and run
Cloud Code: Apply Current JSON/YAML File to K8s Deployed Resource.
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, open the Command Palette (press
P) and run Cloud Code: Diff Current
JSON/YAML File with K8s Deployed Resource.
Performing a dry-run of a YAML file
To perform a dry run of your configuration and check its validity, open the
Command Palette (press
P) and run Cloud Code: Dry-run current config for server-side validation
and Cloud Code: Dry-run Current Config for Client-side Validation.
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, hold the pointer over the secret to decode it.