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 工具。
- 所有节点配置通过
settingsAPI 控制，比如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 键值，例如：
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 参数也纳入原子更新范围
