躬行笔记
type: channel
link: https://www.fuzhoupyy.work/
description: 古人学问无遗力，少壮工夫老始成。 纸上得来终觉浅，绝知此事要躬行。
items: 有手就行！用AI SSH装OpenClaw，这感觉就像开了挂
items: 缓存选型踩坑记：Redis 和 Memcached 到底该怎么选？
items: 小白也能懂，手把手教你 Windows 10 部署 OpenClaw 并接入飞书，打造你的私人 AI 助理！
items: 手把手教你用 cephadm 在 Ubuntu 22.04 上部署生产级 Ceph 集群（Quincy/Reef 版本通用）
items: 从理念到架构：一文彻底讲透 DevOps 的本质与落地实践
items: 别再傻傻分不清了！Containerd 和 Docker 到底有啥区别？命令、架构全拆解
items: 别再折腾 iptables 了！用 cproxy + wstunnel 轻松搞定 Linux 透明代理，内网穿透稳如老狗
items: 让AI替你SSH进服务器，5分钟搞定故障排查！运维人终于能睡整觉了
items: 别再瞎猜了！K8s生产环境排错实战手册：从Pod卡住到服务503，这些坑我都替你踩过了
items: K3s保姆级实战：从单机“点亮”到生产集群搭建，别再对着官方文档发呆了

有手就行！用AI SSH装OpenClaw，这感觉就像开了挂
type: item
date: 2026-03-19T14:04:41+00:00
description: 最近群里一直在讨论OpenClaw这个工具，说是AI编程助手，能帮写代码、改bug，听着挺玄乎的。我寻思着，这玩意儿真有那么神？反正闲着也是闲着，不如搞个服务器试试看。不过说实话，一想到要在服务器上装这一堆东西就头大。Node.js、npm、各种依赖……光是想想那些命令行敲来敲去就够呛。之前装个Jenkins都折腾了大半天，各种报错，各种查文档，最后好不容易弄好了，人都快累趴下了。那天正好看到有人推荐Wisdom SSH这个工具，说是集成了AI的SSH终端，能自动生成命令。我一开始还不信，心想这不就是换个壳的SSH客户端嘛，能有多大的区别。结果用了一次之后，真香。Wisdom SSH这玩意儿官网在wisdomheart.cn，下载安装挺简单的。装好之后打开，界面左边是服务器列表，右边有个AI对话区，就像咱们平时用的聊天窗口一样。连接服务器的方式跟普通SSH工具差不多，填个IP、用户名、密码就能连上。官网地址：https://www.wisdomheart.cn/我这次用的是一台debain13的服务器，配置不算高，2核4G，跑个OpenClaw应该够用。连上服务器之后，我就在AI对话区里敲了一句话：帮我安装OpenClaw。就这么简单的一句话。AI那边停顿了几秒，然后开始给我列步骤。它会先检测系统环境，看看有没有装Node.js，版本是多少，npm有没有，Python环境怎么样。这些要是自己手动查，得敲一堆命令，现在AI自动就帮你搞定了。检测完之后，AI告诉我这台服务器上Node.js版本太老，需要升级到18以上才能装OpenClaw。然后它直接给出了安装命令，我点一下"执行"，命令就自动在终端里跑了。curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash - sudo apt-get install -y nodejs看着命令一行行跑过去，心里还挺踏实的。以前装这些东西，命令记不住，还得去百度，复制粘贴还怕弄错。现在好了，AI直接生成，我只需要确认执行就行。Node.js装好之后，AI又提示说需要安装pnpm，因为OpenClaw推荐用pnpm来管理依赖。这个我之前还真不知道，一直用的npm。AI说pnpm比npm快，而且节省磁盘空间，行吧，那就装。npm install -g pnpm装完pnpm，AI让我克隆OpenClaw的仓库。这个步骤我倒是挺熟悉的，git clone嘛，谁不会。不过AI生成的命令比我想的周全，它还加了个参数，指定克隆深度，这样下载速度快很多。git clone --depth 1 https://github.com/openclaw/openclaw.git克隆完之后进入目录，AI提示说要用pnpm安装依赖。我点执行，然后就开始了漫长的等待。依赖包挺多的，下了得有十几分钟。中间网络有点波动，我还以为要挂，结果pnpm自己重试了几次，最后还是装完了。依赖装好之后，AI说需要配置API密钥。这个是OpenClaw的核心，得有个大模型的API才能用。我之前在OpenAI注册过账号，还有点余额，就把API Key填进去了。配置文件在项目目录下的.env文件里，AI直接帮我打开编辑，我把Key粘贴进去，保存。然后就是启动了。AI给出的命令是：pnpm run dev敲回车，终端里开始刷日志。看着那些绿色的"success"字样，心里还是挺激动的。最后显示服务启动在localhost:3000端口，我本地浏览器访问服务器的IP:3000，果然看到了OpenClaw的界面。说实话，整个过程比我想象的顺利多了。要是以前，光是查各种依赖的安装方法就得折腾好久，还不一定能一次成功。这次用Wisdom SSH，基本上就是跟着AI的提示走，点几下执行按钮，就搞定了。不过中间也遇到点小插曲。启动的时候报了个错，说是端口被占用。我一看，原来服务器上之前跑了个测试服务，占用了3000端口。我正准备去查怎么杀进程，AI已经给出了命令：lsof -i:3000 kill -9 <PID>直接把占端口的进程干掉了。然后重新启动，一切正常。还有个问题是环境变量。OpenClaw需要设置一些环境变量，AI提示说最好写到.bashrc里，这样每次登录都会自动加载。它生成的命令是：echo 'export OPENCLAW_API_KEY=你的key' >> ~/.bashrc source ~/.bashrc这种细节要是自己弄，很容易忘，到时候服务跑起来找不到Key，又得排查半天。用下来感觉Wisdom SSH最大的优势就是省心。以前装东西，得自己查文档，看教程，还得注意版本兼容性，稍不留神就踩坑。现在AI帮你把这些问题都考虑到了，生成的命令也比较靠谱，至少我这次装…

