This page contains information about various tools and technologies that are useful to anyone developing on Knative.
This section contains tools and technologies developed by members of the Knative community specifically for use with Knative.
knctl is an under-development CLI for working with Knative.
This section contains other tools and technologies that are useful when working with Knative.
go-containerregistry is a Go library used by
others, which enables support for pushing, pulling and managing images in a
container image registry, without requiring Docker to be installed.
It also provides packages to interact with images in a local Docker daemon, which does require that Docker be installed.
This library also provides a CLI tool called
which can be used to interact with and inspect images in a registry.
jib is a tool, packaged as a Maven plugin and a Gradle plugin, that
efficiently builds container images from Java source, without a Dockerfile,
without requiring access to the Docker daemon.
jib is invoked, it builds your Java source and pushes an image
with that built source atop a
distroless base image to
produce small images that support fast incremental image builds.
BuildTemplates that wraps
jib for use with Maven and Gradle, at
https://github.com/knative/build-templates/blob/master/jib/. It expects that
build.gradle describes to
jib where to push your image.
The build templates take no parameters.
kaniko is a tool that enables building a container image from source using the
Dockerfile format, without requiring access to a Docker daemon. Removing this
requirement means that
safe to run on a Kubernetes cluster.
By contrast, building an image using
docker build necessarily requires the
Docker daemon, which would give the build complete access to your entire
cluster. So that’s a very bad idea.
kaniko expects to run inside a container, so it’s a natural fit for the Build
CRD builder contract.
kaniko is available as a builder at
gcr.io/kaniko-project/executor:latest, and there’s a
wraps it at
exposes one required parameter,
IMAGE, which describes the name of the image
to push to.
More information here: https://github.com/knative/build-templates/tree/master/kaniko
kaniko is unrelated to
ko is a tool designed to make development of Go apps on Kubernetes easier, by
abstracting away the container image being used, and instead referring to Go
packages by their import paths
The typical usage is
ko apply -f config.yaml, which reads in the config YAML,
and looks for Go import paths representing runnable commands (i.e.,
package main). When it finds a matching import path,
ko builds the package
go build then pushes a container image containing that binary on top of
a base image (by default,
$KO_DOCKER_REPO/unique-string. After pushing those images,
instances of matched import paths with fully-qualified references to the images
ko apply was passed this config:
--- image: github.com/my/repo/cmd/foo
…it would produce YAML like:
--- image: gcr.io/my-docker-repo/foo-zyxwvut@sha256:abcdef # image by digest
(This assumes that you have set the environment variable
ko apply then passes this generated YAML config to
ko also supports:
ko publishto simply push images and not produce configs.
ko resolveto push images and output the generated configs, but not
ko deleteto simply passthrough to
kubectl deletefor convenience.
ko is used during development and release of Knative components, but is not
intended to be required for users of Knative – they should only need to
kubectl apply released configs generated by
skaffold is a CLI tool to aid in iterative development for Kubernetes.
Typically, you would write a
describing to Skaffold how to build and deploy your app, then run
skaffold dev, which will watch your local source tree for changes and
continuously builds and deploys based on your config when changes are detected.
Skaffold supports many pluggable implementations for building and deploying. Skaffold contributors are working on support for Knative Build as a build plugin, and could support Knative Serving as a deployment plugin.