微信扫码
添加专属顾问
我要投稿
OpenClaw 实战迁移 Ingress NGINX,揭秘高效替代方案与自动化迁移技巧。 核心内容: 1. Ingress NGINX 退役倒计时带来的迁移挑战与解决方案 2. Higress 作为替代方案的核心优势与生产验证 3. OpenClaw 自动化迁移流程与关键技能配置
💡 目录 💡
00 起因
01 为什么选择 Higress?
02 准备工作:给 OpenClaw 配置 Skill
03 先说结论
04 为什么不让 AI 直接操作生产环境?
05 实战流程
06 生产环境执行
07 几点体会
08 写在最后
00
起因
周五下午四点半,主管把一条 Kubernetes 官方声明甩到群里:
"下周一之前,给我个迁移方案。"
我看了眼集群里 60 多个 Ingress 资源,还有零零散散的 snippet 配置,脑子里已经开始盘算要加班几个晚上了。这不是"性能优化"的小需求,这是安全合规的硬性要求。再不迁移,等 Ingress NGINX 停止维护,出了安全漏洞都没人修了。
此时,我想起了前阵子配置的 Clawdbot,以及 Higress 社区刚发布的迁移 Skill。
01
面对 Ingress Nginx 退役,市面上的替代方案不少:Traefik、Kong、Envoy Gateway、Higress 等。
选型时我参考了 Sealos 的实践。他们 2023 年就完成了迁移,量级是 2000+ 租户的超高并发场景,有详细的技术对比文章可以参考:《Sealos:为什么我们从 Nginx 切换到 Envoy/Higress(2000 租户实战)》[1]
这种量级的生产验证给了我信心,至少说明 Higress 在稳定性和性能上是经过大规模考验的。
02
准备工作:给 OpenClawd 配置 Skill
开始之前,需要让 OpenClaw 学会这套迁移技能。配置方式很简单,把 Higress 仓库的 Skills 目录给到 Clawdbot 就行:
https://github.com/alibaba/higress/tree/main/.claude/skills
这个目录下有两个关键 Skill:
配置好之后,OpenClaw 就具备了完整的迁移能力,包括在需要时自动开发 WASM 插件,不用你额外操心。
03
先说结论
整个迁移过程,我实际敲键盘的时间不超过 10 分钟。 OpenClaw 在本地 Kind 集群里跑完了所有验证,最后给我输出了一份详细的操作手册。我只需要 review 一下,然后在生产环境照着执行就行。
周五晚上六点,我准时下班了。
04
为什么不让 AI 直接操作生产环境?
我知道有些同学可能会问:既然 AI 这么能干,为什么不直接让它操作生产环境?
这个问题的答案是:因为我还想干到退休。
生产环境是红线,任何自动化工具都不应该直接碰生产。这不是 AI 能不能的问题,是运维原则问题。
这个 Skill 的设计思路非常对我胃口:AI 在仿真环境里折腾,人在生产环境里执行。各司其职,出了问题也能追溯。
05
实战流程
我直接在 Discord 里跟 OpenClaw 说:
帮我分析一下当前 K8s 集群的 ingress-nginx 配置,准备迁移到 Higress
OpenClaw 自动执行了这些命令:
kubectl get ingress -A -o yaml > ingress-backup.yaml
kubectl get configmap -n ingress-nginx ingress-nginx-controller -o yaml
kubectl get ingress -A -o yaml | grep "nginx.ingress.kubernetes.io" | sort | uniq -c
几秒钟后,它给我输出了分析报告:
关于那 3 个 snippet,OpenClaw 详细列出了它们的功能:
这一步是整个流程的精髓。
OpenClaw 自动用 Kind 在本地创建了一个 K8s 集群,然后:
# Clawdbot 执行的命令
kind create cluster --name higress-migration-test
# 安装 Higress(和 nginx 并行运行)
helm install higress higress/higress \
-n higress-system --create-namespace \
--set global.ingressClass=nginx \
--set global.enableStatus=false
关键配置:global.enableStatus=false
这个参数很重要。它让 Higress 不去更新 Ingress 的 status 字段,避免和 Nginx 打架。两个 controller 和平共处,各自处理同一批 Ingress。
OpenClaw 生成了测试脚本,覆盖所有 63 个 Ingress 的路由:
./scripts/generate-migration-test.sh > migration-test.sh
./migration-test.sh 127.0.0.1:8080
60 个直接通过,因为标准 annotation Higress 原生支持。
剩下 3 个使用 snippet 的,OpenClaw 分析后给出了解决方案:
原 Nginx 配置 | Higress 方案 |
User-Agent 识别移动端特定版本,重定向到移动页面 | 使用内置 |
IP 白名单 | 使用内置 |
Basic Auth | 使用内置 |
这三个都不需要写自定义 WASM 插件! Higress 内置插件直接覆盖。
关键是:原有 Ingress 资源完全不动。OpenClaw 自动生成了对应的插件配置(WasmPlugin CRD),在 Kind 环境里验证通过。
上面的案例比较顺利,内置插件就能覆盖。但我们还有另一套环境,情况就没这么简单了。那套环境的 IoT 平台有一段 Lua 脚本,实现了 设备在线状态上报到 Redis 的功能:
location /api/device/heartbeat {
access_by_lua_block {
local redis = require "resty.redis"
local red = redis:new()
-- 从请求参数中获取加密的设备号
local encrypted_device = ngx.var.arg_d
if not encrypted_device then
ngx.exit(400)
end
-- AES 解密设备号
local device_id = aes_decrypt(encrypted_device, secret_key)
if not device_id then
ngx.log(ngx.ERR, "Failed to decrypt device ID")
ngx.exit(403)
end
-- 连接 Redis 并更新在线状态
red:connect("redis.internal", 6379)
red:setex("device:online:" .. device_id, 300, os.time())
red:close()
}
}
这种自定义业务逻辑(Redis 操作 + 参数解密),没有任何内置插件能直接替代。以前遇到这种情况,要么硬着头皮学 WASM 开发,要么找借口拖延迁移。
神奇的是,我什么都不用做。
OpenClaw 在分析兼容性时发现这段 snippet 无法用内置插件替代,就自动调用了 higress-wasm-go-plugin skill,开始了插件开发流程。整个过程我只是在旁边看着:
OpenClaw 分析 Lua 代码,提取出核心逻辑:
d 读取加密设备号自动生成类型安全的 Go 代码:
// 自动生成的 WASM 插件核心逻辑
func onHttpRequestHeaders(ctx wrapper.HttpContext, cfg config.DeviceOnlineConfig) types.Action {
// 读取加密设备号参数
encryptedDevice := getQueryParam(ctx, "d")
if encryptedDevice == "" {
proxywasm.SendHttpResponse(400, "device-online.missing_param",
nil, []byte("Missing device parameter"), -1)
return types.ActionPause
}
// AES 解密设备号
deviceID, err := aesDecrypt(encryptedDevice, cfg.AESKey)
if err != nil {
proxywasm.LogErrorf("Failed to decrypt device ID: %v", err)
proxywasm.SendHttpResponse(403, "device-online.decrypt_failed",
nil, []byte("Invalid device ID"), -1)
return types.ActionPause
}
// 异步更新 Redis
key := fmt.Sprintf("device:online:%s", deviceID)
timestamp := fmt.Sprintf("%d", time.Now().Unix())
err = cfg.RedisClient.SetEx(key, timestamp, cfg.TTL, func(response resp.Value) {
if response.Error() == nil {
proxywasm.LogInfof("Device %s online status updated", deviceID)
}
proxywasm.ResumeHttpRequest()
})
if err != nil {
proxywasm.LogErrorf("Redis call failed: %v", err)
return types.ActionContinue // 降级:Redis 失败不阻塞请求
}
return types.HeaderStopAllIterationAndWatermark
}
生成的代码包含:
# Clawdbot 自动执行
cd payment-auth-plugin
go mod tidy
GOOS=wasip1 GOARCH=wasm go build -o main.wasm ./
编译成功,生成 main.wasm 文件。
# 构建 OCI 镜像并推送到 Harbor
docker build -t harbor.internal/higress-plugins/device-online:v1 .
docker push harbor.internal/higress-plugins/device-online:v1
自动生成 WasmPlugin CRD 并部署到 Kind 环境:
apiVersion: extensions.higress.io/v1alpha1
kind: WasmPlugin
metadata:
name: device-online
namespace: higress-system
spec:
url: oci://harbor.internal/higress-plugins/device-online:v1
phase: UNSPECIFIED_PHASE
priority: 100
defaultConfig:
aesKey: "${DEVICE_AES_KEY}"
redisCluster: "redis.internal:6379"
ttl: 300
然后自动跑测试:
# 正常请求(有效的加密设备号)
curl "http://localhost:8080/api/device/heartbeat?d=${ENCRYPTED_DEVICE_ID}"
# ✅ 200 OK
# Redis 验证:redis-cli GET device:online:device123 -> 当前时间戳
# 缺少参数
curl "http://localhost:8080/api/device/heartbeat"
# ✅ 400 Bad Request
# 无效的加密数据
curl "http://localhost:8080/api/device/heartbeat?d=invalid"
# ✅ 403 Invalid device ID
全部通过。
阶段 | 耗时 | 备注 |
需求分析 | 3 秒 | AI 解析 Lua 代码 |
代码生成 | 10 秒 | 生成完整 Go 项目 |
编译构建 | 3 秒 | WASM 编译 |
镜像推送 | 10 秒 | 推送到 Harbor |
部署验证 | 1 分钟 | CRD 部署 + 测试 |
总计 | < 2 分钟 | 全程无需手写代码 |
以前这种活,光是学 proxy-wasm SDK 就得一两天,写代码调试再一两天,前后加起来一周起步。现在 不到 2 分钟,而且生成的代码质量比我自己写的还规范。
这才是 AI 辅助开发该有的样子:不是帮你补全几行代码,而是把整个 DevOps 流程自动化。
验证全部通过后,OpenClaw 给我生成了一份操作手册:
# Nginx to Higress 迁移操作手册
## 前置检查
- [ ] 确认已备份所有 Ingress 资源
- [ ] 确认 DNS TTL 已降低(建议 60s)
- [ ] 确认监控告警已配置
## 迁移步骤
### 1. 安装 Higress(预计 5 分钟)
(具体命令)
### 2. 下发 snippet 替代配置(预计 10 分钟)
针对 3 个使用 snippet 的 Ingress,通过插件配置实现等效功能:
- 部署 custom-response 插件配置(替代 User-Agent 识别 + 移动端路由 snippet)
- 部署 ip-restriction 插件配置(替代 IP 白名单 snippet)
- 部署 basic-auth 插件配置(替代认证 snippet)
**注意:原有 Ingress 资源无需修改,保持 100% 兼容**
### 3. 验证 Higress 路由(预计 10 分钟)
(测试命令和预期结果)
### 4. 流量切换(预计 5 分钟)
(DNS/LB 切换步骤)
### 5. 观察监控(持续)
(关注指标清单)
## 回滚方案
(一键回滚命令)
06
周一早上,我拿着这份手册,花了 30 分钟完成了迁移:
全程零报警,零回滚。
关键优势:原有 Ingress 资源完全不需要修改,回滚就是切回 Nginx,配置还在,风险极低。
07
Kind 集群成本几乎为零,但能帮你发现 90% 的问题。让 AI 在仿真环境里折腾,比让人在生产环境里试错安全太多了。
OpenClaw 帮我干了分析、验证、生成文档这些脏活累活,但最终执行还是我来。这种分工很合理,AI 负责提效,人负责兜底。
这个 nginx-to-higress-migration skill 的设计思路很清晰:
如果设计成"AI 直接帮你迁移生产环境",我是绝对不敢用的。
这点很重要。OpenClaw 输出的操作手册,每一条都能追溯到 Kind 环境里的实际测试结果。哪个 Ingress 需要改、怎么改、改完预期什么效果,都是验证过的,不是 AI 凭空编出来的。
用 AI 最怕的就是幻觉,尤其是生产环境操作。这套流程的设计把幻觉风险降到了最低:先跑测试,再出文档,文档里的结论都有测试日志背书。
08
Kubernetes 官方声明说得很清楚:你只有两个月时间。
迁移这种事,以前要写方案、评审、排期、执行、验收,走完一套至少一周。但现在情况不一样了——ingress-nginx 退役后不再有安全更新,继续用就是在裸奔。
好消息是,有了 AI 辅助,一天就能搞定迁移验证。核心逻辑没变:生产环境必须由人来操作,AI 只是帮你提前验证和准备。
如果你还在用 ingress-nginx,别等了。两个月看起来很长,但要评估影响、准备方案、协调资源、灰度上线、观察稳定性……时间真的不多。
这个 Skill 能帮你把"迁移验证"这一步压缩到 30 分钟,省下来的时间用来做更重要的事。比如说服老板批预算,或者提前想好回滚方案。
53AI,企业落地大模型首选服务商
产品:场景落地咨询+大模型应用平台+行业解决方案
承诺:免费POC验证,效果达标后再合作。零风险落地应用大模型,已交付160+中大型企业
2026-02-03
引爆AI智能体时代!OrangePi 6Plus全面适配OpenClaw
2026-02-02
ClawdBot初体验:搭建/设置/应用
2026-01-31
一个人顶一个团队,已不是趋势:扎克伯格最新透露,AI工具在Meta内部显著提升产能
2026-01-30
Moltbot实战:MoltBot+RDS AI助手Skill管理RDS实例
2026-01-30
来火山引擎部署Moltbot,9.9元打造私人AI助手
2026-01-27
全网都在预测DeepSeek-R2功能,但它如何“落地企业”呢?
2026-01-25
硅谷顶级风投a16z最新报告:SaaS已死,AI应用的护城河来自三方面
2026-01-23
免费版Claude Cowork来了!支持Skills、定时任务、MCP,太赞了~
2026-01-01
2026-01-05
2025-12-23
2025-12-31
2025-12-30
2025-11-30
2025-12-18
2026-01-13
2025-12-04
2025-12-11
2026-01-27
2026-01-08
2025-12-29
2025-12-28
2025-12-21
2025-12-16
2025-08-20
2025-08-06