support multiple CRI within the nodes

[BenTheElder]

We should theoretically be able to support:

• docker
• cri-o
• containerd

and other similar container runtimes if someone has one they want, within the "node" containers.

Considerations:

• should we install all of these in the base image? at what versions
• we need some plumbing to select which one to use, inform kubeadm etc depending on the first point

@runcom was going to look into cri-o #151 (comment)

containerd should be pretty straighforward once we figure out how we want to handle a second runtime.

/kind feature
/priority important-longterm
/assign
/assign @runcom

[tao12345666333]

In my opinion, we don't need to install all of these in the base image.

We can have multiple types of base image by image tag. And choose one by a flag called CRI or others.

[BenTheElder]

If we have a CRI flag it would have to just be in the base image, which might make kind create cluster less intuitive to select a CRI for most users since they'd need a node image built from a base image with the CRI.

There are some trade-offs with how many images we need to build and maintain, UX, image size, etc.

[tao12345666333]

Yes.

If they are all installed to the base image, the image will become bigger.

I am very happy to participate in this.

[runcom]

@mrunalp ptal as well

[neolit123]

/lifecycle frozen
possibly needs evaluation if containerd is the only option forward at this point.

[BenTheElder]

CRI-O is feasible if someone can figure out how to do the image loading step reasonably.
Otherwise everything within the nodes is on CRI now.

/remove-lifecycle frozen
I'd rather let issues close eventually if there's no activity, regardless of the issue. They can always be re-opened.

[BenTheElder]

[changed my mind on frozen for this issue... but moving to backlog as it's not really clear that varying CRIs on the nodes matters for cases kind is suited to, and this will introduce additional complexity]

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

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/test-infra repository.

[BenTheElder]

we've gotten rid of the lifecycling entirely in this repo for now, but, I still don't think this is the right thing for us to focus on. it does not enable more people to run kind or help people test their apps (portable k8s apps should NOT be aware of which CRI) and for testing kubernetes this is more appropriately done in the node_e2e testing (which involves individual VMs doing integration tests against with different distros/runtimes).