Closed rhelmot closed 6 months ago
Isn't there a way to know in runtime this limitation and enable iptables-legacy
in that case?
I don't know if this may break something.
I'm not sure. The iptables-nft man page claims it works on linux >= 4.17, but my minikube vm is 5.10 and it's not working there. I'm also not sure if there's a non-destructive probe command that could be use to experimentally detect whether it's working.
Generally, linux has an excellent backwards compatibility policy for syscalls and kernel APIs, so I think iptables-legacy itself will work for the forseeable future. The only question is whether there are user applications which depend on newer features of iptables-nft. Docker itself doesn't seem to depend on any of these newer features, but any applications based on this image may break.
I think this is acceptable, because any developer who actively wants to maintain a working environment will pin their image versions, and possibly even their container hashes. I only discovered that this was a problem when I unpinned my images and was prepared to experience the consequences :)
Agh, I am a bit sleepy and I put a comment from the PR in the commit message...
Anyways, you've conviced me :).
This will be available when Docker releases a new version.
Reminder to everyone who reaches this PR that you need at least 7 hours of sleep per day:
@rhelmot There is a new release with this PR included: https://github.com/cruizba/ubuntu-dind/releases/tag/25.0.4-r0
Previously, these images would fail to run on minikube with the kvm2 backend:
If there's other host configurations that fix this, I will gladly close this PR and do that instead, but this fixes the issue with no side effects as far as I can tell.