Open Stack

Steven Dake <sdake at redhat.com> wrote on 09/24/2014 11:02:49 PM:

> On 09/24/2014 03:31 PM, Alan Kavanagh wrote:
> Steven
> I have to ask what is the motivation and benefits we get from 
> integrating Kubernetes into Openstack? Would be really useful if you
> can elaborate and outline some use cases and benefits Openstack and 
> Kubernetes can gain. 
>  
> /Alan
>  
> Alan,
> 
> I am either unaware or ignorant of another Docker scheduler that is 
> currently available that has a big (100+ folks) development 
> community.  Kubernetes meets these requirements and is my main 
> motivation for using it to schedule Docker containers.  There are 
> other ways to skin this cat - The TripleO folks wanted at one point 
> to deploy nova with the nova docker VM manager to do such a thing.  
> This model seemed a little clunky to me since it isn't purpose built
> around containers.

Does TripleO require container functionality that is not available
when using the Docker driver for Nova?

As far as I can tell, the quantitative handling of capacities and
demands in Kubernetes is much inferior to what Nova does today.

> As far as use cases go, the main use case is to run a specific 
> Docker container on a specific Kubernetes "minion" bare metal host.

If TripleO already knows it wants to run a specific Docker image
on a specific host then TripleO does not need a scheduler.

> These docker containers are then composed of the various config 
> tools and services for each detailed service in OpenStack.  For 
> example, mysql would be a container, and tools to configure the 
> mysql service would exist in the container.  Kubernetes would pass 
> config options for the mysql database prior to scheduling

I am not sure what is meant here by "pass config options" nor how it
would be done prior to scheduling; can you please clarify?
I do not imagine Kubernetes would *choose* the config values,
K8s does not know anything about configuring OpenStack.
Before scheduling, there is no running container to pass
anything to.

>                                                           and once 
> scheduled, Kubernetes would be responsible for connecting the 
> various containers together.

Kubernetes has a limited role in connecting containers together.
K8s creates the networking environment in which the containers
*can* communicate, and passes environment variables into containers
telling them from what protocol://host:port/ to import each imported
endpoint.  Kubernetes creates a universal reverse proxy on each
minion, to provide endpoints that do not vary as the servers
move around.
It is up to stuff outside Kubernetes to decide
what should be connected to what, and it is up to the containers
to read the environment variables and actually connect.

Regards,
Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140924/50df4c49/attachment.html>