A brisk introduction to container runtimes (engines) and an understanding of when container orchestrators enter and what role they play. We’ll look at what makes them alike, yet unique. Presented at ContainerizeThis 2016.
Application Containers Single process Use namespaces to deal with resource isolation for a single process. Use cgroups to manage resources for a group of processes. Similarities:
is an implementation of for FreeBSD using jails and ZFS rkt Kurma Jetpack Implemented by - is the reference implementation is a hypervisor-based runtime launches an Intel VT-x secured Clear Containers 2.0 hypervisor runC runV cc-oci-runtime
tooling for the runtime a software shipping container image format spec with security and naming as components tooling for the image runtime-spec runtime-tools image-spec image-tools https://opencontainers.org
Can run Docker Images and also App Container Images (ACIs) Security has been a focal concern uses HTTPS to locate and download remote ACIs and their attached signatures Docker Engine runs a daemon rkt systemd $ rkt run postgres application systemd $ docker run postgres application Docker Engine containerd runC
or as its tagline states "an open source system for automating deployment, scaling, and operations of applications." Written in Golang, Kubernetes is lightweight, modular and extensible considered a third generation container orchestrator led by Google, Red Hat and others. bakes in load-balancing, scale, volumes, deployments, secret management and cross- cluster federated services among other features. Declaratively, opinionated with many key features included @lcalcote
Swarm is responsible for the clustering and scheduling aspects of orchestration. Originally an imperative system, now declarative Swarm’s architecture is not complex as those of Kubernetes and Mesos Written in Golang, Swarm is lightweight, modular and extensible @lcalcote