Statically link CNI plugins

[dims]

Picking a release of cni plugins and inspecting the binaries shows that they are statically linked. So we should do the same.

Following up to a multus-cni testing issue:

• update deploy file: use install_multus bin to update cni file k8snetworkplumbingwg/multus-cni#1213 (comment)
• update deploy file: use install_multus bin to update cni file k8snetworkplumbingwg/multus-cni#1213 (comment)

$ find . -type f | xargs file | grep executable | cut -f 1-4 -d ','
./vrf:                                   ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked
./host-device:                           ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked
./vlan:                                  ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked
./portmap:                               ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked
./dhcp:                                  ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked
./sbr:                                   ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked
./firewall:                              ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked
./tuning:                                ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked
./host-local:                            ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked
./tap:                                   ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked
./bridge:                                ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked
./macvlan:                               ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked
./bandwidth:                             ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked
./ptp:                                   ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked
./ipvlan:                                ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked
./static:                                ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked
./loopback:                              ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked
./dummy:                                 ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked

[dims]

/assign @aojea @BenTheElder

[stmcginnis]

/lgtm

[aojea]

It seems we already discussed this in the original PR #3214 (comment) , can't remember why we did one and not the other since there should not be any requirement on the plugins to use cgo
/assign @BenTheElder

[BenTheElder]

It seems we already discussed this in the original PR #3214 (comment) , can't remember why we did one and not the other since there should not be any requirement on the plugins to use cgo

IIRC we were matching the upstream builds at the time?

Not using CGO makes DNS weird, for things "on the host" we generally build with cgo, unless they're not using the network.

I think none of the CNI plugins should need to use DNS though?

[BenTheElder]

Following up to a multus-cni testing issue:

So, to be clear though: https://kind.sigs.k8s.io/docs/design/node-image/

DO NOT DEPEND ON THE INTERNALS OF THE NODE IMAGES.

statically linking these seems ~ok given upstream is and we're not aware of a specific need to dynamically link these binaries

(also we should consider deleting the ones we're not using, but lets do that separately)

... but I generally expect CNI installs to ship their own binaries and not depend on ours, the same as installing on metal etc.

Commented in k8snetworkplumbingwg/multus-cni#1213 (comment)

That shouldn't block matching the upstream binaries though, we don't have a strong reason to deviate in that regard.

[BenTheElder]

NOTE: We're also not currently releasing at the moment due to being part way through sorting out containerd 2.0

kubernetes/kubernetes#129818 / containerd/containerd#11323 / #3795 / containerd/containerd#11344 / #3853

[BenTheElder]

/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: BenTheElder, dims

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [BenTheElder]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment