9 ms·
https://github.com/google/gvisor https://github.com/google/gvisor gives you essentially the same benefits as a unikernel without having to compromise on compati
by marmarama 5y ago
https://github.com/google/gvisor https://github.com/google/gvisor gives you essentially the same benefits as a unikernel without having to compromise on compatibility or recompile your apps, and integrates nicely with Kubernetes already. It also doesn't require a hypervisor at all.
- bitcharmer 5y agoSince this looks like an intermediary layer between userspace and the host kernel (at least if I'm reading it correctly), does anyone know what its performance impact is?
- marmarama 5y agoThe gVisor documentation has performance comparisons vs. cgroup-style 'traditional' containers at https://gvisor.dev/docs/architecture_guide/performance/ https://gvisor.dev/docs/architecture_guide/performance/ There is definitely some performance overhead, but in most cases it is less than hypervisor-based approaches.
- eyberg 5y agoIn gVisor if you aren't using hardware acceleration (eg: virtualization) then you are using ptrace which is incredibly slow.
- marmarama 5y agoThe benchmarks in the gVisor docs above are using ptrace, and they don't look too shabby.
- eyberg 5y agoUsing redis as an example it's basically half in every benchmark: https://gvisor.dev/docs/architecture_guide/performance/#system-calls https://gvisor.dev/docs/architecture_guide/performance/#syst... IO bound tasks can be up to 10x slower using ptrace. I think using hardware acceleration gives you acceptable performance but ptrace is just a non-starter for prod.
- zamadatix 5y agoI always thought of gVisor as being in the opposite direction of the main point of unikernels in that it's another layer between the app and the kernel rather than removing the separation completely.
- marmarama 5y agoUnikernels never really removed the layer between the app and the kernel, they just made the hypervisor the kernel and invented a layer to handle IO to/from the virtual devices presented by the hypervisor, inside the same memory space as the app. If the hypervisor is KVM, which they are if running on modern AWS EC2 instances or GCP, unikernel apps are literally just Linux processes; the underlying Linux host is doing all the heavy lifting. Conceptually, they're essentially the same as a sandboxed ordinary Linux process with an in-process IO stack, but without the ability to monitor or debug them as if they were an ordinary Linux process.
- eyberg 5y agoI agree with most of this except for the monitoring/debugging part. GDB works great as does printf and others: https://docs.ops.city/ops/debugging https://docs.ops.city/ops/debugging Prometheus and other open source monitoring solutions work out of the box and we even have a custom APM service that is unikernel-tuned https://nanovms.com/radar https://nanovms.com/radar .
- deleted 5y ago[deleted]
- zamadatix 5y agoApp --syscall --> kernel --hypercall--> kernel App --"syscall"--> gVisor --syscall--> kernel Unikernel --hypercall--> kernel Though ideally something like SR-IOV would come into play and they hypervisor is just scheduling shared compute. Of course there is theory and reality and reality is unikernels never really caught on for many reasons while the normal stack just got optimized enough.
- pjmlp 5y ago