Zhangguanzhang

欧拉22.04容器内sudo 被 killed

2026-04-09T09:10:30.000Z

记录下一次欧拉容器内sudo无法使用的排查过程。

由来

实施反馈客户环境上我们部署容器内无法使用 sudo：

1 2	$ sudo ls -l 已杀死

排查

部署容器是基于 openeuler/openeuler:22.03 制作的，之前是实施和另一个同事发现基于 ubuntu 的基础镜像制作的部署镜像内 sudo 可以使用，后面升级后又变成欧拉的，让我排查下。

权限？

远程上去后：

1
2
3

$ docker run --rm -ti --entrypoint bash xxx
$ sudo ls -l
已杀死

想着是不是 seccomp 之类的导致的，用特权启动下试试：

1
2
3

$ docker run --rm -ti --privileged --entrypoint bash xxx
$ sudo ls -l
已杀死

依旧这样，换基于 ubuntu 制作的发现没问题，但是这个欧拉镜像内无 strace 命令。

制作验证

本地制作了下基于欧拉和其他一些镜像增加 sudo 和 strace 的镜像：

FROM openeuler/openeuler:22.03

RUN set -eux; \
    sed -ri 's|://repo.openeuler.org/|://repo.huaweicloud.com/openeuler/|g' /etc/yum.repos.d/openEuler.repo; \
    sed -ri 's|https://mirrors.openeuler.org|https://repo.huaweicloud.com/openeuler/|g' /etc/yum.repos.d/openEuler.repo; \
    yum makecache; \
    dnf install -y --setopt=install_weak_deps=False    \
        sudo   \
        strace   \
    ;

然后几个镜像构建完成后：

1	docker save sudo:oe sudo:xxx \| gzip -> sudo-docker.tar.gz

客户环境上导入测试：

$ docker load -i sudo-docker.tar.gz
$ docker run --rm -ti --entrypoint bash sudo:oe
[root@71ec45b79f63 /]# sudo ls -l
Killed
$ docker run --rm -ti --privileged --entrypoint bash sudo:oe
[root@fea66e40292f /]# sudo -V
Sudo version 1.9.8p2
Configure options: --build=x86_64-openEuler-linux-gnu --host=x86_64-openEuler-linux-gnu --program-prefix= --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --prefix=/usr --sbindir=/usr/sbin --libdir=/usr/lib64 --docdir=/usr/share/doc/sudo --disable-root-mailer --disable-intercept --disable-log-server --disable-log-client --with-logging=syslog --with-logfac=authpriv --with-pam --with-pam-login --with-editor=/bin/vi --with-env-editor --with-ignore-dot --with-tty-tickets --with-ldap --with-selinux --with-passprompt=[sudo] password for %p:  --with-linux-audit --with-sssd
Killed

发现 -V 都报错，没办法了，strace 看看调用过程：

[root@fea66e40292f /]# strace sudo -V
....
mprotect(0x7f605d240000, 4096, PROT_READ) = 0
mprotect(0x7f605d2bf000, 4096, PROT_READ) = 0
openat(AT_FDCWD, "/proc/sys/crypto/fips_enabled", O_RDONLY) = 3
read(3, "0\n", 2)                       = 2
close(3)                                = 0
access("/etc/system-fips", F_OK)        = -1 ENOENT (No such file or directory)
munmap(0x7f605d5eb000, 10235)           = 0
newfstatat(AT_FDCWD, "/usr/libexec/sudo/sudoers.so", {st_mode=S_IFREG|0644, st_size=525888, ...}, 0) = 0
newfstatat(AT_FDCWD, "/usr/libexec/sudo/sudoers.so", {st_mode=S_IFREG|0644, st_size=525888, ...}, 0) = 0
pipe2([3, 4], O_NONBLOCK|O_CLOEXEC)     = 0
getpid()                                = 80
getrandom(0x7fff8e404980, 40, 0)        = -1 ENOSYS (Function not implemented)
gettid()                                = 80
getpid()                                = 80
tgkill(80, 80, SIGKILL)                 = ?
+++ killed by SIGKILL +++
Killed

看着是 getrandom 的 syscall 报错没实现，欧拉镜像是类似 rhel 的，自带 python，用 python 调用它试试：

[root@fea66e40292f /]# python3 -c 'import os;os.getrandom(3)'
Traceback (most recent call last):
  File "", line 1, in 
OSError: [Errno 38] Function not implemented

明确是 getrandom syscall 问题，再试下 Linux shuf 随机数命令：

[root@fea66e40292f /]# shuf -i 1-10 -n 1
shuf: getrandom: Function not implemented
[root@fea66e40292f /]# uname -a
Linux fea66e40292f 3.10.0-514.el7.x86_64 #1 SMP Tue Nov 22 16:42:41 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
[root@fea66e40292f /]# rpm -qa | grep glibc
glibc-common-2.34-170.oe2203sp4.x86_64
glibc-2.34-170.oe2203sp4.x86_64

结论和验证

客户机器是 CentOS 7.3，内核 3.10.0-514.el7.x86_64 ，推测欧拉的 glibc 对 getrandom syscall 强依赖没有 fallback 回退到 openat(/dev/urandom) 机制，客户这套环境还有其他 CentOS 7.9的，上面去测试了下没问题，其他 7.3 的机器上也复现了：

# 其他 7.9 机器上
[root@fea66e40292f /]# shuf -i 1-10 -n 1
4
# 其他 7.3 机器上
[root@fea66e40292f /]# shuf -i 1-10 -n 1
shuf: getrandom: Function not implemented

因为还有其他业务服务使用欧拉基础镜像，如果从 glibc 层面修改解决这个问题成本太大了:

客户现场要针对每个容器镜像单独更新下 glibc
后续我们也要维护一份 glibc 代码编译成欧拉的 rpm 包

让客户使用 CentOS 7.9 的最稳妥，同时该问题已经反馈给欧拉仓库 https://atomgit.com/openeuler/openeuler-docker-images/issues/60

[持续更新] - 安卓 HTTPS 抓包那些事

2026-02-23T20:10:30.000Z

长期记录和更新安卓 HTTPS 抓包相关的内容与笔记。

由来

网上好多文章比较水，只知道照抄步骤。这里以科普、重点和笔记的形式写下安卓 HTTPS 抓包那些事，方便有各方面基础的人快速上手安卓抓 HTTPS 包。

原理相关

基于逆向、协议逆向以及实现某些 app 自动化等需求，往往需要抓取指定 app 的 HTTPS 包才能完成。本文只讨论 HTTPS 抓包本身，涉及 apk 对设备 root 与反调试检测的就不展开了。

中间人

抓 HTTPS 的方式大致分为两类：hack 与非 hack。

hack 方式：例如基于 eBPF 的 gojue/ecapture，在 client 端 hook 相关 SSL 即可解密 HTTPS 报文，另外例如 frida hook app。
非 hack 方式：例如中间人攻击。

eBPF 需要较高内核版本且有对应内核模块支持。网上很多人用 root、KSU 等，却很少去编译内核增加 ebpf 的支持，所以这种方式很难普及， frida 的话要写注入逻辑，一般要电脑配合且要懂点编程和逆向基础。而中间人攻击的原理是：