缓存选型踩坑记：Redis 和 Memcached 到底该怎么选？
type: item
date: 2026-03-19T14:04:04+00:00
description: 上周三凌晨两点，我被一个电话吵醒。电话那头是开发小哥，声音有点抖：「哥，线上缓存挂了，用户登录全部失败。」我脑子瞬间清醒了一半，爬起来开电脑一看，监控图上那条线直接躺平了。Memcached 集群某个节点内存爆了，触发淘汰策略，连带着把会话数据全给清了。那一晚我算是彻底明白了，缓存选型这事儿，真不是随便拍脑袋就能定的。今天就想跟大家聊聊 Redis 和 Memcached 这两个老家伙，到底有什么区别，实际生产里该怎么选。网上文章一大堆，但很多都是照本宣科，我尽量用实际踩过的坑来聊。先说数据结构这事儿Memcached 这东西，设计思路特别纯粹，就是 key-value 存储。你存什么，它就拿什么，不会问你太多问题。代码写起来也简单：import memcache mc = memcache.Client(['127.0.0.1:11211']) mc.set('user:1001', '{"name": "张三", "age": 28}') data = mc.get('user:1001')看着挺清爽对吧。但问题也在这儿，你想存个列表怎么办？想存个哈希怎么办？只能自己序列化，存成字符串。取出来的时候再反序列化。有一次我们做商品库存管理，每个商品有多个规格，每个规格又有不同的库存数量。用 Memcached 的话，我得把整个结构序列化存进去，每次修改某个规格库存，都得把整个对象取出来，改完再存回去。高并发的时候，这操作简直是灾难。后来换到 Redis 就舒服多了：import redis r = redis.Redis(host='127.0.0.1', port=6379) # 用 hash 结构存商品规格 r.hset('product:1001:stock', 'size:M', 100) r.hset('product:1001:stock', 'size:L', 50) r.hset('product:1001:stock', 'size:XL', 30) # 修改单个规格库存，不用动其他数据 r.hincrby('product:1001:stock', 'size:M', -1) # 直接拿某个规格 stock = r.hget('product:1001:stock', 'size:M')Redis 支持的数据结构多了去了，字符串、哈希、列表、集合、有序集合，还有位图、HyperLogLog 这些高级货。有时候想想，这玩意儿哪是缓存啊，简直就是个多功能工具箱。持久化，这个差别太大了Memcached 有个特点，数据全在内存里，重启就没了。听起来挺极端，但人家设计思路就是这样——缓存嘛，本来就可以丢。可实际生产里，有些数据你真不敢让它丢。比如用户会话、购物车、还有一些配置信息。有一次公司做活动，预热阶段把活动配置缓存在 Memcached 里，结果半夜机器重启，配置全没了，第二天活动直接开天窗。Redis 就不一样，它支持持久化。两种方式：RDB 快照：隔一段时间把内存数据快照到磁盘# redis.conf 配置 save 900 1 # 900 秒内至少 1 个 key 变化就保存 save 300 10 # 300 秒内至少 10 个 key 变化就保存 save 60 10000 # 60 秒内至少 10000 个 key 变化就保存AOF 日志：把每个写操作都记下来，重启时重放appendonly yes appendfsync everysec # 每秒同步一次，性能和安全性折中我一般建议生产环境两个都开着。RDB 做备份恢复快，AOF 保证数据不丢。虽然会牺牲点性能，但比起数据丢失的损失，这点性能真不算什么。当然也不是说 Memcached 就不能用。有些场景数据丢了就丢了，比如页面缓存、临时计算结果。这种用 Memcached 反而更合适，毕竟少了很多持久化的开销。内存管理，这里面的坑不少说到内存管理，这两个家伙的思路完全不一样。Memcached 用的是 slab 分配机制。它预先分配好不同大小的内存块，数据来了就找合适大小的块放进去。好处是内存碎片少，分配速度快。但问题也很明显——如果你存的数据大小参差不齐，内存浪费会比较严重。有次我们存用户信息，有的用户数据几百字节，有的几十字节。Memcached 按最大那块分配，结果内存利用率连 60% 都不到。监控看着内存还剩好多，实际已经存不进新数据了。Redis 的内存管理更灵活一些，它会根据数据实际大小动态分配。而且可以配置内存淘汰策略：# 内存满了之后怎么处理 maxmemory 2gb maxmemory-policy allkeys-lru # 淘汰最近最少使用的 key淘汰策略有好几种：volatile-lru：只淘汰有过期时间的 key…

