feature: docker-env, registry, and default behavior

[philips]

Is this a BUG REPORT or FEATURE REQUEST? (choose one): FEATURE REQUEST

Many developers use docker build and having it with minikube makes for a nice little dev system. However, docker build -t foo ., kubectl run foo --image=foo doesn't work. Why?

$ kubectl get pods
NAME                  READY     STATUS             RESTARTS   AGE
foo-798133755-ebi70   0/1       ImagePullBackOff   0          23s

Because the default ImagePullPolicy is not "IfNotPresent".

So, I think we should provide a workaround. I propose that we create a tiny Docker Engine proxy that looks for build and tag verbs and when they are made pushes it into the registry addon.

Advantages:

• Default behavior works
• Works for rkt runtime support as well

Thoughts?

[jimmidyson]

Is the default pull policy configurable?

As an easy workaround for now, you can tag the built image with something other than latest, e.g. foo:dev, & pull policy will be IfNotPresent.

[s-urbaniak]

tldr: Indeed that is k8s default behavior, and currently as I see it in k8s not configurable.

You built an image without a version, so docker build will add a latest tag automatically (and if it doesn't, k8s will add it, see [1]):

$ docker build -t foo .
$ docker images
REPOSITORY                TAG                 IMAGE ID            CREATED             SIZE
foo                       latest              c8921248c847        27 seconds ago      7.244 MB

If the latest tag is attached to the image, k8s will always set ImagePullPolicy = PullAlways, and this is not configurable, see [2].

Workarounds:

1. As suggested by @jimmidyson add a :dev version while building the image
2. Write a k8s yaml:

apiVersion: v1
kind: Pod
metadata:
  name: foo
spec:
  containers:
    - name: foo
      image: foo
      imagePullPolicy: IfNotPresent

[1] https://github.com/kubernetes/kubernetes/blob/dea4b0226d859a1b86a81163c86ec61cffc1b952/pkg/util/parsers/parsers.go#L51
[2] https://github.com/kubernetes/kubernetes/blob/dea4b0226d859a1b86a81163c86ec61cffc1b952/pkg/api/v1/defaults.go#L104

[dlorenc]

Users would still have to name their image something that could be pushed to the registry addon, right? localhost:5000/my image:foo would work, but foo wouldn't.

I wonder if could do this with a custom admission controller...

[jimmidyson]

Users would still have to name their image something that could be pushed to the registry addon, right?

No you don't need the registry if you're building against the minikube docker engine.

[dlorenc]

Yeah sorry, that was in reply to the proxy idea @philips suggested.

[philips]

I think the goal of this is to make this developer workflow work in a "production way" instead of the sort of by accident way it does today. Kubernetes sort of assumes that there is a registry, rightfully, we just need to map the user experience to this.

Aside: I need to get a proposal up but I would like to start writing a docker build endpoint that lives on cluster and pushes to the registry add-on. This would enable rkt based cluster's to do docker build.

[fejta-bot]

Issues go stale after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle rotten
/remove-lifecycle stale

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close