From 14edda0bfb0ddcd41159b601a41869406df04e7f Mon Sep 17 00:00:00 2001 From: Nicolai Ort Date: Tue, 22 Jul 2025 16:19:51 +0200 Subject: [PATCH] docs(day2): Added multi tenant isolation talk --- content/day2/08_multi-tenant.md | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) create mode 100644 content/day2/08_multi-tenant.md diff --git a/content/day2/08_multi-tenant.md b/content/day2/08_multi-tenant.md new file mode 100644 index 0000000..ba644d8 --- /dev/null +++ b/content/day2/08_multi-tenant.md @@ -0,0 +1,29 @@ +--- +title: Isolating Workloads in Multi-Tenant Kubernetes Clusters +weight: 8 +tags: + - multi-tenant + - isolation +--- + + + + +## Container Isolation + +- It's a process with capabilities and user access control +- Plus: Namespaces, CGroups, Seccomp +- Problem: Shared Kernel means that the runtime and kernel make everything else vurnerable + +## Sandboxing + +- Solution: Sandboxing (wrapping) the container to isolate it from the kernel +- Software based with gVisor: Software Layer that basicly emulates the kernel by intercepting all syscalls +- Hardware based with kata: Create a vm (one per pod) that runs our secure container instead of just running it on the host +- Impact: Start up time with kata or gVisor is 2x the time needed by traditional runc + +## Optimisation + +- Unikernel: A stripped down kernel that only contains what our application needs +- urunc: CRI compatible runtime with sandboxes and support for unikernel -> Sets up the specialized env, builds the container and then starts the optimized VM +- Impact: Depending on the urunc variant ony 16-30% slower than native runc \ No newline at end of file