Package fixes for enabling br_netfilter & ip_forward with kubeadm

[sysrich]

What this PR does / why we need it:
For any rpm distribution using our reference .spec files it will include the appropriate configuration to probe the br_netfilter module automatically and enable IP forwarding.

These are mandatory by kubeadm (it fails fatally if this is not configured), but only the Docker CRI runtime satisfies this requirement automatically.

As they're mandatory in kubeadm, they can and should be configured automatically as part of the installation of kubeadm. This will improve kubeadms support for any CRI runtime besides Docker (eg. CRI-O)

The is the upstream aligned variation of openSUSE's equivalent changes here: https://build.opensuse.org/package/rdiff/devel:kubic/kubernetes?linkrev=base&rev=9

Which issue(s) this PR fixes
Fixes kubernetes/kubeadm#1062

Release note:

NONE

[sysrich]

/assign @mikedanese

[sysrich]

/sig cluster-lifecycle

[sysrich]

/kind bug

[timothysc]

/cc @chuckha @detiber
/ok-to-test
/assign @ixdy

[timothysc]

@sysrich - Just an FYI but these are not the canonical rpms/debs for the release.

[chuckha]

I think this is divergent from the actual release repo, however they have been slowly drifting apart.

I wonder if we need a discussion about the future of maintaining these bazel builds.

That being said, if you're using bazel artifacts, these are good changes.

[mikedanese]

Can we give the conf files more intuitive names?

[sysrich]

/test pull-kubernetes-verify

[sysrich]

@mikedanese what would you consider as more intuitive?

I followed the naming convention you typically see in the folders in question, in the case of modules-load.d you typically see the conf file named after the "reason this config file exists". In sysctl.d you typically see the conf file named similarly, with a priority version in front of it, with 50- being typical for things provided by distribution packages

That said, I get the names look weird outside of the context of the installed system.
We could call the files something different in git/packaging and then using the spec to install them with the above naming convention.
To do that, I'd be more comfortable with that if we used a more verbose, openSUSE-style of spec file, where we explicitly list additional files in SourceXXX: declarations, and then reference those as %{SourceX} when installing/renaming them.

Which is a route I'd be perfectly happy to submit - will be less simple and straightforward than the current specfiles and their implicit %{Filename} approach, but less work for me to rebase with what I'm doing in openSUSE.

[rosti]

I like this, although strictly speaking, this should probably be done by the CRI packages (Docker does it for instance).
On the other hand, having this here certainly improves kubeadm UX with non-Docker CRIs.

/area kubeadm

[mikedanese]

Whatever is reasonable.

/lgtm

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: mikedanese, sysrich

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:

• build/rpms/OWNERS [mikedanese]

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