| kata-irc-bot | <hzt731tim> @me1533 @eric.ernst It's not open source. We only need the guest kernel to support ipvs, but we need customer guest image. The binary for ipvsserver will be wrap into the image. When the vm start up, the server will start to listen. Right now, we cannot handle iptables | 01:37 |
|---|---|---|
| kata-irc-bot | <hzt731tim> @eric.ernst I got a question for your solution. I saw you handle iptable operations via command line on shim. How did you interacting with k8s? | 01:43 |
| kata-irc-bot | <me1533> @hzt731tim right now we’re using an on node agent that will listen for updates to an iptables ConfigMap for each VirtualCluster and if there is a pod on the node from a VirtualCluster and the ConfigMap gets updated it will push the rules through the kata shim | 02:37 |
| kata-irc-bot | <hzt731tim> Our solution requires the corresponding functionality in kube-proxy. I assume you don't want to modify kube-proxy, because you push the rules through kata shim. | 02:52 |
| kata-irc-bot | <hzt731tim> I am still confusing how did trigger the operation for iptables. I read the pr, it seems you try to trigger the operation through command-line. | 03:05 |
| kata-irc-bot | <eric.ernst> That's as an example | 03:06 |
| kata-irc-bot | <eric.ernst> In practice, you'd send a http request to the shim’s UDS | 03:06 |
| kata-irc-bot | <eric.ernst> essentially matching what is done in the kata-runtime binaries handler for get/set (make an http GET or PUT at the endpoint) | 03:07 |
| kata-irc-bot | <eric.ernst> The tricky part is calculating the path of the UDS, and needing to know the sandbox ID | 03:08 |
| kata-irc-bot | <eric.ernst> Chris’ll need to share more on the kube proxy side. I'm just the plumber :) | 03:12 |
| kata-irc-bot | <hzt731tim> Which module is going to be the client to do the http request? | 03:27 |
| kata-irc-bot | <me1533> > assume you don’t want to modify kube-proxy, because you push the rules through kata shim. Yes, specifically cause we want the entire virtualclusters IPTables rules which is why we write them in separate kata container with higher privs using kube-proxy, then save the rules and push them to the configmap and then on the node we don’t run kube-proxy at all, we just have our configmap listener which gets the UDS from the CRI and then w | 03:47 |
| kata-irc-bot | talk to the kata shim over HTTP to supply those rules so which will write them into the guest. | 03:47 |
| kata-irc-bot | <me1533> > Which module is going to be the client to do the http request? this is our on node network agent. | 03:54 |
| kata-irc-bot | <bergwolf> @eric.ernst Regarding copying the host netns iptables rules, have you considered this? https://github.com/kata-containers/kata-containers/issues/4080#issuecomment-1137002953 | 09:25 |
| kata-irc-bot | <eric.ernst> In my case though (and all I think), we'd want to reflect iptable rules that would otherwise be in the pod namespace. | 13:52 |
| kata-irc-bot | <eric.ernst> What do you think? | 16:38 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!