随笔 2026.8.19 - 补络阁

1. Kubernetes 小技巧——启动一次性Pod#

在日常使用中，很多场景都需要起一个比较一次性的 Pod 来完成一些操作，如临时Shell（BusyBox），操作数据库（Postgres）等

获得一个临时Shell

1
kubectl run my-shell --rm -it --restart=Never --image=busybox -- /bin/bash

为运行中的Pod添加临时容器

1
kubectl debug -it <目标Pod名称> --image=busybox --target=<目标容器名称>

当目标Pod内的容器缺少Shell或已经崩溃，导致无法直接进入时，可以为它添加一个临时容器

临时操作数据库

1
kubectl run pg-client --rm -it --restart=Never \
2
  --image=postgres:15 \
3
  --namespace=<你的命名空间> \
4
  -- psql -h <数据库Service名称> -U <用户名> -d <数据库名>

2. Authentik 26.5.3 图标加载BUG排障#

2.1 现象#

昨天将 Authentik 的存活探针删除后，再次访问 Web 端时，发现所有的应用图标全部 404 Not Found 了，就很神秘。开始以为是没挂 PVC 的问题，但是 Exec 进容器时发现文件还在，权限也正确。重新上传文件后，可以显示，但是再 rollout restart 一遍就又 404 Not Found 了。

2.2 尝试排查#

尝试了一下，我发现在用户列表界面查看头像可以，但是在文件页面查看又不行，然后观察一下两个请求的URL:

200 OK

1
https://auth.redrock.team/files/media/public/avatar/TuF3i.jpeg?token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJwYXRoIjoibWVkaWEvcHVibGljL2F2YXRhci9UdUYzaS5qcGVnIiwiZXhwIjoyMDk5MTI3Mzg2LCJuYmYiOjE3ODM3NjczNzF9.6WiZobBVcU7SfaXslnosfhhcw0gKOC8pvp4F0yCToOc

404 Not Found

1
https://auth.redrock.team/files/media/public/avatar/TuF3i.jpeg?token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJwYXRoIjoibWVkaWEvcHVibGljL2F2YXRhci9UdUYzaS5qcGVnIiwiZXhwIjoxNzg2ODk2OTcxLCJuYmYiOjE3ODY4OTYwNTZ9.sKmMqE_bkkQMkhwd1Mm2J1GB7zrXD8GWvniCefZJIQ4

观察了一下，发现只是Token不同，所以应该是Token的问题，查了一下Github的 PR #23213，发现是 Postgres 没有检查Token的过期时间，导致过期Token被重复返回。

2.3 解决方案#

这个BUG已经在 26.5.4 版本中被修复，所以决定给 Authentik 更新成 26.5.4

2.3.1 更新 Server 和 Worker#

下载Chart

因为网有问题，导致 helm 拉 Chart 拉不下来，所以直接用 wget 拉

1
wget "https://gh-proxy.org/https://github.com/goauthentik/helm/releases/download/authentik-2026.5.4/authentik-2026.5.4.tgz"

在 values.yaml 改一下镜像

1
// 第一个地方
2
image:
3
    repository: ghcr.m.daocloud.io/goauthentik/server
4

5
// 第二个地方
6
outposts:
7
    container_image_base: ghcr.m.daocloud.io/goauthentik/%(type)s:%(version)s

更新 worker 和 server

1
helm upgrade authentik authentik-2026.5.4.tgz -f values.yaml -n sso

更新 outpost

更新好 server 和 worker 后，发现前哨站没有自动更新，手动更新一下

1
kubectl set image deployment/authentik-outpost-hubble outpost=ghcr.m.daocloud.io/goauthentik/server:2026.5.4 -n sso

其他以此类推

3. Rust llama.cpp 中 AVX2 指令集兼容问题复盘#

3.1 现象#

在部署卷娘的RAG中心时，容器 juan-rag-service 启动后 1ms 内崩溃，exit code 132 无限重启。日志只有一行 配置加载完成，没有报错堆栈。

132 = 128 + 4 = SIGILL（非法指令）。这不是普通错误，是 CPU 拒绝执行某条指令，进程被内核直接杀掉——绕过了 Rust 的所有错误处理和优雅降级。

3.2 排查#

让AI直接读了 vendored 的 llama.cpp/ggml/CMakeLists.txt，发现：

1
GGML_NATIVE_DEFAULT = ON（非交叉编译时）
2
if (GGML_NATIVE OR NOT GGML_NATIVE_DEFAULT) → INS_ENB=OFF
3
else                                        → INS_ENB=ON   ← 我们走的这条
4

5
option(GGML_AVX2  ... ${INS_ENB})   ← 默认 ON！
6
option(GGML_AVX   ... ${INS_ENB})   ← 默认 ON！
7
option(GGML_FMA   ... ${INS_ENB})   ← 默认 ON！
8
option(GGML_F16C  ... ${INS_ENB})   ← 默认 ON！
9
option(GGML_BMI2  ... ${INS_ENB})   ← 默认 ON！

llama.cpp 的 cmake 在 GGML_NATIVE=OFF 时，AVX/AVX2/FMA/F16C/BMI2 默认全部 ON**，会自动追加 -mavx2 -mfma 等编译参数。而 build.rs 只在目标特性包含这些指令时才显式设置、**从不主动关闭——两个构建层之间出现了空档：RUSTFLAGS 改了 GGML_NATIVE，但没改 cmake 的 option() 默认值。

3.3 修复#

Dockerfile 构建阶段显式关掉默认值（GGML_* 环境变量会被 build.rs 透传给 cmake、覆盖 option 默认值）：

1
# 嵌入性能损失可忽略。
2
ENV RUSTFLAGS="-C target-cpu=x86-64-v2"
3

4
# 显式关闭 llama.cpp 默认开启的 AVX/AVX2/FMA/F16C/BMI2（保持 x86-64-v2 可移植基线）
5
ENV GGML_AVX=OFF \
6
    GGML_AVX2=OFF \
7
    GGML_BMI2=OFF \
8
    GGML_FMA=OFF \
9
    GGML_F16C=OFF \
10
    GGML_AVX512=OFF \
11
    GGML_AVX512_VBMI=OFF \
12
    GGML_AVX512_VNNI=OFF \
13
    GGML_AVX512_BF16=OFF \
14
    GGML_AVX_VNNI=OFF

3.4 验证#

用 Dockerfile 完全相同的环境变量本地重编 llama.cpp，然后逐个 objdump 所有 .a 产物：

产物	AVX2/AVX512 指令数
`libggml-cpu.a`	0 ✅
`libggml.a`	0 ✅
`libllama.a`	0 ✅
其余全部	0 ✅

部署后容器正常启动到 RAG-Service 启动于 http://0.0.0.0:3000，SIGILL 彻底消失

4. 结尾#

没有了喵，谢谢阅读

音乐