直接回答：三种主流模式：节点级采集（DaemonSet 跑 Fluent Bit/Vector，读 /var/log/containers 下 kubelet 落盘的容器 stdout/stderr，资源占用最低、与应用解耦，默认答案）；sidecar 采集（每个 Pod 带一个采集容器读共享卷里的日志文件，适合应用只写文件不写 stdout、或需要按应用定制解析的场景，代价是资源翻倍与部署侵入）；应用直推（SDK/客户端直接写日志后端，链路最短但强依赖应用改造，网络分区时丢日志风险自担）。
展开解析：DaemonSet 模式的工程细节：容器运行时每行日志带 CRI 元信息且按大小轮转切割，采集器要用 CRI parser 重组多行堆栈（Java 异常被切成几十行的经典问题）；用 Kubernetes 元数据（namespace、labels）做富化与路由——不同业务线发不同 Kafka topic/ES 索引；节点本地 buffer（磁盘队列）防下游抖动丢数据。规模化的坑：高日志量节点采集器自身要吃 CPU/内存配额（得留 requests）；落盘速率超 IO 能力时标准输出本身成瓶颈（可考虑 logging 写到 emptyDir 再采集）；多行合并与正则解析尽量放在采集端而非昂贵的中转层。选型建议一句话：90% 场景 DaemonSet + 中心化管道（Kafka→ES/Loki）够用，sidecar 留给写文件日志的遗留应用，直推留给审计级“绝不丢”的链路并配合本地落盘兜底。
追问方向：stdout 与写文件两种日志方式在 K8s 下各有什么运维差异？采集延迟如何监控？
（约 480 字）