LGTM label has been added.

dep mechanics lgtm (and unit/integration compatibility tests show we still pass tests with original minor version go release, which is good)

My understanding is that #117647 is caused by mismatched versions of the libcontainer library between kube and the runc binary used. Do the changes in this PR cause any issues with mismatched versions in the opposite direction if a runc binary older than 1.1.6 is used?

also, is there a test demonstrating #117647 is fixed with this change, and doesn't regress the currently working cgroupv2 combinations?

My understanding is that #117647 is caused by mismatched versions of the libcontainer library between kube and the runc binary used. Do the changes in this PR cause any issues with mismatched versions in the opposite direction if a runc binary older than 1.1.6 is used?

Good question. The answer, to my best understanding, is definitely not.

The problem is caused by 1.1.6+ runc binary adding a misc cgroup controller directory which older runc/libcontainer used by kubelet doesn't know about (and thus can't remove). Using an older binary (which does not create misc controller directory) with a newer vendored runc/libcontainer is fine -- missing controllers are ignored.

also, is there a test demonstrating #117647 is fixed with this change, and doesn't regress the currently working cgroupv2 combinations?

If there is, I am not aware. A problem like this is very rare (and ultimately is caused by cgroup v1 idiosyncrasy of having a forest, rather than a tree, of controller hierarchies), and I don't know if there's a test that tries various runc releases.

It would be nice to have though (as well as testing the runc from the main/HEAD).

/lgtm

/approve
per #117691 (comment) and node lgtm

Somewhat unreasonable problem to tackle: I guess KIND is going to have fun with older releases and cgroups v1 as we roll out runc 1.1.6 🙃, we don't currently use older runc for older kubernetes and changing that won't be easy.

How far can we reasonably backport this?

I guess KIND is going to have fun with older releases and cgroups v1 as we roll out runc 1.1.6

this PR doesn't require runc 1.1.6, if I understand #117691 (comment) correctly

/hold just to double-check my understanding in #117691 (comment) is correct

@kolyshkin?

I mean the opposite: runc 1.1.6 requires this PR and not upgrading runc means missing CVE patches?

For tools like CAPI I assume we can do something like forcing cgroupsv2 but we should probably ping cluster lifecycle about the implications of patching runc.

KIND updated to 1.1.6 shortly after release and I didn't realize we'd have this problem and for that particular tool we don't control the kernel / host cgroups

I mean the opposite: runc 1.1.6 requires this PR and not upgrading runc means missing CVE patches?

oh. I'm not sure, but my understanding is that whether runc improves interop with previous versions of this library or not, this is an ok bump to take

agreed, I was asking if we will backport this further / how far, and now also if we're in contact with the owners of in-project cluster tools (CAPI, kOps, kubespray, minikube, ...) regarding the compat issue, I would guess most of them have been upgrading due to CVEs and may not be aware of the problem this PR intends to solve

/hold cancel

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: dims, liggitt, samuelkarp, xmudrii

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

The pull request process is described here