小白也能懂，手把手教你 Windows 10 部署 OpenClaw 并接入飞书，打造你的私人 AI 助理！
type: item
date: 2026-03-09T16:04:47+00:00
description: 最近几个月，OpenClaw 这个开源项目真的火出圈了。身边好几个朋友都在问：“这玩意儿到底怎么装？能不能在飞书里用？”说实话，一开始我也被它的文档绕晕过——一会儿要配 Node.js，一会儿又是 Git、PowerShell 权限、飞书回调地址……但折腾几次之后，发现其实只要踩对坑，整个过程比想象中简单得多。今天我就把我在 Windows 10 上从零开始部署 OpenClaw，并成功接入飞书的全过程，毫无保留地写出来。不玩虚的，全是实操步骤，连“为什么卡在这一步”的坑我都给你标清楚。哪怕你是第一次接触命令行的小白，照着做也能跑起来。先说点实在的：你得准备啥？别急着开干，先看看你的电脑符不符合基本要求：操作系统：Windows 10 或 11（64位），我用的是 Win10 专业版 22H2内存：至少 4GB，建议 8GB 以上（OpenClaw 跑起来会吃点内存）磁盘空间：留出 2GB 以上空闲（C 盘别太满）网络：能正常访问 GitHub、Node.js 官网，最好有稳定的网络（国内用户可能需要耐心等下载）另外，你需要：一个 飞书开发者账号（个人免费注册就行）一个 大模型 API Key（比如豆包、Minimax、火山引擎等，国内可用），这里我用阿里百炼 首月只要7块钱第一步：装好基础环境（Node.js + Git）OpenClaw 是基于 Node.js 开发的，所以第一步必须装好它。1. 安装 Node.js打开 Node.js 官网 1，点击绿色的 “Windows Installer (.msi)” 下载安装包（推荐 LTS 版或最新版，目前我用的是 v24.13.0）。安装时最关键的一点：✅ 务必勾选 “Add to PATH” 和 “Automatically install the necessary tools”这两个选项决定了后面能不能顺利运行命令。其他一路默认下一步就行。装完后，打开 PowerShell（以管理员身份运行），输入：node -v npm -v如果看到类似 v24.13.0 和 10.5.0 的版本号，说明装好了。⚠️ 注意：有些老教程说用 Node.js 18 或 20，但实测 OpenClaw 最新版（2026.3）在 Node 24 上最稳，低于 22 可能直接报错。2. 安装 Git去 Git 官网 2 下载安装包。国内网速慢是常态，耐心等。一路下一步安装过程中，在 “Adjusting your PATH environment” 这一步，选择：Git from the command line and also from 3rd-party software这样 PowerShell 才能识别 git 命令。装完同样验证一下：git --version看到版本号就 OK。第二步：解除 PowerShell 脚本限制Windows 默认禁止执行远程脚本，所以我们得先放行。在 管理员权限的 PowerShell 中执行：Set-ExecutionPolicy RemoteSigned -Scope CurrentUser Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass系统会问你是否确认，输入 Y 回车就行。这一步做完，后面才能顺利运行安装脚本。第三步：安装 OpenClaw现在主角登场。iwr -useb https://openclaw.ai/install.ps1 | iex装完后验证：openclaw --version看到版本号（比如 2026.3.8）就说明成功了。第四步：首次配置（关键！选 QuickStart）接下来运行配置向导：openclaw onboard --install-daemon这里有几个选择，务必按我说的选，不然容易翻车：配置项配置内容I understand this is powerful and inherently risky. Continue?选择 ”Yes”Onboarding mode选择 “QuickStart”Model/auth provider选择 “Skip for now”，后续可以配置Filter models by provider选择 “All providers”Default model使用默认配置Select channel (QuickStart)选择 “Skip for now”，后续可以配置Configure skills now? (recommended)选择 “No”，后续可以配置。Enable hooks?按空格键选中，选择“Skip for now”，按回车键进入下一步。How do you want to hatch …

手把手教你用 cephadm 在 Ubuntu 22.04 上部署生产级 Ceph 集群（Quincy/Reef 版本通用）
type: item
date: 2026-03-08T14:36:31+00:00
description: 最近公司要上一套分布式存储，想要用 Ceph。说实话，我之前虽然接触过 Ceph，但都是测试环境玩玩，这次可是真刀真枪要上生产环境，压力山大。不过好在现在 Ceph 的部署工具已经成熟很多了，尤其是 cephadm 这套基于容器的部署方式，比早年手动编译、配置一堆服务省心太多了。今天这篇文章就把我从零开始搭建 Ceph 集群的过程完整记录下来，全程基于 Ubuntu 22.04 LTS，使用的是官方推荐的 cephadm 工具。无论是 Quincy（17.2.x）还是 Reef（18.2.x）版本，流程基本一致，你可以直接照着操作，部署完就能跑业务。一、先搞清楚你要搭什么在动手部署之前，先花一分钟搞清楚：Ceph 到底是个啥？简单说，Ceph 是一个开源的 软件定义存储（SDS）系统，它能把你一堆普通服务器的硬盘“揉”成一个超大、高可用、自动修复的统一存储池。最牛的是，它一套系统同时支持三种存储接口：块存储（RBD）：像云硬盘一样挂给虚拟机或容器用；文件存储（CephFS）：提供标准的 POSIX 文件系统，多个客户端可同时读写；对象存储（RGW）：兼容 AWS S3 和 OpenStack Swift，适合存图片、视频、备份等海量非结构化数据。这种“三合一”的设计，在业内非常少见。那有没有同类产品？有，比如：GlusterFS：也是开源分布式文件系统，主打文件存储，架构比 Ceph 简单，但扩展性和一致性稍弱，大规模场景下容易出现元数据瓶颈。MinIO / OpenIO：专注对象存储，轻量、易用，但不支持块和文件存储，功能单一。商业方案如 VMware vSAN、Dell PowerScale：功能强、服务好，但贵得离谱，还得绑定硬件。而 Ceph 的优势就很明显了：✅ 真正去中心化：没有元数据服务器单点瓶颈，靠 CRUSH 算法智能分布数据； ✅ 线性扩展：加机器就能扩容，性能和容量同步涨； ✅ 自愈能力强：硬盘坏了？节点宕了？Ceph 自己默默重建副本，业务无感； ✅ 完全开源免费：社区活跃，Red Hat、SUSE、Canonical 都深度集成，连 OpenStack 和 Kubernetes 原生都支持它。当然，Ceph 也不是没缺点——配置复杂、学习曲线陡、对网络要求高。但一旦跑稳了，那就是“省心又省钱”的代名词。尤其在私有云、边缘计算、AI 训练这些需要 EB 级存储的场景里，Ceph 几乎成了事实标准。所以，别被它吓住。只要方法对，部署其实没那么难。接下来，咱们就一步步把它跑起来。Ceph 不是随便几台机器就能跑起来的。它有几个核心角色：Monitor（mon）：负责维护集群状态，至少3个节点（奇数），不能挂。Manager（mgr）：提供监控、仪表盘等功能，一般和 mon 混部或单独部署2个。OSD（osd）：真正存数据的，每个节点挂一块或多块硬盘，越多越好。可选：MDS（用于 CephFS 文件系统）、RGW（对象存储网关）。我们这次的目标是：3 节点最小高可用集群，每台既是 mon/mgr，也跑 OSD，适合中小规模生产环境。硬件建议（别抠门）：CPU：每台至少 4 核内存：OSD 节点建议 8GB 起，最好 16GB+硬盘：每台至少 1 块 ≥1TB 的数据盘（SSD/HDD 都行，但别用系统盘）网络：千兆起步，万兆更佳，所有节点互通二、系统准备（所有节点都要做）1. 设置主机名和 hosts假设三台机器 IP 分别是：192.168.1.10 → ceph1192.168.1.11 → ceph2192.168.1.12 → ceph3在每台机器上执行（以 ceph1 为例）：sudo hostnamectl set-hostname ceph1然后编辑 /etc/hosts，三台机器都加上：192.168.1.10 ceph1 192.168.1.11 ceph2 192.168.1.12 ceph3⚠️ 注意：主机名必须和 hosts 里一致，否则后面 cephadm 添加 host 会报错。2. 关闭防火墙和 SELinuxUbuntu 默认没开 SELinux，但防火墙可能开着：sudo ufw disable检查一下：sudo ufw status # 应该显示 inactive3. 时间同步（非常重要！）Ceph 对时间敏感，不同步会出大问题：sudo apt update sudo apt install -y ntp sudo systemctl enable --now ntp验证：timedatectl # 看 NTP synchronized: yes4. 创建统一用户并配 sudo 免密虽然 cephadm 支持 root，但官方建议用普通用户。我们在三台机器都创建 ceph…

