OVN multi-network plugin for Kubernetes

[Petr Horacek]

Hi,

I finished first working PoC version of Kubetron, OVN multi-network plugin for Kubernetes.

It allows users to connect their Pods to networks configured externally via Neutron API.

After Kubetron and OVN are deployed, administrator can create networks via Ansible/curl and then a user can request these network with a Pod annotation. Once the pod is created on a node it has secondary network interfaces available. If a network has assigned subnet, this interface would obtain an IP address.

You can read sources from kubetron repository https://github.com/phoracek/kubetron, check out presentation about desired model and demo overview on Google slides https://docs.google.com/presentation/d/1KiHQyZngdaL8gtreL9Tmy7S1XiY5Sbnn0YuNCqhggF8/edit?usp=sharing or watch a quick 3min demo on asciinema https://asciinema.org/a/7nB3vgIJcz05TxRNiaD2vLLdE.

If you have any questions, comments suggestions, feel free to comment on the slides or respond to this mail.

Some implementation details of the PoC, more in slides: It uses an admission controller to create ports on requested networks in OVN and add a side-container requesting kubetron resource. There is also a device plugin attaching the Pod to given network by creating an interface on OVS (device plugin checkpoint hack is used to obtain Pod ID). Finally, the side-container runs dhclient on ports connected to networks with an assigned subnet.

Best regards,

Petr

[Ihar Hrachyshka]

Very nice!

I may have some comments and suggestions on the code, but nothing
major (e.g. suggestions on neutron API interaction optimization, HTTP
codes used, log messages etc.) so I am not too sure you would be
interested in them at this point in time. (At the end of the day, it's
just a PoC.) So, what kind of feedback are you looking for right now?
And what's your preferred medium (email? github issues?)

Regards,
Ihar

> --
> You received this message because you are subscribed to the Google Groups
> "kubernetes-wg-resource-management" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to kubernetes-wg-resource...@googlegroups.com.
> To post to this group, send email to
> kubernetes-wg-re...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/kubernetes-wg-resource-management/CAGkpguVdUMRPjkbrD-TgzPVkJUb-u%2BQe-92Xw3AYF80t%3DoUGSQ%40mail.gmail.com.
> For more options, visit https://groups.google.com/d/optout.

[Russell Bryant]

Thank you for sharing!

My main feedback is that I do not think it makes sense to have the Neutron API as something used directly in the Kubernetes context.  My concerns are based on a number of factors, including:

 - my feeling of the general industry feelings about the Neutron API (not great, and also often incompatible with newer approaches)

 - long term outlook for the main Neutron project (slowing down quite a bit, not likely to evolve drastically)

 - state of the network plugin ecosystem for Kubernetes (quite healthy, Neutron doesn't bring access to new backends)

 - what interfaces I expect make sense to expose in a Kubernetes context (should prefer Kubernetes native interfaces over alternative APIs where it makes sense, and I'd argue that's the case here)

I see you include a Network CRD in this PoC.  Instead of having that dynamically created based on what exists in Neutron, I'd flip it and have the Network CRD be what a user (or admin) creates, and then have networks created on the backend automatically, if necessary.  In other words, make Neutron an implementation detail, not something that gets used directly.

Then Neutron becomes one possible backend, which is what the Kuryr project does today and could be expanded to support Network objects in the future if/when they are defined.

-- 

Russell Bryant

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-network" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-network+unsub...@googlegroups.com.
To post to this group, send email to kubernetes-sig-network@googlegroups.com.
Visit this group at https://groups.google.com/group/kubernetes-sig-network.

[Antoni Segura Puimedon]

On Thu, May 17, 2018 at 11:23 PM, Russell Bryant <rbr...@redhat.com> wrote:
> Thank you for sharing!
>
> My main feedback is that I do not think it makes sense to have the Neutron
> API as something used directly in the Kubernetes context. My concerns are
> based on a number of factors, including:
>
> - my feeling of the general industry feelings about the Neutron API (not
> great, and also often incompatible with newer approaches)
>
> - long term outlook for the main Neutron project (slowing down quite a bit,
> not likely to evolve drastically)
>
> - state of the network plugin ecosystem for Kubernetes (quite healthy,
> Neutron doesn't bring access to new backends)
>
> - what interfaces I expect make sense to expose in a Kubernetes context
> (should prefer Kubernetes native interfaces over alternative APIs where it
> makes sense, and I'd argue that's the case here)
>
> I see you include a Network CRD in this PoC. Instead of having that
> dynamically created based on what exists in Neutron, I'd flip it and have
> the Network CRD be what a user (or admin) creates, and then have networks
> created on the backend automatically, if necessary. In other words, make
> Neutron an implementation detail, not something that gets used directly.

This sounds more K8s user friendly indeed.

>> email to kubernetes-sig-ne...@googlegroups.com.

>> To post to this group, send email to

>> kubernetes-...@googlegroups.com.

>> Visit this group at
>> https://groups.google.com/group/kubernetes-sig-network.
>> For more options, visit https://groups.google.com/d/optout.
>

> --
> You received this message because you are subscribed to the Google Groups
> "kubernetes-sig-network" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to kubernetes-sig-ne...@googlegroups.com.

> To post to this group, send email to

> kubernetes-...@googlegroups.com.

[Dan Kenigsberg]

I'll trust you about Neutron falling out of zeitgeist, but do we have
a current alternative? In Petr's demo, he used Neutron's Ansible roles
to define the networks. Very easily can he use Ansible to define
routers as well. He can attach his PoC to ManageIQ for GUI, and
probably to Horizon, not to mention oVirt or the neutron command line.

I think that k8s wants to keep itself pristine and to know as little
as possible about things outside its core. Would it ever want to
internalize all the network modeling that's already done in Neutron?

Anyway, Petr has mentioned an optional mirroring service. I wanted to
keep it off (because duplicating data is evil), but it can surely be
turned on and flipped direction, translating k8s networks into Neutron
ones. If Neutron is cut out, and the translation is done directly into
OVN entity, the Admission Controller will have to include an
OVN-specific driver (duplicating work already done by the Neutron ml2
driver for OVN), and external complex manageability is lost.