googlecontainertools/skaffold

Easy and Repeatable Kubernetes Development

---

Skaffold is a command line tool that facilitates continuous development for Kubernetes applications. You can iterate on your application source code locally then deploy to local or remote Kubernetes clusters. Skaffold handles the workflow for building, pushing and deploying your application. It also provides building blocks and describe customizations for a CI/CD pipeline.

---

Install Skaffold

Or, check out our Github Releases page for release info or to install a specific version.

Features

• Blazing fast local development
  • optimized source-to-deploy - Skaffold detects changes in your source code and handles the pipeline to build, push, and deploy your application automatically with policy based image tagging
  • continuous feedback - Skaffold automatically aggregates logs from deployed resources and forwards container ports to your local machine
• Project portability
  • share with other developers - Skaffold is the easiest way to share your project with the world: git clone and skaffold run
  • context aware - use Skaffold profiles, user level config, environment variables and flags to describe differences in environments
  • CI/CD building blocks - use skaffold run end-to-end, or use individual Skaffold phases to build up your CI/CD pipeline. skaffold render outputs hydrated Kubernetes manifests that can be used in GitOps workflows.
• Pluggable, declarative configuration for your project
  • skaffold init - Skaffold discovers your files and generates its own config file
  • multi-component apps - Skaffold supports applications consisting of multiple components
  • bring your own tools - Skaffold has a pluggable architecture to integrate with any build or deploy tool
• Lightweight
  • client-side only - Skaffold has no cluster-side component, so there is no overhead or maintenance burden
  • minimal pipeline - Skaffold provides an opinionated, minimal pipeline to keep things simple

Check out our examples page for more complex workflows!

IDE integrations

For a managed experience of Skaffold you can install the Google Cloud Code extensions:

• for Visual Studio Code
• for JetBrains IDEs.

It can manage and keep Skaffold up-to-date while providing a more guided startup experience, along with providing and managing other common dependencies, and works with any kubernetes cluster.

Contributing to Skaffold

We welcome any contributions from the community with open arms - Skaffold wouldn't be where it is today without contributions from the community! Have a look at our contribution guide for more information on how to get started on sending your first PR.

Community

Come hang out with us!

• We're always around on #skaffold on Kubernetes Slack
• skaffold-users mailing list
• Have something you want us to hear? Give us feedback!

Office Hours

We hold open office hours on the last Wednesday of the month at 9:30 AM Pacific Time. This is an open forum for anyone to show up and bring ideas, concerns, or just in general come hang out with the team! This is also a great time to get direct feedback on contributions, or give us feedback on ways you think we can improve the project. Come show us how you're using Skaffold!

Join the skaffold-users mailing list to get the calendar invite directly on your calendar. You can access the hangouts invite directly from this calendar invite.

Survey

Your feedback is very valuable to us! We have an anonymous user feedback survey - please help us by spending a quick 5 minutes to tell us how satisfied you are with Skaffold, and what improvements we should make! You can also run skaffold survey from your terminal to open the survey directly in your default browser.

Survey Link - https://forms.gle/BMTbGQXLWSdn7vEs6

Support

Skaffold is generally available and considered production ready. Detailed feature maturity information and how we deprecate features are described in our Deprecation Policy.

Security Disclosures

Please see our security disclosure process. All security advisories are managed on Github.

skaffold's Issues

Getting started documentation

Arch Linux AUR package

Add e2e tests

Tag Spec Validation

We need to make sure that some parameters are valid docker tags before it gets to the downstream tools and fails. We should vendor in the validation from docker/moby

Add watchers for Dockerfile and deploy dependencies

These are currently not watched. The dockerfile is easy to watch, however we need a way for deploy implementations to expose their dependencies.

Improve build and deploy output from docker daemon/registry

We are not processing the messages from the docker daemon or registry properly, so output isn't as pretty as it should be. We should compress status updates for the same layers, add progress bars, etc.

Example:

abe52c89597f: Verifying Checksum
abe52c89597f: Download complete
96e333289084: Verifying Checksum
96e333289084: Download complete
39cd5f38ffb8: Verifying Checksum
39cd5f38ffb8: Download complete
503166935590: Verifying Checksum
503166935590: Download complete
ce145c5cf4da: Verifying Checksum
ce145c5cf4da: Download complete
503166935590: Pull complete
abe52c89597f: Pull complete
ce145c5cf4da: Pull complete
96e333289084: Pull complete
39cd5f38ffb8: Pull complete