从理念到架构：一文彻底讲透 DevOps 的本质与落地实践
type: item
date: 2026-03-07T12:57:47+00:00
description: 很多人第一次听说 “DevOps”，脑子里立刻蹦出一堆工具名：Jenkins、Docker、K8s、GitLab CI、Argo CD……好像不用这些，就不配谈 DevOps。但干了几年一线运维后，我越来越清楚一件事：DevOps 不是工具堆砌，而是一场协作方式的革命。它要解决的，从来不是“怎么自动化”，而是“为什么开发和运维总在互相甩锅”。今天这篇文章，我就用最接地气的方式，从核心理念讲起，再结合真实生产环境中的经典架构模式，带你完整理解 DevOps 到底是什么、为什么重要、以及该怎么落地。不吹概念，只讲能用的。一、DevOps 的起点：那堵看不见的墙想象一个场景：开发写完代码，本地测试通过，兴高采烈地交给运维：“上线吧！”运维拿到代码，发现没写依赖清单、没配环境变量、连日志路径都没统一。部署失败，系统崩了。开发说：“我本地能跑啊！”运维回怼：“你本地又不是生产环境！”这种扯皮，在传统模式下太常见了。开发只对“功能实现”负责，运维只对“系统稳定”负责——目标割裂，责任模糊，交付自然又慢又脆。更惨的是，有些公司上线全靠“四大金刚”（四个资深运维手动操作），脚本五花八门，流程全靠口传。疫情期间开发可以居家轮班，运维却必须24小时待命——人累，系统也慢。这就是 DevOps 要打破的局面。二、DevOps 的核心：不是工具，是文化DevOps 的本质，就一句话：谁构建，谁负责。它要求开发不再只关心“代码能不能跑”，还要关心“代码能不能在线上安全、稳定、快速地跑起来”；也要求运维不再只是“守门人”，而是提供标准化、自助化的平台能力，让开发能安全地自主发布。这不是岗位合并，而是责任共担、目标对齐。当开发开始主动写 Dockerfile、配健康检查、看监控告警，当运维开始参与需求评审、理解业务逻辑，那堵墙才算真正拆了。而工具，只是实现这种协作的“加速器”。没有文化，光有 Jenkins，照样是“伪 DevOps”——流程自动化了，但沟通还是断的。三、DevOps 的落地：四种经典架构模式理念明白了，接下来就是怎么干。不同规模、不同行业的团队，适合的 DevOps 架构完全不同。下面这四种，都是我在生产环境中见过、用过、甚至亲手搭过的。1. 轻量自助型（适合创业公司 / 小团队）典型场景：3~10人团队，既要快又要省成本，没人专职搞平台。架构特点：代码托管：GitLab（自带 CI，省事）流水线：GitLab CI 或 GitHub Actions部署方式：Docker + Ansible 脚本部署到云服务器（如阿里云 ECS）环境：dev / staging / prod 三套，配置通过环境变量注入监控：Sentry（错误追踪）+ 云厂商基础监控流程：开发提交代码 → 自动跑测试 → 构建镜像 → 推送到镜像仓库 → 手动点击“发布到生产” → 自动执行部署脚本。关键设计：所有部署脚本统一管理，避免“一人一套脚本”的混乱prod 发布需二次确认，防止误操作保留历史镜像，支持一键回滚我帮一个做 SaaS 工具的创业团队搭过这套，三人团队每天能发3~5次版。开发自己点发布，运维只负责兜底。虽然“土”，但效率翻倍。2. 微服务 + GitOps 型（中大型互联网企业主流）典型场景：业务已拆成几十上百个微服务，需要强一致性、高可观测性。架构特点：代码仓库：GitHub（业务代码） + GitLab（K8s Manifests）CI：GitHub Actions（构建镜像）CD：Argo CD（实现 GitOps）编排：Kubernetes配置管理：Helm / Kustomize可观测性：Prometheus + Loki + Grafana（全链路）核心思想：集群的期望状态由 Git 仓库定义。比如，你在 Git 里把 user-service 的镜像 tag 从 v1.1 改成 v1.2，Argo CD 会自动检测变更，并将线上集群“纠正”到目标状态。优势：环境完全一致，告别“开发正常、生产报错”所有变更可追溯（看 Git 提交记录就行）回滚秒级完成，权限可控某跨境电商用这套支撑大促，50+ 微服务每天部署上百次。他们甚至把数据库迁移脚本也纳入 GitOps，合规审计直接拉 Git 日志，省了无数人力。3. 稳敏双态型（金融 / 政务行业专属）典型场景：既要满足银保监会等强监管，又要支持互联网业务快速迭代。架构设计：稳态业务（如核心交易系统）：走传统流程，多级审批、人工部署、强审计，发布频率低但绝对安全敏态业务（如活动页、营销系统）：走标准 DevOps 流水线，自动化部署、灰度发布、快速试错统一平台层：共用代码仓库（按项目打标签区分）共用监控、日志、安全扫描能力统一权限与审计中心某股份制银行实施后，敏态业务迭代周期从2周缩到3天，稳态系…

