---
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