Bottlerocket 不运行 systemd 等传统 init 系统，因其是专为容器设计的精简 OS，移除非必要用户态服务以最小化攻击面、加速启动并实现原子更新；运维须通过 Kubernetes API 或 apiclient，配置由 settings API 统一管理。

为什么 Bottlerocket 不直接运行 systemd 或传统 init 系统

Bottlerocket 本质是“只跑容器”的 OS，它砍掉了所有非必需的用户态服务——包括 systemd、sshd、bash（默认不带）、甚至 curl 和 ps。这不是为了炫技，而是让攻击面最小化、启动更快、更新更原子。

实际影响是：你不能用 systemctl restart kubelet，也不能 ssh 进去改配置；所有运维必须走 Kubernetes API 或 Bottlerocket 自带的 apiclient 工具。

• 所有节点配置通过 settings API 控制，比如 host-containers.<container-name>.enabled</container-name>
• kubelet 是唯一被允许直接管理容器的组件，其他容器必须通过 host-containers 声明式启用
• 没有 /etc/systemd/system，也没有 /usr/bin 下的通用工具链——想调试？得用 apiclient 或临时启用 admin-container

如何在 Bottlerocket 上安全启用 admin-container 调试

官方明确不推荐长期开启 admin-container，但它确实是排查网络、证书、kubelet 启动失败等问题的唯一入口。关键不是“能不能开”，而是“怎么开才不破坏安全模型”。

它不是一个 shell，而是一个受限的、只读挂载了 host rootfs 的容器，镜像由 AWS 维护（如 public.ecr.aws/bottlerocket/admin-container:1.15.0），且默认禁用。

• 启用方式只能通过节点启动时的 userdata（或 AMI 设置）：设置 settings.host-containers.admin.enabled = true
• 切勿在运行中用 apiclient 动态开启——这会触发 reboot，因为 settings 变更需原子更新
• 进入后没有 sudo，不能写 host 文件系统；mount、ip、nsenter 等工具存在但权限受限
• 若看到 Failed to connect to api.bottlerocket.aws:8000，大概率是 kubelet 没起来或 CNI 未就绪，此时 admin-container 本身可能无法拉起

kubelet 配置差异：Bottlerocket 不支持 --config 文件路径

Bottlerocket 的 kubelet 启动参数完全由 OS 层控制，不读取 /var/lib/kubelet/config.yaml，也不接受 --config 参数。所有配置项映射为 settings 键值，例如：

linux-sysadmin

Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...

下载

settings.kubernetes.cluster-dns = ["10.100.0.10"] → 对应传统 --cluster-dns

settings.kubernetes.node-labels = "node.kubernetes.io/lifecycle=spot" → 对应 --node-labels

• 错误做法：往 /etc/kubernetes/kubelet.conf 写内容，或试图挂载自定义 configmap —— kubelet 启动时会忽略
• 正确路径：所有配置必须通过 apiclient 提交，或在节点启动前固化进 userdata / Ignition config
• 常见坑：settings.kubernetes.cluster-domain 默认是 cluster.local，但如果你的 CoreDNS 配置了不同 domain，这里不一致会导致 Service DNS 解析失败
• 性能影响：每次 apiclient put 都触发 reboot，频繁调用等于频繁中断 workload —— 配置务必一次对齐

AMI 更新与 os-release 版本号怎么看

Bottlerocket 的版本不是靠 uname -r 或 cat /etc/os-release 直观判断的。它的版本号结构是 1.15.0-9762c5a5，其中后缀是构建哈希，不是语义化版本的一部分。

真正决定兼容性的，是 AMI ID 和对应的 release-channel（如 stable、testing），而非表面数字。

• 查当前版本：运行 apiclient get settings.os.version，返回类似 "1.15.0"
• 查 AMI 是否匹配集群要求：Kubernetes 1.28 要求 Bottlerocket ≥ 1.14.0，但具体到 patch 版本，得看 GitHub Release 页面 的 Supported Kubernetes Versions 表格
• 升级不是 yum update，而是替换节点：新 AMI + 新 userdata + 滚动更新策略；旧节点上的容器不会自动迁移，必须靠控制器（如 Deployment）重建
• 容易忽略的一点：settings.kernel.parameters 修改后，即使只是加一个 net.ipv4.ip_forward=1，也会导致 kernel 重启——因为 Bottlerocket 把 kernel 参数也纳入原子更新范围