客户端                    攻击者            服务器(https://example.com)
  │                        │                         │
  │──── ClientHello ─────▶│                         │
  │                        │──── ClientHello ─────▶ │
  │                        │◀── Server Certificate ─│
  │◀ Fake Certificate ────│                         │
  │                        │                         │
  │==== 加密通信 ====      │  ==== 加密通信 ====      │
  │   (被攻击者解密)        │   (正常HTTPS)           │

客户端向服务器发起 HTTPS 请求，中间人伪装成服务器完成 TLS 握手，拦截并解析数据；中间人再以客户端身份与真实服务器通信，在服务器看来就是普通的一个客户端在访问自己。
攻击者自签 example.com 的 TLS 证书并回复给客户端。
客户端后续发送的 https://example.com/api 等请求，攻击者解密后再向服务器请求，拿到数据后以 HTTPS 形式回给客户端。
从开发视角看，中间人相当于以明文查看 HTTPS 请求，可拦截请求与响应，也可针对某些 URL path 做策略。

HTTPS 刚普及时，很多客户端不校验中间人证书是否由权威 CA 签发（用浏览器访问会看到红色警告）。后来普遍校验证书后，做中间人时需要在 Linux 上把自建 CA 加入 /etc/ssl/certs/ca-certificates.crt 等系统信任链。

安卓的凭据

例如在 Windows 电脑上用 Fiddler，在电脑里加入 Fiddler 的 CA 后，Fiddler 可以抓浏览器或进程的 HTTPS 报文。Linux、Windows、安卓本质都是同一套中间人原理，只是细节不同。在安卓上，CA 以「凭据」形式存在，路径是：设置 → 系统安全 → 凭据存储 → 信任的证书，分为「系统」和「用户」两类。

安卓 7.0 起不再信任用户安装的 CA，需要把 CA 放进「系统」凭据。需要手机 root，可用 MT 管理器或 adb shell（root）把 CA 放到 /system/etc/security/cacerts/。

SSL Pinning

部分 app 不信任系统凭据或对服务器证书做校验，可能还需要配合 LSPosed 和 Magisk 模块（如 JustTrustMe、TrustMeAlready）hook 应用内的 X509TrustManager、okhttp3 等跳过证书校验。会 Frida 的话也可以直接 Frida hook。

高版本安卓的凭据

在安卓 15 + KSU 上试过 Reqable：左上角菜单 → 证书管理 → 安装证书，我选的是手动复制证书文件，证书会保存到 Download/Reqable/xxxxx.0。KSU 授权 com.android.shell 取得 root 后，在 adb root shell 里仍无法把证书推到 /system/etc/security/cacerts/，用 MT 管理器移动也会报「挂载读写失败」。

查资料得知有人分析 framework.jar 发现从安卓 14 起证书目录是 /apex/com.android.conscrypt/cacerts，但试了下依然无法直接写入。继续查发现 /apex 有更严格的系统分区保护，即便 root 后 remount 也改不了。后来看到做法是：先装 OverlayFS MetaModule，再装 MoveCertificate，把证书放到 /data/local/tmp/cert/ 下重启，就能在系统凭据里看到新 CA。

看了下 MoveCertificate 的 post-fs-data.sh，是通过 tmpfs 覆盖挂载 /apex/com.android.conscrypt/cacerts 并配合 SELinux 权限完成凭据列表的注入，前提是已安装 OverlayFS MetaModule。另外我试过只 ksu 里关掉 OverlayFS 模块不关别的，手机重启会起不来。

然后把 Reqable 记录模式选成 V-P-N，应用指定微信，开启增强并启动抓包，打开微信和小程序，发现抓到的全是 CONNECT，点进请求显示 SSL 握手失败，说明 CA 没被正确信任。后来试了 Reqable 生成的 Magisk 模块刷入，并取消使用 MoveCertificate 模块，重启后就能正常抓到了。

安卓 16 好些还要额外安装到用户凭据里。

安卓原理和工具选项

模拟器和安卓上开光速虚机抓包啥的不讨论，如果你看懂了原理又嫌弃 root 麻烦，可以自行搜索查看相关文章。

指定 app 抓包原理

安卓上「指定 app 走代理」的实现原理可以看我之前的文章开发一个让指定应用走代理的安卓 app 过程。安卓的 VPNService 本身支持让指定 app 走类似 Linux /dev/tun 的通道，应用开发者只需实现相应逻辑即可。

工具选型

有人会把 Fiddler 的 CA 导入手机，电脑跑 Fiddler，手机 WiFi 代理指向电脑的 Fiddler 端口。但不少 apk 会检测 WiFi 是否设置了代理，一旦发现就不走代理，导致抓不到该 app 的 HTTPS，所以更稳妥的方式还是：在安卓上装抓包/代理软件，用 VPNService 指定 app，再做中间人拦截。

微信小程序的鉴权里，code 不能重复使用（QQ 的似乎可以），所以常需要抓包拦截住请求不让它发出去，然用请求里的 code 在代码里去使用。我调研了一下，以下是搜到的对比：

软件	开源	UI 和功能	CA 相关
Reqable	未开源，前身是 HttpCanary	UI 现代，请求查看体验较好。需 VIP 解锁全部功能（只有价格说明没具体有哪些功能）	安装后 CA 随机生成这点不错，并且支持生成 magisk 模块；PC 端 USB 装证书到手机疑似通过 adb root 完成，无手动步骤，比较担心被注入不好的东西
proxypin	开源	UI 现代，请求查看不如 Reqable 细致，但支持断点、重写请求	apk 完全可以像 Reqable 那样生成一个 magisk 模块，而不需要让人去下载注入CA 的 Magisk-ProxyPinCA 模块。 apk 生成的 CA 与 Magisk-ProxyPinCA 内的 CA 是固定而不是随机的，可能是一个安全隐患点

安卓 16 好像限制挺多的，可以去尝试下虚拟机，我是安卓 15 + proxypin 和它的 ca 模块可以抓包。理清原理后，甚至可以自己搭一套分布式抓包方案，例如：

在 Linux 上写/部署一个带中间人能力的 SOCKS5 服务端；
复用或开发开源安卓代理 app（如 appproxy）；
手机安装上述 CA，启动 appproxy，让待抓包的 app 走代理，上游指向该 SOCKS5；
SOCKS5 收到流量后做中间人解密，并在 Web 端展示。既利用了安卓的指定 app 走代理，又可以专心开发服务端，不需要过多关注安卓方面。

这里举例是想表明工具只存在功能细节上的差异，不存在某个工具可以做到某个工具不可以的说法。

一些题外话

这些模块可能会在 /data/local/tmp 下创建目录用来注入 CA。若 apk 检测这些路径或系统凭据里是否出现这类 CA 名称，可能被用来做 root/环境检测。所以不抓包时记得把相关模块关掉。

[持续更新] - 为什么不应该为了实现需求而调用命令

2025-12-18T14:37:30.000Z

总结下一些案例场景，图快和方便调用命令在私有化的问题。

由来

在私有化的开发中，到现场客户反馈问题，聊一聊调用命令的后果和如何浪费了别人的时间。

案例

命令注入

有 dashboard 提供 url 检测，后端代码逻辑为：

取 post 的 ip
拼接 curl 命令

然后被安全部门注入了 ip; whoami; rm -rf / 被当作安全案例播放。以及另一个 ip ping 检测的调用 ping 命令拼接。url 检测完全可以调用 request 包，以及 icmp 的可以使用 socket 包。

拿 ping 来举例，某个版本有 ipv6 需求，你在自己的开发系统 ubuntu 上测试 ipv6 没问题：

$ ping ::1
PING ::1(::1) 56 data bytes
64 bytes from ::1: icmp_seq=1 ttl=64 time=0.505 ms
^C

然后提交后，测试人员出包测试后，来找你反馈说某些系统上有问题，你排查了一遍发现是在 centos7 上低版本 ping 测出问题了：

1 2	$ ping ::1 ping: ::1: Address family for hostname not supported

而如果你一开始使用 socket 编程，初期的 icmp 实现是：

1 2	sock = socket.socket(socket.AF_INET, socket.SOCK_RAW, socket.getprotobyname("icmp"))

在接收到 ipv6 需求后，你根据传入的 ip 使用 IPy 库判断 socket 的第一个选项是使用 socket.AF_INET 还是 socket.AF_INET6，测试后续压根不会因为系统来找你，避免了一来一回和挤占了别人时间。golang 的 icmp 实现可以参考 https://github.com/go-ping/ping

Popen 卡住

僵尸进程

在 Python 中，常见的几种调用命令的方式有：os.system(), os.popen(), subprocess.Popen() 等。其中，如果使用 subprocess.Popen() 并且没有调用 wait() 或者没有使用 communicate() 方法，那么子进程在结束后可能会变成僵尸进程。

$ ps aux | grep Z
USER       PID  %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root       2214  0.0  0.0      0     0 ?        Z    03:35   0:00 [docker] 
root       3727  0.0  0.0      0     0 ?        Z    14:21   0:00 [docker] 
root       4908  0.0  0.0      0     0 ?        Z    11:52   0:00 [docker] 
root       7979  0.0  0.0      0     0 ?        Z    14:31   0:00 [docker] 
root      13301  0.0  0.0      0     0 ?        Z    13:07   0:00 [docker] 
root      18508  0.0  0.0      0     0 ?        Z    10:57   0:00 [docker] 
root      20993  0.0  0.0      0     0 ?        Z    14:41   0:00 [docker] 
...

僵尸进程虽然不会占用 cpu mem，但是会占用 pid 资源：

# 默认的 pid max
$ cat /proc/sys/kernel/pid_max
32768
# 可以看到 pid 数字没释放
$ cat /proc/21190/cmdline

而私有化很多客户机器上有监控 agent，僵尸进程数量太多会告警，最后客户会反馈要求处理，而现场 pm 会先要求熟悉 linux 基础的同事 X 排查，最后发现是 daemon 类服务开发 Y 写的，给同事 X 增加定位时间。

命令实际上就是根据 cmdline、env 和命令的配置文件，最后去调用通过网络或者系统的 syscall 处理。例如之前看到一个文件处理服务，调用了 tar 命令最后产生很多僵尸进程的，压缩文件格式实际就是下面的流格式：

┌────────────────────────────────────────────────────────────────────┐
│                              TAR 归档文件                           │
├────────────────────────────────────────────────────────────────────┤
│                                                                    │
│  ┌─────────────────────────────────────────────────────────────┐   │
│  │                    文件1 - 头部 (512字节)                    │   │
│  │  name(100)  mode(8)  uid(8)  gid(8)  size(12)  mtime(12) .. │   │
│  └─────────────────────────────────────────────────────────────┘   │
│                                                                    │
│  ┌─────────────────────────────────────────────────────────────┐   │
│  │                    文件1 - 内容                              │   │
│  │    实际数据 (例如: "Hello World!")                           │   │
│  │                                                             │   │
│  │   填充到 512 字节倍数                                        │   │
│  └─────────────────────────────────────────────────────────────┘   │
│                                                                    │
│  ┌─────────────────────────────────────────────────────────────┐   │
│  │                    文件2 - 头部 (512字节)                    │   │
│  │  name(100)  mode(8)  uid(8)  gid(8)  size(12) ...           │   │
│  └─────────────────────────────────────────────────────────────┘   │
│                                                                    │
│  ┌─────────────────────────────────────────────────────────────┐   │
│  │                    文件2 - 内容                              │   │
│  │  实际数据 (例如: 二进制文件内容)                              │   │
│  │                                                             │   │
│  │  填充到 512 字节倍数                                         │   │
│  └─────────────────────────────────────────────────────────────┘   │
| .....

而每个编程语言都有对应的库的，完全可以使用库去处理，这里就不列举不通 rootfs 下 tar 行为和选项不一致的案例了，使用库在更换基础镜像就不会出现被动情况了。

客户监控

dashboard 有探测端口部分，然后调用的 nmap 命令实现，而很多政府单位机器上有 agent，针对 nmap 这种会认为是机器被黑成为肉鸡扫描其他机器，在护网期间这是非常严重的问题。然后又拉群和一堆人要求处理，最后动员一大堆人，给客户解释原因，客户要求整改。这个完全可以使用 socket 库实现：

def check_tcp_port(ip, port, timeout=1):
    if is_ipv6(ip) is True:
        sk = socket.socket(socket.AF_INET6, socket.SOCK_STREAM)
    else:
        sk = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
    sk.settimeout(timeout)
    try:
        sk.connect((ip, int(port)))
        return True
    except Exception as e:
        print(e)
        return False
    finally:
        sk.close()

命令限制和禁止

某个银行客户，排查问题的时候发现删不掉 pod：

1	kubectl delete pod xxx

最后感觉客户机器有啥软件是不是阻拦了关键字的执行，让实施人员执行：

$ echo 111
111
$ echo 111 delete
$

发现确实，然后去 dashboard 上点击删除的（背后走 k8s api），除了命令限制以外，还有客户不允许执行某些命令，例如 ssh，如果一开始就使用 python 的 paramiko 库就没这种问题了。

行为控制和错误处理

这里以 ssh 命令举例，Linux 的 ssh 和 sshd 的配置都存放在 /etc/ssh/ 下的 ssh_config 和 sshd_config ，而经常客户现场由于等保或者安全需求更改后，出问题了就在 ssh 调用上加 option：

$ find . -type f -name '*.py' -exec grep -P 'ssh .+-o' {} \;
        cmd = "timeout 10 ssh -q -F /dev/null -o StrictHostKeyChecking=no {}@{} -p {} sudo LC_ALL=C {}".format(
        cmd = "timeout 5 ssh {}@{} -o StrictHostKeyChecking=no -p {} ls".format(host_obj.username, host_obj.ip, host_obj.port)
        cmd1 = "timeout 5 ssh {}@{} -o StrictHostKeyChecking=no -p {} {}".format(
                "ssh -p %s -o PubkeyAuthentication=yes -o stricthostkeychecking=no %s@%s cat /etc/hosts 2>/dev/null | grep -m 1 ' xxx-init-job ' | awk '{print $1}'"
                create_cmd = "ssh -p %s -o PubkeyAuthentication=yes -o stricthostkeychecking=no %s@%s 'docker exec -i %s %s'" % (
                cmd = "ssh -p {} -o PubkeyAuthentication=yes -o stricthostkeychecking=no {}@{} 'docker exec -i {} ls /xxx/xxx/xxx-dc-main'".format(
    ssh_cmd = 'ssh -q -F /dev/null -o StrictHostKeyChecking=no {}@{} -p {} "{}"'.format(
# 而且不按照 -o 选项 find 出来的行数居然更多
$ find . -type f -name '*.py' -exec grep -P 'ssh .+@' {} \; | wc -l
22

而每个部分选项又不一样，后续又可能有问题，以及上面的 timeout，这些实际 paramiko 库都有选项可以设置。以及更精准的捕获，远端机器上执行一个命令，到底是 ssh 连接失败还是远端命令失败，库完全可以捕获到：

try:
    ssh.connect(...)
except paramiko.SSHException:
    # 连接层失败

甚至能完全区分 stdour 和 stderr：

ssh = paramiko.SSHClient()
ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy())
ssh.connect(ip, username="user", port=2222)
stdin, stdout, stderr = ssh.exec_command("x")

exit_code = stdout.channel.recv_exit_status()
out = stdout.read().decode()
err = stderr.read().decode()

文件权限

很多 cli 命令的执行需要授权信息，而 cmdline 调用会被客户扫到，非 cmdline 例如配置会在家目录下 ~/.xxx/xx.conf ，而在很多时候为了测试或者运行一个命令，需要产生文件让这个 cli 读取，然后因为容器 pid1 启动最后 gosu 启动切到非 root 运行，docker exec 进去是 root 用户，此刻调用产生的文件的 owner 是 root，后续 daemon 触发又报错权限问题。

例如之前的 mc 测试 minio 上传文件，实际可以使用 minio 的 python 库。以及 kubeconfig 文件权限，零星的有客户反馈要求权限问题，如果使用 kuberketes-api，授权信息存数据库，就能避免这种额外的整改需求。

后续扩展性


kubexxx_deploy_user = config_dict["HOSTS"][0]["username"]
kubexxx_deploy_ip = config_dict["HOSTS"][0]["ip"]
kubexxx_deploy_port = config_dict["HOSTS"][0]["ssh_port"]

ssh = paramiko.SSHClient()
ssh.set_missing_host_key_policy(paramiko.AutoAddPolicy())
ssh.connect(kubexxx_deploy_ip, kubexxx_deploy_port, kubexxx_deploy_user)

# 修改configmap和config.yaml
data_dir = config_dict["DATA_DIR"]
apisix_config_path = os.path.join(data_dir, "kube/apisix/config.yaml")
remote_cmd = f"sudo docker cp {apisix_config_path} kubexxx:/root/kubexxx;sudo docker exec kubexxx chown xxx:xxx /root/kubexxx/config.yaml"
_, stdout, stderr = ssh.exec_command(remote_cmd)
# 获取输出内容
out = stdout.read().decode().strip()
err = stderr.read().decode().strip()
logging.info("STDOUT:\n%s", out)
if err:
    logging.error("STDERR:\n%s", err)
    
# 重新创建configmap，重启pod
configmap_cmd = "kubectl delete cm -n default apisix; kubectl create cm -n default apisix --from-file=/root/kubexxx/config.yaml; kubectl get pods -n default | grep apisix | awk '{print $1}' | xargs -I {} kubectl delete pod -n default {}"
retcode, res = exec_cmd(configmap_cmd)
if retcode != 0:
    logging.error(res)
pod_cmd = "kubectl get pods -n default | grep apisix | awk '{print $1}' | xargs -I {} kubectl delete pod -n default {}"
retcode, res = exec_cmd(pod_cmd)
if retcode != 0:
    logging.error(res)

同样修改 configmap，完全库实现：

def change_backend_type(mode):

    config.load_kube_config()
    api_instance = client.CoreV1Api()

    cm_name = "kube-flannel-cfg"

    cm = api_instance.read_namespaced_config_map(name="kube-flannel-cfg", namespace="kube-system")
    cni_json_str = cm.data.get('net-conf.json', '{}')
    net_conf = json.loads(cni_json_str)
    net_conf['Backend']['Type'] = mode
    cm.data['net-conf.json'] = json.dumps(net_conf)
    result_cm = api_instance.patch_namespaced_config_map(cm_name, "kube-system", cm, pretty=True)
    if get_backend_from_cm(result_cm) != mode:
        logging.error("flannel backend Type修改为{0}失败: ".format(mode))
        return False
        
    logging.info("开始删除 flannel pod")
    pods = api_instance.list_namespaced_pod("kube-system", label_selector='app=flannel').items
    for pod in pods:
        logging.info(f"删除 flannel Pod: {pod.metadata.name}")
        api_instance.delete_namespaced_pod(name=pod.metadata.name, namespace="kube-system")

如果后续 dashboard 需要纳管多个 k8s 之类的，用库只需要修改 client 加载部分来操作具体集群，而且修改 configmap 不会产生临时文件，避免临时文件的权限问题，而命令形式的话 kubectl 拼一堆选项非常麻烦。

默认参数

很多命令有默认参数，再拿 ssh 举例，上面的 ssh，很多时候老是漏掉端口，很多客户的 ssh 端口不是默认的 22，如果基于 paramiko 库封装成方法，要求必须传入端口，能避免后续测试反馈以及客户现场暴漏。

tty

很多命令会通过 isatty(1)，isatty(2) 改变行为，程序调用时默认是非 tty，与人手敲命令完全不是一个世界，以及在管道里是非 tty 行为：

$ ls
Dockerfile  Makefile  README.md
$ ls | cat
Dockerfile
Makefile
README.md

如果不具备这些 Linux 知识，会浪费时间在这种问题上排查。

输出变更

很多时候调用命令是为了获取信息，而很多系统或者切换容器 os 后，命令的版本变化：

$ openssl version
OpenSSL 1.0.2k-fips  26 Jan 2017
$ openssl x509 -noout -text -in ca.pem 
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            77:b0:0a:e0:8c:5a:88:ee:89:9d:18:fa:48:94:c1:cf:28:f6:6d:d1
    Signature Algorithm: ecdsa-with-SHA256


$ openssl version
OpenSSL 3.0.2 15 Mar 2022 (Library: OpenSSL 3.0.2 15 Mar 2022)
$ openssl x509 -in ca.pem -noout -text
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            77:b0:0a:e0:8c:5a:88:ee:89:9d:18:fa:48:94:c1:cf:28:f6:6d:d1
        Signature Algorithm: ecdsa-with-SHA256

例如上面的 openssl 3 版本的 Signature 位置变化了，再例如 docker 新版本镜像输出变化：

# docker images | head
WARNING: This output is designed for human readability. For machine-readable output, please use --format.
IMAGE                                                                   ID             DISK USAGE   CONTENT SIZE   EXTRA
alpine:latest                                                           706db57fb206       8.32MB             0B        
busybox:glibc                                                           08ef35a1c3f0       4.43MB             0B        
busybox:latest                                                          08ef35a1c3f0       4.43MB             0B        
cr.loongnix.cn/kubernetes/etcd:3.5.14                                   dcb2aaf9fcc7       85.3MB             0B        
debian:11                                                               a20b5a7387bf        124MB             0B        
debian:trixie-slim                                                      58c1f2a9fa85       78.6MB             0B        
envoyproxy/envoy:v1.21.2                                                2c32b8d45d47        115MB             0B        
gcr.io/k8s-staging-dns/k8s-dns-dnsmasq-amd64:1.26.5-1-gcf293f8e         60f63d70918c       21.2MB             0B        
gcr.io/k8s-staging-dns/k8s-dns-dnsmasq-amd64:1.26.5-1-gcf293f8e-dirty   60f63d70918c       21.2MB             0B
$ docker images | grep none
WARNING: This output is designed for human readability. For machine-readable output, please use --format.

$ docker images --format table -a | head
REPOSITORY                                              TAG                                              IMAGE ID       CREATED         SIZE
hub-mirror.xxx.xx/xxxx-run/python                       3.12-amd64-oe-v1                                 8634b85409a9   2 hours ago     477MB
hub-mirror.xxx.xx/xxxx-run/python                       3.12.11-amd64-oe-v1                              8634b85409a9   2 hours ago     477MB
                                                                                             af0f5e291624   2 hours ago     477MB
                                                                                             1b7d81e61c72   2 hours ago     467MB
                                                                                             1affa42bade1   2 hours ago     467MB
                                                                                             3353b43ef79a   2 hours ago     467MB
                                                                                             789cff37497a   2 hours ago     467MB
                                                                                             410eb1000652   2 hours ago     467MB
                                                                                             c38df4d4aa02   3 hours ago     426MB

如果使用库完全不限于被动情况。

以及调用 free -h 判断机器内存有多少 g 情况，然后做限制判断，然后客户机器内存 1t了，free -h 显示的数字部分就是 1 了，认为客户机器内存只有 1G。实际上 free 命令就是读取的 /proc 目录：

$ strace free -h |& grep /proc/
openat(AT_FDCWD, "/proc/self/auxv", O_RDONLY) = 3
openat(AT_FDCWD, "/proc/sys/kernel/osrelease", O_RDONLY) = 3
openat(AT_FDCWD, "/proc/self/auxv", O_RDONLY) = 3
openat(AT_FDCWD, "/proc/sys/kernel/osrelease", O_RDONLY) = 3
openat(AT_FDCWD, "/proc/meminfo", O_RDONLY) = 3

$ free -h
              total        used        free      shared  buff/cache   available
Mem:            62G        9.8G         11G        3.0M         40G         52G
Swap:            0B          0B          0B
$ head /proc/meminfo 
MemTotal:       65806560 kB
MemFree:        12365980 kB
MemAvailable:   54861520 kB
Buffers:            2104 kB
Cached:         40519256 kB

以及其他的 /proc/cpuinfo 、/proc/mounts 和 /sys/ 目录。

引发事故

早期的环境检查单独的脚本里，为了检查某些 sysctl 参数调用了 sysctl -p ，而某天同事 A 去重要客户生产环境执行环境检查，执行完后环境崩了，被客户骂赶紧解决。最后排查到是客户修改了 /etc/sysctl.conf 内关闭 net.ipv4.ip_forward = 0 转发，本质这个环境检查就是看这些需要检查的内核参数，完全可以从 /proc 目录下获取和写入就行：

1 2	$ cat /proc/sys/net/ipv4/ip_forward 1

没考虑到的场景

因为网上很多 ssl证书生成都是用的 openssl rsa 生成证书，证书合法性使用 openssl rsa 判断证书 crt 的公钥部分是不是 key 的公钥：

check_crt = subprocess.Popen(
    "openssl x509 -pubkey -noout -in {0}".format(crt_path),
    shell=True,
    stdout=subprocess.PIPE,
)
check_crt.wait()
check_key = subprocess.Popen(
    "openssl rsa -pubout  -in {0}".format(key_path),
    shell=True,
    stdout=subprocess.PIPE,
)
check_key.wait()
if check_crt.returncode == 0:
    check_crt_result = check_crt.stdout.read()
else:
    check_crt_result = False
if check_key.returncode == 0:
    check_key_result = check_key.stdout.read()
else:
    check_key_result = False

然后客户的证书是使用 ecdsa 算法生成(生成效率快，体积更小)，实施使用 nginx 起容器测试没问题，最后临时给证书检验的改为了 openssl pkey -pubout -in，如果调用命令，难道每个 openssl 子命令循环一边吗。

from cryptography import x509
from cryptography.hazmat.primitives.asymmetric import rsa, ec

def cert_key_type(cert_path: str) -> str:
    with open(cert_path, "rb") as f:
        data = f.read()

    try:
        cert = x509.load_pem_x509_certificate(data)
    except ValueError:
        cert = x509.load_der_x509_certificate(data)

    pubkey = cert.public_key()

    if isinstance(pubkey, rsa.RSAPublicKey):
        return "RSA"
    elif isinstance(pubkey, ec.EllipticCurvePublicKey):
        return "ECDSA"
    else:
        return type(pubkey).__name__

以及 cryptography 库还可以生成 ssl 证书，不需要像 openssl 那样产生临时文件调用多次命令。

参数废弃

命令选项的废弃只有运行时候才知道，而如果使用库的话，在代码 lint 层面或者 import 的时候就会报错，避免问题发生时间的滞后。

一些 python 替代

一些文件操作

1
2
3

shutil.copy
shutil.copyfile
shutil.rmtree

通配符文件：

1	glob.glob(f"{IPVS_DIRS}/*.ipvs.conf")

find 类似的路径匹配获取：

1	tag_dirs = [str(p) for p in Path(registry_dir).rglob("/_manifests/tags/")]

一些 sdk 经验

开源 sdk 单独的 logger，在 import 的里会有些输出，关闭的话可以在 import 之前关闭。

1 2	logging.getLogger('docker').setLevel(logging.CRITICAL) logging.getLogger('salt').setLevel(logging.CRITICAL)

使用 ansible runner 默认会保留 tmp 目录，可以：


import os
import ansible_runner
import logging
import shutil


# 默认的 artifacts 处理器
def default_artifacts_handler(artifacts_dir):
    shutil.rmtree(artifacts_dir.split("artifacts/")[0], ignore_errors=True)

# 默认的 event 处理器
def default_event_handler(event):
    line = event.get("stdout", "")
    if line.strip():
        logging.info(line.strip())

def run_ansible_playbook(
    playbook,
    inventory=None,
    user=None,
    private_key=None,
    limit_hosts=None,
    extra_cmdline="",
    base_path=None,
    become=True,
    become_method="sudo",
    suppress_output=True,
    artifacts_handler=None,
    event_handler=None,
):
    """
    执行 Ansible playbook 的封装方法
    
    参数:
        playbook (str): playbook 文件路径
        inventory (str|list): inventory 文件路径，可以是单个路径或路径列表
        user (str): SSH 用户名，默认从环境变量 USER 获取
        private_key (str): SSH 私钥路径
        limit_hosts (list): 限制执行的主机列表
        extra_cmdline (str): 额外的命令行参数
        base_path (str): 基础路径
        become (bool): 是否使用 become
        become_method (str): become 方法
        suppress_output (bool): 是否抑制 ansible 输出
        artifacts_handler (callable): 自定义 artifacts 处理器
        event_handler (callable): 自定义 event 处理器
    
    返回:
        ansible_runner 的运行结果
    """
    
    artifacts_handler = artifacts_handler or default_artifacts_handler
    event_handler = event_handler or default_event_handler
    private_key = private_key or "/root/.ssh/id_rsa"

    # 构建 ansible 命令行参数
    cmdline_parts = []
    
    # 用户名
    user = user or os.getenv("USER")
    if user:
        cmdline_parts.append(f"-u {user}")
    
    # 私钥
    if private_key:
        cmdline_parts.append(f"--private-key={private_key}")
    
    # become
    if become:
        cmdline_parts.append("-b")
        if become_method:
            cmdline_parts.append(f"--become-method={become_method}")
    
    # 限制主机
    if limit_hosts:
        if isinstance(limit_hosts, list):
            cmdline_parts.append(f"--limit={','.join(limit_hosts)}")
        else:
            cmdline_parts.append(f"--limit={limit_hosts}")
    
    if extra_cmdline:
        cmdline_parts.append(extra_cmdline)
    
    ansible_cmdline = " ".join(cmdline_parts)
    
    if isinstance(inventory, str):
        inventory_list = [inventory]
    elif isinstance(inventory, list):
        inventory_list = inventory
    else:
        inventory_list = []

    # 执行 ansible
    r = ansible_runner.run(
        inventory=inventory_list,
        playbook=playbook,
        cmdline=ansible_cmdline,
        artifacts_handler=artifacts_handler,
        event_handler=event_handler,
        settings={"suppress_ansible_output": suppress_output},
    )
    
    return r

salt -N xxx module.name args 实际上可以看 cat $(which salt) 找下源码，可以使用 salt.client：

import salt.client
salt_client = salt.client.LocalClient()
# result = {'10.xx.xx.xxx': True, '10.xxx.xx.xxx': 'Minion did not return. xxxx'}
result = salt_client.cmd(tgt='*', fun='pillar.items', arg=["data_dir"], tgt_type="glob")
print(result)

docker 重启非 host 网络容器造成 dns 异常的梳理和pr修复

2025-11-12T10:30:30.000Z

docker 重启非 host 网络容器造成 dns 异常的梳理和pr修复

由来

内部产品是 toB 和 toG，针对 toG 的完全内网，测试会在搭建的 K8S 集群上所有节点配置个假的 DNS，这样黑盒下测功能，避免业务访问公网而造成功能问题。但是有些后续新业务是依赖公网的，测试测完没公网的部分后就会配置真实 dns 后测这部分功能，之前就遇到过好几次配置节点 DNS 后，个别 Pod 内 DNS 内容不是 k8s 的，而是下面这样类似变成宿主机：

# Generated by Docker Engine.
# This file can be edited; Docker Engine will not make further changes once it
# has been modified.

nameserver 10.xx.xx.xxx

# Based on host file: '/run/systemd/resolve/resolv.conf' (legacy)
# Overrides: []

我们是使用的 cri-dockerd + k8s 组合。

过程

之前反馈了几次，但是一直没稳定复现手段，就先去看了下大概这块 docker 源码，然后给测试说，下次开发环境遇到了别删除 Pod 和对应容器，直接喊我，2025/11/11 下午反馈找到稳定复现步骤了，我们有个 dashboard，测试环境上开发在上面重启了他的 Pod 下的容器，该 Pod 的 spec.containers 只有一个，勾选的是类似 docker ps -a 的那样，/pause 容器和他的容器都勾选点重启的。上面点了下确实发生了。

日志

找到容器所在节点上去看：

$ kubectl get pod -o wide -A | grep ai-aixxxxapi
default       ai-aixxxxapi-6698f696d8-5w8kw                                1/1     Running            1 (27m ago)      35m     10.187.x.34    10.1x.5x.251              
$ ip r g 1
1.0.0.0 via 10.1x.5x.1 dev eth0 src 10.1x.5x.251 uid 0 
    cache 
$ docker ps -a | grep  ai-aixxxxapi-6698f696d8-5w8kw 
8b4ae64cecc0   reg.xxx.lan:5000/xxx/ai-aixxxxapi                                                "/usr/local/bin/star…"   27 minutes ago      Up 27 minutes                         k8s_ai-aixxxxapi_ai-aixxxxapi-6698f696d8-5w8kw_default_79fc032c-e1d3-4603-b21f-e5400ac6e3b6_1
e8eb18aaca94   reg.xxx.lan:5000/xxx/pause:3.9                                                   "/pause"                 27 minutes ago      Up 27 minutes                         k8s_POD_ai-aixxxxapi-6698f696d8-5w8kw_default_79fc032c-e1d3-4603-b21f-e5400ac6e3b6_1
96ea991f9bb3   reg.xxx.lan:5000/xxx/ai-aixxxxapi                                                "/usr/local/bin/star…"   34 minutes ago      Exited (2) 27 minutes ago             k8s_ai-aixxxxapi_ai-aixxxxapi-6698f696d8-5w8kw_default_79fc032c-e1d3-4603-b21f-e5400ac6e3b6_0
e4c64897be98   reg.xxx.lan:5000/xxx/pause:3.9                                                   "/pause"                 35 minutes ago      Exited (0) 27 minutes ago             k8s_POD_ai-aixxxxapi-6698f696d8-5w8kw_default_79fc032c-e1d3-4603-b21f-e5400ac6e3b6_0
$ docker inspect 96ea991f9bb3 | grep Resolv
        "ResolvConfPath": "/data/kube/docker/containers/e4c64897be9891d88b999e81bfd55bb0cc1c21d626708749691d43158062f2bb/resolv.conf",
$ cat /data/kube/docker/containers/e4c64897be9891d88b999e81bfd55bb0cc1c21d626708749691d43158062f2bb/resolv.conf
# Generated by Docker Engine.
# This file can be edited; Docker Engine will not make further changes once it
# has been modified.

nameserver 10.xx.41.103

# Based on host file: '/run/systemd/resolve/resolv.conf' (legacy)
# Overrides: []
$ stat /data/kube/docker/containers/e4c64897be9891d88b999e81bfd55bb0cc1c21d626708749691d43158062f2bb/resolv.conf
  File: /data/kube/docker/containers/e4c64897be9891d88b999e81bfd55bb0cc1c21d626708749691d43158062f2bb/resolv.conf
  Size: 238       Blocks: 8          IO Block: 4096   regular file
Device: 811h/2065dInode: 32449846    Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2025-11-11 15:52:45.692564762 +0800
Modify: 2025-11-11 15:52:45.648562824 +0800
Change: 2025-11-11 15:52:45.655896480 +0800
 Birth: -

容器 id e4c64897be98 找下日志看看：

$ journalctl -xe --no-pager -u docker | grep -P '96ea991f9bb3|e4c64897be98'
Nov 11 15:52:45 ubuntu2004chenxxxx7YX6V70 dockerd[3974]: time="2025-11-11T15:52:45.083407489+08:00" level=warning msg="cleaning up after shim disconnected" id=96ea991f9bb3454bec28712cb91c97f684e8f113e1b45697244190347a8c8305 namespace=moby
Nov 11 15:52:45 ubuntu2004chenxxxx7YX6V70 dockerd[3974]: time="2025-11-11T15:52:45.587632737+08:00" level=warning msg="cleaning up after shim disconnected" id=e4c64897be9891d88b999e81bfd55bb0cc1c21d626708749691d43158062f2bb namespace=moby
Nov 11 15:53:10 ubuntu2004chenxxxx7YX6V70 dockerd[3974]: time="2025-11-11T15:53:10.794469549+08:00" level=warning msg="cleaning up after shim disconnected" id=96ea991f9bb3454bec28712cb91c97f684e8f113e1b45697244190347a8c8305 namespace=moby
Nov 11 15:53:11 ubuntu2004chenxxxx7YX6V70 dockerd[3974]: time="2025-11-11T15:53:11.417476169+08:00" level=warning msg="cleaning up after shim disconnected" id=e4c64897be9891d88b999e81bfd55bb0cc1c21d626708749691d43158062f2bb namespace=moby

也看下容器时间相关：

$ docker inspect e4c
[
    {
        "Id": "e4c64897be9891d88b999e81bfd55bb0cc1c21d626708749691d43158062f2bb",
        "Created": "2025-11-11T07:44:57.093893019Z", 👈 创建时间
        "Path": "/pause",
        "Args": [],
        "State": {
            "Status": "exited",
            "Running": false,
            "Paused": false,
            "Restarting": false,
            "OOMKilled": false,
            "Dead": false,
            "Pid": 0,
            "ExitCode": 0,
            "Error": "",
            "StartedAt": "2025-11-11T07:52:45.856187062Z",
            "FinishedAt": "2025-11-11T07:53:11.408195153Z"
        },

也看下 cri-dockerd 的日志：

1
2

$ journalctl -xe --no-pager -u cri-dockerd | grep e4c64897be9891d88b999e81bfd55bb0cc1c21d626708749691d43158062f2bb
Nov 11 15:45:03 ubuntu2004chenxxxx7YX6V70 cri-dockerd[51041]: time="2025-11-11T15:45:03+08:00" level=info msg="Will attempt to re-write config file /data/kube/docker/containers/e4c64897be9891d88b999e81bfd55bb0cc1c21d626708749691d43158062f2bb/resolv.conf as [nameserver 10.186.0.2 search default.svc.cluster1.local. svc.cluster1.local. cluster1.local. options ndots:5]"

根据上面日志总结时间线：

15.44.47 创建 /pause 容器
15:45:03 cri-dockerd 拉完业务镜像后创建 sandbox 容器，re-write 了容器的 resolv.conf，这块源码逻辑可以搜 Will attempt to re-write
15.52.45 重启了容器
容器的 resolv.conf 根据 mtime 看发生改变

最小复现

后端重启容器逻辑是同事写的，我记得大概逻辑是 python docker client 调用 docker 重启的，直接二分，如果 docker restart 复现了就不是 dashboard 后端逻辑造成的。然后环境上复现了，然后自己搭建个干净 K8S 也复现了。

$ cat testpod.yml
apiVersion: v1
kind: Pod
metadata:
  name: testpod
spec:
  containers:
  - name: testpod
    image: m.daocloud.io/docker.io/library/nginx:latest
#  nodeName: xxx

单节点，如果固定节点的话设置下 nodeName 即可，复现：

$ docker ps -a | grep testpod
73b346e11ef4   m.daocloud.io/docker.io/library/nginx                                            "/docker-entrypoint.…"   3 minutes ago       Up 3 minutes                          k8s_vulnerable-container_testpod_default_f8215913-32b2-4e18-8536-69e5ecce7c84_0
ad255b51f1b3   reg.xxx.lan:5000/xxx/pause:3.9                                                   "/pause"                 3 minutes ago       Up 3 minutes                          k8s_POD_testpod_default_f8215913-32b2-4e18-8536-69e5ecce7c84_0
$ docker inspect 73b346e11ef4 | grep ResolvConfPath
        "ResolvConfPath": "/data/kube/docker/containers/ad255b51f1b396fdea0d2579b373ac5c497fbd707031fa53936e805ac1b30cc9/resolv.conf",
$ cat /data/kube/docker/containers/ad255b51f1b396fdea0d2579b373ac5c497fbd707031fa53936e805ac1b30cc9/resolv.conf
nameserver 10.186.0.2
search default.svc.cluster1.local. svc.cluster1.local. cluster1.local.
options ndots:5
$ docker restart 73b346e11ef4 ad255b51f1b3
73b346e11ef4
ad255b51f1b3
$ cat /data/kube/docker/containers/ad255b51f1b396fdea0d2579b373ac5c497fbd707031fa53936e805ac1b30cc9/resolv.conf
# Generated by Docker Engine.
# This file can be edited; Docker Engine will not make further changes once it
# has been modified.

nameserver 10.x3.41.103

# Based on host file: '/run/systemd/resolve/resolv.conf' (legacy)
# Overrides: []

Pod 的创建流程是容器运行时先创建一个 /pause 容器，然后 pod.spec.containers 的容器会 join 到 /pause 上，而 docker 下容器的 hosts、resolv.conf 和 hostname 这些是单独一层 init 层处理的，会创建文件，Pod 的所有容器都使用同一份：

$ docker ps -a | grep testpod
f6ef003b4864   xxx
340e173d875b   xxxx
$ docker inspect 340e173d875b | grep ResolvConfPath
        "ResolvConfPath": "/data/kube/docker/containers/340e173d875b00b6aca32f8770493b9f1d86159340bcea6bc01b93992763bab7/resolv.conf",
$ docker inspect f6ef003b4864 | grep ResolvConfPath
        "ResolvConfPath": "/data/kube/docker/containers/340e173d875b00b6aca32f8770493b9f1d86159340bcea6bc01b93992763bab7/resolv.conf",
$ cat /data/kube/docker/containers/340e173d875b00b6aca32f8770493b9f1d86159340bcea6bc01b93992763bab7/resolv.conf
nameserver 10.186.0.2
search default.svc.cluster2.local. svc.cluster2.local. cluster2.local.
options ndots:5

$ ls -1 /data/kube/docker/containers/340e173d875b00b6aca32f8770493b9f1d86159340bcea6bc01b93992763bab7/
340e173d875b00b6aca32f8770493b9f1d86159340bcea6bc01b93992763bab7-json.log
checkpoints
config.v2.json
hostconfig.json
hostname
hosts
mounts
resolv.conf
resolv.conf.hash

然后发现最小化复现是只重启 /pause 容器发生：

$ docker ps -a | grep testpod
ef9bb3c69dfa   reg.xxx.lan:5000/xxx/nginx                                                       "/docker-entrypoint.…"   2 minutes ago    Up 2 minutes                              k8s_vulnerable-container_testpod_default_ebb8ace6-84ab-4a28-814c-109c41827908_1
e6868ab3d8ef   reg.xxx.lan:5000/xxx/pause:3.9                                                   "/pause"                  2 minutes ago    Up 2 minutes                              k8s_POD_testpod_default_ebb8ace6-84ab-4a28-814c-109c41827908_1
$ docker inspect e6868ab3d8ef | grep ResolvConfPath
        "ResolvConfPath": "/data/kube/docker/containers/e6868ab3d8ef8fa1238a82a15faa88b1d13967a71a1e16c99618663610d21286/resolv.conf",
$ cat /data/kube/docker/containers/e6868ab3d8ef8fa1238a82a15faa88b1d13967a71a1e16c99618663610d21286/resolv.conf
nameserver 10.186.0.2
search default.svc.cluster2.local. svc.cluster2.local. cluster2.local.
options ndots:5
$ docker restart e6868ab3d8ef
e6868ab3d8ef
$ cat /data/kube/docker/containers/e6868ab3d8ef8fa1238a82a15faa88b1d13967a71a1e16c99618663610d21286/resolv.conf
# Generated by Docker Engine.
# This file can be edited; Docker Engine will not make further changes once it
# has been modified.

nameserver 223.5.5.5

# Based on host file: '/etc/resolv.conf' (legacy)
# Overrides: []

修复

从以上结论来看，kubelet 没问题，cri-dockerd 也没问题（它 re-write 行为和人为修改一样），只可能在 docker 方面修复了，根据上面调用链，restart 容器实际走的：

(dlv) bt
 0  0x0000000002470d2f in github.com/docker/docker/libnetwork.(*Controller).NewSandbox
    at ./libnetwork/controller.go:944
 1  0x0000000002f855e5 in github.com/docker/docker/daemon.(*Daemon).connectToNetwork
    at ./daemon/container_operations.go:762
 2  0x0000000002f82825 in github.com/docker/docker/daemon.(*Daemon).allocateNetwork
    at ./daemon/container_operations.go:525
 3  0x0000000002f87d05 in github.com/docker/docker/daemon.(*Daemon).initializeNetworking
    at ./daemon/container_operations.go:950
 4  0x000000000302d26b in github.com/docker/docker/daemon.(*Daemon).containerStart
    at ./daemon/start.go:117
 5  0x0000000003028736 in github.com/docker/docker/daemon.(*Daemon).containerRestart

看了下就是根据 restart 的 id 获取 containerConfig，containerRestart 调用逻辑是先 stop 在 start，由于是 sandbox，所以重建了一个 sandbox，重建的关键地方在 container_operations.go 内，使用 stop 之前的 containerConfig，创建 SandboxOption 的 slice 。

sbOptions, err := buildSandboxOptions(cfg, ctr)
if err != nil {
return nil, err
}
sb, err := daemon.netController.NewSandbox(ctx, ctr.ID, sbOptions...)

想法是增加一个 SandboxOption 设置 sandbox 的结构体增加一个 flag ，来判断 SandBox 是否由重启行为创建，然后写相关逻辑处理就行，pr 改动如下：

diff --git a/daemon/container_operations.go b/daemon/container_operations.go
index 1ed84bb04e4a0..c00b074881d31 100644
--- a/daemon/container_operations.go
+++ b/daemon/container_operations.go
@@ -149,6 +149,10 @@ func buildSandboxOptions(cfg *config.Config, ctr *container.Container) ([]libnet
 
 sboxOptions = append(sboxOptions, libnetwork.OptionPortMapping(publishedPorts), libnetwork.OptionExposedPorts(exposedPorts))
 
+if !ctr.State.StartedAt.IsZero() && !ctr.State.FinishedAt.IsZero() {
+sboxOptions = append(sboxOptions, libnetwork.OptionCreateByRestart())
+}
+
 return sboxOptions, nil
 }
 
diff --git a/daemon/libnetwork/sandbox.go b/daemon/libnetwork/sandbox.go
index 4d0236f2e4628..606403e5d08f8 100644
--- a/daemon/libnetwork/sandbox.go
+++ b/daemon/libnetwork/sandbox.go
@@ -37,23 +37,24 @@ func (sb *Sandbox) processOptions(options ...SandboxOption) {
 // Sandbox provides the control over the network container entity.
 // It is a one to one mapping with the container.
 type Sandbox struct {
-id              string
-containerID     string
-config          containerConfig
-extDNS          []extDNSEntry
-osSbox          *osl.Namespace
-controller      *Controller
-resolver        *Resolver
-resolverOnce    sync.Once
-dbIndex         uint64
-dbExists        bool
-isStub          bool
-inDelete        bool
-ingress         bool
-ndotsSet        bool
-oslTypes        []osl.SandboxType // slice of properties of this sandbox
-loadBalancerNID string            // NID that this SB is a load balancer for
-mu              sync.Mutex
+id               string
+containerID      string
+config           containerConfig
+extDNS           []extDNSEntry
+osSbox           *osl.Namespace
+controller       *Controller
+resolver         *Resolver
+resolverOnce     sync.Once
+dbIndex          uint64
+dbExists         bool
+isStub           bool
+inDelete         bool
+ingress          bool
+createdByRestart bool
+ndotsSet         bool
+oslTypes         []osl.SandboxType // slice of properties of this sandbox
+loadBalancerNID  string            // NID that this SB is a load balancer for
+mu               sync.Mutex
 
 // joinLeaveMu is required as well as mu to modify the following fields,
 // acquire joinLeaveMu first, and keep it at-least until gateway changes
diff --git a/daemon/libnetwork/sandbox_dns_unix.go b/daemon/libnetwork/sandbox_dns_unix.go
index a5aac066e925b..c99b382b70894 100644
--- a/daemon/libnetwork/sandbox_dns_unix.go
+++ b/daemon/libnetwork/sandbox_dns_unix.go
@@ -264,8 +264,17 @@ func (sb *Sandbox) loadResolvConf(path string) (*resolvconf.ResolvConf, error) {
 // be a copy of the host's file, with overrides for nameservers, options and search
 // domains applied.
 func (sb *Sandbox) setupDNS() error {
-// Make sure the directory exists.
 sb.restoreResolvConfPath()
+
+// Fixes https://github.com/moby/moby/issues/51490
+// non-host network sandbox should check resolvconf.UserModified
+if sb.createdByRestart && !sb.config.useDefaultSandBox {
+if mod, err := resolvconf.UserModified(sb.config.resolvConfPath, sb.config.resolvConfHashFile); err != nil || mod {
+return err
+}
+}
+
+// Make sure the directory exists.
 dir, _ := filepath.Split(sb.config.resolvConfPath)
 if err := createBasePath(dir); err != nil {
 return err
diff --git a/daemon/libnetwork/sandbox_dns_unix_test.go b/daemon/libnetwork/sandbox_dns_unix_test.go
index 3bb64cf5ce5b5..93700c20ced08 100644
--- a/daemon/libnetwork/sandbox_dns_unix_test.go
+++ b/daemon/libnetwork/sandbox_dns_unix_test.go
@@ -14,12 +14,17 @@ import (
 is "gotest.tools/v3/assert/cmp"
 )
 
-func getResolvConfOptions(t *testing.T, rcPath string) []string {
+func getResolvConf(t *testing.T, rcPath string) resolvconf.ResolvConf {
 t.Helper()
 resolv, err := os.ReadFile(rcPath)
 assert.NilError(t, err)
 rc, err := resolvconf.Parse(bytes.NewBuffer(resolv), "")
 assert.NilError(t, err)
+return rc
+}
+
+func getResolvConfOptions(t *testing.T, rcPath string) []string {
+rc := getResolvConf(t, rcPath)
 return rc.Options()
 }
 
@@ -90,3 +95,69 @@ func TestDNSOptions(t *testing.T) {
 dnsOptionsList = getResolvConfOptions(t, sb2.config.resolvConfPath)
 assert.Check(t, is.DeepEqual([]string{"ndots:0"}, dnsOptionsList))
 }
+
+func TestNonHostNetDNSRestart(t *testing.T) {
+c, err := New(context.Background(), config.OptionDataDir(t.TempDir()))
+assert.NilError(t, err)
+
+// Step 1: Create initial sandbox (simulating first container start)
+sb, err := c.NewSandbox(context.Background(), "cnt1")
+assert.NilError(t, err)
+
+sb.startResolver(false)
+
+err = sb.setupDNS()
+assert.NilError(t, err)
+err = sb.rebuildDNS()
+assert.NilError(t, err)
+
+// Step 2: Simulate cri-dockerd modifying the resolv.conf for a Kubernetes pause container.
+// This mimics the behavior where external tools (like cri-dockerd) customize DNS
+// settings for K8s pods, which should be preserved during container restart/unpause.
+resolvConfPath := sb.config.resolvConfPath
+modifiedContent := []byte(`nameserver 10.96.0.10
+search default.svc.cluster.local. svc.cluster.local. cluster.local.
+options ndots:5
+`)
+err = os.WriteFile(resolvConfPath, modifiedContent, 0644)
+assert.NilError(t, err)
+
+// Step 3: Delete the sandbox (simulating container stop)
+err = sb.Delete(context.Background())
+assert.NilError(t, err)
+
+// Step 4: Create a new sandbox with OptionRestartOperate (simulating container restart)
+sbRestart, err := c.NewSandbox(context.Background(), "cnt1",
+OptionCreateByRestart(),
+OptionResolvConfPath(resolvConfPath),
+)
+assert.NilError(t, err)
+defer func() {
+if err := sbRestart.Delete(context.Background()); err != nil {
+t.Error(err)
+}
+}()
+
+sbRestart.startResolver(false)
+
+// Step 5: Call setupDNS on restart - should preserve external modifications
+err = sbRestart.setupDNS()
+assert.NilError(t, err)
+
+// Verify that the DNS settings modified by cri-dockerd are preserved
+rc := getResolvConf(t, sbRestart.config.resolvConfPath)
+assert.Check(t, is.Len(rc.Options(), 1))
+assert.Check(t, is.Equal("10.96.0.10", rc.NameServers()[0].String()))
+assert.Check(t, is.DeepEqual([]string{"default.svc.cluster.local.", "svc.cluster.local.", "cluster.local."}, rc.Search()))
+assert.Check(t, is.Equal("ndots:5", rc.Options()[0]))
+
+err = sbRestart.rebuildDNS()
+assert.NilError(t, err)
+
+rc = getResolvConf(t, sbRestart.config.resolvConfPath)
+assert.Check(t, is.Len(rc.Options(), 1))
+assert.Check(t, is.Equal("10.96.0.10", rc.NameServers()[0].String()))
+assert.Check(t, is.DeepEqual([]string{"default.svc.cluster.local.", "svc.cluster.local.", "cluster.local."}, rc.Search()))
+assert.Check(t, is.Equal("ndots:5", rc.Options()[0]))
+
+}
diff --git a/daemon/libnetwork/sandbox_options.go b/daemon/libnetwork/sandbox_options.go
index ba05582dec270..8210d3bd6845b 100644
--- a/daemon/libnetwork/sandbox_options.go
+++ b/daemon/libnetwork/sandbox_options.go
@@ -151,3 +151,11 @@ func OptionLoadBalancer(nid string) SandboxOption {
 sb.oslTypes = append(sb.oslTypes, osl.SandboxTypeLoadBalancer)
 }
 }
+
+// OptionCreateByRestart function returns an option setter for marking a
+// sandbox was created by restart.
+func OptionCreateByRestart() SandboxOption {
+return func(sb *Sandbox) {
+sb.createdByRestart = true
+}
+}
diff --git a/integration/networking/resolvconf_test.go b/integration/networking/resolvconf_test.go
index c0119bd650be0..4a84077adbb6e 100644
--- a/integration/networking/resolvconf_test.go
+++ b/integration/networking/resolvconf_test.go
@@ -212,3 +212,47 @@ func TestNslookupWindows(t *testing.T) {
 // can only be changed in daemon.json using feature flag "windows-dns-proxy".
 assert.Check(t, is.Contains(res.Stdout.String(), "Addresses:"))
 }
+
+// TestResolvConfPreservedOnRestart verifies that external modifications to
+// /etc/resolv.conf are preserved when a non-host network container is restarted.
+// Regression test for https://github.com/moby/moby/issues/51490
+func TestResolvConfPreservedOnRestart(t *testing.T) {
+skip.If(t, testEnv.DaemonInfo.OSType == "windows", "No /etc/resolv.conf on Windows")
+
+ctx := setupTest(t)
+
+d := daemon.New(t, daemon.WithResolvConf(network.GenResolvConf("8.8.8.8")))
+d.StartWithBusybox(ctx, t)
+defer d.Stop(t)
+
+c := d.NewClientT(t)
+defer c.Close()
+
+const ctrName = "test-resolvconf-preserved-on-restart"
+id := container.Run(ctx, t, c,
+container.WithName(ctrName),
+container.WithImage("busybox:latest"),
+container.WithCmd("top"),
+)
+defer c.ContainerRemove(ctx, id, client.ContainerRemoveOptions{
+Force: true,
+})
+
+appendContent := `# hello`
+res, err := container.Exec(ctx, c, ctrName, []string{
+"sh", "-c",
+"echo '" + appendContent + "' >> /etc/resolv.conf",
+})
+assert.NilError(t, err)
+assert.Check(t, is.Equal(res.ExitCode, 0))
+
+// Restart the container.
+_, err = c.ContainerRestart(ctx, ctrName, client.ContainerRestartOptions{})
+assert.Assert(t, is.Nil(err))
+
+// Verify the modification was preserved
+res, err = container.Exec(ctx, c, ctrName, []string{"tail", "-n", "1", "/etc/resolv.conf"})
+assert.NilError(t, err)
+assert.Check(t, is.Equal(res.ExitCode, 0))
+assert.Check(t, is.Contains(res.Stdout(), appendContent))
+}

2025/11/12 提交 pr https://github.com/moby/moby/pull/51507 后，单元测试啥的都在 github action 里跑过了，然后 docker member 发现一个类似问题：

$ docker run -d --name hello nginx:alpine
2daa4fc6f6c6c708c394c9b490f80a83269108907b86059d7d472f1f735d8b34
$ docker exec hello sh -c 'echo "nameserver 1.1.1.1" > /etc/resolv.conf'
$ docker exec hello sh -c 'tail -n 1 /etc/resolv.conf'
nameserver 1.1.1.1
$ docker restart hello
$ docker exec hello sh -c 'tail -n 1 /etc/resolv.conf'
# Overrides: []

按照我修复后的代码测试了下，也可以解决这个问题，docker libnetwork 负责人 akerouanton 说我这种重启 /pause 是非标行为，但是上面这种默认桥接网络也会发生，他给我 code review了下。
reivew 评论说 createdByRestart 标志会无效，当 docker 宕机以及类似掉电情况下就无效了，让我去掉这个选项。

仔细想了下确实，意外情况下不会走正常的 restart 流程去应用上这个选项，后面就是讨论和 2025/11/26 合入了，预计 docker v29.0.5 版本带出。

docker open /var/lib/docker/tmp/GetImageBlobXXX: no such file 的正确处理方式

2025-11-06T10:30:30.000Z

docker open /var/lib/docker/tmp/GetImageBlobXXX: no such file or directory. 解决

由来

测试反馈 04:33 出包失败，相关步骤报错：

$ docker run -d -p 48835:5000 --name daily-master-K8S_XC-2298 -v /xxx/images:/var/lib/registry harbor.xxx.cn/xxx-base/registry:2.6.1
Unable to find image 'harbor.xxx.cn/xxx-base/registry' locally
2.6.1: Pulling from xxx-base/registry
53478ce18e19: Pulling fs layer
907370c150a1: Pulling fs layer
ecd89ee27260: Pulling fs layer
e4d3e6950197: Pulling fs layer
a0c226b30c4f: Pulling fs layer
d4bda1830450: Pulling fs layer
f441bc34ec75: Pulling fs layer
877c19e43805: Pulling fs layer
docker: open /work/docker/tmp/GetImageBlob838250894: no such file or directory.
See 'docker run --help'.

我们的 docker 设置了 data-root，如果默认路径会是 open /var/lib/docker/tmp/GetImageBlob

处理过程

复现

根据构建日志，登录到构建机器上，手动拉镜像也复现：

$ docker pull harbor.xxx.cn/xxxx-run/gosu:v1
v1: Pulling from xxxx-run/gosu
e9abf7e9593f: Pulling fs layer 
open /work/docker/tmp/GetImageBlob159490514: no such file or directory

去 jenkins 上看这台机器没构建任务，给标记下线状态避免影响其他构建。

排查

这种报错很直观了，不要造轮子和要学会善用搜索引擎，结果搜到都是说重启 docker 解决，如果一个开源项目存在一个必现问题，那就不是问题，golang 项目里妥善 return err 的话，直接源码能搜到相关逻辑，源码里搜 GetImageBlob 搜到：

// https://github.com/moby/moby/blob/v26.1.4/distribution/pull_v2.go#L1070C1-L1072C2
func createDownloadFile() (*os.File, error) {
return os.CreateTemp("", "GetImageBlob")
}

os.CreateTemp 默认是在 /tmp/ 下创建临时文件的，但是实际目录是拼接了，应该有地方设置了 tmp 相关 env，先从 proc 看下：

$ ps -ef | grep docker[d]
root     23938     1  3 03:00 ?        00:19:00 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock

$ xargs -0 -n1 < /proc/23938/environ 
LANG=en_US.UTF-8
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin
NOTIFY_SOCKET=/run/systemd/notify
LISTEN_PID=23938
LISTEN_FDS=1

从 proc 进程能确认启动的没有 TMPDIR 相关 env，那么只有进程自己 os.Setenv 了，搜 TMPDIR 搜到相关逻辑：

// https://github.com/moby/moby/blob/v26.1.4/daemon/daemon.go#L841-L856
// set up the tmpDir to use a canonical path
tmp, err := prepareTempDir(config.Root)
if err != nil {
return nil, fmt.Errorf("Unable to get the TempDir under %s: %s", config.Root, err)
}
realTmp, err := fileutils.ReadSymlinkedDirectory(tmp)
if err != nil {
return nil, fmt.Errorf("Unable to get the full path to the TempDir (%s): %s", tmp, err)
}
if isWindows {
        ...
} else {
os.Setenv("TMPDIR", realTmp)
}

路径拼接逻辑确认了，要确认 err 哪里抛出的，搜上面的 createDownloadFile 找到：

// https://github.com/moby/moby/blob/v26.1.4/distribution/pull_v2.go#L169-L199
func (ld *layerDescriptor) Download(ctx context.Context, progressOutput progress.Output) (io.ReadCloser, int64, error) {
log.G(ctx).Debugf("pulling blob %q", ld.digest)

var (
err    error
offset int64
)

if ld.tmpFile == nil {
ld.tmpFile, err = createDownloadFile()
if err != nil {
return nil, 0, xfer.DoNotRetry{Err: err}
}
} else {
offset, err = ld.tmpFile.Seek(0, io.SeekEnd)
if err != nil {
log.G(ctx).Debugf("error seeking to end of download file: %v", err)
offset = 0

ld.tmpFile.Close()
if err := os.Remove(ld.tmpFile.Name()); err != nil {
log.G(ctx).Errorf("Failed to remove temp file: %s", ld.tmpFile.Name())
}
ld.tmpFile, err = createDownloadFile()
if err != nil {
return nil, 0, xfer.DoNotRetry{Err: err}
}
} else if offset != 0 {
log.G(ctx).Debugf("attempting to resume download of %q from %d bytes", ld.digest, offset)
}
}

err 是这附近抛出的，具体位置不知道，但是看有日志打印，需要查看下 docker daemon 日志确认下：

1
2

Nov 06 10:30:22 centos-xx dockerd[23938]: time="2025-11-06T10:30:22.290434484+08:00" level=error msg="Download failed after 1 attempts: open /work/docker/tmp/GetImageBlob1655640392: no such file or directory"
Nov 06 10:48:51 centos-xx dockerd[23938]: time="2025-11-06T10:48:51.619866730+08:00" level=error msg="Download failed after 1 attempts: open /work/docker/tmp/GetImageBlob1626967315: no such file or directory"

搜 Download failed after 搜到：

// https://github.com/moby/moby/blob/v26.1.4/distribution/xfer/download.go#L274-L293
for {
downloadReader, size, err = descriptor.Download(d.transfer.context(), progressOutput)
if err == nil {
break
}

// If an error was returned because the context
// was cancelled, we shouldn't retry.
select {
case <-d.transfer.context().Done():
d.err = err
return
default:
}

if _, isDNR := err.(DoNotRetry); isDNR || attempt >= ldm.maxDownloadAttempts {
log.G(context.TODO()).Errorf("Download failed after %d attempts: %v", attempt, err)
d.err = err
return
}

那确认 err 是上面的 download 里 return 的，从 daemon 的日志来看，该 err 没有经过 errors.Wrap 类似添加额外信息，应该就是 createDownloadFile() 抛出的 syscall 层面 error。

想着 golang 写一个 demo 复现，但是想着 mktmp 这个不也是很常见的行为吗，shell 就自带 mktemp 相关命令，复现下看看：

$ mktemp /work/docker/tmp/test1111
mktemp: too few X's in template ‘/work/docker/tmp/test1111’
$ mktemp /work/docker/tmp/testXXXX
mktemp: failed to create file via template ‘/work/docker/tmp/testXXXX’: No such file or directory
$ mktemp /tmp/testXXX
/tmp/testx1T

work 目录挂载的，测试了下读写也没问题，然后发现了 docker data-root 没有 tmp 目录：

$ touch /work/docker/test1111
$ rm -f /work/docker/test1111
$ ls -l /work/docker/
total 4
drwx--x--x 4 root root 170 Nov  6 03:00 buildkit
drwx--x--- 2 root root  10 Nov  6 03:00 containers
-rw------- 1 root root  36 Nov  6 03:00 engine-id
drwx------ 3 root root  30 Nov  6 03:00 image
drwxr-x--- 3 root root  27 Nov  6 03:00 network
drwx--x--- 3 root root  52 Nov  6 03:00 overlay2
drwx------ 4 root root  44 Nov  6 03:00 plugins
drwx------ 2 root root  10 Nov  6 03:00 swarm
drwx-----x 2 root root  62 Nov  6 03:00 volumes

然后创建该目录后就好了：

$ docker pull harbor.xxx.cn/xxxx-run/gosu:v1
v1: Pulling from xxxx-run/gosu
e9abf7e9593f: Pulling fs layer 
open /work/docker/tmp/GetImageBlob1426925393: no such file or directory
$ mkdir -p /work/docker/tmp
$ docker pull harbor.xxx.cn/xxxx-run/gosu:v1
v1: Pulling from xxxx-run/gosu
e9abf7e9593f: Pull complete 
Digest: sha256:06ff9bb691ce53498f7dda976e0028639fb320f71513f6a41b4dd6761e989e78
Status: Downloaded newer image for harbor.xxx.cn/xxxx-run/gosu:v1
harbor.xxx.cn/xxxx-run/gosu:v1

根因

原本想启动 docker 后创建下目录：

# .d 目录的话，即使后续 docker 更新也不会删掉下面文件，能持久化住逻辑
mkdir -p /etc/systemd/system/docker.service.d/
cat > /etc/systemd/system/docker.service.d/tmp.conf << EOF
[Service]
ExecStartPost=/usr/bin/mkdir /work/docker/tmp
EOF

systemctl daemon-reload

但是想了下，别人重启 docker 能解决说明 docker daemon 启动是会创建这个目录的，搜了下确认有如此逻辑：

// https://github.com/moby/moby/blob/v26.1.4/daemon/daemon.go#L1420-L1442

// prepareTempDir prepares and returns the default directory to use
// for temporary files.
// If it doesn't exist, it is created. If it exists, its content is removed.
func prepareTempDir(rootDir string) (string, error) {
var tmpDir string
if tmpDir = os.Getenv("DOCKER_TMPDIR"); tmpDir == "" {
tmpDir = filepath.Join(rootDir, "tmp")
newName := tmpDir + "-old"
if err := os.Rename(tmpDir, newName); err == nil {
go func() {
if err := os.RemoveAll(newName); err != nil {
log.G(context.TODO()).Warnf("failed to delete old tmp directory: %s", newName)
}
}()
} else if !os.IsNotExist(err) {
log.G(context.TODO()).Warnf("failed to rename %s for background deletion: %s. Deleting synchronously", tmpDir, err)
if err := os.RemoveAll(tmpDir); err != nil {
log.G(context.TODO()).Warnf("failed to delete old tmp directory: %s", tmpDir)
}
}
}
return tmpDir, idtools.MkdirAllAndChown(tmpDir, 0o700, idtools.CurrentIdentity())
}

那就是说外部行为删除了 tmp 目录导致，查看定时任务：

$ crontab -l
0 3 * * *  systemctl stop docker && mv /work/docker /work/docker-$(date +\%Y\%m\%d) && systemctl start docker
15 3 * * * rm -rf /work/docker-*
20 3 * * * find /work -maxdepth 1 -name '*dev*' -type d -ctime +1 | xargs rm -rf
23 3 * * * find /work -maxdepth 1 -name '*test*' -type d -ctime +1 | xargs rm -rf
25 3 * * * find /work -maxdepth 1 -name '*release*' -type d -ctime +1 | xargs rm -rf
27 3 * * * find /work -maxdepth 1 -name '*openxxx*' -type d -ctime +1 | xargs rm -rf
0 9-23/2 * * * python /data/epy/clean_dir.py  /work
#0 9-23/2  * * *  docker system prune -f
0 */2 * * * echo 3 > /proc/sys/vm/drop_caches

*/30 * * * * python /data/prepullimage/pull_image.py

根据 04:33 附近时间看没有，询问了下同事发现 jenkins 有定时 04:30 清理机器上的文件，调整后解决

多线程执行skopeo copy panic的一次解决过程

2025-10-31T17:30:30.000Z

多线程执行skopeo copy panic的一次解决过程

由来

内部构建出包存在大概以下逻辑：

起一个 registry 容器，假设随机端口为 45678
然后把相关镜像 skopeo copy 从缓存的 harbor 同步到 registry容器
打包registry的目录成为 iamge-xxx.tgz

然后发现这几天打包有问题，多线程 skopeo copy 报错没处理，最后 iamge-xxx.tgz 大小不对。

排查

调用链分析

查看出包日志一堆panic，由于多线程调用的，golang 的 panic 堆栈的顺序都错乱了，构建机器都是 centos7，都不维护了，上面的 skopeo 通过包管理安装的，版本比较低：

1 2	$ skopeo --version skopeo version 0.1.40

根据版本去查看源码找调用链，skopeo 使用了 cobra 库，从 cmd/skopeo/copy.go 找到堆栈：

1	/builddir/build/BUILD/skopeo-be6146b0a8471b02e776134119a2c37dfb70d414/cmd/skopeo/copy.go:159 +0x94b fp=0xc0005f3920 sp=0xc0005f3678 pc=0x559635b91b0b

代码：

import (
    "github.com/containers/image/v5/copy"
    ....
)

// https://github.com/containers/skopeo/blob/v0.1.40/cmd/skopeo/copy.go#L159-L167
    _, err = copy.Image(ctx, policyContext, destRef, srcRef, &copy.Options{
        RemoveSignatures:      opts.removeSignatures,
        SignBy:                opts.signByFingerprint,
        ReportWriter:          stdout,
        SourceCtx:             sourceCtx,
        DestinationCtx:        destinationCtx,
        ForceManifestMIMEType: manifestType,
        ImageListSelection:    imageListSelection,
    })

根据导包找到：

1
2

// https://github.com/containers/skopeo/blob/v0.1.40/vendor/github.com/containers/image/v5/copy/copy.go#L173
func Image(ctx context.Context, policyContext *signature.PolicyContext, destRef, srcRef types.ImageReference, options *Options) (copiedManifest []byte, retErr error) {

便于查找，给所有堆栈字符串保存到文件里，从输出混乱的堆栈字符串里搜索 copy/copy.go: 找到:

$ grep -Po 'vendor.*?/copy/copy.go:\d+' txt | sort -u
vendor/src/github.com/containers/image/v5/copy/copy.go:1337
vendor/src/github.com/containers/image/v5/copy/copy.go:258
vendor/src/github.com/containers/image/v5/copy/copy.go:578
vendor/src/github.com/containers/image/v5/copy/copy.go:740
vendor/src/github.com/containers/image/v5/copy/copy.go:755
vendor/src/github.com/containers/image/v5/copy/copy.go:765
vendor/src/github.com/containers/image/v5/copy/copy.go:766
vendor/src/github.com/containers/image/v5/copy/copy.go:770
vendor/src/github.com/containers/image/v5/copy/copy.go:771
vendor/src/github.com/containers/image/v5/copy/copy.go:860
vendor/src/github.com/containers/image/v5/copy/copy.go:948
vendor/src/github.com/containers/image/v5/copy/copy.go:949
vendor/src/github.com/containers/image/v5/pkg/blobinfocache/boltdb/boltdb.go0x105/builddir/build/BUILD/skopeo-be6146b0a8471b02e776134119a2c37dfb70d414/vendor/src/github.com/containers/image/v5/copy/copy.go:174

根据上面信息和源码，调用链为：

copy/copy.go#L173 的 func Image(ctx context.Context,
copy/copy.go#L258 的 if copiedManifest, _, _, err = c.copyOneImage(
copy/copy.go#L473 的 func (c *copier) copyOneImage
copy/copy.go#L578 的 if err := ic.copyLayers(ctx);
copy/copy.go#L704 的 func (ic *imageCopier) copyLayers(ctx context.Context)
copy/copy.go:766 的 go copyLayerHelper(i, srcLayer, progressPool)，而该方法是下面闭包声明的
copy/copy.go:755 的 cld.destInfo, cld.diffID, cld.err = ic.copyLayer(ctx, srcLayer, pool)
copy/copy.go:948 的 func (ic *imageCopier) copyLayer(ctx，然后走到内部第一行
copy/copy.go:949 的 cachedDiffID := ic.c.blobInfoCache.UncompressedDigest(srcInfo.Digest)

而方法 UncompressedDigest 是接口：

// https://github.com/containers/skopeo/blob/v0.1.40/vendor/github.com/containers/image/v5/types/types.go#L177-L198
type BlobInfoCache interface {

    UncompressedDigest(anyDigest digest.Digest) digest.Digest

    RecordDigestUncompressedPair(anyDigest digest.Digest, uncompressed digest.Digest)
    RecordKnownLocation(transport ImageTransport, scope BICTransportScope, digest digest.Digest, location BICLocationReference)
    CandidateLocations(transport ImageTransport, scope BICTransportScope, digest digest.Digest, canSubstitute bool) []BICReplacementCandidate
}

搜 ic.c.blobInfoCache 里的 blobInfoCache 赋值，搜到：

1 2	// https://github.com/containers/skopeo/blob/v0.1.40/vendor/github.com/containers/image/v5/copy/copy.go#L173-L233 blobInfoCache: blobinfocache.DefaultCache(options.DestinationCtx)

然后发现是 boltdb 存储 cache：

// https://github.com/containers/skopeo/blob/v0.1.40/vendor/github.com/containers/image/v5/pkg/blobinfocache/default.go
func DefaultCache(sys *types.SystemContext) types.BlobInfoCache {
    dir, err := blobInfoCacheDir(sys, getRootlessUID())
    if err != nil {
        logrus.Debugf("Error determining a location for %s, using a memory-only cache", blobInfoCacheFilename)
        return memory.New()
    }
    path := filepath.Join(dir, blobInfoCacheFilename)
    if err := os.MkdirAll(dir, 0700); err != nil {
        logrus.Debugf("Error creating parent directories for %s, using a memory-only cache: %v", blobInfoCacheFilename, err)
        return memory.New()
    }

    logrus.Debugf("Using blob info cache at %s", path)
    return boltdb.New(path)
}

查看失败构建的构建机器上：

$ cd /var/lib/containers/cache
$ ls -l
total 25740
-rw------- 1 root root 43134976 Oct 28 12:31 blob-info-cache-v1.boltdb
$ ls -al
total 25740
drwx------ 2 root root       39 Aug 27 14:18 .
drwxr-xr-x 4 root root       35 Aug 27 14:18 ..
-rw------- 1 root root 43134976 Oct 28 12:31 blob-info-cache-v1.boltdb

和堆栈里的 boltdb 相关堆栈也对的上：

$ grep -Po 'blobinfocache/boltdb/boltdb.go:\d+' txt  | sort -u
blobinfocache/boltdb/boltdb.go:108
blobinfocache/boltdb/boltdb.go:112
blobinfocache/boltdb/boltdb.go:114
blobinfocache/boltdb/boltdb.go:119
blobinfocache/boltdb/boltdb.go:124
blobinfocache/boltdb/boltdb.go:146
blobinfocache/boltdb/boltdb.go:172
blobinfocache/boltdb/boltdb.go:174
blobinfocache/boltdb/boltdb.go:175
blobinfocache/boltdb/boltdb.go:3010
blobinfocache/boltdb/boltdb.go:54
blobinfocache/boltdb/boltdb.go:56
blobinfocache/boltdb/boltdb.go:58
blobinfocache/boltdb/boltdb.go:65
blobinfocache/boltdb/boltdb.go:66
blobinfocache/boltdb/boltdb.go:67
blobinfocache/boltdb/boltdb.go:84

这里调用链就不细致分析了，确定是 uncompressedDigest 方法里 boltdb 问题：

1
2
3

// https://github.com/containers/skopeo/blob/v0.1.40/vendor/github.com/containers/image/v5/pkg/blobinfocache/boltdb/boltdb.go#L145C1-L146C57
func (bdc *cache) uncompressedDigest(tx *bolt.Tx, anyDigest digest.Digest) digest.Digest {
    if b := tx.Bucket(uncompressedDigestBucket); b != nil {

这里有问题的话就说明 boltdb 文件损坏，boltdb 文件损坏的话，docker 和 etcd 都能遇到，搜关键字就知道了：

1 2	$ grep invalid txt panic: invalid page type: 6432: 10

原因

写个 boltdb 查看 Bucket 的 cli 复现下：

package main

import (
    "fmt"
    "log"
    "os"

    bolt "go.etcd.io/bbolt"
)

func main() {
    if len(os.Args) < 2 {
        fmt.Fprintf(os.Stderr, "Usage: %s \n", os.Args[0])
        os.Exit(1)
    }
    filename := os.Args[1]

    db, err := bolt.Open(filename, 0600, &bolt.Options{ReadOnly: true})
    if err != nil {
        log.Fatalf("failed to open %s: %v", filename, err)
    }
    defer db.Close()

    err = db.View(func(tx *bolt.Tx) error {
        fmt.Printf("Top-level buckets in %s:\n", filename)
        return tx.ForEach(func(name []byte, _ *bolt.Bucket) error {
            fmt.Printf("- %s\n", name)
            return nil
        })
    })
    if err != nil {
        log.Fatal(err)
    }
}

拷贝到构建机器上执行：

$ ./bbolt-tool blob-info-cache-v1.boltdb
Top-level buckets in blob-info-cache-v1.boltdb:
panic: invalid page type: 6432: 10

goroutine 1 [running]:
go.etcd.io/bbolt.(*Cursor).search(0xc0000a5cd8, {0x7ff6b8ff8130, 0x47, 0x47}, 0x0?)
        /root/go/pkg/mod/go.etcd.io/bbolt@v1.4.3/cursor.go:286 +0x279
go.etcd.io/bbolt.(*Cursor).seek(0xc0000a5cd8, {0x7ff6b8ff8130?, 0xc000080140?, 0xc0000ac040?})
        /root/go/pkg/mod/go.etcd.io/bbolt@v1.4.3/cursor.go:162 +0x2e
go.etcd.io/bbolt.(*Bucket).Bucket(0xc0000aa018, {0x7ff6b8ff8130, 0x47, 0x4e8c40?})
        /root/go/pkg/mod/go.etcd.io/bbolt@v1.4.3/bucket.go:97 +0xb6
main.main.func1.(*Tx).ForEach.2({0x7ff6b8ff8130, 0x47, 0x47}, {0xc0000a5dd8?, 0x1?, 0x1?})
        /root/go/pkg/mod/go.etcd.io/bbolt@v1.4.3/tx.go:158 +0x45
go.etcd.io/bbolt.(*Bucket).ForEach(0x51c268?, 0xc0000a5de8)
        /root/go/pkg/mod/go.etcd.io/bbolt@v1.4.3/bucket.go:591 +0x89
go.etcd.io/bbolt.(*Tx).ForEach(...)
        /root/go/pkg/mod/go.etcd.io/bbolt@v1.4.3/tx.go:157
main.main.func1(0xc0000aa000)
        /root/code/golang/bbolt/main.go:26 +0x9d
go.etcd.io/bbolt.(*DB).View(0x7ffca6c567a8?, 0xc0000a5f00)
        /root/go/pkg/mod/go.etcd.io/bbolt@v1.4.3/db.go:939 +0x6c
main.main()
        /root/code/golang/bbolt/main.go:24 +0x1f0

正常构建机器上：

1
2
3

$ ./bbolt-tool blob-info-cache-v1.boltdb 
Top-level buckets in blob-info-cache-v1.boltdb:
- knownLocations

解决

根据上面方法 DefaultCache 可以把 path 创建成文件，让走内存缓存，但是查看了下新版本 skopeo 已经默认使用 sqlite 缓存了：

// If the format changes in an incompatible way, increase the version number.
blobInfoCacheFilename = "blob-info-cache-v1.sqlite"
// systemBlobInfoCacheDir is the directory containing the blob info cache (in blobInfocacheFilename) for root-running processes.
systemBlobInfoCacheDir = "/var/lib/containers/cache"

改为使用新版本 skopeo ，以及相关多线程的输出也加了前缀，避免下次类似问题堆栈混乱。然后发现老版本分支还是会走老逻辑，构建机器上把这个 boltdb 文件 mv 下避免影响其他分支，

离线安装docker和包管理安装docker下containerd的启动相关

2025-10-23T17:10:30.000Z

简单科普下 docker 启动时候和 contaienrd 相关

由来

昨天处理了一个现场 docker 起不来的问题，借着处理过程科普下。docker 无法启动日志：

$ journarlctl -xe --no-pager -u docker
Oct 23 17:28:33 XXX251023S00P systemd[1]: docker.service: Unit entered failed state.
Oct 23 17:28:33 XXX251023S00P systemd[1]: docker.service: Failed with result 'exit-code'.
Oct 23 17:28:43 XXX251023S00P systemd[1]: docker.service: Service RestartSec=10s expired, scheduling restart.
Oct 23 17:28:43 XXX251023S00P systemd[1]: Stopped Docker Application Container Engine.
-- Subject: Unit docker.service has finished shutting down
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit docker.service has finished shutting down.
Oct 23 17:28:43 XXX251023S00P systemd[1]: Starting Docker Application Container Engine...
-- Subject: Unit docker.service has begun start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit docker.service has begun starting up.
Oct 23 17:28:43 XXX251023S00P dockerd[7355]: time="2025-10-23T17:28:43+08:00" level=info msg="SUSE:secrets :: enabled"
Oct 23 17:28:44 XXX251023S00P dockerd[7355]: time="2025-10-23T17:28:44.000689797+08:00" level=warning msg="The \"graph\" config file option is deprecated. Please use \"data-root\" instead."
Oct 23 17:28:44 XXX251023S00P dockerd[7355]: time="2025-10-23T17:28:44.064839553+08:00" level=warning msg="grpc: addrConn.createTransport failed to connect to {unix:///run/containerd/containerd.sock 0  }. Err :connection error: desc = \"transport: Error while dialing dial unix /run/containerd/containerd.sock: connect: connection refused\". Reconnecting..." module=grpc
Oct 23 17:28:45 XXX251023S00P dockerd[7355]: time="2025-10-23T17:28:45.065163178+08:00" level=warning msg="grpc: addrConn.createTransport failed to connect to {unix:///run/containerd/containerd.sock 0  }. Err :connection error: desc = \"transport: Error while dialing dial unix /run/containerd/containerd.sock: connect: connection refused\". Reconnecting..." module=grpc

排查

上面日志右边滑动查看，核心报错是 Error while dialing dial unix /run/containerd/containerd.sock: connect: connection refused ，解决这个问题要先了解下 docker 和 containerd 启动相关。

包管理下的 docker 和 containerd

docker damon 和 containerd 是存在交互而工作的，如果是包管理安装的 docker，会有两个 systemd service 文件：

containerd 包提供 containerd.service 文件
docker-ce 的 docker.service

这里以 rpm 包举例：

$ rpm -qa | grep -P 'containerd'
containerd.io-1.6.33-3.1.el7.x86_64
$ rpm -ql containerd.io | grep -Ev '/(doc|licen|man)'
/etc/containerd
/etc/containerd/config.toml
/usr/bin/containerd
/usr/bin/containerd-shim
/usr/bin/containerd-shim-runc-v1
/usr/bin/containerd-shim-runc-v2
/usr/bin/ctr
/usr/bin/runc
/usr/lib/systemd/system/containerd.service

而包管理 docker.service 有依赖：

1
2
3

$ systemctl cat --no-pager  docker | grep containerd.service
After=network-online.target docker.socket firewalld.service containerd.service time-set.target
Wants=network-online.target containerd.service

二进制安装 docker

我们私有化就是 docker 离线安装的，根据官方文档 https://docs.docker.com/engine/install/binaries/ 下载二进制安装，但是官方文档没有说 systemd service 文件获取。以及我接手后发现也没有创建 containerd.service 纳管 containerd，但是 docker 也能运行，查看 docker 子进程能看到：

$ systemctl status docker
● docker.service - Docker Application Container Engine
   Loaded: loaded (/etc/systemd/system/docker.service; enabled; vendor preset: disabled)
   Active: active (running) since 三 2025-10-22 16:44:38 CST; 1 day 1h ago
     Docs: http://docs.docker.io
 Main PID: 16487 (dockerd)
    Tasks: 167
   Memory: 6.1G
   CGroup: /system.slice/docker.service
...
           ├─16506 containerd --config /var/run/docker/containerd/containerd.toml --log-level warn
...

说明 docker 肯定内部协程起了 containerd 进程，低版本 containerd 名字可能是 docker-containerd 。
逆向思维查下源码，因为协程起 containerd 进程，肯定会拼接 cmdline，源码搜索 --config 找到：

// https://github.com/moby/moby/blob/v19.03.15/libcontainerd/supervisor/remote_daemon.go#L165C1-L212C5
func (r *remote) startContainerd() error {
    pid, err := r.getContainerdPid()
    if err != nil {
        return err
    }

    if pid != -1 {
        r.daemonPid = pid
        logrus.WithField("pid", pid).
            Infof("libcontainerd: %s is still running", binaryName)
        return nil
    }

    configFile, err := r.getContainerdConfig()
    if err != nil {
        return err
    }

    args := []string{"--config", configFile}

    if r.Debug.Level != "" {
        args = append(args, "--log-level", r.Debug.Level)
    }

    cmd := exec.Command(binaryName, args...)
    // redirect containerd logs to docker logs
    cmd.Stdout = os.Stdout
    cmd.Stderr = os.Stderr
    cmd.SysProcAttr = containerdSysProcAttr()
    // clear the NOTIFY_SOCKET from the env when starting containerd
    cmd.Env = nil
    for _, e := range os.Environ() {
        if !strings.HasPrefix(e, "NOTIFY_SOCKET") {
            cmd.Env = append(cmd.Env, e)
        }
    }
    if err := cmd.Start(); err != nil {
        return err
    }

    r.daemonWaitCh = make(chan struct{})
    go func() {
        // Reap our child when needed
        if err := cmd.Wait(); err != nil {
            r.logger.WithError(err).Errorf("containerd did not exit successfully")
        }
        close(r.daemonWaitCh)
    }()

然后反向找 startContainerd() 的调用链：

同文件的 func (r *remote) monitorDaemon(ctx context.Context) {
同文件的 func Start(
因为 Start 方法大写，肯定在其他地方包导入，搜 supervisor.Start 找到

// https://github.com/moby/moby/blob/v19.03.15/cmd/dockerd/daemon_unix.go#L152C1-L171
func (cli *DaemonCli) initContainerD(ctx context.Context) (func(time.Duration) error, error) {
    var waitForShutdown func(time.Duration) error
    if cli.Config.ContainerdAddr == "" {
        systemContainerdAddr, ok, err := systemContainerdRunning(honorXDG)
        if err != nil {
            return nil, errors.Wrap(err, "could not determine whether the system containerd is running")
        }
        if !ok {
            logrus.Debug("Containerd not running, starting daemon managed containerd")
        opts, err := cli.getContainerdDaemonOpts()
        if err != nil {
          return nil, errors.Wrap(err, "failed to generate containerd options")
        }

        r, err := supervisor.Start(ctx, filepath.Join(cli.Config.Root, "containerd"), filepath.Join(cli.Config.ExecRoot, "containerd"), opts...)
        if err != nil {
          return nil, errors.Wrap(err, "failed to start containerd")
        }
        logrus.Debug("Started daemon managed containerd")
        cli.Config.ContainerdAddr = r.Address()

上面代码逻辑就是 systemContainerdRunning 方法判断 containerd 是否运行，没有运行就调用 supervisor.Start 启动 containerd，查看 systemContainerdRunning 内部实现：

// https://github.com/moby/moby/blob/v19.03.15/cmd/dockerd/daemon.go#L691C1-L702C2
func systemContainerdRunning(honorXDG bool) (string, bool, error) {
    addr := containerddefaults.DefaultAddress
    if honorXDG {
        runtimeDir, err := homedir.GetRuntimeDir()
        if err != nil {
            return "", false, err
        }
        addr = filepath.Join(runtimeDir, "containerd", "containerd.sock")
    }
    _, err := os.Lstat(addr)
    return addr, err == nil, nil
}

是查看连接 containerd 的 grpc sock 文件 /run/containerd/containerd.sock 存在否判断是否运行的，也就是说如果 systemd 启动了 containerd，docker daemon 就不 supervisor.Start 启动 containerd 子进程。

现场的是 suse docker rpm 包安装的，有 containerd 的 rpm 包，才发现里面没 service 文件，也就是走源码子进程逻辑：

$ rpm -ql containerd
/etc/containerd
/etc/containerd/config.toml/usr/sbin/containerd
/usr/sbin/containerd-shim
/usr/sbin/docker-containerd
/usr/sbin/docker-containerd-shim
/usr/share/doc/packages/containerd
/usr/share/doc/packages/containerd/README
/usr/share/licenses/containerd
/usr/share/licenses/containerd/LICENSE

查看果然是有 sock 文件而没 containerd 进程：

$ ls -l /run/containerd/
total 28
srw-rw---- 1 root root     0 Oct 23 15:20 containerd.sock
-rwxr-xr-x 1 root root 25651 Oct 23 15:26 events.log
$ ps -ef | grep container[d]

删掉该文件后重起 docker 解决。

keepalived Locking pid file error 22 - Invalid argument

2025-10-17T18:10:30.000Z

由来

现场部署业务后发现访问有问题，排查后发现业务网关访问 etcd 的 keepalived IPVS svc 不通

排查

基础排查

1 2	$ curl 169.254.20.4:12379 curl: (7) Failed to connect to 169.254.20.4 port 12379: Connection refused

这个是我们 etcd 的 svc 的，curl real server 正常：

1	$ curl <本机IP>:12379

然后看了下 iptables -t filter -S 无额外规则，怕客户安全加固啥的前面 insert 了规则影响。

1
2
3

$ sysctl --all |& grep vs.conn
net.ipv4.vs.conn_reuse_mode = 1
net.ipv4.vs.conntrack = 1

vs.conntrack 正常，不是 0，查看下 ipvs 规则：

1	$ docker exec keepalived-ipvs ipvsadm -ln \| grep -A3 169.254.20.4

现场说为空，让去掉 grep 直接看也是为空：

$ docker exec keepalived-ipvs ipvsadm -ln
IP Virtual Server version 1.2.1 (size=4096)
Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn

让看下 keepalived 日志，发现有个错误：

daemon is already running
Locking pid file /run/keepalived.pid error 22 - Invalid argument
Opening file '/etc/keepalived/conf.d/xxx.conf'.
Opening file '/etc/keepalived/conf.d/xxx2.conf'.
...

源码

因为 keepalived 容器需要操作 lvs 规则，所以是有 privileged: true 的，感觉还是内核相关问题导致的，那就看源码了。我们用的 keepalived 版本是最新的 v2.3.4 ，搜索源码 Locking pid file 搜到：

// https://github.com/acassen/keepalived/blob/v2.3.4/keepalived/core/pidfile.c#L183-L194
#if HAVE_DECL_F_OFD_SETLK == 1
    fl.l_pid = 0;
    while ((ret = fcntl(pidf->fd, F_OFD_SETLK, &fl)) && errno == EINTR);
    if (ret) {
      if (errno == EAGAIN)
        log_message(LOG_INFO, "Another process has pid file %s locked", pidf->path);
      else
        log_message(LOG_INFO, "Locking pid file %s error %d - %m", pidf->path, errno);

      break;
    }
#endif

看这个宏定义内的代码就是 fcntl 使用 F_OFD_SETLK 针对 Pid 文件上锁，这个特性是内核特性，现场是 CentOS 7.4 ，内核版本 3.10.0-693.el7.x86_64，想看下这块提交，于是下载源码后找到下面俩个 commmit：

第一个 commit 是增加 Pid 锁，第二个是允许宏定义不用这个特性在老系统上构建，利用 autoconf 检测支持 F_OFD_SETLK 不。

编译

因为我们使用的是容器化部署，基础镜像换成欧拉了，而欧拉的包管理安装的 keepalived 版本太低，所以我是 Dockerfile 内编译安装的 keepalived，而构建这个镜像的机器的内核比较高，只能构建的时候传递选项关闭了。

影响面也不需要关注，因为是容器，并且镜像的启动脚本内我在启动的时候先删除 pid 文件的，无脑编译关闭即可，不要 hack 修改代码，autoconf 啥的都是大家遵守的规范，主要是 configure.ac 下面的：

dnl -- Linux 3.15
AC_CHECK_DECLS([F_OFD_SETLK], [], [],
  [[
    #include 
    #include 
  ]])
for flag in F_OFD_SETLK; do
  AS_VAR_COPY([decl_var], [ac_cv_have_decl_$flag])
  if test ${decl_var} = yes; then
    add_system_opt[${flag}]
  fi
done

看下面逻辑，"ac_cv_have_decl_"+"F_OFD_SETLK"="yes" ，在 ./configure 后面加就行：

...
    ./autogen.sh; \
    ./configure ac_cv_have_decl_F_OFD_SETLK=no \
        --disable-dynamic-linking \
        --prefix=/usr \
        --exec-prefix=/usr \
        --bindir=/usr/bin \
        --sbindir=/usr/sbin \
        --sysconfdir=/etc \
        --enable-nftables \
        --enable-regex \
        --disable-systemd \
        ; \

编译打包镜像后测试没问题。

从自己造轮子NodePort白名单到参考 calico 规则

2025-10-15T10:10:30.000Z

研究下 calico 如何实现 nodePort 白名单。

由来

由于我们做私有化，很多客户注重安全，需要有类似 NetworkPolicy 那样做白名单限制来源，而 calico 最小化部署的话下面配置：

apiVersion: operator.tigera.io/v1
kind: Installation
metadata:
  name: default
spec: # https://docs.tigera.io/calico/latest/reference/installation/api#installationspec
  calicoNetwork: # https://docs.tigera.io/calico/latest/reference/installation/api#caliconetworkspec
    ipPools:
    - name: default-ipv4-ippool
      blockSize: 24 # node 上分配到的 PodIP 的掩码，默认26，我喜欢改成24方便阅读
      cidr: 10.187.0.0/16
      encapsulation: VXLANCrossSubnet # https://docs.tigera.io/calico/latest/reference/installation/api#encapsulationtype
      natOutgoing: Enabled
      nodeSelector: all()
    nodeAddressAutodetectionV4: # https://docs.tigera.io/calico/latest/reference/installation/api#nodeaddressautodetection
      canReach: 223.5.5.5
  registry: m.daocloud.io/quay.io # https://docs.tigera.io/calico/latest/operations/image-options/alternate-registry
  flexVolumePath: None # 设置为None 不安装 CSI 相关
  kubeletVolumePluginPath: None
---
apiVersion: operator.tigera.io/v1
kind: APIServer
metadata:
  name: default
spec: {}

下都会部署很多组件：

$ kubectl -n calico-system get deploy
NAME                      READY   UP-TO-DATE   AVAILABLE   AGE
calico-kube-controllers   1/1     1            1           6d3h
calico-typha              1/1     1            1           6d3h
goldmane                  1/1     1            1           6d1h
whisker                   1/1     1            1           6d1h
$ kubectl -n calico-apiserver get deploy
NAME               READY   UP-TO-DATE   AVAILABLE   AGE
calico-apiserver   2/2     2            2           6d1h

而且很多客户机器配置不高，所以我们使用 flannel，而网络策略这块有实现一个 agent 容器做 iptables 规则白名单，非 K8S 下 docker 也可以用。某个版本开始有部分业务需要 NodePort 暴漏用于外部上传备份文件，但是考虑到客户安全要求，所以需要 NodePort 做白名单限制。
如果对 iptables 不熟悉，可能会下意识的去 INPUT 链去做，实际是不行的，NodePort 在 nat 表里 PREROUTING 先匹配做 nat 的，拿如下 svc 做说明：

Name:                     my-service
Namespace:                default
Labels:                   
Annotations:              
Selector:                 nodePort=test
Type:                     NodePort
IP Family Policy:         SingleStack
IP Families:              IPv4
IP:                       10.186.158.205
IPs:                      10.186.158.205
Port:                       80/TCP
TargetPort:               80/TCP
NodePort:                   30008/TCP
Endpoints:                10.187.220.19:80
Session Affinity:         None
External Traffic Policy:  Cluster
Events:

相关 nat 表下的 PRETOUTING 链如下：

# 入口
-A PREROUTING -m comment --comment "kubernetes service portals" -j KUBE-SERVICES
-A KUBE-SERVICES -m comment --comment "kubernetes service nodeports; NOTE: this must be the last rule in this chain" -m addrtype --dst-type LOCAL -j KUBE-NODEPORTS
-A KUBE-NODEPORTS -p tcp -m comment --comment "default/my-service" -m tcp --dport 30008 -j KUBE-EXT-FXIYY6OHUSNBITIX
# nodePort 匹配之前先打 snat mark，再是下面的 KUBE-SVC-FXIYY6OHUSNBITIX svc 的 dnat 链
-A KUBE-EXT-FXIYY6OHUSNBITIX -m comment --comment "masquerade traffic for default/my-service external destinations" -j KUBE-MARK-MASQ
-A KUBE-EXT-FXIYY6OHUSNBITIX -j KUBE-SVC-FXIYY6OHUSNBITIX

# svc 的 dnat 链
-A KUBE-SVC-FXIYY6OHUSNBITIX -d 10.186.158.205/32 -p tcp -m comment --comment "default/my-service cluster IP" -m tcp --dport 80 -j KUBE-MARK-MASQ
-A KUBE-SVC-FXIYY6OHUSNBITIX -m comment --comment "default/my-service -> 10.187.220.19:80" -j KUBE-SEP-DPGHCWFA3YQKRCGQ

# svc 的 endpoint 链
-A KUBE-SEP-DPGHCWFA3YQKRCGQ -s 10.187.220.19/32 -m comment --comment "default/my-service" -j KUBE-MARK-MASQ
-A KUBE-SEP-DPGHCWFA3YQKRCGQ -p tcp -m comment --comment "default/my-service" -m tcp -j DNAT --to-destination 10.187.220.19:80

等走到 INPUT 后，目标 IP 和 port 都经过了 dnat了，所以不能在 INPUT 拦截匹配，同理 docker -p 暴漏的端口也是一样。所以之前我是在 raw 表的 PREROUTING 里做的。

规则问题

设计的规则是一个 ipset 存白名单端口列表，一个是 ip 白名单，规则如下：

$ iptables -t raw -S PREROUTING
# 回程 conntrack 状态放行
-A PREROUTING -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
# 来源 IP 不是白名单 IP，但是目标端口是白名单端口就拒绝
-A PREROUTING -m set ! --match-set whiteiplist src -m set --match-set whiteportlist dst -j DROP

然后测了下发现没问题，后面时不时收到实施反馈客户现场环境上，服务作为客户端访问外部低概率超时，抓包发现本机上访问外部 server，server 回包被阻断：

本机上作为 client 访问外部，发送 SYN 包
外部 server 给本机发送 SYN-ACK 被阻断

根据 iptables 统计数据看：

$ iptables -t raw -nvL PREROUTING
Chain PREROUTING (policy ACCEPT)
 pkts bytes target     prot opt in     out     source               destination         
 162M   64G ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
 20   1604 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ! match-set whiteiplist src match-set whiteportlist dst

发现就是 raw 的这个规则匹配 DROP 的，排查发现，某个版本开始后，把白名单端口增加很多，例如 49100-49500 之类的（INPUT 链我们也在用 whiteportlist），在 ip_local_port_range 范围内，刚好客户端使用就会发生：

本机请求外部 server，分配的 local_port 是 whiteportlist 例如：49123
外部回包，此刻没有被 conntrack 标记为 ESTABLISHED 状态，走到下一条规则
然后命中下一条就被 DROP

使用 tcp 编程复现：

import socket

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.bind(('0.0.0.0', 49123))
s.connect(('39.156.70.37', 80))
s.send(b'GET / HTTP/1.1\r\nHost: www.baidu.com\r\n\r\n')
print(s.recv(1024))
s.close()

39.156.70.37 为百度域名 IP，执行后卡住，查看统计信息增加了也符合：

# 清空 PREROUTING 统计信息
$ iptables -t raw -Z PREROUTING
$ python test.py
^C
$ iptables -t raw -nvL PREROUTING

看来 raw 如字面意思，太原始了。

calico

研究下 calico 如何实现的，单机干净 K8S 集群上部署了 calico ，看了下 operator 安装的 calico 版本为：

1 2	$ docker images \| grep calico/node m.daocloud.io/quay.io/calico/node v3.30.3 ce9c4ac0f175 7 weeks ago 401MB

本文的规则研究以 v3.30.3 版本为准。

准备工作

先部署一个 NodePort：

apiVersion: v1
kind: Pod
metadata:
  namespace: default
  name: test-hostname
  labels:
    nodePort: test
spec:
  containers:
  - name: test
    image: m.daocloud.io/docker.io/library/nginx:alpine
---
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: NodePort
  selector:
    nodePort: test
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
      nodePort: 30008

相关信息存档，后续生效的策略对比：

iptables -w -t raw -S > raw
iptables -w -t nat -S > nat
iptables -w -t mangle -S > mangle
iptables -w -S > filter
ipset list > ipset

GlobalNetworkPolicy

谷歌搜到官方文档network-policy kubernetes-node-ports，使用的是 GlobalNetworkPolicy，看了下文档，calico 的这个 CRD 相对于 NetworkPolicy 范围更广，它可以控制主机层面，而非 NetworkPolicy 只控制 ns 和 Pod 策略，根据文档例子写了下：

apiVersion: projectcalico.org/v3
kind: GlobalNetworkPolicy
metadata:
  name: allow-cluster-nodeport-only
spec:
# 常规使用是配合兜底策略，优先级高的前面放行，优先级最低的是拒绝，也就是白名单策略。或者优先级最低的是放行，优先级高的是DROP，也就是黑名单策略
# 这里我是只测试，写出下面规则
  order: 20
  preDNAT: true
  applyOnForward: true
  ingress:
    - action: Allow
      source:
        nets:
         - 10.xxx.41.110/32 # 自身 IP
         - 10.xxx.195.118/32 # 外部测试 IP
         - 10.187.0.0/16 # Pod CIDR
    - action: Deny
      protocol: TCP
      destination:
        ports: [30008]
  selector: has(kubernetes.io/os)

apply 后发现 iptables 的所有表里都没有规则增加，官方文档说选择器可以选 node 的，但是实际测试不行，看官方文档其他地方有使用 kind: HostEndpoint 配合 selector ，设置下自动创建 hep 还是不行：

$ kubectl patch kubecontrollersconfigurations default \
  --type=merge -p '{"spec": {"controllers": {"node":{"hostEndpoint":{"autoCreate": "Enabled"}}}}}'
$ kubectl get hep -l kubernetes.io/os
NAME                     CREATED AT
10.xxx.xx.170-auto-hep   2025-10-15T09:18:37

看了下选择器文档，直接改成 selector: all() 后可以了，外部 IP 不在上面的白名单里 curl nodeport 不通

规则研究

导出现在规则：

iptables -w -t raw -S > raw2
iptables -w -t nat -S > nat2
iptables -w -t mangle -S > mangle2
iptables -w -S > filter2

新增规则

对比：

$ diff mangle*
10a11
> -N cali-failsafe-in
11a13
> -N cali-fh-any-interface-at-all
12a15
> -N cali-pi-_Ddz2TLFtYPs0Zt3iUZs
25a29,37
> -A cali-failsafe-in -p tcp -m comment --comment "cali:wWFQM43tJU7wwnFZ" -m multiport --dports 22 -j ACCEPT
> -A cali-failsafe-in -p udp -m comment --comment "cali:LwNV--R8MjeUYacw" -m multiport --dports 68 -j ACCEPT
> -A cali-failsafe-in -p tcp -m comment --comment "cali:QOO5NUOqOSS1_Iw0" -m multiport --dports 179 -j ACCEPT
> -A cali-failsafe-in -p tcp -m comment --comment "cali:cwZWoBSwVeIAZmVN" -m multiport --dports 2379 -j ACCEPT
> -A cali-failsafe-in -p tcp -m comment --comment "cali:7FbNXT91kugE_upR" -m multiport --dports 2380 -j ACCEPT
> -A cali-failsafe-in -p tcp -m comment --comment "cali:8Ftbkk2dRH2eEeq1" -m multiport --dports 5473 -j ACCEPT
> -A cali-failsafe-in -p tcp -m comment --comment "cali:-JoRSaAQZPJAegMo" -m multiport --dports 6443 -j ACCEPT
> -A cali-failsafe-in -p tcp -m comment --comment "cali:PUKij4Rn9njHfVTi" -m multiport --dports 6666 -j ACCEPT
> -A cali-failsafe-in -p tcp -m comment --comment "cali:vSprVE-4rient0wc" -m multiport --dports 6667 -j ACCEPT
34a47,64
> -A cali-fh-any-interface-at-all -m comment --comment "cali:CCbcqJXqEISzSqnH" -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
> -A cali-fh-any-interface-at-all -m comment --comment "cali:mmvu-cTJXJ7YH9Lp" -m conntrack --ctstate INVALID -j DROP
> -A cali-fh-any-interface-at-all -m comment --comment "cali:NnqjZhu9yccY4C7-" -j cali-failsafe-in
> -A cali-fh-any-interface-at-all -m comment --comment "cali:AtciE88iDfq0ah2L" -j MARK --set-xmark 0x0/0x30000
> -A cali-fh-any-interface-at-all -m comment --comment "cali:BZMMxJKaVi8hIM9r" -m comment --comment "Start of tier default" -j MARK --set-xmark 0x0/0x20000
> -A cali-fh-any-interface-at-all -m comment --comment "cali:_hnIU4TYdSt--CFh" -m mark --mark 0x0/0x20000 -j cali-pi-_Ddz2TLFtYPs0Zt3iUZs
> -A cali-fh-any-interface-at-all -m comment --comment "cali:-n3Ama1WlBcv-Yv9" -m comment --comment "Return if policy accepted" -m mark --mark 0x10000/0x10000 -j RETURN
> -A cali-from-host-endpoint -m comment --comment "cali:0MLuqUx2SPsTwgBS" -g cali-fh-any-interface-at-all
> -A cali-pi-_Ddz2TLFtYPs0Zt3iUZs -m comment --comment "cali:5eFTXO3b0B-Tbiq8" -m comment --comment "Policy default.allow-cluster-nodeport-only ingress" -j MARK --set-xmark 0x0/0x180000
> -A cali-pi-_Ddz2TLFtYPs0Zt3iUZs -s 10.xxx.41.110/32 -m comment --comment "cali:L5TwSbHWsELZIAEd" -j MARK --set-xmark 0x80000/0x80000
> -A cali-pi-_Ddz2TLFtYPs0Zt3iUZs -s 10.xxx.195.118/32 -m comment --comment "cali:noUEAlswvbgG5j7d" -j MARK --set-xmark 0x80000/0x80000
> -A cali-pi-_Ddz2TLFtYPs0Zt3iUZs -s 10.187.0.0/16 -m comment --comment "cali:TxEjJz-IsLiJzVDK" -j MARK --set-xmark 0x80000/0x80000
> -A cali-pi-_Ddz2TLFtYPs0Zt3iUZs -m comment --comment "cali:SBosizM5mtjxTsOe" -m mark --mark 0x80000/0x80000 -j MARK --set-xmark 0x10000/0x10000
> -A cali-pi-_Ddz2TLFtYPs0Zt3iUZs -m comment --comment "cali:5w4NEetZaXhF7wjm" -m mark --mark 0x10000/0x10000 -j NFLOG --nflog-prefix  "API0|default.allow-cluster-nodeport-only" --nflog-group 1 --nflog-range 80
> -A cali-pi-_Ddz2TLFtYPs0Zt3iUZs -m comment --comment "cali:NMym66CfdBVWGhc6" -m mark --mark 0x10000/0x10000 -j RETURN
> -A cali-pi-_Ddz2TLFtYPs0Zt3iUZs -p tcp -m comment --comment "cali:HONlGpSGnitWLUh-" -m multiport --dports 30008 -j MARK --set-xmark 0x40000/0x40000
> -A cali-pi-_Ddz2TLFtYPs0Zt3iUZs -m comment --comment "cali:9vcFh92OaOMP06xg" -m mark --mark 0x40000/0x40000 -j NFLOG --nflog-prefix  "DPI1|default.allow-cluster-nodeport-only" --nflog-group 1 --nflog-range 80
> -A cali-pi-_Ddz2TLFtYPs0Zt3iUZs -m comment --comment "cali:URAeOCUsDbThanFp" -m mark --mark 0x40000/0x40000 -j DROP

主要是多了三个链：

cali-failsafe-in
cali-fh-any-interface-at-all
cali-pi-_Ddz2TLFtYPs0Zt3iUZs

cali-failsafe-in 链如名字所示，兜底策略，先放行 ssh/etcd/kube-apiserver 之类端口，避免配置错误网络策略后导致机器集群无法连上，涉及到的端口见官方文档 failsafe，对于新增过滤规则的都会先跳到这个链。

后面俩链是具体 cali-pi-_Ddz2TLFtYPs0Zt3iUZs 里做处理：

1	> -A cali-fh-any-interface-at-all -m comment --comment "cali:_hnIU4TYdSt--CFh" -m mark --mark 0x0/0x20000 -j cali-pi-_Ddz2TLFtYPs0Zt3iUZs

来懒人办法，清理掉链的统计信息看生效在哪块：

$ iptables -t mangle -Z cali-pi-_Ddz2TLFtYPs0Zt3iUZs
$ iptables -t mangle -nvL cali-pi-_Ddz2TLFtYPs0Zt3iUZs
Chain cali-pi-_Ddz2TLFtYPs0Zt3iUZs (1 references)
 pkts bytes target     prot opt in     out     source               destination         
   10   600 MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* cali:5eFTXO3b0B-Tbiq8 */ /* Policy default.allow-cluster-nodeport-only ingress */ MARK and 0xffe7ffff
    0     0 MARK       all  --  *      *       10.xxx.41.110        0.0.0.0/0            /* cali:L5TwSbHWsELZIAEd */ MARK or 0x80000
    0     0 MARK       all  --  *      *       10.xxx.195.118       0.0.0.0/0            /* cali:noUEAlswvbgG5j7d */ MARK or 0x80000
    0     0 MARK       all  --  *      *       10.187.0.0/16        0.0.0.0/0            /* cali:TxEjJz-IsLiJzVDK */ MARK or 0x80000
    0     0 MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* cali:SBosizM5mtjxTsOe */ mark match 0x80000/0x80000 MARK or 0x10000
    0     0 NFLOG      all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* cali:5w4NEetZaXhF7wjm */ mark match 0x10000/0x10000 nflog-prefix  "API0|default.allow-cluster-nodeport-only" nflog-group 1 nflog-range 80
    0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* cali:NMym66CfdBVWGhc6 */ mark match 0x10000/0x10000
    0     0 MARK       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            /* cali:HONlGpSGnitWLUh- */ multiport dports 30008 MARK or 0x40000
    0     0 NFLOG      all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* cali:9vcFh92OaOMP06xg */ mark match 0x40000/0x40000 nflog-prefix  "DPI1|default.allow-cluster-nodeport-only" nflog-group 1 nflog-range 80
    0     0 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* cali:URAeOCUsDbThanFp */ mark match 0x40000/0x40000

然后外部的不在白名单里的 curl 下 NodePort，再看下统计信息：

$ iptables -t mangle -nvL cali-pi-_Ddz2TLFtYPs0Zt3iUZs
Chain cali-pi-_Ddz2TLFtYPs0Zt3iUZs (1 references)
 pkts bytes target     prot opt in     out     source               destination         
   44  2640 MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* cali:5eFTXO3b0B-Tbiq8 */ /* Policy default.allow-cluster-nodeport-only ingress */ MARK and 0xffe7ffff
    0     0 MARK       all  --  *      *       10.xxx.41.110        0.0.0.0/0            /* cali:L5TwSbHWsELZIAEd */ MARK or 0x80000
    0     0 MARK       all  --  *      *       10.xxx.195.118       0.0.0.0/0            /* cali:noUEAlswvbgG5j7d */ MARK or 0x80000
    0     0 MARK       all  --  *      *       10.187.0.0/16        0.0.0.0/0            /* cali:TxEjJz-IsLiJzVDK */ MARK or 0x80000
    0     0 MARK       all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* cali:SBosizM5mtjxTsOe */ mark match 0x80000/0x80000 MARK or 0x10000
    0     0 NFLOG      all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* cali:5w4NEetZaXhF7wjm */ mark match 0x10000/0x10000 nflog-prefix  "API0|default.allow-cluster-nodeport-only" nflog-group 1 nflog-range 80
    0     0 RETURN     all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* cali:NMym66CfdBVWGhc6 */ mark match 0x10000/0x10000
    2   120 MARK       tcp  --  *      *       0.0.0.0/0            0.0.0.0/0            /* cali:HONlGpSGnitWLUh- */ multiport dports 30008 MARK or 0x40000
    2   120 NFLOG      all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* cali:9vcFh92OaOMP06xg */ mark match 0x40000/0x40000 nflog-prefix  "DPI1|default.allow-cluster-nodeport-only" nflog-group 1 nflog-range 80
    2   120 DROP       all  --  *      *       0.0.0.0/0            0.0.0.0/0            /* cali:URAeOCUsDbThanFp */ mark match 0x40000/0x40000

其实就是用 mark 做条件 flag 匹配处理，主要看这几个规则就行：

> -A cali-pi-_Ddz2TLFtYPs0Zt3iUZs -m comment --comment "cali:5eFTXO3b0B-Tbiq8" -m comment --comment "Policy default.allow-cluster-nodeport-only ingress" -j MARK --set-xmark 0x0/0x180000
> -A cali-pi-_Ddz2TLFtYPs0Zt3iUZs -s 10.xxx.41.110/32 -m comment --comment "cali:L5TwSbHWsELZIAEd" -j MARK --set-xmark 0x80000/0x80000
> -A cali-pi-_Ddz2TLFtYPs0Zt3iUZs -s 10.xxx.195.118/32 -m comment --comment "cali:noUEAlswvbgG5j7d" -j MARK --set-xmark 0x80000/0x80000
> -A cali-pi-_Ddz2TLFtYPs0Zt3iUZs -s 10.187.0.0/16 -m comment --comment "cali:TxEjJz-IsLiJzVDK" -j MARK --set-xmark 0x80000/0x80000
> -A cali-pi-_Ddz2TLFtYPs0Zt3iUZs -m comment --comment "cali:SBosizM5mtjxTsOe" -m mark --mark 0x80000/0x80000 -j MARK --set-xmark 0x10000/0x10000
> -A cali-pi-_Ddz2TLFtYPs0Zt3iUZs -m comment --comment "cali:5w4NEetZaXhF7wjm" -m mark --mark 0x10000/0x10000 -j NFLOG --nflog-prefix  "API0|default.allow-cluster-nodeport-only" --nflog-group 1 --nflog-range 80
> -A cali-pi-_Ddz2TLFtYPs0Zt3iUZs -m comment --comment "cali:NMym66CfdBVWGhc6" -m mark --mark 0x10000/0x10000 -j RETURN
> -A cali-pi-_Ddz2TLFtYPs0Zt3iUZs -p tcp -m comment --comment "cali:HONlGpSGnitWLUh-" -m multiport --dports 30008 -j MARK --set-xmark 0x40000/0x40000
> -A cali-pi-_Ddz2TLFtYPs0Zt3iUZs -m comment --comment "cali:9vcFh92OaOMP06xg" -m mark --mark 0x40000/0x40000 -j NFLOG --nflog-prefix  "DPI1|default.allow-cluster-nodeport-only" --nflog-group 1 --nflog-range 80
> -A cali-pi-_Ddz2TLFtYPs0Zt3iUZs -m comment --comment "cali:URAeOCUsDbThanFp" -m mark --mark 0x40000/0x40000 -j DROP

白名单会打上 0x80000/0x80000 标记
-m mark --mark 0x80000/0x80000 -j MARK --set-xmark 0x10000/0x10000 匹配上 0x80000/0x80000 的打新 mark 0x10000/0x10000 ，这里按照二进制理解，两者都存在
--mark 0x10000/0x10000 -j NFLOG 匹配 0x10000/0x10000 的在 NFLOG 上记录，可以用 tcpdump -i nflog:1 抓包，配合前面一条也就是命中规则的才会 NFLOG
--mark 0x10000/0x10000 -j RETURN 白名单命中放行的此刻不往下走
-m multiport --dports 30008 -j MARK --set-xmark 0x40000/0x40000 访问的是 NodePort 打上标记
--mark 0x40000/0x40000 -j NFLOG 记录，再往下走
--mark 0x40000/0x40000 -j DROP 扔掉报文

mangle 的 PREROUTING

设计

一个 ipset 存储白名单 whiteiplist，匹配上就 ACCEPT
一个 ipset 存储 Port whiteportlist，此刻还匹配就说明不是白名单走过来，打 mark 2
匹配到 mark 2 则 DROP

如果有问题，可以某个地方再加一个规则打上 mark 1 来热修。

mangle 表

由于我们只使用 flannel，并且也不需要各种情况，所以就不用 mark 处理了，所以也只是像 calico 那样在 mangle 的 PRETOUTING 做链：

#先创建链
iptables --wait --table mangle --new test-PREROUTING

# 插入 mangle 表的 PREROUTING 链前面
iptables --wait --table mangle --insert PREROUTING --jump test-PREROUTING

# 放行已建立的连接
iptables --wait --table mangle --insert test-PREROUTING -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

# 创建单独的链
iptables --wait --table mangle --new test-from-host-endpoint

# 匹配行为在 test-from-host-endpoint 里做，有问题在它前面 INSERT 规则即可
iptables --wait --table mangle --append test-PREROUTING -j test-from-host-endpoint

test-from-host-endpoint 链

拆成两个是可以后续再 test-from-host-endpoint 前 insert 本机网卡 IP 或者可以添加类似 failsafe-in 之类的 ipset 之类的。

# 白名单 IP 直接放行
iptables --wait --table mangle --append test-from-host-endpoint -m set --match-set whiteiplist src -j ACCEPT

# 非白名单 ip 访问白名单端口拒绝
iptables --wait --table mangle --append test-from-host-endpoint -m set --match-set whiteportlist dst -j DROP

filter 表的 INPUT 链里我们也加了下类似 this-host 的逻辑：

-A INPUT -j BASE-RULE

-A BASE-RULE -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A BASE-RULE -m set --match-set whiteiplist src -j ACCEPT
-A BASE-RULE -m set --match-set this-host src -j ACCEPT
-A BASE-RULE -m set --match-set whiteportlist dst -j DROP

成品

支持双栈，支持获取网卡IP，ipv6 根据 ipv6list 和 cat /proc/sys/net/ipv6/conf/all/disable_ipv6 值做开关

Name: this-host
Type: hash:net
Revision: 6
Header: family inet hashsize 1024 maxelem 1000000
Size in memory: 568
References: 1
Number of entries: 3
Members:
127.0.0.0/24
10.xx.94.189
169.254.0.0/16

Name: whiteipv6list
Type: hash:net
Revision: 6
Header: family inet6 hashsize 1024 maxelem 1000000
Size in memory: 1608
References: 2
Number of entries: 4
Members:
2408:8656:22df:ff01::14:1620
2408:8656:22df:ff01::14:1621
::1
2408:8656:22df:ff01::14:1622

Name: this-host6
Type: hash:net
Revision: 6
Header: family inet6 hashsize 1024 maxelem 1000000
Size in memory: 1496
References: 1
Number of entries: 3
Members:
ee80:169:254:20::/64
2408:8656:22df:ff01::14:1620
::1

Name: whiteportlist
Type: bitmap:port
Revision: 3
Header: range 0-65535
Size in memory: 8296
References: 4
Number of entries: 230
Members:
...

一些仅供他人参考的 shell：

function get_if_inet(){
  local if=$1
  ip -4 -o a s $if | awk '{print $4}'
}

function this_host(){
  ipset create this-host hash:net maxelem 1000000 -exist
  ipset add this-host 127.0.0.1/24 -exist
  ipset add this-host 169.254.0.0/16 -exist

  if [ -d /sys/devices/virtual/net/cni0/ ];then
    ipset add this-host $(get_if_inet cni0| sed 's#/\d+#/16#') -exist
  fi

  ip -o -4 a s scope global | grep -Ev ':\s+(cali|tunl|vxlan|flannel|docker0|veth|wireguard|wg|cni0|kube|dummy|veth)' | awk -F'[ /]+' '{print $4}'| \
  while read ip;do
    ipset add this-host $ip -exist
  done

}

function get_if_inet6(){
  local if=$1 ignore=$2 inet6
  inet6=ip -6 -o a s $if | awk '{print $4}'
  if [ -n "$ignore" ];then
    inet6=$(echo $inet6 | grep -Ev "$2")
  fi
  echo $inet6
}

function this_host6(){
  ipset create this-host6 hash:net maxelem 1000000 family inet6 -exist
  ipset add this-host6 ::1 -exist

  if [ -d /sys/devices/virtual/net/cni0/ ];then
    cni0_inet6=$(get_if_inet6 cni0| sed 's#/\d+#/56#')
    if [ -n "$cni0_inet6" ];then
      ipset add this-host6 $cni0_inet6 -exist
    fi
  fi

  ip -o -6 a s scope global | grep -Ev ':\s+(cali|tunl|vxlan|flannel|docker0|veth|wireguard|wg|cni0|kube|dummy|veth)' |\
   grep -Ev '^fe80::.+/64' | awk -F'[ /]+' '{print $4}'| \
  while read ip;do
    ipset add this-host6 $ip -exist
  done

}

hostNetwork下hostname的坑

2025-10-13T10:10:30.000Z

最近升级和压测遇到的 hostNetwork 下 hostname 的坑问题

由来

性能压测团队压测后发现 kafka 的数据目录下有俩个很大的目录给机器目录占满：

1
2
3

total 88
drwxr-xr-x 568 nfsnobody nfsnobody 28672 Oct  1 17:42 kafka-logs-kafka-1
drwxr-xr-x 535 nfsnobody nfsnobody 28672 Sep 26 19:51 kafka-logs-vm10-7-131-94

大小问题

大小问题是因为 kafka 默认配置 log.retention.bytes = -1：

$  docker logs 2d21e7 |& grep -P '^\s+log\.retention'
log.retention.bytes = -1
log.retention.check.interval.ms = 150000
log.retention.hours = 168
log.retention.minutes = null
log.retention.ms = null

查看了下 kafka 的启动脚本，支持 env 配置，配置下 KAFKA_LOG_RETENTION_BYTES: "1073741824" 后测试没问题：

# 终端1写入topic
for i in {1..1000}; do head -c 102400000 /dev/urandom | base64 |kafka-console-producer.sh --bootstrap-server 127.0.0.1:9092  --topic test; done

# 终端2 观察
$ du -shx *; ls -lh test-0
0cleaner-offset-checkpoint
4.0Klog-start-offset-checkpoint
4.0Kmeta.properties
4.0Krecovery-point-offset-checkpoint
4.0Kreplication-offset-checkpoint
3.5Gtest-0
3.5Gtest-1
总用量 3.5G
-rwxr-xr-x 1 65534 65534 514K 10月 13 17:58 00000000000012487638.index.deleted
-rwxr-xr-x 1 65534 65534 1.0G 10月 13 17:58 00000000000012487638.log.deleted
-rwxr-xr-x 1 65534 65534 355K 10月 13 17:58 00000000000012487638.timeindex.deleted
-rwxr-xr-x 1 65534 65534 517K 10月 13 19:02 00000000000024975185.index
-rwxr-xr-x 1 65534 65534 1.0G 10月 13 19:02 00000000000024975185.log
-rwxr-xr-x 1 65534 65534 4.0K 10月 13 17:58 00000000000024975185.snapshot
-rwxr-xr-x 1 65534 65534 372K 10月 13 19:02 00000000000024975185.timeindex
-rwxr-xr-x 1 65534 65534 4.1K 10月 13 18:02 00000000000027453871.snapshot
-rw-r--r-- 1 65534 65534  10M 10月 13 19:02 00000000000037462545.index
-rw-r--r-- 1 65534 65534 430M 10月 13 19:02 00000000000037462545.log
-rw-r--r-- 1 65534 65534 4.6K 10月 13 19:02 00000000000037462545.snapshot
-rw-r--r-- 1 65534 65534  10M 10月 13 19:02 00000000000037462545.timeindex
-rw-r--r-- 1 65534 65534   15 10月 13 19:03 leader-epoch-checkpoint
-rwxr-xr-x 1 65534 65534   43 10月 13 17:33 partition.metadata
$ du -shx *; ls -lh test-0
0cleaner-offset-checkpoint
4.0Klog-start-offset-checkpoint
4.0Kmeta.properties
4.0Krecovery-point-offset-checkpoint
4.0Kreplication-offset-checkpoint
1.5Gtest-0
1.5Gtest-1
总用量 1.5G
-rwxr-xr-x 1 65534 65534 517K 10月 13 19:02 00000000000024975185.index
-rwxr-xr-x 1 65534 65534 1.0G 10月 13 19:02 00000000000024975185.log
-rwxr-xr-x 1 65534 65534 4.0K 10月 13 17:58 00000000000024975185.snapshot
-rwxr-xr-x 1 65534 65534 372K 10月 13 19:02 00000000000024975185.timeindex
-rwxr-xr-x 1 65534 65534 4.1K 10月 13 18:02 00000000000027453871.snapshot
-rw-r--r-- 1 65534 65534  10M 10月 13 19:02 00000000000037462545.index
-rw-r--r-- 1 65534 65534 430M 10月 13 19:02 00000000000037462545.log
-rw-r--r-- 1 65534 65534 4.6K 10月 13 19:02 00000000000037462545.snapshot
-rw-r--r-- 1 65534 65534  10M 10月 13 19:02 00000000000037462545.timeindex
-rw-r--r-- 1 65534 65534   15 10月 13 19:03 leader-epoch-checkpoint
-rwxr-xr-x 1 65534 65534   43 10月 13 17:33 partition.metadata

hostname 问题

两个带 hostname 目录的问题

# https://github.com/wurstmeister/kafka-docker/blob/master/start-kafka.sh#L43C1-L45C3
if [[ -z "$KAFKA_LOG_DIRS" ]]; then
    export KAFKA_LOG_DIRS="/kafka/kafka-logs-$HOSTNAME"
fi

从启动脚本看到上面逻辑，没有设置就拼接 hostname，指定 KAFKA_LOG_DIRS 成固定，再修改启动脚本支持升级后把老目录 mv 成不带 hostname 的唯一目录：

if [ -n "$KAFKA_LOG_DIRS" ] && ! [ -d "$KAFKA_LOG_DIRS" ];then
latest_log_dir=$(ls -1 -t -d /kafka/kafka-logs-* | head -n1)
if [ -n "$latest_log_dir" ];then
echo "found old kafka-logs-: ${latest_log_dir}"
mv -v $latest_log_dir $KAFKA_LOG_DIRS
fi
fi

hostname 问题

两个目录问题还是要查找原因的，出现的场景是在我们 kafka 之前是 staticPod + hostPath 部署的，后面切成 docker-compose 部署后发生的，相关配置为：

# staticPod
  hostNetwork: true
  hostname: kafka-{{ MY_ID }}

# docker-compose
    network_mode: host
    hostname: kafka-{{ kafka.MY_ID }}

而仔细看 mtime：

1
2
3

total 88
drwxr-xr-x 568 nfsnobody nfsnobody 28672 Oct  1 17:42 kafka-logs-kafka-1
drwxr-xr-x 535 nfsnobody nfsnobody 28672 Sep 26 19:51 kafka-logs-vm10-7-131-94

-kafka-1 是最新的，也就是说 docker-compose 没问题，而 k8s 的容器获取到的是宿主机的 hostname，验证了下确实：

1 2	$ docker run -ti --entrypoint hostname --net host --hostname test111 m.daocloud.io/docker.io/library/nginx:alpine test111

测试 hostNetwork 和 hostname 一起下，容器的 hostname 是宿主机的：

---
apiVersion: v1
kind: Pod
metadata:
  namespace: default
  name: test-hostname
spec:
  containers:
  - name: test
    image: m.daocloud.io/docker.io/library/nginx:alpine
    command: ["/bin/sh"]
    tty: true
  hostname: test111
  hostNetwork: true

一开始想着是 cri-dockerd 的 bug，想着去再提交一个 pr ，于是先让群友 containerd 环境 K8S 测下，好拿信息去提交 pr。结果发现 containerd K8S 下也一样是宿主机的 hostname，搜索了下后发现：

https://github.com/kubernetes/kubernetes/issues/67019

是 K8S 代码逻辑导致的，看了下 issue，看到有 pr 关联 KEP-4762: Allows setting any FQDN as the pod’s hostname 是新版本里加了个特性 features.HostnameOverride 门控和字段 HostnameOverride，但是看了下描述，发现压根不是一回事：

// HostnameOverride specifies an explicit override for the pod's hostname as perceived by the pod.
// This field only specifies the pod's hostname and does not affect its DNS records.
// When this field is set to a non-empty string:
// - It takes precedence over the values set in `hostname` and `subdomain`.
// - The Pod's hostname will be set to this value.
// - `setHostnameAsFQDN` must be nil or set to false.
// - `hostNetwork` must be set to false.
//
// This field must be a valid DNS subdomain as defined in RFC 1123 and contain at most 64 characters.
// Requires the HostnameOverride feature gate to be enabled.
//
// +featureGate=HostnameOverride
// +optional
HostnameOverride *string

注意看上面的 hostNetwork must be set to false. ，新版本的这个特性压根解决不了这个问题，只能是自己踩坑了。

结论

截止目前为止，k8s 的 Pod 同时配置 hostNetwork 和 hostname 下，容器内的 hostname 是宿主机的，docker 直接起这样配置的容器则没问题，如果你的进程依赖 hostname，则要注意这块。

个别节点上 flannel.1 的 IP 无法 ping

2025-09-23T10:10:30.000Z

一次客户环境上个别节点 flannel.1 的 IP 无法 ping 的排查

由来

客户反馈他们环境 agent 告警监控：本机上的 IP 10.187.12.0 无法 ping 通。

排查

定位范围

客户环境不能远程，都是发命令让查的，查看 flannel 容器均没有重启：

1 2	$ docekr ps -a \| grep flanneld cb0e35b00899 1e0b2bff6efb "/opt/bin/flanneld -…" 7 weeks ago Up 7 weeks k8s_kube-flannel_kube-flannel-ds-qbps5_kube-system_bffc6d17-0835-468d-bb90-2367c190c94f_0

让客户去告警机器上 ping，客户说 cni0 地址是通的，就 10.187.12.0 和 10.187.11.0 无法 ping 通，沟通一番才意识到是这俩 ip 在各自本机上无法 ping 通，直接 ping 报错：

1 2	$ ping 10.187.12.0 Do you want to ping broadcast? Then -b. If not, check your local firewall rules.

看了下 flannel.1 和 cni0 的 IP 信息也没问题：

$ ip a s flannel.1
9: flannel.1:  mtu 1450 qdisc noqueue state UNKNOWN group default 
    link/ether 4e:81:e2:84:ff:49 brd ff:ff:ff:ff:ff:ff
    inet 10.187.12.0/32 scope global flannel.1
       valid_lft forever preferred_lft forever
    inet6 fe80::4c81:e2ff:fe84:ff49/64 scope link 
       valid_lft forever preferred_lft forever
$ ip a s cni0
7: cni0:  mtu 1450 qdisc noqueue state UP group default qlen 1000
    link/ether 02:e6:56:fb:18:3d brd ff:ff:ff:ff:ff:ff
    inet 10.187.12.1/24 brd 10.187.12.255 scope global cni0
       valid_lft forever preferred_lft forever
    inet6 fe80::e6:56ff:fefb:183d/64 scope link 
       valid_lft forever preferred_lft forever

看了下内核参数也正常：

1 2	$ cat /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts 1

去搜下源码看看，

1 2	$ rpm -qf `which ping` iputils-20190709-5.ky10.aarch64

搜到源码 iputils 没特殊处理逻辑：

// https://github.com/iputils/iputils/blob/master/ping/ping.c#L885-L895

sock_setmark(rts, probe_fd);

dst.sin_port = htons(1025);
if (rts->nroute)
dst.sin_addr.s_addr = rts->route[0];
if (connect(probe_fd, (struct sockaddr *)&dst, sizeof(dst)) == -1) {
if (errno == EACCES) {
if (rts->broadcast_pings == 0)
error(2, 0,
_("Do you want to ping broadcast? Then -b. If not, check your local firewall rules"));
fprintf(stderr, _("WARNING: pinging broadcast address\n"));

完全走的系统层面分配，获取到的地址是广播地址才报错，看下路由：

$ ip route show
default via xxx dev enp4s0
....
10.187.12.0/24 dev cni0 proto kernel scope link src 10.187.12.1

但是路由匹配就有问题了：

1
2
3

$ ip route get 10.187.12.0
broadcast 10.187.12.0 dev cni0 src 10.187.12.1 uid 58248
    cache

看来问题就在路由这块，ip route show 实际是 ip route show talbe main 看下由网卡生成的 local 路由表：

1
2
3

$ ip route show table local | grep 10.187.12.0
broadcast 10.187.12.0 dev cni0 proto kernel scope link src 10.187.12.1 
local 10.187.12.0 dev flannel.1 proto kernel scope host src 10.187.12.0

果然是顺序导致，local 路由表是根据网卡顺序生成的，前面细心的话会发现 flannel.1 前面数字是 9，cni0 是 7，意味着 cni0 比 flannel.1 先创建，或者是 flannel.1 网卡删除后重启 flanneld 容器创建的。

复现

内部找个 k8s 环境测试下复现了：

$ ip a s flannel.1
6: flannel.1:  mtu 1450 qdisc noqueue state UNKNOWN group default 
    link/ether 4a:53:ae:34:23:99 brd ff:ff:ff:ff:ff:ff
    inet 10.187.2.0/32 scope global flannel.1
       valid_lft forever preferred_lft forever
    inet6 fe80::4853:aeff:fe34:2399/64 scope link 
       valid_lft forever preferred_lft forever
$ ping 10.187.2.0
PING 10.187.2.0 (10.187.2.0) 56(84) bytes of data.
64 bytes from 10.187.2.0: icmp_seq=1 ttl=64 time=0.042 ms
^C
--- 10.187.2.0 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.042/0.042/0.042/0.000 ms

$ ip link delete flannel.1
$ docker ps -a | grep flanneld
46079b620076   reg.xxx.lan:5000/xxx/flannel                                                     "/opt/bin/flanneld -…"   8 days ago       Up 8 days 
$ docker restart 460
$ ping 10.187.2.0
Do you want to ping broadcast? Then -b. If not, check your local firewall rules.

解决

添加 32 位掩码路由不行：

1
2
3

$ ip route add 10.187.2.0/32 dev flannel.1
$ ping 10.187.2.0
Do you want to ping broadcast? Then -b. If not, check your local firewall rules.

因为 local 先匹配：

1
2
3

$ ip route show table local | grep 10.187.2.0
broadcast 10.187.2.0 dev cni0 proto kernel scope link src 10.187.2.1 
local 10.187.2.0 dev flannel.1 proto kernel scope host src 10.187.2.0

删除后可以：

$ ip route delete broadcast 10.187.2.0 dev cni0 proto kernel scope link src 10.187.2.1
$ ip route show
...
10.185.0.0/16 dev docker0 proto kernel scope link src 10.185.0.1 
10.187.0.0/24 via 10.187.0.0 dev flannel.1 onlink 
10.187.1.0/24 via 10.187.1.0 dev flannel.1 onlink 
10.187.2.0/24 dev cni0 proto kernel scope link src 10.187.2.1 
$ ip route show table local  | grep 10.187.2.0
local 10.187.2.0 dev flannel.1 proto kernel scope host src 10.187.2.0

$ ping 10.187.2.0
PING 10.187.2.0 (10.187.2.0) 56(84) bytes of data.
64 bytes from 10.187.2.0: icmp_seq=1 ttl=64 time=0.074 ms
^C
--- 10.187.2.0 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.074/0.074/0.074/0.000 ms

测下跨节点也没问题：

$ ping 10.187.0.1
PING 10.187.0.1 (10.187.0.1) 56(84) bytes of data.
64 bytes from 10.187.0.1: icmp_seq=1 ttl=64 time=0.365 ms
64 bytes from 10.187.0.1: icmp_seq=2 ttl=64 time=0.325 ms
^C
--- 10.187.0.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.325/0.345/0.365/0.020 ms

结论

虽然这个细节问题不影响 k8s overlay 网络，但是客户监控告警要查清楚原因。

salt-run很久才返回

2025-09-12T20:10:30.000Z

一次 salt-run 很久才返回的排查

由来

所有 salt-run 命令耗时都很久

$ time salt-run jobs.active
[INFO    ] Runner completed: 20250912111420062465_14113

real0m23.432s
user0m2.716s
sys0m0.320s

排查

salt-master 是容器里运行的，该容器没 ptrace 权限，怕重启容器后故障无了。就容器内执行卡住后看下宿主机进程 salt-run 是唯一的，宿主机上有 strace 命令，strace 看看：

$ strace -p `ps -ef | grep -E 'salt-ru[n]' | awk '{print $2}' `
...
...

openat(AT_FDCWD, "/etc/hosts", O_RDONLY|O_CLOEXEC) = 11
fstat(11, {st_mode=S_IFREG|0644, st_size=898, ...}) = 0
lseek(11, 0, SEEK_SET)                  = 0
read(11, "#\n# hosts         This file desc"..., 4096) = 898
read(11, "", 4096)                      = 0
close(11)                               = 0
newfstatat(AT_FDCWD, "/etc/nsswitch.conf", {st_mode=S_IFREG|0644, st_size=1516, ...}, 0) = 0
newfstatat(AT_FDCWD, "/etc/resolv.conf", {st_mode=S_IFREG|0644, st_size=211, ...}, 0) = 0
openat(AT_FDCWD, "/etc/hosts", O_RDONLY|O_CLOEXEC) = 11
fstat(11, {st_mode=S_IFREG|0644, st_size=898, ...}) = 0
lseek(11, 0, SEEK_SET)                  = 0
read(11, "#\n# hosts         This file desc"..., 4096) = 898
read(11, "", 4096)                      = 0
close(11)                               = 0
socket(PF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 11
setsockopt(11, SOL_IP, IP_RECVERR, [1], 4) = 0
connect(11, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.xx.xx.1")}, 16) = 0
poll([{fd=11, events=POLLOUT}], 1, 0)   = 1 ([{fd=11, revents=POLLOUT}])
sendto(11, "e\366\1\0\0\1\0\0\0\0\0\0\7kubexxx\0\0\34\0\1", 25, MSG_NOSIGNAL, NULL, 0) = 25
poll([{fd=11, events=POLLIN}], 1, 5000


...

左边窗口执行，右边赶紧 strace，发现有输出后卡主，赶紧按回车分开，最后往上翻找空行附近就是卡住的信息。从上面看就是 glibc 的 DNS 解析行为：

先看 /etc/nsswitch.conf 内的 hosts 行，看 hosts 和 dns 的优先级
connect(11, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.xx.xx.1")}, 16) = 0 发起了 DNS 解析请求的连接信息
sendto(11, "e\366\1\0\0\1\0\0\0\0\0\0\7kubexxx\0\0\34\0\1", 25, MSG_NOSIGNAL, NULL, 0) = 25 DNS 请求

然后再执行下，另一个窗口看了下链接确实存在 DNS 解析行为：

1 2	$ ss -anuop \| grep :53 ESTAB 0 0 10.xx.xx.215:36250 10.xx.xx.1:53 users:(("salt-run",pid=13752,fd=4))

然后抓包看了下请求：

# 手机阅读的话，请往右侧翻
$ tcpdump -nn -i any port 53 -vvv
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
19:34:24.952563 IP (tos 0x0, ttl 64, id 50084, offset 0, flags [DF], proto UDP (17), length 53)
    10.xx.xx.215.63760 > 10.xx.xx.1.53: [bad udp cksum 0xc324 -> 0xd5d2!] 64743+ AAAA? kubexxx. (25)
19:34:26.613645 IP (tos 0x0, ttl 64, id 50437, offset 0, flags [DF], proto UDP (17), length 53)
    10.xx.xx.215.35564 > 10.xx.xx.1.53: [bad udp cksum 0xc324 -> 0x3614!] 2763+ AAAA? kubexxx. (25)

看上面的 AAAA? kubexxx，可以确认是请求 hostname kubexxx 的 IPv6 DNS 解析记录，然后加了下 hosts 就好了。

$  echo "::1 $HOSTNAME" >> /etc/hosts
$ time salt-run jobs.active
[INFO    ] Runner completed: 20250912113512377461_16938

real0m3.265s
user0m2.714s
sys0m0.254s

解决

搜了下关键字 salt-run dns ipv6 看看有没有其他人遇到，结果找到类似问题：

但是回复都是老版本遇见多，我这边版本都很新了：

$ salt --versions-report
Salt Version:
          Salt: 3006.15
 
Python Version:
        Python: 3.10.13 (main, Sep  8 2025, 06:32:11) [GCC 10.3.1]
 
Dependency Versions:
          cffi: 1.14.5
      cherrypy: Not Installed
  cryptography: 44.0.1
      dateutil: 2.8.2
     docker-py: 6.1.3
         gitdb: Not Installed
     gitpython: Not Installed
        Jinja2: 3.0.1
       libgit2: Not Installed
  looseversion: 1.3.0
      M2Crypto: Not Installed
          Mako: 1.2.2
       msgpack: 1.0.5
  msgpack-pure: Not Installed
  mysql-python: Not Installed
     packaging: 24.1
     pycparser: 2.20
      pycrypto: 3.19.1
  pycryptodome: Not Installed
        pygit2: Not Installed
  python-gnupg: Not Installed
        PyYAML: 6.0.1
         PyZMQ: 27.0.2
        relenv: Not Installed
         smmap: Not Installed
       timelib: Not Installed
       Tornado: 4.5.3
           ZMQ: 4.3.5
 
System Versions:
          dist: openeuler 22.03 LTS-SP4
        locale: utf-8
       machine: x86_64
       release: 4.12.14-120-default
        system: Linux
       version: openEuler 22.03 LTS-SP4

这种是 glibc 的行为，salt 会解析 hostname，业务临近封库，改这个 docker 镜像内启动脚本也来不及了，就先在代码层面解决了，搜了下 python socket 库并没有那种纯看 hosts 条目的库，就手动写了如下逻辑：

import fcntl
import socket

def ensure_hosts_entry(ip_address, hostname):
    with open("/etc/hosts", "r+") as f:
        try:
            # 加排他锁（阻塞模式，确保并发安全）
            fcntl.flock(f, fcntl.LOCK_EX)
            original_content = f.readlines()

            for index, line in enumerate(original_content):
                line_part = line.split(' ')
                if len(line_part) < 2:
                    continue
                if hostname in line_part:
                    return

            original_content.append(f"{ip_address} {hostname}\n")
            f.seek(0)
            f.truncate()
            f.write(''.join(original_content))
            f.flush()
        finally:
            fcntl.flock(f, fcntl.LOCK_UN)


ensure_hosts_entry("::1", socket.gethostname())
...

麒麟内核4.19.90-52.49导致的flannel vxlan跨节点不通

2025-09-10T18:10:30.000Z

一次麒麟内核导致 flannel 跨节点不通的排查

由来

客户有一套 K8S 环境 A 要扩容，给了两台机器加进后，同事发现新节点 flannel 跨节点不通。抓包排查发现新节点的 ip -s a s flannel.1 显示的 Rx 收包为0。
客户认为是 k8s 问题，我们认为是客户网络环境没放行 UDP。然后双方达成共识搞一套干净环境 B 部署 K8S 看看，然后发现依旧跨节点不通。

排查

环境信息

$ cat /etc/os-release
NAME="Kylin Linux Advanced Server"
VERSION="V10 (Lance)"
ID="kylin"
VERSION_ID="V10"
PRETTY_NAME="Kylin Linux Advanced Server V10 (Lance)"
ANSI_COLOR="0;31"

$ lscpu
Architecture:                    x86_64
CPU op-mode(s):                  32-bit, 64-bit
Byte Order:                      Little Endian
Address sizes:                   48 bits physical, 48 bits virtual
CPU(s):                          14
On-line CPU(s) list:             0-13
Thread(s) per core:              1
Core(s) per socket:              2
Socket(s):                       7
NUMA node(s):                    1
Vendor ID:                       AuthenticAMD
CPU family:                      15
Model:                           6
Model name:                      Hygon C86-3G 7390 32-core Processor
Stepping:                        3
CPU MHz:                         2699.998
BogoMIPS:                        5399.99
Hypervisor vendor:               KVM
Virtualization type:             full
L1d cache:                       896 KiB
L1i cache:                       896 KiB
L2 cache:                        7 MiB
L3 cache:                        112 MiB
NUMA node0 CPU(s):               0-13
Vulnerability Itlb multihit:     Not affected
Vulnerability Spec store bypass: Not affected
Vulnerability Spectre v1:        Mitigation; usercopy/swapgs barriers and __user pointer sanitization
Vulnerability Spectre v2:        Mitigation; Retpolines, STIBP disabled, RSB filling, PBRSB-eIBRS Not affected
Vulnerability Srbds:             Not affected
Vulnerability Tsx async abort:   Not affected
Flags:                           fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx lm rep_good 
                                 nopl cpuid extd_apicid tsc_known_freq pni cx16 x2apic aes hypervisor cmp_legacy 3dnowprefetch vmmcall

接手缘由

现场的同事卸载了 K8S 后测试UDP 还是一样，然后认为 udp 存在限制，客户用 nmap 扫描认为 UDP 没限制，我们用 nc 起 server 用 client 测不通，客户认为我们这种测试方式不准，我就写了个测试脚本给同事：

# -*- coding: utf-8 -*-
from __future__ import print_function
import socket
import sys
import logging


if sys.version_info[0] == 2:
    input = raw_input

def usage():
    print("Usage:")
    print("  Server: python udp-test.py ")
    print("  Client: python udp-test.py ")
    sys.exit(1)

def parse_addr(s):
    if ":" in s:
        host, port = s.rsplit(":", 1)
        return host, int(port)
    else:
        return None, int(s)

def server(port):
    sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
    sock.bind(("0.0.0.0", port))
    logging.info("Server listening on UDP *:%d", port)
    while True:
        data, addr = sock.recvfrom(4096)
        msg = data.decode('utf-8', 'ignore')
        logging.info("Received from %s: %r", addr, msg)
        sock.sendto(data, addr)          # 回显

def client(host, port):
    sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
    target = (host, port)
    logging.info("Client target UDP %s:%d (type message and press Enter)", host, port)
    while True:
        try:
            text = input(">>> ")
        except (EOFError, KeyboardInterrupt):
            print("\nBye")
            break
        if not text:
            continue
        sock.sendto(text.encode('utf-8'), target)
        sock.settimeout(2)
        try:
            data, _ = sock.recvfrom(4096)
            logging.info("Server echoed: %r", data.decode('utf-8', 'ignore'))
        except socket.timeout:
            logging.debug("No echo within 2s")

def main():
    if len(sys.argv) != 2:
        usage()
    addr_str = sys.argv[1]
    host, port = parse_addr(addr_str)

    LOG_FMT = "%(asctime)s [%(levelname)s] %(message)s"
    logging.basicConfig(level=logging.INFO, format=LOG_FMT)
    if host is None:
        # 纯数字端口 -> 服务端
        server(port)
    else:
        # host:port -> 客户端
        client(host, port)


if __name__ == "__main__":
    main()

脚本就是连上后发消息回车，server 把收到的消息发回客户端，客户端也打印收到的消息，同事客户环境上测了下发现不正常，然后客户用 tcpdump 抓包说接收到了。看了下客户抓包方式确实没问题：

机器B 上先开抓包 tcpdump -nn -i eth0 port 8472 -w xxx.pcap
机器A 上 echo "123" | nc -u <机器B_ip> 8472

之前以为是客户在发送机器上抓的，理清楚客户思路是正确后，就远程上去看了。

抓包重现

确实目标机器能抓到报文：

$ tcpdump  -nn -i any port 8472 -vvv
dropped privs to tcpdump
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes
14:43:39.267522 IP (tos 0x0, ttl 64, id 56033, offset 0, flags [DF], proto UDP (17), length 35)
    10.xx.50.166.50492 > 10.xx.50.169.8472: [udp sum ok] OTV,  [|OTV]
^C
1 packet captured
3 packets received by filter
0 packets dropped by kernel

上面是抓包后用 nc 发 UDP 抓的，然后下面是脚本形式发的抓的

$ tcpdump -nn -i any port 8472 -vvv
dropped privs to tcpdump
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes
14:48:58.540224 IP (tos 0x0, ttl 64, id 48511, offset 0, flags [DF], proto UDP (17), length 31)
    10.xx.50.166.46543 > 10.xx.50.169.8472: [bad udp cksum 0x7a0d -> 0x4acd!] OTV,  [|OTV]
^C
1 packet captured
2 packets received by filter
0 packets dropped by kernel

解决

上面抓包对比里有 bad udp cksum，尝试取消网卡计算 checksum 试试：

$ ethtool --show-offload eth0 | grep checksum
rx-checksumming: on [fixed]
tx-checksummtng: on
tx-checksum-ipv4:off[fixed]
tx-checksum-ip-generic: on
tx-checksum-ipv6: off [fixed]
tx-checksum-fcoe-crc: off [ftxed]
tx-checksum-sctp: off [fixed]
$ ethtool --offload eth0 tx-checksum-ip-generic off
Actual changes:
tx-checksumming: off
tx-checksum-ip-generic: off
tcp-segmentatton-offLoad: off
tx-tcp-segmentation; off [requested on]
tx-tcp-ecn-segmentation: off [requested on]
tx-tcp6-segmentation: off [requested on]

测了下发下还不行，然后几个都设置了还是不行：

1	ethtool --offload eth0 tx off rx off

对比了环境 A 的 offload 都一样，并且查看驱动也一致：

1 2	$ readlink -f /sys/class/net/eth0/device/driver/module /sys/module/virtio_net

iptables 啥规则都没有，还有不一样的就只有内核版本了：

正常环境：Linux 4.19.90-52.22.v2207.ky10.x86_64 #1 SMP Tue Mar 14 12:19:10 CST 2023 x86_64 x86_64 x86_64 GNU/Linux
异常环境：Linux 4.19.90-52.49.v2207.ky10.x86_64 #3 SMP Thu Jul 24 02:43:35 CST 2025 x86_64 x86_64 x86_64 GNU/Linux

询问客户能不能这套环境 B 机器换成和正常环境一样内核的虚机，客户答复说是平台自动化开的机器，无法保持内核一致。没办法，然后看这套环境是不是升级过内核：

$ grep kernel /var/log/dnf*
...
/var/log/dnf.rpm.log:2025-08-07T01:34:25Z SUBDEBUG InstaLLed:kernel-4.19.90-52.49.v2207.ky10.x86_64
/var/log/dnf.rpm.log:2025-08-67T01:34:26Z SUBDEBUG Upgrade:kernel-tools-4.19.90-52.49.v2207.ky10.x86_64
/var/log/dnf.rpm.log:2025-08-07T01:34:29Z SUBDEBUG Upgraded:kernel-tools-4.19.90-52.45.v2207.ky10.x86_64
/var/log/dnf.rpm.log:2025-08-67T01:34:30Z SUBDEBUG Upgraded:kernel-headers-4.19.90-52.45.v2207.ky10.x86_64
/var/log/dnf.rpm.log:2025-08-07T01:34:34Z SUBDEBUG Upgraded:kernel-tools-libs-4.19.90-52.45.v2207.ky10.x86_64

果然升级了，看下老版本在不在：

$ rpm -qa | grep kernel
kernel-modules-extra-4.19.90-52.45.v2207.ky10.x86_64
kernel-moduLes-extra-4.19.90-52.22.v2207.ky10.x86_64
kernel-modules-4.19.90-52.49.v2207.ky10.x86_64
kernel-core-4.19.90-52.22.v2207.ky10.x86_64
kerne1-t001s-11bs-4.19.90-52.49.V2207.ky10.x86_64
kernel-modules-extra-4.19.96-52.49.v2207.ky10.x86_64
kernel-4.19.90-52.22.v2207.ky10.x86_64
kernel-t00L5-4.19.90-52.49.v2207.ky10.x86_64
kernel-core-4.19.90-52.45.v2207.ky10.x86_64
kernel-modules-4.19.90-52.45.v2207.ky10.x86_64
kernel-4.19.90-52.45.v2207.ky10.x86_64
kernel-modules-4.19.90-52.22.v2207.ky10.x86_64
kernel-headers-4.19.96-52.49.v2207.ky10.x86_64
kernel-4.19.90-52.49.v2207.ky10.x86_64
kernel-4.19.90-52.49.v2207.ky10.x86_64

查看下 grub 里顺序：

$ awk -F\' '$1=="menuentry " {print i++ " : " $2}' /etc/grub2.cfg
0 : Kylin Linux Advanced Server (4.19.90-52.49.v2207.ky10.x86_64) V10 (Lance)
1 : Kylin Linux Advanced Server (4.19.90-52.45.v2207.ky10.x86_64) V10 (Lance)
2 : Kylin Linux Advanced Server (4.19.90-52.22.v2207.ky10.x86_64) V10 (Lance)
3 : Kylin Linux Advanced Server (0-rescue-de06076a688a45bf9d1acd0bf45bb93e) V10 (Lance)

切换到 52.22:

1 2	$ grub2-set-default 2 $ grub2-mkconfig -o /etc/grub2.cfg

询问客户能否重启，可以重启，重启后测试就正常了：

$ uname -a
Linux TKVMJT0240 4.19.90-52.22.v2207.ky10.x86_64 #1 SMP Tue Mar 14 12:19:10 CST 

# 任意机器1
$ python udp-test.py 8472


# 机器2
$ python udp-test.py 机器1的ip:8472
25-09-10 17:29:59,623 [INFO] Client raget UDP xxx:8472( type message and press Enter)
>>> 123
25-09-10 17:30:00,753 [INFO] Server echoed: '123'
>>> ^C
Bye

其他几个机器一样处理后都正常。

flannel 路由错乱

2025-09-03T10:10:30.000Z

一次 flannel 路由错乱导致的跨节点不通

由来

有一套客户测试环境，实施部署业务后发现有问题，看了下业务日志无法解析域名。因为 host-gw 需要二层，而且有些虚拟化有 IP/MAC 绑定，所以默认用 vxlan 模式。

排查

路由不对

上去查了下发现 Pod 网段路由不对：

$  ip r s 
default via 172.16.0.1 dev eth0 proto dhcp metric 100 
10.185.0.0/16 dev docker0 proto kernel scope link src 10.185.0.1 linkdown 
10.187.0.0/24 via 172.16.0.250 dev eth0
10.187.1.0/24 via 172.16.0.202 dev eth0 
10.187.2.0/24 via 172.16.0.104 dev eth0 #<--- 这几个
10.187.3.0/24 via 172.16.0.104 dev eth0 #<--- 这几个
10.187.3.0/24 dev cni0 proto kernel scope link src 10.187.3.1 #<--- 这几个
172.16.0.0/24 dev eth0 proto kernel scope link src 172.16.0.231 metric 100

是 vxlan 模式，但是 2.0、3.0 下一跳都是 172.16.0.104，而且本机是 10.187.3.0/24 网段，cni0 的路由无法匹配到。怀疑是客户添加的路由，让和客户沟通后换个和客户内网不重合的 Pod CIDR。然后实施重装后还是这样，上去看了下日志：

模式错乱

$ docker ps -a | grep flanneld
$ docker logs xxxx # flannel容器ID
W0903 01:37:31.229597       1 main.go:540] no subnet found for key: FLANNEL_IPV6_NETWORK in file: /run/flannel/subnet.env
W0903 01:37:31.229636       1 main.go:540] no subnet found for key: FLANNEL_IPV6_SUBNET in file: /run/flannel/subnet.env
I0903 01:37:31.229643       1 iptables.go:125] Setting up masking rules
I0903 01:37:31.422425       1 iptables.go:226] Changing default FORWARD chain policy to ACCEPT
I0903 01:37:31.523863       1 main.go:396] Wrote subnet file to /run/flannel/subnet.env
I0903 01:37:31.523889       1 main.go:400] Running backend.
I0903 01:37:31.524023       1 route_network.go:56] Watching for new subnet leases
I0903 01:37:31.524247       1 subnet.go:152] Batch elem [0] is { lease.Event{Type:0, Lease:lease.Lease{EnableIPv4:true, EnableIPv6:false, Subnet:ip.IP4Net{IP:0xa610100, PrefixLen:0x18}, IPv6Subnet:ip.IP6Net{IP:(*ip.IP6)(nil), PrefixLen:0x0}, Attrs:lease.LeaseAttrs{PublicIP:0xac100068, PublicIPv6:(*ip.IP6)(nil), BackendType:"host-gw", BackendData:json.RawMessage{0x6e, 0x75, 0x6c, 0x6c}, BackendV6Data:json.RawMessage(nil)}, Expiration:time.Date(1, time.January, 1, 0, 0, 0, 0, time.UTC), Asof:0}} }
I0903 01:37:31.524425       1 subnet.go:152] Batch elem [0] is { lease.Event{Type:0, Lease:lease.Lease{EnableIPv4:true, EnableIPv6:false, Subnet:ip.IP4Net{IP:0xa610300, PrefixLen:0x18}, IPv6Subnet:ip.IP6Net{IP:(*ip.IP6)(nil), PrefixLen:0x0}, Attrs:lease.LeaseAttrs{PublicIP:0xac1000e7, PublicIPv6:(*ip.IP6)(nil), BackendType:"host-gw", BackendData:json.RawMessage{0x6e, 0x75, 0x6c, 0x6c}, BackendV6Data:json.RawMessage(nil)}, Expiration:time.Date(1, time.January, 1, 0, 0, 0, 0, time.UTC), Asof:0}} }
I0903 01:37:31.524449       1 route_network.go:93] Subnet added: 10.97.1.0/24 via 172.16.0.104
I0903 01:37:31.524705       1 route_network.go:166] Route to {Ifindex: 2 Dst: 10.97.1.0/24 Src:  Gw: 172.16.0.104 Flags: [] Table: 0 Realm: 0} already exists, skipping.
I0903 01:37:31.524797       1 route_network.go:93] Subnet added: 10.97.3.0/24 via 172.16.0.231
I0903 01:37:31.524876       1 route_network.go:166] Route to {Ifindex: 2 Dst: 10.97.3.0/24 Src:  Gw: 172.16.0.231 Flags: [] Table: 0 Realm: 0} already exists, skipping.
I0903 01:37:31.524903       1 subnet.go:152] Batch elem [0] is { lease.Event{Type:0, Lease:lease.Lease{EnableIPv4:true, EnableIPv6:false, Subnet:ip.IP4Net{IP:0xa610000, PrefixLen:0x18}, IPv6Subnet:ip.IP6Net{IP:(*ip.IP6)(nil), PrefixLen:0x0}, Attrs:lease.LeaseAttrs{PublicIP:0xac1000fa, PublicIPv6:(*ip.IP6)(nil), BackendType:"host-gw", BackendData:json.RawMessage{0x6e, 0x75, 0x6c, 0x6c}, BackendV6Data:json.RawMessage(nil)}, Expiration:time.Date(1, time.January, 1, 0, 0, 0, 0, time.UTC), Asof:0}} }
I0903 01:37:31.524939       1 route_network.go:93] Subnet added: 10.97.0.0/24 via 172.16.0.250
I0903 01:37:31.525190       1 route_network.go:166] Route to {Ifindex: 2 Dst: 10.97.0.0/24 Src:  Gw: 172.16.0.250 Flags: [] Table: 0 Realm: 0} already exists, skipping.
I0903 01:37:31.621427       1 main.go:421] Waiting for all goroutines to exit
I0903 01:37:31.922267       1 iptables.go:372] bootstrap done
I0903 01:37:32.129063       1 iptables.go:372] bootstrap done

上面日志很奇怪，注意几个关键地方：

BackendType:"host-gw"
Subnet added: 10.97.0.0/24 via 172.16.0.250

怎么会是 host-gw 模式，查看下路由：

[root@vm172-16-0-202 ~]# ip r s 
default via 172.16.0.1 dev eth0 proto dhcp metric 100 
10.97.0.0/24 via 172.16.0.250 dev eth0 
10.97.1.0/24 via 172.16.0.104 dev eth0 
10.97.2.0/24 via 172.16.0.250 dev eth0 
10.97.2.0/24 dev cni0 proto kernel scope link src 10.97.2.1 
10.97.3.0/24 via 172.16.0.231 dev eth0 
10.185.0.0/16 dev docker0 proto kernel scope link src 10.185.0.1 linkdown 
10.187.0.0/24 via 172.16.0.250 dev eth0 
10.187.2.0/24 via 172.16.0.104 dev eth0 
10.187.3.0/24 via 172.16.0.231 dev eth0 
172.16.0.0/24 dev eth0 proto kernel scope link src 172.16.0.202 metric 100

老路由忽略，新路由看确实是 host-gw 模式的路由，看下 configmap 配置模式：

[root@vm172-16-0-202 ~]# kubectl -n kube-system get cm kube-flannel-cfg -o yaml
apiVersion: v1
data:
  cni-conf.json: |
    {
      "name": "cbr0",
      "cniVersion": "0.3.1",
      "plugins": [
        {
          "type": "flannel",
          "delegate": {
            "hairpinMode": true,
            "isDefaultGateway": true
          }
        },
        {
          "type": "portmap",
          "capabilities": {
            "portMappings": true
          }
        }
      ]
    }
  net-conf.json: |
    {

      "Network": "10.97.0.0/16",
            "Backend": {
        "Type": "vxlan",
        "Port": 8475
      }
    }
kind: ConfigMap

configmap 是 vxlan 没问题，看下文件：

[root@vm172-16-0-202 ~]# cat /run/flannel/subnet.env 
FLANNEL_NETWORK=10.97.0.0/16
FLANNEL_SUBNET=10.97.2.1/24
FLANNEL_MTU=1500
FLANNEL_IPMASQ=true

奇怪了，怎么是 host-gw 的 1500 MTU，删除下 flannel 容器后再看看：

[root@vm172-16-0-202 ~]# docker rm -f xxx # flanneld 容器id
[root@vm172-16-0-202 ~]# cat /run/flannel/subnet.env 
FLANNEL_NETWORK=10.97.0.0/16
FLANNEL_SUBNET=10.97.2.1/24
FLANNEL_MTU=1450
FLANNEL_IPMASQ=true
[root@vm172-16-0-202 ~]# docker ps -a | grep flanneld
e288c4442ee2   reg.xxx.lan:5000/xxx/flannel                   "/opt/bin/flanneld -…"   41 seconds ago   Up 40 seconds                         k8s_kube-flannel_kube-flannel-ds-w7rk2_kube-system_581101b1-cfa5-4ccc-80be-e78a9c248b96_1
[root@vm172-16-0-202 ~]# docker logs e288
I0903 01:47:13.123249       1 main.go:211] CLI flags config: {etcdEndpoints:http://127.0.0.1:4001,http://127.0.0.1:2379 etcdPrefix:/coreos.com/network etcdKeyfile: etcdCertfile: etcdCAFile: etcdUsername: etcdPassword: version:false kubeSubnetMgr:true kubeApiUrl: kubeAnnotationPrefix:flannel.alpha.coreos.com kubeConfigFile: iface:[] ifaceRegex:[] ipMasq:true ifaceCanReach: subnetFile:/run/flannel/subnet.env publicIP: publicIPv6: subnetLeaseRenewMargin:60 healthzIP:0.0.0.0 healthzPort:0 iptablesResyncSeconds:5 iptablesForwardRules:true netConfPath:/etc/kube-flannel/net-conf.json setNodeNetworkUnavailable:true}
W0903 01:47:13.123387       1 client_config.go:618] Neither --kubeconfig nor --master was specified.  Using the inClusterConfig.  This might not work.
I0903 01:47:13.223377       1 kube.go:139] Waiting 10m0s for node controller to sync
I0903 01:47:13.223476       1 kube.go:469] Starting kube subnet manager
I0903 01:47:13.230593       1 kube.go:490] Creating the node lease for IPv4. This is the n.Spec.PodCIDRs: [10.97.1.0/24]
I0903 01:47:13.230628       1 kube.go:490] Creating the node lease for IPv4. This is the n.Spec.PodCIDRs: [10.97.2.0/24]
I0903 01:47:13.230637       1 kube.go:490] Creating the node lease for IPv4. This is the n.Spec.PodCIDRs: [10.97.3.0/24]
I0903 01:47:13.230644       1 kube.go:490] Creating the node lease for IPv4. This is the n.Spec.PodCIDRs: [10.97.0.0/24]
I0903 01:47:14.223684       1 kube.go:146] Node controller sync successful
I0903 01:47:14.223761       1 main.go:231] Created subnet manager: Kubernetes Subnet Manager - 172.16.0.202
I0903 01:47:14.223767       1 main.go:234] Installing signal handlers
I0903 01:47:14.224176       1 main.go:452] Found network config - Backend type: vxlan
I0903 01:47:14.229346       1 kube.go:669] List of node(172.16.0.202) annotations: map[string]string{"flannel.alpha.coreos.com/backend-data":"null", "flannel.alpha.coreos.com/backend-type":"host-gw", "flannel.alpha.coreos.com/kube-subnet-manager":"true", "flannel.alpha.coreos.com/public-ip":"172.16.0.202", "node.alpha.kubernetes.io/ttl":"0", "volumes.kubernetes.io/controller-managed-attach-detach":"true"}
I0903 01:47:14.229398       1 match.go:210] Determining IP address of default interface
I0903 01:47:14.229758       1 match.go:263] Using interface with name eth0 and address 172.16.0.202
I0903 01:47:14.229788       1 match.go:285] Defaulting external address to interface address (172.16.0.202)
I0903 01:47:14.229841       1 vxlan.go:141] VXLAN config: VNI=1 Port=8475 GBP=false Learning=false DirectRouting=false
I0903 01:47:14.233427       1 kube.go:636] List of node(172.16.0.202) annotations: map[string]string{"flannel.alpha.coreos.com/backend-data":"null", "flannel.alpha.coreos.com/backend-type":"host-gw", "flannel.alpha.coreos.com/kube-subnet-manager":"true", "flannel.alpha.coreos.com/public-ip":"172.16.0.202", "node.alpha.kubernetes.io/ttl":"0", "volumes.kubernetes.io/controller-managed-attach-detach":"true"}
I0903 01:47:14.249292       1 iptables.go:51] Starting flannel in iptables mode...
W0903 01:47:14.249452       1 main.go:540] no subnet found for key: FLANNEL_IPV6_NETWORK in file: /run/flannel/subnet.env
W0903 01:47:14.249491       1 main.go:540] no subnet found for key: FLANNEL_IPV6_SUBNET in file: /run/flannel/subnet.env
I0903 01:47:14.249498       1 iptables.go:125] Setting up masking rules
I0903 01:47:14.250112       1 kube.go:490] Creating the node lease for IPv4. This is the n.Spec.PodCIDRs: [10.97.2.0/24]
I0903 01:47:14.529553       1 iptables.go:226] Changing default FORWARD chain policy to ACCEPT
I0903 01:47:14.622211       1 main.go:396] Wrote subnet file to /run/flannel/subnet.env
I0903 01:47:14.622240       1 main.go:400] Running backend.
I0903 01:47:14.622545       1 vxlan_network.go:65] watching for new subnet leases
I0903 01:47:14.622590       1 subnet.go:152] Batch elem [0] is { lease.Event{Type:0, Lease:lease.Lease{EnableIPv4:true, EnableIPv6:false, Subnet:ip.IP4Net{IP:0xa610100, PrefixLen:0x18}, IPv6Subnet:ip.IP6Net{IP:(*ip.IP6)(nil), PrefixLen:0x0}, Attrs:lease.LeaseAttrs{PublicIP:0xac100068, PublicIPv6:(*ip.IP6)(nil), BackendType:"host-gw", BackendData:json.RawMessage{0x6e, 0x75, 0x6c, 0x6c}, BackendV6Data:json.RawMessage(nil)}, Expiration:time.Date(1, time.January, 1, 0, 0, 0, 0, time.UTC), Asof:0}} }
I0903 01:47:14.622651       1 subnet.go:152] Batch elem [0] is { lease.Event{Type:0, Lease:lease.Lease{EnableIPv4:true, EnableIPv6:false, Subnet:ip.IP4Net{IP:0xa610300, PrefixLen:0x18}, IPv6Subnet:ip.IP6Net{IP:(*ip.IP6)(nil), PrefixLen:0x0}, Attrs:lease.LeaseAttrs{PublicIP:0xac1000e7, PublicIPv6:(*ip.IP6)(nil), BackendType:"host-gw", BackendData:json.RawMessage{0x6e, 0x75, 0x6c, 0x6c}, BackendV6Data:json.RawMessage(nil)}, Expiration:time.Date(1, time.January, 1, 0, 0, 0, 0, time.UTC), Asof:0}} }
I0903 01:47:14.622694       1 vxlan_network.go:100] Received Subnet Event with VxLan: BackendType: host-gw, PublicIP: 172.16.0.104, PublicIPv6: (nil), BackendData: null, BackendV6Data: (nil)
W0903 01:47:14.622710       1 vxlan_network.go:102] ignoring non-vxlan v4Subnet(10.97.1.0/24) v6Subnet(::/0): type=host-gw
I0903 01:47:14.622724       1 vxlan_network.go:100] Received Subnet Event with VxLan: BackendType: host-gw, PublicIP: 172.16.0.231, PublicIPv6: (nil), BackendData: null, BackendV6Data: (nil)
W0903 01:47:14.622727       1 vxlan_network.go:102] ignoring non-vxlan v4Subnet(10.97.3.0/24) v6Subnet(::/0): type=host-gw
I0903 01:47:14.622737       1 subnet.go:152] Batch elem [0] is { lease.Event{Type:0, Lease:lease.Lease{EnableIPv4:true, EnableIPv6:false, Subnet:ip.IP4Net{IP:0xa610000, PrefixLen:0x18}, IPv6Subnet:ip.IP6Net{IP:(*ip.IP6)(nil), PrefixLen:0x0}, Attrs:lease.LeaseAttrs{PublicIP:0xac1000fa, PublicIPv6:(*ip.IP6)(nil), BackendType:"host-gw", BackendData:json.RawMessage{0x6e, 0x75, 0x6c, 0x6c}, BackendV6Data:json.RawMessage(nil)}, Expiration:time.Date(1, time.January, 1, 0, 0, 0, 0, time.UTC), Asof:0}} }
I0903 01:47:14.622759       1 vxlan_network.go:100] Received Subnet Event with VxLan: BackendType: host-gw, PublicIP: 172.16.0.250, PublicIPv6: (nil), BackendData: null, BackendV6Data: (nil)
W0903 01:47:14.622764       1 vxlan_network.go:102] ignoring non-vxlan v4Subnet(10.97.0.0/24) v6Subnet(::/0): type=host-gw
I0903 01:47:14.722083       1 main.go:421] Waiting for all goroutines to exit
I0903 01:47:15.123247       1 iptables.go:372] bootstrap done
I0903 01:47:15.525861       1 iptables.go:372] bootstrap done