别再傻傻分不清了！Containerd 和 Docker 到底有啥区别？命令、架构全拆解
type: item
date: 2026-03-06T15:25:13+00:00
description: 前阵子有个刚入行的小伙伴跑来问我：“哥，我听说现在 Kubernetes 都不用 Docker 了，改用 Containerd，那是不是以后 Docker 就废了？我学 Docker 还有意义吗？”我当时差点一口老血喷出来——这问题问得，就跟“微信被抖音干掉了，我还用不用装微信”一样离谱。其实啊，Docker 没死，只是它的一部分功能被“剥离”出去了，而那个被剥离出来的核心组件，就是 Containerd。今天咱们就掰开揉碎了讲讲：Containerd 和 Docker 到底有啥区别？从命令行操作到底层架构，一条条给你捋清楚。这篇文章不灌鸡汤，全是我在生产环境里踩过的坑、调过的参数、看过的日志堆出来的干货。先说个前提：Docker 其实是个“全家桶”。你平时用 docker run、docker build，背后其实是一整套工具链在干活。这套工具链里，真正负责和 Linux 内核打交道、创建容器、管理镜像的，并不是 Docker 本身，而是它内部的一个叫 containerd 的守护进程。你可以把 Docker 想象成一个“外卖平台”——你点个“宫保鸡丁”，平台接单（Docker CLI），然后派单给后厨（containerd），后厨炒菜（拉镜像、启容器），最后骑手送餐（网络、存储等）。而 Containerd 呢，就是那个后厨，只管做菜，不管接单也不管送餐。所以，Kubernetes 把 Docker “踢出局”，其实是说：“我不需要你这个外卖平台了，我自己会接单（Kubelet 直接调 containerd），你把后厨交出来就行。”于是 Docker 把 containerd 开源给了 CNCF（云原生基金会），现在它是个独立项目，谁都能用。那从命令行角度看，差别大吗？如果你习惯了 docker ps、docker images、docker exec，那你直接切到 containerd 上，会有点懵——因为 containerd 根本没有这些命令！Containerd 提供的是 ctr 和 crictl 两个命令行工具。注意，这两个不是一回事：ctr 是 containerd 自带的调试工具，功能齐全但不稳定，官方明确说“别在生产环境用”。crictl 是 Kubernetes CRI（容器运行时接口）标准下的命令行工具，专为 K8s 设计，推荐在集群节点上使用。举个例子：你想看当前有哪些容器在跑：# Docker 方式 docker ps # ctr 方式（不推荐生产用） ctr containers list # crictl 方式（K8s 节点推荐） crictl ps再比如拉个镜像：# Docker docker pull nginx # ctr ctr image pull docker.io/library/nginx:latest # crictl（注意：crictl 不能直接 pull，得通过 pod sandbox 或 runtime 接口间接拉） # 所以通常 crictl 不用来拉镜像，而是配合 kubelet 自动拉看到没？ctr 的命令更底层，参数也更啰嗦。而且 ctr 拉下来的镜像，默认命名空间是 default，而 K8s 用的是 k8s.io。如果你用 ctr 拉了个镜像，K8s 可能根本看不到——因为不在同一个命名空间里！这就导致一个经典翻车现场：运维同学在 K8s 节点上用 ctr pull 了一个镜像，然后纳闷“为啥 Pod 还在 ImagePullBackOff”？结果一查，镜像在 default 命名空间，而 kubelet 在 k8s.io 里找，当然找不到。正确的做法是：ctr -n k8s.io image pull nginx:latest加个 -n k8s.io 指定命名空间，这样 kubelet 才能认。再说架构差异，这才是重点。Docker 的架构是这样的（简化版）：用户 → Docker CLI → Docker Daemon (dockerd) → containerd → runc → Linux Kernel其中：Docker CLI：你敲的 docker 命令Docker Daemon (dockerd)：后台服务，负责解析命令、管理镜像、网络、卷等containerd：负责容器生命周期管理（创建、启动、停止等）runc：OCI 标准的容器运行时，真正调用 clone()、mount() 等系统调用创建容器而纯 Containerd 的架构（比如在 K8s 中）是：Kubelet → CRI Plugin → containerd → runc → Linux Kernel这里少了 Docker Daemon 这一层。Kubelet 通过 CRI（Cont…

