/tags/vault/ Recent content in vault on Hugo -- gohugo.io en Wed, 27 May 2026 17:00:00 +0800 /posts/homelab-vault-reboot-recovery/ Wed, 27 May 2026 17:00:00 +0800 /posts/homelab-vault-reboot-recovery/ 背景：一次内存扩容引出的连锁恢复 事情的起点很无聊：homelab 那台单节点 K3s 跑在 Proxmox VM 上，内存只给了 10G，kube-prometheus-stack 加上一堆有状态服务之后内存 requests 一直在 58% 上下，限制（limits）甚至超卖到 186%。我决定把 VM 从 10G 扩到 12G。 Terraform 改一行 vm_memory，apply，VM 重启——这一步本身顺利完成，节点回来了，kubectl top node 显示 12G 到位。但紧接着我发现一连串东西不对： argocd 里 personal-services 是 Synced/Degraded 12 个 ExternalSecret 全部 SecretSyncedError calibre-web、grafana 等依赖 secret 的 pod 起不来 表面上看是 ExternalSecrets 集体挂掉，但直接触发点集中在一个地方：Vault 一重启就 sealed 了。 这篇文章把从"重启后 secret 全挂"到"固化成一条 just homelab-recover“的排查过程整理出来，重点是中间踩到的三个坑——其中第三个是我自己写的恢复脚本里的 bug。 Vault 为什么一重启就 sealed 先说这个不是 bug，是设计。 HashiCorp Vault 启动时数据是加密的，主密钥（master key）本身又被一组 unseal key 保护。进程刚起来时处于 sealed 状态：它能响应健康检查，但任何读写密钥的请求都会被拒。需要用 unseal key 把 master key 解出来、加载进内存，Vault 才进入 unsealed 状态开始服务。 /posts/homelab-alertmanager-gotify-bridge/ Sat, 25 Apr 2026 01:00:00 +0800 /posts/homelab-alertmanager-gotify-bridge/ 背景 Homelab 跑了一套 LGTM 可观测性栈（Loki + Grafana + Tempo + Prometheus），Prometheus Alertmanager 已经在收集各种告警，但一直没有配出通知渠道——告警只是静静地积在队列里，没有任何推送。 Gotify 是一个轻量的自托管推送通知服务，已经在集群里跑着了，主要用于接收 Redpanda Connect 推送的消息。顺手把 Alertmanager 的告警也接进来，省得再引入第三方服务。 架构 Alertmanager 的 webhook receiver 发送的是自己定义的 JSON 格式；Gotify 的 POST /message API 期望的是另一套字段（title / message / priority）。两者不能直接对接，需要一个中间层做格式转换。 DRuggeri/alertmanager_gotify_bridge 是一个专门做这件事的小服务。它的 README 说明默认监听 /gotify_webhook，并把收到的 Alertmanager webhook 转换后转发到 Gotify。 flowchart LR P[Prometheus] --> A[Alertmanager] A -->|webhook| B[alertmanager-gotify-bridge] B -->|POST /message| G[Gotify] 部署拓扑： 组件 Namespace 说明 Gotify personal-services 消息服务端，已有 alertmanager-gotify-bridge monitoring 格式转换 bridge Alertmanager monitoring kube-prometheus-stack 的一部分 Token 管理走 Vault + External Secrets Operator：在 Gotify 创建一个专用 Application，把 token 存入 Vault，ESO 自动同步到 bridge 所在的 monitoring namespace。 /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/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，而是安装完以后把整条依赖链重新扶起来。