support for network policy GA about kube-router HOT 5 CLOSED

Have you ever tested kube-router in Flannel with Vxlan backend and can kube-router preserve the source pod IP?

from kube-router.

@m1093782566 i am answering to questions in #21 as well here

IPVS has no conflict with encapsulation used. From IPVS perspective, all it needs is reverse traffic goes through IPVS director so that traffic reaches the source pod (after performing DNAT). This is no different from the requiremetns of kube-proxy.

I tested some time back, but will test again the combination of Flannel + Kube-router providing IPVS service proxy and network policy. I will update the thread after re-testing.

Just so you know Canal has Flannel VXLAN + iptables Kube-proxy + Calico network policy. I dont think it has any issues with source IP not being preserved.

from kube-router.

@m1093782566 I just tested with Flannel VXLAN + Kube-routers service proxy and network policies, i dont see any issue with VXLAN encapsulation + IPVS.

from kube-router.

Quick notes on what changed with 1.7 GA of network policy compared to beta of NP(network policies). Kube-router currently implements Beta NP.

• By default, pods are non-isolated; they accept traffic from any source. (this is the behaviour in Beta of NP till 1.6 as well.) Current implemention of Kube-router honours this now. So no change is required.

• Annotation to network policy to default deny has no significance in the NP GA. In Beta NP and current implementation of Kube-router adding a annotation to namespaces to default deny, puts all the pods in the namespace isolated. So kube-router behaviour needs to change dependeing on kubernetes server version. If kubernetes is ver 1.7 then kube-router needs to ignore [namespace network plocy annotation] (http://blog.kubernetes.io/2016/04/Kubernetes-Network-Policy-APIs.html) even if its configured.

• Pods become isolated by having a NetworkPolicy that selects them. Once there is any NetworkPolicy in a Namespace selecting a particular pod, that pod will reject any connections that are not allowed by any NetworkPolicy. Current implementation in kube-router should be able to handle this change, with no modification.

• Other pods in the Namespace that are not selected by any NetworkPolicy will continue to accept all traffic. This is big change from Beta GA. Pods not selected by any network policy continue to accept traffic.

Overall semantic changes from NP Beta to 1.7 GA shoule be easily adopted. Only part that is little challenging is to support both NP Beta and GA version. Or may be just implement for network policy GA semantics, and suggest users if they want to use Kube-router for network policy then use Kuberetes 1.7

from kube-router.

Spent some time analyzing the effort and changes needed. It seems its wise to hold on this for a while. Though changes required are lot lesser than i thought, i see potential re-work due to client-go, api repos are in flux. Its better to wait a bit and see direction client-go goes. It looks like client-go will use api repo post 4.0 release, which will force kube-router to use api, which is good as its going to be canonical location of the Kubernetes API definition.

Anyway, 1.7 is still backward compatible, so beta network policies still can be used.

from kube-router.