别再折腾 iptables 了！用 cproxy + wstunnel 轻松搞定 Linux 透明代理，内网穿透稳如老狗
type: item
date: 2026-03-04T15:00:26+00:00
description: 最近有个朋友找我帮忙，说他们公司有个老旧的 Linux 服务器，跑着一堆内部服务，现在想让这些服务能通过公网访问，但又不能直接暴露端口，防火墙策略也卡得死死的。常规的反向代理方案搞不定，因为应用层根本没做任何代理适配，总不能一个个改代码吧？这时候我就想到了“透明代理”——对应用完全无感，流量在系统层面就被劫持转发，上层程序压根不知道自己走的是代理。听起来很玄乎？其实没那么复杂，关键就俩工具：cproxy 和 wstunnel。今天这篇，我就手把手带你把这套组合拳打出来，顺便聊聊我在生产环境里踩过的坑、调过的参，保证你照着做就能跑起来。先说说 cproxy 是啥cproxy 不是那种大厂开源的明星项目，它是个轻量级的透明代理工具，专门干一件事：把本地发出的 TCP 流量重定向到指定的 SOCKS5 或 HTTP 代理。它底层用的是 Linux 的 TPROXY 模块（不是 REDIRECT！），所以能保留原始目的地址，特别适合做透明代理。很多人一听到“透明代理”就想到 iptables + redsocks / proxychains，但那些方案要么配置复杂，要么兼容性差。cproxy 的优势在于：配置简单、性能不错、支持 UDP（虽然我们这次主要用 TCP），而且它能和 wstunnel 完美配合——后者能把任意 TCP 流量封装成 WebSocket，轻松绕过企业防火墙。场景还原：为什么需要这个组合？假设你有台内网机器 A（192.168.1.100），上面跑了个 Web 服务（比如 8080 端口）。现在你想让外网用户通过你的公网服务器 B（比如 example.com）访问这个服务，但：服务器 A 不能直接开公网 IP防火墙只允许出站 443（HTTPS）你不想改 Web 应用的代码或配置这时候，常规思路是用 frp/ngrok，但它们依赖中心节点，而且有些环境连 frp 的自定义端口都不让连。而 wstunnel 可以把流量伪装成正常的 WebSocket（走 443），再配合 cproxy 做透明劫持，整个链路就通了。实操开始：部署 wstunnel先在公网服务器 B 上起一个 wstunnel 服务端。wstunnel 的 GitHub 仓库是 https://github.com/erebe/wstunnel，安装很简单，直接下二进制就行：# 在服务器 B（公网）上执行 wget https://github.com/erebe/wstunnel/releases/latest/download/wstunnel-linux-amd64 -O /usr/local/bin/wstunnel chmod +x /usr/local/bin/wstunnel然后启动服务端，监听 443 端口（假装是 HTTPS）：wstunnel server --port 443 --restrictTo "127.0.0.1:8080" wss://example.com--restrictTo 是安全限制，只允许转发到本机的 8080 端口（后面我们会把内网流量打到这里）。注意：如果你已经有 Nginx 占用 443，可以用 --port 8443，然后用 Nginx 反代 /wstunnel 路径到 8443，这里为了简化先直接占 443。内网机器 A：部署 cproxy + wstunnel 客户端现在回到内网机器 A（192.168.1.100）。首先装 cproxy。它没有官方 release，但源码编译非常快：git clone https://github.com/txthinking/cproxy.git cd cproxy make sudo cp cproxy /usr/local/bin/接着，在 A 上启动 wstunnel 客户端，连接到公网服务器 B：wstunnel client wss://example.com --udp --tcp -L 127.0.0.1:1080这行命令的意思是：把本地 1080 端口作为 SOCKS5 代理，所有流量通过 wss://example.com 隧道转发。--udp --tcp 表示同时支持两种协议（虽然我们主要用 TCP）。现在，1080 端口就是一个“出口”，所有发往这里的流量都会被 wstunnel 打包成 WebSocket，从 443 出去。关键一步：用 cproxy 把流量劫持到 1080接下来就是透明代理的核心了。cproxy 的作用是：监听一个本地端口（比如 12345），把所有发往它的 TCP 连接，通过 SOCKS5 代理（127.0.0.1:1080）转发出去。启动 cproxy：cproxy -l 12345 -a 127.0.0.1…

