cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Will Stevens <wstev...@cloudops.com>
Subject Re: [PROPOSAL] add native container orchestration service
Date Fri, 27 Jan 2017 15:08:57 GMT
Hey Murali,
How different is this proposal than what ShapeBlue already built.  It looks
pretty consistent with the functionality that you guys open sourced in
Seville.

I have not yet used this functionality, but I have reports that it works
quite well.

I believe the premise here is to only orchestrate the VM layer and
basically expose a "group" of running VMs to the user.  The user is
responsible for configuring K8S or whatever other container orchestrator on
top.  I saw mention of the "cloud-config" scripts in the FS, how are those
exposed to the cluster?  Maybe the FS can expand on that a bit?

I believe the core feature that is being requested to be added is the
ability to create a group of VMs which will be kept active as a group if at
all possible.  ACS would be responsible for making sure that the number of
VMs specified for the group are in running state and it would spin up new
VMs as needed in order to satisfy the group settings.  In general, it is
understood that any application running on this group would have to be
fault tolerant enough to be able to rediscover a new VM if one fails and is
replaced by a fresh copy.  Is that fair to say?  How is it expected that
this service discovery is done, just by VMs being present on the network?

As for some of the other people's concerns in this thread.

- Regarding Wido's remarks.  I understand that there is some added
complexity, but I don't feel like the scope of the addition is
unrealistic.  I think the LXC integration was a lot farther out of the
scope of what ACS does then this is.  This does not change the "things"
which ACS orchestrates, it just adds the concept of a grouping of things
which ACS already manages.  I think this is the right approach since it is
not trying to be a container orchestrator.  We will never compete with K8S,
for example, and we should not try, but K8S is here and the market wants
it.  I do think we should be keeping our head up about that fact because
being able to provide a the underlay for K8S is very valuable in the
current marketplace.  I see this functionality as a way to enable K8S
adoption on top of ACS without changing our core values.

- Regarding Erik's remarks.  The container space is moving fast, but so is
the industry.  If we want to remain relevant, we need to be able to adapt a
bit.  I don't think this is a big shift in what we do, but it is one that
enables people to be able to start running with something like K8S on top
of their existing ACS.  This is something we are interested in doing and so
are our customers.  If we can have a thin layer in ACS which helps enable
the use of K8S (or other container orchestrators) by orchestrating
infrastructure, as we already do, and making it easier to adopt a container
orchestrator running on top of ACS, I think that gives us a nice foothold
in the market.  I don't really feel it is fair to compare containers to
IPv6.  IPv6 has been out forever and it has taken almost a decade to get
anyone to adopt it.  Containers have really only been here for like 2 years
and they are changing the market landscape in a very real way.

Kind of on topic and kind of off topic.  I think understanding our approach
to containers is going to be important for the ACS community as a whole.
If we don't offer that market anything, then we will not be considered and
we will lose market share we can't afford to lose.  If we try to hitch our
horse to that cart too much, we will not be able to be agile enough and
will fail.  I feel like the right approach is for us to know that it is a
thriving market and continue to do what we do, but to extend an olive
branch to that market.  I think this sort of implementation is the right
approach because we are not trying to do too much.  We are simply giving a
foundation on which the next big thing in the container orchestration world
can adopt without us having to compete directly in that space.  I think we
have to focus on what we do best, but at the same time, think about what we
can do to enable that huge market of users to adopt ACS as their
foundation.  The ability to offer VMs and containers in the same data plane
is something we have the ability to do, especially with this approach, and
is something that most other softwares can not do.  The adoption of
containers by bigger organizations will be only part of their workload,
they will still be running VMs for the foreseeable future. Being able to
appeal to that market is going to be important for us.

Hopefully I don't have too many strong opinions here, but I do think we
need to be thinking about how we move forward in a world which is adopting
containers in a very real way.

Cheers,

Will

*Will STEVENS*
Lead Developer

<https://goo.gl/NYZ8KK>

On Fri, Jan 27, 2017 at 5:38 AM, Erik Weber <terbolous@gmail.com> wrote:

> On Fri, Jan 27, 2017 at 7:20 AM, Murali Reddy <muralimmreddy@gmail.com>
> wrote:
> > All,
> >
> > I would like propose native functionality into CloudStack to provide a
> container service through which users out-of-the box can use to launch
> container based application. Idea is to support ability to orchestrate the
> resources and automate aspects of setting up container orchestrator through
> CloudStack. Public IAAS service providers AWS with its ECS [1] and google
> with GKE [2] already provides ability container applications.  Competitive
> cloud orchestration platforms already have native support for container
> service. Users of CloudStack both as public cloud providers and users with
> private clouds will benefit with such functionality.
> >
> > While container orchestrator of user choice can be provisioned on top of
> CloudStack (with out CloudStack being involved) with tools like
> TerraForm[3], Ansible[4] etc, advantage of having native orchestration is
> giving user a nice cohesive integration. This proposal would like add a
> notion of first class CloudStack entity called container cluster which can
> be used to provision resources, scale up, scale down, start and stop the
> cluster of VM’s on which containerised applications can be run. For actual
> container orchestration we will still need container orchestrator like
> docker swarm, marathon, kubernetes, but CloudStack container service can
> automate setting up of control place automatically.
> >
>
> To be honest I'm torn on this one.
>
> Containers are a rapid changing thing, and while docker swam,
> kubernetes, rancher or whatnot is popular today, they might not be
> tomorrow.
> They might use CoreOS today, but might not tomorrow.
>
> We have a rather poor track record of staying up to date with new
> features/versions, and adding a feature that is so rapidly changing
> is, I fear, going to be hard to maintain.
> Want an example, look at xenserver. It is one of the most used
> hypervisors we support, yet it took 6 months or so for us to support
> the latest release.
> Or IPv6...
>
> I don't mean to bash at maintainers/implementers of those features, I
> appreciate all the work being done in every aspect, but I believe we
> should be realistic and realize that we have issues with keeping stuff
> up to date.
>
> I'd say focus on making sure other tools can do their job well against
> CloudStack (kops, rancher, ++), but that does not mean I will -1 the
> idea if anyone really wants to go through with it.
>
> --
> Erik
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message