为自由和真理，英勇地献身

一、故障现象 在一次客户升级内存CPU之后，服务全挂 最早暴露出来的是 CoreDNS 一直起不来，日志持续报错： 1 2 [INFO] plugin/ready: Still waiting on: "kubernetes" [WARNING] plugin/kubernetes: Kubernetes API connection failure: Get "https://10.43.0.1:443/version": dial tcp 10.43.0.1:443: i/o timeout 这说明 CoreDNS 的 kubernetes 插件无法访问集群内的 Kubernetes API Service，也就是 10.43.0.1:443。 复杂的是，机器里面有两张网卡，ens192和ens224 1 2 3 4 5 [root@linglang-Bi server]# ip route default via 192.168.1.1 dev ens192 10.42.0.0/24 dev cni0 proto kernel scope link src 10.42.0.1 192.168.1.0/24 dev ens192 scope link 192.168.30.0/24 dev ens224 scope link 二、确认 apiserver 存活状态 先查节点状态：...

一、环境与现象 1.1 环境信息 项目 值 OS CentOS 7 Kernel 3.10.0-1160.119.1.el7.x86_64 容器编排 K3s (内置 containerd) CNI Flannel 1.2 故障现象 在之前客户环境升级组件时，经常有pod长期处于Terminating状态导致无法升级的情况 我在相同内核版本的测试机复现了这个环境，升级后出现多个 Pod 长时间卡在 Terminating 状态无法销毁，新 Pod 处于 Pending： 1 2 3 4 5 6 7 8 9 $ kubectl get pods | grep -E "Terminating|Pending" spark-job-engine-controller-c46bfcc7d-vtpdj 0/1 Pending 0 25h langfuse-worker-8588567885-vxkxw 0/1 Terminating 7 8d analytics-server-controller-7bcf876764-mkg2w 0/1 Terminating 4 8d langfuse-redis-6c5b76587f-4jj26 0/1 Terminating 4 8d langfuse-web-b4bf858d8-2l4xv 0/1 Terminating 11 8d grafana-controller-59cc7fd9bd-dpb7t 0/1 Terminating 4 12d spark-job-engine-controller-c46bfcc7d-xr2g4 0/1 Terminating 2 5d19h analytics-admin-controller-6fb9f7c5b5-ppv2h 0/1 Terminating 7 12d 1....

记一次 K3s 网络深坑：为什么宿主机访问 ClusterIP 会超时丢包 TL;DR 由于旧版内核（3.10）与网卡硬件校验卸载（Checksum Offload）不兼容，导致跨节点 VXLAN 封包的 UDP Checksum 错误，被目标节点内核拦截。 背景 故障复现环境 OS: CentOS 7 (Kernel 3.10) K8s Distro: Client Version: v1.18.3-k3s1 Server Version: v1.18.3-k3s1 CNI: Flannel (VXLAN) 网络拓扑资源 宿主机 Node IP: 10.66.3.15 (Gateway: 10.66.3.125) Service CIDR: 10.43.0.0/16 Pod CIDR: 10.42.0.0/16 目标服务: spark-webui (ClusterIP: 10.43.236.230:8080) 1 2 3 4 5 6 [root@master-node ~]# kubectl get nodes -o wide NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME worker-1 Ready <none> 4y52d v1....

前言 最近OpenClaw又火了，第一次给我的观感像我以前玩过的AutoGPT，只不过现在的模型能力强得多了，能做的事情更多了，最大的改进我觉得就是能接入各种IM做你的私人助手吧（笑 但是看到这么多朋友都搞上了，我也想试试 调研一波发现没Mac会大大束缚OpenClaw的能力，想保存个文件都没那么顺畅 至此，我决定使用Docker上安装MacOS再装OpenClaw的套娃操作 2. KVM 宿主机的准备 这次我是在我的HomeLab上安装的，配置如图 我单独给Claw开了一个vm，分配了10c16g + 150G 基于我是在KVM上再安装的，这个MacOS容器需要依赖KVM以及QEMU 在创建VM的时候需要在CPU这里选择host模式而不是x86模拟等 3. 核心环节：Docker 启动 macOS 14 官方的镜像 是只把虚拟化等准备好的，也就是不带MacOS镜像(等安装的时候再通过自带的Opencore启动文件从苹果官方下载），不过这里也建议先把Docker镜像先拉下来 1 docker pull sickcodes/docker-osx:latest 创建一个img提前占坑（这一步很重要!) 1 qemu-img create -f qcow2 /data/macos/mac_hdd_ng.img 150G 然后给镜像加点权限 1 chmod 777 /data/macos/mac_hdd_ng.img 拉好镜像之后，执行我的docker run命令，我的命令如下： 1 2 3 4 5 6 7 8 9 10 11 12 docker run -it \ --device /dev/kvm \ -p 50922:10022 \ -p 5999:5999 \ -v /data/macos/mac_hdd_ng.img:/home/arch/OSX-KVM/mac_hdd_ng.img \ -e RAM=16 \ -e SHORTNAME=sonoma \ -e MASTER_PLIST_URL='https://raw....

最近在维护自己的 Minecraft 服务器，遇到个挺真实的需求 因为服务器是放在宿舍局域网里通过 FRP 穿透出去的，平时想知道有没有朋友上线，只能登到服务器上，我又不想用别人改过的服务端 于是写了一个 Caddy 的 Layer 4 扩展插件 mc_monitor。它能在不对 MC 服务端做任何改动的前提下，在网关层直接“嗅探”出登录的玩家名称，并异步推送到 Telegram 或 Discord。 这个插件工作在 OSI 模型的第四层（传输层）。 它的核心逻辑是在 TCP 连接建立时，利用 io.TeeReader 这种“三通”技术，在不消耗原始数据流的情况下，把玩家发来的握手包（Handshake）和登录包（Login Start）复制一份出来。 通过解析这些二进制包提取出玩家 ID（Username），然后再把流量原封不动地转发给后端的 MC 服务器。最后计算玩家从连接到断开的时长，生成报告。 当然，我这里用到了之前之前大佬写的关于mc服务端相关的库 核心代码实现 这里贴一下这个 Caddy 模块的核心逻辑代码，主要是 Handle 和 parseMCLogin 方法，它们负责了主要的流量劫持和协议解析工作： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 // Handle 处理连接的核心逻辑 // 这里我们利用 io....