Host containers are a special type of container you can use to manage and administer your Bottlerocket node. These containers are non-orchestrated, which means Kubernetes or ECS are unaware of these containers and cannot directly manage their lifecycle. Instead you manage the lifecycle of these containers by manipulating specific Bottlerocket settings with the API.
This diagram represents the components of the
Note the “Host Containers” in the upper left.
Depending on the variant, Bottlerocket has two standard host containers: the control container and the admin container. The control container provides a pathway to connect (via SMM) to and interact with the host as well as conveniently access the Bottlerocket API. The control container also provides an entry point to the admin container. The admin container allows you to more deeply interact with the host as it mounts the root filesystem and has elevated privileges.
The control and admin containers are not actually special: both are just host containers with specific privileges. Case in point, you can disable (and re-enable) these containers as-needed and you can even fully replace the functionality of both the host and admins containers with your own host containers.
Host containers have a number of different properties from orchestrated containers.
Bottlerocket has two parallel instances of
containerd: one for your orchestrated workloads and one for host containers.
All host containers automatically mount the API socket (
/run/api.sock) and the API Client (
This allows you to run API commands and manipulate Bottlerocket settings from within the host containers without explicitly mounting these resources.
As a consequence, any user that can access a host container can change configurations which could effect the efficiency or stability of the node.
Host containers start and stop based on the value of their
If a host container exits, Bottlerocket automatically restarts the container after 45 seconds.
Host containers can have high levels of privilege.
settings.host-containers.<container>.superpowered for more details.
All host containers have persistent storage that survive node reboots as well as container stop/start cycles2.
When considering if you should use a host container, evaluate the specific properties of host containers and if you need to manage the lifecycle with your orchestrator. Generally, you should try to solve your problem with an orchestrated container and only turn to a host container for low-level use-cases.
Paths for persistent storage and user data (
<HOST_CONTAINER_NAME> being the name of the host container):