[Build] Automatically detect and set minikube docker opts from kube context

Port this code and add tests

https://github.com/r2d4/skaffold/blob/master/pkg/skaffold/builder/minikube.go

[Deploy] Add context target to Deploy Config

Add ability to deploy to a specific cluster context or maybe multiple contexts.

[Deploy] Add Ksonnet Deployer

Command that helps maintainers debug user issues

In other projects I've worked on, there has been a command (something like skaffold debug) that puts together either a bundle of artifacts or prints out information that can be useful for maintainers to either reproduce or further debug issues that are reported. We could add a note to the issue template that asks users to run this command and add the info to their report.

Handle optional port-forwarding

I started to go down the route of figuring out how to work with Skaffold and use a remote debugger (delve in my case).

The only thing I really needed from Skaffold was for it to be able to reconfigure a port-forwarding setup to one of the new pods that was created.

I think it could look something like:

portForwarding:
  - labelSelector:
      app: my-app
      component: backend
    port: 2345
  - labelSelector:
      app: my-app
      component: frontend
    port: 8080:80

Skaffold could pick the most recently deployed pod that matches the selectors, although some more precise detection of the "right pod" may be necessary.

Allow deploy steps to use a configurable context for K8s clusters

When deploying, you may want to define a specific cluster to use rather than the one that is configured on the local host.

`skaffold dev` should return warning on build or deploy failure

[Build] Expose Docker CLI configurations in Config

DOCKER_HOST
DOCKER_CERT_PATH
etc.

We read these from the environment variables now (or generate them from minikube), but it might be useful to expose these options as overrides in the config.

Support .dockerignore files in dependency calculation.

Perform cleanup during development or on exit

This is an umbrella issue for some ideas on how we might clean up the development artifacts we create in a skaffold dev pipeline.

• Auto prune images/tags to save disk splace

Add `skaffold dev` command

Add more verbose buildtime info to build

We should have something like this

	return apimachineryversion.Info{
		Major:        gitMajor,
		Minor:        gitMinor,
		GitVersion:   gitVersion,
		GitCommit:    gitCommit,
		GitTreeState: gitTreeState,
		BuildDate:    buildDate,
		GoVersion:    runtime.Version(),
		Compiler:     runtime.Compiler,
		Platform:     fmt.Sprintf("%s/%s", runtime.GOOS, runtime.GOARCH),
	}

https://github.com/kubernetes/kubernetes/blob/master/pkg/version/version.go#L31-L40

Formattable with the TemplateFlag in skaffold version

Inspect parent images for ONBUILD instructions

We'll have to download and inspect parent dockerfiles for deferred instructions.

Add `skaffold run` command

Add configurable ignore-list for watched dependencies

Even though we can calculate all the dependencies, users might not want to (or be able to) watch all dependencies for a large project. We should figure out how we want to expose a ignore functionality to the user

#15 (comment)

Integration tests for all examples

All examples should be covered by integration tests. We should always keep examples up to date with new changes, and convey to the users clearly when there are breaking change. We can do this with release notes or config comments.

[Deploy] Stream logs from deployed containers

Port this code and add tests https://github.com/r2d4/skaffold/blob/master/pkg/skaffold/kubernetes/logs/logs.go

[Deploy] Add Kubectl Deployer

Brew package

brew install skaffold

Deploy files under glob

https://github.com/GoogleCloudPlatform/skaffold/blob/master/pkg/skaffold/deploy/kubectl.go#L67

It should definitely be expanded to cover .yaml, .yml, and .json.

Additionally, if the file is a specific reference to a file and not a glob, we should try to deploy that regardless.

Updates of workloads due to ConfigMap changes

When a ConfigMap manifest is updated, users may want that to automatically update the workload that it references. Unfortunately the deployment will only update if the configmap name or any other field changes in the spec.

[Dockerfile] Resolve envvar when ENV inherited from parent image

We don't currently support the scenario when an ENV is inherited from the parent image and then used in the source of a COPY or ADD. As a short term solution, we can add the entire context, but we might want to figure out a way to resolve those ENVs without adding everything.

Set Config Defaults

Build and deploy prechecks

Add prechecks to both builders and deployers to ensure basic conditions before the pipeline is ran. This could be implemented as an interface that both Builder and Deployer embed.

