0

for example, can I have one pod running docker and another running cri-o?

I am new to the world of kubernetes and I've not been able to find the answer in the documentation.

honestSalami
  • 103
  • 2
  • Very likely, since from kubelet's point of view it's only [changing the administrative socket and `--container-runtime`](https://github.com/cri-o/cri-o/blob/v1.20.1/tutorials/kubernetes.md#preparing-kubelet). You'd likely want to also add a Node label to indicate which Nodes are on docker and which are on cri-o since the scheduler will not otherwise know. But what problem are you trying to solve by doing something like that? – mdaniel Mar 21 '21 at 17:02
  • I'm not trying to solve a problem. I'm just studying kubernetes and the question occurred to me. Given the lack of answers, I guess this is really an unusual idea that does not solve any real life problem. – honestSalami Mar 22 '21 at 01:59
  • For sure mixing containerization technologies in a cluster is weird. I also just realized you asked about "one pod" running docker and another cri-o, and what I said is true about kubelet but kubelet's domain is the entire node, so it would be all pods on that node which use one technology or the other, and one cannot change containerization down to the individual pod – mdaniel Mar 23 '21 at 02:29
  • I believe you could, but not using any vanilla Kubernetes mechanism (maybe an annotation? or a nodespec?). Tanzu (IIRC) has an ability to run some pods in a more segregated fashion, although I can't find a reference for that at present. Kubernetes has been designed to make it easier to plug-in different container engines, although that's generally for service providers to enable better isolation in multi-tenancy scenarios. – Cameron Kerr Apr 12 '21 at 11:28
  • Turns out that this is no-longer true; see the concept of a RuntimeClass – Cameron Kerr Apr 23 '21 at 23:14

1 Answers1

1

In Kubernetes version 1.20 you have concept of a RuntimeClass. This basically tells Kubernetes, on a Pod level, which container engine to use to run the pod.

You can set a different RuntimeClass between different Pods to provide a balance of performance versus security. For example, if part of your workload deserves a high level of information security assurance, you might choose to schedule those Pods so that they run in a container runtime that uses hardware virtualization. You'd then benefit from the extra isolation of the alternative runtime, at the expense of some additional overhead.

You can also use RuntimeClass to run different Pods with the same container runtime but with different settings.

With this in place, you can use concept such as a micro-VM / lightweight-VM to run a pod. This concept is not particular to Kubernetes or container orchestration, but really comes from the related world of sandboxing applications (eg. as a browser security enhancement for opening attachments from untrusted websites). See for example this comparison of micro-VMs for application sandboxing.

For Kubernetes, technologies such as gVisor and Kata (and other; see the Container Runtime landscape on CNCF) aim to provide value.

The capabilities that are made available will be heavily dependent on the Kubernetes distribution and how its VM infrastructure has been setup.

Cameron Kerr
  • 4,069
  • 19
  • 25