-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rootless: Add abillity to select port driver #6488
Comments
We bundle slirp4netns, if we're not using it then I'm not sure why we include it. |
RootlessKit is used for ingress traffic, slirp4netns is used for egress traffic. So slirp4netns is not removable |
So would this need to be configurable on an ingress/egress basis? We also have a request in another issue to allow configuring the MTU. It would be nice if there was a way to allow all of this without adding a bunch more flags. |
Check out the PR I just merged. You should be able to use a commit build from the installer once CI is done. |
@AkihiroSuda with the changes from that PR, I am now able to run both server and agent on the same node in different rootless user units. Unfortunately, they both end up having the same address by default unless I manually change the slirp4netns CIDR block to something unique for each of them. Can you think of a better way to handle this? brandond@dev01:~$ kubectl get node -A -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
k3s-server Ready control-plane,master 3m31s v1.25.4+k3s-b09dea28 10.41.0.100 <none> Ubuntu 22.10 5.19.0-1011-aws containerd://1.6.8-k3s1
k3s-agent Ready <none> 2m58s v1.25.4+k3s-b09dea28 10.41.0.100 <none> Ubuntu 22.10 5.19.0-1011-aws containerd://1.6.8-k3s1 Even after doing that, I have other problems... I need to override the server's advertise-address to the node's actual IP in order for the agent to connect properly, and even after doing that metrics-server doesn't work right because the node IPs cannot route to each other. I suspect flannel isn't routing pod-to-pod traffic between nodes correctly either. I guess that in order to make this work properly, there would need to be some way to forward traffic between tunnel interfaces? I have no idea where to even begin with that. There is also the larger issue of making this work across multiple hosts, which I think would have a bunch of challenges that I haven't even thought of yet. |
Maybe hash the username into the CIDR ?
Flannel (VXLAN) is known to work with rootless, but not integrated to rootless k3s yet. |
What about routing between multiple user namespaces on the same host? I see that the slirp4netns docs mention needing to use an external tool like vde_plug to make this work between instances; would it be possible to somehow get k3s to share the slirp4netns instance instead? |
Theoretically yes, but not implemented yet. |
Not implemented on the rootlesskit side, or just not in K3s yet? If it just needs some work on our side I'm glad to continue poking at it. |
Maybe we should add an optional support for This assigns the "real" IP address that is accessible from other user namespaces, but needs to configure |
##Environment Details Infrastructure
Node(s) CPU architecture, OS, and version:
Cluster Configuration:
k3s-rootless.service
Default k3s-rootless.service output
Results:
Additional Environment Variables k3s-rootless.service output*attn to service file's additional Environment variables at the top*Validation Steps
$ systemctl --user status k3s-rootless
Additional context / logs: it appears we aren't using builtin by default so I'll confer on that and either patch the docs or see if we can get a fix. |
Is your feature request related to a problem? Please describe.
It seems to not be possible to get the source ip of ingress traffic in rootless mode.
Describe the solution you'd like
Currently K3s is always using the builtin port driver of rootlesskit. According to https://github.com/rootless-containers/rootlesskit/blob/1920341cd41e047834a21007424162a2dc946315/docs/port.md, this driver does not support the propagation of source ip addresses. slirp4netns would support this but is slower. The user should be able to make the decision for this tradeoff.
Describe alternatives you've considered
Inspecting the traffic outside of the cluster.
Additional context
https://github.com/rootless-containers/rootlesskit/blob/1920341cd41e047834a21007424162a2dc946315/docs/port.md
k3s/pkg/rootless/rootless.go
Line 173 in 483eadb
k3s/pkg/rootless/rootless.go
Line 197 in 483eadb
This is a copy of #5405 because a bot closed that one incorrectly.
The text was updated successfully, but these errors were encountered: