CLOUD PUBLIC CLOUDS …… MULTI-CLOUD DATA CONTROLLER TO ACCESS AND MANAGE DATA ACROSS CLOUDS object & file storage in a single system · peer to peer architecture · unlimited scalability · unbounded scale-out performance · most adaptive set of robust data protection mechanisms · autonomous self-healing · designed in close collaboration with the biggest (cloud-scale) service providers in the world a single, unified API across all clouds to simplify application development · the only multi-cloud data management solution independent of the storage system · stores data in standard cloud format to make the data consumable directly by native cloud apps and services · true multi-cloud IT · global search across all managed data independent of cloud location …… … … …
a “copy on write” mechanism • The bad: There is several storage drivers, each with their strengths and weaknesses • The ugly: Bad combination of Docker, Storage Driver and Kernel can lead to issues (mostly upon stop) Docker : Storage Drivers
supported by kernel anymore since 3.18 Warning : bad performance for local-lvm Run out of inode easily Require disabling selinux, require Centos7.4 (kernel 3.10.0-693) Docker storage driver of choice = overlay2 - Best performance/stability with less requirements - With docker < 18.02, detection over kernel capabilities for overlay2 is buggy (require force storage driver for docker 17.03) - Educated bet on future Docker Storage Driver: which and why ?
“storage-opts”: [“overlay2.override_kernel_check=true”] • Double check the compatibility matrix • On RedHat/CentOS be wary of: ◦ XFS with a specific mkfs option mandatory with OverlayFS for /var/lib/docker ◦ Device or resource busy when stopping a container ◦ How to Setup OverlayFS on RedHat Docker : Storage Drivers
production • Be wary of Kernel capabilities and Docker “default” Storage Driver decision • Future might be to use directly containerd 1.1+ (interesting history of graph drivers and why it isn’t supported “as is” in containerd) Docker : Summary
provide API abstraction - Control plane run server side (compared to docker compose) - Self-healing - Auto-scaling (of pods, of cluster, of resources requests) - Huge set of plugins (centralised logging, monitoring, ingress) - Big community - Docker announcement to support Kubernetes in 2017 - Customers trust and want it
identified for Moby • A runc change of behavior with kernel memory accounting • A Kubernetes bug identifying the issue • More precisely : this commit is responsible of the “bug” • A chinese page describing the issue (thank you google translate) What we found so far