问题描述
在按照k3s教程进行DNS故障排除时，在步骤2 “为用户添加KUBECONFIG” 后，运行以下命令出现问题：
kubectl run -it --rm --restart=Never busybox --image=busybox:1.28 -- nslookup www.google.com
用户得到以下错误：
nslookup: can't resolve 'www.google.com'pod "busybox" deletedpod default/busybox terminated (Error)
用户使用的是单节点的k3s集群，而在安装了k3s的同一台机器上，用户可以正常运行 nslookup www.google.com。用户对于教程中没有提供后续步骤感到困惑。用户想知道在k3s内部可能导致外部解析失败，但在k3s外部却能正常解析的原因。用户的Core DNS日志显示了以下错误：
[ERROR] plugin/errors: 2 google.com. AAAA: read udp 10.42.0.6:40115->1.1.1.1:53: i/o timeout
[ERROR] plugin/errors: 2 google.com. A: read udp 10.42.0.6:54589->1.1.1.1:53: i/o timeout
当用户在外部服务器上运行curl时，得到以下结果：
command terminated with exit code 6
尽管这是用户遇到的第一个症状，但事实证明，用户也无法通过IP ping或curl/wget外部网站。出于这些原因，用户认为问题更加复杂，可能涉及到iptables。
解决方案
请注意以下操作注意版本差异及修改前做好备份。
方案1 – 修复默认路由
用户的问题基本上是由于具有多个默认路由导致的。通过以下步骤来解决这个问题：
- 使用命令
ip route查看当前的默认路由列表。 - 找到具有多个默认路由的条目。
- 使用命令
sudo ip route del default via <网关IP> dev <网络接口>删除其中一个不必要的默认路由。
例如，假设以下是用户的默认路由列表：
default via 172.16.42.1 dev ens5 proto dhcp src 172.16.42.135 metric 100
default via 172.16.42.1 dev ens3 proto dhcp src 172.16.42.95 metric 100
default via 10.2.64.1 dev ens4 proto dhcp src 10.2.67.51 metric 100
用户可以通过删除其中一个不必要的默认路由来修复问题，例如：
sudo ip route del default via 10.2.64.1 dev ens4 metric 100
方案2 – 使用Terraform设置no_gateway
用户还可以在Terraform中的网络子网配置中使用no_gateway = true来避免出现多个默认路由的问题。例如：
resource "openstack_networking_subnet_v2" "subnet_project" {
name = "subnet_project"
network_id = openstack_networking_network_v2.net_project.id
cidr = "172.16.42.0/24"
ip_version = 4
no_gateway = true
}
通过设置no_gateway = true，可以确保子网不会自动分配默认网关，从而避免多个默认路由的情况。
方案3 – 验证IP地址和接口配置
用户可以通过执行以下命令验证IP地址和接口配置：
- 使用
ip -o addr命令查看IP地址配置和接口状态。 - 使用
ip link命令查看接口信息。
根据输出检查IP地址是否正确分配，接口是否正确启用。
这些解决方案中的一种或多种可能会解决用户在k3s集群中无法解析外部域名或连接到外部资源的问题。用户可以根据实际情况选择其中一个方案或多个方案来解决问题。
请注意，由于网络配置可能因环境而异，使用这些解决方案时请谨慎，并确保备份重要数据和配置。在进行更改之前，最好在测试环境中尝试这些操作，以避免潜在的问题。
这些方案应该能够帮助您解决在新安装的k3s集群上无法解析外部域名或连接到外部资源的问题。根据您的环境和实际情况，选择适合您的解决方案，并根据需要进行调整和修改。