<tt><font size=2>Steven Dake <sdake@redhat.com> wrote on 09/24/2014
11:02:49 PM:<br>
<br>
> On 09/24/2014 03:31 PM, Alan Kavanagh wrote:</font></tt>
<br><tt><font size=2>> Steven</font></tt>
<br><tt><font size=2>> I have to ask what is the motivation and benefits
we get from <br>
> integrating Kubernetes into Openstack? Would be really useful if you<br>
> can elaborate and outline some use cases and benefits Openstack and
<br>
> Kubernetes can gain. </font></tt>
<br><tt><font size=2>>  </font></tt>
<br><tt><font size=2>> /Alan</font></tt>
<br><tt><font size=2>>  </font></tt>
<br><tt><font size=2>> Alan,<br>
> <br>
> I am either unaware or ignorant of another Docker scheduler that is
<br>
> currently available that has a big (100+ folks) development <br>
> community.  Kubernetes meets these requirements and is my main
<br>
> motivation for using it to schedule Docker containers.  There
are <br>
> other ways to skin this cat - The TripleO folks wanted at one point
<br>
> to deploy nova with the nova docker VM manager to do such a thing. 
<br>
> This model seemed a little clunky to me since it isn't purpose built<br>
> around containers.</font></tt>
<br>
<br><tt><font size=2>Does TripleO require container functionality that
is not available</font></tt>
<br><tt><font size=2>when using the Docker driver for Nova?</font></tt>
<br>
<br><tt><font size=2>As far as I can tell, the quantitative handling of
capacities and</font></tt>
<br><tt><font size=2>demands in Kubernetes is much inferior to what Nova
does today.</font></tt>
<br><tt><font size=2><br>
> As far as use cases go, the main use case is to run a specific <br>
> Docker container on a specific Kubernetes "minion" bare
metal host.</font></tt>
<br>
<br><tt><font size=2>If TripleO already knows it wants to run a specific
Docker image</font></tt>
<br><tt><font size=2>on a specific host then TripleO does not need a scheduler.</font></tt>
<br><tt><font size=2><br>
> These docker containers are then composed of the various config <br>
> tools and services for each detailed service in OpenStack.  For
<br>
> example, mysql would be a container, and tools to configure the <br>
> mysql service would exist in the container.  Kubernetes would
pass <br>
> config options for the mysql database prior to scheduling</font></tt>
<br>
<br><tt><font size=2>I am not sure what is meant here by "pass config
options" nor how it</font></tt>
<br><tt><font size=2>would be done prior to scheduling; can you please
clarify?</font></tt>
<br><tt><font size=2>I do not imagine Kubernetes would *choose* the config
values,</font></tt>
<br><tt><font size=2>K8s does not know anything about configuring OpenStack.</font></tt>
<br><tt><font size=2>Before scheduling, there is no running container to
pass</font></tt>
<br><tt><font size=2>anything to.</font></tt>
<br>
<br><tt><font size=2>>              
                     
                     
and once <br>
> scheduled, Kubernetes would be responsible for connecting the <br>
> various containers together.<br>
</font></tt>
<br><tt><font size=2>Kubernetes has a limited role in connecting containers
together.</font></tt>
<br><tt><font size=2>K8s creates the networking environment in which the
containers</font></tt>
<br><tt><font size=2>*can* communicate, and passes environment variables
into containers</font></tt>
<br><tt><font size=2>telling them from what protocol://host:port/ to import
each imported</font></tt>
<br><tt><font size=2>endpoint.  Kubernetes creates a universal reverse
proxy on each</font></tt>
<br><tt><font size=2>minion, to provide endpoints that do not vary as the
servers</font></tt>
<br><tt><font size=2>move around.</font></tt>
<br><tt><font size=2>It is up to stuff outside Kubernetes to decide</font></tt>
<br><tt><font size=2>what should be connected to what, and it is up to
the containers</font></tt>
<br><tt><font size=2>to read the environment variables and actually connect.</font></tt>
<br>
<br><tt><font size=2>Regards,</font></tt>
<br><tt><font size=2>Mike</font></tt>
<br>