pod重启后日志丢失？ pod重启原因定位？

K8S出现问题,排查秘诀!

网络问题：检查Calico等网络插件的状态，确保网络通信正常。存储问题：Pod挂载的共享存储连接不上可能导致POD启动异常。此时，需要检查共享存储和存储卷的状态是否正常。代码问题：应用程序代码在容器启动后失败。需要排查应用程序代码，确保其能在容器环境中正确运行。

记录一次calico无法启动问题的排查过程

1、尝试重启containerd或Docker服务，看是否能解决问题。使用systemctl restart containerd或systemctl restart docker重启服务。检查内核参数：确认系统的内核参数是否支持容器的正常运行。检查如CONFIG_NAMEspaceS、CONFIG_IPC_NS等内核配置是否启用。

2、检查网络配置和防火墙规则：确认集群的网络配置是否正确，包括CIDR、节点间的通信方式等。检查是否有防火墙规则阻止了calico-node与其他组件的必要通信。调整系统资源限制：如果系统的资源限制（如线程数）导致kubelet无法初始化线程，从而影响calico-Node的启动，可以尝试增加系统的资源限制。

3、网络问题：检查Calico等网络插件的状态，确保网络通信正常。存储问题：pod挂载的共享存储连接不上可能导致Pod启动异常。此时，需要检查共享存储和存储卷的状态是否正常。代码问题：应用程序代码在容器启动后失败。需要排查应用程序代码，确保其能在容器环境中正确运行。

干货|kubernetes日志运维痛点及高效解决方案总结

Kubernetes日志运维痛点及高效解决方案总结运维痛点 日志采集的可靠性与复杂性 pod 生命周期短、易销毁：容器重启或 Pod 被销毁后，日志容易丢失，除非已进行持久化或集中采集。

社区解决方案：kubegateway。CoreDNS Coredns是KuberneTES的核心组件，支持内部域名解析。反亲和性：增加应用的反亲和性，防止coreDNS调度到同一台主机上，提高可用性。扩缩机制：根据集群规模选择合适的coredns扩缩机制，避免使用hpa，推荐使用cluster-proportional-autoscaler根据node节点数伸缩dns。

在 Kubernetes 环境中，由于容器的动态伸缩等特性，日志的收集和展示过程相对复杂。为了简化这一过程，可以利用 MaxCloud 提供的 EFK（ELasticsearch，Fluentd，Kibana）解决方案，实现一键部署，快速搭建 k8s 日志采集、分析、展示平台。

一次意想不到的pod内存驱逐问题

答案：此次Pod驱逐问题的原因是K8S集群中的kubelet服务未正确识别到节点内存扩容后的新配额，导致在内存使用达到原配额上限时触发了Pod驱逐。详细分析：案发现场：客户反馈门户网站无法打开，多个Pod状态为Evicted（驱逐）。

以下是三个大厂K8s集群故障案例：案例一：电商平台促销活动Pod驱逐故障问题现象：促销活动期间，超30%的Pod进入Evicted状态，多个Worker节点内存使用率超95%，用户支付失败率从0.1%升至15%。根因分析：节点内存不足触发kubelet主动驱逐机制，recommendation - Service的Pod内存占用异常高且未设置内存限制。

在Linux系统层面，内存不足导致进程被kill的现象较为常见。通过命令`dMESg | tail -N`，您可以查看近N行系统日志，寻找被kill的进程信息。

在KuberNETes（K8S）环境中，当Pod使用的内存超过其限制时，会发生内存溢出（OOM）并被K8S重启。这里讨论的是一个特殊的内存溢出案例，其特殊之处在于问题并非由Java虚拟机（JVM）引起。问题背景 Pod内存分配：该服务所在的Pod被设置为2G内存限制，超过此限制将触发K8S的OOM重启机制。

Kubernetes OOM（内存不足）问题 Pod 中的每个容器都需要内存才能运行。当容器使用的内存超过其限制时，linux 内核的 OOM Killer 会终止该进程以回收内存。OOM 的触发条件：容器使用的内存超过其设置的 limits。节点上的内存资源不足，导致 Kubernetes 需要驱逐一些 Pod 以释放内存。