Skaffold

Docker Build

Mon, 01 Jan 0001 00:00:00 +0000

Skaffold supports building with Dockerfile

Dockerfile with Docker locally

If you have Docker installed, Skaffold can be configured to build artifacts with the local Docker daemon.

By default, Skaffold connects to the local Docker daemon using Docker Engine APIs, though it can also use the Docker command-line interface instead, which enables artifacts with BuildKit.

After the artifacts are successfully built, Docker images will be pushed to the remote registry. You can choose to skip this step.

Getting Started With Your Project

Mon, 01 Jan 0001 00:00:00 +0000

Skaffold requires a skaffold.yaml, but - for supported projects - Skaffold can generate a simple config for you that you can get started with. To configure Skaffold for your application you can run skaffold init.

Running skaffold init at the root of your project directory will walk you through a wizard and create a skaffold.yaml that defines how your project is built and deployed.

skaffold init

What’s next

You can further set up File Sync for source files that do not need a rebuild in dev mode.

Local build

Mon, 01 Jan 0001 00:00:00 +0000

Local build execution is the default execution context. Skaffold will use your locally-installed build tools (such as Docker, Bazel, Maven or Gradle) to execute the build.

Configuration

To configure the local execution explicitly, add build type local to the build section of skaffold.yaml

build:
  local: {}

The following options can optionally be configured:

Option	Description	Default
`push`	should images be pushed to a registry. If not specified, images are pushed only if the current Kubernetes context connects to a remote cluster.
`tryImportMissing`	whether to attempt to import artifacts from Docker (either a local or remote registry) if not in the cache.	`false`
`useDockerCLI`	use `docker` command-line interface instead of Docker Engine APIs.	`false`
`useBuildkit`	use BuildKit to build Docker images. If unspecified, uses the Docker default.
`concurrency`	how many artifacts can be built concurrently. 0 means “no-limit”.	`1`

Faster builds

There are a few options for achieving faster local builds.

Container Structure Test

Mon, 01 Jan 0001 00:00:00 +0000

It’s common practice to validate built container images before deploying them to our cluster. To do this, Skaffold has an integrated testing phase between the build and deploy phases of the pipeline. Natively, Skaffold has support for running container-structure-tests on built images, which validate the structural integrity of container images. The container-structure-test binary must be installed to run these tests.

Structure tests are defined per image in the Skaffold config. Every time an artifact is rebuilt, Skaffold runs the associated structure tests on that image. If the tests fail, Skaffold will not continue on to the deploy stage. If frequent tests are prohibitive, long-running tests should be moved to a dedicated Skaffold profile. Users can opt out of running container structure tests by using the --skip-tests flag.

skaffold dev

Mon, 01 Jan 0001 00:00:00 +0000

skaffold dev enables continuous local development on an application. While in dev mode, Skaffold will watch an application’s source files, and when it detects changes, will rebuild your images (or sync files to your running containers), push any new images, test built images, and redeploy the application to your cluster.

skaffold dev is considered Skaffold’s main mode of operation, as it allows you to leverage all of the features of Skaffold in a continuous way while iterating on your application.

Custom Test

Mon, 01 Jan 0001 00:00:00 +0000

Custom Test allows developers to run custom commands as part of their development pipeline. The command executes in the testing phase of the Skaffold pipeline. It will run on the local machine where Skaffold is being executed and works with all supported Skaffold platforms. Users can opt out of running custom tests by using the --skip-tests flag.

Some example use cases for Custom Test are below:

Run unit tests
Run validation and security scans on images before deploying the image to a cluster for example by running GCP Container Analysis or Anchore Grype

Custom tests are defined on a per image basis in the Skaffold config. Every time an artifact is rebuilt, Skaffold runs the associated custom tests as part of the Skaffold dev loop. Multiple testers can be defined per test. The Skaffold pipeline will be blocked on the custom test to complete or fail. Skaffold will block deployment when the first test fails. For ongoing test failures in the dev loop, Skaffold will stop the loop (not continue with the deploy) but will not exit the loop. Skaffold would surface the errors to the user and will keep the dev loop running. Skaffold will continue watching user specified test dependencies and re-trigger the loop whenever it detects another change.

In cluster build

Mon, 01 Jan 0001 00:00:00 +0000

Skaffold supports building in cluster via Kaniko or Custom Build Script.

Configuration

To configure in-cluster Build, add build type cluster to the build section of skaffold.yaml.

build:
  cluster: {}

The following options can optionally be configured:

