Open Stack

On 29/05/16 08:16, Hongbin Lu wrote:
>
>> -----Original Message-----
>> From: Zane Bitter [mailto:zbitter at redhat.com]
>> Sent: May-27-16 6:31 PM
>> To: OpenStack Development Mailing List
>> Subject: [openstack-dev] [TripleO][Kolla][Heat][Higgins][Magnum][Kuryr]
>> Gap analysis: Heat as a k8s orchestrator
>>
>> I spent a bit of time exploring the idea of using Heat as an external
>> orchestration layer on top of Kubernetes - specifically in the case of
>> TripleO controller nodes but I think it could be more generally useful
>> too - but eventually came to the conclusion it doesn't work yet, and
>> probably won't for a while. Nevertheless, I think it's helpful to
>> document a bit to help other people avoid going down the same path, and
>> also to help us focus on working toward the point where it _is_
>> possible, since I think there are other contexts where it would be
>> useful too.
>>
>> We tend to refer to Kubernetes as a "Container Orchestration Engine"
>> but it does not actually do any orchestration, unless you count just
>> starting everything at roughly the same time as 'orchestration'. Which
>> I wouldn't. You generally handle any orchestration requirements between
>> services within the containers themselves, possibly using external
>> services like etcd to co-ordinate. (The Kubernetes project refer to
>> this as "choreography", and explicitly disclaim any attempt at
>> orchestration.)
>>
>> What Kubernetes *does* do is more like an actively-managed version of
>> Heat's SoftwareDeploymentGroup (emphasis on the _Group_). Brief recap:
>> SoftwareDeploymentGroup is a type of ResourceGroup; you give it a map
>> of resource names to server UUIDs and it creates a SoftwareDeployment
>> for each server. You have to generate the list of servers somehow to
>> give it (the easiest way is to obtain it from the output of another
>> ResourceGroup containing the servers). If e.g. a server goes down you
>> have to detect that externally, and trigger a Heat update that removes
>> it from the templates, redeploys a replacement server, and regenerates
>> the server list before a replacement SoftwareDeployment is created. In
>> constrast, Kubernetes is running on a cluster of servers, can use rules
>> to determine where to run containers, and can very quickly redeploy
>> without external intervention in response to a server or container
>> falling over. (It also does rolling updates, which Heat can also do
>> albeit in a somewhat hacky way when it comes to SoftwareDeployments -
>> which we're planning to fix.)
>>
>> So this seems like an opportunity: if the dependencies between services
>> could be encoded in Heat templates rather than baked into the
>> containers then we could use Heat as the orchestration layer following
>> the dependency-based style I outlined in [1]. (TripleO is already
>> moving in this direction with the way that composable-roles uses
>> SoftwareDeploymentGroups.) One caveat is that fully using this style
>> likely rules out for all practical purposes the current Pacemaker-based
>> HA solution. We'd need to move to a lighter-weight HA solution, but I
>> know that TripleO is considering that anyway.
>>
>> What's more though, assuming this could be made to work for a
>> Kubernetes cluster, a couple of remappings in the Heat environment file
>> should get you an otherwise-equivalent single-node non-HA deployment
>> basically for free. That's particularly exciting to me because there
>> are definitely deployments of TripleO that need HA clustering and
>> deployments that don't and which wouldn't want to pay the complexity
>> cost of running Kubernetes when they don't make any real use of it.
>>
>> So you'd have a Heat resource type for the controller cluster that maps
>> to either an OS::Nova::Server or (the equivalent of) an OS::Magnum::Bay,
>> and a bunch of software deployments that map to either a
>> OS::Heat::SoftwareDeployment that calls (I assume) docker-compose
>> directly or a Kubernetes Pod resource to be named later.
>>
>> The first obstacle is that we'd need that Kubernetes Pod resource in
>> Heat. Currently there is no such resource type, and the OpenStack API
>> that would be expected to provide that API (Magnum's /container
>> endpoint) is being deprecated, so that's not a long-term solution.[2]
>> Some folks from the Magnum community may or may not be working on a
>> separate project (which may or may not be called Higgins) to do that.
>> It'd be some time away though.
>>
>> An alternative, though not a good one, would be to create a Kubernetes
>> resource type in Heat that has the credentials passed in somehow. I'm
>> very against that though. Heat is just not good at handling credentials
>> other than Keystone ones. We haven't ever created a resource type like
>> this before, except for the Docker one in /contrib that serves as a
>> prime example of what *not* to do. And if it doesn't make sense to wrap
>> an OpenStack API around this then IMO it isn't going to make any more
>> sense to wrap a Heat resource around it.
> There are ways to alleviate the credential handling issue. First, Kubernetes supports Keystone authentication [1]. Magnum has a BP [2] to turn on this feature. In addition, there is a Kubernetes python-binding [3] under development. By combining all these efforts, it is possible to create a Kubernetes resource in Heat without handing credentials other than the Keystone ones.
>
> [1] http://kubernetes.io/docs/admin/authentication/
> [2] https://blueprints.launchpad.net/magnum/+spec/keystone-for-k8s-bay
> [3] https://github.com/openstack/python-k8sclient
>
>> A third option might be a SoftwareDeployment, possibly on one of the
>> controller nodes themselves, that calls the k8s client. (We could
>> create a software deployment hook to make this easy.) That would suffer
>> from all of the same issues that TripleO currently has about having to
>> choose a server on which to deploy though.
>  From my point of view, the Kubernetes Heat resources approach is possibly more user-friendly than the SoftwareDeployment approach.
Having kubernetes accept a keystone token would likely meet TripleO's 
requirements and justify creating a heat resource which interacts 
directly with kubernetes. A general solution would also need some 
multi-tenancy separation - and that is what magnum does.

So we could have an in-tree kubernetes resource as long as we don't do 
what we did for the docker resource and allow the endpoint/auth to be 
specified via resource properties. The endpoint would have to come from 
a magnum resource, or the keystone catalog, or something else beyond the 
influence of the template author.

> That is because SoftwareDeployment and SoftwareDeploymentGroup resources are very advanced and complex. It might take a while for users to figure out how to use them. The requirement of building a custom image is another barrier of entry. In Magnum, we explored the possibility to leverage SD/SDG in Atomic-based COEs, but stopped on that direction until the os-*-* tools have been fully containerized [4] so that those resources could work on any OS.
>
> [4] https://bugs.launchpad.net/magnum/+bug/1424969
There have been containerized heat-agent options for quite some time 
now. heat-templates hosts one using docker-compose:
https://github.com/openstack/heat-templates/tree/master/hot/software-config/heat-container-agent

But likely a better starting point is the the one being developed in 
tripleo-common:
https://github.com/openstack/tripleo-common/tree/master/heat_docker_agent

It uses docker-compose but will soon switch to using docker directly, 
while using an identical configuration format.


>> The secondary obstacle is networking. TripleO has some pretty
>> complicated networking requirements (specifically network isolation for
>> the various services) that for now can't be supported when deploying a
>> cluster with Magnum. The Kuryr project is working on improved
>> networking for Magnum, but I don't know whether this is a use-case that
>> would be covered.
> Sorry, I don't get this. Mind elaborating the details of your network requirements?
IAmNotANetworkingExpert, but here is my understanding of the requirements.

TripleO uses neutron to define an overlay network. The architecture of 
this network is completely flexible based on the deployer's specific 
requirements for network isolation of various traffic classes. Each node 
has a corresponding os-net-config data deployed to it to configure its X 
interfaces to Y isolated networks (using bonding if X!=Y)

Since we already have the overhead of one overlay network, we have the 
hard requirement of kubernetes *not* adding another one. I believe this 
rules out any solution involving flannel.

It sounds like full integration between Kuryr and Kubernetes is the best 
chance of providing what we need, and I see two new repos that look like 
are intended to host this integration:
http://git.openstack.org/cgit/openstack/kuryr-kubernetes
http://git.openstack.org/cgit/openstack/kuryr-libnetwork

Tripleo defines neutron ports for the overcloud service VIPs and 
configures a HA loadbalancer in the overcloud to back them. It would be 
very nice if the kuryr-kubernetes integration could integrate kubernetes 
service vips with already created neutron ports.

>> There's also the issue that IIUC Magnum operates its Neutron L3 agents
>> in such a way that connectivity to the user nodes is guaranteed only if
>> Magnum itself is running in an HA cloud. This is a problematic
>> assumption in general, but it's particularly problematic in the case of
>> the TripleO *undercloud*, which is not HA and which we very much do not
>> want to be in the networking path for the overcloud controller nodes.
>> Again, I don't know if this will be resolved by Kuryr or when.
>>
>> Magnum does offer the option to pass a custom template, and I assume
>> that would allow us to set up the networking the way we want it.
>> However, TripleO uses all kinds of tricks with the environment and
>> parameters, so there'd quite likely need to be some enhancements to
>> both Heat (in order to access the current environment from within a
>> template) and Magnum (to pass an environment along with the template)
>> to support that.
> Magnum prefers to leverage the Heat conditionals feature instead of leveraging environments, because we expected Heat conditionals would make our Heat templates simpler and easier to maintain. If we can pass a parameter to Heat template and use conditionals to interpret the parameter, I am not sure if we also need to support passing environments as well (it seems conditionals can do whatever environments can do).
>

I assume that the HA requirements of Magnum is due to the overlay 
network it manages, needing an HA undercloud is a second reason why we 
wouldn't want to add another overlay.

>> At that point it's a legitimate question to ask what exactly Magnum is
>> buying us if TripleO has to maintain its own Kubernetes deployment
>> templates anyway. I can think of only two things: an easier transition
>> later if we do believe that the networking stuff will be resolved, and
>> the /containers API. And the /containers API is being deprecated.
>>
>> In that sense, the Magnum/Higgins split could be a good thing for the
>> Heat+Kubernetes use case in the long term - if we had a
>> Keystone-authenticated API that can allow Heat to make use of any k8s
>> cluster, not just those deployed via Magnum, then Magnum could be cut
>> out of the loop in those cases where networking issues preclude its use.
> Wearing my Magnum PTL hat, I am sorry to hear Magnum couldn't resolve your problem immediately. Wearing my Higgins core hat, I am thrilled that Higgins is under your consideration in long term.

I'd like to think that if kubernetes had a viable no-overlay 
neutron-integrated networking option then Magnum would be prepared to 
support it.

In this case TripleO could consider using Magnum to manage the cluster 
via the Bay API. All I'm seeing to achieve this is the Bay node_count. 
This is fine for adding nodes to the controller cluster. Magnum is 
backed by Heat so it shouldn't be hard to expose a mechanism to scale 
down by removing specific nodes, but TripleO needs more than that. There 
may need to be REST API exposure and some COE integration to do things like:
- evacuate running containers from a node in preparation for scale down, 
replacement, or temporary removal for repair
- fencing a misbehaving node
- remove one node and add another in a single operation

Some discussion on whether it would be appropriate to perform these 
functions would be interesting. And if not Magnum then what? TripleO has 
something now but its been quite a journey to get 
heat/nova/ironic/pacemaker to work together in scale down and node 
replacement scenarios.
>> In the short term, though, there seems to be a number of obstacles.
>> Perhaps some of the folks involved in the relevant projects could
>> comment on when/if those are likely to be resolved.
>>
>> cheers,
>> Zane.
>>
>> [1]
>> http://lists.openstack.org/pipermail/openstack-dev/2016-
>> March/090055.html
>> [2]https://etherpad.openstack.org/p/newton-magnum-unified-abstraction
>>
>> _______________________________________________________________________
>> ___
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-
>> request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev