Build and deploy Go applications on Kubernetes

Related tags

go kubernetes deploy container
Overview

ko: Easy Go Containers

Travis Build Status GitHub Actions Build Status GoDoc Go Report Card

ko is a simple, fast container image builder for Go applications.

It's ideal for use cases where your image contains a single Go application without any/many dependencies on the OS base image (e.g., no cgo, no OS package dependencies).

ko builds images by effectively executing go build on your local machine, and as such doesn't require docker to be installed. This can make it a good fit for lightweight CI/CD use cases.

ko also includes support for simple YAML templating which makes it a powerful tool for Kubernetes applications (See below).

Setup

Install

Install from Releases

VERSION=TODO # choose the latest version
OS=Linux     # or Darwin
ARCH=x86_64  # or arm64, i386, s390x
curl -L https://github.com/google/ko/releases/download/${VERSION}/ko_${VERSION}_${OS}_${ARCH}.tar.gz | tar xzf - ko
chmod +x ./ko

Install using Homebrew

brew install ko

Build and Install from Source

With Go 1.16+, build and install the latest released version:

go install github.com/google/ko

Authenticate

ko depends on the authentication configured in your Docker config (typically ~/.docker/config.json). If you can push an image with docker push, you are already authenticated for ko.

Since ko doesn't require docker, ko login also provides a surface for logging in to a container image registry with a username and password, similar to docker login.

Choose Destination

ko depends on an environment variable, KO_DOCKER_REPO, to identify where it should push images that it builds. Typically this will be a remote registry, e.g.:

  • KO_DOCKER_REPO=gcr.io/my-project, or
  • KO_DOCKER_REPO=my-dockerhub-user

Build an Image

ko publish ./cmd/app builds and pushes a container image, and prints the resulting image digest to stdout.

ko publish ./cmd/app
...
gcr.io/my-project/[email protected]:6e398316742b7aa4a93161dce4a23bc5c545700b862b43347b941000b112ec3e

Because the output of ko publish is an image reference, you can easily pass it to other tools that expect to take an image reference:

To run the container:

docker run -p 8080:8080 $(ko publish ./cmd/app)

Or, for example, to deploy it to other services like Cloud Run:

gcloud run deploy --image=$(ko publish ./cmd/app)

Configuration

Aside from KO_DOCKER_REPO, you can configure ko's behavior using a .ko.yaml file. The location of this file can be overridden with KO_CONFIG_PATH.

Overriding Base Images

By default, ko bases images on gcr.io/distroless/static:nonroot. This is a small image that provides the bare necessities to run your Go binary.

You can override this base image in two ways:

  1. To override the base image for all images ko builds, add this line to your .ko.yaml file:
defaultBaseImage: registry.example.com/base/image
  1. To override the base image for certain importpaths:
baseImageOverrides:
  github.com/my-user/my-repo/cmd/app: registry.example.com/base/for/app
  github.com/my-user/my-repo/cmd/foo: registry.example.com/base/for/foo

Naming Images

ko provides a few different strategies for naming the image it pushes, to workaround certain registry limitations and user preferences:

Given KO_DOCKER_REPO=registry.example.com/repo, by default, ko publish ./cmd/app will produce an image named like registry.example.com/repo/app-<md5>, which includes the MD5 hash of the full import path, to avoid collisions.

  • --preserve-import-path (-P) will include the entire importpath: registry.example.com/repo/github.com/my-user/my-repo/cmd/app
  • --base (-B) will omit the MD5 portion: registry.example.com/repo/app
  • --bare will only include the KO_DOCKER_REPO: registry.example.com/repo

Local Publishing Options

ko is normally used to publish images to container image registries, identified by KO_DOCKER_REPO.

ko can also publish images to a local Docker daemon, if available, by setting KO_DOCKER_REPO=ko.local, or by passing the --local (-L) flag.

ko can also publish images to a local KinD cluster, if available, by setting KO_DOCKER_REPO=kind.local.

Multi-Platform Images