Option	Description	Default
`HTTP_PROXY`	for kaniko pod.
`HTTPS_PROXY`	for kaniko pod.
`pullSecretPath`	path to the Google Cloud service account secret key file.
`pullSecretName`	name of the Kubernetes secret for pulling base images and pushing the final image. If given, the secret needs to contain the Google Cloud service account secret key under the key `kaniko-secret`.	`kaniko-secret`
`pullSecretMountPath`	path the pull secret will be mounted at within the running container.
`namespace`	Kubernetes namespace. Defaults to current namespace in Kubernetes configuration.
`timeout`	amount of time (in seconds) that this build is allowed to run. Defaults to 20 minutes (`20m`).
`dockerConfig`	describes how to mount the local Docker configuration into a pod.
`serviceAccount`	describes the Kubernetes service account to use for the pod. Defaults to ‘default’.
`tolerations`	describes the Kubernetes tolerations for the pod.	`[]`
`nodeSelector`	describes the Kubernetes node selector for the pod.	`{}`
`annotations`	describes the Kubernetes annotations for the pod.	`{}`
`labels`	describes the Kubernetes labels for the pod.	`{}`
`runAsUser`	defines the UID to request for running the container. If omitted, no SecurityContext will be specified for the pod and will therefore be inherited from the service account.
`resources`	define the resource requirements for the kaniko pod.
`concurrency`	how many artifacts can be built concurrently. 0 means “no-limit”.	`0`
`volumes`	defines container mounts for ConfigMap and Secret resources.	`[]`
`randomPullSecret`	adds a random UUID postfix to the default name of the pull secret to facilitate parallel builds, e.g. kaniko-secretdocker-cfgfd154022-c761-416f-8eb3-cf8258450b85.	`false`
`randomDockerConfigSecret`	adds a random UUID postfix to the default name of the docker secret to facilitate parallel builds, e.g. docker-cfgfd154022-c761-416f-8eb3-cf8258450b85.	`false`

Faster builds

Skaffold can build multiple artifacts in parallel, by settings a value higher than 1 to concurrency. For in-cluster builds, the default is to build all the artifacts in parallel. If your cluster is too small, you might want to reduce the concurrency. Setting concurrency to 1 will cause artifacts to be built sequentially.

Jib Build

Mon, 01 Jan 0001 00:00:00 +0000

Jib is a set of plugins for Maven and Gradle for building optimized OCI-compliant container images for Java applications without a Docker daemon.

Skaffold can help build artifacts using Jib; Jib builds the container images and then pushes them to the local Docker daemon or to remote registries as instructed by Skaffold.

Skaffold requires using Jib v1.4.0 or later.

Skaffold supports building with Jib

Jib Maven and Gradle locally

Configuration

Kubectl

Mon, 01 Jan 0001 00:00:00 +0000

Deploying with kubectl

kubectl is Kubernetes command-line tool for deploying and managing applications on Kubernetes clusters.

Skaffold can work with kubectl to deploy artifacts on any Kubernetes cluster, including Google Kubernetes Engine clusters and local Minikube clusters.

Configuration

To use kubectl, add deploy type kubectl to the deploy section of skaffold.yaml.

The kubectl type offers the following options:

Option	Description	Default
`flags`	additional flags passed to `kubectl`.
`remoteManifests`	Kubernetes manifests in remote clusters.	`[]`
`defaultNamespace`	default namespace passed to kubectl on deployment if no other override is given.
`hooks`	describes a set of lifecycle hooks that are executed before and after every deploy.

flags section offers the following options:

Raw YAML

Mon, 01 Jan 0001 00:00:00 +0000

Rendering with raw YAML

In the case that your project does not currently use a render engine (helm, kustomize, kpt, etc), the rawYaml renderer should be used. This instructs skaffold to only do it’s own yaml field replacement (image: and labels: modifications) and not to use any additional render engine.

Configuration

To use rawYaml, add render type rawYaml to the manifests section of skaffold.yaml.

The rawYaml configuration accepts a list of paths to your manifests with glob syntax supported.

Bazel

Mon, 01 Jan 0001 00:00:00 +0000

Bazel is a fast, scalable, multi-language, and extensible build system.

Skaffold can help build artifacts using Bazel locally; after Bazel finishes building container images, they will be loaded into the local Docker daemon.

Configuration

To use Bazel, bazel field to each artifact you specify in the artifacts part of the build section, and use the build type local. context should be a path containing the bazel files (WORKSPACE and BUILD). The following options can optionally be configured:

Debugging With Skaffold

Mon, 01 Jan 0001 00:00:00 +0000

Skaffold lets you set breakpoints and step through your application, even when deployed to remote Kubernetes clusters, as if the code were running locally on your machine. Skaffold detects the language runtimes of your container images, reconfigures the pods for debugging, forwards debugging ports, and then monitors for when debuggable containers come online. IDE integrations like Cloud Code leverage Skaffold’s events to automatically set up debugging sessions.

Debugging is currently supported for five language runtimes.

Google Cloud Build

Mon, 01 Jan 0001 00:00:00 +0000

Skaffold supports building remotely with Google Cloud Build.

Cloud Build is a Google Cloud Platform service that executes your builds using Google infrastructure. To get started with Cloud Build, see Cloud Build Quickstart.

Skaffold automatically connects to Cloud Build and runs your builds with it. After Cloud Build finishes building your artifacts, they are saved to the specified remote registry, such as Google Container Registry.

Skaffold’s Cloud Build process differs from the gcloud command gcloud builds submit. Skaffold does the following:

gRPC API

Mon, 01 Jan 0001 00:00:00 +0000

This is a generated reference for the Skaffold API gRPC layer.

We also generate the reference doc for the HTTP layer.

v2/skaffold.proto

You can find the source for v2/skaffold.proto on Github.

Services

SkaffoldV2Service

Describes all the methods for the Skaffold API

