Distroless 的 Fluent Bit 容器里如何执行脚本?

Distroless 镜像没有 shell 和包管理器,无法直接执行脚本。解决方案:自制镜像拷贝 bash 与脚本、改用带包管理器的基础镜像、或用 K8s initContainer 在容器外完成初始化。本文给出三种方案。

最佳实践
Distroless 的 Fluent Bit 容器里如何执行脚本?封面

Distroless 镜像里只有 fluent-bit 二进制本身——没有 shell,脚本无从执行。三种出路:自制镜像把 bash 和脚本拷进去、换 Alpine 等带 shell 的基础镜像、或把初始化逻辑挪到 K8s initContainer。

方案一:自制镜像拷贝 bash

FROM fluent/fluent-bit
COPY --from=busybox:latest /bin/sh /bin/sh
COPY entrypoint.sh /entrypoint.sh
ENTRYPOINT ["/bin/sh", "/entrypoint.sh"]

从 busybox 借一个静态 shell 拷进来,配合自定义入口脚本。

方案二:换带包管理器的基础镜像

FROM alpine:3.19
RUN apk add --no-cache fluent-bit
COPY entrypoint.sh /entrypoint.sh
ENTRYPOINT ["/entrypoint.sh"]

镜像略大但获得完整 shell 与 apk 生态,调试方便。

方案三:K8s initContainer(推荐)

需要"启动前先处理点事"(渲染配置、等待依赖)的场景,K8s 原生解法:

initContainers:
  - name: init-config
    image: busybox
    command: ['sh', '-c', 'envsubst < /config-template/fluent-bit.conf > /shared/fluent-bit.conf']
    volumeMounts: [{name: shared, mountPath: /shared}]
containers:
  - name: fluent-bit
    image: fluent/fluent-bit
    volumeMounts: [{name: shared, mountPath: /fluent-bit/etc}]

主容器保持 distroless 的安全优势,初始化在 init 容器完成。

常见问题(FAQ)

Q:为什么官方用 distroless? 攻击面最小——没有 shell,入侵者拿到容器也几乎干不了什么。

Q:临时排障想进容器怎么办? kubectl debug 挂一个临时调试容器,或用 crictl 在节点上检查文件系统。

获取专属方案

联系我们

加入社区

微信扫码
加入官方交流群

立即体验

在线开通,按量计费,真正的云服务!

立即开始

选择观测云版本

代码托管平台