Kubernetes 不直接管理日志长期存储，而是通过 stdout/stderr 输出、DaemonSet 或 Sidecar 模式采集日志，并借助 Operator 实现声明式管理，推荐结构化 JSON 日志与 Loki/Elasticsearch 后端。
Kubernetes 本身不直接管理日志的长期存储或集中分析，而是提供统一的日志输出接口和生命周期无关的采集基础。真正的日志采集与收集，依赖外部方案协同实现。核心思路是：让日志脱离 Pod 和节点生命周期，统一接入可持久、可检索的后端系统。
基于 stdout/stderr 的标准路径
容器应用应优先将日志输出到标准输出（stdout）和标准错误（stderr）。Kubernetes 运行时（如 containerd 或 dockerd）会自动将其转存为 JSON 格式文件，路径通常为 /var/log/pods/<pod-uid>/<container-name>_<index>.log。这是所有采集方案的共同起点。
-
kubectl logs <pod-name>就是读取这个路径下的内容 - 不建议应用自行写文件到容器内路径（如
/app/logs/），否则需额外处理
DaemonSet 模式：节点级轻量采集
在每个 Node 上部署一个日志代理（如 Filebeat、Fluent Bit），通过 hostPath 挂载宿主机的 /var/log/pods 和 /var/log/containers 目录，实时读取新生成的日志文件。
针对 Kubernetes 仪表板和 Web UI 的浏览器自动化。适用于与 Kubernetes Dashboard、Grafana、ArgoCD UI 或其他 Web 界面交互。需要设置 MCP_BROWSER_ENABLED=true。
- 优势：资源开销低、部署简单、天然支持多容器日志分离
- 注意点：需配置
cri解析器（尤其 containerd 环境），启用db文件避免重复采集 - 典型配置项：
input.type = tail、parser = cri、path = /var/log/pods/*/*.log
Sidecar 模式：Pod 级精细控制
为关键业务 Pod 注入一个专用日志容器（如 Fluent Bit Sidecar），共享 emptyDir 或 hostPath 卷，直接读取主容器写入的文件，或接管其 stdout/stderr 流。
- 适用场景：主容器无法改日志输出方式（如遗留 Java 应用）、需定制解析规则、隔离敏感日志
- 风险提示：Sidecar 会增加 Pod 资源占用；若主容器日志未重定向到 stdout，则
kubectl logs查不到内容
借助 Operator 实现声明式管理
使用 Logging Operator（如 Banzai Cloud 或 OpenShift Logging）通过 CRD 定义采集策略。例如创建 Logging 和 Flow 资源，自动注入采集配置、关联命名空间、注入元数据（pod_name、namespace、container_name）。
- 自动适配 Pod 创建/销毁事件
- 支持动态过滤、字段增强、多目标输出（Elasticsearch + Loki + S3）
- 减少手动维护 ConfigMap 和 DaemonSet 的复杂度
必须配套的关键实践
- 日志格式尽量用结构化 JSON，避免纯文本解析困难
- 启用容器层日志轮转（如 Docker 的
--log-opt max-size=10m --log-opt max-file=3）防止磁盘打满 - 采集时注入 Kubernetes 元信息（labels、annotations、node name），便于按业务维度聚合查询
- 输出目标推荐 Loki（轻量、Prometheus 生态兼容）或 Elasticsearch（全文检索强）
不复杂但容易忽略
