问题描述
我观察到，将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吗？
我该如何解决？
解决方法
否，是因为您的nip.io中的resolv.conf地址。这是special domain，用于反射和模拟。不是ndots:5。
作为一个快速解决方案，您可以利用Pod Spec中的dnsConfig覆盖默认的dns配置，更多详细信息：https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#pod-dns-config
,除了上述答案外，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的最后一部分 通常是LAB的或系统范围的DNS，它是网络的一部分。因此，您可以使用DNS policy进行覆盖，也可以在实验室中对其进行更新。 nip.io是有需要的FQDN制造商，因此您可能想出一个在您的LAB中解析的本地DNS名称，而不是依赖它。