6 ms·

Using Virtual Machines to Improve Container Security with Rkt v0.8.0

37 points by preillyme 11y ago

preillyme 11y ago
I also think it's worth mentioning that Intel® Clear Containers now supports Docker as well.
- preillyme 11y ago
  Arjan van de Ven (from Intel) can share more context.
  - eloff 11y ago
    It's fantastic that you've reduced the startup and memory overhead to the point where it's almost negligible. That's quite an achievement! One thing that was not discussed is the impact hypervisor-based virtualization has on runtime. I've seen plenty of benchmarks where AWS EC2 instances perform much more poorly than a bare-metal machine with a similar processor. Do you have any idea what the overhead might be for clear containers vs standard linux namespace-based containers?
    - wmf 11y ago
      It's probably similar to our results from last year: http://domino.research.ibm.com/library/cyberdig.nsf/papers/0929052195DD819C85257D2300681E7B http://domino.research.ibm.com/library/cyberdig.nsf/papers/0...
      - eloff 11y ago
        Thanks for sharing! So roughly 20% slower for computationally intensive workloads, likely due to nested paging putting increased pressure on the TLB. For applications using huge pages, the slowdown would likely be much less. Both docker and KVM introduce a lot of overhead with frequent, small IOs. That's likely the chattiness of the syscalls with the Kernel, which is a problem even without virtualization. Doing more work per syscall reduces those overheads. e.g. writev, readv, sendmmsg recvmmsg, etc. The context switch involved in syscalls (especially the cache and TLB pollution they cause) is very expensive.
- tristanz 11y ago
  Where is this documented?
deleted 11y ago
[deleted]
josephjacks 11y ago
Disclaimer: I work for Kismatic. It's exciting to see further investment in Intel® Clear Containers. At Kismatic, we have been fans (0) of Clear Containers since the beginning! (0): https://kismatic.com/technical/quickstart-intel-clear-linux-containers/ https://kismatic.com/technical/quickstart-intel-clear-linux-...
eloff 11y ago
A good intro to clear containers here, it's really fascinating reading: http://lwn.net/Articles/644675/ http://lwn.net/Articles/644675/
thinkingkong 11y ago
This might be viewed as slightly OT but this entire container security thing always reminds me how important it is to build on the right ecosystem. This technology has been available for years on other platforms in a stable fashion. The fact that they never get used for different reasons is always sobering
edwintorok 11y ago
Although the article says Intel VT-x, the demo successfully runs on an AMD CPU with SVM although with this warning: [ 0.000000] KERNEL supported cpus: [ 0.000000] Intel GenuineIntel [ 0.000000] CPU: vendor_id 'AuthenticAMD' unknown, using generic init. [ 0.000000] CPU: Your system may be unstable.

37 points by preillyme 11y ago

preillyme 11y ago

I also think it's worth mentioning that Intel® Clear Containers now supports Docker as well.

preillyme 11y ago
Arjan van de Ven (from Intel) can share more context.
- eloff 11y ago
  It's fantastic that you've reduced the startup and memory overhead to the point where it's almost negligible. That's quite an achievement! One thing that was not discussed is the impact hypervisor-based virtualization has on runtime. I've seen plenty of benchmarks where AWS EC2 instances perform much more poorly than a bare-metal machine with a similar processor. Do you have any idea what the overhead might be for clear containers vs standard linux namespace-based containers?
  - wmf 11y ago
    It's probably similar to our results from last year: http://domino.research.ibm.com/library/cyberdig.nsf/papers/0929052195DD819C85257D2300681E7B http://domino.research.ibm.com/library/cyberdig.nsf/papers/0...
    - eloff 11y ago
      Thanks for sharing! So roughly 20% slower for computationally intensive workloads, likely due to nested paging putting increased pressure on the TLB. For applications using huge pages, the slowdown would likely be much less. Both docker and KVM introduce a lot of overhead with frequent, small IOs. That's likely the chattiness of the syscalls with the Kernel, which is a problem even without virtualization. Doing more work per syscall reduces those overheads. e.g. writev, readv, sendmmsg recvmmsg, etc. The context switch involved in syscalls (especially the cache and TLB pollution they cause) is very expensive.
tristanz 11y ago
Where is this documented?

deleted 11y ago

[deleted]

josephjacks 11y ago

Disclaimer: I work for Kismatic. It's exciting to see further investment in Intel® Clear Containers. At Kismatic, we have been fans (0) of Clear Containers since the beginning! (0): https://kismatic.com/technical/quickstart-intel-clear-linux-containers/ https://kismatic.com/technical/quickstart-intel-clear-linux-...

eloff 11y ago

A good intro to clear containers here, it's really fascinating reading: http://lwn.net/Articles/644675/ http://lwn.net/Articles/644675/

thinkingkong 11y ago

This might be viewed as slightly OT but this entire container security thing always reminds me how important it is to build on the right ecosystem. This technology has been available for years on other platforms in a stable fashion. The fact that they never get used for different reasons is always sobering

edwintorok 11y ago

Although the article says Intel VT-x, the demo successfully runs on an AMD CPU with SVM although with this warning: [ 0.000000] KERNEL supported cpus: [ 0.000000] Intel GenuineIntel [ 0.000000] CPU: vendor_id 'AuthenticAMD' unknown, using generic init. [ 0.000000] CPU: Your system may be unstable.