Because Go supports cross-compilation to other CPU architectures and operating systems, ko excels at producing multi-platform images.

To build and push an image for all platforms supported by the configured base image, simply add --platform=all. This will instruct ko to look up all the supported platforms in the base image, execute GOOS=<os> GOARCH=<arch> GOARM=<variant> go build for each platform, and produce a manifest list containing an image for each platform.

You can also select specific platforms, for example, --platform=linux/amd64,linux/arm64

Static Assets

ko can also bundle static assets into the images it produces.

By convention, any contents of a directory named <importpath>/kodata/ will be bundled into the image, and the path where it's available in the image will be identified by the environment variable KO_DATA_PATH.

As an example, you can bundle and serve static contents in your image:

cmd/
  app/
    main.go
    kodata/
      favicon.ico
      index.html

Then, in your main.go:

func main() {
    http.Handle("/", http.FileServer(http.Dir(os.Getenv("KO_DATA_PATH"))))
    log.Fatal(http.ListenAndServe(":8080", nil))
}

You can simulate ko's behavior outside of the container image by setting the KO_DATA_PATH environment variable yourself:

KO_DATA_PATH=cmd/app/kodata/ go run ./cmd/app

Tip: Symlinks in kodata are followed and included as well. For example, you can include Git commit information in your image with:

ln -s -r .git/HEAD ./cmd/app/kodata/

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:

kubectl apply -f deployment.yaml

With ko, you can instead reference your Go binary by its importpath, prefixed with ko://:

    ...
    spec:
      containers:
      - name: my-app
        image: ko://github.com/my-user/my-repo/cmd/app

ko resolve

With this small change, running ko resolve -f deployment.yaml will instruct ko to:

  1. scan the YAML file(s) for values with the ko:// prefix,
  2. for each unique ko://-prefixed string, execute ko publish <importpath> to build and push an image,
  3. replace ko://-prefixed string(s) in the input YAML with the fully-specified image reference of the built image(s), for example:
spec:
  containers:
    - name: my-app
      image: registry.example.com/github.com/my-user/my-repo/cmd/[email protected]:deadb33f...
  1. Print the resulting resolved YAML to stdout.

The result can be redirected to a file, to distribute to others:

ko resolve -f config/ > release.yaml

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:

ko resolve -f config/ | kubectl apply -f -

Since this is a relatively common use case, the same functionality is available using ko apply:

ko apply -f config/

NB: This requires that kubectl is available.

ko delete

To teardown resources applied using ko apply, you can run ko delete:

ko delete -f config/

This is purely a convenient alias for kubectl delete, and doesn't perform any builds, or delete any previously built images.

Frequently Asked Questions

How can I set ldflags?

Using -ldflags is a common way to embed version info in go binaries (In fact, we do this for ko!). Unforunately, because ko wraps go build, it's not possible to use this flag directly; however, you can use the GOFLAGS environment variable instead:

GOFLAGS="-ldflags=-X=main.version=1.2.3" ko publish .

Why are my images all created in 1970?

In order to support reproducible builds, ko doesn't embed timestamps in the images it produces by default; however, ko does respect the SOURCE_DATE_EPOCH environment variable.

For example, you can set this to the current timestamp by executing:

export SOURCE_DATE_EPOCH=$(date +%s)

or to the latest git commit's timestamp with:

export SOURCE_DATE_EPOCH=$(git log -1 --format='%ct')

Can I optimize images for eStargz support?

Yes! Set the environment variable GGCR_EXPERIMENT_ESTARGZ=1 to produce eStargz-optimized images.

Does ko support autocompletion?

Yes! ko completion generates a Bash completion script, which you can add to your bash_completion directory:

ko completion > /usr/local/etc/bash_completion.d/ko

Or, you can source it directly:

source <(ko completion)

Does ko work with Kustomize?

Yes! ko resolve -f - will read and process input from stdin, so you can have ko easily process the output of the kustomize command.

kustomize build config | ko resolve -f -

Acknowledgements

This work is based heavily on learnings from having built the Docker and Kubernetes support for Bazel. That work was presented here.

