Network Plumbing Working Group kick-off

[Dan Williams]

It was great to talk to everyone at KubeCon, and hopefully we can bring
everyone who couldn't make it up to speed.

What
----
Starting with discussions at KubeCon, I'm organizing a "Network
Plumbing" or "Low-level Networking" working group that encompasses
topics around multi-network and how to rework those into something that
upstream Kubernetes finds acceptable.

How
---
Meet opposite weeks of the existing SIG Network meeting. Same time,
same Zoom, but every week SIG Network does not meet.

First meeting: December 21, for those who can make it.

We'll have a different agenda doc so we don't clutter up SIG Network's.

Who
---
Anyone interested in low-level network plumbing topics, though focusing
on the multi-network cases for the next few months. Everyone's
contributions will be welcome, though we'd like to keep focused and
implementation-driven.

Even if you're not part of the Kube community, feel free to join and
contribute. "Contribute" is a key word here :)

Short-term Goals
----------------
As Tim stated, "instead of a couple 30% solutions let's get a 90%
solution".

Combine the best parts of Multus and CNI Genie into one "standard"
multi-sidecar-network CNI plugin that works for existing users.
Standardize the CRDs and annotations for this plugin. Write
documentation and examples.

Continue gathering use-cases and figure out which ones multus+genie
does not satisfy. Especially around Services.

Medium/long-term Goals
----------------------
Continue discussing how to address the requirements from the Sept 27th
2017 meeting around API stability, app portability, and complexity.

Can we find some abstractions that work for enough people and don't
violate these requirements? The Resource Management WG may have some
lessons to offer here. Enhance the CNI plugin with these ideas, and
continue doing PoCs to prove them.

What further extension points are needed from Kube? Help make those
happen.

If we actually think we need API changes, work with upstream to make
those happen in a way that doesn't greatly increase complexity of
Kubernetes.

Structure
---------
For now I'd like to keep this an informal working group. If things go
well we can think about trying to formalize within the Kubernetes
processes.

Most of us are also involved with SIG Network of course, and
interaction must be regular and communication free-flowing between the
two. This WG is not meant to be isolated from or duplicative of SIG
Network efforts in any way.

Why not in SIG Network?
-----------------------
When these discussions were happening in SIG Network, we got little
done, both from a SIG Network and a multi-network standpoint. Let's
leave SIG Network tactical and focused on larger, higher level network
issues. And make the WG laser focused on the goals above.


Happy to address any questions or clarify anything above. Just ask!

Dan

[Bowei Du]

Hi Dan, 

Will the discussion mailing list be sig-network or a working group only channel?

Bowei

Dan

--
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.
For more options, visit https://groups.google.com/d/optout.

[Ed Warnicke]

Dan,

Question, since most of the use cases I've seen are related to NFV... why not an NFV working group?

Ed

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.

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 Williams]

On Wed, 2017-12-13 at 16:31 +0000, Ed Warnicke wrote:
> Dan,
>
> Question, since most of the use cases I've seen are related to NFV...
> why
> not an NFV working group?

They aren't just limited to NFV. The other two we have are storage
networks and media streaming, which share some commonality with NFV,
but the workloads are different and the apps are typically architected
differently as well.

That said, I think there are common solutions for all three.

[Dan Williams]

On Tue, 2017-12-12 at 23:48 -0800, 'Bowei Du' via kubernetes-sig-

network wrote:
> Hi Dan,
>
> Will the discussion mailing list be sig-network or a working group
> only
> channel?

Good point, forgot that. I think we can stay with sig-network for now.

Dan

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

[kman...@solarflare.com]

I'd like to be involved.  I'll struggle to make the bi-weekly call due to timezone differences but if there's a slack channel where things will be discussed I'll join that.

My specific interest is in how we can accelerate networking using device plugins but multi-network is I think a key step towards that.

In addition to the goals you've already outlined, it might be useful to enumerate the key problems or challenges that need to be addressed to reach those goals.  I would find it much easier to contribute where there are specific tasks, especially if there is some agreement that those are the right tasks to be doing.

Thanks for taking the initiative to get this moving.

Kieran

[Guru Shetty]

I have tried to experiment with multi-networking with k8s - i.e use k8s to do what  AWS  cloud provide their customers - network isolation. The general idea being can k8s be used to orchestrate multi-tenant infrastructure. The biggest road-block I face is always the kubelet's health-check requirements over IP address. Unless that issue gets resolved or if anyone already has some ideas, network virtualization looks hard.

--

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.

[Peter Zhao]

Hi Dan,

Thanks for starting the working group. I'd like to join the effort again in this new way. I believe the working group will push things forward more effectively.

We (ZTE) also have a CNI plugin (not yet opened source, but hopefully soon) which supports multiple-network. It supports the NFV cases well and is working in our internal project. It's kinda like a "thick" plugin as you once mentioned in former discussions in the mailing list. Hopefully it can help with ideas to form the  "standard" multi-sidecar-network CNI plugin.

