s1061123
commented
2 years ago Hi Abderaouf,
Thank you for your comments. Simply to answer, currently this implementation works with MACVLAN (we will create demo movie which creates nginx service in macvlan network soon). Kube-proxy adds iptables rules in container host but multus-proxy adds iptables in pod network namespace as you see the code. In addition, multus-service does not introduce any new type of object (CR) yet.
Currently this repository is not mainly for end-users because it is not matured. In addition, unfortunately, we don't have a resource that creates resources (e.g. document) for end-users/beginners (of container networking). After hardening of the code and bugfixing, then we could focus on such resources as our priority, I hope.
So please wait in patience until the repository get matured.
Hello,
I am following up on the discussion https://github.com/k8snetworkplumbingwg/multus-cni/issues/466.
If I understand correctly, you intend to develop a tool similar to kube-proxy to put the network rules on the different Pods. I would like to know how you intend to solve the problem of CNI plugins that do not allow the host to communicate with the interface created on the Pod (e.g. MACVLAN).
For me, I saw another method which consists in implementing only a controller which looks at a new type of object (CR). Depending on the content of CR, the controller creates a K8s service without label selector + endpoints resource. The controller continues to look, for each CR, at the Pods that have the labels defined in that CR and their additional interfaces update the endpoints resource. Load balancing and other features will be ensured then by kube-proxy. The problem with this method is that it doesn't work (I think) for example with MACVLAN interfaces where the host can't use the master interface to reach the interface on the Pod.
Best regards, Abderaouf