让AI替你SSH进服务器，5分钟搞定故障排查！运维人终于能睡整觉了
type: item
date: 2026-03-02T13:19:58+00:00
description: 最近我遇到了一个特别有意思的场景，让我对AI运维有了全新的认识。事情是这样的：我有一台Rocky Linux服务器需要部署WordPress，但我不想手动敲那些繁琐的命令。于是我就想，能不能让AI直接帮我操作服务器？结果发现，现在真的有工具能做到这一点——通过sshmcp协议。什么是sshmcp？这玩意儿到底有多神奇说实话，第一次听说sshmcp的时候我还以为是什么新的加密协议。后来才知道，这是基于MCP（Model Context Protocol）协议的一个SSH工具，专门为了让AI能够安全地远程操作服务器而设计的。简单来说，sshmcp就像是给AI配了一个"数字手"，让它能够通过SSH连接到你的服务器，执行命令、传输文件，甚至帮你排查问题。但最关键的是，它不会把你的SSH密码直接暴露给AI模型，所有的凭据都在本地管理，从根源上保证了安全性[5]。如何开始使用sshmcp项目地址：https://github.com/classfang/ssh-mcp-server/blob/main/README_CN.md我使用的ai工具是：Cherry Studio项目地址：https://www.cherry-ai.com/安装完成后配置大模型大模型配置好后安装mcp如果你也想体验这种AI运维的感觉，其实并不复杂。根据官方文档，你可以通过NPX直接运行ssh-mcp-server：npm i @fangjunjie/ssh-mcp-server或者如果你更喜欢Python版本，也可以使用：pip install ssh-mcp-server ssh-mcp-server --config your-config.json添加mcp服务器配置文件通常包含你的SSH连接信息：{ "mcpServers": { "ssh-mcp-server": { "command": "npx", "args": [ "-y", "@fangjunjie/ssh-mcp-server", "--host", "192.168.198.133", "--port", "22", "--username", "root", "--password", "pwd123456" ] } } }一旦配置完成，任何支持MCP协议的AI助手（比如Cursor、Trae等）就可以通过这个服务器来操作你的远程机器了[3]。sshmcp的核心优势：安全与效率的完美平衡说到sshmcp，我觉得它最厉害的地方在于解决了AI运维的最大痛点——安全性。传统的做法要么是把SSH密钥直接给AI（极其危险），要么就是完全手动操作（效率低下）。而sshmcp通过以下机制保证了安全：凭据隔离：SSH凭据完全在本地管理，永远不会暴露给AI模型命令控制：可以通过黑白名单机制精确控制允许执行的命令范围标准化接口：遵循MCP协议规范，可与所有支持该协议的AI助手无缝集成双向文件传输：不仅支持命令执行，还支持安全的文件上传下载这意味着你可以放心地让AI帮你处理日常运维任务，而不必担心服务器被黑或者数据泄露。操作演示-让ai安装lnmp环境，部署wordpress发现端口占用处理实际应用场景：不止是部署WordPress虽然我用WordPress部署作为例子，但sshmcp的应用场景远不止于此：应急响应：当服务器出现故障时，AI可以立即连接并执行诊断命令，快速定位问题所在[2]。批量操作：如果你管理着多台服务器，AI可以同时连接所有服务器并执行相同的维护任务。配置管理：AI可以帮助你标准化服务器配置，确保所有服务器都遵循相同的安全策略。日志分析：AI可以直接读取服务器日志，分析异常模式并提供优化建议。安全审计：定期检查服务器的安全配置，发现潜在的风险点。安全考虑：别让便利成为隐患虽然sshmcp看起来很美好，但我们还是要保持谨慎。毕竟让AI直接操作生产服务器是有风险的。以下几点建议供参考：最小权限原则：为AI创建专用的SSH用户，只授予必要的权限命令限制：使用黑白名单严格控制AI可以执行的命令审计日志：记录AI执行的所有操作，便于事后审查测试环境先行：先在测试环境中验证AI的操作逻辑人工审核关键操作：对于删除、重启等高危操作，要求人工确认未来展望：AI运维的新时代说实话，体验过这种AI辅助的运维方式后，我真的觉得传统手动运维有点过时了。想象一下，以后我们可能只需要告诉AI："帮我优化这台服务器的性能"，它就能自动分析瓶颈、调整配置、应用最佳实践。当然，这并不意味着运维工程师会被取代。相反，我们的角色会从"操作工"转变为"策略制定者"和"质量监督员"。我们需要设计更好的自动化流程，制定更智能的运维策略，同时确保AI的行为符合我们的预期和安全要求。总结回到我最初的那个WordPress部署案例，虽然我…

别再瞎猜了！K8s生产环境排错实战手册：从Pod卡住到服务503，这些坑我都替你踩过了
type: item
date: 2026-03-01T13:58:50+00:00
description: 说实话，K8s这玩意儿，部署起来可能半小时搞定，但真到了生产环境出问题，那可真是“一小时定位，三小时复盘，五小时背锅”。今天这篇文章，不讲理论，不画架构图，就聊点实在的——生产环境真实遇到的排错案例 + 详细处理过程 + 踩过的坑。内容全来自我亲手处理过的故障，有些甚至半夜三点被电话叫醒去救火。如果你也在搞K8s，建议收藏，说不定哪天就用上了。🧯 场景一：Pod 卡在 Pending，你以为是资源不够？前几天，测试团队反馈新上线的服务一直起不来，kubectl get pod 看到状态是 Pending。第一反应：是不是节点资源不够？赶紧 kubectl describe pod xxx 一看：Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning FailedScheduling 2m default-scheduler 0/5 nodes are available: 5 Insufficient cpu.看起来确实是 CPU 不够。但奇怪的是，集群明明还有两台空闲节点，CPU 使用率不到30%。这时候很多人就懵了：“资源明明够啊，为啥调度不过去？”真相其实是：QoS 和 PriorityClass 在背后搞鬼。我们项目里为了保障核心服务，给某些 Pod 设置了高优先级（PriorityClass）。而这个新上线的服务没配，结果被调度器直接“降级”了——即使有资源，也得等高优先级任务跑完再说。排查命令：# 查看当前集群所有 PriorityClass kubectl get priorityclass # 查看 Pod 是否绑定了 PriorityClass kubectl get pod <pod-name> -o jsonpath='{.spec.priorityClassName}'解决办法：如果是非核心业务，可以临时调低其他高优 Pod 的副本数；或者给这个新服务也配上合适的 PriorityClass；更彻底的做法是：在命名空间级别设置 ResourceQuota + LimitRange，避免资源被无限制抢占。💡 小提醒：别只看 kubectl describe 的 Events 表面信息。有时候“Insufficient cpu”只是障眼法，真正原因是亲和性（affinity）、污点（taint）或调度插件策略。🌪️ 场景二：服务间歇性 503，日志却一切正常？这是最让人抓狂的问题之一。用户访问接口，偶尔返回 503 Service Unavailable，但 kubectl logs 看应用日志，完全正常，连 error 都没有。重启 Pod？暂时好了，几小时后又来。一开始以为是应用 Bug，后来发现：根本不是应用的问题，而是 conntrack 表溢出了！K8s 默认用 iptables 做 Service 转发，而 iptables 依赖内核的 conntrack 模块记录连接状态。当并发连接数暴增（比如大促、压测、爬虫攻击），conntrack 表满了，新连接直接被丢弃，表现为“服务不可达”，但容器本身毫无感知。怎么确认？登录到 Pod 所在节点，执行：# 查看当前 conntrack 连接数 sysctl net.netfilter.nf_conntrack_count # 查看最大限制 sysctl net.netfilter.nf_conntrack_max如果 count 接近 max（默认一般是 65536），基本就是它了。解决方案：临时扩容（应急）：sysctl -w net.netfilter.nf_conntrack_max=262144长期优化：改用 IPVS 模式（性能更好，不依赖 conntrack）；或者调整 kube-proxy 配置，启用 strictARP: true + 合理设置 conntrack 参数；对外暴露的服务，前面加一层 Nginx 或 LVS 做连接收敛。📌 血泪教训：有一次我们没注意，大促当天凌晨 conntrack 满了，导致支付回调失败，损失几十万订单。从此以后，监控里必加 nf_conntrack_count 指标。🔌 场景三：PVC 挂载失败，Pod 卡在 ContainerCreating这种情况太常见了。你写了个 StatefulSet，挂了个 PVC，结果 Pod 一直卡在 ContainerCreating，describe 一看：MountVolume.SetUp failed for volume "pvc-xxx" : mount failed: exit status 32或者：Unable to attach or mount volu…