文件内容是对了，但是看日志内部显示节点 annotation 注解不对劲：

kube.go:636] List of node(172.16.0.202) annotations: \
  map[string]string{"flannel.alpha.coreos.com/backend-data":"null", \
  "flannel.alpha.coreos.com/backend-type":"host-gw", \
  "flannel.alpha.coreos.com/kube-subnet-manager":"true", \
  "flannel.alpha.coreos.com/public-ip":"172.16.0.202", \
  "node.alpha.kubernetes.io/ttl":"0", "volumes.kubernetes.io/controller-managed-attach-detach":"true"}

显示的是 host-gw ，看下节点注解：

$ kubectl get node -o yaml | grep flannel
      flannel.alpha.coreos.com/backend-data: "null"
      flannel.alpha.coreos.com/backend-type: host-gw
      flannel.alpha.coreos.com/kube-subnet-manager: "true"
      flannel.alpha.coreos.com/public-ip: 172.16.0.104
      - reg.xxx.lan:5000/xxx/flannel@sha256:13cddb14533a10394aa9436bd96a4c866a139b7ef01e71526aae013e724acca7
      - flannel/flannel:v0.25.4
      - reg.xxx.lan:5000/xxx/flannel:v0.25.4
      - reg.xxx.lan:5000/xxx/flannel-cni-plugin@sha256:85aa4c338969e97b1ab751fdc2c167af228a241a224e2d0e5b81ca0f3e93e1fa
      - flannel/flannel-cni-plugin:v1.4.1-flannel1
      - reg.xxx.lan:5000/xxx/flannel-cni-plugin:v1.4.1
      flannel.alpha.coreos.com/backend-data: '{"VNI":1,"VtepMAC":"f6:12:96:a0:5a:14"}'
      flannel.alpha.coreos.com/backend-type: vxlan
      flannel.alpha.coreos.com/kube-subnet-manager: "true"
      flannel.alpha.coreos.com/public-ip: 172.16.0.202
      - reg.xxx.lan:5000/xxx/flannel@sha256:13cddb14533a10394aa9436bd96a4c866a139b7ef01e71526aae013e724acca7
      - flannel/flannel:v0.25.4
      - reg.xxx.lan:5000/xxx/flannel:v0.25.4
      - reg.xxx.lan:5000/xxx/flannel-cni-plugin@sha256:85aa4c338969e97b1ab751fdc2c167af228a241a224e2d0e5b81ca0f3e93e1fa
      - flannel/flannel-cni-plugin:v1.4.1-flannel1
      - reg.xxx.lan:5000/xxx/flannel-cni-plugin:v1.4.1
      flannel.alpha.coreos.com/backend-data: "null"
      flannel.alpha.coreos.com/backend-type: host-gw
      flannel.alpha.coreos.com/kube-subnet-manager: "true"
      flannel.alpha.coreos.com/public-ip: 172.16.0.231
      - reg.xxx.lan:5000/xxx/flannel@sha256:13cddb14533a10394aa9436bd96a4c866a139b7ef01e71526aae013e724acca7
      - flannel/flannel:v0.25.4
      - reg.xxx.lan:5000/xxx/flannel:v0.25.4
      - reg.xxx.lan:5000/xxx/flannel-cni-plugin@sha256:85aa4c338969e97b1ab751fdc2c167af228a241a224e2d0e5b81ca0f3e93e1fa
      - flannel/flannel-cni-plugin:v1.4.1-flannel1
      - reg.xxx.lan:5000/xxx/flannel-cni-plugin:v1.4.1
      flannel.alpha.coreos.com/backend-data: "null"
      flannel.alpha.coreos.com/backend-type: host-gw
      flannel.alpha.coreos.com/kube-subnet-manager: "true"
      flannel.alpha.coreos.com/public-ip: 172.16.0.250

