Pod to service communication when using macvlan or ipvlan

29 views
Skip to first unread message

Surya Teja Palavalasa

unread,
Sep 27, 2017, 7:40:36 AM9/27/17
to Kubernetes developer/contributor discussion
Hi,
In the present iptables service proxy mode for a pod to contact a service via the virtual ip the pods traffic should go through the iptables stack of the host machine, And i feel that assming that the network packet from the pod will go through the ip stack is not correct. In case of using macvlan or ipvlan to orchestrate container networking, the pod to service communication wont work. we could use some hacks to get it to work (routing vip to a specific host which does the dnat and masquerade) but there should be some clean solution for this.

Tim Hockin

unread,
Sep 27, 2017, 2:55:02 PM9/27/17
to Surya Teja Palavalasa, Kubernetes developer/contributor discussion
You're right. The default networking mode does this, and the default
Services implementation assumes it. If you want to use something like
macvlan, you need a different way to implement Services.
> --
> You received this message because you are subscribed to the Google Groups
> "Kubernetes developer/contributor discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to kubernetes-de...@googlegroups.com.
> To post to this group, send email to kuberne...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/kubernetes-dev/843fe59d-9030-4ab9-8fef-400cf7324f46%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Surya Teja Palavalasa

unread,
Sep 28, 2017, 2:16:13 AM9/28/17
to Kubernetes developer/contributor discussion
Is there a workaround for this

Tim Hockin

unread,
Sep 28, 2017, 1:51:46 PM9/28/17
to Surya Teja Palavalasa, Kubernetes developer/contributor discussion
This is not a "workaround" it's part of the overall product. There
are several options which need to be explored and developed.

You could have a second interface in each pod that sends Service
traffic to the rootns, and everythign else out the main interface.
That's not ideal.

You could program iptables in each leaf namespace, which hurts because
iptables programming is not cheap at scale.

You could wait for IPVS and do IPVS in each leaf namespace. This is unexplored.

You could have your service VIPs terminate at a real load-balancer.

On Wed, Sep 27, 2017 at 11:16 PM, Surya Teja Palavalasa
<palavalasas...@gmail.com> wrote:
> Is there a workaround for this
>
> --
> You received this message because you are subscribed to the Google Groups "Kubernetes developer/contributor discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-de...@googlegroups.com.
> To post to this group, send email to kuberne...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/c90e51ab-fbff-4303-a766-e43c6af205ac%40googlegroups.com.

Mike Danese

unread,
Sep 28, 2017, 2:37:47 PM9/28/17
to Tim Hockin, Surya Teja Palavalasa, Kubernetes developer/contributor discussion
Another one:

You can run kube-proxy on a separate, dedicated pool of nodes. Route
the service CIDR to these nodes. Adds a hop and is also unexplored.

On Thu, Sep 28, 2017 at 10:51 AM, 'Tim Hockin' via Kubernetes
developer/contributor discussion <kuberne...@googlegroups.com>
wrote:
> To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAO_RewbjT-fF7WLNnj3jQoWtoN2uLPwP6Eihke-YWnm27XGqbw%40mail.gmail.com.
Reply all
Reply to author
Forward
This conversation is locked
You cannot reply and perform actions on locked conversations.
0 new messages