K3s保姆级实战：从单机“点亮”到生产集群搭建，别再对着官方文档发呆了
type: item
date: 2026-02-28T14:04:20+00:00
description: 上一篇咱们聊了K3s的定位，后台有不少兄弟私信我：“老哥，道理我都懂，但到底怎么装？官方文档那一堆参数看得我脑仁疼，能不能来点直接能抄作业的？”没问题。今天这篇咱们不整虚的，直接开搞。我把话放这儿：只要你有一台能联网的Linux机器（甚至虚拟机），跟着我这篇走，半小时内你要是跑不起来一个带Ingress、带存储的K8s集群，我把键盘吃了。但这不仅仅是简单的安装教程。我是做运维的，我知道咱们在生产环境会遇到什么——内网隔离、镜像拉不动、证书过期、节点死活加不进去。这些坑，我都替你们填平了。准备好了吗？打开你的终端，咱们开始。第一阶段：环境准备（别跳过，这是血泪史）很多新手上来就跑安装脚本，结果报错报得怀疑人生。其实90%的问题都是环境没收拾干净。在跑任何K3s命令之前，你先检查这几样东西：1. 你的 Hostname（主机名）K3s（以及K8s）对主机名非常敏感。别用 localhost 这种名字，也别用带下划线 _ 的奇葩名字。乖乖地，改成标准的DNS兼容格式，比如 node-1、k3s-master。hostnamectl set-hostname k3s-master-01 # 改完记得退出重进一下终端，或者 source /etc/profile2. 关闭防火墙和 Swap虽然K3s声称支持Swap，但为了稳妥（特别是新手），我建议还是关了。防火墙是大坑。如果你不是网络专家，搞不定iptables那些复杂的转发规则，就把 firewalld 或者 ufw 关了。systemctl stop firewalld systemctl disable firewalld swapoff -a # 记得去 /etc/fstab 里把 swap 那行注释掉，不然重启又回来了3. 时间同步这个我强调过无数次了。集群节点之间时间误差超过几秒，认证证书直接失效，节点状态全是 NotReady。装个 chrony 也就是一分钟的事儿。第二阶段：单机急速部署（Hello World 级别）如果你只是想在笔记本虚拟机或者开发环境试水，用这个模式。官方给的脚本是 curl -sfL https://get.k3s.io | sh -。但是！ 如果你在国内，直接跑这个脚本，你可能会卡在下载二进制文件那一步，或者卡在拉取 pause 镜像那一步。咱们用个“魔改版”的命令，利用国内的镜像加速：curl -sfL https://rancher-mirror.rancher.cn/k3s/k3s-install.sh | \ INSTALL_K3S_MIRROR=cn \ sh -这就完了？对，这就完了。但是，作为一个老鸟，我通常会加几个参数，让它更符合我的使用习惯：curl -sfL https://rancher-mirror.rancher.cn/k3s/k3s-install.sh | \ INSTALL_K3S_MIRROR=cn \ INSTALL_K3S_EXEC="--write-kubeconfig-mode 644 --disable-cloud-controller" \ sh -解释一下这几个参数（这都是经验）：--write-kubeconfig-mode 644：这个太重要了。默认情况下，生成的 kubeconfig 文件只有 root 能读。你稍微切个普通用户想跑 kubectl，直接 Permission denied。加上这个，省去后续 chmod 的麻烦。--disable-cloud-controller：因为咱们是在裸机或者虚拟机跑，不需要去连AWS或者阿里云的云控制器，禁用了能省点内存。验证一下：装完后，等个几十秒（取决于你的网速拉镜像快慢），运行：kubectl get nodes如果看到状态是 Ready，恭喜你，你的单节点K3s集群已经活了。第三阶段：生产级集群搭建（Server + Agent 模式）好，现在咱们来点真格的。假设你有三台机器：192.168.1.10 (Master/Server)192.168.1.11 (Worker/Agent)192.168.1.12 (Worker/Agent)1. 启动 Master 节点在 1.10 上执行：curl -sfL https://rancher-mirror.rancher.cn/k3s/k3s-install.sh | \ INSTALL_K3S_MIRROR=cn \ INSTALL_K3S_EXEC="--node-ip 192.168.1.10 --flannel-iface eth0" \ sh ---node-ip：指定节点IP，防止多网卡环境K3s识别错了。--flannel-iface：指定Flannel网络走哪个网口。这个极其…