一、背景

       由于业务需要，需要提供高可用及自动自动扩容、缩容功能需求，服务部署在K8S中。最近发生一次故障，在问题排查过程中发现系统业务逻辑正常执行，但是打印日志不全，存在部分日志丢失问题。

二、问题描述

      项目服务在K8S中，K8S有3个master节点、2个node节点，项目服务分部在2个node节点上，节点replicas配置数量为5，通过HorizontalPodAutoscaler来控制pod节点自动扩、缩容。在一次变更中由于网络策略问题，只能一个node节点可用。所有5个pod均存在一个node节点上。通过volumeMounts来实现对日志挂载在node节点/opt/log目录下。在故障排查过程中发现pod日志存在丢失，但是业务逻辑正常执行。

三、排查过程

    通过向业务系统（多个pod分布在一个node上）发送测试数据，来排查日志打印问题，第一次发送数据，查看日志文件，日志正常打印，数据库正常入库。第二次发送数据，日志无打印，但数据正常入库，说明业务逻辑正常执行。多次重复发送数据后，发现日志丢失是一个必现的问题，且没有固定概率。猜测可能是因为多个pod日志并发写入造成日志覆盖。

     搭建测试环境，调整pod数量为3，分别分布在三个不同的node上。经过多次发送测试数据，发现，日志打印正常，业务逻辑均正常执行.所以，猜测正确。

    但是，目前没有足够的资源可供扩容，为了先解决问题。只能通过其他方案解决。

四、解决方案

    通过对pod日志分别输出在不同的地址上，这样就不会发生并发写入问题，业务服务虽然统一部署，可以在deployment文件中通过变量来获取pod名称。从而，将不同pod日志打印在对应pod名称的地址下。

  地址输出地址：volumeMounts.subPathExpr: $(POD_NAME)

  指定EVN获取pod名称：

   - name: POD_NAME
              valueFrom:
                fieldRef:
                  apiVersion: v1
                  fieldPath: metadata.name

经过测试，pod日志打印在对应pod名称地址下，不再出现日志丢失问题。