Update runc to v1.1.7

[hakman]

No description provided.

[justinsb]

Awesome - fingers crossed that this now works after the gce CSI update :-)

[hakman]

Awesome - fingers crossed that this now works after the gce CSI update :-)

Unfortunately, it looks like it's still failing...

[hakman]

/test pull-kops-e2e-k8s-gce-ci

[hakman]

/test pull-kops-e2e-k8s-gce-ci

[hakman]

/test pull-kops-e2e-k8s-gce-ci

[hakman]

/test pull-kops-e2e-k8s-gce-ci

[hakman]

Most likely related to opencontainers/runc#3849.
Should be fixed with the next K8s patch releases.

[hakman]

@anthonyhaussman ^^^

[hakman]

/hold

[BenTheElder]

FWIW, I've been considering what to do in KIND, and it seems we have some other unrelated problems, but only 1.24+ will get the k8s patch so runc 1.1.6+ currently will break anyone on cgroups v1 and <1.23, seems like this should be held for a bit? 1.1.5 had the CVE fixes.

Unless I'm mis-reading https://kops.sigs.k8s.io/welcome/releases/

The latest Kubernetes minor version supported by a kOps release is the one matching the kOps version. E.g for kOps 1.25, the highest supported Kubernetes version is 1.25. From that version, kOps additionally support Kubernetes two additional minor versions. In this case 1.24 and 1.23. To ease migration, kOps also supports two more minor versions that are considered deprecated. Bugs isolated to deprecated Kubernetes versions will not be fixed unless they prohibit upgrades to supported versions. kOps users are advised to run one of the 3 minor versions Kubernetes supports.

(I'm actually just interested in how kOps will handle this, as some degree of precedent for other projects with the same problem)

[hakman]

@BenTheElder kOps doesn't have strict control on the patch versions that operators use. We may have to start set the requiredVersion in channels, or go even further and make it an error when someone configures an older K8s version with runc v1.1.6+.
It's not yet clear how will future K8s releases deal with older containerd + runc versions.

For sure we will have to hold back containerd + runc for older K8s versions, as you suggested.

Regarding the mention that CVEs were fixed in v1.1.5, that's true for now. There will be other CVEs, so holding back is not ideal.

We were hesitant of switching the default base image to Ubuntu 22.04 with cgroup v2, but this issue may finally give us a good reason to switch.

[hakman]

/test all

[hakman]

/test pull-kops-e2e-cni-cilium-etcd

[hakman]

/test pull-kops-e2e-cni-amazonvpc
/test pull-kops-e2e-cni-calico

[hakman]

/retest

[hakman]

/cc @justinsb

[hakman]

/hold cancel

[hakman]

/retest

[justinsb]

Thanks @hakman ... I might have a go at rewriting the fallthrough logic to see if there's a way to make it more obvious, but that's just nitpicking.

/approve
/lgtm

[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

[hakman]

/retest

[BenTheElder]

FTR: kind is disabling the misc controller on cgroups v1. Seeing as it's unlikely to be used by anything in Kubernetes and wasn't supported by runc on v1 until now anyhow. xref kubernetes-sigs/kind#3223

That pretty neatly avoids all of the issues. Though for KIND that's a bit messy to accomplish.
With control over the host kernel etc it would be much more straightforward to do something like cgroup_disable=misc in the kernel args.