A form to isolate applications from the host OS — Allow developers to pack all dependencies — Easy to move between environments — Easy to develop, deploy and manage — Extra layer of security
1979 the concept of process isolation — FreeBSD Jails introduced in 2000 the concept of resources partition — Linux VServer (2001), the Jails mechanism for Linux — Open VZ (2005) introduced virtualized containers for Linux — cgroups (Linux resource partition) and LXC (LinuX Containers) – Introduced in the Linux 2.6 release in 2008 — Docker was introduced in 2013 – Containers started to explode in popularity
— Windows-based containers runs only on Windows — Linux-based containers runs on Linux and Windows — Docker can only run Linux-based containers – Uses a VM on Windows or WSL — FreeBSD and Solaris also have their own container implementation — macOS has no native container implementation – Can run Docker and Linux-based with VMs
— Processes think it has its own global resource — Processes can share namespaces or have exclusive access — Types available – Cgroup, IPC, Network, Mount, PID, Time, User, UTS
resource usage – CPU, memory, disk I/O, network, etc. — Allow processes to be organized into hierarchical groups — Usage of resources can be limited and monitored — Version 1 – Many inconsistencies — Version 2 – Intended to replace v1 – Implements only a subset of controllers in v1
permissions — Avoid the need to use root user – Process has "root access" to attributed capability but not entire system — Replaces the use setuid attribute — Root user can bypass all permission checks — For example – CAP_SYS_TIME allows the process to set system clock
Low level component used by container engines — Manages the container lifecycle – Creates and run containers – Not required to do much else — Provides information for container engines – Metadata, mount points — Responsible for setting up – cgroups, SELinux policy, App Armor rules
— Kubernetes was originally based on Docker — Gained popularity and needed alternative runtime support — New spec is created to describe container orchestration – The Container Runtime Interface (CRI) — CRI allows to support multiple runtimes without custom changes — CRI has additional concerns than runtime – Image management and distribution, storage, networking and more
high-level runtime interface – Uses runC by default — crio-o – RedHat implementation for Kubernetes – Uses runC or crun (with cgroups v2) — frakti – VM based CRI – Kata absorbed many features and frakti is less relevant today
Software that accepts user requests (CLI) — Engines do not run containers — Engines manages resources – Pull images, Remove images – Prepare container mount point – Prepare metadata for the runtime — Communicates with runtime to run user commands
Reserved. SUSE and the SUSE logo are registered trademarks of SUSE LLC in the United States and other countries. All third-party trademarks are the property of their respective owners. For more information, contact SUSE at: +1 800 796 3700 (U.S./Canada) Maxfeldstrasse 5 90409 Nuremberg www.suse.com Thank you