Bottlerocket nodes in EKS can start up 30% faster and offer a more secure runtime than traditional Amazon Linux 2 nodes.
Let’s see Bottlerocket in action. Imagine you’re deploying a new service. With Bottlerocket, your worker nodes are ready to accept pods in under 60 seconds, significantly reducing your deployment pipeline’s latency.
# Example Bottlerocket AMI ID (replace with your specific region and desired version)
ami_id="ami-0f1f3e7d8c9a0b1c2"
# Example EKS Node Group creation using Bottlerocket
eksctl create nodegroup \
--cluster=my-eks-cluster \
--region=us-west-2 \
--name=bottlerocket-nodes \
--node-type=m5.large \
--nodes=3 \
--ami=$ami_id \
--bottlerocket-ami-family=aws-ecs-x86_64 \
--ssh-access=false \
--asg-access=false \
--external-dns-access=false \
--alb-ingress-access=false \
--os=linux \
--kubelet-extra-args="--node-labels=nodegroup=bottlerocket-nodes,workload=frontend"
This eksctl command provisions a new EKS node group. Notice the --bottlerocket-ami-family flag, which specifies Bottlerocket. The --ami flag points to a Bottlerocket AMI. We’re also disabling SSH and other direct access methods to enforce the security model.
Bottlerocket is a Linux-based operating system purpose-built to run containers. It’s designed with a minimal attack surface and a strong emphasis on security and operational simplicity. Unlike general-purpose operating systems, Bottlerocket’s components are optimized for running container workloads.
The core of Bottlerocket’s speed and security comes from its layered architecture and immutability. It consists of two main components: the "boot" partition and the "rootfs" partition. The boot partition contains the kernel and essential boot components. The rootfs partition contains the user-space binaries and libraries, including the container runtime (like containerd) and the kubelet.
When a Bottlerocket node starts, it boots from a read-only root filesystem. This means the operating system itself cannot be tampered with post-deployment. Updates are applied as atomic image replacements. The system boots into a new image, and if something goes wrong, it can roll back to the previous known-good image. This immutability drastically reduces the risk of configuration drift and malicious modifications.
The minimal nature of Bottlerocket means it ships with only what’s necessary to run containers. There’s no shell access by default, no package manager (like apt or yum), and no unnecessary daemons. This significantly shrinks the attack surface. Security patches are delivered as full OS image updates, ensuring that the entire system is updated consistently and reliably.
The faster startup is a direct consequence of this minimal design. Bottlerocket boots directly into its container runtime and kubelet, bypassing the lengthy boot processes of traditional OSs that involve numerous services and checks. It’s optimized for quickly joining the EKS cluster and becoming ready to schedule pods.
Internal workings: Bottlerocket uses a combination of systemd for service management and a custom init system. The core container components are managed as services. When a node registers with the EKS control plane, the kubelet on Bottlerocket takes over, reporting the node’s status and capabilities. Pods are then scheduled onto these nodes, and the container runtime pulls the necessary images and starts the containers. The node’s configuration, including EKS-specific settings and any user-defined customizations via the settings.toml file, is managed through a dedicated API.
The Bottlerocket configuration is managed via a settings.toml file. This file allows you to define various aspects of the node’s behavior, such as network settings, API endpoints, and even custom user data. For example, to enable specific kernel parameters or configure the container runtime, you would modify this settings.toml file and apply it to your node group.
# Example snippet from settings.toml to enable specific kernel modules
[kernel]
[kernel.modules]
[kernel.modules.load]
"overlay" = true
"br_netfilter" = true
This configuration snippet ensures that the overlay and br_netfilter kernel modules are loaded at boot time, which are often required for advanced networking features in Kubernetes. This declarative approach to configuration simplifies management and ensures consistency across your fleet of nodes.
One critical aspect of Bottlerocket’s security is its role-based access control (RBAC) for its API. You can control who or what can modify the node’s configuration. This is often done by integrating with AWS IAM. For instance, you can create an IAM role that allows your EKS control plane or a specific automation tool to update the settings.toml configuration without granting direct administrative access to the nodes themselves. This is crucial for maintaining a secure and auditable environment.
The next hurdle you’ll likely encounter is managing custom software or binaries that aren’t part of the Bottlerocket base image.