在 k8s 中对指定 Pod 进行抓包

标签: | 发表时间:2020-06-27 10:49 | 作者:
出处:https://ruofeng.me

近日在研究微服务架构中的 Distributed Tracing时,遇到了一些问题,需要深入到底层去进行网络抓包分析报文。但是应用时运行在 k8s 集群中的,与传统的在一台机器上跑一个进程直接通过 tcpdump 抓包方式略有不同。最初对容器的理解不深刻认为一定要进入到这个容器抓包,而进入容器内并没有 tcpdump 等基础工具,相当于自己还是把容器当作虚拟机在看待。而实际上 它们只是在宿主机上不同 namespace 运行的进程而已。因此要在不同的容器抓包可以简单地使用命令切换 network namespace 即可,可以使用在宿主机上的 tcpdump 等应用。

查看指定 pod 运行在哪个宿主机上

    kubctl describe pod <pod> -n mservice

获得容器的 pid

    docker inspect -f {{.State.Pid}} <container>

进入该容器的 network namespace

    nsenter --target <PID> -n

使用 tcpdump抓包,指定 eth0 网卡

    tcpdump -i eth0 tcp and port 80 -vvv

或者直接抓包并导出到文件

    tcpdump -i eth0 -w ./out.cap

从远程 scp 到本地

    scp [email protected]:/home/ruofeng/out.cap ./

之后在 Wireshark 中可以打开文件非常直观得查看过滤抓到的数据。


相关 [k8s pod] 推荐:

深入掌握K8S Pod - Yabea - 博客园

- -
K8S configmap介绍. Pod是k8s中最小的调度单元,包含了一个“根容器”和其它用户业务容器. 如果你使用过k8s的话,当然会了解pod的基本使用,但是为了更好的应用,你需要深入了解pod的配置、调度、升级和扩缩容等. pod包含一个或多个相对紧密耦合的容器,处于同一个pod中的容器共享同样的存储空间、IP地址和Port端口.

k8s外网如何访问业务应用之Service 池化pod

- - IT瘾-geek
一、废话:先讲述一个k8s重要概念,我觉得这个概念是整个k8s集群实现微服务的最核心的概念. Service定义了Pod的逻辑集合和访问该集合的策略,是真实服务的抽象. Service提供了一个统一的服务访问入口以及服务代理和发现机制,用户不需要了解后台Pod是如何运行. 只需要将一组跑同一服务的pod池化成一个service,k8s集群会自动给这个service分配整个集群唯一ip和端口号(这个端口号自己在yaml文件中定义),一个service定义了访问pod的方式,就像单个固定的IP地址和与其相对应的DNS名之间的关系.

在 k8s 中对指定 Pod 进行抓包

- -
Distributed Tracing时,遇到了一些问题,需要深入到底层去进行网络抓包分析报文. 但是应用时运行在 k8s 集群中的,与传统的在一台机器上跑一个进程直接通过 tcpdump 抓包方式略有不同. 最初对容器的理解不深刻认为一定要进入到这个容器抓包,而进入容器内并没有 tcpdump 等基础工具,相当于自己还是把容器当作虚拟机在看待.

k8s 部署 skywalking 并将 pod 应用接入链路追踪

- - SegmentFault 最新的文章
前面写了两篇文章介绍使用 docker 部署 spring boot 和 tomcat 项目,并将其接入skywalking,这篇文章主要介绍使用 k8s 部署 skywalking 并将 pod 应用接入链路追踪. 二、使用 helm 部署 skywalking. 在 k8s 中使用 helm 的前提是需要先安装 helm 客户端,关于 helm 的安装可以查看官方文档.

排查 K8S Pod 被 OOM 的思路及建议

- - 明哥教程
K8S + 容器的云原生生态,改变了服务的交付方式,自愈能力和自动扩缩等功能简直不要太好用. 有好的地方咱要夸,不好的地方咱也要说,真正的业务是部署于容器内部,而容器之外,又有一逻辑层 Pod. 对于容器和 K8S 不怎么熟悉的人,一旦程序发生了问题,排查问题就是个头疼的问题. 这两天一直在排查一个 Pod OOM 的问题,花了不少的时间,感觉有必要写下来,帮助自己梳理的同时,也能给其他人一些思路.

图解 K8S(03):从 Pause 容器理解 Pod 的本质

- - 明哥教程
在 K8S 中,Pod 是最核心、最基础的资源对象,它是 Kubernetes 中调度最小单元,学习 K8S 很多时候,我们都是在跟 Pod 打交道,它的内容是最多的,需要分好多的章节才能将它讲透. 本篇作为 Pod 的首篇,打算先从咱们熟悉的 Docker 容器入手,介绍 Pod 的组成及其工作原理.

影响K8S Pod分配和调度策略的两大关键特性

- - DockOne.io
在Kubernetes中有一个最复杂的调度器可以处理pod的分配策略. 基于在pod规范中所提及的资源需求,Kubernetes调度器会自动选择最合适的节点来运行pod. 但在许多实际场景下,我们必须干预调度过程才能在pod和一个节点或两个特定pod之间进行匹配. 因此,Kubernetes中有一种十分强大的机制来管理及控制pod的分配逻辑.

k8s资源需求和限制, 以及pod驱逐策略 - ainimore - 博客园

- -
requests:需求,最低保障, 保证被调度的节点上至少有的资源配额 limits:限制,硬限制, 容器可以分配到的最大资源配额. 如果Pod中所有Container的所有Resource的limit和request都相等且不为0,则这个Pod的QoS Class就是Guaranteed. 注意,如果一个容器只指明了limit,而未指明request,则表明request的值等于limit的值.

CentOS7 安装 K8S

- - 企业架构 - ITeye博客
前提:VirtualBox CentOS7. 物理机IP   192.168.18.8. 虚拟机1IP:192.168.18.100(VMaster master). 虚拟机2IP:192.168.18.101(VServer1 node1). 虚拟机3IP:192.168.18.102(VServer2 node2).

k8s水平扩容

- - Bboysoul's Blog
k8s 的好处就是可以弹性水平扩容和纵向扩容,平时纵向扩容用的不太多,所以今天说说水平扩容,在创建hpa之前你要确定集群中已经安装了metrics-server,我使用的是k3s,直接自带. 首先创建需要的容器,下面是dockerfile. 原理就是当你访问index.php的时候会进行一个循环计算来提高cpu的使用率.