K8s实战小技巧——该如何查看pod崩溃前的日志

这篇具有很好参考价值的文章主要介绍了K8s实战小技巧——该如何查看pod崩溃前的日志。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

使用场景

当pod处于crash状态的时候,容器不断重启,此时用 kubelet logs 可能出现一直捕捉不到前一个奔溃POD日志。本文就教你如何捕捉POD奔溃日志。

解决方法:kubectl previous

kubectl previous 参数作用:If true, print the logs for the previous instance of the container in a pod if it exists.

  • 单容器pod:
kubectl logs pod-name --previous
  • 多容器pod:
kubectl logs pod-name --previous -c container-name

比如:

NAME                              READY       STATUS             RESTARTS   AGE
nginx-7d8b49557c-c2lx9            2/2        Running            5   

kubectl logs nginx-7d8b49557c-c2lx9 --previous
Error: xxxxxxxxxxx

原理

kubelet会保持pod的前几个失败的容器,这个是查看的前提条件。

核心原理

kubelet实现previous的原理:将pod的日志存放在 /var/log/pods/podname,并且是链接文件,链接到docker的容器的日志文件,同时kubelet还会保留上一个容器,同时有一个链接文件链接到pod上一个崩溃的容器的日志文件,使用previous就是查看的这个文件

实践

比如查看一个pod:

ubuntu@~$ kubelet get pod
NAME                     READY   STATUS    RESTARTS   AGE
busybox                  1/1     Running   2394       99d
nginx-deployment-6wlhd   1/1     Running   0          79d
redis                    1/1     Running   0          49d

到pod所在node查看kubelet放的两个日志文件:

 ls /var/log/pods/default_busybox_f72ab71a-5b3b-4ecf-940d-28a5c3b30683/busybox
2393.log  2394.log

数字的含义:2393 证明是第 2393 次重启后的日志,2394 代表是第2394次重启后的日志。

实际这两个日志文件是链接文件,指向了docker的日志文件:

/busybox# stat 2393.log
  File: 2393.log -> /data/kubernetes/docker/containers/68a5b32c9fdb1ad011b32e6252f9cdb759f69d7850e6b7b8591cb4c2bf00bcca/68a5b32c9fdb1ad011b32e6252f9cdb759f69d7850e6b7b8591cb4c2bf00bcca-json.log
  Size: 173           Blocks: 8          IO Block: 4096   symbolic link
