Kubernetes is a system for managing containerized applications across a cluster of machines. Kubernetes runs all applications in containers. In the default setup, this is performed using the Docker engine, but Kubernetes also features support for using rkt as its container runtime backend. This allows a Kubernetes cluster to leverage some of rkt's security features and native pod support.
The container runtime is configured at the kubelet level. The kubelet is the agent that runs on each machine to manage containers. The kubelet provides several flags to use rkt as the container runtime:
--container-runtime=rkt
Sets the node's container runtime to rkt.--rkt-api-endpoint=HOST:PORT
Sets the endpoint of the rkt API service. Default tolocalhost:15441
.--rkt-path=PATH_TO_RKT_BINARY
Sets the path of the rkt binary. If empty, it will search for rkt in$PATH
.--rkt-stage1-image=STAGE1_NAME
Sets the name of the stage1 image, e.g.coreos.com/rkt/stage1-coreos
. If not set, the default stage1 image (coreos.com/rkt/stage1-coreos
) is used.
Check the rktnetes getting started guide for information about setting up and using a rktnetes cluster.
The coreos-kubernetes and coreos-baremetal repos both support configuring rkt as the Kubernetes runtime out of the box.
Check out the coreos-kubernetes repo if you want to spin up a cluster on AWS or locally with Vagrant. The common configuration option here is setting CONTAINER_RUNTIME
environment variable to rkt.
For baremetal, check out the Kubernetes guides here.
Using Minikube
Minikube is a tool that makes it easy to run Kubernetes locally. It launches a single-node cluster inside a VM aimed at users looking to try out Kubernetes. Follow the instructions in the Minikube Quickstart section on how to get started with rktnetes.
Integration of rkt as a container runtime was officially announced in the Kubernetes 1.3 release. Known issues and tips for using rkt with Kubernetes can be found in the rktnetes notes.