怎么两个 host-gw 模式，既然删除 pod 无用，就 edit 去掉 flannel.alpha.coreos.com/backend-type 注解了

[root@vm172-16-0-202 ~]# kubectl edit node 172.16.0.202
[root@vm172-16-0-202 ~]# kubectl -n kube-system delete pod kube-flannel-ds-2cxkf kube-flannel-ds-hml7r
pod "kube-flannel-ds-2cxkf" deleted
pod "kube-flannel-ds-hml7r" deleted
[root@vm172-16-0-202 ~]# kubectl get no -o yaml | grep flannel
      flannel.alpha.coreos.com/backend-data: '{"VNI":1,"VtepMAC":"de:87:3d:b7:74:fc"}'
      flannel.alpha.coreos.com/backend-type: vxlan
      flannel.alpha.coreos.com/kube-subnet-manager: "true"
      flannel.alpha.coreos.com/public-ip: 172.16.0.104
      - reg.xxx.lan:5000/xxx/flannel@sha256:13cddb14533a10394aa9436bd96a4c866a139b7ef01e71526aae013e724acca7
      - flannel/flannel:v0.25.4
      - reg.xxx.lan:5000/xxx/flannel:v0.25.4
      - reg.xxx.lan:5000/xxx/flannel-cni-plugin@sha256:85aa4c338969e97b1ab751fdc2c167af228a241a224e2d0e5b81ca0f3e93e1fa
      - flannel/flannel-cni-plugin:v1.4.1-flannel1
      - reg.xxx.lan:5000/xxx/flannel-cni-plugin:v1.4.1
      flannel.alpha.coreos.com/backend-data: '{"VNI":1,"VtepMAC":"f6:12:96:a0:5a:14"}'
      flannel.alpha.coreos.com/backend-type: vxlan
      flannel.alpha.coreos.com/kube-subnet-manager: "true"
      flannel.alpha.coreos.com/public-ip: 172.16.0.202
      - reg.xxx.lan:5000/xxx/flannel@sha256:13cddb14533a10394aa9436bd96a4c866a139b7ef01e71526aae013e724acca7
      - flannel/flannel:v0.25.4
      - reg.xxx.lan:5000/xxx/flannel:v0.25.4
      - reg.xxx.lan:5000/xxx/flannel-cni-plugin@sha256:85aa4c338969e97b1ab751fdc2c167af228a241a224e2d0e5b81ca0f3e93e1fa
      - flannel/flannel-cni-plugin:v1.4.1-flannel1
      - reg.xxx.lan:5000/xxx/flannel-cni-plugin:v1.4.1
      flannel.alpha.coreos.com/backend-data: '{"VNI":1,"VtepMAC":"1e:24:24:5e:b8:84"}'
      flannel.alpha.coreos.com/backend-type: vxlan
      flannel.alpha.coreos.com/kube-subnet-manager: "true"
      flannel.alpha.coreos.com/public-ip: 172.16.0.231
      - reg.xxx.lan:5000/xxx/flannel@sha256:13cddb14533a10394aa9436bd96a4c866a139b7ef01e71526aae013e724acca7
      - flannel/flannel:v0.25.4
      - reg.xxx.lan:5000/xxx/flannel:v0.25.4
      - reg.xxx.lan:5000/xxx/flannel-cni-plugin@sha256:85aa4c338969e97b1ab751fdc2c167af228a241a224e2d0e5b81ca0f3e93e1fa
      - flannel/flannel-cni-plugin:v1.4.1-flannel1
      - reg.xxx.lan:5000/xxx/flannel-cni-plugin:v1.4.1
      flannel.alpha.coreos.com/backend-data: '{"VNI":1,"VtepMAC":"36:a5:28:4d:ec:e3"}'
      flannel.alpha.coreos.com/backend-type: vxlan
      flannel.alpha.coreos.com/kube-subnet-manager: "true"
      flannel.alpha.coreos.com/public-ip: 172.16.0.250