Peter Zhao

[Antoni Segura Puimedon]

On Thu, Dec 14, 2017 at 5:58 PM, Guru Shetty <guru...@gmail.com> wrote:
> I have tried to experiment with multi-networking with k8s - i.e use k8s to
> do what AWS cloud provide their customers - network isolation. The general
> idea being can k8s be used to orchestrate multi-tenant infrastructure. The
> biggest road-block I face is always the kubelet's health-check requirements
> over IP address. Unless that issue gets resolved or if anyone already has
> some ideas, network virtualization looks hard.

Couldn't the CNI daemon running on the machine be responsible for putting
an interface (or l3 connectivity) to each of the isolated networks and
allow only
established and outgoing traffic from this IP used by the kubelet for
the probes?

>
>
> On 14 December 2017 at 07:17, <kman...@solarflare.com> wrote:
>>
>> I'd like to be involved. I'll struggle to make the bi-weekly call due to
>> timezone differences but if there's a slack channel where things will be
>> discussed I'll join that.
>>
>> My specific interest is in how we can accelerate networking using device
>> plugins but multi-network is I think a key step towards that.
>>
>> In addition to the goals you've already outlined, it might be useful to
>> enumerate the key problems or challenges that need to be addressed to reach
>> those goals. I would find it much easier to contribute where there are
>> specific tasks, especially if there is some agreement that those are the
>> right tasks to be doing.
>>
>> Thanks for taking the initiative to get this moving.
>>
>> Kieran
>>
>> --
>> 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.

>> 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.

[Guru Shetty]

On 15 December 2017 at 00:18, Antoni Segura Puimedon <cele...@gmail.com> wrote:

On Thu, Dec 14, 2017 at 5:58 PM, Guru Shetty <guru...@gmail.com> wrote:
> I have tried to experiment with multi-networking with k8s - i.e use k8s to
> do what  AWS  cloud provide their customers - network isolation. The general
> idea being can k8s be used to orchestrate multi-tenant infrastructure. The
> biggest road-block I face is always the kubelet's health-check requirements
> over IP address. Unless that issue gets resolved or if anyone already has
> some ideas, network virtualization looks hard.

Couldn't the CNI daemon running on the machine be responsible for putting
an interface (or l3 connectivity) to each of the isolated networks and
allow only
established and outgoing traffic from this IP used by the kubelet for
the probes?

Right. But by default kubelet assumes that there is only one IP per pod. So it will try to health check on your primary IP. There should be a change in kubelet to have a secondary IP for health-check to be acceptable, right? If you already have ideas to work-around it, I would really like to hear. 

>
>
> On 14 December 2017 at 07:17, <kman...@solarflare.com> wrote:
>>
>> I'd like to be involved.  I'll struggle to make the bi-weekly call due to
>> timezone differences but if there's a slack channel where things will be
>> discussed I'll join that.
>>
>> My specific interest is in how we can accelerate networking using device
>> plugins but multi-network is I think a key step towards that.
>>
>> In addition to the goals you've already outlined, it might be useful to
>> enumerate the key problems or challenges that need to be addressed to reach
>> those goals.  I would find it much easier to contribute where there are
>> specific tasks, especially if there is some agreement that those are the
>> right tasks to be doing.
>>
>> Thanks for taking the initiative to get this moving.
>>
>> Kieran
>>
>> --
>> 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.
>> 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-network+unsub...@googlegroups.com.

> To post to this group, send email to

> kubernetes-sig-network@googlegroups.com.

[Tim Hockin]

Adding multiple IPs to Pod is something we should support.

>> >> 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.

>> > 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.

[Ed Warnicke]

Tim,

Do you have thoughts on what that might look like?  I know for example for dual stack v4/v6 its going to be needful, how would that look in the Kubernetes Networking APIs?  Does 'ip' simply become a list rather than a scalar?

[Tim Hockin]

There are some proposal open regarding this. It can't literally
change type, and we probably need to decorate IPs with metadata like
"use this for liveness probes".

https://github.com/kubernetes/kubernetes/issues/27398

[Dan Williams]

Hi,

Tentative agenda for Thursday's meeting is at:

https://docs.google.com/document/d/1oE93V3SgOGWJ4O1zeD1UmpeToa0ZiiO6LqRAmZBPFWM/edit?usp=sharing

Feel free to add more stuff, and tag it with your name. I don't expect
to get a ton solidified or done due to the upcoming break that many of
us have. But let's get a short-term plan nailed down if we can.

See you Thursday @ 14:00 US Pacific, SIG Network Zoom account.

Dan

[Yaniv Lavi]

Hi,

I would appreciate a EMEA friendly meeting time zone as well (at least for some of the meetings).

Would that be possible?

Thanks,

Yaniv

[mspr...@us.ibm.com]

Thanks for kicking this off.  I would like to participate.

Thanks,
Mike

[akshya.p...@gmail.com]

Dear Sir ,

    I am doing plumbing work please ad my mobale no 9036214928