@daveey Great PR!

I had also needed to depend on a 3rd party image in my PR #465

What I have done there was to make image/command passed to docker run fully configurable via cluster.yaml and noted that it may change in the future. See https://github.com/coreos/coreos-kubernetes/pull/465/files#diff-071e0ee4ae8c6adf4865f25d851f30c9R74 for code regarding it.

With that, I believe that there will be small chances we can get our PRs merged as is, because we won't break things in fragile/backward-incompatible ways.

If that is not enough, I guess we can contribute a Dockerfile for kubectl and ask CoreOS guys if they could docker build/push it in a Docker repo something like quay.io/coreos/kubectl.

@colhom @aaronlevy Excuse me for being obtrusive but would you mind looking into this? We like to contribute but the same issue seems to be blocking us.

Couple things to cover here:

• As far as the underlying issue, can you give more detail on how curl is silently failing in a way that kubectl would surface more info? If curl fails, I would expect the apiserver response to be in the journal output for the unit - if not we can likely resolve this.
• As far as kubectl in the hyperkube container, I would prefer that the flag issue be fixed upstream, rather than trying to work around the bug by including a separate binary or needing to package a separate image. We try to keep our images as close to upstream as possible (and others in the community could also benefit from this fix).

Once the flag bug is resolved, I wouldn't necessarily be opposed to running kubectl via a container (although I'd likely prefer that it was run via rkt). But it would be slightly slower on the installation process (vs curl).

@aaronlevy thanks for the review, I should have posted a link to the issue.

#447

Take a look at the discussion there which addresses the "apply" issue, as well as why curl is problematic.

I agree with the preference for the original hyperkube image, however the flag bug has been open for a while and not addressed so I don't know when we can expect it.

Commented on the linked issue.

Would you be interested in taking a stab at fixing the upstream issue? On a quick scan it looks like it would mean improving flag parsing here: https://github.com/kubernetes/kubernetes/blob/master/cmd/hyperkube/hyperkube.go#L117

@aaronlevy i won't have time to work on the upstream issue for a while

@daveey I'll be looking into the upstream hyperkube issue soon to see if we can get this resolved.

@daveey update on things. kubernetes/kubernetes#25512 is merged, fixing the hyperkube flag issue.

we're going to wait until v1.3 (with that PR in it) is released before going forward with this PR.

@daveey would this be something you're still interested in tackling? kubectl is now part of hyperkube, so we could now do something like rkt run quay.io/coreos/hyperkube --exec /hyperkube -- kubectl create -f foo.yaml

I'm going to close this due to inactivity - but please re-open if this is something you would like to see merged.