Create a single kubernetes binary for all cmds about kubernetes HOT 15 CLOSED

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.

from kubernetes.

SGTM.

Brendan

On Sat, Jun 14, 2014, 9:00 AM, Joe Beda [email protected] 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)
.

from kubernetes.

The localkube thing I made is most of the way there already.
On Jun 14, 2014 9:25 AM, "brendandburns" [email protected] wrote:

SGTM.

Brendan

On Sat, Jun 14, 2014, 9:00 AM, Joe Beda [email protected] 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)
.

from kubernetes.

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" [email protected] wrote:

The localkube thing I made is most of the way there already.
On Jun 14, 2014 9:25 AM, "brendandburns" [email protected]
wrote:

SGTM.

Brendan

On Sat, Jun 14, 2014, 9:00 AM, Joe Beda [email protected]
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)
.

from kubernetes.

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

from kubernetes.

@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.

from kubernetes.

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

from kubernetes.

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.

from kubernetes.

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?

from kubernetes.

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.

from kubernetes.

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

from kubernetes.

@jbeda @brendandburns Is this done?

from kubernetes.

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

from kubernetes.

Agree.

from kubernetes.

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

from kubernetes.