1: Pod始终处于pending状态 详细描述: Pod始终处于pending状态 解题思路: 如果pod保持在pending的状态,意味着无法被正常的调度到节点上,由于系统的某些资源无法满足Pod的运行需求 原因分析: 系统没有足够的资源或者用户指定了hostPort;通过hostPort用户能够将服务暴露到指定的主机端口上,会限制pod被调度到可运行节点上 ...
排错经历:首先排查了kube-proxy是否正常,发现启动都是正常的,然后也重启了,还是一样ping不通,然后又排查了网络插件,也重启过flannel,依然没有任何效果。后来想到自己的另一套k8s环境,是能正常ping通service的,就对比这两套环境检查配置,发现所有配置中只有kube-proxy的配置有一点差别,能ping通的环境kube-proxy使用了-...
能够ping通,并且不影响正常访问服务 Headless: ClusterIP=None Headless svc 不会分配 clusterIP,而是返回对应 DNS 的 A 记录,如果 svc 后端有3个 pod 则返回 3 个 pod IP。访问 svc 时会随机选择一个 IP,所以 headless svc 是可以 ping 通的。【ping service的名称,就和pingbaidu.com的原理是一样的】 Lo...
1. 确认Pod网络策略配置是否正确 网络策略可能限制了Pod之间的通信。使用以下命令检查Pod的网络策略配置: bash kubectl describe pod [pod_name] -n [namespace_name] 查看输出中的Network Policies部分,确认是否有策略阻止了Pod的访问。 2. 检查Pod所在的节点网络状态 Pod的网络问题有时可能与其所在的节点有关。...
必须得有一个 Service 名称为 b,这是前提。 在容器内,会根据 /etc/resolve.conf 进行解析流程。选择 nameserver 10.68.0.2 进行解析,然后,用字符串 “b”,依次带入 /etc/resolve.conf 中的 search 域,进行DNS查找,分别是: // search 内容类似如下(不同的pod,第一个域会有所不同) ...
k8s集群中pod内不能访问clusterIP和service 排错背景:在一次生产环境的部署过程中,配置文件中配置的访问地址为集群的Service,配置好后发现服务不能正常访问,遂启动了一个busybox进行测试,测试发现在busybox中,能通过coredns正常的解析到IP,然后去ping了一下service,发现不能ping通,ping clusterIP也不能ping通。
集群启动之后,kube-system namespace 下的 pod 看起来都是 running 的。 为了演示问题,我们先使用 k8s 官方的debug service部署进行复现,按照文档中的部署,会有一个 busybox pod,以及三个 hostnames pod, 我们让三个 hostnames pod 恰好分布在三个不同的节点上。
因为server端连接地址在我本地和集群宿主机上是可以正常调用,因此怀疑服务pod到server端地址不通,进入到pod中进行测试,发现的确不能调用,使用ping域名也是可以通的,但是发现ping解析出来的ip地址并不是我们server端的外网ip地址;因此怀疑到了dns解析的问题上,使用nsloopup命令进行排除(通常服务都没有该命令需要手动安装...
因为server端连接地址在我本地和集群宿主机上是可以正常调用,因此怀疑服务pod到server端地址不通,进入到pod中进行测试,发现的确不能调用,使用ping域名也是可以通的,但是发现ping解析出来的ip地址并不是我们server端的外网ip地址;因此怀疑到了dns解析的问题上,使用nsloopup命令进行排除(通常服务都没有该命令需要手动安装...