[openstack-dev] [Zun] About k8s integration

Hongbin Lu hongbin.lu at huawei.com
Mon Dec 12 19:20:22 UTC 2016


Thanks for the inputs. Let’s continue the discussion at the team meeting later today.

Best regards,

From: shubham sharma [mailto:shubham.git at gmail.com]
Sent: December-12-16 12:19 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Zun] About k8s integration

Hi Hongbin,

Both of these 2 options have pros and cons :
1. If we create our own "pod like concept" in Zun, then:
-> It is duplicating the efforts for the features that are already available in a particular COE.
-> It requires huge efforts as compared to second option
-> When we create our own pods then how do we can't say that we are not competing with existing COEs
-> If we have to provide our own pods and similar features then, we will need to have some more features (eg: Replication Controller) to attract users for Zun

2. If we create proxy for k8s, then:
-> It will be specific to k8s and for other COEs also, we will need to do the same
-> We do not want to compete with any COE and that can be achieved by following this approach
-> Our approach of choosing k8s first might be questionable as in "why to support a specific COE first, why not swarm first"
-> Moreover behaving like proxy only doesn't makes much sense. Instead of using zun, they will use will native clis of respective COE. Zun will just add complexity for such users

Looking at above, still feel that we should have our own implementation of pods(or similar term for it) because that's where we should be heading for Zun. Zun can't be just for CRUD operations of containers. If we take a common subset of features from each COE and have them in Zun then our goal is clear that we want to have containers supported inside OpenStack without the need of any COEs. It sounds like competing with COEs but in fact we are just trying to make OpenStack friendly for the users/operators who wants to use containers inside/with OpenStack.
​this design seems quite extensible i.e. we can easily integrate with other COEs without having users to worry which COE they are actually running.Same set of APIs can be used for any COE at the backend​.

​For required efforts,we need to think and plan.


On Wed, Dec 7, 2016 at 6:26 AM, Hongbin Lu <hongbin.lu at huawei.com<mailto:hongbin.lu at huawei.com>> wrote:
Hi all,

This is a continued discussion of the k8s integration blueprint [1]. Currently, Zun exposes a container-oriented APIs that provides service for end-users to operate on containers (i.e. CRUD). At the last team meeting, we discussed how to introduce k8s to Zun as an alternative to the Docker driver. There are two approaches that has been discussed:

1. Introduce the concept of Pod. If we go with this approach, an API endpoint (i.e. /pods) will be added to the Zun APIs. Both Docker driver and k8s driver need to implement this endpoint. In addition, all the future drivers need to implement this endpoint as well (or throw a NotImplemented exception). Some of our team members raised concerns about this approach. The main concern is that this approach will hide a lot of k8s-specific features (i.e. replication controller) or there will be a lot of work to bring all those features to Zun.

  $ zun pod-create … # this create a k8s pod (if k8s driver is used), or create a sandbox with a set of containers (if docker driver is used)
  $ zun create … # this create a k8s pod with one container, or create a sandbox with one container

2. Introduce a dedicated k8s endpoint that acts as a proxy to k8s APIs. This will expose all the k8s features but users won’t have a unified APIs across drivers.

  $ zun k8s pod create … # this create a k8s pod
  $ zun docker container create … # this create a docker container
  $ zun create … # the behavior of this command is unclear

So far, we haven’t decided which approach to use (or use a third approach), but we wanted to collect more feedback before making a decision. Thoughts?

[1] https://blueprints.launchpad.net/zun/+spec/k8s-integration

Best regards,

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161212/3894b0f6/attachment.html>

More information about the OpenStack-dev mailing list