Added service-cluster-ip-range as flag to bootkube start

[dhawal55]

Fixes #236

[coreosbot]

Can one of the admins verify this patch?

[coreosbot]

Can one of the admins verify this patch?

[aaronlevy]

Changing of the service IP ends up touching many different components. And while it really does need to be a configurable -- I'm hesitant to try and plumb this through as a configuration option right now.

As an example (and I'm likely forgetting things) - For this change to work properly, it also requires changes to the on-host kubelet, self-hosted kubelet, self-hosted controller-manager, dns service manifest, validation of podCidrs, and templating tls asset generation.

It ends up being a fairly intrusive change. And while I'm not outright opposed to making this a configurable, it does open a pretty big door for complexity. Any change which would require coordination of flags between bootkube render and bootkube start means that we can leave users in a place where generated assets no longer work unless you use the correct flags (which I really want to avoid).

Longer term, I believe minimizing this risk will come in a couple stages:

• Changing bootkube start to using static manifests for the temporary control-plane, rather than compiled-in components (Possibly use static pods for temporary control-plane rather than compiled-in components #168). This will mean that bootkube render will create all the information needed for the temporary control-plane, and bootkube start can source all of that information from static manifests (not runtime flags).

• Changing bootkube render to source from versioned configuration, rather than runtime flags. See some of the brainstorming discussion here: Provide a generic mechanism for flag customizations #106

[dhawal55]

@aaronlevy I like the idea of bootkube start using static manifests for temporary control-plane. Currently, I'm not using bootkube render to generate assets becuase there are lots of configuration missing. I generate my own assets dir and pass it to bootkube start. It makes sense to do the same for temporary control-plane too. Will the init_master.sh script be responsible for copying over the static manifests to /etc/kubernetes/manifests directory?

[aaronlevy]

@dhawal55 init-master.sh just copies from the remote location to your local box (so that you have a copy of things like the CA cert, etc.). But it merely executes bootkube remotely.

I think in the new mode of operation we would still do the same (execute bootkube remotely) -- but with bootkube start --cluster-dir=foo, the cluster-dir would also contain manifests for the "temporary" control plane.

This would allow you to similarly not use render (or use, then modify) -- and self provide those assets however you see fit (and just reference a --cluster-dir)

[aaronlevy]

I'm going to close this PR in favor of a (yet to be implemented) alternative solution discussed in: #236 (comment)