Migrate Ingress NGINX to Higress in Under 2 Minutes with OpenClaw AI

On a Friday afternoon the Kubernetes Steering Committee announced that Ingress NGINX will be retired in March 2026, warning that continued use would expose clusters to security risks. About half of cloud‑native environments will be affected, leaving only two months to prepare.

Why Choose Higress?

The author considered alternatives such as Traefik, Kong, Envoy Gateway, and Higress. Sealos had already migrated a 2000‑tenant, high‑concurrency environment to Higress in 2023, providing a detailed technical comparison.

Step 1 – Let OpenClaw Learn the Current State

Using a Discord chat with OpenClaw, the author asked the tool to analyze the cluster’s Ingress‑NGINX configuration. OpenClaw executed the following commands:

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

The analysis reported 63 Ingress resources, 18 different NGINX annotations, and three Ingresses that used configuration-snippet (a known migration pitfall).

Step 2 – Build a Kind Simulation Environment

OpenClaw created a local Kind cluster, imported the sanitized Ingress resources, deployed mock backend services, and installed Higress with the same ingressClass as the production NGINX controller:

# Create Kind cluster
kind create cluster --name higress-migration-test
# Install Higress alongside NGINX
helm install higress higress/higress \
  -n higress-system --create-namespace \
  --set global.ingressClass=nginx \
  --set global.enableStatus=false

The crucial flag global.enableStatus=false prevents Higress from updating the Ingress status field, allowing both controllers to coexist peacefully.

Step 3 – Verify Compatibility

OpenClaw generated a test script covering all 63 routes and ran it against the Higress controller:

./scripts/generate-migration-test.sh > migration-test.sh
./migration-test.sh 127.0.0.1:8080

Results: 60 Ingresses passed directly because their annotations are natively supported by Higress. The remaining three required custom handling.

Handling Custom Snippets

For the three problematic Ingresses, OpenClaw identified the snippets:

Custom response header

IP whitelist

Basic authentication

Higress provides built‑in plugins ( custom-response, ip-restriction, basic-auth) that replace these snippets, so no custom WASM code was needed.

When Built‑In Plugins Aren’t Enough

In a separate IoT scenario, a Lua snippet performed device heartbeat reporting to Redis with AES‑encrypted parameters. OpenClaw recognized that no built‑in plugin could replicate this logic and automatically invoked the higress-wasm-go-plugin skill to generate a Go‑based WASM plugin.

// Auto‑generated WASM plugin core logic
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
    }
    deviceID, err := aesDecrypt(encryptedDevice, cfg.AESKey)
    if err != nil {
        proxywasm.SendHttpResponse(403, "device-online.decrypt_failed", nil, []byte("Invalid device ID"), -1)
        return types.ActionPause
    }
    key := fmt.Sprintf("device:online:%s", deviceID)
    timestamp := fmt.Sprintf("%d", time.Now().Unix())
    err = cfg.RedisClient.SetEx(key, timestamp, cfg.TTL, func(resp resp.Value) {
        if resp.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 // degrade gracefully
    }
    return types.HeaderStopAllIterationAndWatermark
}

The tool then built, packaged, and pushed the plugin as an OCI image:

# Build OCI image
docker build -t harbor.internal/higress-plugins/device-online:v1 .
# Push to internal registry
docker push harbor.internal/higress-plugins/device-online:v1

Finally, OpenClaw created a WasmPlugin CRD and applied it to the Kind cluster:

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

All tests passed, confirming that the generated plugin behaved as expected.

Step 4 – Generate an Execution Handbook

OpenClaw produced a markdown‑style checklist covering pre‑checks, installation steps, snippet replacement via plugins, validation commands, DNS cut‑over, and rollback procedures. Each item is traceable to the Kind test results, eliminating AI hallucination.

Step 5 – Production Rollout

Using the handbook, the author completed the migration in about 30 minutes:

Install Higress alongside NGINX (no downtime).

Deploy plugin configurations to replace the three snippets.

Validate routing with the generated test suite.

Switch DNS/LB to Higress.

Monitor metrics – no alerts, no rollback.

The key advantage is that the original Ingress resources remain unchanged; rollback simply means disabling Higress.

Takeaways

Simulation environments are safe nets: Kind clusters cost almost nothing but catch >90 % of issues before production.

AI is a tool, not a replacement: OpenClaw automates analysis, testing, and code generation, while humans retain final execution control.

Well‑designed Skills matter: The migration skill follows a clear three‑phase workflow – compatibility analysis, simulated validation, and handbook generation.

Documentation must be backed by tests: Every handbook entry links to concrete Kind test outcomes, preventing hallucinated instructions.

With the official deprecation deadline only two months away, the author urges teams still on Ingress‑NGINX to adopt this AI‑assisted migration path, turning a week‑long effort into a half‑hour verification and execution process.