1. 是否可以获取该应用的旧Pod日志？ #

得分两种情况来看：

• 如果旧Pod还处于Terminating状态（集群还没彻底清理掉它），直接用kubectl logs <旧Pod完整名称>就能拿到日志；
• 如果旧Pod已经被彻底删除，默认kubelet不会在节点上长期保留这些日志文件（节点日志一般存在/var/log/pods/目录，但会被定期清理）。要是之前没部署日志采集工具把日志同步到外部存储，那大概率就拿不到了。所以生产环境里，提前搭建日志聚合系统持久化所有Pod日志是很有必要的。

2. 是否可以配置单个Pod可累积的日志大小？ #

当然可以，主要有两种常用方式：

• 容器日志驱动配置：如果用的是json-file这类kubelet默认的日志驱动，可在Pod YAML的容器部分添加日志轮转参数。示例：

  spec:
    containers:
    - name: your-app-container
      image: your-app-image
      args:
        - --log-driver=json-file
        - --log-opt=max-size=100m  # 单个日志文件最大100MB
        - --log-opt=max-file=5     # 最多保留5个轮转日志文件
  

  不同容器运行时（containerd、docker）的配置细节略有差异，也可以通过kubelet全局配置统一设置所有Pod的日志限制。
• Sidecar容器辅助：用Fluentd这类日志处理Sidecar接管应用日志，通过Sidecar的配置控制日志文件的大小和保留数量，这种方式更灵活，还能同时做日志过滤和转发。

3. 日志累积过多导致Pod存储空间不足时，会发生什么情况？ #

后果分两个层面：

• 容器层面：如果容器可写层被日志占满，应用可能因无法写入日志或其他文件直接崩溃；部分应用会抛出磁盘空间不足的错误，无法正常提供服务。
• 节点层面：当节点磁盘被日志耗尽时，kubelet会触发节点驱逐机制，按照Pod的QoS等级（BestEffort > Burstable > Guaranteed）优先驱逐占用资源多的Pod，严重时整个节点的Pod都会受影响，甚至节点本身进入不可用状态。如果配置了日志轮转，kubelet会自动删除最旧的日志文件释放空间；没配置的话，磁盘会一直被占用直至耗尽。

4. Kubernetes中部署的Pod日志，推荐的查看与管理方式是什么？ #

分日常排查和长期管理两个场景来说：

• 日常快速排查：
  • 查看单Pod日志：kubectl logs <pod-name>，多容器Pod加-c <container-name>指定容器；
  • 实时跟踪日志：kubectl logs -f <pod-name>，类似tail -f的效果；
  • 查看容器重启前的日志：kubectl logs --previous <pod-name>，适合排查容器崩溃类问题；
• 长期日志管理：
  • 搭建日志聚合系统：这是生产环境的必备方案，比如轻量的Loki（配合Promtail采集、Grafana可视化）、功能全面的ELK Stack（Elasticsearch存储、Logstash采集、Kibana展示），或者直接用云厂商的托管日志服务，能统一存储、检索所有Pod的日志，包括已删除的旧Pod日志；
  • 强制配置日志轮转：不管用哪种方案，都要给容器设置日志大小和保留数量限制，避免节点磁盘被占满；
  • 结合Deployment版本回溯：用kubectl rollout history deployment/<deploy-name>查看历史版本，若需要回溯旧版本日志，依赖日志聚合系统是最可靠的方式。

内容的提问来源于stack exchange，提问作者Anil Kumar P