Method Name	Request Type	Response Type	Description
GetState	.google.protobuf.Empty	State	Returns the state of the current Skaffold execution
Events	.google.protobuf.Empty	Event stream	Returns all the events of the current Skaffold execution from the start
ApplicationLogs	.google.protobuf.Empty	Event stream	Returns all the user application logs of the current Skaffold execution
Execute	UserIntentRequest	.google.protobuf.Empty	Allows for a single execution of some or all of the phases (build, sync, deploy) in case autoBuild, autoDeploy or autoSync are disabled.
AutoBuild	TriggerRequest	.google.protobuf.Empty	Allows for enabling or disabling automatic build trigger
AutoSync	TriggerRequest	.google.protobuf.Empty	Allows for enabling or disabling automatic sync trigger
AutoDeploy	TriggerRequest	.google.protobuf.Empty	Allows for enabling or disabling automatic deploy trigger
Handle	Event	.google.protobuf.Empty	EXPERIMENTAL. It allows for custom events to be implemented in custom builders for example.

Data types

gRPC API

Mon, 01 Jan 0001 00:00:00 +0000

This is a generated reference for the Skaffold API gRPC layer.

We also generate the reference doc for the HTTP layer.

v1/skaffold.proto

You can find the source for v1/skaffold.proto on Github.

Services

SkaffoldService

Describes all the methods for the Skaffold API