Issues
  • Multi-platform ko

    Multi-platform ko

    This is a sketch of what I had in mind for https://github.com/google/ko/issues/6

    For this PR, I've set the default base image for this repo to ubuntu so that you can just fetch this branch and run ko publish ./cmd/ko to test out the change. It should build a different binary for every platform and publish a manifest list instead of just a manifest.

    $ ko publish ./cmd/ko
    2019/06/17 14:04:04 Using base index.docker.io/library/ubuntu:latest for github.com/google/ko/cmd/ko
    2019/06/17 14:04:04 No matching credentials were found, falling back on anonymous
    2019/06/17 14:04:06 Building github.com/google/ko/cmd/ko
    2019/06/17 14:04:12 Building github.com/google/ko/cmd/ko
    2019/06/17 14:04:15 Building github.com/google/ko/cmd/ko
    2019/06/17 14:04:19 Building github.com/google/ko/cmd/ko
    2019/06/17 14:04:23 Building github.com/google/ko/cmd/ko
    2019/06/17 14:04:27 Building github.com/google/ko/cmd/ko
    2019/06/17 14:04:30 Publishing gcr.io/jonjohnson-test/ko/ko-099ba5bcefdead87f92606265fb99ac0:latest
    2019/06/17 14:04:32 existing manifest: sha256:e66f9706d017b28a5f63fd2b1a9395a43852bb8691c2a3d789bf6187ed2a83ef
    2019/06/17 14:04:32 existing manifest: sha256:6ae8959c22069d43bbaa848496237a653f4644244f638d11aa05dee555e2d7d9
    2019/06/17 14:04:32 existing manifest: sha256:d835632ac512ee32b2489d44c15ecb03a139785b2e3d475a07670288fc95242e
    2019/06/17 14:04:32 existing manifest: sha256:ce8f3571502ac3b5c86f1d527c712abd4cad953c97f24ba9b28a6505e502f1ad
    2019/06/17 14:04:32 existing manifest: sha256:5c60f74c26ec1726f06e6c35ca1a3aee0c567d37001143ec70e9cc6f5b1a763b
    2019/06/17 14:04:33 existing manifest: sha256:c1940d8d12f448cf17212cf76e012d8b8480e0b033fac5ff6068402a8f0f590f
    2019/06/17 14:04:34 gcr.io/jonjohnson-test/ko/ko-099ba5bcefdead87f92606265fb99ac0:latest: digest: sha256:96ac9a314510e380cf3dd3aae3abc51dad577eecf53ebf6691f0c4d665d90621 size: 1411
    2019/06/17 14:04:34 Published gcr.io/jonjohnson-test/ko/[email protected]:96ac9a314510e380cf3dd3aae3abc51dad577eecf53ebf6691f0c4d665d90621
    gcr.io/jonjohnson-test/ko/[email protected]:96ac9a314510e380cf3dd3aae3abc51dad577eecf53ebf6691f0c4d665d90621
    
    $ crane manifest gcr.io/jonjohnson-test/ko/[email protected]:96ac9a314510e380cf3dd3aae3abc51dad577eecf53ebf6691f0c4d665d90621 | jq .
    {
      "schemaVersion": 2,
      "mediaType": "application/vnd.docker.distribution.manifest.list.v2+json",
      "manifests": [
        {
          "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
          "size": 1073,
          "digest": "sha256:e66f9706d017b28a5f63fd2b1a9395a43852bb8691c2a3d789bf6187ed2a83ef",
          "platform": {
            "architecture": "amd64",
            "os": "linux"
          }
        },
        {
          "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
          "size": 1073,
          "digest": "sha256:6ae8959c22069d43bbaa848496237a653f4644244f638d11aa05dee555e2d7d9",
          "platform": {
            "architecture": "arm",
            "os": "linux",
            "variant": "v7"
          }
        },
        {
          "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
          "size": 1073,
          "digest": "sha256:d835632ac512ee32b2489d44c15ecb03a139785b2e3d475a07670288fc95242e",
          "platform": {
            "architecture": "arm64",
            "os": "linux",
            "variant": "v8"
          }
        },
        {
          "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
          "size": 1073,
          "digest": "sha256:ce8f3571502ac3b5c86f1d527c712abd4cad953c97f24ba9b28a6505e502f1ad",
          "platform": {
            "architecture": "386",
            "os": "linux"
          }
        },
        {
          "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
          "size": 1073,
          "digest": "sha256:5c60f74c26ec1726f06e6c35ca1a3aee0c567d37001143ec70e9cc6f5b1a763b",
          "platform": {
            "architecture": "ppc64le",
            "os": "linux"
          }
        },
        {
          "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
          "size": 1073,
          "digest": "sha256:c1940d8d12f448cf17212cf76e012d8b8480e0b033fac5ff6068402a8f0f590f",
          "platform": {
            "architecture": "s390x",
            "os": "linux"
          }
        }
      ]
    }
    

    I haven't actually tested pulling/running this on different platforms (I don't have any), so YMMV, but publishing works 👍

    I don't actually like this very much because I've made every package deal with a new abstraction (I've called it Steve so that we don't ever merge this) that can represent either base image or a base manifest list. A better approach would probably be to make everything deal with a manifest list to simplify things.

    When pulling base image:

    • if it's a manifest list, pass that along as the base
    • if it's an image, wrap it as a singleton manifest list

    When publishing the artifacts:

    • if it's a singleton manifest list, unwrap it and publish just the image
    • otherwise, publish it as a manifest list

    This isn't perfect (what if the user actually does want to publish a singleton manifest list?), so maybe it's not the best idea. Open to suggestions :)

    opened by jonjohnsonjr 36
  • Add `pkg/v1/kind` for writing images to KinD

    Add `pkg/v1/kind` for writing images to KinD

    I think we want something like: https://github.com/google/go-containerregistry/tree/master/pkg/v1/daemon

    ... but to write it directly to KinD.

    cc @BenTheElder for pointers on the best API.

    I'd love to get some mechanism like this so that we can support something like: KO_DOCKER_REPO=kind.local

    opened by mattmoor 23
  • KO not authenticating against the target docker registry/repo

    KO not authenticating against the target docker registry/repo

    After successfully using KO to build the NATS channel controller and dispatcher, KO failed to deploy the image to the target registry, in this case, docker.io

    below are the execution steps to replicate this issue

    1. set KO_DOCKER_REPO = pkaisharis [account name]
    2. run ko apply -f natss/config
    3. execution results
    2019/09/24 15:00:54 Publishing index.docker.io/pkaisharis/channel_controller-c1ecaddae73c4ef9fc778b143614b0c2:latest
    2019/09/24 15:00:54 Publishing index.docker.io/pkaisharis/channel_dispatcher-c87d09956961b64d037b8b7969b36e36:latest
    2019/09/24 15:00:56 error processing import paths in "natss/config/500-dispatcher.yaml": unsupported status code 401
    

    Below is the docker.io auth config from .docker/config.json

    {
    	"auths": {
    		"https://index.docker.io/v1/": {}
    	},
    	"HttpHeaders": {
    		"User-Agent": "Docker-Client/19.03.2 (linux)"
    	},
    	"credsStore": "secretservice"
    }
    
    opened by pksurferdad 17
  • v0.8.0 tarball sha256 change?

    v0.8.0 tarball sha256 change?

    I'm attempting to update Homebrew's version of Go (Homebrew/homebrew-core#71289).

    While testing the new version, CI produced the following error:

    ==> FAILED
    ==> Downloading https://github.com/google/ko/archive/v0.8.0.tar.gz
    ==> Downloading from https://codeload.github.com/google/ko/tar.gz/v0.8.0
    Error: SHA256 mismatch
    Expected: 8ecb73697915b19ae5f3a647d877656ccaaa9f46f6c5f22e81cb8763cc0a8a18
      Actual: a1b90267574102d3fb43cab7587bbe54f221e5b79ca731781a89c7d0c1f5b2ef
        File: /Users/brew/Library/Caches/Homebrew/downloads/c4c486f4e0ec600d534026b410741c7c8c34fd303b2ff15714940e8e7eeeca56--ko-0.8.0.tar.gz
    

    I can update the sha256 associated with ko, but CI will come back to me with the following error:

    ko:

    • stable sha256 changed without the url/version also changing; please create an issue upstream to rule out malicious circumstances and to find out why the file changed.

    Could someone help understand why the tarball sha might have changed?

    opened by roopakv 17
  • Allow comma-separated list of platforms

    Allow comma-separated list of platforms

    Fixes https://github.com/google/ko/issues/253

    Fixes https://github.com/google/ko/issues/274

    $ ko publish -B --platform=linux/amd64,linux/arm64 ./cmd/ko/
    2020/12/07 13:57:20 Using base gcr.io/distroless/static:nonroot for github.com/google/ko/cmd/ko
    2020/12/07 13:57:21 Building github.com/google/ko/cmd/ko for linux/amd64
    2020/12/07 13:57:25 Building github.com/google/ko/cmd/ko for linux/arm64
    2020/12/07 13:57:29 Publishing gcr.io/jonjohnson-test/ko/ko:latest
    2020/12/07 13:57:30 existing blob: sha256:72164b581b02b1eb297b403bcc8fc1bfa245cb52e103a3a525a0835a58ff58e2
    2020/12/07 13:57:30 existing blob: sha256:e59bd8947ac7af2c8f4403b183326986ab554bbc262739cf5d9d596c7c7a3aca
    2020/12/07 13:57:31 pushed blob: sha256:314bd22f324d73c81d23dd94a14e3a4df6a591381e39b9164163208115c23ae4
    2020/12/07 13:57:33 pushed blob: sha256:dd714425e64113dddc2cf7a21a1b7f47c20ae29dc2072284b64fe1e7b82a5307
    2020/12/07 13:57:33 gcr.io/jonjohnson-test/ko/[email protected]:cb6a0c6cb99e6c7b1d7dfd598484d0d25b74e15a69837f3d87c08c58ee7f88e2: digest: sha256:cb6a0c6cb99e6c7b1d7dfd598484d0d25b74e15a69837f3d87c08c58ee7f88e2 size: 751
    2020/12/07 13:57:34 existing blob: sha256:72164b581b02b1eb297b403bcc8fc1bfa245cb52e103a3a525a0835a58ff58e2
    2020/12/07 13:57:34 existing blob: sha256:d34b09c140e4b67f2c6214e24f26a68bc6b17c28d42f0dda89db38ad03488416
    2020/12/07 13:57:35 pushed blob: sha256:99af2cd1b289d3a47aba52934e2ac8c4037e92563e8a4d119b5d0e040f5b9ed3
    2020/12/07 13:57:37 pushed blob: sha256:052d3194d06e9194d60e7dcdce4c7d8e91df952f34dfddd461ce181732342db2
    2020/12/07 13:57:37 gcr.io/jonjohnson-test/ko/[email protected]:ca19f1aa2adc983e55c1eb7d6af1ed8574991ff6762eccec8ef7b5e5d965d1ce: digest: sha256:ca19f1aa2adc983e55c1eb7d6af1ed8574991ff6762eccec8ef7b5e5d965d1ce size: 751
    2020/12/07 13:57:38 gcr.io/jonjohnson-test/ko/ko:latest: digest: sha256:03ed41dd8676e9988fb4958366cf8d38fbb39e576d5b09bb1cc108c937e6d7ff size: 529
    2020/12/07 13:57:38 Published gcr.io/jonjohnson-test/ko/[email protected]:03ed41dd8676e9988fb4958366cf8d38fbb39e576d5b09bb1cc108c937e6d7ff
    gcr.io/jonjohnson-test/ko/[email protected]:03ed41dd8676e9988fb4958366cf8d38fbb39e576d5b09bb1cc108c937e6d7ff
    
    cla: yes 
    opened by jonjohnsonjr 16
  • ko stops building containers after Golang updates

    ko stops building containers after Golang updates

    After each minor Golang version bump (e.g. 1.13.2 -> 1.13.3), ko apply no longer builds container images but happily applies the yaml untransformed, which leads with image pull errors on the cluster. After reinstalling ko, it works again as expected.

    Ideally ko would continue to work after a Golang update, but if not, it should fail loudly and demand to be reinstalled.

    lifecycle/frozen 
    opened by scothis 15
  • add support for build using `go test`

    add support for build using `go test`

    as described in #96: currently only real go builds are supported. With this PR importpaths that only contain tests will also be built using go test -c

    lifecycle/stale 
    opened by k15r 13
  • Support setting Go build flags via configuration file

    Support setting Go build flags via configuration file

    Although, build flags like -ldflags can be set using an environment variable, there is a problem if you want to set multiple linker flags like that. Since the Go docs on the environment variables now state that spaces are not allowed in this context and specifying the flags multiple times does not work due to the way overrides are handled, I do not currently see a good way to specify multiple ldflags. The use-case I have in mind would be to set ldflags for -s, -w, and -X, which is not an uncommon combination. In GoReleaser this is solved by section in the configuration to specify the respective settings, which I think is quite nice. Any chance that the .ko.yaml could be used for this kind of configuration, too? Thanks in advance for your feedback.

    help wanted 
    opened by HeavyWombat 12
  • Fix release URL install setup doc

    Fix release URL install setup doc

    This PR fixes the release URL construction in the root README.md.

    cla: no 
    opened by maxgio92 12
  • Build should take a context.Context

    Build should take a context.Context

    Builds can take a while, so it would be nice to be able to cancel them.

    good first issue 
    opened by jonjohnsonjr 11
  • Make --insecure-registry work with TLS registries whose certs we can't verify.

    Make --insecure-registry work with TLS registries whose certs we can't verify.

    Fixes #396

    Note that this is technically breaking if people are using --insecure-registry and replacing the RoundTripper with something that's not an http.Transport. I decided to blow up loudly, rather than let it pass, but I could be convinced to go the other way.

    Verified on harbor 2.2.3 with a self-signed cert with a SAN of 192.168.10.12.

    cla: yes 
    opened by evankanderson 0
  • Can't figure out flags for insecure registry

    Can't figure out flags for insecure registry

    I'm using ko version v0.8.3, and I'm probably an idiot, but I can't seem to get either --insecure-registry flag from ko resolve or the --insecure-registry and --insecure-skip-tls-verify flags working against a private harbor registry.

    The harbor registry has a SNI cert for 192.168.10.12, and I've set KO_DOCKER_REPO=192.168.10.12, and I've set up authorization via docker login (and added the registry to insecure-registries in the docker JSON config).

    It looks like the following should be the correct usage:

    $ ko apply --insecure-registry -f config/contour
    ...
    Publishing 192.168.10.12/dev/contour-ff924afcef2cd0177014d053ee4b167d:latest
    ....
    error during command execution:error processing import paths in "config/contour/external.yaml": error resolving image references: Get "https://192.168.10.12/v2/": x509: certificate signed by unknown authority; Get "https://192.168.10.12:443/v2/": x509: certificate signed by unknown authority
    

    This just produces an error:

    $ ko --insecure-registry apply -f config/contour
    Error: unknown flag: --insecure-registry
    

    The --insecure-skip-tls-verify flag might be a kubectl flag, though it's not documented what it connects to:

    $ ko apply -f config/contour --insecure-skip-tls-verify
    error: Unexpected args: [true]
    ...
    Error: error executing 'kubectl apply': exit status 1
    ...
          --insecure-skip-tls-verify       If true, the server's certificate will not be checked for validity. This will make your HTTPS connections insecure
    

    (This command doesn't seem to end up trying to publish an image before it fails)

    opened by evankanderson 2
  • Bump k8s.io/cli-runtime from 0.20.6 to 0.21.3

    Bump k8s.io/cli-runtime from 0.20.6 to 0.21.3

    Bumps k8s.io/cli-runtime from 0.20.6 to 0.21.3.

    Commits

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    cla: yes dependencies 
    opened by dependabot[bot] 0
  • Bump github.com/spf13/viper from 1.7.0 to 1.8.1

    Bump github.com/spf13/viper from 1.7.0 to 1.8.1

    Bumps github.com/spf13/viper from 1.7.0 to 1.8.1.

    Release notes

    Sourced from github.com/spf13/viper's releases.

    v1.8.1

    This patch releases fixes two minor issues:

    • Replace %s with %w when wrapping errors
    • Fix pflag.StringArray processing

    v1.8.0

    This is a maintenance release primarily containing fixes and improvements. The most prominent change is the etcd update to 3.5.0. Thanks to proper Go modules support, the dependency graph became much smaller.

    Changes

    Added

    • Allow BindEnv to register multiple environment variables
    • Support for accessing slices
    • Experimental WASM support: Viper compiles on WASM
    • INI load options

    Changed

    • Ensure BindPFlag detects a nil flag parameter

    Fixed

    • Merging a key into a nil target
    • Panics during saving INI files

    Security

    • Updated etcd to 3.5 which should make a lot of false positive vulnerability reports disappear

    In addition to the above changes, this release comes with tons of minor improvements, documentation changes an dependency updates. Find more details in the 1.8.0 milestone.

    Many thanks to everyone who contributed to this release!

    v1.7.1

    This release contains a bugfix for environment variable expansion. See #495 and #940 for details.

    Commits
    • bd03865 Add a proper processing for pflag.StringArray
    • 3fcad43 update %s to %w
    • faa8ba0 chore: update gotestsum
    • 65ee986 chore(lint): fix gofumpt
    • 04ef5fa chore: update golangci-lint
    • acd965b Add ini load options argument
    • 5f4d053 chore(deps): update dependencies
    • dd57ae6 chore(deps): update etcd
    • cdb5e59 Fix merging a key into a nil target
    • 36be6bf feat: make sure Viper compiles on WASM
    • Additional commits viewable in compare view

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    cla: yes dependencies 
    opened by dependabot[bot] 0
  • update deps

    update deps

    Closes https://github.com/google/ko/pull/387 https://github.com/google/ko/pull/389 https://github.com/google/ko/pull/390 https://github.com/google/ko/pull/388 without rebase hoop-jumping

    cla: yes 
    opened by imjasonh 0
  • Annotate OCI image indexes with base image information

    Annotate OCI image indexes with base image information

    Unfortunately Docker manifest lists (e.g., distroless) don't support annotations. Attempting to push an annotated manifest list resulted in:

    2021/07/22 09:15:49 error during command execution:failed to publish images: error publishing ko://github.com/google/ko/test: PUT https://gcr.io/v2/imjasonh/test/manifests/latest: MANIFEST_INVALID: Failed to parse manifest for request "/v2/imjasonh/test/manifests/latest": Failed to deserialize application/vnd.docker.distribution.manifest.list.v2+json.
    
    cla: yes 
    opened by imjasonh 0
  • Re-enable travis

    Re-enable travis

    Disabled for now because arm tests seem broken.

    opened by jonjohnsonjr 0
  • Update

    Update "go install" instructions

    I got the following error when following the original instructions:

    go install: version is required when current directory is not in a module
            Try 'go install github.com/google/[email protected]' to install the latest version
    
    cla: yes 
    opened by xuhdev 2
  • By default build with -buildmode=pie when available

    By default build with -buildmode=pie when available

    I believe this would enable https://en.wikipedia.org/wiki/Address_space_layout_randomization and help our security posture

    opened by dprotaso 0
  • Build working Windows container images

    Build working Windows container images

    Fixes #361

    The main discoveries while implementing this have been:

    • Windows containers expect contents to be in a Files/ root directory in the tar archive
      • ...and for a Hives/ root directory to be present, though it can be empty
    • Executable entries in the tar archive must have a PAXRecords value to be executable at runtime

    Even after this work lands, users building images will have to make sure they use a base image that provides the exact Windows OS version that they intend to run the image on. Users wishing to produce a multi-OS image with ko will probably also have to stitch together a suitable base image from nanoserver etc., and whatever Linux base image they want to use (distroless, alpine, etc.), since AFAIK suitable multi-OS base images aren't exactly prevalent in the wild.

    cla: yes 
    opened by imjasonh 1
Releases(v0.8.3)
Owner
Google
Google ❤️ Open Source
Google
Automatically deploy from GitHub to Replit, lightning fast ⚡️

repl.deploy Automatically deploy from GitHub to Replit, lightning fast ⚡️ repl.deploy is split into A GitHub app, which listens for code changes and s

Khushraj Rathod 42 Jul 18, 2021
A Kubernetes Mutating Webhook to automatically re-point pod images to mirrors

kubernetes-mimic Kubernetes Mimic is a Mutating Webhook that will watch for pod creation and update events in a Kubernetes cluster and automatically a

null 5 Jun 21, 2021
Managing your Kubernetes clusters (including public, private, edge, etc) as easily as visiting the Internet

Clusternet Managing Your Clusters (including public, private, hybrid, edge, etc) as easily as Visiting the Internet. Clusternet (Cluster Internet) is

Clusternet 69 Jul 23, 2021
Enterprise-grade container platform tailored for multicloud and multi-cluster management

KubeSphere Container Platform What is KubeSphere English | 中文 KubeSphere is a distributed operating system providing cloud native stack with Kubernete

KubeSphere 6.2k Jul 27, 2021
Production-Grade Container Scheduling and Management

Kubernetes (K8s) Kubernetes, also known as K8s, is an open source system for managing containerized applications across multiple hosts. It provides ba

Kubernetes 79.2k Jul 20, 2021
Lightweight Kubernetes

K3s - Lightweight Kubernetes Lightweight Kubernetes. Production ready, easy to install, half the memory, all in a binary less than 100 MB. Great for:

null 17.3k Jul 23, 2021
Not another markup language. Framework for replacing Kubernetes YAML with Go.

Not another markup language. Replace Kubernetes YAML with raw Go! Say so long ?? to YAML and start using the Go ?? programming language to represent a

Kris Nóva 710 Jul 17, 2021
Simplified network and services for edge applications

English | 简体中文 EdgeMesh Introduction EdgeMesh is a part of KubeEdge, and provides a simple network solution for the inter-communications between servi

KubeEdge 30 Jul 11, 2021
kubequery is a Osquery extension that provides SQL based analytics for Kubernetes clusters

kubequery powered by Osquery kubequery is a Osquery extension that provides SQL based analytics for Kubernetes clusters kubequery will be packaged as

Uptycs Inc 47 Jul 13, 2021
Large-scale Kubernetes cluster diagnostic tool.

English | 简体中文 KubeProber What is KubeProber? KubeProber is a diagnostic tool designed for large-scale Kubernetes clusters. It is used to perform diag

Erda 18 Jul 20, 2021
Kubernetes Virtualization API and runtime in order to define and manage virtual machines.

Kubernetes Virtualization API and runtime in order to define and manage virtual machines.

KubeVirt 2.7k Jul 22, 2021
Go library to create resilient feedback loop/control controllers.

Gontroller A Go library to create feedback loop/control controllers, or in other words... a Go library to create controllers without Kubernetes resour

Spotahome 122 Jun 29, 2021
🐶 Kubernetes CLI To Manage Your Clusters In Style!

K9s - Kubernetes CLI To Manage Your Clusters In Style! K9s provides a terminal UI to interact with your Kubernetes clusters. The aim of this project i

Fernand Galiana 12.8k Jul 21, 2021
Client extension for interacting with Kubernetes clusters from your k6 tests.

⚠️ This is a proof of concept As this is a proof of concept, it won't be supported by the k6 team. It may also break in the future as xk6 evolves. USE

k6 4 Jul 15, 2021