Skip to content


vdocker moved to cradle

Vdocker is how we call the thing that responds to docker api calls like log, attach, exec and cp.

Vdocker used to run on the host, and all the commands where carefully funneled through a virtio-serial. The advantage is that cradle is small, and starts faster. However, we realized most people do start fairly large containers that take a few seconds to start anyway. Hence sub-100ms startup time for cradle is no longer a priority

Instead we traded a few milliseconds of start time for much higher bandwidth by moving vdocker directly into cradle. It listens inside of your pod on port 1 and accepts the nessesary docker commands from the api frontend. docker cp now works properly and is much faster. Also docker attach no longer glitches.

Unfortunately this means docker run feels slower, although it really hasnt changed much. Log output starts appearing roughly 80ms after download completed, but for larger container it may take several seconds to download layers, which you can currently not see.

On the upside, all other commands now feel alot faster, because we skip vmm and just proxy the http call directly to vdocker.

global file system is now generally available

Global file system can be mounted simultaneously on multiple containers, enabling easy out of the box shared directories between services.

Similar to NFS, it does make files available over the network, but GFS is fully managed and does not have a single point of failure. It is also significantly faster than NFS due to direct memory access in virtiofs.

docker volume create shared --driver gfs
docker run -ti -v shared:/data alpine

Coherent filesystem for horizontal scaling

GFS enables an application developer to start multiple instances of the same application, without implementing synchronization. This is specifically useful for traditional stacks like PHP where horizontal scaling requires a separate network storage.

Any docker container works with GFS without changes. The same standard syntax used to mount volumes on your local computers dockers will simply work in the cloud.

Shared object storage for multiple services

Modern applications often choose to store shared files in object storages, specifically s3. With GFS, you can simply store a file using unix file semantics without the need for a separate layer.

File i/o behaves identical using a docker volume on your local machine, and with kraud. This makes developing apps locally and deploying into the kraud seamless.

Built in redundancy by ceph

GFS is backed by cephfs on a 3 times redundant SSD cluster. Ceph is an open source object storage cluster backed by redhat, CERN and others. All pods/containers launched in the Falkenstein DC enjoy a 20MB/s transfer rate.

Users with hybrid regions should note that GFS data transfer counts towards external traffic.

Additionally, customers may choose a separate cluster for large intermediate data on magnetic disks. This is intended for science applications working with large data sets and can easily scale to multiple petabytes.

see the documentation for details