investigate switch to NRI for product mounts

[BenTheElder]

See: https://github.com/containerd/nri/tree/main/plugins/hook-injector

More context: https://github.com/containerd/containerd/issues/6262

/kind cleanup

This will let us avoid skew in the OCI base config ...

Though I won't be surprised when users start depending on the OCI hooks directory being available >.< If you're reading this: don't do that. depending on the contents of the kind image is NOT supported. Only that it runs Kubernetes. We need room to make changes like this.

[samuelkarp]

Do you need the actual hook injector? Or just mount injection? https://github.com/kubernetes-sigs/kind/blob/74acdf744a3566279ddf7e4d7d2e2b364b1ec5bd/images/base/Dockerfile#L210-L213 looks like adding a couple mounts (and then rlimit adjustment, which there is another NRI plugin for).

[BenTheElder]

The rlimit bit is just an old attempt to mimic the actual default base json from CRI since ctr oci spec doesn't have those transformations.

We only need the mounts.

[samuelkarp]

If you only need the mounts you probably don't want the hook injector then. You can see an example for injecting mounts directly here: https://github.com/containerd/nri/blob/027de07a85a99e99845755aa7ced8e24a4fa9ceb/plugins/device-injector/device-injector.go#L186

[BenTheElder]

/help

[k8s-ci-robot]

@BenTheElder: This request has been marked as needing help from a contributor.

Guidelines

Please ensure that the issue body includes answers to the following questions:

• Why are we solving this issue?
• To address this issue, are there any code changes? If there are code changes, what needs to be done in the code and what places can the assignee treat as reference points?
• Does this issue have zero to low barrier of entry?
• How can the assignee reach out to you for help?

For more details on the requirements of such an issue, please see here and ensure that they are met.

If this request no longer meets these requirements, the label can be removed by commenting with the /remove-help command.

In response to this:

/help

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[2003Aditya]

Hey @BenTheElder 👋

I’ve been going through this issue and related discussions. From what I understood, the current ctr oci spec + jq step in kind/images/base/Dockerfile manually injects mount points (and removes rlimits) in /etc/containerd/cri-base.json.

The goal seems to be migrating this to NRI so that mount injection happens via a cleaner, supported interface instead of directly modifying the OCI base config.

I checked the device-injector plugin example from NRI, which uses specgen.WithMounts() for adding mounts dynamically — that looks like a good direction to follow.

Before I explore implementing a minimal NRI plugin or wiring it into the base image, could you confirm whether you’d prefer:

• Using an existing NRI plugin (like device-injector) with minimal config changes, or
• Writing a small custom NRI plugin for kind to handle just these mounts?

Once you confirm, I’d love to start investigating and testing this locally.

Thanks!

[BenTheElder]

I think we need to investigate which will be easier to maintain longterm. Is device-injector meant to be a stable tool for production use? How does it align to containerd upgrades? "Sample" to me indicates that it's unfortunately probably not stable / supported.

We also need to be careful of any incidental changes from switching off the oci hook. Our config doesn't quite match the standard OCI template (see the linked issues)