Method Name	Request Type	Response Type	Description
GetState	.google.protobuf.Empty	State	Returns the state of the current Skaffold execution
EventLog	LogEntry stream	LogEntry stream	DEPRECATED. Events should be used instead. TODO remove (https://github.com/GoogleContainerTools/skaffold/issues/3168)
Events	.google.protobuf.Empty	LogEntry stream	Returns all the events of the current Skaffold execution from the start
Execute	UserIntentRequest	.google.protobuf.Empty	Allows for a single execution of some or all of the phases (build, sync, deploy) in case autoBuild, autoDeploy or autoSync are disabled.
AutoBuild	TriggerRequest	.google.protobuf.Empty	Allows for enabling or disabling automatic build trigger
AutoSync	TriggerRequest	.google.protobuf.Empty	Allows for enabling or disabling automatic sync trigger
AutoDeploy	TriggerRequest	.google.protobuf.Empty	Allows for enabling or disabling automatic deploy trigger
Handle	Event	.google.protobuf.Empty	EXPERIMENTAL. It allows for custom events to be implemented in custom builders for example.

Data types

Kpt [NEW]

Mon, 01 Jan 0001 00:00:00 +0000

Note

kpt CLI must be installed on your machine for the below functionality. Skaffold will not install it.

`manifests.transform` and `manifests.validate` functionality powered by kpt

With Skaffold V2, skaffold now has a new render phase and associated manifests top level config field. Along with these changes, a manifests.transform and a manifests.validate field were added which allows users to specify kpt manifest transformations and validations to be done in the render phase. manifests.transform allows users to create a pipeline of manifest transformations which transform manifests via the specified container. For more information on the manifests.transform functionality see, the docs for kpt mutators here. For a list of kpt supported containers to use in the manifests.transform schema see the list here with the tag mutator. manifests.validate allows users to create a pipeline of manifest validations that run serially, checking the yaml manifests for the specified validation test. For more information on the manifests.validate functionality, see the docs for kpt validators here. For a list of kpt supported containers to use in the manifests.validate schema see the list here with the tag validator.

Kpt [UPDATED]

Mon, 01 Jan 0001 00:00:00 +0000

Rendering with kpt

kpt allows Kubernetes developers to customize raw, template-free YAML files for multiple purposes. Skaffold can work with kpt by calling its command-line interface.

Configuration

To use kpt with Skaffold, add deploy type kpt to the deploy section of skaffold.yaml.

The kpt type offers the following options:

Option	Description	Default
`dir`	equivalent to the dir in `kpt live apply <dir>`. If not provided, skaffold deploys from the default hydrated path `<WORKDIR>/.kpt-pipeline`.
`applyFlags`	additional flags passed to `kpt live apply`.	`[]`
`flags`	kpt global flags.	`[]`
`name`	alpha inventory object name.
`inventoryID`	alpha inventory ID which annotates the resources being lively applied by kpt.
`namespace`	alpha sets the inventory namespace.
`force`	used in `kpt live init`, which forces the inventory values to be updated, even if they are already set.	`false`
`defaultNamespace`	default namespace passed to kpt on deployment if no other override is given.

Each entry in paths should point to a folder with a kustomization file.

Kustomize

Mon, 01 Jan 0001 00:00:00 +0000

Rendering with kustomize

kustomize allows Kubernetes developers to customize raw, template-free YAML files for multiple purposes. Skaffold can work with kustomize by calling its command-line interface.

Configuration

To use kustomize with Skaffold, add render type kustomize to the manifests section of skaffold.yaml.

The kustomize configuration accepts a list of paths to folders containing a kustomize.yaml file.

Example

The following manifests section instructs Skaffold to render artifacts using kustomize. Each entry should point to a folder with a kustomize.yaml file.

Continuous Delivery

Mon, 01 Jan 0001 00:00:00 +0000

Note

Skaffold is used under the hood to power Google Cloud Platform’s Cloud Deploy API. See the docs here for more information on how to use Skaffold + Cloud Deploy for CI/CD

Skaffold provides several features and sub-command “building blocks” that make it very useful for integrating with (or creating entirely new) CI/CD pipelines. The ability to use the same skaffold.yaml for iterative development and continuous delivery eases handing off an application from a development team to an ops team.

Cross-platform and multi-platform build support

Mon, 01 Jan 0001 00:00:00 +0000

Skaffold selectively supports building for an architecture that is different than the development machine architecture (cross-platform build) or building for multiple architectures (multiple-platform build). The target platforms for an artifact can be specified in one of the following ways:

The pipeline’s platforms property in the skaffold.yaml file.

build:
  platforms: ["linux/arm64"]
  artifacts:
    - image: example

The artifact’s platforms constraints in the skaffold.yaml file. This overrides the value specified in the pipeline’s platforms property.

build:
  artifacts:
    - image: app1
      platforms: ["linux/arm64"]
    - image: app2
      platforms: ["linux/amd64"]

The CLI flag --platform which overrides the values set in both the previous ways.

skaffold build --platform=linux/arm64,linux/amd64

Additionally, for skaffold dev, skaffold debug and skaffold run commands, where the build output gets deployed immediately, skaffold checks the platform for the kubernetes cluster nodes and attempts to build artifacts for that target platform.

Custom Build Script

Mon, 01 Jan 0001 00:00:00 +0000

Custom build scripts allow Skaffold users the flexibility to build artifacts with any builder they desire. Users can write a custom build script which must abide by the following contract for Skaffold to work as expected:

Contract between Skaffold and Custom Build Script

Skaffold will pass in the following additional environment variables to the custom build script:

Environment Variable	Description	Expectation
$IMAGE	The fully qualified image name. For example, “gcr.io/image1:tag”	The custom build script is expected to build this image and tag it with the name provided in $IMAGE. The image should also be pushed if `$PUSH_IMAGE=true`.
$PUSH_IMAGE	Set to true if the image in `$IMAGE` is expected to exist in a remote registry. Set to false if the image is expected to exist locally.	The custom build script will push the image `$IMAGE` if `$PUSH_IMAGE=true`
$BUILD_CONTEXT	An absolute path to the directory this artifact is meant to be built from. Specified by artifact `context` in the skaffold.yaml.	None.
$PLATFORMS	A comma-separated string of platforms to build the image for. For example, `linux/arm64,linux/amd64`.	If there’s only a single platform specified the custom build script should build for that platform. If multiple platforms are specified then the custom build script should build a multi-arch image comprising all those platforms.
$SKIP_TEST	Whether to skip the tests after building.	None.
Local environment variables	The current state of the local environment (e.g. `$HOST`, `$PATH)`. Determined by the golang os.Environ function.	None.

As described above, the custom build script is expected to:

Helm [UPDATED]

Mon, 01 Jan 0001 00:00:00 +0000

helm is a package manager for Kubernetes that helps you manage Kubernetes applications. Skaffold natively supports iterative development for projects configured to use helm.

Note

To use helm with Skaffold, the helm binary must be installed on your machine. Skaffold will not install it for you.

Configuring your Helm Project with Skaffold

Skaffold supports projects set up to render and/or deploy with Helm, but certain aspects of the project need to be configured correctly in order for Skaffold to work properly. This guide should demystify some of the nuance around using Skaffold with Helm to help you get started quickly.

Helm [UPDATED]

Mon, 01 Jan 0001 00:00:00 +0000

helm is a package manager for Kubernetes that helps you manage Kubernetes applications. Skaffold natively supports iterative development for projects configured to use helm.

Note

To use helm with Skaffold, the helm binary must be installed on your machine. Skaffold will not install it for you.

Configuring your Helm Project with Skaffold

HTTP API

Mon, 01 Jan 0001 00:00:00 +0000

This is a generated reference for the Skaffold API HTTP layer.

We also generate the reference doc for the gRPC layer.

HTTP API

Mon, 01 Jan 0001 00:00:00 +0000

This is a generated reference for the Skaffold API HTTP layer.

We also generate the reference doc for the gRPC layer.

Skaffold Pipeline

Mon, 01 Jan 0001 00:00:00 +0000

You can configure Skaffold with the Skaffold configuration file, skaffold.yaml. A single configuration consists of several different components:

Component	Description
`apiVersion`	The Skaffold API version you would like to use. The current API version is skaffold/v4beta14 .
`kind`	The Skaffold configuration file has the kind `Config`.
`metadata`	Holds additional properties like the `name` of this configuration.
`build`	Specifies how Skaffold builds artifacts. You have control over what tool Skaffold can use, how Skaffold tags artifacts and how Skaffold pushes artifacts. Skaffold supports using local Docker daemon, Google Cloud Build, Kaniko, or Bazel to build artifacts. See Builders and Taggers for more information.
`test`	Specifies how Skaffold tests artifacts. Skaffold supports container-structure-tests to test built artifacts and custom tests to run custom commands as part of the development pipeline. See Testers for more information.
`deploy`	Specifies how Skaffold deploys artifacts. Skaffold supports using `kubectl`, `helm`, or `kustomize` to deploy artifacts. See Deployers for more information.
`profiles`	Profile is a set of settings that, when activated, overrides the current configuration. You can use Profile to override the `build`, `test` and `deploy` sections.
`requires`	Specifies a list of other skaffold configurations to import into the current config

You can learn more about the syntax of skaffold.yaml.

Init

Mon, 01 Jan 0001 00:00:00 +0000

skaffold init helps you get started using Skaffold by running you through a wizard and generating the required skaffold.yaml file in the root of your project directory.

The generated skaffold.yaml defines your build and deploy config.

Build Config Initialization

skaffold init currently supports build detection for those builders:

skaffold init walks your project directory and looks for any build configuration files such as Dockerfile, build.gradle/pom.xml, package.json, requirements.txt or go.mod. init skips files that are larger than 500MB.

File Sync

Mon, 01 Jan 0001 00:00:00 +0000

Skaffold supports copying changed files to a deployed container so as to avoid the need to rebuild, redeploy, and restart the corresponding pod. The file copying is enabled by adding a sync section with sync rules to the artifact in the skaffold.yaml. Under the hood, Skaffold creates a tar file with changed files that match the sync rules. This tar file is sent to and extracted on the corresponding containers.

Log Tailing

Mon, 01 Jan 0001 00:00:00 +0000

Skaffold has built-in support for tailing logs for containers built and deployed by Skaffold on your cluster to your local machine when running in either dev, debug or run mode.

Note

Log Tailing is enabled by default for dev and debug.
Log Tailing is disabled by default for run mode; it can be enabled with the --tail flag.

Log Structure

To view log structure, run skaffold run --tail in examples/microservices

skaffold run --tail

will produce an output like this

Verify [NEW]

Mon, 01 Jan 0001 00:00:00 +0000

Skaffold v2.0.0+ supports running post-deployment verification tests. You define these tests as a list of test containers that are either standalone or built by Skaffold. Skaffold runs these containers after the deploy stage and monitors them for success or failure.

You can configure and execute post-deployment verification tests using the verify command and associated skaffold.yaml schema configuration.

Execution modes

You can run post-deployment verification tests in the following execution environments:

A local Docker environment
A Kubernetes cluster environment

Local

When Skaffold runs a post-deployment verifications test in the local execution mode, it uses the docker CLI to run the test container on the host machine. This is the default execution mode.

Deploy Status Checking

Mon, 01 Jan 0001 00:00:00 +0000

This page describes how Skaffold’s deployment status checking waits for deployed resources to become ready, and reports errors if they fail to stabilize within a certain time period.

Overview

Commands that trigger a deployment, like skaffold dev, skaffold deploy, skaffold run, and skaffold apply, monitor select resources and wait for them to become ready.

Skaffold monitors the status of the following resource types:

Pod: check that the pod and its containers are in a Ready state.
Deployment: check the output of kubectl rollout status deployment command
Stateful Sets: check the output of kubectl rollout status statefulset command
Cloud Run instances (running containers) are ready to receive traffic

Note

Status checking is enabled by default; it can be disabled with the --status-check=false flag, or by setting the statusCheck field of the deployment config stanza in the skaffold.yaml to false.

Lifecycle Hooks

Mon, 01 Jan 0001 00:00:00 +0000

This page describes how to use the lifecycle hook framework to run code triggered by different events during the skaffold process lifecycle.

Overview

We identify three distinct phases in skaffold - build, sync and deploy. Skaffold can trigger a hook before or after executing each phase. There are two types of hooks that can be defined - host hooks and container hooks.

Host hooks

Host hooks are executed on the runner and can be defined for the following phases:

Port Forwarding

Mon, 01 Jan 0001 00:00:00 +0000

Skaffold has built-in support for forwarding ports from exposed Kubernetes resources on your cluster to your local machine when running in dev, debug, deploy, or run modes.

Automatic Port Forwarding

Skaffold supports automatic port forwarding the following classes of resources:

user: explicit port-forwards defined in the skaffold.yaml (called user-defined port forwards)
services: ports exposed on services deployed by Skaffold.
debug: debugging ports as enabled by skaffold debug for Skaffold-built images.
pods: all containerPorts on deployed pods for Skaffold-built images.

Skaffold enables certain classes of forwards by default depending on the Skaffold command used. These defaults can be overridden with the --port-forward flag, and port-forwarding can be disabled with --port-forward=off.

Cleanup

Mon, 01 Jan 0001 00:00:00 +0000

Skaffold works with image builders and deployers that both have side effects on both your local and deployment environments:

resources are created in one or more namespaces in a Kubernetes cluster
images might be created on the local Docker daemon
images might be pushed to registries
application might have arbitrary side effects

Skaffold offers cleanup functionality to negate some of these side effects:

Kubernetes resource cleanup - skaffold delete, and automatic cleanup on Ctrl+C for skaffold dev and skaffold debug
Image pruning - for local Docker daemon images only, automatically on Ctrl+C for skaffold dev and skaffold debug

For pushed images in registries and application side effects the user has to take care of cleanup.

Custom Actions

Mon, 01 Jan 0001 00:00:00 +0000

With Skaffold you can define generic actions in a declarative way using a Skaffold config file (skaffold.yaml), and execute them with the skaffold exec <action-name> command.

A generic action (a.k.a. Custom Action), defines a list of containers that will be executed in parallel when the action is invoked. A Custom Action execution is considered successful if all its containers end without errors, and considered as failed if one or more of its containers report an error.

Cloud Native Buildpacks

Mon, 01 Jan 0001 00:00:00 +0000

Cloud Native Buildpacks enable building a container image from source code without the need for a Dockerfile.

Skaffold supports building with Cloud Native Buildpacks, requiring only a local Docker daemon. Skaffold performs the build inside a container using the builder specified in the buildpack config.

On successful build completion, the built image will be pushed to the remote registry. You can choose to skip this step.

Configuration

To use Buildpacks, add a buildpack field to each artifact you specify in the artifacts part of the build section. context should be a path to your source.

Docker

Mon, 01 Jan 0001 00:00:00 +0000

Note

This feature is currently experimental and subject to change.

Deploying applications to a local Docker daemon

For simple container-based applications that don’t rely on Kubernetes resource types, Skaffold can “deploy” these applications by running application containers directly in your local Docker daemon. This enables application developers who are not yet ready to make the jump to Kubernetes to take advantage of the streamlined development experience Skaffold provides.

Additionally, deploying to Docker bypasses the overhead of pushing images to a remote registry, and provides a faster time to running application than traditional Kubernetes deployments.

Global Configuration

Mon, 01 Jan 0001 00:00:00 +0000

Some context specific settings can be configured in a global configuration file, which defaults to ~/.skaffold/config. Options can be configured globally or for specific Kubernetes contexts. Context name matching supports regex, e.g.: .*-cluster.*-regex.*-test.*

The options are:

Option	Type	Description
`default-repo`	string	The image registry where built artifact images are published (see image name rewriting).
`multi-level-repo`	boolean	If true, do not replace ‘.’ and ‘/’ with ‘_’ in image name.
`debug-helpers-registry`	string	The image registry where debug support images are retrieved (see debugging).
`insecure-registries`	list of strings	A list of image registries that may be accessed without TLS.
`k3d-disable-load`	boolean	If true, do not use `k3d import image` to load images locally.
`kind-disable-load`	boolean	If true, do not use `kind load` to load images locally.
`local-cluster`	boolean	If true, do not try to push images after building. By default, contexts with names `docker-for-desktop`, `docker-desktop`, or `minikube` are treated as local.
`update-check`	boolean	Check for a more recent version of Skaffold.
`collect-metrics`	boolean	Collect anonymized usage data.

For example, to treat any context as local by default:

Load environment variables from a file

Mon, 01 Jan 0001 00:00:00 +0000

In Skaffold, a skaffold.env file can be defined in the project root directory to specify environment variables that Skaffold will load into the process. This provides a more organized and manageable way of setting environment variables, rather than passing them as command line arguments.

The skaffold.env file should be in the format of KEY=value pairs, with one pair per line. Skaffold will automatically load these variables into the environment before running any commands.

Managing ARM workloads [NEW]

Mon, 01 Jan 0001 00:00:00 +0000

Skaffold has a lot of intelligence built-in to simplify working with ARM workloads. Whether developing on an Apple Silicon Macbook that uses an ARM based chip, or deploying to a GKE Kubernetes cluster having ARM nodes, Skaffold can take away the complexities that arise when the architecture of your development machine and Kubernetes cluster don’t match.

Why is image architecture important?

Container images are built targeting specific Instruction Set Architectures like amd64, arm64, etc. You must use container images that are compatible with the architecture of the node where you intend to run the workloads. For example, to deploy to a GKE cluster running ARM nodes, the image needs to be built for linux/arm64 platform.

Privacy Settings

Mon, 01 Jan 0001 00:00:00 +0000

The privacy of our users is very important to us. Your use of this software is subject to the Google Privacy Policy.

Update check

To keep Skaffold up to date, update checks are made to Google servers to see if a new version of Skaffold is available. By default, this behavior is enabled. As a side effect this request is logged.

To disable the update check you have two options:

Deprecation Policy

Mon, 01 Jan 0001 00:00:00 +0000

This document sets out the deprecation policy for Skaffold, and outlines how the Skaffold project will approach the introduction of breaking changes over time.

Deprecation policy applies only to Stable Builds. Bleeding Edge builds may have less stable implementations.

Deprecations to a flag or CLI command require the following notification periods, depending on the release track:

Release Track	Deprecation Period
Alpha (experimental)	0 releases
Beta (pre-release)	3 months or 1 release (whichever is longer)
GA (generally available)	6 months or 1 release (whichever is longer)

Breaking changes A breaking change is when the primary functionality of a feature changes in a way that the user has to make changes to their workflows/configuration.

Google Cloud Run [NEW]

Mon, 01 Jan 0001 00:00:00 +0000

Note

This feature is currently experimental and subject to change. Not all Skaffold features are supported, for example debug is currently not supported in Cloud Run (but is on our roadmap).

Cloud Run is a managed compute platform on Google Cloud that allows you to run containers on Google’s infrastructure. With Skaffold, now you are able to configure your dev loop to build, test, sync and use Cloud Run as the deployer for your images.

ko

Mon, 01 Jan 0001 00:00:00 +0000

ko enables fast, standardized, reproducible, configuration-less, Docker-less, and multi-platform container image builds for Go apps.

Skaffold embeds ko as a library, so you do not need to download ko to use the ko builder.

Benefits of the ko builder

Compared to …

the Cloud Native buildpacks builder, the ko builder is fast, doesn’t require Docker, and uses a default base image that has a small attack surface.
the Docker builder, the ko builder standardizes builds, avoiding artisanal snowflake Dockerfiles. It also doesn’t require the Docker daemon, so builds can run in environments where Docker isn’t available for security reasons.

Local Cluster

Mon, 01 Jan 0001 00:00:00 +0000

Skaffold supports fast deployments to supported locally-hosted clusters, such as minikube and Docker Desktop, by loading images directly into the cluster. Loading images is typically much faster than the roundtrip required to push an image to a remote registry and then for the cluster to pull that image again.

Auto detection

Skaffold’s heuristic to detect local clusters is based on the Kubernetes context name set on kubectl. You can find your the current context name by running:

Skaffold API

Mon, 01 Jan 0001 00:00:00 +0000

When running skaffold dev or skaffold debug, Skaffold starts a server that exposes an API over the lifetime of the Skaffold process. Besides the CLI, this API is the primary way tools like IDEs integrate with Skaffold for retrieving information about the pipeline and for controlling the phases in the pipeline.

To retrieve information about the Skaffold pipeline, the Skaffold API provides two main functionalities:

A streaming event log created from the different phases in a pipeline run, and

Image Repository Handling

Mon, 01 Jan 0001 00:00:00 +0000

Often, a Kubernetes manifest (or skaffold.yaml) makes references to images that push to registries that we might not have access to. Modifying these individual image names manually is tedious, so Skaffold supports automatically prefixing these image names with a registry specified by the user. Using this, any project configured with Skaffold can be run by any user with minimal configuration, and no manual YAML editing!

This is accomplished through the default-repo functionality, and can be used one of three ways:

Profiles

Mon, 01 Jan 0001 00:00:00 +0000

Skaffold profiles allow you to define build, test and deployment configurations for different contexts. Different contexts are typically different environments in your app’s lifecycle, like Production or Development.

You can create profiles in the profiles section of skaffold.yaml.

For a detailed discussion on Skaffold configuration, see Skaffold Concepts and skaffold.yaml References.

Profiles (`profiles`)

Each profile has six parts:

Name (name): The name of the profile
Build configuration (build)
Test configuration (test)
Deploy configuration (deploy)
Patches (patches)
Activation (activation)

Once a profile is activated, the specified build, test and deploy configuration in it will be laid onto, but won’t completely replace, the build, test and deploy sections declared in the main section of skaffold.yaml. The build, test and deploy configuration in the profiles section use the same syntax as the build, test and deploy sections of skaffold.yaml; for more information, see Builders, Testers, Deployers and you can always refer to skaffold.yaml reference for an overview of the syntax. Alternatively, you can override the main configuration with finer grained control using patches.

Kube-context Activation

Mon, 01 Jan 0001 00:00:00 +0000

When interacting with a Kubernetes cluster, just like any other Kubernetes-native tool, Skaffold requires a valid Kubernetes context to be configured. The selected kube-context determines the Kubernetes cluster, the Kubernetes user, and the default namespace. By default, Skaffold uses the current kube-context from your kube-config file.

You can override this default one of two ways:

--kube-context flag
```
skaffold dev --kube-context <myrepo>
```
Specify deploy.kubeContext configuration in skaffold.yaml
```
deploy:
  kubeContext: minikube
```

The CLI flag always takes precedence over the config field in the skaffold.yaml.

Use Skaffold to build and deploy an application on Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

This is a link to an introductory Cloud Shell tutorial. In this tutorial, you will:

Use skaffold init to bootstrap your Skaffold config.
Use skaffold dev to automatically build and deploy your application when your code changes.
Use skaffold build and skaffold test to tag, push, and test your container images.
Use skaffold render and skaffold apply to generate and deploy Kubernetes manifests as part of a GitOps workflow.

Manage CRDs w/ Skaffold - Configuring Which K8s Resources & Fields Skaffold Manages

Mon, 01 Jan 0001 00:00:00 +0000

Common Use Cases This Page Helps Resolve:

Users who want skaffold to properly manage the rendering and deployment of their custom CRDs (as skaffold does with K8s objects like Pod, Deployment.apps, etc.)
- Additionally users w/ a CRD that uses a different field name for image: (eg: foo:) and want skaffold to properly modify the value to instead have the image label for the image skaffold recently built
Users who are seeing issues with skaffold’s default resource field overwriting for a given resource - eg: skaffold errors as it tries to mutate immutable config on re-deployment

Currently skaffold modifies the manifests it renders and deploys for the following functionality:

Templated Fields

Mon, 01 Jan 0001 00:00:00 +0000

Skaffold allows for certain fields in the config to be templated via the Go text/template package. Environment variables and certain special values computed by Skaffold (see below) are available in the templating context (defined as “dot” or .).

Go templates are quite powerful, including control flow, arguments, pipelining and variables. Predefined functions in the standard library are complemented in Skaffold by the Sprig template function library.

build:
  tagPolicy:
    envTemplate:
      template: "{{.FOO}}"
  artifacts:
  - image: gcr.io/k8s-skaffold/example

Suppose the value of the FOO environment variable is v1, the image built will be gcr.io/k8s-skaffold/example:v1.

Defining dependencies between artifacts

Mon, 01 Jan 0001 00:00:00 +0000

This page describes how to define dependencies between artifacts and reference them in the docker builder.

Before you begin

First, you will need to have Skaffold and a Kubernetes cluster set up. To learn more about how to set up Skaffold and a Kubernetes cluster, see the quickstart docs.

Tutorial - Simple artifact dependency

This tutorial will be based on the simple-artifact-dependency example in our repository.

Adding an artifact dependency

We have a base artifact which has a single Dockerfile that we build with the docker builder:

Importing configuration as dependencies

Mon, 01 Jan 0001 00:00:00 +0000

Skaffold’s config dependencies feature allows you to import configurations defined across multiple skaffold.yaml files (even across repositories) into a single configuration as its dependencies. This helps more readily integrate Skaffold with multi-microservice and multi-repository applications.

For a guided Cloud Shell tutorial on setting up local dependencies, follow:

For a guided Cloud Shell tutorial on setting up remote git dependencies, follow:

Building Artifacts with a Custom Build Script

Mon, 01 Jan 0001 00:00:00 +0000

This page describes building Skaffold artifacts using a custom build script, which builds images using ko. ko builds containers from Go source code, without the need for a Dockerfile or even installing Docker.

Before you begin

First, you will need to have Skaffold and a Kubernetes cluster set up. To learn more about how to set up Skaffold and a Kubernetes cluster, see the quickstart docs.

Tutorial - Hello World in Go

This tutorial will be based on the custom example in our repository.

Developer Journey with Buildpacks

Mon, 01 Jan 0001 00:00:00 +0000

Skaffold Developer Journey with Buildpacks Tutorial

Introduction

What is this project?

Skaffold allows developers to easily transition from local development on minikube to remote development on an enterprise Kubernetes cluster managed by IT. During the transition from local to remote deployment, a security team might ask a developer to patch a library with a specific vulnerability in it. This is where Skaffold’s support for buildpacks comes in handy. In this tutorial, you’ll start out deploying an application locally, swap out buildpacks in the skaffold.yaml file to use the latest libraries, and then deploy the application to a remote Kubernetes cluster.

Go integration test coverage profiles

Mon, 01 Jan 0001 00:00:00 +0000

This tutorial describes how to use Skaffold to collect coverage profile data from Go applications when running integration tests. These more comprehensive tests, often called end-to-end tests, are run against a deployed application, typically testing multiple user journeys.

Background

Go 1.20 introduced support for collecting coverage profile data from running Go applications. To enable coverage collection, build the binary with the -cover flag. The application records coverage profile data in a local directory set by the GOCOVERDIR environment variable.

Override the run image in buildpacks builder

Mon, 01 Jan 0001 00:00:00 +0000

This is a link to a guided Cloud Shell tutorial using skaffold’s artifact dependency feature to override the run image in the buildpacks builder:

Using Skaffold for CI/CD with GitLab

Mon, 01 Jan 0001 00:00:00 +0000

Contributed by: @tvvignesh

Skaffold is a tool which is non-opinionated about the CI/CD tool you should use and acts as a platform agnostic solution for both development and deploying to production.

To facilitate building and deploying images in CI/CD, skaffold offers docker images which you can build on top of. If that doesn’t work for your use-case, you can make your own Dockerfile and pull in skaffold and its dependencies using curl.

Search Results

Mon, 01 Jan 0001 00:00:00 +0000

Skaffold

Docker Build

Dockerfile with Docker locally

Getting Started With Your Project

What’s next

Local build

Configuration

Faster builds

Container Structure Test

skaffold dev

Custom Test

In cluster build

Configuration

Faster builds

Jib Build

Jib Maven and Gradle locally

Kubectl

Deploying with kubectl

Configuration

Raw YAML

Rendering with raw YAML

Configuration

Bazel

Debugging With Skaffold

Google Cloud Build

gRPC API

v2/skaffold.proto

Services

SkaffoldV2Service

Data types

gRPC API

v1/skaffold.proto

Services

SkaffoldService

Data types

Kpt [NEW]

Note

manifests.transform and manifests.validate functionality powered by kpt

Kpt [UPDATED]

Rendering with kpt

Configuration

Kustomize

Rendering with kustomize

Configuration

Example

Continuous Delivery

Note

Cross-platform and multi-platform build support

Custom Build Script

Contract between Skaffold and Custom Build Script

Helm [UPDATED]

Note

Configuring your Helm Project with Skaffold

Helm [UPDATED]

Note

Configuring your Helm Project with Skaffold

HTTP API

HTTP API

Skaffold Pipeline

Init

Build Config Initialization

Tag

File Sync

Log Tailing

Note

Log Structure

Verify [NEW]

Execution modes

Local

Deploy Status Checking

Overview

Note

Lifecycle Hooks

Overview

Host hooks

Port Forwarding

Automatic Port Forwarding

Cleanup

Custom Actions

Cloud Native Buildpacks

`manifests.transform` and `manifests.validate` functionality powered by kpt

Profiles (`profiles`)