Kubernetes Integration
You could stop at just building and pushing images.
But, because building images is so easy with ko
, and because building with
ko
only requires a string importpath to identify the image, we can integrate
this with YAML generation to make Kubernetes use cases much simpler.
YAML Changes
Traditionally, you might have a Kubernetes deployment, defined in a YAML file, that runs an image:
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-deployment
spec:
replicas: 3
...
template:
spec:
containers:
- name: my-app
image: registry.example.com/my-app:v1.2.3
...which you apply to your cluster with kubectl apply
:
With ko
, you can instead reference your Go binary by its importpath, prefixed
with ko://
:
ko resolve
With this small change, running ko resolve -f deployment.yaml
will instruct
ko
to:
- scan the YAML file(s) for values with the
ko://
prefix, - for each unique
ko://
-prefixed string, executeko build <importpath>
to build and push an image, - replace
ko://
-prefixed string(s) in the input YAML with the fully-specified image reference of the built image(s), as above. - Print the resulting resolved YAML to stdout.
The result can be redirected to a file, to distribute to others:
Taken together, ko resolve
aims to make packaging, pushing, and referencing
container images an invisible implementation detail of your Kubernetes
deployment, and let you focus on writing code in Go.
ko apply
To apply the resulting resolved YAML config, you can redirect the output of
ko resolve
to kubectl apply
:
Since this is a relatively common use case, the same functionality is available
using ko apply
:
Also, any flags passed after --
are passed to kubectl apply
directly, for example to specify context and kubeconfig:
NB: This requires that kubectl
is available.
ko delete
To teardown resources applied using ko apply
, you can run ko delete
:
This is purely a convenient alias for kubectl delete
, and doesn't perform any
builds, or delete any previously built images.