剩下几个 node 处理后：

[root@vm172-16-0-202 ~]# ip r s
default via 172.16.0.1 dev eth0 proto dhcp metric 100 
10.97.0.0/24 via 10.97.0.0 dev flannel.1 onlink 
10.97.1.0/24 via 10.97.1.0 dev flannel.1 onlink 
10.97.2.0/24 via 172.16.0.250 dev eth0 
10.97.2.0/24 dev cni0 proto kernel scope link src 10.97.2.1 
10.97.3.0/24 via 10.97.3.0 dev flannel.1 onlink 
10.185.0.0/16 dev docker0 proto kernel scope link src 10.185.0.1 linkdown 
10.187.0.0/24 via 172.16.0.250 dev eth0 
10.187.2.0/24 via 172.16.0.104 dev eth0 
10.187.3.0/24 via 172.16.0.231 dev eth0 
172.16.0.0/24 dev eth0 proto kernel scope link src 172.16.0.202 metric 100

重启后也没问题

[root@vm172-16-0-202 ~]# ip r
default via 172.16.0.1 dev eth0 proto dhcp metric 100 
10.97.0.0/24 via 10.97.0.0 dev flannel.1 onlink 
10.97.1.0/24 via 10.97.1.0 dev flannel.1 onlink 
10.97.2.0/24 dev cni0 proto kernel scope link src 10.97.2.1 
10.97.3.0/24 via 10.97.3.0 dev flannel.1 onlink 
10.185.0.0/16 dev docker0 proto kernel scope link src 10.185.0.1 linkdown 
172.16.0.0/24 dev eth0 proto kernel scope link src 172.16.0.202 metric 100

