Replace kubernetes mount code with utils

[justinsb]

This will remove one of the main dependencies on the kubernetes/kubernetes repo.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: justinsb

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 [justinsb]

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

[geojaz]

None of us love k/k deps, but right now, someone else is theoretically taking care of this for us. Are we gaining anything other than a somewhat smaller binary?
I'm not opposed to simplifying deps. But even here, there are bits and pieces that are out of sync (boilerplates, spacings, renames, etc), that seem to increase our scope. Feel free to educate me :)

[johngmyers]

/test pull-kops-verify-staticcheck

[justinsb]

@geojaz you're quite right - I should have pointed out the big problem. It was removed from k/k in kubernetes/kubernetes#81843 . It's also vastly overcomplicated for what we're actually using it for, so I think it's a net win for us, even if our hand is being forced.

[hakman]

I see Protokube is using nsenter for running systemd commands. Seems to me that most of the namespace changing job is done by starting the Protokube container as privileged in parent pid namespace.
I did some experiments at some point and, replacing nsenter with a simple chroot worked fine. Maybe it's worth exploring at some point.

kops/nodeup/pkg/model/protokube.go

Lines 226 to 228 in 0b52b99

	"--net=host",
	"--pid=host", // Needed for mounting in a container (when using systemd mounting?)
	"--privileged", // We execute in the host namespace

[justinsb]

@hakman that is interesting ... and maybe we can simplify things further. If I recall correctly, the complexities are whether the filesystem namespace is the same and whether there are helpers we need to run (e.g. mkfs.ext4). As it stands, this should be mostly importing just the bits of the k/k code we need (I think), and then maybe we can try to simplify it?

I think protokube isn't actually doing much with mounting any more (for users that are running recent k8s), because most of the mounting is now done in etcd-manager. etcd-manager actually has an easier problem because we don't need the volume to be visible outside the pod because it runs etcd in the same pod (though that does have its own challenges, like having to ship multiple etcd versions). So it would be good to look into simplifying this code!

[rifelpet]

/lgtm