/tags/networking/ Recent content in networking 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，所以最后一节会和我之前那几篇实战文接上。 /posts/cilium-clustermesh-dual-k3s/ Sun, 08 Mar 2026 12:00:00 +0800 /posts/cilium-clustermesh-dual-k3s/ 背景 在前两篇文章中，我分别记录了 homelab 集群 和 Oracle Cloud 集群 从 Flannel 迁移到 Cilium 的过程。两个集群各自独立运行 Cilium，通过 Tailscale 子网路由实现 Pod CIDR 互通，OTel Collector 从 oracle-k3s 推送日志、指标和链路追踪到 homelab 的 LGTM 栈。 这个架构能工作，但有一个明显的缺失：两个集群之间没有原生的服务发现。oracle-k3s 的 OTel Collector 必须通过 NodePort + Tailscale IP 硬编码连接 homelab 的 Loki、Prometheus、Tempo。如果 homelab 的 Tailscale IP 变了（剧透：它真的变了），所有跨集群的连接都会断。 Cilium ClusterMesh 正是为解决这类问题设计的——它在已有的 Cilium 数据面上增加跨集群的身份联邦和服务发现，而不需要额外的 overlay 网络。 本文记录从 homelab 集群重建到 ClusterMesh 双向连接的完整过程。 架构概览 双集群拓扑 ┌──────────────────────────────────┐ ┌──────────────────────────────────┐ │ homelab (Proxmox VM) │ │ oracle-k3s (Oracle Cloud) │ │ 10. /posts/cilium-migration-on-k3s-homelab/ Sat, 07 Mar 2026 20:00:00 +0800 /posts/cilium-migration-on-k3s-homelab/ 背景 我的 homelab 运行着一个单节点 K3s 集群（Proxmox VM 上的 Ubuntu），通过 Cloudflare Tunnel 对外提供十几个服务。之前一直用 K3s 默认的 Flannel (VXLAN) 作为 CNI，一切安好。 出于对 eBPF 可观测性（Hubble）和更强 Network Policy 能力的兴趣，我决定将 CNI 替换为 Cilium。迁移本身不复杂——需要重装 K3s（禁用 Flannel 和内置 Network Policy）、安装 Cilium Helm chart、然后按依赖顺序重部署所有工作负载。 迁移过程在 安装计划文档 中有详细记录。本文聚焦于迁移完成后遇到的三个意外问题，以及每个问题的排查过程。 Cilium 配置概览 先记录一下我最终使用的 Cilium 配置，作为后续排查的上下文： # cilium-values.yaml 关键配置 kubeProxyReplacement: false # 保留 K3s kube-proxy routingMode: tunnel # VXLAN 隧道模式 tunnelProtocol: vxlan ipam: operator: clusterPoolIPv4PodCIDRList: ["10.42.0.0/16"] # 保留 Traefik 作为 Gateway，不用 Cilium Gateway API gatewayAPI: enabled: false hubble: enabled: true relay: enabled: true ui: enabled: true 关键点是 routingMode: tunnel——这意味着 Pod 间的流量通过 VXLAN 封装，Cilium 的 TC BPF 程序挂在每个 veth 上处理入/出站包。后面会看到，这个模式对 Pod→Host 流量有微妙的影响。