Note that this relates to #19 as it would (a) make it less painful to copy stuff in and out of a boot2docker VM during build and (b) would make the resultant container images smaller as they'd all share a base with the single binary.

SGTM.

Brendan

On Sat, Jun 14, 2014, 9:00 AM, Joe Beda notifications@github.com wrote:

Note that this relates to #4
#4 as it would
(a) make it less painful to copy stuff in and out of a boot2docker VM
during build and (b) would make the resultant container images smaller as
they'd all share a base with the single binary.

—
Reply to this email directly or view it on GitHub
#108 (comment)
.

The localkube thing I made is most of the way there already.
On Jun 14, 2014 9:25 AM, "brendandburns" notifications@github.com wrote:

SGTM.

Brendan

On Sat, Jun 14, 2014, 9:00 AM, Joe Beda notifications@github.com wrote:

Note that this relates to #4
#4 as it
would
(a) make it less painful to copy stuff in and out of a boot2docker VM
during build and (b) would make the resultant container images smaller
as
they'd all share a base with the single binary.

—
Reply to this email directly or view it on GitHub
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/108#issuecomment-46091743>

.

—
Reply to this email directly or view it on GitHub
#108 (comment)
.

Consider using subcommand instead of flags for defining which component to
launch, ex:
kube agent -some-agent-flag
On Jun 14, 2014 9:39 AM, "Daniel Smith" notifications@github.com wrote:

The localkube thing I made is most of the way there already.
On Jun 14, 2014 9:25 AM, "brendandburns" notifications@github.com
wrote:

SGTM.

Brendan

On Sat, Jun 14, 2014, 9:00 AM, Joe Beda notifications@github.com
wrote:

Note that this relates to #4
#4 as it
would
(a) make it less painful to copy stuff in and out of a boot2docker VM
during build and (b) would make the resultant container images smaller
as
they'd all share a base with the single binary.

—
Reply to this email directly or view it on GitHub
<

https://github.com/GoogleCloudPlatform/kubernetes/issues/108#issuecomment-46091743>

.

—
Reply to this email directly or view it on GitHub
<
https://github.com/GoogleCloudPlatform/kubernetes/issues/108#issuecomment-46092426>

.

—
Reply to this email directly or view it on GitHub
#108 (comment)
.

Maybe also support busybox-style command selection via argv[0]? That way you can symlink/hardlink the main binary under different names.

http://www.busybox.net/FAQ.html#source

@delroth I love the busybox model but I'm not sure that we want to rely on it completely. We will probably want to have the client tools run on Windows at some point and I'm not sure how that'd work.

In any case, everyone seems on board so I'll mark this as a "feature request" instead of a question.

I like the subcommand idea as seen in git, go command, gcloud and so on....

I'm going a bit against the crowd here, but I prefer each service as a separate binary mainly to help keep each one focused. If the decision was to move to a single binary then subcommands would be ideal:

kube apiserver
kube controller-manager
kube kubelet
kube proxy

But I think the UX of subcommands for completely different services to be pretty bad. It works well for users with experience, but will most likely confuse new users. Finally, again non-technical, but I think unnecessary coupling between components starts to happen once you have a "single" binary.

I'll agree with this last comment - I don't find 50 MB to be particularly damning - but maybe I have been in C++ land for too long. At the same time, I also don't find the idea of jamming them all together into one binary to make a lot of sense. It's sort of early to be apologizing for the size of Go binaries isn't it?

Or we could just do symlinks like:

kube-apiserver

Where the executable checks its executable name, sees it's != kube, then attempts to use the subcommand matching apiserver. That resolves the subcommand ordeal and enforces consistency at the same time.

I'm a huge +1 for a single binary, but it should be optional for folks who operate on different build cycles. We probably want to ensure that the executable entry points are cleanly separated from pkg/ code as well, so that people can create new cmd/ entry points that composite function.

IMO, having all of them grouped in a single command means that they will be used always together.

It is also true that when using a set of different tools, it is easier to have all related commands under one common prefix, so maybe @smarterclayton's solution is the best in this case

@jbeda @brendandburns Is this done?

@bgrant0607 This one seems to be done now that we have hyperkube.

Agree.

As we start building a bunch of binaries the size of our output goes up. Because of go static linking, we end up with 8-10MB for each binary. Currently we 7 of these for a total of 58M (find output/go -type f -perm +111 | xargs du -ch).

If we created a single binary with a switch for which functionality users want we would have a single binary that would adapt as necessary and probably be ~10M.

I'd image we'd call this thing kube and by default it'd be the client binary. If you want to run a server component you would do something like kube --daemon=api-server.

Thoughts?

Create a file /opt/KUCC00302/kucc00302.txt that lists all pods that implement Service foo in
Namespace production.
The format of the file should be one pod name per line.

kubectl get svc -o wide -n production
得到label
kubectl get pod -l label=value |awk '{print $1}' |grep -v "NAME" >> /opt/KUCC00302/kucc00302.txt
kubectl get po -l label