/tags/cilium/ Recent content in cilium on Hugo -- gohugo.io en Sun, 08 Mar 2026 18:30:00 +0800 /posts/cilium-gateway-argocd-dns-recovery/ Sun, 08 Mar 2026 18:30:00 +0800 /posts/cilium-gateway-argocd-dns-recovery/ 背景 这次故障一开始看起来像两个互不相干的问题： ArgoCD 里 gateway Application 一直是 Degraded 其他几个 Application 又出现了 OutOfSync 或者后续的 Unknown 如果只看表面，很容易把它归类成“Cilium Gateway API 有问题”或者“ArgoCD 状态异常”。 但真正麻烦的地方在于，这次故障不是单点失效，而是一条跨层级的链路问题： ArgoCD 健康状态异常 -> 先看到 Gateway Degraded -> 再发现 repo-server 拉 Git 也失败 -> 往下追到 CoreDNS 外部解析异常 -> 再继续追到 ZITADEL 根本没有把 backend Service 建出来 -> 最后发现 Vault 里的 ZITADEL master key 长度也不对 也就是说，最上层暴露出来的是 Gateway 和 ArgoCD，真正的根因却横跨了： Cilium Gateway API ArgoCD repo-server CoreDNS systemd-resolved Vault + External Secrets ZITADEL Helm 安装链路 这篇文章就按我实际排查的顺序，把整个问题怎么拆开、怎么验证、最后怎么收敛讲清楚。 /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/oracle-k3s-cilium-migration/ Sat, 07 Mar 2026 22:45:00 +0800 /posts/oracle-k3s-cilium-migration/ 背景 我的 homelab 现在是双集群结构： homelab 跑在 Proxmox 上，负责 Vault、ZITADEL、ArgoCD、Grafana、Kopia 这类核心服务。 oracle-k3s 跑在 Oracle Cloud A1 免费机上，负责 Homepage、Miniflux、KaraKeep、Uptime Kuma、Timeslot 等轻量工作负载。 前一阵我先把 homelab 主集群从 Flannel 切到了 Cilium。迁移完成后，整个架构留下了一个非常明显的不对称：一边是 Cilium，一边还是 K3s 默认 Flannel。 这件事短期看没有坏处，但中长期会越来越烦： 网络问题的排障路径不一致。 两套集群文档会慢慢分叉。 以后不管是做 ClusterMesh PoC，还是只是想统一认知模型，都会被这块技术债反咬。 所以这次我决定把 oracle-k3s 也迁到 Cilium。 这次迁移真正的目标 表面目标是把 CNI 从 Flannel 换成 Cilium，但真正目标其实有三个： 统一双集群数据面：以后提到 Pod 网络、Hubble、NetworkPolicy，两个集群说的是同一套东西。 验证恢复能力：既然是重装 K3s，就顺手检验一下 GitOps、Vault、备份、PVC 恢复到底是不是纸上谈兵。 识别复杂度来源：哪些问题是 Cilium 带来的，哪些其实是之前就存在，只是这次被重建过程暴露出来了。 迁移步骤概览 最终流程大致是这样： 备份本地 PVC 数据 -> 卸载 K3s -> 关闭 Flannel，重装 K3s -> 安装 Cilium Helm chart -> 重装 ESO / Traefik 配置 / 各类 manifests -> 修 Vault Secret / Cloudflare Tunnel / 探针 / 数据库连接 -> 恢复 PVC 数据 -> 验证所有对外服务 其中真正耗时间的不是安装 Cilium，而是安装完以后把整条依赖链重新扶起来。 /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 流量有微妙的影响。