问题描述
在使用Kubernetes（K8）和Docker时，遇到了一个问题。他的场景是这样的：他有一个私有的Docker注册表（registry），它位于默认命名空间，并使用了TLS，地址为https://docker-registry.default:5000。他通过在本地进行端口转发（端口5000），并将docker-registry.default添加到/etc/hosts文件中，成功地拉取和推送了镜像。然而，他使用了一个由Serverless框架（Nuclio）管理的部署。问题出现在这个过程中，错误信息如下：
Failed to pull image "docker-registry.default:5000/docker/nuclio/processor-helloworld1:latest": rpc error: code = Unknown desc = Error response from daemon: Get https://docker-registry.default:5000/v2/: dial tcp: lookup docker-registry.default on 169.254.169.254:53: no such host
用户遇到了”No Such Host”的错误。
一位Nuclio的开发人员确认了这不是Nuclio的问题，因为他甚至不能从Nuclio Admin pod（不是上面提到的失败的Pod）执行docker login到这个内部的docker-registry.default地址，尽管他可以执行docker login到Docker Hub，并且可以成功地使用wget命令访问docker-registry.default。Nuclio Admin pod使用的是Alpine Linux系统。
解决方案
请注意以下操作注意版本差异及修改前做好备份。
首先，错误信息表明DNS解析出现问题，”No Such Host”表示主机名无法解析。我们可以进行以下步骤来排查和解决这个问题。
步骤1：验证DNS解析
为了验证主机名是否能够从集群中解析，我们可以在集群中运行一个临时的Ubuntu Pod，并在该Pod内进行DNS解析的测试。
-
运行临时的Ubuntu Pod：
shell
kubectl run ubuntu -it --image ubuntu --rm=true -- bash -
在Ubuntu Pod内部执行以下命令来进行DNS解析测试：
shell
apt update && DEBIAN_FRONTEND=noninteractive apt --yes install dnsutils
dig docker-registry.default
如果docker-registry.default无法解析，我们需要检查DNS配置。
步骤2：检查DNS配置
检查K8集群的DNS配置，确保集群能够正确解析私有Docker注册表的主机名。
- 检查K8集群中的DNS配置：
shell
kubectl get configmap -n kube-system coredns -o jsonpath='{.data.Corefile}'
确保配置中有能够解析docker-registry.default的配置。
- 如果需要，更新DNS配置以包含私有Docker注册表的主机名解析。
步骤3：检查网络和私有DNS
如果您使用的是云提供商（例如Azure），确保您的私有DNS区域与集群的虚拟网络连接正确。请参考相关文档以确保连接私有DNS区域和虚拟网络：使用Azure Private Link连接到Azure容器注册表。
步骤4：检查镜像路径和部署清单
确认部署清单中的镜像路径是否正确。在部署清单中查找镜像的路径，确保与私有Docker注册表的地址和路径匹配。
步骤5：在相同私有网络内测试
尝试从位于相同私有网络内的另一个VM上拉取镜像。确保网络环境正常，能够访问私有Docker注册表。
以上步骤应该可以帮助您解决”no such host”错误。如果问题仍然存在，请确保网络配置正确，DNS解析正常，并检查可能存在的网络隔离或防火墙设置。
注意：如果您使用的是Kubernetes的特定版本，可能会有一些版本差异或特定配置。根据您的实际环境和版本，可能需要适当调整上述解决方案中的操作。
提示：如果需要测试Kubernetes集群的网络连通性，您可以尝试使用
curl或wget命令来访问私有Docker注册表，以验证网络连接是否正常。