核心是减少日志写入对容器和宿主机的干扰，需从驱动选型、缓冲机制、轮转策略三方面优化：换掉默认json-file驱动，优先选用自带压缩与轮转的local驱动或支持异步的fluentd/Fluent Bit驱动；严格配置max-size（10M–50M）、max-file（3–5份）和compress:true；启用异步日志处理并精简Hubble采样率与应用日志级别。
核心是减少日志写入对容器和宿主机的干扰，避免磁盘 I/O 压力、CPU 占用飙升和日志丢失。不靠堆硬件，关键在驱动选型、缓冲机制和轮转策略这三块。
换掉默认 json-file 驱动
json-file 看似简单，但高频输出时会持续刷磁盘，容易拖慢容器甚至卡死节点。生产环境别硬扛。
-
local 驱动最省心：自带压缩和轮转，不依赖外部服务，适合大多数场景。配置示例：
{"log-driver":"local","log-opts":{"max-size":"20m","max-file":"5","compress":"true"}} - fluentd 或 Fluent Bit 驱动更灵活：日志先进内存缓冲再批量发出去，应用完全无感知。需额外部署 Fluent Bit，但换来了稳定性和可扩展性。
- syslog 要慎用：网络一抖就丢日志，没重试和缓冲机制，只适合已有成熟 syslog 架构的老系统。
必须配好日志轮转和压缩
不管用哪种驱动，不设限制等于埋雷。一个跑一周的容器能把磁盘撑爆，运维半夜被报警叫醒不是段子。
- max-size 控制单文件大小：建议 10M–50M 之间。太小导致频繁滚动，太大影响读取和清理效率。
- max-file 设定保留份数：3–5 份够排查问题，再多只是占空间。旧文件自动归档为 .gz，压缩率通常达 70% 以上。
- compress:true 必开：滚动时自动 gzip，磁盘占用直降，且不影响后续 grep 或日志工具解析。
让日志处理异步化
同步写日志 = 应用等磁盘响应，尤其在高并发打日志时，延迟肉眼可见。目标是“写了就忘”，不卡主线程。
- 用 fluentd 驱动时，加 "fluentd-async":"true"，日志进队列就返回，Fluent Bit 后台慢慢发。
- local 驱动虽不支持异步参数，但它内部已做缓冲和批写，配合合理 max-size 实际效果接近异步。
- 禁用 mode=blocking（默认就是 blocking），确认配置里没手动设成阻塞模式。
精简 Hubble 和应用日志的并发压力
Cilium 开启 Hubble 后，网络流日志 + 应用 stdout 一起猛灌，CPU 和内存双吃紧，尤其在 Node 数量多、Pod 密度高的集群里。
- Hubble 默认全量采集，改成采样模式：hubble-flow-sampling-ratio: "100" 表示每 100 条流只存 1 条。
- 业务日志别打 DEBUG 级别满屏刷，上线前关掉冗余日志；用结构化字段（如 JSON）替代纯文本，下游解析更快。
- 非核心容器可考虑 --log-driver=none，比如健康检查 sidecar，本身就不需要日志。
