/tags/external-secrets/ Recent content in external-secrets 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。