Test flannel-docker as possible solution for add-unit

whitmo / bundle-kubernetes

A juju bundle to deploy a multi-node kubernetes stack

Other

5 stars 2 forks source link

Test flannel-docker as possible solution for add-unit #3

Open whitmo opened 9 years ago

lazypower commented 9 years ago

@whitmo @mbruzek I was thinking about taking the existing deployment infra and subbing in the docker + flannel-docker charms we have nearly carried to a first iteration stable release, getting them seated firmly in this bundle, and track just those vs continuing to maintain the existing flannel charm in the bundle.

This would obv. be lower priority than existing work items, but what are your thoughts on this?

mbruzek commented 9 years ago

@marcoceppi mentioned that adding flannel units first and using --to was kind of wonky/unnatural and I would like to see if we could address that in the charm.

lazypower commented 9 years ago

well if we switched to the docker charm as it stands today - that replaces one --to with another --to :( we would be co-locating docker and the kubes minion... unless we move kubes minion to a subordinate service.

mbruzek commented 9 years ago

@chuckbutler I didn't think about making the Kubernetes minion a subordinate! That is a idea worth exploring.

I know we talked about having the flannel node on there first because it had to do some networking config before kubernetes code ran. Is that still the case here? Or with our new understanding can we apply the flannel stuff at any time?

lazypower commented 9 years ago

I think flannel would have to come up before the minion is added, and heres why: I believe this has to do with minion enlistment in kubes-master. If that's the case we can guard against that since we are controlling the charm delivery. Now this has some implications that we'll have to explore - such as:

Is flannel our only SDN concern? (its the only one we have implemented today)
are we ever going to not care if there is an SDN - as in, will we always be using SDN

If thats not the case - I think this will just work. Even if we implement flannel post-facto, I do believe if we kick the minion service it should re-enlist with the new networking config (worth exploring as well)

lazypower commented 9 years ago

I've got some prototype code for this in a bundle. I can confirm that moving kubernetes (the minions) to a subordinate - this makes 'add-unit docker` scale the service, and propigates the mesh container farm growing as we would expect. I'll follow up with details once I have the prototype tested and pushed