询问了是不是有人最开始部署改过模式了，说没有，奇怪了。

私有化下(CentOS 7)Podman调研

2025-08-06T10:10:30.000Z

CentOS 7 上 Podman调研…..

由来

内部需要调研 podman 替换掉 docker，因为我们私有化要适配很多操作系统（很多客户内部规定了必须使用啥系统，所以要支持），使用最常见的 CentOS 7：

$ cat /etc/redhat-release 
CentOS Linux release 7.8.2003 (Core)
$ uname -a
Linux xxx 3.10.0-1127.el7.x86_64 #1 SMP Tue Mar 31 23:36:51 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

过程

离线安装

官方安装文档上并没有 centos7 的安装，因为已经 EOL 好几年。考虑到客户会无网，需要类似 docker-static 那样，搜索谷歌和 github 找到 podman-static。podman 最新版本是v5，下载 v5.5.2 的压缩包后解压。

daemon 进程相关

因为我们还需要调用 API，所以需要起 daemon 进程监听 socket 和 tcp，需要以下：

$ podman system service -h
Run API service

Description:
  Run an API service

Enable a listening service for API access to Podman commands.


Usage:
  podman system service [options] [URI]

Examples:
  podman system service --time=0 unix:///tmp/podman.sock
  podman system service --time=0 tcp://localhost:8888

Options:
      --cors string   Set CORS Headers
  -t, --time uint     Time until the service session expires in seconds.  Use 0 to disable the timeout (default 5)

发现无法同时监听 tcp 和 socket，并且 tcp 不支持tls选项，搜索issue Support (m)TLS API socket发现暂未支持，只能使用 socket 监听。

然后发现无法监听指定路径 socket文件：

1	API service listening on \"/run/podman/podman.sock\". URI: \"unix:///var/run/docker.sock\""

查阅 podman 源码，发现走到以下逻辑：

