Kubernetes：使用 K3s 为 CoreDNS 提供独立的 resolv.conf

 Pod DNS 解析的默认设置是 CoreDNS 使用worker节点底层操作系统的设置。如果您的 Kubernetes VM 已加入多个网络或search domains，这可能会导致意外结果以及性能问题。

如果您正在使用K3s，则可以为 Kubelet 提供一个独立的 resolv.conf 文件，该文件将由 CoreDNS 使用，并且不会与 操作系统级别的dns设置冲突。

解决方案概述

在没有任何明确 DNS 策略或选项的情况下创建的 pod 使用“ ClusterFirst ”策略，该策略将非集群资源转发到工作节点的上游，并且让 pod 继承worker节点的 DNS 搜索后缀。

对于 Kubernetes 集群内解析来说，这可能并不理想，我们可以选择创建仅用于集群 DNS 解析的自定义 resolv.conf。

为了实现这一点，我们需要创建一个自定义的“/etc/k3s-resolv.conf”，更新resolv-conf 的kubelet 参数，重新启动 K3s 服务，最后重新启动 CoreDNS pod 以使更改生效。

创建自定义 resolv.conf

我们将创建一个名为“/etc/k3s-resolv.conf”的简单自定义 resolv.conf 文件，其中包含任何外部domain的上游 DNS 服务器。

echo "nameserver 192.168.1.1" | sudo tee /etc/k3s-resolv.conf

由于 CoreDNS pod 可以从任何节点运行，因此应该在所有master和worker节点上创建它。

更新 kubelet 参数

我们不会使用flags，而是使用标准的“/etc/rancher/k3s/config.yaml”，K3s 将在启动时自动读取它。

# append kubelet arg
echo 'kubelet-arg:' | sudo tee -a /etc/rancher/k3s/config.yaml
echo '- "resolv-conf=/etc/k3s-resolv.conf"' | sudo tee -a /etc/rancher/k3s/config.yaml

# check values
sudo cat /etc/rancher/k3s/config.yaml

# restart k3s service
sudo systemctl stop k3s
sleep 10
sudo systemctl start k3s
systemctl status k3s

重启 CoreDNS pod

CoreDNS pod需要重新启动。

# enable CoreDNS logging if not found
kubectl get cm -n kube-system coredns -o=json | grep -q log | kubectl get cm -n kube-system coredns -o=json | jq 'del(.metadata.resourceVersion,.metadata.uid,.metadata.selfLink,.metadata.creationTimestamp,.metadata.annotations,.metadata.generation,.metadata.ownerReferences,.status)' | sed 's#\.:53 {#\.:53 {\\n    log#' | kubectl replace -f -

# restart all CoreDNS pods
kubectl get pod -n kube-system -l k8s-app=kube-dns --no-headers | awk '{print $1}' | xargs -I{} kubectl delete pod -n kube-system {}

# wait to be available again
kubectl wait deployment -n kube-system coredns --for condition=Available=True --timeout=90s

# tail CoreDNS logs
kubectl logs deployment/coredns -n kube-system -f

验证上游DNS

首先测试内部的“kubernetes”服务，该 pod 内部以“.default.svc.cluster.local”作为后缀。

# try alpine based image with musl library which can act differently than libc
kubectl run -ti --rm alpine-musl --image=giantswarm/tiny-tools:3.12 --restart=Never --timeout=5s -- nslookup kubernetes

# try libc based library
kubectl run -ti --rm busybox-libc --image=busybox:1.35.0-glibc --restart=Never --timeout=5s -- nslookup kubernetes

DNS 查询将输出在之前跟踪的 CoreDNS 日志中。

然后测试一个外部域名，例如“google.com”，该域名必须使用来自 /etc/k3s-resolv.conf 的上游

# alpine musl image
kubectl run -ti --rm alpine-musl --image=giantswarm/tiny-tools:3.12 --restart=Never --timeout=5s -- nslookup google.com

# libc image
kubectl run -ti --rm busybox-libc --image=busybox:1.35.0-glibc --restart=Never --timeout=5s -- nslookup google.com

DNS 查询将输出在之前跟踪的 CoreDNS 日志中。