K8S CoreDNS部署失败,问题分析

1. 查询k8s集群部署pod的基本情况

如下图,我们可知容器coredns和dnsutils都部署成功,但是由于域名解析的问题,导致coredns和dnsutils的容器不断重启(原因heath检查,无法请求成功,被kubelet重启了pod)

命令如下:

root >> kubectl get all --all-namespaces -o wide

root >> kubectl describe pod coredns-57bbd778b9-kxl7b -n kube-system

root >> kubectl logs coredns-57bbd778b9-kxl7b -n kube-system

2. 修改VM的DNS解析文件之前,

如下图:cat /etc/resolv.conf 中192.168.3.1是我VM物理机的网卡设置的DNS名称,这个是一个虚拟的错误的DNS地址,实际上是我路由器的IP。

docker exec -it fda365569efa /bin/bash,表示进入k8s容器dnsutils-ds-55fpd内部。

10.3.0.2,这个是我k8s集群中定义和创建的CoreDNS容器的ClusterIP,如果部署成功的话,内外网的域名或服务访问,都可以通过它做地址解析。

问题:如下图,在容器内部,不能正常解析 外网地址www.baidu.com 和 内部地址cluster.local。这里说明是物理机VM的nameserver配置错误导致的。

3. 修改VM的DNS解析文件之后,

# 修改VM机器上的网卡配置文件eno01,如下图替换为正确的DNS地址。

# 这里我们用谷歌的DNS域名地址8.8.8.8 和 本地K8S集群CoreDNS的CluterIP地址10.3.0.2。

root >> vi /etc/sysconfig/network-scripts/ifcfg-eno01

# 然后记得保存,重启VM机器之后,我们在重新检查CoreDNS解析是否正常,操作如下:

root >> cat /etc/sysconfig/network-scripts/ifcfg-eno01

root >> cat /etc/resolv.conf

root >> ping -c 1 www.baidu.com

root >> ping -c 1 10.3.0.2

root >> ping -c 1 kubernetes

root >> nslookup www.baidu.com

root >> nslookup kubernetes

root >> nslookup kube-dns.kube-system.svc

root >> nslookup kube-dns.kube-system.svc.cluster.local

root >> nslookup cluster.local

#### docker 内部检查dns 解析

root >> docker ps | grep dns

dnsutils root >>

原文地址:https://www.cnblogs.com/itshare/p/11368998.html

时间: 2024-08-01 08:18:21

K8S CoreDNS部署失败,问题分析的相关文章

K8S CoreDNS部署失败,发现的一个问题

K8S CoreDNS部署失败,查看错误日志,提示如下 root >> kubectl get all --all-namespaces -o wide root >> kubectl logs -f coredns-56f56989d6-krs6h -n kube-system 错误提示,如下: Failed to list *v1.Namespace: Get https://10.3.0.1:443/api/v1/namespaces?limit=500&resour

Spark on K8S环境部署细节

Spark on K8S环境部署细节 sparkk8s time: 2020-1-3 Spark on K8S环境部署细节 Spark operator安装 准备kubectl客户端和Helm客户端 安装spark operator Spark wordcount 读写OSS 准备oss依赖的jar包 准备core-site.xml 打包支持读写oss的镜像 下载spark安装包解压 打包发布镜像 准备wordcount作业 1. spark submit 提交 2. spark operato

【2016-07-11】Qt远程部署失败,提示"没有那个文件或目录"的解决方法

首先明确一下,这里的部署失败与网络连接.ssh/scp/sftp等无关. 一般出现在删除了远端上的可执行文件,而本地程序未做明显改动时远程部署执行的时候. Qt应用程序输出中的提示信息如下: 究其原因,是因为程序编译结果未改变,Qt部署时自动跳过了上传文件的步骤,认为不必进行部署,看程序的编译输出所提示 的信息就知道了: 而导致这一看问题的根源,在于Qt构建和运行-运行设置-部署时默认使用了增量部署,将该默认选项去掉即可: 另外,为确保上传的是最新编译的程序,可添加自定义的远程命令将远端的可执行

Linux下中断程序导致写文件失败的分析

案例: 一个普通linux C程序,执行期间会进行多次printf操作,利用bash脚本重定向功能,将stdout重定向到一个另一个文件中去.在运行途中用ctrl+C终止程序,发现定向文件始终为空,即写失败. 分析: 原本以为是bash重定向机制导致的问题,于是将重定向取消,改为使用fprintf,而非printf.即在C程序内部进行写文件.发现问题依旧.(排除fopen打开失败的因素) 仔细观察,发现问题集中在两个层面,一个是ctrl+c到底做了什么,二是写文件操作为什么失败. 首先,ctrl

Gartner:克服SIEM部署失败的常见问题

2014年8月21日,Gartner发布了一份新的SIEM报告:Overcoming Common Causes for SIEM Deployment Failures.作者是一位刚从HP跳到Gartner的新人Oliver,目前跟Mark Nicolett在一个team. 报告提出了当前SIEM部署失败的6个常见原因:计划不周.范围不清.期望过高.噪声过大.情境不够.资源不足. 原文是:Failure to Plan Before Buying,Failure to Define Scope

幽门螺旋菌(8)_耐药及治疗失败原因分析

由于幽门螺杆菌(Helicobacter pylori, 下称H.pylori)感染与多种上胃肠道疾病密切相关,所以抗H.pylori 感染治疗的研究一直是H.pylori 研究领域中的重点.为了评估抗菌治疗效果,并客观比较不同治疗方案的差异,Graham[1] 提出了一个评分系统,该系统分A.B.C.D.F 五个级别:A 级(Excellent)是ITT > 95% :B 级(Good)是ITT 90%~94% :C 级(Acceptable)是ITT 85% - 89% :D 级(Poor)

关于注册模型失败的分析

在这个地方中,显示模型未注册.但是在nop框架中,初始化时就已经把整个系统的Model全部注册了的. 在这个地方就已经全部绑定了.所以上面的错,俺也不清楚了.不过不是绑定那就查自身Model的问题了,开始以为是依赖注入的问题,后面也看了不是的. 但是当我在Validators这个里面处理,模型验证时.发现他妈多了一个构造函数.哈哈,去掉以后所有的错误就消失了. using Nop.Admin.Models.Examination; using Nop.Services.Localization;

memcache分布式部署的原理分析

下面本文章来给各位同学介绍memcache分布式部署的原理分析,希望此文章对你理解memcache分布式部署会有所帮助哦. 今天在封装memcache操作类库过程中,意识到一直以来对memcache的使用都是局限在单台服务器的情况下,还没有使用到memcache的分布式部署.虽然知道memcache的分布式是怎么回事,但是为了更加深入的理解,还是通过谷歌搜索了这方面的相关资料. 下面是精摘于网络的一些关于 memcache分布式部署 的资料. memcache分布式部署是什么呢?下面通过一个例子

Citrix XenDesktop VDA升级失败案例分析

今天处理了一个关于Citrix XenDesktop VDA升级失败的案例,这里跟大家分享一下. [背景] 用户需要将现有的XenDesktop5.6的环境升级到XenDesktop7.5,Citrix支持这种场景的支持,用户在更新VDA的是否发现升级失败. [问题描述] 具体错误信息可以参考以下截图: 具体的错误信息: rror Id: XDMI:1414B9D7 Exception:     Citrix.MetaInstaller.MetaInstallerException Instal