docs(day2): Added multi tenant isolation talk

content/day2/08_multi-tenant.md

@@ -0,0 +1,29 @@
+---
+title: Isolating Workloads in Multi-Tenant Kubernetes Clusters
+weight: 8
+tags:
+ - multi-tenant
+ - isolation
+---
+
+<!-- {{% button href="https://youtu.be/rkteV6Mzjfs" style="warning" icon="video" %}}Watch talk on YouTube{{% /button %}} -->
+<!-- {{% button href="https://docs.google.com/presentation/d/1nEK0CVC_yQgIDqwsdh-PRihB6dc9RyT-" style="tip" icon="person-chalkboard" %}}Slides{{% /button %}} -->
+
+## 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