and originally posted on Kinvolk.io
When using rktlet, all container workloads are run with the rkt container runtime.
The rkt container runtime is unique amongst container runtimes in that, once rkt is finished setting up the pod and starting the application, no rkt code is left running. rkt also takes a security-first approach, not allowing insecure functionality unless the user explicitly disables security features. And rkt is pod-native, matching ideally with the Kubernetes concept of pods. In addition, rkt prefers to integrate and drive improvements into existing tools, rather than reinvent things. And lastly, rkt allows for running apps in various isolation environments — container, VM or host/none.
rkt support in Kubernetes
With this initial release of rktlet, rkt currently has two Kubernetes implementations. Original rkt support for Kubernetes was introduced in Kubernetes version 1.3. That implementation — which goes by the name rktnetes — resides in the core of Kubernetes. Just as rkt itself kickstarted the drive towards standards in containers, this original rkt integration also spurred the introduction of a standard interface within Kubernetes to enable adding support for other container runtimes. This interface is known as the Kubernetes Container Runtime Interface (CRI).
With the Kubernetes CRI, container runtimes have a clear path towards integrating with Kubernetes. rktlet is the rkt implementation of that interface.
The goal is to make rktlet the preferred means to run workloads with rkt in Kubernetes. But companies like Blablacar rely on the Kubernetes-internal implementation of rkt to run their infrastructure. Thus, we cannot just remove that implementation without having a viable alternative.
rktlet currently passes 129 of the 145 Kubernetes end-to-end conformance tests. We aim to have full compliance. Later in this article, we’ll look at what needs remain to get there.
Once rktlet it ready, the plan is to deprecate the rkt implementation in the core of Kubernetes.
How rktlet works
These methods handle lifecycle management and gather state.
To create pods, rktlet creates a transient systemd service using
systemd-run with the appropriate
rkt command line invocation. Subsequent actions like adding and removing containers to and from the pods, respectively, are done by calling the
rkt command line tool.
The following component diagram provides a visualization of what we’ve described.
To try out rktlet, follow the Getting Started guide.
Driving rkt development
Work on rktlet has spurred a couple new features inside of rkt itself which we’ll take a moment to highlight.
rkt has always been pod-native, but the pods themselves were immutable. The original design did not allow for actions such as starting, stopping, or adding apps to a pod. These features were added to rkt in order to be CRI conformant. This work is described in the app level API document
Logging and attaching
Historically, apps in rkt have offloaded logging to a sidecar service — by default systemd-journald — that multiplexes their output to the outside world. The sidecar service handled logging and interactive applications reused a parent TTY.
But the CRI defines a logging format that is plaintext whereas systemd-journald’s output format is binary. Moreover, Kubernetes has an attaching feature that couldn’t be implemented with the old design.
To solve these problems, a component called
iottymux was implemented. When enabled, it replaces systemd-journald completely; providing app logs that are formatted to be CRI compatible and the needed logic for the attach feature.
For a more detailed description of this design, check out the log attach design document.
Future work for rktlet
rktlet still needs work before it’s ready for production workloads and be 100% CRI compliant. Some of the work that still needs to be done is…
- kubectl attach,
- CRI container stats,
- Performance improvements,
- More testing with kubernetes v1.8.x
- Documentation improvements
Join the team
If you’d like to join the effort, rktlet offers ample chances to get involved. Ongoing work is discussed in the #sig-node-rkt Kubernetes Slack channel. If you’re at Kubecon + CloudNativeCon North America in Austin from December 6-8, please come by the rkt salon to talk about rkt and rktlet.