Components

The Linux kernel provides the foundation of Bottlerocket. The kernel (major+minor) version may vary between variants, but does not change on update.

systemd serves as the initialization and service management layer. systemd unifies a broad, modern, widely-used set of APIs that Bottlerocket can build atop in a variety of contexts.

Bottlerocket runs two instances of the container runtime, containerd. Containers used for operational and administrative purposes have a devoted containerd instance, whilst orchestrator-managed workloads have a separate containerd instance.

On Kubernetes variants, Bottlerocket runs Kubelet to communicate with the Kubernetes control plane and orchestrate container lifecycles.

Bottlerocket defers workload management to the orchestrator. While Bottlerocket is a distinctive operating system, the differences are mostly transparent to your application workloads. If your workload requires specific host-level interactions, accommodations go through the Bottlerocket Settings API in addition to typical patterns of mounted directories and container privileges.

“Host Containers” are containers specifically used to maintain, operate, or administer the node. Host containers provide a secondary method to manipulate and administer the operating system even if the orchestrator agent is non-responsive or exhausted of resources.

There are two host containers that are published for use with Bottlerocket: the control container and the admin container. The control container is on by default. It is pre-configured to be able to use the Bottlerocket API and can be accessed by SSM. The admin container is off by default and has elevated privileges for system exploration and debugging. Furthermore, any container can be run as a host container, and any number of host containers can run.

Bottlerocket ECS variants function in roughly the same way but differ subtly in components. Instead of Kubelet, ECS variants use the ecs-agent and Docker daemon. The ecs-agent communicates with the ECS control plane but Docker interposes between the agent and the container runtime.

Variants designed to run on-premises have different access constraints. The control container with SSM is available, but disabled by default. As with the other variants, Bottlerocket does not start with an enabled admin container, however some solutions may enable it for an easier first-boot access path.