Extract iptables binary staging to iptablesutils

[juanluisvaladas]

Description

CPLB potentially will need to create some iptables rules for its userspace proxy, hence this code should be in iptablesutils rather than pkg/worker/kubelet.
Fixes # (issue)

Type of change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update

How Has This Been Tested?

• Manual test
• Auto test added

Checklist:

• My code follows the style guidelines of this project
• My commit messages are signed-off
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules
• I have checked my code and corrected any misspellings

[juanluisvaladas]

Hi Tom, I came back to this and I started doing but I realized kubelet needs both the iptables binaries (which isn't a problem) and an iptables mode (which is either nft or legacy).

If we move the iptables binary staging, to a new component we need to gather this information from the iptables component to the kubelet component. We can set this field in the iptables.Init phase and pass it to kubelet before calling componentManager.Start but that means that we either have to:

1- Add some code between the calls of componentManager.Init and componentManager.Start
2- Other option would be giving the kubelet component a pointer to the iptables but I'm not a big fan of that.
3- Don't make a new component.

Option 1 is probably the cleanest so I implemented it.. Do you have any preference?

[twz123]

If we move the iptables binary staging, to a new component we need to gather this information from the iptables component to the kubelet component.

After looking at the kubelet component, I think the only reason the component needs to know the iptables mode is because it currently extracts the iptables binaries. So if we put that in its own component, I don't see any reason why the kubelet component would need to know about the iptables mode anymore. I'd do something along those lines:

type IPTablesSetup struct {
	IPTablesMode string
	// ...
}

func (i *IPTablesSetup) Init(context.Context) error  { /* Gather iptables mode, extract binaries */ }
func (i *IPTablesSetup) Start(context.Context) error { /* No-op, probably? */ }
func (i *IPTablesSetup) Stop() error                 { /* No-op, probably? */ }

The IPTablesMode in the kubelet component can then be dropped.

1- Add some code between the calls of componentManager.Init and componentManager.Start
2- Other option would be giving the kubelet component a pointer to the iptables but I'm not a big fan of that.
3- Don't make a new component.

Option 1 is probably the cleanest so I implemented it.. Do you have any preference?

Fortunately, as far as I can see, we won't need any of the above here. However, there's already precedence for the second approach in k0s.

[juanluisvaladas]

You're right, fixed.

[twz123]

I've left some proposals. I'd have approved this PR already, but since it's auto-merge, I just commented. Just ping me if you want me to approve this.

[twz123]

If there was a BinDir struct field instead of the K0sVars struct field here, it would be immediately obvious that this component only needs the k0s bin dir from the config, nothing else.

[twz123]

This function could become private now.

[twz123]

I'd just declare the logger once log := logrus.WithField("component", "iptables") and then use it in lines 47 and 54. I'd also drop constant.IptablesBinariesComponentName from constants.go and inline it here. It's only required once here. The component constants mainly exist to support the --disable-components flag. I'd keep the struct name and the component name in sync.

[twz123]

We could also name this Component to make it clear that this is the component: iptables.Component reads a bit nicer than iptables.IPTables IMO.

[juanluisvaladas]

These are good suggestions so I modified the code accordingly. I also squashed both commits into one because it doesn't really add value to have two.

[k0s-bot]

Successfully created backport PR for release-1.31:

• [Backport release-1.31] Extract iptables binary staging to iptablesutils #5282