--- title: "Push the boundaries of kubernetes multi-tenancy with containerruntimeclasses" weight: 8 tags: - rejekts - runtime --- I missed the first 3 minutes of this talk because they started ealy so the notes are currently missing the first levels of multi-tenancy This was a real interesting introduction into the world of runtime classes and how you could use them to choose the right level of isolation for each of your pods/deployments utilizing different runtimes/shims. Running everything from normal containers to hardened/Emulated processes and vms side-by-side in kubernetes. ## Levels of multi-tenancy - God-Level: A physical clusters seperated out in multiple virtual clusters which can be isolated into even more nested virtual clusters (for ) - Problem: We're using the same container runtime ## Runtimes - There are different runtimes since TODO -> They replaced dockershim as the runtime in 1.24 - Choice can range from cri-o )performant) to kata containers (secure) - In the past there was no plugin architecture (node had to be reinstalled and restarted to switch cri) now you just have to update the container confug through a new RuntimeClass - Can be targeted for each Pod/Deployment Spec - You can still use containerd as the default class with shims (Shim v2 Project) for specialized runtimes like kata or windows - Expansion: KubeVirt - vms as a runtime class (also implemented by others like kata with qemu isolation) ## Pro/Con - Pro: Security, Cost optimization, Performance optimization, diversity/flexibility - Con: Day2 complexity, complex debugging (anyone say networking), additional costs of using VMs