// https://github.com/containers/podman/blob/v5.5.2/cmd/podman/system/service_abi.go#L58-L77
        switch uri.Scheme {
        case "unix":
            path, err := filepath.Abs(uri.Path)
            if err != nil {
                return err
            }
            if os.Getenv("LISTEN_FDS") != "" {
                // If it is activated by systemd, use the first LISTEN_FD (3)
                // instead of opening the socket file.
                f := os.NewFile(uintptr(3), "podman.sock")
                listener, err = net.FileListener(f)
                if err != nil {
                    return err
                }
            } else {
                listener, err = net.Listen(uri.Scheme, path)
                if err != nil {
                    return fmt.Errorf("unable to create socket: %w", err)
                }
            }

通过查看 env 发现确实有 LISTEN_FDS 的 env：

$ xargs -n1 -0 < /proc/$(pgrep podman)/environ
LANG=zh_CN.UTF-8
PATH="/data/kube/bin:/bin:/sbin:/usr/bin:/usr/sbin"
LISTEN_PID=9047
LISTEN_FDS=1
LOGGING="--log-level=info"

看了下代码说明，是支持 systemd 的 socket 主动激活，我们不需要，去掉压缩包里的:

system/podman.socket
system/podman.service 内 require和 after podman.socket

然后启动可行：

1	API service listening on "/var/run/docker.sock". URI: "unix:///var/run/docker.sock"

info 的 format 差异

我们使用到了部分 info 里的 format 存在差异：

'{{.OSType}}' -> '{{.Host.OS}}'
'{{.DockerRootDir}}' -> '{{.Store.GraphRoot}}'

非 host 网络容器

部署后发现无法启动非 host 网络容器：

1
2

$ docker run --name registry_pass --entrypoint htpasswd registry:2.7.1
Error: creating network namespace for container 3de0fd230fd7693a107de4b56e5ab1444a558ae1e835e78e292ed364915a6362: failed to create namespace: failed to bind mount ns at /run/netns/netns-b0f807fe-e630-3182-e16b-5b5837e2b1a3: no such file or directory

golang 代码的 Error 是信息叠加的，所以可以直接搜索报错 creating network namespace for container ，找到报错代码：

// https://github.com/containers/podman/blob/v5.5.2/libpod/networking_linux.go#L77-L81
func (r *Runtime) createNetNS(ctr *Container) (n string, q map[string]types.StatusBlock, retErr error) {
    ctrNS, err := netns.NewNS()
    if err != nil {
        return "", nil, fmt.Errorf("creating network namespace for container %s: %w", ctr.ID(), err)
    }

跳转到 netns.NewNS() 内：

func NewNS() (ns.NetNS, error) {
    nsRunDir, err := GetNSRunDir()
    if err != nil {
        return nil, err
    }

    // Create the directory for mounting network namespaces
    // This needs to be a shared mountpoint in case it is mounted in to
    // other namespaces (containers)
    err = makeNetnsDir(nsRunDir)
    if err != nil {
        return nil, err
    }

    for range 10000 {
        nsName, err := getRandomNetnsName()
        if err != nil {
            return nil, err
        }
        nsPath := path.Join(nsRunDir, nsName)
        ns, err := newNSPath(nsPath)
        if err == nil {
            return ns, nil
        }
        // retry when the name already exists
        if errors.Is(err, os.ErrExist) {
            continue
        }
        return nil, err
    }
    return nil, errNoFreeName
}

是那行 makeNetnsDir() 报错，内部都是基础的文件和 ns mount 操作：

func makeNetnsDir(nsRunDir string) error {
    err := os.MkdirAll(nsRunDir, 0o755)
    if err != nil {
        return err
    }
    // Important, the bind mount setup is racy if two process try to set it up in parallel.
    // This can have very bad consequences because we end up with two duplicated mounts
    // for the netns file that then might have a different parent mounts.
    // Also because as root netns dir is also created by ip netns we should not race against them.
    // Use a lock on the netns dir like they do, compare the iproute2 ip netns add code.
    // https://github.com/iproute2/iproute2/blob/8b9d9ea42759c91d950356ca43930a975d0c352b/ip/ipnetns.c#L806-L815

    dirFD, err := unix.Open(nsRunDir, unix.O_RDONLY|unix.O_DIRECTORY|unix.O_CLOEXEC, 0)
    if err != nil {
        return &os.PathError{Op: "open", Path: nsRunDir, Err: err}
    }
    // closing the fd will also unlock so we do not have to call flock(fd,LOCK_UN)
    defer unix.Close(dirFD)

    err = unix.Flock(dirFD, unix.LOCK_EX)
    if err != nil {
        return fmt.Errorf("failed to lock %s dir: %w", nsRunDir, err)
    }

    // Remount the namespace directory shared. This will fail with EINVAL
    // if it is not already a mountpoint, so bind-mount it on to itself
    // to "upgrade" it to a mountpoint.
    err = unix.Mount("", nsRunDir, "none", unix.MS_SHARED|unix.MS_REC, "")
    if err == nil {
        return nil
    }
    if err != unix.EINVAL {
        return fmt.Errorf("mount --make-rshared %s failed: %q", nsRunDir, err)
    }

    // Recursively remount /run/netns on itself. The recursive flag is
    // so that any existing netns bindmounts are carried over.
    err = unix.Mount(nsRunDir, nsRunDir, "none", unix.MS_BIND|unix.MS_REC, "")
    if err != nil {
        return fmt.Errorf("mount --rbind %s %s failed: %q", nsRunDir, nsRunDir, err)
    }

    // Now we can make it shared
    err = unix.Mount("", nsRunDir, "none", unix.MS_SHARED|unix.MS_REC, "")
    if err != nil {
        return fmt.Errorf("mount --make-rshared %s failed: %q", nsRunDir, err)
    }

    return nil
}

下载代码后编译 podman 调试看看 makeNetnsDir() 具体哪个步骤出问题，发现无法跳到断点：

$ dlv exec bin/podman --  run  -ti --entrypoint ls docker.io/library/registry:2.7.1
Type 'help' for list of commands.
(dlv) b libpod/networking_linux.go:78
Breakpoint 1 set at 0x1555494 for github.com/containers/podman/v5/libpod.(*Runtime).createNetNS() ./libpod/networking_linux.go:78
(dlv) c
WARN[0000] Using cgroups-v1 which is deprecated in favor of cgroups-v2 with Podman v5 and will be removed in a future version. Set environment variable `PODMAN_IGNORE_CGROUPSV1_WARNING` to hide this warning. 
WARN[0000] The input device is not a TTY. The --tty and --interactive flags might not work properly 
received SIGINT, stopping process (will not forward signal)
> runtime.futex() /usr/local/go/src/runtime/sys_linux_amd64.s:558 (PC: 0x492243)
Warning: debugging optimized function
   553:        MOVQ    ts+16(FP), R10
   554:        MOVQ    addr2+24(FP), R8
   555:        MOVL    val3+32(FP), R9
   556:        MOVL    $SYS_futex, AX
   557:        SYSCALL
=> 558:        MOVL    AX, ret+40(FP)

然后发现 podman info 也卡住：

1
2
3

$ bin/podman  info
WARN[0000] Using cgroups-v1 which is deprecated in favor of cgroups-v2 with Podman v5 and will be removed in a future version. Set environment variable `PODMAN_IGNORE_CGROUPSV1_WARNING` to hide this warning. 
^C

看了下 podman info 调用链，调试了下发现：

(dlv) n
> github.com/containers/podman/v5/libpod.(*Runtime).hostInfo() ./libpod/info.go:106 (PC: 0x21d942e)
   101:        cpuUtil, err := getCPUUtilization()
   102:        if err != nil {
   103:            return nil, err
   104:        }
   105:    
=> 106:        locksFree, err := r.lockManager.AvailableLocks()
   107:        if err != nil {
   108:            return nil, fmt.Errorf("getting free locks: %w", err)
   109:        }
   110:    
   111:        info := define.HostInfo{
(dlv) n

看了下代码是卡在 cgo 的 shm lock 那里，无法调试找到网络ns创建问题。

v4版本尝试

v4 已经不维护，官方主干版本是 v5，尝试下载了最新的v4 v4.9.5 启动报错不支持：

1 2	$ podman run --entrypoint ls alpine:latest Error: netavark: create veth pair: Netlink error: Not supported (os error 95)

对于v5和v4的报错均搜索到类似的问题:

centos7的3.10内核不满足最低的4.18

结论

podman 现阶段不支持 tls，并且 socket 和 tcp 无法同时监听，安全问题只能使用 socket 文件，无法远程管理
私有化需要支持众多操作系统下，内核版本跨度从老到新都有，无法使用 podman，如果不是私有化自己单一环境且有网的情况下，可以使用

python grpc 使用域名第一次耗时长问题

2025-07-29T17:40:30.000Z

最近给同事解决的 python grpc 耗时长问题…..

由来

昨天上着班突然被群里拉到一个开发任务群里，看了下聊天记录说啥慢，询问了下理清了流程：

 client    server1   model server
┌──┐        ┌──┐        ┌──┐ 
└┬─┘        └┬─┘        └─┬┘ 
 ├───http───►│            │  
 │           ├───grpc────►│  
 │           │◄──grpc─────┤  
 │◄───http───┤            │

http 客户端请求服务1，带了模型服务的 model_url，server1 会 grpc 请求 model_url，然后发现回复非常慢，把 ai-xxx 换成实际的外部 IP 就会很快。

curl --location 'http://xxxx:8870/chat' \
    --header 'Content-Type: application/json' \
    --data '{
        "stream": true,
        "messages_type": 1,
        "title": "人工智能",
        "inspiration": "文风严谨，语言简洁凝练",
        "model_config": {
            "default": true,
            "type": "xxxx",
            "model_url": "ai-xxx",
            "model_name": "xxxxx-xxxx",
            "model": "xxxxx"
        }
    }'

环境上测了下果然是，server1 的访问日志看有 9s 左右耗时，看了下环境是 k8s， ai-xxx 是直接创建的 svc 和 ep，endpoint 为外部一个模型服务的 ip 端口。看了下 server1 内的 /etc/nsswitch 正常：

1 2	$ grep hosts /etc/nsswitch.conf hosts: files dns

加了下 hosts 测下还是每次都必现，可以肯定和 k8s dns 无关了，如果是 k8s dns 5s timeout 问题，那是 IPv6 的 AAAA 记录五元组冲突导致的超时的话都是偶现而非必现，和这个不一样。

解决过程

初步怀疑是研发的 server1 后端接口逻辑有问题，但是他们说有些环境正常有些不正常，于是我让他们给个最小的 python grpc client 访问模型的 demo。这样二分排除范围，不然两个链路不好查。没想到今天测试又催这个问题看得咋样了。然后让研发把 demo 发过来看。

demo 复现

拿到 demo 有点无语，这种耗时的打印居然是用的 print，手动修改成 logging 后测试复现了，大概逻辑如下：

server_urls = [
    "ai-xxx:80",
    "10.xx.xx.xxx:10037"
]

for server_url in server_urls:
    grpc_test()

拷贝到 server1 的容器里执行，发现必现，耗时久的附近是如下 35s - 43s：

2025-07-29 16:52:35 [INFO] 🔥 开始测试GRPC连接: ai-xxx:80
2025-07-29 16:52:35 [INFO] 📡 创建Triton客户端...
2025-07-29 16:52:35 [INFO] ✅ 客户端创建成功
2025-07-29 16:52:35 [INFO] 🔍 检查服务器状态...
2025-07-29 16:52:43 [INFO]    服务器存活: ✅
2025-07-29 16:52:43 [INFO]    服务器就绪: ✅
2025-07-29 16:52:43 [INFO] ✅ 服务器状态检查通过
...
2025-07-29 16:52:44 [INFO] 🔥 开始测试GRPC连接: 10.xx.xx.xxx:10037
2025-07-29 16:52:44 [INFO] 📡 创建Triton客户端...
2025-07-29 16:52:44 [INFO] ✅ 客户端创建成功
2025-07-29 16:52:44 [INFO] 🔍 检查服务器状态...
2025-07-29 16:52:44 [INFO]    服务器存活: ✅
2025-07-29 16:52:44 [INFO]    服务器就绪: ✅
2025-07-29 16:52:44 [INFO] ✅ 服务器状态检查通过

看了下 demo 代码对应位置：

triton_client = grpcclient.InferenceServerClient(
    url=server_url,
    verbose=False
)
logging.info("✅ 客户端创建成功")

# 2. 检查服务器状态
logging.info("🔍 检查服务器状态is_server_live")
is_live = triton_client.is_server_live()
logging.info("🔍 检查服务器状态is_server_ready")
is_ready = triton_client.is_server_ready()

python -m pdb grpc-test.py 调试了下，发现这个方法只是一个纯粹的 grpc 请求：

(Pdb) n
> /usr/local/lib/python3.10/site-packages/tritonclient/grpc/_client.py(294)is_server_live()
-> try:
(Pdb) list
289          InferenceServerException
290              If unable to get liveness or has timed out.
291  
292          """
293          metadata = self._get_metadata(headers)
294  ->        try:
295              request = service_pb2.ServerLiveRequest()
296              if self._verbose:
297                  print("is_server_live, metadata {}\n{}".format(metadata, request))
298              response = self._client_stub.ServerLive(
299                  request=request, metadata=metadata, timeout=client_timeout

grpc 客户端用的 tritonclient:

1 2	$ pip list \| grep client tritonclient 2.57.0

pypi 查了下这个 grpc 库发现找到的仓库 triton-inference-server/client 分支和上面版本号对不上，很奇怪。

谷歌搜了下 is_server_live long time 发现能搜到同样问题 is_server_live() python GRPC client got no response，但是别人用的是 IP ，后面还把 issue 关闭了说是他们自己的网络问题。

然后让研发找 is_server_live() 的 grpc server 端研发查下 ServerLive 接口调用逻辑，另一方面让 server1 研发把 is_server_live() 注释了试试，他说走 CI 流程会稍微慢些，让我看看环境上能直接改不，于是大家一起并行操作。

稍有眉目

发现环境改了后还是复现，于是我在 demo 里改了下发现慢在第二个了：

# 2. 检查服务器状态
logging.info("🔍 检查服务器状态is_server_live")
# is_live = triton_client.is_server_live()
logging.info("🔍 检查服务器状态is_server_ready")
# is_ready = triton_client.is_server_ready()

# logging.info(f"   服务器存活: {'✅' if is_live else '❌'}")
# logging.info(f"   服务器就绪: {'✅' if is_ready else '❌'}")

# if not is_live:
#     raise Exception("服务器未存活")
# if not is_ready:
#     raise Exception("服务器未就绪")

logging.info("✅ 服务器状态检查通过")

# 3. 获取模型信息
logging.info("📋 获取模型信息...")
try:
    model_metadata = triton_client.get_model_metadata("xxxxx")

2025-07-29 17:32:32 [INFO] ✅ 客户端创建成功
2025-07-29 17:32:32 [INFO] 🔍 检查服务器状态is_server_live
2025-07-29 17:32:32 [INFO] 🔍 检查服务器状态is_server_ready
2025-07-29 17:32:32 [INFO] ✅ 服务器状态检查通过
2025-07-29 17:32:32 [INFO] 📋 获取模型信息...
2025-07-29 17:32:40 [INFO] ✅ 成功获取模型元数据
2025-07-29 17:32:40 [INFO]    模型名称: xxxx
2025-07-29 17:32:40 [INFO]    模型版本: ['1']
2025-07-29 17:32:40 [INFO] 🧠 执行简单推理测试...
2025-07-29 17:32:40 [INFO] ✅ 流启动成功
2025-07-29 17:32:40 [INFO] ✅ 推理请求发送成功
2025-07-29 17:32:40 [INFO] ⏳ 等待响应...
2025-07-29 17:32:40 [INFO] ✅ 收到成功响应
2025-07-29 17:32:40 [INFO]    输出tokens: [9]
2025-07-29 17:32:40 [INFO] 🎉 GRPC连接测试完全成功!
2025-07-29 17:32:40 [INFO] 🎉 务器 ai-xxx:80 测试成功!

这次不是前面的 is_server_live() 问题，仔细看了下代码想了下是 grpcclient 的第一个 grpc 请求有问题导致耗时长，搜索了下发现一样相似但是更耗时的问题：

https://github.com/triton-inference-server/server/issues/1821

不过上面 issue 里 triton 官方说是 grpc/grpc 的问题，搜到 Communication from c++ server to python client is too slow 说 python 很慢但是 c++ 的不慢，python 的首次 grpc 建立连接耗时很长，后续的请求都在 ms 内完成。issue 内下面大佬排查出耗时大部分开销都是在 libc 相关调用上。

众所周知，grpc 是长连接后推流，让研发要不要改代码写成连接池试试，他们说来不及。

感觉既然和 triton 无关，就搜 python grpc dns first time long 搜到了 Python client hangs on first connection 类似问题，排查和 DNS 相关，发现大佬说试试 GRPC_DNS_RESOLVER=native ，搜了下 grpc/grpc 官方文档：

* GRPC_DNS_RESOLVER
  Declares which DNS resolver to use. The default is ares if gRPC is built with
  c-ares support. Otherwise, the value of this environment variable is ignored.
  Available DNS resolver include:
  - ares (default on most platforms except iOS, Android or Node)- a DNS
    resolver based around the c-ares library
  - native - a DNS resolver based around getaddrinfo(), creates a new thread to
    perform name resolution

默认是 c 的库 c-ares 去解析的，设置为 native 则使用系统 libc 的 getaddrinfo() ，于是测试了下可以：

$ GRPC_DNS_RESOLVER=native python3  /root/test2.py 
2025-07-29 17:59:43 [INFO] ✅ tritonclient导入成功
2025-07-29 17:59:43 [INFO] ============================================================
2025-07-29 17:59:43 [INFO] 🚀 GRPC连接测试工具
2025-07-29 17:59:43 [INFO] ============================================================
2025-07-29 17:59:43 [INFO] 
📍 测试服务器: ai-xxx:80
2025-07-29 17:59:43 [INFO] ----------------------------------------
2025-07-29 17:59:43 [INFO] 🔍 测试DNS解析: ai-xxx:80
2025-07-29 17:59:43 [INFO] ✅ DNS解析成功: ai-xxx -> 10.186.44.250:80
2025-07-29 17:59:43 [INFO] 🔥 开始测试GRPC连接: ai-xxx:80
2025-07-29 17:59:43 [INFO] 📡 创建Triton客户端...
2025-07-29 17:59:43 [INFO] ✅ 客户端创建成功
2025-07-29 17:59:43 [INFO] 🔍 检查服务器状态is_server_live
2025-07-29 17:59:44 [INFO] 🔍 检查服务器状态is_server_ready
2025-07-29 17:59:44 [INFO]    服务器存活: ✅
2025-07-29 17:59:44 [INFO]    服务器就绪: ✅
2025-07-29 17:59:44 [INFO] ✅ 服务器状态检查通过
2025-07-29 17:59:44 [INFO] 📋 获取模型信息...
2025-07-29 17:59:44 [INFO] ✅ 成功获取模型元数据
2025-07-29 17:59:44 [INFO]    模型名称: xxxx
2025-07-29 17:59:44 [INFO]    模型版本: ['1']
2025-07-29 17:59:44 [INFO] 🧠 执行简单推理测试...
2025-07-29 17:59:44 [INFO] ✅ 流启动成功
2025-07-29 17:59:44 [INFO] ✅ 推理请求发送成功

golang gitlab subgroup 构建问题

2025-06-17T14:40:30.000Z

最近给同事解决的 subgroup 问题…..

由来

开发构建 Docker 镜像报错没权限拉取依赖：

xxxapi/middlewares imports
xxx.xxxgitlab.net/x/xx/xxx/econtext: xxx.xxxgitlab.net/x/xx/xxx@v1.6.5-rc.7.0.20250609085545-4855369c0f1e: invalid version: git ls-remote -q origin in /go/pkg/mod/cache/vcs/672638ca2205d3f2cdc0288db28840b769e58250b95fbbd31e553c6c8076fc3c: exit status 128:
remote: 
remote: ========================================================================
remote: 
remote: The project you were looking for could not be found or you don't have permission to view it.
remote: 
remote: ========================================================================
remote: 
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

解决过程

镜像内有 gitlab 的 deploy keys，初步怀疑是没依赖仓库权限，让开发联系该依赖仓库负责人，去开启 Enabled deploy keys 后还是一样。

手动构建测试

登录到构建机器上，docker build 实际就是按照 Dockerfile 来 docker run 和 docker commit 的结合，找到失败的 run 的镜像 id：

1 2	$ docker ps -a b7c4be99d86d ba54b82c5b1c "/bin/sh -c 'IN_DOCK…" 4 hours ago Exited (1) 1 hours ago nervous_chandrasekhar

用上面的镜像 ID 和 command 手动测下：

1
2
3

$ docker run --rm -ti --entrypoint bash ba54b82c5b1c
root@a9114c46d496:/go/src/xxx.xxxgitlab.net/xxxxx/# IN_DOCKER=1 bash ./build.sh
...

报错依旧，GOPRIVATE GONOPROXY 啥的都配置了的，以及 ssh 相关 git config --global url."git@xxx.xxxgitlab.net:".insteadof "https://xxx.xxxgitlab.net/"都是以及配置了没问题的：

1
2
3

$ cat ~/.gitconfig
[url "git@xxx.xxxgitlab.net:"]
insteadof = https://xxx.xxxgitlab.net/

用 git 测试也没问题：

$ ssh -T git@xxx.xxxgitlab.net
Welcome to GitLab, @xxxx_reporter!
$ git clone xxx.xxxgitlab.net/x/xx/xxx
...

看了下 go 的 help ，发现 go mod 没有 debug level 相关 cmdline，但是 go get 有：

$ go get -x  xxx.xxxgitlab.net/x/xx/xxx
# get https://xxx.xxxgitlab.net/x/xx/xxx?go-get=1
# get https://xxx.xxxgitlab.net/x/xx/xxx?go-get=1: 200 OK (0.063s)
# get https://xxx.xxxgitlab.net/docmxini/xx?go-get=1
# get https://xxx.xxxgitlab.net/x/xx?go-get=1: 200 OK (0.016s)
mkdir -p /go/pkg/mod/cache/vcs # git3 https://xxx.xxxgitlab.net/x/xx.git
# lock /go/pkg/mod/cache/vcs/672638ca2205d3f2cdc0288db28840b769e58250b95fbbd31e553c6c8076fc3c.lock
# /go/pkg/mod/cache/vcs/672638ca2205d3f2cdc0288db28840b769e58250b95fbbd31e553c6c8076fc3c for git3 https://xxx.xxxgitlab.net/x/fx.git
cd /go/pkg/mod/cache/vcs/672638ca2205d3f2cdc0288db28840b769e58250b95fbbd31e553c6c8076fc3c; git -c log.showsignature=false log --no-decorate -n1 '--format=format:%H %ct %D' 4855369c0f1e --
0.002s # cd /go/pkg/mod/cache/vcs/672638ca2205d3f2cdc0288db28840b769e58250b95fbbd31e553c6c8076fc3c; git -c log.showsignature=false log --no-decorate -n1 '--format=format:%H %ct %D' 4855369c0f1e --
cd /go/pkg/mod/cache/vcs/672638ca2205d3f2cdc0288db28840b769e58250b95fbbd31e553c6c8076fc3c; git ls-remote -q origin
0.232s # cd /go/pkg/mod/cache/vcs/672638ca2205d3f2cdc0288db28840b769e58250b95fbbd31e553c6c8076fc3c; git ls-remote -q origin
# get https://xxx.xxxgitlab.net/x/xx.git
# get https://xxx.xxxgitlab.net/x/xx.git: 200 OK (0.076s)
cd /go/pkg/mod/cache/vcs/672638ca2205d3f2cdc0288db28840b769e58250b95fbbd31e553c6c8076fc3c; git tag -l
0.002s # cd /go/pkg/mod/cache/vcs/672638ca2205d3f2cdc0288db28840b769e58250b95fbbd31e553c6c8076fc3c; git tag -l
go: xxx.xxxgitlab.net/x/xx/xxx@v1.6.5-rc.7.0.20250609085545-4855369c0f1e: invalid version: git ls-remote -q origin in /go/pkg/mod/cache/vcs/672638ca2205d3f2cdc0288db28840b769e58250b95fbbd31e553c6c8076fc3c: exit status 128:
remote: 
remote: ========================================================================
remote: 
remote: The project you were looking for could not be found or you don't have permission to view it.
remote: 
remote: ========================================================================
remote: 
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

上面最后的命令报错，cd 进去执行下看看：

$ cd /go/pkg/mod/cache/vcs/672638ca2205d3f2cdc0288db28840b769e58250b95fbbd31e553c6c8076fc3c
$ git ls-remote
remote: 
remote: ========================================================================
remote: 
remote: The project you were looking for could not be found or you don't have permission to view it.
remote: 
remote: ========================================================================
remote: 
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

其实前面的 go get -x 里就有问题详细信息了，这里我是看目录下文件发现的：

$ ls -al
total 28
drwxr-xr-x  7 root root  119 Jun 17 03:53 .
drwxr-xr-x 20 root root 8192 Jun 17 03:53 ..
-rw-r--r--  1 root root   23 Jun 17 03:53 HEAD
drwxr-xr-x  2 root root    6 Jun 17 03:53 branches
-rw-r--r--  1 root root  179 Jun 17 03:53 config
-rw-r--r--  1 root root   73 Jun 17 03:53 description
drwxr-xr-x  2 root root 4096 Jun 17 03:53 hooks
drwxr-xr-x  2 root root   21 Jun 17 03:53 info
drwxr-xr-x  4 root root   30 Jun 17 03:53 objects
drwxr-xr-x  4 root root   31 Jun 17 03:53 refs
$ cat config
[core]
repositoryformatversion = 0
filemode = true
bare = true
[remote "origin"]
url = https://xxx.xxxgitlab.net/x/xx.git
fetch = +refs/heads/*:refs/remotes/origin/*

仓库地址不对，改成 url = https://xxx.xxxgitlab.net/x/xx/xxx.git 后就可以了：

$ git ls-remote | head
From git@xxx.xxxgitlab.net:x/xx/xxx.git
74f35a28ecc0f9721a49c41fb5d7bffa071d1502HEAD
295c3a79dfc0d27022459d0cec21411031edd5e8refs/heads/0xxx
...

gitlab subgroup

搜了下，发现是 gitlab 的鉴权和 golang 的 get 逻辑冲突，双方都认为对方不规范，谁都不让谁，具体见文章:

解决方案只有两种，一种是 ~/.netrc 但是是明文密码，不适用于 CI/CD 构建。
使用 replace 的话需要指定一样的版本，而 go get 升级依赖的时候 replace 不会动。
写 shell 在 go build 前执行的话，怕正则边界和模糊匹配到了前缀一样的，并且 go mod edit -json 可以输出 json 信息，好在 golang 编译镜像是 ubuntu，内部有 python。

脚本解决

花了点时间写了如下 python 脚本，执行方式如下：

go mod edit -json | python3 scripts/golang-subgroup.py \
  --repo xxx.xxxgitlab.net/x/xx/xxx \
  --repo xxx.xxxgitlab.net/x/xx/xxx2

# 或者
go mod edit -json > go.mod.json
python3 scripts/golang-subgroup.py \
  --repo xxx.xxxgitlab.net/x/xx/xxx \
  --repo xxx.xxxgitlab.net/x/xx/xxx2

# -*- coding: utf-8 -*-

import argparse
import sys
import os
import json
import logging

def parse_args():
    parser = argparse.ArgumentParser(description='解决 go.mod 里的 gitlab subgroups 问题')
    parser.add_argument('--repo', action='append', help='要处理的仓库名字，例如: xx.gitlab.cn/a/b/c')
    parser.add_argument('--mod', default="./go.mod", help='go.mod path')
    return parser.parse_args()

def replace_repo(repo_list, mod_json, mod_path):
    if mod_json['Replace']:
        mod_replace_list = [ i['Old']['Path'] for i in mod_json['Replace']]
        repo_list = [repo for repo in repo_list if repo not in mod_replace_list]
        if len(repo_list) == 0:
            logging.info("已经全部替换")
            return

    replace_list = [ i for i in mod_json['Require'] if i['Path'] in repo_list and (not i.get('Indirect', False))]
    if len(replace_list) == 0:
        logging.error("未找到需要替换的仓库: %s", ','.join(repo_list))
        return
    with open(mod_path, 'a', encoding='utf-8') as f:
        for item in replace_list:
            replace_str = "replace {0} => {0}.git {1}".format(item['Path'], item['Version'])
            logging.info("添加 %s", replace_str)
            f.writelines(replace_str+'\n')

def main():
    logging.basicConfig(level=logging.INFO, format='%(asctime)s - %(levelname)s - %(message)s')
    args = parse_args()
    if args.repo is None or len(args.repo) == 0:
        return

    mod_json = {}
    mod_json_path = "go.mod.json"
    if os.isatty(0):
        if not os.path.isfile(mod_json_path):
            logging.error("请以 go mod edit -json | python3 %s 运行", __file__)
            os._exit(2)
        with open(mod_json_path, 'r') as file:
            mod_json = json.load(file)
    else:
        mod_json = json.loads(sys.stdin.read())

    
    if (not isinstance(mod_json, dict)) or mod_json.get("Module", "") == "":
        logging.error("请以 go mod edit -json | python3 %s 运行", __file__)
        os._exit(2)
    replace_repo(args.repo, mod_json, args.mod)

if __name__ == "__main__":
    main()

小白向的 kubernetes 证书讲解

2025-06-02T20:40:30.000Z

最近同事遇到几起证书相关问题，从小白角度来写下 k8s 证书…..

由来

很多人对 k8s 证书和 kubeconfig 望而却步，证书过期和相关报错就无从下手，市面上有写证书的文章博客，但是感觉很长的理论会让很多人看不下去，实际更需要的是解决问题时候的具体步骤和方向。

理论部分

简单讲解证书理论部分。

双向 SSL

访问一个 https 网站，需要目标 web server 配置有 ssl 证书，而证书来源两种：

CA（证书颁发机构）使用私钥签署出根 CA 证书（公钥），浏览器和操作系统内置这些根 CA 证书，只有 CA 机构签署的证书才会是绿锁。
使用证书工具或者遵守证书规范的库生成的 CA 私钥自己签署出的证书，浏览器显示红色警告（连接不安全/无效证书）

k8s 采用的是基于 X.509 V3 标准的双向 SSL，客户端和服务端通信，都会验证双方证书，根据双方是否是一样的 CA 签署的证书，而 CA 私钥是自己生成的，你可以看到 k8s 组件的 cmdline 都有指定参数 ca-file|cert-file 相关。

证书建议相关

时间

无论是 openssl 还是 cfssl，推荐都把过期时间设置高一些：

$ openssl req -x509 ... -days 10000
$ cat ca-config.json
...
  "expiry": "876000h"

而对于 kubeadm，网上有修改编译的，或者 go build 的时候注入覆盖默认的时间的，自行搜索。

certSAN

k8s 里 kube-apiserver 和 etcd 都是部署在多个机器上实现高可用的，在 openssl/cfssl/kubeadm 里推荐加 IP 以外还要加域名以防后续换 IP 相关：

openssl 配置文件参考 kubernetes-sigs/kubespray 的 openssl.conf
cfssl 使用的 json 文件里的 hosts 字段
kubeadm 的 certSANs 字段

这里以 ipv4 下 kubeadm 的指定 yml 创建集群来举例一般写那些：

$ cat initconfig.yaml
apiServer:
  certSANs:
  - 10.96.0.1 # service cidr的第一个ip
  - 127.0.0.1 # 多个master的时候负载均衡出问题了能够快速使用localhost调试
  - localhost
  - apiserver.k8s.local # 负载均衡的域名或者vip
  - 172.19.0.2 # 三台 kube-apiserver 的 IP
  - 172.19.0.3
  - 172.19.0.4
  - apiserver01.k8s.local 
  - apiserver02.k8s.local
  - apiserver03.k8s.local
  - apiserver04.k8s.local # 预留域名
  - apiserver05.k8s.local
  - master
  - kubernetes
  - kubernetes.default
  - kubernetes.default.svc
  - kubernetes.default.svc.cluster.local # 集群内 dns search 和 clusterDomain
...
etcd: # https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta2#Etcd
  local:
    serverCertSANs:
    - localhost
    - 127.0.0.1
    - 172.19.0.2
    - 172.19.0.3
    - 172.19.0.4
    - etcd01.k8s.local
    - etcd02.k8s.local
    - etcd03.k8s.local
    - etcd04.k8s.local # 预留域名
    - etcd05.k8s.local
    peerCertSANs:
    - localhost
    - 127.0.0.1
    - 172.19.0.2
    - 172.19.0.3
    - 172.19.0.4
    - etcd01.k8s.local
    - etcd02.k8s.local
    - etcd03.k8s.local
    - etcd04.k8s.local # 预留域名
    - etcd05.k8s.local

上面只列举 IPv4 的，如果后续有双栈啥的可以预先写上，如果写漏了域名和 IP，管理组件或者 pod 内通过 SDK 访问 kube-apiserver 的时候会报错：

1	Unable to connect to the server: tls: failed to verify certificate: x509: certificate is valid for 10.96.0.1, yyyy, not xxxx

也就是证书的 certSANs 只有 10.96.0.1, yyyy 而没有 xxxx，可以使用原有 CA 证书签署下。命令行查看证书的 certSAN 可以使用 openssl ，编程语言的话推荐去使用库：

# 一般会把证书放在 /etc/kubernetes/pki 找不到的找 apiserver cmdline 参数路径
$ openssl x509 -noout -text -in apiserver.crt
X509v3 Subject Alternative Name:
                DNS:localhost, DNS:kubernetes, DNS:kubernetes.default, DNS:kubernetes.default.svc, DNS:kubernetes.default.svc.cluster.local, IP Address:10.96.0.1, IP Address: 172.19.0.2

openssl 上面的输出里很多信息，还包含证书过期时间，而且 openssl x509 下很多选项的：

# 利用 -certopt 和 -text 配合只打印 certSANs
openssl x509 -noout  -in apiserver.crt  -certopt no_subject,no_header,no_version,no_serial,no_signame,no_validity,no_issuer,no_pubkey,no_sigdump,no_aux -text

# 只查看证书时间
openssl x509 -noout  -in apiserver.crt -dates

# 只展示 subject
openssl x509 -noout  -in apiserver.crt  -subject

只有同一套 ca 签署证书才符合要求，可以使用 openssl 命令检查：

1
2
3

# 检查 apiserver.crt 是否是由 ca.key 签署
$ openssl verify -CAfile ca.crt apiserver.crt
apiserver.crt: OK

k8s role 和 RBAC

双向 TLS 过去了，但是具体权限控制 k8s 怎么做的呢，就是 X.509 证书签署（Subject 字段内）的 CN(Common Name) 与 O(Organization) 字段，对应 User Name 和 Group，也就是 k8s 的 RBAC：

$ kubectl get clusterrolebinding
NAME                                                   ROLE                                                                               AGE
cluster-admin                                          ClusterRole/cluster-admin                                                          81m
kubeadm:get-nodes                                      ClusterRole/kubeadm:get-nodes                                                      81m
kubeadm:kubelet-bootstrap                              ClusterRole/system:node-bootstrapper                                               81m
kubeadm:node-autoapprove-bootstrap                     ClusterRole/system:certificates.k8s.io:certificatesigningrequests:nodeclient       81m
kubeadm:node-autoapprove-certificate-rotation          ClusterRole/system:certificates.k8s.io:certificatesigningrequests:selfnodeclient   81m
kubeadm:node-proxier                                   ClusterRole/system:node-proxier                                                    81m
...
system:coredns                                         ClusterRole/system:coredns                                                         81m
system:discovery                                       ClusterRole/system:discovery                                                       81m
system:kube-controller-manager                         ClusterRole/system:kube-controller-manager                                         81m
system:kube-dns                                        ClusterRole/system:kube-dns                                                        81m
system:kube-scheduler                                  ClusterRole/system:kube-scheduler                                                  81m
system:monitoring                                      ClusterRole/system:monitoring                                                      81m
system:node                                            ClusterRole/system:node                                                            81m
system:node-proxier                                    ClusterRole/system:node-proxier                                                    81m
system:public-info-viewer                              ClusterRole/system:public-info-viewer                                              81m
system:service-account-issuer-discovery                ClusterRole/system:service-account-issuer-discovery                                81m
system:volume-scheduler                                ClusterRole/system:volume-scheduler                                                81m

kube-apiserver 启动后会创建上面的 clusterrolebinding，kubectl 本质就是个 client + kubeconfig 访问 kube-apiserver 的，查看 kubectl 当前使用的 kubeconfig 可以通过 k8s 所有二进制的 cmdline 的 -v 选项，从详细信息里获取：

1
2
3

$ kubectl config view -v=6
I0604 10:40:46.836786   14513 loader.go:395] Config loaded from file:  /root/.kube/config
...

可以从上面看到是 /root/.kube/config ，以 kubeadm 的举例，该文件内容内有证书内容：

$ cat /root/.kube/config
certificate-authority-data  /etc/kubernetes/pki/ca.crt 内容 base64 加密后的值
client-certificate-data     /etc/kubernetes/pki/admin.crt 内容 base64 加密后的值
client-key-data             /etc/kubernetes/pki/admin.key 内容 base64 加密后的值

上面后面俩已经内嵌了，所以文件不存在，但是也会有些人自建集群上面的后面值是路径，是因为 kubectl config 生成 kubeconfig 的时候没指定选项 --embed-certs，内嵌的步骤如下：

kubectl --kubeconfig /etc/kubernetes/admin.conf config set-credentials admin \
        --client-certificate=/etc/kubernetes/pki/admin.crt \
        --embed-certs=true \
        --client-key=/etc/kubernetes/pki/admin.key"
# rm -f /etc/kubernetes/pki/admin.???

kubeadm golang 直接没有落地文件，直接生成 yml 内容的，我们可以扣出证书信息看看

$ openssl x509 -in <(kubectl config view --raw -o jsonpath="{.users[0]['user']['client-certificate-data']}" | base64 -d ) -noout -text

$ openssl x509 -in <(kubectl config view --raw -o jsonpath="{.users[0]['user']['client-certificate-data']}" | base64 -d ) -noout  -subject
subject= /O=system:masters/CN=kubernetes-admin

我们可以看到 O=system:masters ，实际对应 clusterrolebinding cluster-admin 的信息：

$ kubectl get clusterrolebinding cluster-admin -o yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  creationTimestamp: "2025-06-03T07:36:44Z"
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: cluster-admin
  resourceVersion: "160"
  uid: d5638680-38de-4010-a2c9-084645a8ad21
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: cluster-admin
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:masters

也就是组 system:masters 具备 clusterrole cluster-admin 的权限。

本小结参考：

实战

说完理论部分，来实战下，利用证书的 CN(Common Name) 与 O(Organization) 字段来创建两个权限证书测试下：

用户 test1 具备 default ns 下的 pod list 权限
组 test2 具备所有 ns 的 pod list 权限

避免路径、证书名字和后缀和习惯问题，实战部分以 cfssl 在 kubeadm 初始化后的文件目录内操作。

对证书做操作之前要有备份习惯，无论证书损坏还是过期：

1 2	cd /etc/kubernetes cp -a pki pki.bak

创建证书

创建配置文件：

cd /etc/kubernetes/pki/

# 创建 ca 签署证书签名配置文件，因为该证书是只 client 使用，不需要在 usages 里带 "server auth"
# 如果所有证书手动生成时候用同一个 ca-config.json 可以偷懒带上 "server auth"

cat > ca-config.json << EOF
{
  "signing": {
    "default": {
      "expiry": "876000h"
    },
    "profiles": {
      "kubernetes": {
        "usages": [
            "signing",
            "key encipherment",
            "client auth"
        ],
        "expiry": "876000h"
      }
    }
  }
}
EOF

# cn 对应 user o 对应 group
cat > test1-csr.json << EOF
{
  "CN": "test1",
  "hosts": [],
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "O": "test1",
      "OU": "System"
    }
  ]
}
EOF

签署证书：

cfssl gencert \
        -ca=ca.crt \
        -ca-key=ca.key \
        -config=ca-config.json \
        -profile=kubernetes test1-csr.json | cfssljson -bare test1

测试证书权限：

# 避免 kubeconfig 干扰，改名下家目录文件
$ mv ~/.kube/config ~/.kube/config.bak
$ KUBECONFIG= kubectl --kubeconfig /dev/null --server=https://xxx:6443 \
  --certificate-authority=/etc/kubernetes/pki/ca.crt \
  --client-certificate=/etc/kubernetes/pki/test1.pem \
  --client-key=/etc/kubernetes/pki/test1-key.pem get pod
Error from server (Forbidden): pods is forbidden: User "test1" cannot list resource "pods" in API group "" in the namespace "default"

kube-apiserver 本质是 http/grpc server，我们也可以 curl 测下：

$ curl -X GET \
  --cacert /etc/kubernetes/pki/ca.crt \
  --cert /etc/kubernetes/pki/test1.pem \
  --key /etc/kubernetes/pki/test1-key.pem \
  -H "Accept: application/json" \
  "https://xxx:6443/api/v1/namespaces/default/pods?limit=500"
{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {},
  "status": "Failure",
  "message": "pods is forbidden: User \"test1\" cannot list resource \"pods\" in API group \"\" in the namespace \"default\"",
  "reason": "Forbidden",
  "details": {
    "kind": "pods"
  },
  "code": 403
}

因为我们没有创建 test1 的 RBAC ，也就是 rolebinding，创建下后再试试：

$ mv ~/.kube/config.bak ~/.kube/config
$ cat > test1-rbac.yml << EOF
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: test1-role
  namespace: default
rules:
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - get
  - list
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: test1-rolebinding
  namespace: default
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: test1-role
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: test1
EOF

$ kubectl apply -f test1-rbac.yml

然后再测试，可以列出 default 下的 pod 而不能列出 svc：

$ mv ~/.kube/config ~/.kube/config.bak
$ KUBECONFIG= kubectl --kubeconfig /dev/null --server=https://xxx:6443 \
  --certificate-authority=/etc/kubernetes/pki/ca.crt \
  --client-certificate=/etc/kubernetes/pki/test1.pem \
  --client-key=/etc/kubernetes/pki/test1-key.pem get pod
No resources found in default namespace.

$ KUBECONFIG= kubectl --server=https://xxx:6443   --certificate-authority=/etc/kubernetes/pki/ca.crt   --client-certificate=/etc/kubernetes/pki/test1.pem   --client-key=/etc/kubernetes/pki/test1-key.pem get svc
Error from server (Forbidden): services is forbidden: User "test1" cannot list resource "services" in API group "" in the namespace "default"

同样使用 curl 测下：

$ curl -X GET  \
  --cacert /etc/kubernetes/pki/ca.crt  \
  --cert /etc/kubernetes/pki/test1.pem  \
  --key /etc/kubernetes/pki/test1-key.pem  \
   -H "Accept: application/json"   "https://10.xxx.xx.xxx:6443/api/v1/namespaces/default/pods?limit=500"
{
  "kind": "PodList",
  "apiVersion": "v1",
  "metadata": {
    "resourceVersion": "107116"
  },
  "items": []
}

$ curl -X GET  \
  --cacert /etc/kubernetes/pki/ca.crt  \
  --cert /etc/kubernetes/pki/test1.pem  \
  --key /etc/kubernetes/pki/test1-key.pem  \
   -H "Accept: application/json"   "https://10.xxx.xx.xxx:6443/api/v1/namespaces/default/services?limit=500"
{
  "kind": "Status",
  "apiVersion": "v1",
  "metadata": {},
  "status": "Failure",
  "message": "services is forbidden: User \"test1\" cannot list resource \"services\" in API group \"\" in the namespace \"default\"",
  "reason": "Forbidden",
  "details": {
    "kind": "services"
  },
  "code": 403
}

可以看到证书权限符合预期，kubeconfig 里可以包含多个配置段的，前面的证书生成 kubeconfig 可以使用 kubectl ，按照下面步骤生成对应配置段：

# 设置集群参数，指定CA证书和apiserver地址
kubectl --kubeconfig=test1.kubeconfig config set-cluster kubernetes \
    --certificate-authority=/etc/kubernetes/pki/ca.crt \
    --embed-certs=true \
    --server=https://xxx:6443
        
# 设置客户端认证参数，指定使用证书和私钥
kubectl --kubeconfig=test1.kubeconfig config set-credentials test1 \
    --client-certificate=test1.pem \
    --embed-certs=true \
    --client-key=test1-key.pem

# 追加一个名为 kubernetes 的上下文参数，指定它使用前面添加的 集群 kubernetes 和名为 test1 的凭据
kubectl --kubeconfig=test1.kubeconfig config set-context kubernetes \
    --cluster=kubernetes --user=test1

# 选择默认的上下文
kubectl --kubeconfig=test1.kubeconfig config use-context kubernetes

然后使用该 kubeconfig 测试：

[root@zgz pki]# kubectl --kubeconfig=test1.kubeconfig get pod
No resources found in default namespace.
[root@zgz pki]# kubectl --kubeconfig=test1.kubeconfig get svc
Error from server (Forbidden): services is forbidden: User "test1" cannot list resource "services" in API group "" in the namespace "default"

group test2 一样操作，就是注意 O 字段即可，然后是 clusterrole 和 clusterrolebinding ，自行挑战下。

kube-apiserver 的 certSAN

此部分解决 kube-apiserver 的证书（过期也可以按照如下步骤来），例如很多人 kubeadm 初始化后，certSAN 缺少 hosts 报错：


$ echo '127.0.0.1 santest' >> /etc/hosts
$ kubectl --server https://santest:6443 get pod
...
Unable to connect to the server: tls: 
    failed to verify certificate: x509: 
    certificate is valid for kubernetes, kubernetes.default, kubernetes.default.svc, kubernetes.default.svc.cluster.local, node, not santest

这个时候可以用 ca 签署新证书来包含 santest ：

cd /etc/kubernetes/pki/

# 创建 ca 签署证书签名配置文件，因为该证书是只 server 使用，不需要在 usages 里带 "client auth"
# 如果所有证书手动生成时候用同一个 ca-config.json 可以偷懒带上 "client auth"

cat > ca-config.json << EOF
{
  "signing": {
    "default": {
      "expiry": "876000h"
    },
    "profiles": {
      "kubernetes": {
        "usages": [
            "signing",
            "key encipherment",
            "server auth"
        ],
        "expiry": "876000h"
      }
    }
  }
}
EOF


# 查看现有 certSAN
openssl x509 -noout  -in apiserver.crt  -certopt no_subject,no_header,no_version,no_serial,no_signame,no_validity,no_issuer,no_pubkey,no_sigdump,no_aux -text

# 把上面老的和要添加的 写到文件里
cat > kubernetes-csr.json << EOF
{
  "CN": "kube-apiserver",
  "hosts": [
    "127.0.0.1",
    "::1",
    "localhost",
    "santest"
    "10.xx",
    "10.96.0.1",
    "kubernetes",
    "kubernetes.default",
    "kubernetes.default.svc",
    "kubernetes.default.svc.cluster",
    "kubernetes.default.svc.cluster.local"
  ],
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "O": "k8s",
      "OU": "Kubernetes"
    }
  ]
}
EOF

# 签署证书

cfssl gencert \
        -ca=ca.crt \
        -ca-key=ca.key \
        -config=ca-config.json \
        -profile=kubernetes kubernetes-csr.json | cfssljson -bare apiserver2

修改 kube-apiserver 的 cmdline 使用 apiserver2.pem 和 apiserver2-key.pem :

$ cd /etc/kubernetes/manifests/
$ grep -E 'apiserver.(crt|key)' /etc/kubernetes/manifests/kube-apiserver.yaml
    - --tls-cert-file=/etc/kubernetes/pki/apiserver.crt
    - --tls-private-key-file=/etc/kubernetes/pki/apiserver.key
$ sed -ri -e 's#/apiserver.crt#/apiserver2.pem#' -e 's#/apiserver.key#/apiserver2-key.pem#' /etc/kubernetes/manifests/kube-apiserver.yaml
$ grep -E -- '--tls-(cert|private)' /etc/kubernetes/manifests/kube-apiserver.yaml
    - --tls-cert-file=/etc/kubernetes/pki/apiserver2.pem
    - --tls-private-key-file=/etc/kubernetes/pki/apiserver2-key.pem

然后用上面的 santest 域名测试：

$ kubectl --server https://santest:6443 get pod
No resources found in default namespace.
$ kubectl --server https://santest:6443 get svc
NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
kubernetes   ClusterIP   10.96.0.1            443/TCP   1h

故障案例

kubectl 证书过期

1 2	$ kubectl apply -f /tmp/test-svc.yml ... x509: certificate has exprired or is not yet valid: current time 2025-05-20T23:25:51+08:00 is after 2025-01-16T02:16:34Z

查看 kubeconfig 内嵌的证书过期时间：

1 2	$ openssl x509 -in <(kubectl config view --raw -o jsonpath="{.users[0]['user']['client-certificate-data']}" \| base64 -d ) -noout -enddate notAfter=Jan 16 02:16:34 2025 GMT

而 admin.pem 看现场重新签署了下，时间没过期：

1
2
3

$ openssl x509 -in admin.pem -noout -dates
notBefore=Jan 17 03:05:00 2024 GMT
notAfter=Dec 24 03:05:00 2123 GMT

所以内嵌下证书生成新的 kubeconfig 即可：

# 我们证书后缀和文件路径不一样，不要照抄，env 和命令行指定生成的 kubeconfig 均一样
cd /etc/kubernetes/cluster1/ssl

KUBECONFIG=/etc/kubernetes/cluster1/.kube/config2 \
        kubectl config set-cluster kubernetes \
        --certificate-authority=ca.pem \
        --embed-certs=true \
        --server=https://127.0.0.1:8443
        
KUBECONFIG=/etc/kubernetes/cluster1/.kube/config2 \
        kubectl config set-credentials admin \
        --client-certificate=admin.pem \
        --embed-certs=true \
        --client-key=admin-key.pem

KUBECONFIG=/etc/kubernetes/cluster1/.kube/config2 \
        kubectl config set-context kubernetes \
        --cluster=kubernetes --user=admin

KUBECONFIG=/etc/kubernetes/cluster1/.kube/config2 \
         kubectl config use-context kubernetes

KUBECONFIG=/etc/kubernetes/cluster1/.kube/config2 kubectl get node

deploy 的 rs 创建报错过期

$ kubectl -n default describe deploy deployment-example
Name:                   deployment-example
Namespace:              default
CreationTimestamp:      Fri, 30 May 2025 15:45:03 +0800
Labels:                 
Annotations:            
Selector:               app=nginx
Replicas:               2 desired | 0 updated | 0 total | 0 available | 0 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  25% max unavailable, 25% max surge
Pod Template:
  Labels:  app=nginx
  Containers:
   nginx:
    Image:        nginx:1.19-alpine
    Port:         12343/TCP
    Host Port:    0/TCP
    Environment:  
    Mounts:       
  Volumes:        
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Progressing    False   ReplicaSetCreateError
OldReplicaSets:  
NewReplicaSet:   
Events:
  Type     Reason                 Age                From                   Message
  ----     ------                 ----               ----                   -------
  Warning  ReplicaSetCreateError  21s (x7 over 21s)  deployment-controller  Failed to create new replica set "deployment-example-b4f6c7989": Get "https://[::1]:6443/api/v1/namespaces/default/resourcequotas": x509: certificate has expired or is not yet valid: current time 2025-05-30T22:06:13+08:00 is after 2024-08-28T14:45:36Z
  Warning  ReplicaSetCreateError  20s (x2 over 20s)  deployment-controller  Failed to create new replica set "deployment-example-b4f6c7989": Get "https://[::1]:6443/api/v1/namespaces/default/resourcequotas": x509: certificate has expired or is not yet valid: current time 2025-05-30T22:06:14+08:00 is after 2024-08-28T14:45:36Z
  Warning  ReplicaSetCreateError  18s                deployment-controller  Failed to create new replica set "deployment-example-b4f6c7989": Get "https://[::1]:6443/api/v1/namespaces/default/resourcequotas": x509: certificate has expired or is not yet valid: current time 2025-05-30T22:06:16+08:00 is after 2024-08-28T14:45:36Z
  Warning  ReplicaSetCreateError  16s                deployment-controller  Failed to create new replica set "deployment-example-b4f6c7989": Get "https://[::1]:6443/api/v1/namespaces/default/resourcequotas": x509: certificate has expired or is not yet valid: current time 2025-05-30T22:06:18+08:00 is after 2024-08-28T14:45:36Z
  Warning  ReplicaSetCreateError  11s                deployment-controller  Failed to create new replica set "deployment-example-b4f6c7989": Get "https://[::1]:6443/api/v1/namespaces/default/resourcequotas": x509: certificate has expired or is not yet valid: current time 2025-05-30T22:06:23+08:00 is after 2024-08-28T14:45:36Z
  Warning  ReplicaSetCreateError  0s                 deployment-controller  Failed to create new replica set "deployment-example-b4f6c7989": Get "https://[::1]:6443/api/v1/namespaces/default/resourcequotas": x509: certificate has expired or is not yet valid: current time 2025-05-30T22:06:34+08:00 is after 2024-08-28T14:45:36Z

这套环境是二进制部署，ReplicaSet 是 kube-controller-manager 创建的，该报错需要看 kube-controller-manager 日志，然后 k8s 的管理组件是通过 lease 对象保证只有一个真正处理：

$ kubectl -n kube-system get lease
NAME                      HOLDER                                                                     AGE
kube-controller-manager   ubuntu-Standard-PC-i440FX-PIIX-1996_296a57fb-a219-4301-a0a6-62c3cd09e0f2   639d
kube-scheduler            ubuntu-Standard-PC-i440FX-PIIX-1996_edd2caff-d647-4633-8bd5-2d9788986e1f   639d

holder 的名字生成规则如下

// https://github.com/kubernetes/kubernetes/blob/v1.29.5/cmd/kube-controller-manager/app/controllermanager.go#L256-L286
id, err := os.Hostname()
if err != nil {
return err
}

// add a uniquifier so that two processes on the same host don't accidentally both become active
id = id + "_" + string(uuid.NewUUID())

发现每台机器的 hostname 一样的，完全不知道当前持有 lease 的 kube-controller-manager 是哪台，算了，每个去看日志吧：

$ journalctl -xe --no-pager -u kube-controller-manager.service 
-- Logs begin at Fri 2025-05-09 14:24:19 CST, end at Fri 2025-05-30 22:21:03 CST. --
May 22 00:01:48 ubuntu-Standard-PC-i440FX-PIIX-1996 kube-controller-manager[53418]: E0522 00:01:48.204891   53418 leaderelection.go:325] error retrieving resource lock kube-system/kube-controller-manager: etcdserver: leader changed

May 30 22:08:57 ubuntu-Standard-PC-i440FX-PIIX-1996 kube-controller-manager[22314]: E0530 22:08:57.593721   22314 deployment_controller.go:495] Get "https://[::1]:6443/api/v1/namespaces/default/resourcequotas": x509: certificate has expired or is not yet valid: current time 2025-05-30T22:08:57+08:00 is after 2024-08-28T14:45:36Z
May 30 22:08:57 ubuntu-Standard-PC-i440FX-PIIX-1996 kube-controller-manager[22314]: I0530 22:08:57.593752   22314 deployment_controller.go:496] Dropping deployment "default/deployment-example" out of the queue: Get "https://[::1]:6443/api/v1/namespaces/default/resourcequotas": x509: certificate has expired or is not yet valid: current time 2025-05-30T22:08:57+08:00 is after 2024-08-28T14:45:36Z
May 30 22:08:57 ubuntu-Standard-PC-i440FX-PIIX-1996 kube-controller-manager[22314]: I0530 22:08:57.593824   22314 event.go:291] "Event occurred" object="default/deployment-example" kind="Deployment" apiVersion="apps/v1" type="Warning" reason="ReplicaSetCreateError" message="Failed to create new replica set \"deployment-example-b4f6c7989\": Get \"https://[::1]:6443/api/v1/namespaces/default/resourcequotas\": x509: certificate has expired or is not yet valid: current time 2025-05-30T22:08:57+08:00 is after 2024-08-28T14:45:36Z"

从 cmdline 获取 kubeconfig 路径：

$ systemctl cat kube-controller-manager.service 
# /etc/systemd/system/kube-controller-manager.service
[Unit]
Description=Kubernetes Controller Manager
Documentation=https://github.com/GoogleCloudPlatform/kubernetes

[Service]
ExecStart=/data/kube/bin/kube-controller-manager \
  --address=127.0.0.1 \
  --kubeconfig=/etc/kubernetes/cluster1/ssl/kube-controller-manager.kubeconfig \
...
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

查看下时间

$ kubectl --kubeconfig  /etc/kubernetes/cluster1/ssl/kube-controller-manager.kubeconfig \
config view --raw -o jsonpath="{.users[0]['user']['client-certificate-data']}" | base64 -d > test.pem
$ openssl x509 -in test.pem -noout -enddate
notAfter=Aug  5 15:37:00 2123 GMT

时间没问题，然后看了下每个 kube-controller-manager 都没问题，轮流间隔重启了下 kube-controller-manager 还是一样，然后重启了下 kube-apiserver 才好，感觉 kube-apiserver 缓存 bug。

kubelet 轮转证书

证书位于 /var/lib/kubelet ，有时候 kubelet 不会自动轮转，该目录内证书备份下后重启 kubelet 即可，以及推荐设置 kube-controller-manager 的轮转证书时间久些。

一些其他的

不单单 k8s 证书， etcd 证书一样，k8s 访问 etcd 相关大同小异，上面实战部分如果理解能力不行，在关于 ca-config.json 的 usages 可以偷懒下面 client 和 server 都写上了，一个 ca 配置文件用于所有：

"usages": [
    "signing",
    "key encipherment",
    "server auth",
    "client auth"
],

任何关于证书报错的信息和日志仔细看，证书过期、 certSAN 不匹配和不是一套 ca 导致校验不通过等是不一样的事情，不要无脑找到啥证书文章博客就跟着瞎操作，证书操作前要备份已有证书，产生 kubeconfig 文件的时候，要使用 kubectl 指定新路径生成，不要动老的。

开发一个让指定应用走代理的安卓 app 过程

2025-04-27T20:40:30.000Z

最近开发一个让指定 app 走 http 代理的经过…..

由来

想对网络做一些验证，初步想法是找下 golang socks5 代理 server 上对每个 conn 的字节流反序列化后做动作，然后发现如果设备多了的话，没有代理池基本源 IP 就是一个了，所以想着手机端上有没有非 root 下让指定 app 走代理的代理软件。

然后想起了 v2rxxNG 里可以指定 app 走代理，于是研究折腾了一番到学习 kotlin 和安卓 compose 自己开发安卓 app。

底层探讨经过

先大致看了下 v2rxxNG 的代码，发现用的 tun2socks 技术，主要是 tun 接口，也就是 Linux 的 tun 技术。

Tun

在 Linux 里一切皆文件，Tap/Tun 是 Linux 提供的用户态封装报文的接口，Tap 是数据链路层二层，Tun 是网络 IP 层三层，Tun 一端连着内核的协议栈，另一端连着用户态的进程。使用流程是：

程序使用现有或者创建的虚拟网卡（Tap/Tun）
程序需要对收和发的报文进行处理（也就是读写 /dev/net/tun 字符设备），程序的逻辑就像物理网卡的硬件功能一样

详细流程见理解Linux虚拟网卡设备tun/tap的一切，不搞啥虚拟交换机，而是常规做软件代理隧道啥的一般都是使用 Tun。

例如 linux 机器使用 socks5 tun 模式代理：

走路由或者 iptables fmark 匹配到发往 tun 网卡
Linux 协议栈会把 TCP/IP 报文发到用户态程序的 socks5 client
client 程序解析 IP 层的数据，封装成 socks5 协议的包发出去
协议栈收到后发往物理网卡，物理网卡发出去
socks5 server 端收到报文，解析后，本机发往目标地址

这样目标地址看到就是 socks5 server 的 IP 请求的自己了，和 socks5 无关，代理隧道啥的基本都是这样的工作原理。

更详细的图文见：

安卓和 Tun

v2rxxNG 是把 badvxn 编译成二进制文件，放在 libs 下命名为 libtun2socks.so，这样 Android 在安装 app 的时候会自动给 .so 后缀的文件 +rx 执行权限，在没有 root 的情况下，应用程序是无法给一个文件增加 x 权限的，这也算是一个骚操作。

然后在安卓开发的时候，安卓提供了接口，需要继承 VxnService ，在其类的内部使用 Builder() 创建 tun，只不过安卓上不再是 /dev/net/tun 而是文件描述符了：

ParcelFileDescriptor tunDevice = new Builder()
    .addAddress(VXN_ADDRESS, 32)
    .addRoute(VXN_ROUTE, 0)
    .addDnsServer(VXN_DNS)
    .addAllowedApplication("com.google.android.tethering")
    .addAllowedApplication("com.google.android.tethering2")
    .establish();

fd = tunDevice.getFd()

然后 libtun2socks 使用这个 fd 运行，badvxn 是基于 LwIP 修改的实现，c 语言基本都忘光了，找了下 golang 的实现看看，找到了 https://github.com/xjasonlyu/tun2socks ，为啥选它是应为它内置了好几个模式，例如 direct ，修改起来应该比较简单（这里我不去追求性能极限，以需求优先而选型）。

安卓开发

搜了下相关没有搜到现有的轮子，唯一一个比较接近我需求的 appproxy 是 flutter 写的，并且代理类型只有 http 和 socks5，没办法，就去学习了下 kotlin 和安卓开发。

需求分析

主要需求为如下：

添加、修改、删除代理配置
通知栏的前台运行通知
右下角的浮动开关
tun2socks 对接启动
app 选择界面选择哪些 app 走代理

快速看完官方文档的 compose 开发后，基于 inventory-app 复制修改开始，各个界面跳转用 navigate ，另外还发现 tailscale-android 也是全部用 kotlin + jetpack compose 开发的，可以从里面学下代码。

tun2socks aar

根据文档 tun2socks 的 How to use file descriptor in Android 得知，集成到安卓是要利用 gomobile 编译出安卓的 aar 后代码里加载（而不是 v2rxxNG 那样运行二进制文件）。先编译出来后写个最小 demo 试试看，需要 NDK 和 SDK_TOOLS 和 golang，搜索了下后制作了一个带环境的 docker 镜像，直接下面步骤快速编译：

git clone https://github.com/xjasonlyu/tun2socks
cd tun2socks
# 不要在低配置机器上编译，会卡死机器
docker run --rm -ti \
 -e GOPROXY='https://goproxy.cn,https://mirrors.aliyun.com/goproxy/,https://goproxy.io,https://proxy.golang.com.cn,direct' \
  --entrypoint bash -v $PWD:/w -w /w registry.aliyuncs.com/zhangguanzhang/gomobile
go get golang.org/x/mobile/bind
mkdir -p build
#  也可以使用一些go build 参数 这里我指定-androidapi 24最低兼容安卓7，默认值是16，但是较新的 NDK 上无法编译， 23.1.7779620 可以编译
gomobile bind -ldflags="-s -w" -trimpath -o build/tun2socks.aar \
-target android \
-androidapi 24 \
github.com/xjasonlyu/tun2socks/v2/engine
$ ls -l build/
total 30580
-rw-r--r-- 1 root root 31304576 Apr 27 11:50 tun2socks.aar
-rw-r--r-- 1 root root     6927 Apr 27 11:50 tun2socks-sources.jar

issue 里基本都是 java 开发的，我这里是 kotlin 和最新版本的 Android Studio，最新的版本里，都是用 kotlin 的 DSL gradle 了，按照 issue 里的添加后在 Android Studio 里一直报红，然后搜索后下面的才行：

1 2	# app 下的 buid.grade.kts 的依赖下添加 implementation(files("libs/tun2socks.aar"))

把上面的 aar 文件放 app/libs/ 下即可，使用和 issue 里一样。

gomobile 一些实践参考:

前台

官方的 demo Toy 非常老，而且是 java 的，这里是我找的官方文档和一些参考代码：

前台服务运行需要 Notification ，参考下别人代码后 Android Studio 模拟器里状态栏前台需要的通知出不来，在真机安卓 11 试了下没问题，发现模拟器的安卓版本太高了，谷歌了下需要加下面代码申请：

@RequiresApi(Build.VERSION_CODES.TIRAMISU)
fun checkNotificationPermission() {
    val permission = android.Manifest.permission.POST_NOTIFICATIONS
    when {
        ContextCompat.checkSelfPermission(
            this,
            permission
        ) == PackageManager.PERMISSION_GRANTED -> {
        }

        shouldShowRequestPermissionRationale(permission) -> {
        }

        else -> {
            requestNotificationPermission.launch(permission)
        }
    }
}

private val requestNotificationPermission =
    registerForActivityResult(ActivityResultContracts.RequestPermission()) { isGranted ->
        if (isGranted) Toast.makeText(this, "通知权限已授予", Toast.LENGTH_SHORT)
            .show()
        else Toast.makeText(this, "通知权限被拒绝", Toast.LENGTH_SHORT)
            .show()
    }

然后启动代理闪退，发现没有像以前用的 app 那样弹窗口和钥匙，就是说该 app 申请 vpn 接口，会对啥啥的，需要调用：

1	VpnService.prepare(this)

一些其他细节问题

启动后，切出去，再从通知栏进来，发现浮动按钮状态和实际不一致，最后还是按照 Binder 和 Service 通信才行，以及 Broadcast 让按钮状态和实际一致。
完整代码在 appproxy

打包发给其他人，发现安装不上，最后发现是签名问题，没签名安装不了，偷懒可以暂时 Build -> Generate App Bundles or APKs -> Generate APKs 弹出的点 locate 里。还可以分架构打非一体包：

splits {
    abi {
        isEnable = true
        reset()
        include("armeabi-v7a", "arm64-v8a", "x86_64")
        isUniversalApk = false
    }
}

后续

app 开发完成后，后续就是 fork tun2socks 复制 direct 后在 conn 对流解析和修改发送，当然可以天马行空下不要局限在代理层面，例如用户态 kotlin 直接对 fd 的流转发下只统计访问 ip，就可以做一个简单的网络访问统计了。

tun2socks 好多全局变量和 init 里做操作，这里记录下梳理的一些启动流程：

1. main.go 里的 engine.Start()
2. engine/engine.go 里的 start()
3. engine/engine.go 里的 netstack() 内的 `tunnel.T().SetDialer(_defaultProxy)`
4. 上面 import 了 tunnel 执行了 tunnel/global.go 内的 init() 的 T().ProcessAsync()
5. go t.process(ctx)
func (t *Tunnel) process(ctx context.Context) {
for {
select {
case conn := <-t.tcpQueue:
go t.handleTCPConn(conn)
case conn := <-t.udpQueue:
go t.handleUDPConn(conn)
case <-ctx.Done():
return
}
}
}

由于是 aar 引用，入口是 engine/engine.go 内的 engine.Start() 方法，对于日志，如果有打印到文件的需求的要在这个文件里修改，由于默认 cwd 是 / 会报错只读，推荐给 Key 添加 Dir 参数在 engine/engine.go 里：

func general(k *Key) error {
level, err := log.ParseLevel(k.LogLevel)
if err != nil {
return err
}

filename := path.Join(_defaultKey.Dir, "tun2socks.log")
cfg := zap.NewProductionConfig()
cfg.OutputPaths = []string{filename}
cfg.Level.SetLevel(level)
log.SetLogger(zap.Must(cfg.Build()))

// log.SetLogger(log.Must(log.NewLeveled(level)))

然后在 service 里给 key.dir 传递 getExternalFilesDir(null)?.absolutePath，也就是下面路径：

1	/storage/emulated/0/Android/data//files/

这样 engine 日志就可以打印在上面目录内，另外对于 tcp 链接，核心就是这块代码：

func (t *Tunnel) handleTCPConn(originConn adapter.TCPConn) {
defer originConn.Close()

id := originConn.ID()
metadata := &M.Metadata{
Network: M.TCP,
SrcIP:   parseTCPIPAddress(id.RemoteAddress),
SrcPort: id.RemotePort,
DstIP:   parseTCPIPAddress(id.LocalAddress),
DstPort: id.LocalPort,
}

ctx, cancel := context.WithTimeout(context.Background(), tcpConnectTimeout)
defer cancel()

remoteConn, err := t.Dialer().DialContext(ctx, metadata)
if err != nil {
log.Warnf("[TCP] dial %s: %v", metadata.DestinationAddress(), err)
return
}
metadata.MidIP, metadata.MidPort = parseNetAddr(remoteConn.LocalAddr())

remoteConn = statistic.NewTCPTracker(remoteConn, metadata, t.manager)
defer remoteConn.Close()

log.Infof("[TCP] %s <-> %s", metadata.SourceAddress(), metadata.DestinationAddress())
pipe(originConn, remoteConn)
}

工作流程如下，客户端发起连接到 tun2socks，然后 tun2socks t.Dialer().DialContext(ctx, metadata) 连接目标地址，然后 pipe 两个 conn

1 2	# 也可以去看看 core/tcp.go client ----originConn----> tun2socks -----remoteConn----> server

如果需要 tun2socks 主动给 client 回包，需要把 remoteConn 传递过去，同时在 t.Dialer().DialContext 内产生的 net.Conn 的 Read 的 []byte len 发现有点小，我自己维护了个 buf 做处理：

func (m *mirrorStream) Read(p []byte) (int, error) {
tmp := make([]byte, len(p))
n, err := m.rawConn.Read(tmp)
if err != nil {
return 0, err
}
copy(p, tmp[:n])
m.buf = append(m.buf, tmp[:n]...)
m.mirrorMessages()
return n, nil
}

参考

kube-log-runner 使用和适配 logrotate 改造

2025-04-21T10:40:30.000Z

最近使用 kube-log-runner 的经历…..

由来

kubelet 和一些 kube 组件在二进制 systemd service 管理下，日志最终会在 /var/log/messages 里，我们的客户对该文件会有关键字（Error、Failed …）监控，让我们把相关组件日志写到其他文件里去。

经过

选型

根据官方文档系统日志得知 v1.26 开始移除了以前的日志文件、目录和轮转之类的参数，而是让使用 kube-log-runner 代替，该二进制已经内置在二进制下载压缩包里了。如果是使用镜像，官方的容器镜像内置了，只是名字叫做 /go-runner。

根据 github kube-log-runner 得知使用方式和源码，它就是 golang 写的一个简单工具，启动命令，把命令的标准输出和错误输出捕获写到文件，然后转发信号给进程。

尝试

$ systemctl cat --no-pager kube-apiserver
...
ExecStart=/usr/local/bin/kube-log-runner \
  --log-file=/var/logs/kube-apiserver.log \
  /usr/local/bin/kube-apiserver

直接测试了下发现启动报错下面：

1	4月 18 10:30:25 xxx systemd[1]: Got notification message from PID 9885, but reception only permitted for main PID 9880

如果对 systemd 比较熟悉，可以直接看出问题。因为我们这边用的 Type=notify，该设置下，服务启动后会发送 sd_notify 给 systemd，这样 systemd 确认该服务正常启动。这个报错就是：

systemd 拉起的主进程 Pid 是 9880
从非主进程的 9885 收到了 notification 消息

解决该问题很简单，systemd 给了配置选项接收所有的 notify ：

1	NotifyAccess=all

logrotate

日志要写入到文件，那就一定要遵守 Linux 规范配置 logrotate 避免日志写满分区。然后相关配置完，写完配置用一个小的 size 参数测试了 logrotate 发现不行：

1	logrotate -v /etc/logrotate.d/kube-apiserver

logrotate 轮转日志分为两种模式，create 和 copytruncate，默认是 create，两种大致原理如下：

create：重命名日志文件，再创建原有的日志文件，等同于 mv + touch
copytruncate：cp xx.log xx.log.1 && truncate -s 0 xx.log

Linux 上打开文件名实际是操作 inode，文件名在打开 inode 后改名或者删掉文件 path 对进程并不会有影响，create 方式需要进程支持 reopen 日志文件路径使用新的 inode，类似 nginx 的 logrotate 配置如下：

/var/log/nginx/*.log /var/log/nginx/*/*.log{
daily
missingok
rotate 14
compress
delaycompress
notifempty
create 640 root adm
sharedscripts
postrotate
[ ! -f /var/run/nginx.pid ] || kill -USR1 `cat /var/run/nginx.pid`
endscript
}

kube-apiserver 并没有支持这种行为，就尝试了下 copytruncate 发现也不行，然后去 kep 的 kube-log-runner 下回复了下请求添加 logrotate 支持。

修改

等官方估计很久了，先自己修改下源码支持下：

package main

import (
"flag"
"fmt"
"io"
"log"
"os"
"os/exec"
"os/signal"
"strings"
"sync"
"syscall"
)

var (
logFilePath    = flag.String("log-file", "", "If non-empty, save stdout to this file")
alsoToStdOut   = flag.Bool("also-stdout", false, "useful with log-file, log to standard output as well as the log file")
redirectStderr = flag.Bool("redirect-stderr", true, "treat stderr same as stdout")

// 新增全局变量
logFile         *os.File
logFileMu       sync.Mutex
globalLogFile   string
globalAlsoStdOut bool
globalRedirectStderr bool
)

// SyncWriter 支持动态切换 Writer
type SyncWriter struct {
mu sync.Mutex
w  io.Writer
}

func (sw *SyncWriter) Write(p []byte) (n int, err error) {
sw.mu.Lock()
defer sw.mu.Unlock()
return sw.w.Write(p)
}

func (sw *SyncWriter) SetWriter(w io.Writer) {
sw.mu.Lock()
defer sw.mu.Unlock()
sw.w = w
}

var (
outputSync = &SyncWriter{w: os.Stdout}
errSync    = &SyncWriter{w: os.Stderr}
)

func main() {
flag.Parse()

if err := configureAndRun(); err != nil {
log.Fatal(err)
}
}

func configureAndRun() error {
// 保存参数到全局变量
globalLogFile = *logFilePath
globalAlsoStdOut = *alsoToStdOut
globalRedirectStderr = *redirectStderr

// 初始化日志文件
if globalLogFile != "" {
var err error
logFile, err = os.OpenFile(globalLogFile, os.O_APPEND|os.O_CREATE|os.O_WRONLY, 0644)
if err != nil {
return fmt.Errorf("failed to open log file: %w", err)
}

if globalAlsoStdOut {
outputSync.SetWriter(io.MultiWriter(os.Stdout, logFile))
} else {
outputSync.SetWriter(logFile)
}

if globalRedirectStderr {
errSync.SetWriter(outputSync)
}
}

args := flag.Args()
if len(args) == 0 {
return fmt.Errorf("not enough arguments to run")
}

exe := args[0]
var exeArgs []string
if len(args) > 1 {
exeArgs = args[1:]
}
cmd := exec.Command(exe, exeArgs...)
cmd.Stdout = outputSync
cmd.Stderr = errStream()

log.Printf("Running command:\n%v", cmdInfo(cmd))
err := cmd.Start()
if err != nil {
return fmt.Errorf("starting command: %w", err)
}

// 信号处理
go setupSigHandler(cmd.Process)
if err := cmd.Wait(); err != nil {
return fmt.Errorf("running command: %w", err)
}
return nil
}

func errStream() io.Writer {
if *redirectStderr {
return outputSync
}
return os.Stderr
}

func cmdInfo(cmd *exec.Cmd) string {
return fmt.Sprintf(
`Command env: (log-file=%v, also-stdout=%v, redirect-stderr=%v)
Run from directory: %v
Executable path: %v
Args (comma-delimited): %v`, *logFilePath, *alsoToStdOut, *redirectStderr,
cmd.Dir, cmd.Path, strings.Join(cmd.Args, ","),
)
}

// 修改后的信号处理函数
func setupSigHandler(process *os.Process) {
signals := []os.Signal{
syscall.SIGHUP, syscall.SIGINT,
syscall.SIGTERM, syscall.SIGQUIT, syscall.SIGUSR1,
}
c := make(chan os.Signal, 1)
signal.Notify(c, signals...)

log.Println("Now listening for signals")
for s := range c {
if s == syscall.SIGUSR1 {
handleLogRotate()
} else {
forwardSignal(process, s)
}
}
}

// 处理日志轮转
func handleLogRotate() {
logFileMu.Lock()
defer logFileMu.Unlock()

if globalLogFile == "" {
log.Println("No log file configured, ignoring SIGUSR1")
return
}

// 关闭旧文件
if logFile != nil {
logFile.Sync()
if err := logFile.Close(); err != nil {
log.Printf("Error closing log file: %v", err)
}
}

// 打开新文件
newFile, err := os.OpenFile(globalLogFile, os.O_APPEND|os.O_CREATE|os.O_WRONLY, 0644)
if err != nil {
log.Printf("ERROR: Failed to reopen log file: %v (logging to stdout)", err)
outputSync.SetWriter(os.Stdout)
if globalRedirectStderr {
errSync.SetWriter(os.Stdout)
}
return
}

logFile = newFile
log.SetOutput(logFile)
log.Println("Successfully reopened log file")

// 更新输出流
if globalAlsoStdOut {
outputSync.SetWriter(io.MultiWriter(os.Stdout, logFile))
} else {
outputSync.SetWriter(logFile)
}

if globalRedirectStderr {
errSync.SetWriter(outputSync)
}
}

func forwardSignal(process *os.Process, s os.Signal) {
log.Printf("Forwarding signal %v to PID %v", s, process.Pid)
if err := process.Signal(s); err != nil {
log.Printf("Error forwarding signal %v: %v", s, err)
}
}

上面代码不转发 USR1 信号给套娃的进程，自身处理 USR1 信号就是 reopen 日志文件。然后 logrotate 触发需要 pid 文件，systemd 里增加:

1	ExecStartPost=/bin/sh -c "echo $MAINPID > /var/run/kube-apiserver.pid"

logrotate 配置文件：

/var/logs/kube-apiserver.log {
    daily
    rotate 5
    size 400M
    missingok
    compress
    nomail
    delaycompress
    create
    postrotate
        [ ! -f /var/run/kube-apiserver.pid ] || kill -USR1 `cat /var/run/kube-apiserver.pid`
    endscript
}

参考

https://wsgzao.github.io/post/logrotate/

Zhangguanzhang

欧拉22.04容器内sudo 被 killed

由来

排查

权限？

制作验证

结论和验证

[持续更新] - 安卓 HTTPS 抓包那些事

由来

原理相关

中间人

安卓的凭据

SSL Pinning

高版本安卓的凭据

安卓原理和工具选项

指定 app 抓包原理

工具选型

一些题外话

[持续更新] - 为什么不应该为了实现需求而调用命令

由来

案例

命令注入

Popen 卡住

僵尸进程

客户监控

命令限制和禁止

行为控制和错误处理

文件权限

后续扩展性

默认参数

tty

输出变更

引发事故

没考虑到的场景

参数废弃

一些 python 替代

一些文件操作

一些 sdk 经验

docker 重启非 host 网络容器造成 dns 异常的梳理和pr修复

由来

过程

日志

最小复现

相关源码

断点调试

分析

sandbox change

containerd 没复现

重启偶尔重建Pod

修复

docker open /var/lib/docker/tmp/GetImageBlobXXX: no such file 的正确处理方式

由来

处理过程

复现

排查

根因

多线程执行skopeo copy panic的一次解决过程

由来

排查

调用链分析

原因

解决

离线安装docker和包管理安装docker下containerd的启动相关

由来

排查

包管理下的 docker 和 containerd

二进制安装 docker

keepalived Locking pid file error 22 - Invalid argument

由来

排查

基础排查

源码

编译

从自己造轮子NodePort白名单到参考 calico 规则

由来

规则问题

calico

准备工作

GlobalNetworkPolicy

规则研究