CoreOS rkt, the next-generation application container runtime for Linux, continues its flight toward being the most secure, composable container environment with the latest release, rkt 0.15.0. This significant release lays new groundwork for using containers to distribute and run the entire spectrum of software needed to construct the enterprise stack. Starting with this version of rkt, system-level processes can be executed at a configurable level of container isolation by a new feature called rkt fly.
Running isolated, interoperable instances of every application version and process side-by-side is the holy grail for managing painless software updates. Containers are the building block enabling isolation between different versions of software running simultaneously. rkt is paving the way toward flexibility for devops to run everything in containers. This means security in running the latest version of software, and confidence in developing applications without the pain of interconnected dependencies. The new rkt fly facility is designed to give applications and services with cluster- or network-wide management and configuration duties (such as controller nodes or dynamic routing managers) the containerization advantages of cryptographically-verified, repeatable application packaging and distribution.
The rkt 0.15.0 release also brings UX improvements, bug fixes, API service enhancements, and support for building with Go 1.5. Available in both the CoreOS Linux alpha channel and from the project’s releases page, you can get started with rkt and the rkt fly feature today.
Fly, rkt, fly
rkt is designed to be a composable unit within enterprise container cluster workflows, and is itself comprised of a few well-defined, interacting modules. This architecture allows great flexibility in how containers are executed. For example, rkt is already capable of launching a container as a virtual machine, allowing for greater isolation in a traditional mechanism for multi-tenant resource control. This works by replacing the default rkt stage1 container environment provisioner with a stage1 invoking KVM CPU-based virtualization.
At the other end of the spectrum, the new rkt fly stage1 provides a specialized way to run exceptionally-privileged software, like cluster management controllers, with many of the usual container isolation features switched off. This allows even the lowest-level code to run with as much protection as possible, and with all of the security and distribution advantages of the App Container Image (ACI) container format, including image signature verification and simple distribution endpoints.
The Kubernetes kubelet is an excellent example of rkt fly’s use case. The kubelet runs on every Kubernetes cluster node, and must be able to schedule work and manage the container runtime that, in turn, executes the user application containers that perform business tasks in the cluster. The kubelet’s additional need to manipulate host network interfaces, routing, and firewall rules makes it difficult to run within a container. Yet for a minimal system like CoreOS, tracking a component from an upstream project like the kubelet as a binary included in the OS image is less than satisfactory. The pace of Kubernetes development outstrips the stability needed at the system level, and making the kubelet a standard component of the operating system increases the image size for sites that may not be running Kubernetes. rkt fly is an ideal solution to this chicken-and-egg problem that can affect a variety of management-level software like cluster controllers.
In future versions of the CoreOS Linux alpha release, the kubelet will be managed and executed by rkt, rather than being built into the operating system’s default set of binaries. The fly stage1 provides an isolated
chroot file system, but otherwise allows access to the host and its container facilities, as required by the kubelet’s duties. This allows the CoreOS kubelet to be packaged in a single, easily distributed, easily updated, and cryptographically-signed and validated ACI file, fetched and added to the system only on demand. CoreOS systems that are not Kubernetes nodes never fetch or install the Kubernetes support software. Meanwhile CoreOS clusters under both Tectonic and vanilla Kubernetes can more easily track the many exciting improvements from the Kubernetes project through predictable, static container updates from a known container registry.
Other notable improvements: UX, API service, Go 1.5 builds
Version 0.15.0 makes several rkt features easier for administrators to use and control. Most notably, images can now be removed from the local store either by UUID or by their human-readable name. As rkt advances toward wider deployment, the new ability to grant members of the host’s
rkt group permission to examine pod logs adds some granular control of access to individual features of the rkt environment.
The rkt API service has been improved and now exposes more information to API clients. Clients can now learn image size from the API. Annotations found in pod and image manifests are also newly available from the API, making ACI annotation strings a general facility for communicating image metadata, such as application version, or build details. In addition, the backing store for the API service has been made thread-safe, fixing a potential race condition and expanding service capacity. Kubernetes is a major charter client of the rkt API, with “k8s” cluster management components making requests to learn about container images and application execution. This work is an example of the larger common effort by both projects to advance container standardization by making Kubernetes runtime-agnostic.
Go 1.5 — specifically the latest version, 1.5.3 — is now the supported and expected go environment for building rkt. The latest go compiler and runtime deliver more predictable garbage collection performance, and incremental improvements to dependency management along with many other fixes and features.
Not specifically related to rkt, but important for rkt developers and users on CoreOS systems, the latest CoreOS Linux alpha version 928.0.0 also includes a fix for a minor OpenSSH vulnerability, disabling the vestigial
ssh client “roaming” feature to help keep connections to CoreOS rkt cluster nodes secure.
Take off with rkt
We encourage you to join the community to test and influence rkt as it advances toward v1.0.
Get involved in the rkt community via discussion on the rkt-dev mailing list or on the #rkt-dev Freenode IRC channel, by joining community meetings, by filing GitHub issues, or contributing directly to the project. We hope to see you at the next rkt/appc community hangout on January 20, 2016!