CoreOS rkt
CoreOS rkt (pronounced rocket) is a containerization software engine for running application workloads in isolation from the underlying infrastructure. It is a major competitor to the Docker container engine.
CoreOS rkt is based on the Application Container Image (ACI) as defined by the App Container spec (appc). An ACI is a tarballconsisting of a root file system, which contains all necessary files to execute an application, and an image manifest. Most of the default settings are editable upon runtime; the rkt runcommand enables users to write custom execution parameters to a given image. Docker images must use the docker2aci command to convert from Docker format images to ACI format; CoreOS rkt does this conversion automatically. As of mid-year 2017, the appc standard is no longer valid, and CoreOS is restructuring rkt images to follow Open Container Initiative format.
CoreOS rkt containers operate in most major Linux OS distributions as a binary file that integrates with Linux init systems and scripts, and operates according to the standard Unix process model, which is a parent-child relationship. Rkt containers comply to this model through a simple API that directly interacts with production environments, rather than a daemon that translates commands from input to output. Every CoreOS rkt updated version release also builds self-contained installable packages, which are available as part of a Kubernetes repository.
CoreOS rkt structure
CoreOS rkt uses pods for container configuration, which are collections of any number of applications that execute simultaneously. A pod, which is structured similarly to a Kubernetes Pod, can contain separate configurations for different scopes, from pod-level down to particular applications within the pod. Pods run without a central daemon in self-contained and isolated environments.
CoreOS rkt pods are immutable by default, but CoreOS rkt also offers an exploratory mutable environment. Immutable runtimes are unalterable upon creation, but the mutable runtime, operable only in the rkt app subcommand set, enables application addition, removal, initiation and cessation while the pod is active. Both runtimes are internally managed by systemd.
CoreOS rkt pods execute in a series of stages:
Stage0: An admin invokes an execution process by running the rkt binary file. This binary file fetches designated APIs; generates the pod’s universally unique identifier, manifest and file system; sets up stages 1 and 2 directories; unpacks the stage 1 ACI; and unpacks all ACIs to copy each included app into the stage 2 directories.
Stage1: A trusted binary takes the stage 0-created filesystem and sets up container isolation and any desired networks. This binary reads the image and the manifests for the image and pod. The image manifest specifies default application execution; the pod manifest defines unit order and overrides. This binary also executes the pod’s isolation environment, described as flavors, of which there are several.
Stage2: This is the actual container production environment launched in stage 1.
CoreOS rkt vs Docker
Docker Engine runs as an API daemon, whereas CoreOS rkt launces containers via client commands and lacks a centralized daemon. This makes rkt compatible with systemd, upstart and other init daemons.
CoreOS rkt and Docker operate similarly, such that rkt can operate both Docker images and ACIs.
In March 2017, CoreOS rkt donated the rkt container execution engine to the Cloud Native Computing Foundation (CNCF). Rkt uses the Container Network Interface (CNI), which is a CNCF project pertaining exclusively to container network connectivity and resource dispersal upon container deletion.