After taking another look at it, I realized that the hairpin controller that I had originally created to ensure that hairpin mode was enabled on the pod's network namespace link was entirely superfluous. Instead, user's should be using the little known hairpinMode of the bridge CNI plugin for kube-router.
This plugin is already in the pod's network namespace when it needs to run and is much more reliable than the controller that I created.
For now I'm leaving the code, but just removing references to it so that I can bring it back in the future if I decide that its helpful. However, it had quite a few problems with it, as mentioned in #1630.
I've also updated the dsr reference daemonset to include this mode, as I'm not sure why this was left out in the first place. The docs in the user-guide mention this CNI option quite a bit already, so it was already well documented there.
aauren
commented
7 months ago
After taking another look at it, I realized that the hairpin controller that I had originally created to ensure that hairpin mode was enabled on the pod's network namespace link was entirely superfluous. Instead, user's should be using the little known
hairpinModeof the bridge CNI plugin for kube-router.This plugin is already in the pod's network namespace when it needs to run and is much more reliable than the controller that I created.
For now I'm leaving the code, but just removing references to it so that I can bring it back in the future if I decide that its helpful. However, it had quite a few problems with it, as mentioned in #1630.
I've also updated the dsr reference daemonset to include this mode, as I'm not sure why this was left out in the first place. The docs in the user-guide mention this CNI option quite a bit already, so it was already well documented there.