RuntimeHandler support

[tallclair]

As part of the new Kubernetes RuntimeClass feature, we're adding a new field to the CRI's RunPodSandboxRequest: runtime_handler (https://github.com/kubernetes/kubernetes/pull/67518).

As discussed in the proposal (under RuntimeHandler), this new field is designed to select between multiple "handler" configurations, and deprecate the binary "trusted" and "untrusted" runtime selection.

In order to support this new feature, the following items need to be addressed:

• [x] Map the runtime_handler field to a runtime configuration, deprecating the io.kubernetes.cri.untrusted-workload annotation.
• [x] Reject requests that cannot be mapped to a valid runtime configuration
• [x] (optional) Support multiple (non-binary) named runtime configurations
• [x] Integration tests

Proposal

1. Deprecate plugins.cri.containerd.untrusted_workload_runtime. If it is provided, give it the implicit configuration name of untrusted.
   • (optional) Deprecate the DefaultRuntime field as well, favoring a runtime with the name of default or ''
2. Introduce a new ContainerdConfig field: Runtimes map[string]Runtime
   • Specifying both the untrusted_workload_runtime and a Runtimes['untrusted'] is a configuration error (ditto for default, if we go that route).
3. Modify criService.getSandboxRuntime to take the runtime handler as a parameter, and map it to the correct runtime config.
   • Return an error if it cannot be mapped.
   • If both the untrusted annotation & runtime_handler are specified, prefer the runtime handler EDIT: return an error

If this proposal sounds good, I'm happy to open a PR.

[resouer]

+1 for this proposal. This is tightly related with kata shimv2 integration as well.

We may also need a item about refactoring the CRI and e2e tests. plugins.cri.containerd.untrusted_workload_runtime is referred in the tests for quite a while.

[Random-Liu]

It might be hard to add an integration test, unless we can have another runtime running on the test node.

Another option is to use the same runc runtime, but configure different runtime root. However, in anyway, we need to start containerd with specific config at the beginning of the whole integration test.

[Random-Liu]

First 3 items are done. Integration test is harder to add now without a test alternative runtime. Punt to next release.

[Random-Liu]

We are running runtimeclass test for containerd in cluster e2e now https://k8s-testgrid.appspot.com/sig-node-containerd#e2e-gci

I think we can close this one.