minikube ingress-dns 插件实战用集群内 DNS 终结/etc/hosts污染问题【免费下载链接】minikubeRun Kubernetes locally项目地址: https://gitcode.com/gh_mirrors/mi/minikube本文以 minikube 的ingress-dnsaddon 为对象讲解如何在不修改宿主机/etc/hosts的情况下让myservice.test这类本地域名直接解析到minikube ip从而用 Ingress 替代 NodePort 和minikube tunnel访问本地服务。读完本文你将掌握ingress-dns的工作原理、完整的安装与宿主机 DNS 配置步骤覆盖 Linux 的 resolvconf / NetworkManager / systemd-resolved、macOS、Windows 三大平台、集群内 CoreDNS 转发配置以及一套可复现的端到端验证方法。为什么需要 ingress-dns/etc/hosts污染问题在本地使用 minikube 时访问服务的常规手段有两种minikube tunnel和 NodePort。NodePort 在很多场景下够用但当你希望用 Ingress 测试某些特性比如基于 Host 头路由、TLS 终结、灰度发布时就必须让 Ingress 控制器能够工作。Ingress 控制器的核心依赖是DNS——你配置的myservice.test这类本地域名必须能解析到minikube ip。传统做法是手动为每个服务在宿主机/etc/hosts中追加一条记录。这会带来一系列问题每新增、删除、重命名一个服务都需要人工维护/etc/hosts即便用脚本自动化配置也被分散存储在宿主机操作系统里而不是保存在集群中无法随集群一起版本化管理条目会持续累积、腐化形成/etc/hosts污染。解决方案运行在集群内的 DNS 服务ingress-dnsaddon 的思路是把 DNS 服务本身跑进 Kubernetes 集群里。启用后你只需要做两件事安装启用该 addon把minikube ip配置为宿主机的一个 DNS 服务器。此后每次 DNS 查询到来时该服务都会向 Kubernetes API Servermaster service发起一次调用获取集群中全部 Ingress 的列表如果查询的域名与某个 Ingress rule 的 host 匹配就返回minikube ip作为解析结果。以minikube ip为192.168.99.169、集群内配置了myservice.test的 Ingress 规则为例宿主机上的查询结果如下#bash:~$ nslookup myservice.test $(minikube ip) Server: 192.168.99.169 Address: 192.168.99.169#53 Non-authoritative answer: Name: myservice.test $(minikube ip) Address: 192.168.99.169从源码看 addon 的构成仓库中该 addon 的部署模板位于 deploy/addons/ingress-dns/ingress-dns-pod.yaml.tmpl由 5 个 Kubernetes 对象组成可以清晰地看到它的权限模型与运行方式ServiceAccountminikube-ingress-dnskube-system 命名空间Pod 以专用服务账户运行ClusterRoleminikube-ingress-dns授予对、extensions、networking.k8s.io三个 API 组中ingresses资源的get、list、watch权限——这正是查询集群内全部 Ingress所需的最小权限集ClusterRoleBinding把上述角色绑定到服务账户Podkube-ingress-dns-minikube这是核心注意它的spec.hostNetwork: true意味着 DNS Pod 直接共享节点网络栈并通过containerPort: 53 / hostPort: 53 / protocol: UDP将 DNS 端口暴露出来容器镜像由模板变量{{.CustomRegistries.IngressDNS | default .ImageRepository | default .Registries.IngressDNS }}{{.Images.IngressDNS}}决定即支持通过自定义镜像仓库覆盖ConfigMapminikube-ingress-dns目前包含一个配置项dns-nodata-delay-ms: 20用于控制无匹配记录NODATA时的应答延迟。从 pkg/minikube/assets/addons.go 可以看到该 addon 在 minikube 中的注册定义默认镜像为kicbase/minikube-ingress-dns:0.0.4带 sha256 摘要并绑定了官方文档地址。另外pkg/addons/addons.go 中的supportLegacyIngress逻辑专门处理了兼容性问题当 Kubernetes 版本 1.19.0时ingress与ingress-dns两个 addon 会替换为兼容旧版本的镜像ingress-dns 使用cryptexlabs/minikube-ingress-dns:0.3.0从而保证在旧集群上仍可工作。安装步骤第 1 步启动 minikubeminikube start第 2 步启用 addon注意需要同时启用ingress与ingress-dns两个 addon——前者提供 Ingress 控制器后者提供 DNS 解析minikube addons enable ingress minikube addons enable ingress-dns第 3 步把minikube ip配置为宿主机 DNS 服务器首先用minikube ip拿到节点 IP下文所有示例中的192.168.99.169都替换为该命令的实际输出然后按你的操作系统选择对应配置。Linux先确认 DNS 管理方式查看/etc/resolv.conf的开头几行判断你的系统由谁来管理域名解析内容中出现resolvconf→ 由resolvconf管理内容是# Generated by NetworkManager→ 由NetworkManager管理内容类似# This is /run/systemd/resolve/stub-resolv.conf managed by man:systemd-resolved(8)→ 由systemd-resolved管理。Linux resolvconf更新/etc/resolvconf/resolv.conf.d/base写入以下内容192.168.99.169替换为minikube ip的输出search test nameserver 192.168.99.169 timeout 5如果系统使用systemctlsudo resolvconf -u systemctl disable --now resolvconf.service如果系统不使用systemctl则需要采用该系统对应的 resolvconf 刷新方式原文档中该分支尚待补充具体命令。Linux NetworkManagerdnsmasqNetworkManager 自带集成的缓存 DNS 服务器dnsmasq插件可以按域名配置独立的 nameserver。编辑/etc/NetworkManager/NetworkManager.conf启用 dnsmasq[main] dnsdnsmasq然后配置 dnsmasq 处理以.test结尾的域名sudo mkdir -p /etc/NetworkManager/dnsmasq.d/ echo server/test/$(minikube ip) | sudo tee /etc/NetworkManager/dnsmasq.d/minikube.conf重启 NetworkManagersystemctl restart NetworkManager.service最后确认/etc/resolv.conf中只有一个 nameservercat /etc/resolv.conf | grep nameserver nameserver 127.0.0.1Linux systemd-resolved创建 drop-in 配置并重启 systemd-resolvedsudo mkdir -p /etc/systemd/resolved.conf.d sudo tee /etc/systemd/resolved.conf.d/minikube.conf EOF [Resolve] DNS$(minikube ip) Domains~test EOF sudo systemctl restart systemd-resolved这里Domains~test的含义是仅当查询域名以test结尾波浪号前缀表示路由到该 DNS时才使用 minikube 的 DNS其余域名仍走系统原有解析从而避免影响正常上网。macOS创建文件/etc/resolver/minikube-test写入domain test nameserver 192.168.99.169 search_order 1 timeout 5192.168.99.169替换为你的minikube ip。如果你有多个 minikube IP例如多个集群/多节点必须为每个 IP 分别配置一个文件。注意该 resolver 文件的port字段在 macOS 上不生效与文档描述不符请勿依赖。Windows以管理员身份打开 PowerShell 并执行Add-DnsClientNrptRule -Namespace .test -NameServers $(minikube ip)NRPTName Resolution Policy Table规则用于按命名空间指定解析服务器。当minikube ip变化时可先移除旧规则再新建一条命令完成Get-DnsClientNrptRule | Where-Object {$_.Namespace -eq .test} | Remove-DnsClientNrptRule -Force; Add-DnsClientNrptRule -Namespace .test -NameServers $(minikube ip)第 4 步可选让集群内部也能解析本地域名有时你希望集群内的其他应用微服务、API、测试也能通过 Ingress 的本地域名互相访问此时需要让集群内的 CoreDNS 把test域的查询转发给 ingress-dns。编辑 CoreDNS 配置kubectl edit configmap coredns -n kube-system在 Corefile 中追加一个针对本地域的 server block192.168.99.169替换为minikube iptest:53 { errors cache 30 forward . 192.168.99.169 }最终的 ConfigMap 大致如下省略号部分为原有默认内容apiVersion: v1 data: Corefile: | .:53 { errors health { lameduck 5s } ... } test:53 { errors cache 30 forward . 192.168.99.169 } kind: ConfigMap metadata: ...其中cache 30表示对该域的解析结果缓存 30 秒forward . 192.168.99.169表示把test域的所有查询转发到 minikube 的 DNS 服务。验证测试仓库自带了完整的测试样例位于 deploy/addons/ingress-dns/example/example.yaml。该清单包含 5 个对象Deploymenthello-world-app使用docker.io/kicbase/echo-server:1.0镜像容器端口 8080Ingressexample-ingresskube-systemingressClassName: nginx包含hello-john.test与hello-jane.test两个 host 规则路径/pathType: Prefix后端指向 servicehello-world-app的 80 端口Servicehello-world-appkube-systemtype: ExternalNameexternalName 指向hello-world-app.default.svc.cluster.local用于跨命名空间转发Servicehello-world-appdefaulttype: NodePort端口 80 → targetPort 8080selector 匹配app: hello-world-app。第 1 步部署测试 Ingresskubectl apply -f https://raw.githubusercontent.com/kubernetes/minikube/master/deploy/addons/ingress-dns/example/example.yaml注意该示例 Ingress 使用了networking.k8s.io/v1API最低要求 Kubernetes 1.19。上文提到的 pkg/addons/addons.go 中的supportLegacyIngress正是为 1.19的集群做兼容降级。第 2 步确认 DNS 返回 A 记录nslookup hello-john.test $(minikube ip) nslookup hello-jane.test $(minikube ip)第 3 步确认宿主机能解析域名ping hello-john.test ping hello-jane.test预期结果两域名均解析到minikube ipPING hello-john.test (192.168.99.169): 56 data bytes 64 bytes from 192.168.99.169: icmp_seq0 ttl64 time0.361 msPING hello-jane.test (192.168.99.169): 56 data bytes 64 bytes from 192.168.99.169: icmp_seq0 ttl64 time0.262 ms第 4 步通过 Ingress 访问示例服务curl http://hello-john.test curl http://hello-jane.test预期结果echo-server 返回Hello, world! Version: 1.0.0 Hostname: hello-world-app-557ff7dbd8-64mtv已知问题与注意事项.localhost总是解析到回环地址.localhost在多数系统上会被强制解析为回环地址127.0.0.1因此不能用于minikube ip。请改用.test、.example或.invalid这类本地测试保留域。.local是保留 TLD不要使用.local作为域名后缀——它是 mDNS多播 DNS和 bind9 的保留 TLD会与局域网内的 mDNS 解析冲突。macOSmDNS 重载每次在/etc/resolver中创建或修改文件后可能需要重载 macOS 的 mDNS resolver 才能生效Big Sur 之前的 macOS使用以下传统命令sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plistBig Sur 及更新版本传统命令会报错Load failed: 5: Input/output error Try running launchctl bootstrap as root for richer errors.此时应改用以下命令sudo launchctl enable system/com.apple.mDNSResponder.reloaded sudo launchctl disable system/com.apple.mDNSResponder.reloaded已知的待办事项原文档明确列出了两个计划中的改进方向说明当前体验仍有优化空间增加一个运行在宿主机上的服务自动维护/etc/resolver下的文件在minikube addons enable ingress-dns时自动启动该服务在minikube addons disable ingress-dns时自动停止。也就是说目前宿主机侧尤其是 macOS的 resolver 文件仍需手动维护。附addon 使用的镜像ImageSourceOwneringress-nginxkubernetes/ingress-nginxKubernetes ingress-nginxminikube-ingress-dnscryptexlabs/public/development/minikube-ingress-dnsCryptex Labs其中minikube-ingress-dns是 ingress-dns addon 的核心实现DNS 服务器 Kubernetes Ingress 查询逻辑minikube 侧通过 pkg/minikube/assets/addons.go 中的默认镜像kicbase/minikube-ingress-dns:0.0.4引用它在 Kubernetes 1.19的旧集群中则自动降级为cryptexlabs/minikube-ingress-dns:0.3.0见 pkg/addons/addons.go。小结ingress-dns把本地域名 → minikube IP的映射从宿主机/etc/hosts迁移到了集群内的 DNS 服务天然解决了手动维护、配置分散的问题让基于 Ingress 的本地开发体验与生产环境保持一致。核心使用链路可以概括为启用ingressingress-dnsaddon → 把minikube ip配成宿主机 DNS或 CoreDNS 转发→ 部署带 host 规则的 Ingress → 用本地域名直接访问。在动手之前请记住两条铁律优先使用.test等保留域而非.localhost/.local并确保宿主机 DNS 配置方式与你的系统resolvconf / NetworkManager / systemd-resolved / macOS resolver / Windows NRPT匹配。【免费下载链接】minikubeRun Kubernetes locally项目地址: https://gitcode.com/gh_mirrors/mi/minikube创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考