Cloud Native 16 min read

How I Migrated 60+ Ingresses from Nginx to Higress in Under 2 Minutes with AI

When Kubernetes announced the retirement of Ingress NGINX, the author used the OpenClaw AI tool and Higress to analyze, test, and fully automate the migration of over 60 Ingress resources, generating plugins, building WASM modules, and producing a verified operation manual in less than two minutes.

Ops Development Stories
Ops Development Stories
Ops Development Stories
How I Migrated 60+ Ingresses from Nginx to Higress in Under 2 Minutes with AI

Why Higress?

Ingress NGINX will be deprecated, and alternatives such as Traefik, Kong, Envoy Gateway, and Higress were evaluated. A large‑scale migration case from Sealos (over 2000 tenants) demonstrated Higress’s stability and performance, giving confidence to adopt it.

Preparation – Configure OpenClaw Skills

Clone the Higress repository and add the .claude/skills directory to OpenClaw:

git clone https://github.com/alibaba/higress.git
cd higress
# The skills are under .claude/skills

The directory contains two essential skills:

nginx-to-higress-migration – Main migration flow: compatibility analysis, simulation environment setup, test generation, and operation‑manual creation.

higress-wasm-go-plugin – Automatic generation of proxy‑WASM plugins when built‑in plugins are insufficient.

Step 1 – Analyze Existing Ingress Resources

Ask OpenClaw (via Discord) to collect the current Ingress configuration:

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 distinct nginx.ingress.kubernetes.io/* annotations

3 Ingresses using configuration-snippet (requiring special handling)

Step 2 – Build a Kind Simulation Environment

OpenClaw creates a local Kind cluster, imports the sanitized Ingress definitions, and installs Higress with the same ingressClass as NGINX:

# Create Kind cluster
kind create cluster --name higress-migration-test

# Install Higress (co‑exists with NGINX)
helm install higress higress/higress \
  -n higress-system --create-namespace \
  --set global.ingressClass=nginx \
  --set global.enableStatus=false

The flag global.enableStatus=false prevents Higress from updating the Ingress status field, allowing both controllers to run side‑by‑side safely.

Step 3 – Verify Compatibility

OpenClaw generates a test script covering all 63 routes and executes it against the local Higress instance:

# Generate test script
./scripts/generate-migration-test.sh > migration-test.sh
# Run tests against the Kind cluster
./migration-test.sh 127.0.0.1:8080

Results:

60 Ingresses passed using Higress built‑in plugins ( custom-response, ip-restriction, basic-auth).

The remaining 3 Ingresses required custom logic, so the higress-wasm-go-plugin skill was invoked.

Automatic WASM Plugin Generation

A Lua configuration‑snippet that updates device status in Redis was analyzed. OpenClaw produced type‑safe Go code for a proxy‑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.LogErrorf("Failed to decrypt device ID: %v", err)
        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(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 // downgrade on Redis failure
    }
    return types.HeaderStopAllIterationAndWatermark
}

Build and push the WASM module automatically:

# Build the WASM binary
cd payment-auth-plugin
go mod tidy
GOOS=wasip1 GOARCH=wasm go build -o main.wasm ./

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

Deploy the plugin via a WasmPlugin CRD:

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

Tests in the Kind cluster confirmed correct handling of valid, missing, and invalid parameters.

Step 4 – Generate an Operation Manual

After successful verification, OpenClaw outputs a concise checklist‑style manual covering pre‑checks, installation, plugin deployment, validation, DNS cut‑over, and rollback procedures. The manual is directly derived from the test logs, ensuring traceability.

# Nginx to Higress Migration Manual
## Pre‑checks
- [ ] Backup all Ingress resources
- [ ] Reduce DNS TTL to 60 s
- [ ] Configure monitoring alerts

## Migration Steps
1. Install Higress (≈5 min)
2. Deploy plugin configurations for the 3 snippet‑based Ingresses
3. Verify routes (≈10 min)
4. Switch traffic (≈5 min)
5. Monitor continuously

## Rollback
- Run the provided rollback command to restore NGINX control

Insights and Best Practices

Simulation environment is a safety net – Kind clusters cost near zero and catch >90 % of issues before production.

AI assists, does not replace human operators – OpenClaw performs analysis, validation, and code generation; final execution remains a manual, auditable step.

Well‑designed Skills matter – The migration skill separates compatibility analysis, simulation testing, and manual generation, making each phase independently verifiable.

Operation manual is backed by real test logs – Every instruction can be traced to a successful test in the simulated environment, eliminating hallucination risk.

Final Thoughts

Kubernetes warns that Ingress NGINX will be unsupported after two months, making migration urgent. Using the AI‑assisted workflow, the entire migration verification can be completed in about 30 minutes, freeing time for stakeholder communication and risk mitigation while keeping production changes under strict human control.

Related Links (plain URLs)

Sealos case study: https://sealos.run/blog/sealos-envoy-vs-nginx-2000-tenants

Higress migration skill: https://github.com/alibaba/higress/tree/main/.claude/skills/nginx-to-higress-migration

Higress official documentation: https://higress.io/

OpenClaw project: https://github.com/openclaw/openclaw

MigrationAIKubernetesIngressOpenClaw
Ops Development Stories
Written by

Ops Development Stories

Maintained by a like‑minded team, covering both operations and development. Topics span Linux ops, DevOps toolchain, Kubernetes containerization, monitoring, log collection, network security, and Python or Go development. Team members: Qiao Ke, wanger, Dong Ge, Su Xin, Hua Zai, Zheng Ge, Teacher Xia.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.