/tags/coredns/ Recent content in coredns on Hugo -- gohugo.io en Fri, 29 May 2026 21:00:00 +0800 /posts/k8s-service-network-from-dns-to-ebpf/ Fri, 29 May 2026 21:00:00 +0800 /posts/k8s-service-network-from-dns-to-ebpf/ 背景：一个 DNS 短视频把我带进了整条链路 起因很小：我刷到 KodeKloud 的一个短视频《Pod DNS Not Working - Part 1》，讲的是 Pod 解析不了 DNS 时怎么一步步排查。视频本身不长，给的排查技巧也很实用，但真正勾住我的是它顺带提到的一句话——业务流量通常不会直接依赖 Pod 原始 IP，而是更常通过 Service DNS 名称访问，因为 Pod IP 会随着重建变化。 于是我冒出一个问题：CoreDNS 解析一个普通 Service 的 DNS 名称，返回给我的只是一个 ClusterIP，而这个 ClusterIP 是个虚拟地址，通常并不直接挂在任何节点的物理网卡上——那发往它的包，到底是怎么找到并送到某个真实 Pod 的？ 这里说的 Service DNS 名称，既包括 my-svc.default.svc.cluster.local 这种完整域名，也包括同 namespace 里常写的 my-svc 这种短名；后者会被 Pod 里的 resolver 按 search domain 补成完整域名再查询。 顺着这个问题往下挖，我发现它其实串起了 K8s Service 网络的一整条链路。这篇就按这条链路走一遍： Pod 怎么把域名变成 IP（DNS / CoreDNS） ClusterIP 这个虚拟 IP 的包怎么到达 Pod（kube-proxy + 内核 DNAT） kube-proxy 凭什么知道后端有哪些 Pod（EndpointSlice） 负载均衡到底是谁在做 为什么 2026 年这套 dataplane 正在从 iptables / IPVS 往 nftables 和 eBPF 迁移 我自己 homelab 那几个 K3s 集群已经换成了 Cilium，所以最后一节会和我之前那几篇实战文接上。