我观察到,将exec执行到pod时,群集中的pod无法安装软件包。在调试时,我意识到这是由于/etc/resolv.conf
项引起的。
其中一个窗格中的/etc/resolv.conf
条目是:
nameserver 192.168.27.116
search ui-container.svc.cluster.local svc.cluster.local cluster.local 192.168.27.116.nip.io
options ndots:5
在这里,如果我从所有主节点,工作节点的resolv.conf中删除条目192.168.27.116.nip.io
,则pod可以连接到Internet,并且apt-get update
和apt-get install
可以工作。这只是暂时的解决方法,因为不建议您更新resolv.conf。因为我已经观察到resolv.conf的内容在节点重启后重新设置为原始。
是由于options ndots:5
中的/etc/resolv.conf
吗?
我该如何解决?
答案 0 :(得分:3)
否,是因为您的nip.io
中的resolv.conf
地址。这是special domain,用于反射和模拟。不是ndots:5
。
答案 1 :(得分:3)
作为一个快速解决方案,您可以利用Pod Spec中的dnsConfig覆盖默认的dns配置,更多详细信息:https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#pod-dns-config
答案 2 :(得分:2)
除了上述答案外,resolve.conf通常遵循以下模式
nameserver <local domain server provided by docker>
search <pod namespace>.svc.cluster.local svc.cluster.local cluster.local <host/node's actual DNS>
options ndots:5
DNS的最后一部分 <主机/节点的实际DNS> 通常是LAB的或系统范围的DNS,它是网络的一部分。因此,您可以使用DNS policy进行覆盖,也可以在实验室中对其进行更新。 nip.io是有需要的FQDN制造商,因此您可能想出一个在您的LAB中解析的本地DNS名称,而不是依赖它。