Some ideas for prechecks:

• LocalBuilder: Ensure connection to docker daemon
• KubectlDeploy: Ensure connection to cluster, kubectl installed
• HelmDeploy: Ensure connection to cluster, helm installed, (tiller installed?)

Should these prechecks also verify manifest conditions? I think eventually we might want to add some sort of linting of kubernetes resources, and possibly extend that to skaffold resources.

Windows Support?

[UX] Add command completion

This is already provided by the CLI library we're using.

Subcommands for build and deploy implementations

Exposing the build and deploy steps as single runnable commands

$ skaffold build local
$ skaffold deploy helm --chart-path

We could autogenerate most, if not all, of the command by iterating over BuildType and DeployType and then generating flags based on the parameters on the subtypes like LocalBuild. Each command would output a go-template BuildResult or DeployResult.

[Watch] Add Watch API

Kubectl Deploy: Allow directories/globs

Instead of having to list every manifest

[Builder] Support Google Cloud Build

Push to registry should be the default for local builder

Currently you have to have

local
  push: true

This is part of #47

Add unit test coverage for util.RunCommand

We should add info and debug level logging to this function also. As we add more build and deploy implementations, we'll be using this a lot so it should have good test coverage.

To test exec.Command, we can shell out to the test binary like the std library does https://github.com/golang/go/blob/master/src/os/exec/exec_test.go#L33

We can also use the fake readclosers in our testutil package.

[Deploy] Add Helm Deployer

Dockerfile, Context resolution should have its own function

https://github.com/GoogleCloudPlatform/skaffold/blob/910aa891c5f2dc28cdc95602067f0a1ca45f5806/pkg/skaffold/build/local.go#L60-L62

https://github.com/GoogleCloudPlatform/skaffold/blob/87beed031679b0e350ef6e3c07c3fa57001f43cb/pkg/skaffold/watch/watch.go#L107-L109

We should mimic the resolution that the docker cli does here. We support a very basic version here, but it should be its own function to infer workspace and dockerfile paths.

Dockerfile="" ====> Dockerfile="Dockerfile"
Workspace="" ====> Workspace="."

Dockerfile="" ====> Dockerfile="Dockerfile"
Workspace="dir/Dockerfile" ====> Workspace="dir"

[Meta] How do we want to use GitHub Projects?

A few possible ideas:

1. Have a new "project" for every release

• Might make more sense once we've gotten some users

2. Have a new "project" for alpha, beta, GA

• At the early stages (pre-release), tracking alpha and beta features might be more valuable than releases

3. Don't use it at all

• GitHub projects just recently added support for automatically moving "cards" from different stages based on status. In short, there are a lot of features missing and its historically been hard to use.

4. One large meta project that has subtabs broken down by releases or milestones

I've started a basic version of 2. I don't have strong opinions here and would love to hear your thoughts or what you've seen work well @viglesiasce @dlorenc

[Builder] Local builder push to remote repository

And authentication to private repositories

envsubst on certain skaffold fields

Do we want to expand bash substitutions in some skaffold fields? It is a bit of feature creep, but might be useful for complete portability of skaffold.yaml

We could ship examples for other repos by including a workspace: $GOPATH/src/path/to/project, so that we don't need to keep all of the example code here, only the example configuration.

It also makes paths less fragile, since its not so dependent on where the user actually runs skaffold run.

Here's a library we could use (note: haven't used it before, this is just the result of a quick google search)
https://github.com/drone/envsubst

Add GCB Trigger docs to getting started

Conditionally rebuild artifacts from watch

Currently, all artifacts are rebuilt after one source file changes, and changes during the build and deploy pipeline are ignored.

Flag to start `skaffold dev` with a build or default behavior

I don't think theres much harm into trying an initial build, since we should just warn if its fails anyways.

[Deploy] Add Deploy API

Release alpha binary

I'd like to manually release an alpha binary pending

• #90
• #81
• #85
• #29
• #30

ref #79

Release automation

Track Deployed Artifacts

Opening an issue to get some discussion started on how skaffold can keep track of what it's deploying through the various deployers we support (helm, kubectl apply, ksonnet, etc.).

Tracking these artifacts can help with things like #94 and deletion cases.

For kubectl, we know the manifest paths so we could parse those YAMLs and apply labels, or build a label selector?

For helm, we know the release names so we can query them with helm list or something similar.