2.0 KiB
2.0 KiB
title, weight, tags
| title | weight | tags | ||
|---|---|---|---|---|
| Push the boundaries of kubernetes multi-tenancy with containerruntimeclasses | 8 |
|
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