/tags/ebpf/ Recent content in ebpf 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，所以最后一节会和我之前那几篇实战文接上。 /reading/github/ebpf-deployment-safety/ Fri, 22 May 2026 12:00:00 +0800 /reading/github/ebpf-deployment-safety/ InfoQ 这篇新闻总结的是 GitHub Engineering 在 2026 年 4 月发布的一篇文章。它讨论的不是常见的 eBPF 网络加速或可观测性案例，而是一个更偏平台工程的问题：部署系统本身会不会依赖它正在修复的系统。 这个角度并不常见：谈 Cloud Native 的可靠性时，常被提到的是多副本、自动扩缩容、健康检查、Service Mesh、GitOps、回滚策略；但当系统真的进入故障态时，一个更朴素的问题往往更实际：修复系统的工具链还能不能工作。 GitHub 这次解决的是什么问题 GitHub 的基本矛盾是一个典型的循环依赖：GitHub 的源码托管在 github.com 上，但 github.com 如果出现故障，修复它的部署动作又可能需要访问 github.com。 这个显性的循环依赖可以通过代码镜像和构建产物镜像缓解。真正麻烦的是部署脚本里的隐性依赖，比如： 直接依赖：部署脚本临时从 GitHub 下载某个 open source 工具。 隐藏依赖：机器上已有的工具启动时自动检查更新，背后访问了 GitHub。 传递依赖：部署脚本调用内部服务，内部服务再去 GitHub 拉取 release 或 binary。 这些依赖平时可能不容易看出来，因为所有服务都健康时它们只是一次普通的网络访问。等到事故发生，才发现部署链路需要依赖一个已经不可用的服务，于是修复动作被卡住，MTTR 被拉长。 GitHub 的做法不是要求每个团队手工审查脚本，而是把部署脚本放进单独的 cGroup，再用 eBPF 挂到这个 cGroup 的网络出口上。这样可以只观察和限制部署进程的 outbound network access，而不影响同一台 stateful host 上继续承载生产流量的其他进程。 这个方案里 eBPF 做了什么 这个方案里 eBPF 有四个关键作用。 第一，按进程边界做网络控制。GitHub 使用 BPF_PROG_TYPE_CGROUP_SKB 这类能力，把规则挂在特定 cGroup 的 egress 路径上。也就是说，它不是粗暴地封掉整台机器访问 github. /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 流量有微妙的影响。