Device: fc02h/64514d    Inode: 529958      Links: 1
Access: (0777/lrwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2023-01-31 13:32:03.751514283 +0800
Modify: 2023-01-31 13:32:03.039526838 +0800
Change: 2023-01-31 13:32:03.039526838 +0800
 Birth: -

 /busybox# stat 2394.log
  File: 2394.log -> /data/kubernetes/docker/containers/2ed9ebf0585215602874b076783e12191dbb010116038b8eb4646273ebfe195c/2ed9ebf0585215602874b076783e12191dbb010116038b8eb4646273ebfe195c-json.log
  Size: 173           Blocks: 8          IO Block: 4096   symbolic link
Device: fc02h/64514d    Inode: 529955      Links: 1
Access: (0777/lrwxrwxrwx)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2023-01-31 14:32:03.991106950 +0800
Modify: 2023-01-31 14:32:03.183119308 +0800
Change: 2023-01-31 14:32:03.183119308 +0800
 Birth: -

看到分别指向了这两个容器的日志文件,一个是当前pod里在跑的容器,一个是pod上次跑的容器,现在已经退出了

docker ps -a
CONTAINER ID        IMAGE                  COMMAND                  CREATED             STATUS                      PORTS               NAMES
2ed9ebf05852        ff4a8eb070e1           "sleep 3600"             24 minutes ago      Up 24 minutes                                   k8s_busybox_busybox_default_f72ab71a-5b3b-4ecf-940d-28a5c3b30683_2394
68a5b32c9fdb        ff4a8eb070e1           "sleep 3600"             About an hour ago   Exited (0) 24 minutes ago                       k8s_busybox_busybox_default_f72ab71a-5b3b-4ecf-940d-28a5c3b30683_2393

使用logs的时候读的是当前容器那个文件,使用 –previous 的时候,读的是上次退出的容器的日志文件,由于kubelet为pod保留了上次退出的容器。

我们手动编辑这两个文件的内容,看kubelet是否读的是这两个文件

/busybox# cat 2393.log
{"log":"last crash logs\n","stream":"stderr","time":"2022-11-05T08:11:27.31523845Z"}

/busybox# cat 2394.log
{"log":"now pod log\n","stream":"stderr","time":"2022-11-05T08:11:27.31523845Z"}

ubuntu@10-234-32-51:~$ k logs busybox --previous
last crash logs
ubuntu@10-234-32-51:~$ k logs busybox
now pod log

由于是链接文件,那么可能实际是从别的地方读的,或者说直接读容器目录下的,由于链接文件我们改了后容器目录下的日志文件也跟着改了,我们直接创建两个文件来做验证:

ubuntu@10-234-32-51:~$ k get pod
NAME                     READY   STATUS    RESTARTS   AGE
busybox                  1/1     Running   2395       99d
nginx-deployment-6wlhd   1/1     Running   0          79d
redis                    1/1     Running   0          49d

/busybox# ls
2394.log  2395.log

/busybox# rm 2394.log  2395.log

我们删除,然后自己创建,这时是regular file,而不是链接文件了:
/busybox# ls
2394.log  2395.log

/busybox# stat 2394.log
  File: 2394.log
  Size: 100           Blocks: 8          IO Block: 4096   regular file
Device: fc02h/64514d    Inode: 529965      Links: 1
Access: (0640/-rw-r-----)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2023-01-31 15:42:11.307170422 +0800
Modify: 2023-01-31 15:42:07.711225229 +0800
Change: 2023-01-31 15:42:07.711225229 +0800
 Birth: -

/busybox# stat 2395.log
  File: 2395.log
  Size: 86            Blocks: 8          IO Block: 4096   regular file
Device: fc02h/64514d    Inode: 529967      Links: 1
Access: (0640/-rw-r-----)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2023-01-31 15:41:17.539989934 +0800
Modify: 2023-01-31 15:41:14.348038586 +0800
Change: 2023-01-31 15:41:14.352038525 +0800
 Birth: -

/busybox# cat 2394.log
{"log":"previous logs create by myself\n","stream":"stderr","time":"2022-11-05T08:11:27.31523845Z"}
/busybox# cat 2395.log
{"log":"create by myself\n","stream":"stderr","time":"2022-11-05T08:11:27.31523845Z"}

ubuntu@10-234-32-51:~$ k logs busybox
create by myself
ubuntu@10-234-32-51:~$ k logs busybox --previous
previous logs create by myself

得出结论

kubelet读的是 /var/log/pods/ 下的日志文件,–previous 读的也是 /var/log/pods/ 下的日志文件,且专门有个链接文件来指向上一个退出容器的日志文件,以此来获取容器崩溃前的日志。文章来源地址https://www.toymoban.com/news/detail-531933.html

到了这里,关于K8s实战小技巧——该如何查看pod崩溃前的日志的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • 【云原生 | Kubernetes 系列】K8s 实战 如何给应用注入数据 II 将pod数据传递给容器

    在上一篇文章中,我们学习了针对容器设置启动时要执行的命令和参数、定义相互依赖的环境变量、为容器设置环境变量,三种设置方式,本篇文章,我们将继续学习数据的传递。 有两种方式可以将 Pod 和 Container 字段传递给运行中的容器: 环境变量 卷文件 这两种呈现 Pod

    2024年01月25日
    浏览(66)
  • k8s查看所有在运行pod内的镜像版本

    本地跑的算法镜像有时候与线上跑的环境不一致,这时候又需要同步,每一个都去查找又很麻烦 这时候查看两边的镜像,选取其中不同的地方edit一下,就方便多了 名称空间更改为自己的名称空间 查询镜像并去重,有名称空间的  记得把名称空间加上  同时显示pod名称和镜像

    2024年02月12日
    浏览(48)
  • k8s主节点部署pod状态一直是pending原因排除,并彻底删除pod技巧

    一般来说,master节点是会产生一个污点,不允许部署pod的。 如果其他原因也可以使用这个命令检查状态原因 当出现类似这样问题 问题描述: Warning FailedScheduling 40s (x28 over 28m) default-scheduler 0/1 nodes are available: 1 node(s) had untolerated taint {node-role.kubernetes.io/master: }, that the pod didn’

    2024年01月19日
    浏览(34)
  • (二)k8s实战-深入Pod详解

    创建Pod nginx样例 参数名 类型 字段说明 apiVersion String K8S APl 的版本,可以用 kubectl api versions 命令查询 kind String yam 文件定义的资源类型和角色 metadata Object 元数据对象,下面是它的属性 metadata.name String 元数据对象的名字,比如 pod 的名字 metadata.namespace String 元数据对象的命名

    2024年02月11日
    浏览(24)
  • k8s查看当前命名空间下所有运行的 pod 对应的镜像

    1,查看镜像 2,去重查看 3, 同时显示pod名称和镜像 4,查看所有deployment和其中的镜像

    2024年02月02日
    浏览(38)
  • Filebeat 采集 k8s Pod 和 Events 日志实战操作

    要使用 Filebeat 采集 Kubernetes 中的 Pod 和 Events 日志,您需要配置 Filebeat 以适应这两种类型的数据。以下是详细说明: 1)采集 Pod 日志流程介绍 Pod 日志是容器内产生的日志数据。 Filebeat 可以监控这些日志并将它们发送到中央存储或分析系统。下面是如何配置 Filebeat 来采集

    2024年02月04日
    浏览(31)
  • k8s中如何正确删除pod

    --- ♦ 在日常的k8s运维过程中,避免不了会对某些pod进行剔除,那么如何才能正确的剔除不需要的pod呢? 首先,需要查出想要删除的pod kubectl 删除pod命令 可是这里你会发现,在进行删除delete pod后,并不会直接删除。该pod会自动重新构建(可以理解为重启、重构),原因是k

    2023年04月27日
    浏览(27)
  • k8s如何访问 pod 元数据

    **我们在 pod 中运行容器的时候,是否也会有想要获取当前 pod 的环境信息呢?**咱们写的 yaml 清单写的很简单,实际上部署之后, k8s 会给我们补充在 yaml 清单中没有写的字段,那么我们的 pod 环境信息和容器的元数据如何传递到容器中呢?是不是也是通过获取这些 k8s 默认给

    2024年02月16日
    浏览(36)
  • 如何批量删除k8s中的异常pod信息

    kubectl get pods 发现有很多pod出问题了 Evicted可使用kubectl中的强制删除命令 批量删除所有“Evicted”状态的pod即可 OutOfCpu可使用kubectl中的强制删除命令 批量删除所有“OutOfcpu ”状态的pod即可 Terminating可使用kubectl中的强制删除命令

    2024年02月12日
    浏览(26)
  • 如何在K8s中实现 Pod 的自动扩展

    在 Kubernetes 中实现 Pod 的自动扩缩,你可以使用 HorizontalPodAutoscaler 资源。以下是一个简单的例子: 首先,你需要确保你的 Kubernetes 集群中已经安装了 Metrics Server,因为 HPA 需要它来获取 Pod 的资源使用情况。 1、部署 Metrics Server(如果尚未部署): kubectl apply -f https://github.com/

    2024年03月27日
    浏览(37)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包